1

Тема: Для кожної задачі — свій інструмент

Відкривши підручник будь-якої довільно взятої мови програмування, ми, ймовірно, прочитаємо, що %LANGUAGENAME% — мова загального призначення. Але, як правило, це і правда, і неправда: з одного боку — так, ми можемо робити веб-сайти на Delphi, консольні текстові конвертери на Java'і, GUIшний графічний редактор на perl'і, і т.п. — технічні можливості для цього є, а часто й готові бібліотеки з необхідним мінімумом функціоналу для даного типу задач. Але, з іншого, чомусь так здебільшого не роблять. Справа не лише в можливостях конкретної мови чи навіть наявності бібліотек та фреймворків, а й також у спільноті, що склалась навколо тієї чи іншої мови, напрацьованому коді, зрештою, в вакансіях, де від спеціаліста з загальної мови А очікується вміння працювати з задачами типу α.

Так ось, хотілось би більш чітко окреслити, для чого та чи інша мова фактично використовується, наприклад:
php — тільки веб
perl — веб, шел-скрипти
Java — андроїд, сек'юрні веб-інтерфейси до комерційних баз даних, десктопні програми — якщо все узагальнити, користувацькі інтерфейси (?)
Python — сучасна заміна perl'у, плюс задачі штучного інтелекту (?), розподілені обчислення... (для чого насправді використовується Python?!)
Pascal — навчання студентів
С/C++ — практично все, що системне чи низькорівневе, бібліотеки й службові програми, критичні за швидкодією частини складних проектів; навчання студентів
Ruby — веб (а ще?..)
Haskell, LISP та ін. — усіляка езотерика з лямбдами (а насправді?..), навчання
LISP, Prolog — колись розглядались як мови для створення ШІ (це ще актуально?)
...

Подякували: leofun011

2

Re: Для кожної задачі — свій інструмент

Щонайменше, варто додати Lua як однозначно не менш широко вживану, порівняно з останніми пунктами переліку.

Подякували: P.Y.1

3

Re: Для кожної задачі — свій інструмент

Lordie написав:

Щонайменше, варто додати Lua як однозначно не менш широко вживану, порівняно з останніми пунктами переліку.

Переважно в комп'ютерних іграх, наскільки я розумію? Чи не тільки?

4

Re: Для кожної задачі — свій інструмент

P.Y. написав:
Lordie написав:

Щонайменше, варто додати Lua як однозначно не менш широко вживану, порівняно з останніми пунктами переліку.

Переважно в комп'ютерних іграх, наскільки я розумію? Чи не тільки?

Далеко не лише, але й перелік суто ігрових проектів з його підтримкою вельми чималий.

5 Востаннє редагувалося raxp (08.10.2016 16:57:33)

Re: Для кожної задачі — свій інструмент

Абсолютно всi натiв-мови використовують для:

практично все, що системне чи низькорівневе, бібліотеки й службові програми, критичні за швидкодією частини складних проектів; навчання студентів

...

Lua

останнiм часом захоплює ринок Інтернет-речей (IoT).

Подякували: P.Y.1

6

Re: Для кожної задачі — свій інструмент

Абсолютно всi натiв-мови використовують для...

Питання стосується не придатності, а мейнстріму: критичні частини коду в Java- чи Python-проекті можна й на паскалі чи фортрані переписати, але чомусь найчастіше беруть C++.

7

Re: Для кожної задачі — свій інструмент

Хаскель варто розглядати, коли ваша програма має прийняти щось на вхід, обробити його, і віддати результат обробки на вихід, при цьому без жорстких часових обмежень. Наприклад, компілятор. Або якась обробка зображень.

Подякували: P.Y., leofun012

8

Re: Для кожної задачі — свій інструмент

Питання стосується не придатності, а мейнстріму: критичні частини коду в Java- чи Python-проекті можна й на паскалі чи фортрані переписати, але чомусь найчастіше беруть C++.

ай эм залiзячник і WEB-а з JAVA та Python не торкаюся (останній взагалі використовував лише раз для роботи зі Скрайбусом), їх застосування в радіотехніці і електроніці практично наближається до нуля.

Звичайно, зустрічав пайтоновскі GUI-додатки для SDR, JAVA-інтерпретатори в модемах, але в підсумку, самі вони лише надбудови, яка використовує машину на натів, на яких написані бібліотеки, драйвери. Для десктопних застосувань, що вимагають швидкодії і жеруть мінімум системних ресурсів, застосувань в роботі з контролерами, процесорами натiв незамінні були і залишаться ще не один десяток рокiв. Скільки бачив GUI на JAVA, гальмо гальмом, жеруть все бiльше та бiльше, особливо додатки на #NET. А все тому, що нинішні розробники сидять на суперсучасному залiзі з купою системних тиків і RAM, та не піклуються про збереження пам'яті. А в підсумку, на старих і бiльш слабких машинах результат пригнічує. Ось такий вот мейнстрім.

