Що людей так приваблює в динамічних мовах? [зачинено]

Здається, останнім часом усі стрибають на динамічну, некомпільовану нарізку. Я переважно працював лише на скомпільованих мовах із статичним типом (C, Java, .Net). Я маю досвід роботи з динамічними мовами, наприклад, ASP (Vb Script), JavaScript та PHP. Використання цих технологій залишило неприємний смак у роті, коли я думав про динамічні мови. Речі, які зазвичай вловлював би компілятор, такі як неправильно написані імена змінних та присвоєння змінному значення неправильного типу, не відбуваються до часу виконання. І навіть тоді ви можете не помітити помилку, оскільки вона просто створює нову змінну та присвоює якесь значення за замовчуванням. Я також ніколи не бачив, щоб intellisense добре працював на динамічній мові, оскільки, ну, змінні не мають явного типу.

Я хочу знати, що людей цікавить динамічні мови? Які основні переваги з точки зору речей, які дозволяють вам робити динамічні мови, чого неможливо зробити або важко зробити в компільованих мовах. Мені здається, що ми давно вирішили, що такі речі, як нескладені asp-сторінки, що викидають винятки під час виконання, були поганою ідеєю. Чому коди такого типу відроджуються? І чому мені принаймні здається, що Ruby on Rails насправді не схожа на те, що ви не могли зробити з ASP 10 років тому?

Я думаю, причина в тому, що люди звикли до статично набраних мов, які мають дуже обмежені та невиразні системи типу. Це такі мови, як Java, C ++, Pascal і т. Д. Замість того, щоб рухатись у напрямку до більш виразних систем типу та кращого виведення типу (як, наприклад, у Haskell, і навіть SQL до певної міри), деякі люди люблять просто тримати всю інформацію про "тип" у своїй голові (і в тестах) і взагалі покінчити зі статичною перевіркою типу.

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

Помилка: динамічні мови менш багатослівні. Помилка полягає в тому, що інформація про тип дорівнює анотації типу. Це абсолютно неправда. Ми всі знаємо, що анотація типу дратує. Машина повинна мати змогу зрозуміти це. І насправді це відбувається в сучасних компіляторах. Ось статично набраний QuickSort у двох рядках Haskell (з haskell.org ):

qsort []     = []
qsort (x:xs) = qsort (filter (< x) xs) ++ [x] ++ qsort (filter (>= x) xs)

А ось динамічно набраний QuickSort у LISP (від swisspig.net ):

(defun quicksort (lis) (if (null lis) nil
  (let* ((x (car lis)) (r (cdr lis)) (fn (lambda (a) (< a x))))
    (append (quicksort (remove-if-not fn r)) (list x)
      (quicksort (remove-if fn r))))))

Приклад Хаскелла фальсифікує статично набрану, отже, багатослівну гіпотезу . Приклад LISP фальсифікує багатослівність гіпотези , тому статично набрана . Немає ніяких наслідків в обох напрямках між набором тексту та багатослівністю. Ви можете сміливо викидати це з розуму.

Помилка: мови, що набираються із статичним набором, слід компілювати, а не інтерпретувати. Знову ж таки, неправда. Багато мов із статичним типом мають перекладачів. Існує інтерпретатор Scala, інтерпретатори GHCi та Hugs для Haskell, і, звичайно, SQL як статично набирається, так і інтерпретується довше, ніж я був у живих.

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

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

Не забувайте, що вам потрібно написати 10x покриття коду в модульних тестах, щоб замінити те, що робить ваш компілятор: D

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

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

1) Код менш багатослівний. Я не вважаю це дійсним. Деякі динамічні мови менш багатослівні, ніж деякі статичні. Але F # набирається статично, але статичне введення там не додає багато, якщо таке є, коду. Хоча це неявно набирається, але це зовсім інша річ.

2) "Моя улюблена динамічна мова X має мою улюблену функціональну функцію Y, тому динамічна краще". Не змішуйте функціональне та динамічне (я не можу зрозуміти, чому це потрібно сказати).

3) На динамічних мовах ви можете негайно побачити свої результати. Новини: Ви можете зробити це за допомогою C # у Visual Studio (з 2005 року) теж. Просто встановіть точку зупинки, запустіть програму в налагоджувачі та модифікуйте програму під час налагодження. Я роблю це постійно, і це чудово працює.

