Чи є реальна перевага динамічних мов? [зачинено]

_{По-перше, я хочу сказати, що Java є єдиною мовою, яку я коли-небудь використовував, тому, будь ласка, вибачте моє незнання з цього приводу.}

Динамічно набрані мови дозволяють вводити будь-яке значення в будь-яку змінну. Так, наприклад, ви можете написати таку функцію (psuedocode):

void makeItBark(dog){
    dog.bark();
}

І ви можете передавати всередині нього будь-яку цінність. Поки значення має bark()метод, код буде працювати. Інакше викидається виняток із виконання або щось подібне. _{(Будь ласка, виправте мене, якщо я помиляюся з цього приводу).}

Здається, це дає вам гнучкість.

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

Так, наприклад, коли ви пишете makeItBark()функцію, ви маєте намір приймати лише ті речі, які можуть гавкати, і вам все одно потрібно переконатися, що ви передаєте їй лише такі речі. Єдина відмінність полягає в тому, що зараз компілятор не скаже вам, коли ви помилилися.

Звичайно, є одна перевага цього підходу, яка полягає в тому, що для статичних мов, щоб досягти "ця функція приймає все, що може гавкати", вам потрібно буде застосувати явний Barkerінтерфейс. Все-таки це здається незначною перевагою.

Я щось пропускаю? Що я насправді здобуваю, використовуючи динамічно набрану мову?

Мови, що динамічно вводяться, є однотипними

Порівнюючи системи типів , немає переваги в динамічному наборі тексту. Динамічне введення тексту є особливим випадком статичного набору тексту - це статично типова мова, де кожна змінна має один і той же тип. Те ж саме можна досягти і в Java (мінус стислість), зробивши кожну змінну типу Object, а типи "об'єктних" значень типу Map<String, Object>:

void makeItBark(Object dog) {
    Map<String, Object> dogMap = (Map<String, Object>) dog;
    Runnable bark = (Runnable) dogMap.get("bark");
    bark.run();
}

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

Складання кори качки мовою статичного типу

Крім того, хороша статична мова дозволить вам написати код, який працює з будь-яким типом, який має barkоперацію. У Haskell це клас типу:

class Barkable a where
    bark :: a -> unit

Це виражає обмеження, що для певного типу, aякий вважається Баркабельним, повинна існувати barkфункція, яка приймає значення цього типу і нічого не повертає.

Потім можна записати загальні функції з точки зору Barkableобмеження:

makeItBark :: Barkable a => a -> unit
makeItBark barker = bark (barker)

Це говорить про те, що makeItBarkбуде працювати для будь-якого типу, що відповідає Barkableвимогам. Це може здатися схожим на interfaceJava або C #, але це має одну велику перевагу - типи не повинні вказувати наперед, для яких типів класів вони задовольняються. Я можу сказати, що тип Duckє Barkableв будь-який час, навіть якщо Duckце сторонній тип, який я не писав. Насправді, неважливо, що автор Duckне написав barkфункції - я можу надати її після факту, коли я розмовляю мовою, яка Duckзадовольняє Barkable:

instance Barkable Duck where
    bark d = quack (punch (d))

makeItBark (aDuck)

Це говорить про те, що Ducks може брахати, а їх кора функція реалізується шляхом штампування качки перед тим, як зробити її кряканням. Якщо це не виходить, ми можемо закликати makeItBarkкачок.

Standard MLі OCamlще більш гнучкими в тому, що ви можете задовольнити один і той же тип класу більш ніж одним способом. Цими мовами я можу сказати, що цілі числа можна замовити за допомогою звичайного впорядкування, а потім розвернутися і сказати, що вони також можуть бути впорядковані на поділ (наприклад, 10 > 5тому що 10 ділиться на 5). У Haskell ви можете інстанціювати тип типу лише один раз. (Це дозволяє Haskell автоматично знати, що нормально дзвонити barkна качку; в SML або OCaml ви повинні мати чітку інформацію про те, яку bark функцію ви хочете, оскільки їх може бути більше.)

Лаконічність