9 Востаннє редагувалося Torbins (08.10.2016 21:12:49)

Re: Для кожної задачі — свій інструмент

Java для розробки десктопних прог використовують дуже рідко. Принаймні у мене на домашньому компі таких немає жодної. На роботі одна була, але на неї без сліз неможливо було дивитися.
С# - десктопний софт для вінди, та майже увесь софт для віндофонів. Також популярний в ентерпрайзі.
Delphi - для тих хто не вважає себе програмістом, але пам'ятає паскаль з інституту, і час від часу має потребу швиденько щось збацати для власних потреб.
SQL та мови на його основі - робота з базами даних.
JS - фронтенди для вебу.
Rust, Go - спроба виправити помилки в генетичному коді C++.

Подякували: P.Y., leofun012

10

Re: Для кожної задачі — свій інструмент

ай эм залiзячник і WEB-а з JAVA та Python не торкаюся (останній взагалі використовував лише раз для роботи зі Скрайбусом), їх застосування в радіотехніці і електроніці практично наближається до нуля.

А як щодо пітона на Raspberry Pi? Знаю, що таке існує, бо бачив одну таку залізяку в дії. Наскільки поширена подібна практика?

11

Re: Для кожної задачі — свій інструмент

можливо це буде отак виглядати,

Прихований текст

https://сайт-злодій/upload/2013/09/mem/shrek_30091156_orig_.jpeg

але запитаю: assambler?

12

Re: Для кожної задачі — свій інструмент

Java для розробки десктопних прог використовують дуже рідко

Ну так... усього лише якісь екзотичні виключення на зразок Eclipse, OpenOffice та добрячої половини IDE...

JS - фронтенди для вебу.

Розробники NodeJS пішли стрілятись

13

Re: Для кожної задачі — свій інструмент

але запитаю: assambler?

По-моєму, лише там, де потрібне щось низькорівневіше за Сі. Мода на прикладні програми з асемблерними вставками була в вісімдесяті, але нині, схоже, це вже неактуально.

14

Re: Для кожної задачі — свій інструмент

Lordie
Перечитайте перші п'ять речень першого посту іще раз.

Q-bart
Assambler - робота з залізом, та й то лише в тих місцях, де треба витиснути із цього заліза максимум.

P.Y.
Raspberry Pi - то майже повноцінний комп, десь на рівні четвертого пенька.

15

Re: Для кожної задачі — свій інструмент

Torbins, перечитав, з другої та навіть третьої спроби ближчими до реальності наведені в них твердження не стали. Я навів щонайменше декілька прикладів десктопного ПЗ на Java з мільйонами користувачів, на які, кхм, не лише можна, але й щодня дивляться без будь-яких сліз.

16

Re: Для кожної задачі — свій інструмент

Розробники NodeJS пішли стрілятись

До речі, а яку приблизно нішу займає в веб-розробці NodeJS — в яких випадках доцільно обирати саме його, а не більш поширені php чи asp.net?

17 Востаннє редагувалося raxp (09.10.2016 09:16:09)

Re: Для кожної задачі — свій інструмент

А як щодо пітона на Raspberry Pi? Знаю, що таке існує, бо бачив одну таку залізяку в дії. Наскільки поширена подібна практика?

чого тільки для малини не використовують http://raxp2.blogspot.com/2012/05/raspb … -faq.html, а якщо встановлен Win IoT, то фантазія не обмежена.

Принаймні у мене на домашньому компі таких немає жодної

з JAVA додатків у мене вдома Sweet Home 3D, та ще SDK, який ембаркадери підтягують )

Delphi - для тих хто не вважає себе програмістом, але пам'ятає паскаль з інституту, і час від часу має потребу швиденько щось збацати для власних потреб.

ось так одним махом з плеча рубати ))) У мене промислові додатки на ньому і не на ньому, бібліотеки, і не для власних потреб.

Assambler - робота з залізом,

не варто виділяти якийсь із натів окремо, ті ж драйвери в ОС і навіть під МК можна писати на Пуріке, прикладів безліч.

де треба витиснути із цього заліза максимум.

як би так й як би вже і нi. Сучасні компілятори оптимізують код, що на Сі, що на ASM майже однаково, а мороки з АСМом набагато більше в плані переносимості коду. ASM залiзякозалежен.

p.s.: до речi, якщо згадати історію самої Delphi, то взагалі замислювався для роботи з базами даних спочатку. Та й сам він лише відгалуження FP.