Я сам рішуче прихильник статичного набору тексту з однієї головної причини: ремонтопридатність. У мене є система з парою 10 тисяч рядків JavaScript, і будь-яка інша рефакторинг, який я хочу зробити, займе півдня, оскільки (неіснуючий) компілятор не скаже мені, що ця змінна перейменовувала. І це код, який я написав сам, також добре структурований IMO. Я б не хотів, щоб завдання було керувати еквівалентною динамічною системою, яку написав хтось інший.

Думаю, за це мене масово прихилять, але я ризикну.

VBScript відстій, якщо ви не порівнюєте його з іншим смаком VB. PHP - це нормально, якщо ви пам’ятаєте, що це обросла мова шаблонів. Сучасний Javascript чудовий. Дійсно. Тонни веселощів. Просто тримайтеся подалі від будь-яких сценаріїв із тегом "DHTML".

Я ніколи не користувався мовою, яка не допускала помилок виконання. ІМХО, це в основному червоний оселедець: компілятори не вловлюють всіх помилок і не перевіряють наміри. Явне введення тексту - це чудово, коли вам потрібні явні типи, але частіше за все цього немає. Шукайте запитання тут genericsабо тему про те, чи було використання неподписаних типів хорошим вибором для змінних індексу - більшу частину часу цей матеріал просто заважає і дає людям можливість крутити, коли у них є час .

Але, я насправді не відповів на ваше запитання. Чому динамічні мови привабливі? Оскільки через деякий час написання коду стає нудним, і ви просто хочете реалізувати алгоритм. Ви вже сиділи і все це опрацьовували, складали схеми потенційних проблемних сценаріїв і довели їх розв'язуваність, і єдине, що залишилось зробити, це закодувати двадцять рядків реалізації ... і двісті рядків зразкового тексту, щоб він скомпілювався . Потім ти розумієш, що система типів, з якою ти працюєш, відображає не те, що ти насправді робиш, а чужу надзвичайно абстрактну ідею того, чим ти можеш займатися, і ти вже давно відмовився від програмування на все життя, щоб налаштувати нарікання так нав’язливо-компульсивний, що це буде ганьбою навіть вигаданого детектива Адріана Монка.

Ось тоді ви починаєте гіпсувати, починаючи серйозно дивитись на динамічні мови.

Я штатний програміст .Net, який повністю закріпився за статичним типом C #. Однак я люблю сучасний JavaScript.

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

Я думаю, що є також кілька класів динамічних мов. У мене немає бажання повертатися до написання класичних сторінок ASP у VBScript. Для того, щоб бути корисним, я думаю, що динамічна мова повинна підтримувати якусь колекцію, список чи асоціативну конструкцію в своїй основі, щоб об'єкти (або те, що передається об'єктам) могли бути виражені та дозволяти вам будувати більш складні конструкції. (Можливо, нам усім слід просто кодувати в LISP ... це жарт ...)

Я думаю, що в колах .Net динамічні мови отримують поганий реп, оскільки вони пов'язані з VBScript та / або JavaScript. VBScript просто згадується як страшний сон з багатьох причин, за якими заявила Кібі - хтось пам'ятає, як застосовувати тип у VBScript за допомогою CLng, щоб переконатися, що у вас є достатньо бітів для 32-бітового цілого числа. Крім того, я думаю, що JavaScript все ще розглядається як мова браузера для випадаючих меню, яка написана по-різному для всіх браузерів. У цьому випадку проблема полягає не в мові, а в різних об’єктних моделях браузера. Що цікаво, чим більше дозріває C #, тим динамічніше він починає виглядати. Я люблю лямбда-вирази, анонімні об'єкти та умовивід типу. Це більше схоже на JavaScript щодня.

Ось статично набраний QuickSort у двох рядках Haskell (з haskell.org):

qsort []     = []
qsort (x:xs) = qsort (filter (< x) xs) ++ [x] ++ qsort (filter (>= x) xs)

А ось динамічно набраний QuickSort у LISP (від swisspig.net):

(defun quicksort (lis) (if (null lis) nil
  (let* ((x (car lis)) (r (cdr lis)) (fn (lambda (a) (< a x))))
    (append (quicksort (remove-if-not fn r)) (list x)
      (quicksort (remove-if fn r))))))

Думаю, ви тут упереджуєте вибір мови. Лисп, як відомо, важкий для батьків. Більш близьким до Хаскелла буде Пітон.