Звичайно, є синтаксичні відмінності. Представлений вами код Python набагато більш стислий, ніж аналог, який я написав. На практиці ця стислість є важливою частиною привабливості динамічно набраних мов. Але висновок типу дозволяє писати код, який настільки ж стислий на мовах статичного типу, позбавляючи вас від необхідності чітко писати типи кожної змінної. Статично введена мова також може забезпечити нативну підтримку динамічного набору тексту, видаляючи багатослівність усіх маніпуляцій із литтям та картою (наприклад, C # 's dynamic).

Правильні, але неправильно набрані програми

Якщо чесно, статичне введення обов'язково виключає деякі технічно правильні програми, навіть якщо перевіряючий тип не може його перевірити. Наприклад:

if this_variable_is_always_true:
    return "some string"
else:
    return 6

Більшість мов, які мають статичний тип, відхилять це ifтвердження, навіть якщо інша гілка ніколи не зустрінеться. На практиці, здається, ніхто не використовує цей тип коду - все, що занадто розумно для перевірки типів, ймовірно, змусить майбутніх утримувачів вашого коду проклинати вас і ваших близьких. Насправді, хтось успішно перевів 4 проекти з відкритим кодом Python на Haskell, а це означає, що вони не робили нічого, що не могло б скласти гарна статична мова. Більше того, компілятор знайшов пару помилок, пов’язаних з типом, які одиничні тести не знайшли.

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

Яблука та апельсини

Нарешті, не забувайте, що в мовах є великі розбіжності, ніж просто їх тип типів. До Java 8 виконання будь- якого функціонального програмування на Java було практично неможливим; для простої лямбда потрібні 4 рядки анонімного коду класу. Java також не має підтримки для літератур колекції (наприклад [1, 2, 3]). Також можуть бути різниці у якості та доступності інструментарію (IDE, налагоджувачі), бібліотек та підтримки громади. Коли хтось стверджував, що в Python або Ruby більш продуктивним, ніж на Java, це врахування нерівності потрібно враховувати. Існує різниця між порівнянням мов із усіма батареями , мовними ядрами та типами систем .

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

Ось мій погляд на це: Суть мов високого рівня полягає в обмеженні того, що програміст може зробити з комп'ютером. Це дивує багатьох людей, оскільки вони вважають, що мета - надати користувачам більше влади та досягти більше . Але оскільки все, що ви пишете в Prolog, C ++ або List, врешті-решт виконується як машинний код, фактично неможливо дати програмісту більше енергії, ніж мова монтажу вже передбачена.

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

Ось де різниться сприйняття людей. Деякі люди (я серед них) вважають, що поки ваша програма перевірки пароля в будь-якому випадку очікує рівно два аргументи, і завжди рядок, що супроводжується числовим ідентифікатором, корисно оголосити це в коді та автоматично нагадати, якщо пізніше ви забудете дотримуватися цього правила. Аутсорсинг такого невеликого обліку книг для компілятора допомагає звільнити розум від проблем вищого рівня та робить вас кращими в розробці та архітектурі вашої системи. Тому типові системи - це чистий виграш: вони дозволяють комп'ютеру робити те, що в ньому добре, а люди роблять те, у чому вони хороші.

Інші бачать зовсім інакше. Їм не подобається, коли компілятор сказав, що робити. Вони не люблять додаткових зусиль, щоб визначитися з типом декларації та набрати її. Вони віддають перевагу дослідницькому стилю програмування, у якому ви пишете фактичний бізнес-код, не маючи плану, який би точно розказував, які типи та аргументи використовувати де. А для стилю програмування, який вони використовують, це може бути цілком правдивим.

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

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

Код, написаний з використанням динамічних мов, не пов'язаний із системою статичного типу. Тому ця відсутність з'єднання є перевагою порівняно з поганими / неадекватними системами статичного типу (хоча це може бути помилкою або недоліком порівняно з чудовою системою статичного типу).

Крім того, для динамічної мови систему статичного типу не потрібно проектувати, впроваджувати, тестувати та підтримувати. Це може спростити реалізацію порівняно з мовою зі системою статичного типу.