Подякували: leofun01, P.Y.2

18

Re: Для кожної задачі — свій інструмент

Сучасні компілятори оптимізують код

Це ми так думаємо. Хтось реально той оптимізований код перечитує?
Скажімо, в асемблері існує інструкція для циклічного зсуву. В Сі та інших мовах цього нема — доводиться розписувати циклічний зсув через два лінійні, напр. (a<<n)|(a>>32-n) — і ми не знаємо, здогадається компілятор зробити з цієї байди просту машинну інструкцію, чи так і залишить. Це ж стосується ділення-модуля однією інструкцією, і т.п. Об'єктивно, ми не знаємо, що́ в програмі компілятор оптимізує, а що́ ні.

Подякували: leofun01, 221VOLT2

19 Востаннє редагувалося ReAl (10.10.2016 10:00:02)

Re: Для кожної задачі — свій інструмент

P.Y. написав:

Хтось реально той оптимізований код перечитує?

Об'єктивно, ми не знаємо, що́ в програмі компілятор оптимізує, а що́ ні.

Я перечитую :-)
Об'єктивно не знаємо. Саме тому іноді варто перечитувати, щоб знати межі.

P.Y. написав:

Скажімо, в асемблері існує інструкція для циклічного зсуву. В Сі та інших мовах цього нема — доводиться розписувати циклічний зсув через два лінійні, напр. (a<<n)|(a>>32-n) — і ми не знаємо, здогадається компілятор зробити з цієї байди просту машинну інструкцію, чи так і залишить. Це ж стосується ділення-модуля однією інструкцією, і т.п.

Пристойний сучасний компілятор має зрозуміти.

gcc розуміє.
#include <stdint.h>

uint32_t foo1(uint32_t val, uint8_t n)
{
        return (val << n) | (val >> 32-n);
}

int a, b;

void moo(int c, int d)
{
        a = c / d;
        b = c % d;
}

x86

foo1:
        movzbl  8(%esp), %ecx
        movl    4(%esp), %eax
        roll    %cl, %eax
        ret

moo:
        movl    %edi, %eax
        cltd
        idivl   %esi
        movl    %eax, a(%rip)
        movl    %edx, b(%rip)
        ret

Cortex-M3 (відповідної команди ділення нема, тому залишок обчислюється множенням частки на дільник і відніманням від початкового числа командою mls)

foo1:
        rsb     r1, r1, #32
        rors    r0, r0, r1
        bx      lr

moo:
        sdiv    r3, r0, r1
        mls     r1, r1, r3, r0
        ldr     r2, .L2
        ldr     r0, .L2+4
        str     r3, [r2]
        str     r1, [r0]
        bx      lr

Навіть складніші речі компілятор виловлює. От дещо обчислюється у знаковому 32-бітному акумуляторі з фіксованою крапкою і запасом по розрядності в старші біти. Результат на ЦАП треба видати 12-бітний беззнаковий з насиченням з цілої частини акумулятора (тобто акумулятор може залетіти в мінус або більше 4095, це треба зсунути вправо і потім обмежити).
gcc ставить одну команду CM3 на всі ці дії. Спеціально дивився, бо там по часу тісно, то чи треба буде асм-вставки робити, чи ні.

Якось так
#include <stdint.h>

int32_t acc;
// Тут для демонстрації виділено в окрему функцію
// Реально це частина більшого коду і там взагалі одна команда,
// бо не треба виймати з пам'яті
uint16_t get_value()
{
        int32_t val = acc >> 18;
        if (val > 4095)
                val = 4095;
        else if (val < 0)
                val = 0;
        return val;
}

Єдине, що не зрозумів компілятор, це що після usat в r0 вже лише додатні 12-бітні і залишив команду uxth приведення int32_t до uint16_t (занулення старшої частини слова)

get_value:
        ldr     r3, .L2               ; Завантажили адресу акумулятора
        ldr     r0, [r3]              ; Завантажили значення акумулятора
        usat    r0, #12, r0, asr #18  ; Все тіло функції
        uxth    r0, r0                ; приведення int32 до uint16
        bx      lr

.L2:
        .word   acc

І от саме тому, що я вичитую, іноді я таки пишу на асемблері.
Хоча загалом ще з фідошних ех в усіх суперечках asm vs C стояв на тому, що треба писати на С — за виключенням тих випадків, коли ти точно знаєш, чому саме ти пишеш на асмі (за результатами прогонів та вивчення згенерованого коду).

Подякували: P.Y., leofun01, Torbins, 221VOLT4

20

Re: Для кожної задачі — свій інструмент

raxp
Не тільки у вас багато написаного коду на Delphi. Але нові проекти на ньому зараз майже не починають.