if len(L) <= 1: return L
return qsort([lt for lt in L[1:] if lt < L[0]]) + [L[0]] + qsort([ge for ge in L[1:] if ge >= L[0]])

Код Python звідси

Для мене перевага динамічних мов у тому, наскільки читабельнішим стає код завдяки меншій кількості коду та функціональних прийомів, таких як блок Ruby та розуміння списку Python.

Але тоді я начебто пропускаю перевірку часу компіляції (друкарська помилка трапляється) та автоматичне завершення IDE. Загалом менша кількість коду та читабельність для мене окупаються.

Ще однією перевагою є зазвичай інтерпретована / некомпільована природа мови. Змініть код і негайно перегляньте результат. Це справді економить час під час розробки.

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

Ваші аргументи проти динамічних мов цілком слушні. Однак враховуйте наступне:

1. Динамічні мови не потрібно компілювати : просто запустіть їх. Ви навіть можете перезавантажити файли під час роботи, не перезавантажуючи програму в більшості випадків.
2. Динамічні мови, як правило, менш багатослівні та читабельніші : ви коли-небудь переглядали даний алгоритм або програму, реалізовану в статичній мові, а потім порівнювали його з еквівалентом Ruby або Python? Загалом, ви дивитесь на зменшення рядків коду в 3 рази. Багато коду лісів не потрібні в динамічних мовах, а це означає, що кінцевий результат є більш читабельним і більш зосередженим на актуальній проблемі.
3. Не турбуйтеся про проблеми з набором тексту : загальний підхід при програмуванні на динамічних мовах - це не турбуватися про введення тексту: більшість випадків правильний аргумент передається вашим методам. І час від часу хтось може використовувати різні аргументи, які просто теж спрацьовують. Коли щось піде не так, ваша програма може бути зупинена, але це рідко трапляється, якщо ви зробили кілька тестів.

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

Я вважаю, що "нова знайдена любов" до мов з динамічним типом має менше спільного з тим, чи є статично набрані мови кращими чи гіршими - в абсолютному сенсі - ніж зростання популярності певних динамічних мов. Рубін на рейках, очевидно, був великим явищем, яке спричинило відродження динамічних мов. Те, що зробило рейки настільки популярними і створило стільки перетворювачів із статичного табору, було головним чином: дуже стислий та сухий код та конфігурація. Це особливо вірно у порівнянні з веб-фреймворками Java, які вимагали конфігурації XML. Багато програмістів Java - розумних - теж перетворюються, а деякі навіть євангелізують рубін та інші динамічні мови. Для мене три різні функції дозволяють динамічним мовам, таким як Ruby або Python, бути більш стислими:

1. Мінімалістичний синтаксис - головним є те, що анотації типів не потрібні, але також дизайнер мови розробив мову з самого початку стислою
2. синтаксис вбудованої функції (або лямбда) - можливість писати вбудовані функції та передавати їх як змінні робить багато видів коду більш короткими. Зокрема, це справедливо для операцій зі списком / масивом. Коріння цієї ідеї, очевидно, було - LISP.
3. Метапрограмування - метапрограмування є великою частиною того, що змушує рейки галочкувати. Це породило новий спосіб рефакторингу коду, який дозволив клієнтському коду вашої бібліотеки бути набагато коротшим. Це також походить від LISP.

Усі ці три функції не є ексклюзивними для динамічних мов, але вони, безумовно, відсутні в популярних сьогодні статичних мовах: Java та C #. Ви можете стверджувати, що C # має номер 2 у делегатів, але я міг би стверджувати, що він взагалі не використовується широко - наприклад, з операціями зі списком.

Що стосується більш вдосконалених статичних мов ... Haskell - чудова мова, у неї є №1 та №2, і хоча у неї немає №3, система типів настільки гнучка, що ви, мабуть, не знайдете браку мета бути обмежувальним. Я вважаю, що ви можете робити метапрограмування в OCaml під час компіляції з мовним розширенням. Scala - нещодавно додане і дуже перспективне. F # для табору .NET. Але користувачів цих мов меншість, і тому вони насправді не сприяли цій зміні в середовищі мов програмування. Насправді, я дуже впевнений, що популярність Ruby вплинула на популярність таких мов, як Haskell, OCaml, Scala та F #, на додаток до інших динамічних мов.

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

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

Зайве говорити, що я продуктивніший у будь-якій з цих мов, ніж PHP. До біса, я волів би кодувати в Scheme або Prolog, ніж в PHP. (Але останнім часом я насправді роблю більше Prolog, ніж будь-що інше, тож сприйміть це з достатком солі!)

