Что привлекает людей в динамических языках?

Я думаю, причина в том, что люди привыкли к языкам со статической типизацией, которые имеют очень ограниченные и невыразительные системы типов. Это такие языки, как 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))))))

Пример Haskell опровергает гипотезу, статически типизированной, поэтому многословной. Пример LISP опровергает гипотезу, подробный, поэтому статически типизированный. Нет никакого смысла ни в одном направлении между набором текста и многословием. Вы можете смело выбросить это из головы.

Заблуждение: языки со статической типизацией должны компилироваться, а не интерпретироваться. Опять же, это неправда. Многие статически типизированные языки имеют интерпретаторы. Есть интерпретатор Scala, интерпретаторы GHCi и Hugs для Haskell, и, конечно же, SQL был статически типизирован и интерпретирован дольше, чем я жил.

Вы знаете, может быть, динамичная толпа просто хочет свободы, чтобы не думать так тщательно о том, что они делают. Программное обеспечение может быть некорректным или надежным, но, возможно, это не обязательно.

Лично я считаю, что те, кто отказался бы от безопасности типов, чтобы купить небольшую временную свободу, не заслуживают ни свободы, ни безопасности типов.

Не забывайте, что вам нужно написать 10-кратное покрытие кода в модульных тестах, чтобы заменить то, что делает ваш компилятор: D

Я был там, делал это с динамическими языками, и я не вижу абсолютно никаких преимуществ.

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

1) Код менее подробный. Я не считаю это верным. Некоторые динамические языки менее подробны, чем некоторые статические. Но F # имеет статическую типизацию, но статическая типизация там не добавляет большого количества кода, если таковой имеется. Хотя он неявно типизирован, но это другое дело.

2) «Мой любимый динамический язык X имеет мою любимую функциональную возможность Y, поэтому динамический лучше». Не путайте функциональное и динамическое (не понимаю, почему это нужно говорить).

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

Лично я убежденный сторонник статической типизации по одной основной причине: ремонтопригодность. У меня есть система с парой 10 тыс. Строк JavaScript, и любой рефакторинг, который я хочу провести, займет примерно полдня, поскольку (несуществующий) компилятор не скажет мне, что это за переименование переменной облажался. И этот код я написал сам, ИМО тоже хорошо структурирован. Я бы не хотел, чтобы меня возложили на эквивалентную динамическую систему, написанную кем-то другим.

Думаю, за это меня будут сильно отвергать, но я рискну.

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))))))

Я думаю, что вы предвзято относитесь к выбору языка. Lisp, как известно, перегружен пареном. Более близким эквивалентом Haskell был бы Python.

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. Не беспокойтесь о проблемах с набором текста: общий подход при программировании на динамических языках заключается в том, чтобы не беспокоиться о наборе текста: в большинстве случаев вашим методам будет передаваться правильный тип аргумента. И время от времени кто-то может использовать аргументы другого типа, которые тоже могут сработать. Когда что-то пойдет не так, ваша программа может быть остановлена, но это редко случается, если вы выполнили несколько тестов.

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

Я считаю, что «новая любовь» к языкам с динамической типизацией связана не столько с тем, являются ли языки со статической типизацией лучше или хуже - в абсолютном смысле, - чем с ростом популярности определенных динамических языков. . Ruby on Rails, очевидно, был большим явлением, которое привело к возрождению динамических языков. То, что сделало rails настолько популярным и привело к такому количеству преобразований из статического лагеря, было главным образом: очень кратким и СУХИМ кодом и конфигурацией. Это особенно верно по сравнению с веб-фреймворками Java, которым требовалось множество конфигураций XML. Многие Java-программисты - в том числе и умные - преобразовали, а некоторые даже проповедовали Ruby и другие динамические языки. На мой взгляд, три различные функции позволяют сделать динамические языки, такие как 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 это и другие преимущества использования динамических языков исчезнут.

Ах, я не видел эту тему, когда отправлял аналогичный вопрос

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

Моя основная причина, по которой мне нравятся динамические (типизированные, поскольку это, кажется, фокус потока) языки, заключается в том, что те, которые я использовал (в рабочей среде), намного превосходят нединамические языки, которые я использовал. C, C ++, Java и т. Д. - все они ужасные языки для выполнения реальной работы. Мне бы хотелось увидеть язык с неявной типизацией, который так же естественен для программирования, на таком же большом количестве языков с динамической типизацией.

При этом есть определенные конструкции, которые просто великолепны в динамически типизированных языках. Например, в Tcl

 lindex $mylist end-2

Тот факт, что вы передаете "end-2", чтобы указать нужный вам индекс, невероятно краток и очевиден для читателя. Я еще не видел статически типизированного языка, который бы это делал.

