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

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

Пример с 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».

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

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

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

Программирование программы.

Это довольно сложно сделать на компилируемых языках, например, например .Net. Чтобы заставить его работать, вы должны делать все виды мамбо-джамбо, и обычно это заканчивается кодом, который работает примерно в 100 раз медленнее.

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

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

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

Теперь попробуйте сделать это в .Net.

Моя основная причина, по которой мне нравятся динамические (типизированные, поскольку это, кажется, фокус потока) языки, заключается в том, что те, которые я использовал (в рабочей среде), намного превосходят нединамические языки, которые я использовал. 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 = {};

Вы знаете, что такое Человек сейчас? Это общий словарь. Я могу это сделать:

Человек ["First_Name"] = "Джон";
Человек ["Last_Name"] = "Кузнец";

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

Person.First_Name

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

Person.changeFirstName = function (newName) {
  this.First_Name = новое имя;
};

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

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

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

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

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

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

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

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