Моя оцінка динамічних мов дуже пов’язана з тим, наскільки функціональними вони. Розуміння списку Python, закриття Ruby та прототипізовані об’єкти JavaScript - все це дуже привабливі аспекти цих мов. Всі вони також мають першокласні функції - те, без чого я не бачу життя.

Я б не класифікував PHP та VB (сценарій) однаково. Для мене це переважно імперативні мови з усіма недоліками динамічного набору тексту, які ви пропонуєте.

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

Однією з переваг, на яку вказують динамічні мови, є можливість просто змінити код і продовжувати працювати. Не потрібно перекомпілювати. У VS.Net 2008 під час налагодження ви можете фактично змінити код і продовжувати працювати без перекомпіляції. Чи можливий зникнення цієї та інших переваг використання динамічних мов завдяки досягненню компіляторів та IDE.

Ах, я не бачив цієї теми, коли публікував подібне запитання

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

Програмування програми.

Це досить складно зробити в компільованих мовах, загалом, візьмемо для прикладу .Net. Для того, щоб це працювало, вам потрібно зробити всі види mambo jumbo, і зазвичай це закінчується кодом, який працює приблизно в 100 разів повільніше.

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

Наприклад, щоб створити калькулятор в Lua, все, що мені потрібно зробити, це:

print( loadstring( "return " .. io.read() )() )

Тепер спробуйте зробити це в .Net.

Моя основна причина вподобання динамічних (набраних, оскільки це, здається, фокус потоку) мов полягає в тому, що ті, якими я користувався (у робочому середовищі), значно перевершували нединамічні мови, якими я користувався. C, C ++, Java тощо ... це всі жахливі мови для реальної роботи. Я хотів би бачити неявно набрану мову, яку так само природно програмувати на стільки динамічно набраних.

З огляду на це, є певні конструкції, які просто вражають динамічно набраними мовами. Наприклад, у Tcl

 lindex $mylist end-2

Той факт, що ви передаєте "кінець-2", щоб вказати потрібний індекс, неймовірно стислий і очевидний для читача. Я ще не бачив статично набраної мови, яка робить це.

Я думаю, що такий аргумент є дещо дурним: "Речі, які зазвичай потрапляли б до компілятора, такі як неправильно написані імена змінних та присвоєння змінному значення неправильного типу, не відбуваються до часу виконання" так, це правильно, як PHP-розробник Я не бачу таких речей, як помилково введені змінні до часу виконання, АЛЕ час виконання - це крок 2 для мене, в C ++ (це єдина компільована мова, у якої я маю досвід) це крок 3, після зв’язування та компіляції.

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

Аргумент є більш складним, ніж цей (прочитайте статтю Єгге "Чи слабкий друк досить сильний" для цікавого огляду набір ).

У динамічних мовах також не обов’язково бракує перевірки помилок - висновок типу C #, можливо, є одним із прикладів. Таким же чином, C і C ++ мають жахливі перевірки компіляції, і вони набираються статично.

Основними перевагами динамічних мов є: а) здатність (яку не обов’язково постійно використовувати) та б) закон Бойда про ітерацію .

Остання причина є масовою.

Хоча я ще не є великим шанувальником Ruby, я вважаю динамічні мови справді чудовими та потужними інструментами.

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

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

Хороші IDE дадуть достатньо intellisense, щоб ви знали, чи змінна була "оголошена", і вони також намагаються зробити для вас умовивід для певного типу, щоб ви могли визначити, що таке змінна.

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

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

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

• яка змінна має який тип
• як динамічно вирощувати рядок, як потрібно
• як написати код, щоб, якщо я змінив тип однієї змінної, мені не довелося переписувати всі функції, які з нею взаємодіють

до проблем, які ближче до потреб бізнесу, наприклад

• дані зберігаються / оновлюються тощо в базі даних, як я використовую їх для залучення трафіку на мій сайт

У будь-якому випадку, одна перевага вільно набраних мов полягає в тому, що нас насправді не хвилює, який це тип, якщо він поводиться так, як передбачається. Саме тому ми набираємо качок на динамічно набраних мовах. це відмінна функція, і я можу використовувати однакові імена змінних для зберігання різних типів даних у міру потреби. також, статично набрані мови змушують вас мислити як машина (як компілятор взаємодіє з вашим кодом тощо), тоді як динамічно набрані мови, особливо ruby ​​/ ror, змушують машину мислити як людина.