Я думаю, что такой аргумент немного глуп: «То, что обычно было бы обнаружено компилятором, например, неправильное написание имен переменных и присвоение переменной значения неправильного типа, не происходит до тех пор, пока не выполняется время выполнения» да, это правильно, как PHP-разработчик. Я не вижу таких вещей, как неверно введенные переменные, до времени выполнения, НО время выполнения для меня - это шаг 2, в C ++ (который является единственным скомпилированным языком, который у меня есть) это шаг 3 после связывания и компиляции.

Не говоря уже о том, что это занимает всего несколько секунд после того, как я нажму "Сохранить". до того момента, когда мой код будет готов к запуску, в отличие от компилируемых языков, где это может занять буквально часы. Прошу прощения, если это звучит немного сердито, но я устал от людей, относящихся ко мне как к второсортному программисту, потому что мне не нужно компилировать свой код.

Аргумент более сложный, чем этот (прочтите статью Ягге «Слабое печатание - сильное Достаточно " для интересного обзора).

В динамических языках не обязательно отсутствует проверка ошибок - возможно, одним из примеров является вывод типа 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 на Squeak / Pharo с Seaside - гораздо более эффективная и действенная веб-платформа, чем ASP.Net (/ MVC), RoR или Wicket, для сложных приложений. Пока вам не понадобится взаимодействовать с чем-то, что имеет библиотеки в одной из этих, но не smalltalk.

Имена переменных с ошибками в 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);
        }
    }
}

Lua:

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"] = "John";
Person["Last_Name"] = "Smith";

Но это тоже объект. Я мог бы ссылаться на любой из этих «ключей» так:

Person.First_Name

И добавьте любые методы, которые я считаю необходимыми:

Person.changeFirstName = function(newName) {
  this.First_Name = newName;
};

Конечно, могут возникнуть проблемы, если newName не является строкой. Его поймают не сразу, если вообще, но вы можете проверить себя. Это вопрос обмена выразительной силы и гибкости в пользу безопасности. Я не возражаю против добавления кода для проверки типов и т. Д. Я сам, и я еще не столкнулся с ошибкой типа, которая сильно меня огорчила (и я знаю, что это мало о чем говорит. Это может быть вопросом времени: )). Однако мне очень нравится эта способность адаптироваться на лету.

Хорошая запись в блоге на ту же тему: Python заставляет меня нервничать

Сигнатуры методов в Python практически бесполезны. В Java статическая типизация превращает сигнатуру метода в рецепт: это все, что вам нужно, чтобы заставить этот метод работать. Не так в Python. Здесь сигнатура метода скажет вам только одно: сколько аргументов вам нужно, чтобы он работал. Иногда он даже этого не делает, если ты начнешь возиться с ** kwargs.

Потому что это весело, весело, весело. Например, забавно не беспокоиться о распределении памяти. Приятно не ждать компиляции. и т. д. и т. д.

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

Прошлой весной я использовал VHDL для нескольких классов, и мне нравится их метод представления битов / байтов и то, как компилятор обнаруживает ошибки, если вы пытаетесь назначить 6-битную шину 9-битной шине. Я попытался воссоздать его на C ++, и мне очень трудно заставить набор текста плавно работать с существующими типами. Я думаю, Стив Йегге очень хорошо описывает проблемы, связанные с системами сильных типов.

Что касается многословности: я считаю, что Java и C # довольно многословны в целом (давайте не будем отбирать маленькие алгоритмы, чтобы «доказать» точку зрения). И да, я написал на обоих. C ++ борется и в той же области; Здесь VHDL терпит поражение.

Экономия кажется достоинством динамических языков в целом (я представляю Perl и F # в качестве примеров).

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

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

Да, теоретически язык в стиле c может предоставлять аналогичные функции (D пытается с auto обнаружением типов и dmdr, который компилирует модули и запускает их на лету, как если бы они были сценариями),

Так что да, скептики правы в том, что быть динамичным не обязательно означает более простой / чистый код.

но на практике Python > Java

Попробуйте w = "my string here".split()[1] на C или даже на Java.

Для меня это вопрос ситуации. Я трачу много времени на написание кода Perl для веб-сайтов и C ++ для графических движков. Две совершенно разные области программирования на двух очень разных языках.

В любом случае, для меня динамические языки работают быстрее, поскольку я трачу меньше времени на то, чтобы убедиться, что фреймворк на месте, и больше на реальную проблему.

Однако статические языки предлагают более точный контроль, который может быть необходим в некоторых приложениях, таких как рендеринг графики в реальном времени. Я могу делать на C ++ вещи, которые работают намного эффективнее и быстрее, чем то, что я написал бы для Perl, но для размера большинства скриптов Perl потеря эффективности незначительна.

В конце концов, все сводится к постановке проблемы и вашим целевым целям. Если у вас есть много простых дел, в которых скорость и эффективность памяти не имеют большого значения, используйте динамический язык. Если у вас есть мегалитический проект, который должен выжать каждый последний цикл из вашей системы, переходите к статике.