Ось деякі аргументи, якими я обґрунтовую свою роботу та досвід роботи з динамічними мовами!

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

Щоб бути циніком, може бути, що просто динамічні мови дозволяють розробнику бути більш ледачим і робити все, щоб знати менше про основи обчислень. Чи це добре, чи погано - вирішує читач :)

FWIW, Компіляція більшості додатків не повинна тривати годинами. Я працював із програмами розміром від 200 до 500 тис. Рядків, на компіляцію яких потрібні хвилини. Звичайно, не години.

Я віддаю перевагу компільованим мовам сам. Я відчуваю, ніби інструменти налагодження (з мого досвіду, що може бути не так для всіх) кращі, а інструменти IDE кращі.

Мені подобається можливість приєднати Visual Studio до запущеного процесу. Чи можуть інші IDE це робити? Можливо, але я не знаю про них. Останнім часом я займаюся розробкою PHP, і чесно кажучи, це не все так погано. Однак я набагато віддаю перевагу C # та VS IDE. Я відчуваю, що працюю швидше і швидше налагоджую проблеми.

То, можливо, це для мене більше набору інструментів, ніж проблема динамічної / статичної мови?

Останній коментар ... якщо ви розробляєте за допомогою локального сервера, збереження відбувається швидше, ніж компіляція, але часто у мене немає доступу до всього на моєму локальному комп'ютері. Бази даних та файлообмінники живуть деінде. Простіше FTP перейти на веб-сервер, а потім запустити мій PHP-код лише для того, щоб знайти помилку, а також виправити та повторно встановити ftp.

Продуктивність у певному контексті. Але це лише одне середовище, яке я знаю, порівняно з деякими іншими, які я знаю чи бачив, що використовуються.

Smalltalk on Squeak / Pharo with Seaside - набагато ефективніша та ефективніша веб-платформа, ніж ASP.Net (/ MVC), RoR або Wicket, для складних додатків. Поки вам не потрібно буде взаємодіяти з чимось, що має бібліотеки в одній із цих, але не малих розмов.

Неправильно написані імена змінних червоні в IDE, IntelliSense працює, але не настільки конкретно. Помилки під час роботи на веб-сторінках - це не проблема, а особливість, один клік, щоб викликати налагоджувач, один клік до моєї IDE, виправити помилку в налагоджувачі, зберегти, продовжити. Для простих помилок час туди-назад для цього циклу становить менше 20 секунд.

Динамічні мови завдають удару у відповідь

http://www.youtube.com/watch?v=tz-Bb-D6teE

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

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

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

Крім того, мені набридло писати такі речі, як MyFancyObjectInterface f = new MyFancyObject (). СУХИЙ принцип хто-небудь?

Поставте себе на місце абсолютно нового програміста, який вибирає мову для початку, якому не байдужа динаміка проти стаїчного проти лямбда проти цього проти цього тощо; яку мову ВИ б обрали?

C #

using System;
class MyProgram
{
    public static void Main(string[] args)
    {
        foreach (string s in args)
        {
            Console.WriteLine(s);
        }
    }
}

Луа:

function printStuff(args)
    for key,value in pairs(args) do
       print value .. " "
    end
end
strings = {
    "hello",
    "world",
    "from lua"
}
printStuff(strings)

Все це зводиться частково до того, що підходить для конкретних цілей і що є загальним особистим уподобанням. (Е.Г. Це буде величезна база кодів, яку підтримує більша кількість людей, ніж може провести розумну зустріч разом? Ви хочете перевірити тип.)

Особиста частина стосується торгівлі деякими чеками та іншими кроками для розробки та тестування швидкості (при цьому, ймовірно, відмова від деякої продуктивності процесора). Є деякі люди, для яких це звільнення та підвищення продуктивності, а є деякі, для кого це зовсім протилежне, і так, це певним чином залежить від конкретного смаку вашої мови. Я маю на увазі, що ніхто тут не каже, що Java скелюється за швидкий, стислий розвиток, або що PHP - це тверда мова, де ви рідко будете робити важко помітну друкарську помилку.

Я люблю як статичні, так і динамічні мови. Кожен проект, яким я займався приблизно з 2002 року, був додатком C / C ++ із вбудованим інтерпретатором Python. Це дає мені найкраще з обох світів:

1. Компоненти та фреймворки, що складають додаток, для даного випуску програми є незмінними. Вони також повинні бути дуже стабільними, а отже, добре перевіреними. Статично набрана мова - правильний вибір для побудови цих частин.
2. Підключення компонентів, завантаження компонентних бібліотек DLL, ілюстрацій, більшої частини графічного інтерфейсу тощо ... може сильно відрізнятися (скажімо, для налаштування програми для клієнта) без необхідності змінювати будь-який фреймворк або код компонентів. Для цього ідеально підходить динамічна мова.

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

Відповісти на питання "Що з любов’ю до динамічних мов?" Для мене це здатність повністю перепроводити систему під час виконання будь-яким можливим способом. Я розглядаю мову сценаріїв як "запуск шоу", тому виконувана програма може робити все, що завгодно.

Я взагалі не маю великого досвіду роботи з динамічними мовами, але одну динамічну мову, яку я знаю, JavaScript (вона ж ECMAScript), я дуже люблю.

Ну, почекайте, яка тут дискусія? Динамічна компіляція? Або динамічний набір тексту? JavaScript охоплює обидві бази, тому, мабуть, я поговорю про обидві:

Динамічна компіляція :

Для початку, мови динамічні є скомпільовані, компіляція не просто відкладати на потім. А Java і .NET дійсно компілюються двічі. Одного разу до відповідних проміжних мов, і знову, динамічно, до машинного коду.

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

Ще однією перевагою є те, що ви можете писати та компілювати код під час виконання . Чи можливо це в статично скомпільованому коді, я не знаю. Я думаю, це повинно бути, оскільки все, що компілює JavaScript, в кінцевому підсумку є машинним кодом і статично компілюється. Але в динамічній мові це тривіальна справа. Код може писати і запускати сам. (І я майже впевнений, що .NET може це зробити, але CIL, до якого .NET компілюється, так чи інакше динамічно компілюється, і це не так тривіально в C #)

Динамічний набір тексту :

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

var Person = {};

Чи знаєте ви, що таке Людина зараз? Це загальний словник. Я можу зробити це:

Person ["First_Name"] = "Джон";
Person ["Last_Name"] = "Сміт";

Але це ще й об’єкт. Я міг би звернутися до будь-якого з цих "ключів" таким чином:

Person.First_Name

І додайте будь-які методи, які я вважаю необхідними:

Person.changeFirstName = функція (newName) {
  this.First_Name = newName;
};

Звичайно, можуть виникнути проблеми, якщо newName не є рядком. Його не зловлять відразу, якщо взагалі коли-небудь, але ви можете перевірити себе. Це питання торгівлі виразною силою та гнучкістю задля безпеки. Я не проти додати код для перевірки типів і т. Д., І я ще не зіткнувся з помилкою типу, яка завдала мені великого горя (і я знаю, що це не говорить багато. Це може бути питанням часу: )). Однак мені дуже подобається така здатність адаптуватися на льоту.

Гарний допис у блозі на ту саму тему: Python робить мене нервовим

Підписи методів практично не потрібні в Python. У Java статичне введення робить підпис методу рецептом: це все лайно, яке потрібно, щоб цей метод працював. У Python не так. Тут підпис методу скаже вам лише одне: скільки аргументів потрібно, щоб він працював. Іноді це навіть не зробить, якщо ти почнеш трахатися з ** кваргами.

Тому що це весело весело весело. Приємно не турбуватися про розподіл пам’яті, наприклад. Цікаво не чекати компіляції. тощо тощо тощо

Слабо набрані мови дозволяють гнучко керувати даними.

Я використовував VHDL минулої весни для кількох класів, і мені подобається їх метод представлення бітів / байтів, і те, як компілятор ловить помилки, якщо ви намагаєтеся призначити 6-бітову шину 9-бітовій шині. Я спробував відтворити його в C ++, і я чесно намагаюся акуратно змусити друк працювати безперебійно з існуючими типами. На мою думку, Стів Єгге дуже добре описує проблеми, пов’язані з сильними системами типу.

Щодо багатослівності: Я вважаю, що Java та C # є досить багатослівними у великому плані (давайте не будемо вибирати маленькі алгоритми, щоб "довести" думку). І так, я писав в обох. С ++ також бореться з тією ж сферою; VHDL тут піддається.

Здавалося б, парсум є доброчесністю динамічних мов загалом (я наводжу Perl та F # як приклади).