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

Я думаю, что причина состоит в том, что люди привыкли к статически типизированным языкам, которые имеют очень ограниченные и невыразительные системы типов. Это языки как Java, C++, Паскаль, и т.д. Вместо того, чтобы идти в направлении более выразительных систем типов и лучшего вывода типа, (как в Haskell, например, и даже SQL в некоторой степени), некоторым людям нравится просто хранить всю информацию "типа" в их голове (и в их тестах) и покончить со статическим typechecking в целом.

то, Что это покупает Вас в конце, неясно. Существует много неверно понятых понятий о typechecking, те я обычно сталкиваюсь, эти два.

Ошибка: Динамические языки являются менее подробными. неправильное представление состоит в том, что информация о типе равняется аннотации типа. Это полностью неверно. Все мы знаем, что аннотация типа является раздражающей. Машина должна быть в состоянии понять тот материал. И на самом деле, это делает в современных компиляторах. Вот 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 и интерпретаторы Объятий для Haskell, и конечно SQL был и со статическим контролем типов и интерпретирован для дольше, чем я был жив.

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

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

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

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

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

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

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

И для записи, я - полностью занятый разработчик.NET, и я люблю скомпилированные языки. Я только использую динамические языки в свое свободное время для получения дополнительной информации о них и лучше мне как разработчик..

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

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

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

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

Моя оценка для динамических языков очень связывается с тем, как функциональный они. Понимания списка Python, закрытия Ruby и смоделированные объекты JavaScript являются всеми очень привлекательными фасетами тех языков. Все также показывают, в первом классе функционирует - что-то, без чего я не вижу проживание никогда снова.

я не категоризировал бы PHP и VB (сценарий) таким же образом. Мне те - главным образом императивные языки со всеми недостатками динамического контроля типов, которые Вы предлагаете.

Несомненно, Вы не получаете тот же уровень проверок времени компиляции (так как нет времени компиляции), но я ожидал бы, что статические проверяющие синтаксис инструменты для развития со временем к, по крайней мере, частично решают ту проблему.

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

я путь более продуктивен в Python, чем в C или Java, и не только, потому что необходимо сделать танец edit-compile-link-run. Я становлюсь более продуктивным в Objective C, но это происходит, вероятно, более из-за платформы.

, Само собой разумеется, я более продуктивен на любом из этих языков, чем PHP. Черт, я кодировал бы в Схеме или Прологе, чем PHP. (Но в последнее время я на самом деле делал больше Пролога, чем что-либо еще, поэтому возьмите это с мелкой частицей соли!)

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

1. Динамические языки не должны быть скомпилированы : просто выполните их. Можно даже перезагрузить файлы во время выполнения, не перезапуская приложение в большинстве случаев.
2. Динамические языки обычно - меньше подробное и больше читаемое : Вы когда-либо смотрели на данный алгоритм или программу, реализованную на статическом языке, затем сравнивали ее с Ruby или эквивалентным Python? В целом Вы смотрите на сокращение строк кода фактором 3. Много кода лесов является ненужным на динамических языках, и это означает, что конечный результат более читаем и более сфокусирован на фактической проблеме под рукой.
3. не волнуются о вводе проблем : общий подход, когда программирование на динамических языках не должно волноваться о вводе: большую часть времени правильный вид аргумента будет передан Вашим методам. И время от времени, кто-то может использовать другой вид аргумента, который просто, оказывается, работает также. Когда вещи идут не так, как надо, Ваша программа может быть остановлена, но это редко происходит, если Вы сделали несколько тестов.

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

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

, Но тогда я вид мисс время компиляции, проверяя (опечатка действительно происходит), и IDE, автоматический завершенный. В целом, меньший объем кода и удобочитаемость окупаются для меня.

Другое преимущество обычно интерпретировано/не, скомпилировал природа языка. Измените некоторый код и сразу посмотрите результат. Это - действительно средство экономии времени во время разработки.

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

Вот 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 известно paren-тяжел. Более близким equivelent 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 от здесь

Я - полный рабочий день.Net программист, полностью укрепленный в муках C# со статическим контролем типов. Однако я люблю современный JavaScript.

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

я думаю, что существует несколько классов динамических языков, также. У меня нет требования вернуться к записи классических ASP-страниц в VBScript. Чтобы быть полезным, я думаю, что динамический язык должен поддерживать своего рода набор, список или ассоциативную конструкцию в ее ядре так, чтобы объекты (или что передача для объектов) могли быть выражены и позволить Вам создавать более сложные конструкции. (Возможно, мы должны все просто кодировать в LISP..., это - шутка...)

, я думаю в.Net кругах, динамические языки получают плохой рэп, потому что они связаны с VBScript и/или JavaScript. VBScript является просто вспомненным как кошмаром по многим причинам указанный Kibbee - кто-либо не забывает осуществлять тип в VBScript с помощью CLng, чтобы удостовериться, что Вы получили достаточно битов для 32-разрядного целого числа. Кроме того, я думаю, что JavaScript все еще просматривается как язык браузера для выпадающих меню, который записан различный путь ко всем браузерам. В этом случае проблемой не является язык, но различные объектные модели браузера. То, что интересно, то, что, чем больше C# назревает, тем более динамичный он начинает для взгляда. Я люблю Лямбда-выражения, анонимные объекты и вывод типа. Это каждый день чувствует больше как JavaScript.

VBScript сосет, если Вы не сравниваете его с другой разновидностью VB. PHP в порядке, пока Вы имеете в виду, что это - переросший язык шаблонной обработки. Современный JavaScript является большим. Действительно. Тонны забавы. Просто держитесь подальше от отмеченного "DHTML" любых сценариев.

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

, Но, я действительно не ответил на Ваш вопрос. Почему динамические языки обращаются? Поскольку через некоторое время, пишущий код становится тусклым, и Вы просто хотите реализовать алгоритм. Вы уже сидели и разработали все это в пере, схематически изобразили потенциальные проблемные сценарии и доказали их разрешимый, и единственная вещь, оставленная сделать, кодировать двадцать строк реализации... и двести строк шаблона, чтобы заставить его скомпилировать. Тогда Вы понимаете, что система типов, с которой Вы работаете, не отражает то, что Вы на самом деле делаете, но чужая ультраабстрактная идея того, что Вы могли бы сделать, и Вы давно отказались от программирования для жизни knicknack, настраивающего столь обсессивно-компульсивный, что это позорило бы даже вымышленного детектива Adrian Monk.

Именно тогда Вы <забастовка> идете, оштукатурены начинают смотреть серьезно на динамические языки.

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

1) код является менее подробным. Я не нахожу это допустимым. Некоторые динамические языки являются менее подробными, чем некоторые статические. Но F# со статическим контролем типов, но статический контроль типов там не добавляет много, если таковые имеются, код. Это неявно вводится, тем не менее, но это - другая вещь.

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

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

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

я предполагаю, что буду в широком масштабе downvoted для этого, но я рискну.

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

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

Аргумент более сложен, чем это (читайте статья "Is Weak Typing Strong Enough" Yegge для интересного обзора).

Динамические языки не обязательно испытывают недостаток в проверке ошибок любой - вывод типа C# является возможно одним примером. Таким же образом C и C++ имеют ужасные проверки компиляции, и они со статическим контролем типов.

основными преимуществами динамических языков является a) возможность (который должен не обязательно использоваться все время), и закон b) Boyd Повторения .

последняя причина значительна.

FWIW, компиляция в большинстве приложений не должна занимать часы. Я работал с приложениями длиной от 200 до 500 тысяч строк, которые компилируются за минуты. Конечно, не часы.

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

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

Так что, может быть, это для меня более важная вещь, чем проблема с динамическим / статическим языком?

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

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

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

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

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

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

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

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

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

Я думаю, что у обоих стилей есть свои сильные стороны. На мой взгляд, такое мышление «либо / или» наносит вред нашему сообществу. Я работал с архитектурами, которые были статически типизированы сверху вниз, и это было нормально. Моя любимая архитектура - это динамическая типизация на уровне пользовательского интерфейса и статическая типизация на функциональном уровне. Это также способствует возникновению языкового барьера, который приводит к разделению пользовательского интерфейса и функций.

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

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

Smalltalk на Squeak / Pharo с Seaside - гораздо более эффективная и действенная веб-платформа, чем ASP.Net (/ MVC), RoR или Калитка для сложных приложений. Пока вам не понадобится взаимодействовать с чем-то, что имеет библиотеки в одной из этих, но не в smalltalk.

Имена переменных с ошибками в IDE отображаются красным цветом, IntelliSense работает, но не так специфично. Ошибки времени выполнения на веб-страницах - это не проблема, а особенность, один щелчок, чтобы вызвать отладчик, один щелчок, чтобы моя IDE, исправить ошибку в отладчике, сохранить, продолжить. Для простых ошибок время приема-передачи для этого цикла составляет менее 20 секунд.

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

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

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

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

Динамические языки наносят ответный удар

http: // www. youtube.com/watch?v=tz-Bb-D6teE[1216 visible Обсуждение динамических языков, некоторые из положительных и отрицательных сторон на самом деле не соответствуют действительности.

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

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

 lindex $mylist end-2

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

Я считаю, что «новая любовь» к языкам с динамической типизацией связана не столько с тем, являются ли языки со статической типизацией лучше или хуже - в абсолютном смысле, - чем с ростом популярности языков с динамической типизацией некоторые динамические языки. 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 #, в дополнение к другим динамическим языкам.

s совсем не широко используется - например, с операциями со списками.

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

s совсем не широко используется - например, с операциями со списками.

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

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

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

и хотя у него нет №3, его система типов настолько гибкая, что вы, вероятно, не сочтете отсутствие мета ограничивающим. Я считаю, что вы можете выполнять метапрограммирование в OCaml во время компиляции с помощью языкового расширения. Scala - очень недавнее дополнение, и оно очень многообещающее. F # для .NET-лагеря. Но пользователи этих языков составляют меньшинство, и поэтому они не внесли особого вклада в это изменение в ландшафте языков программирования. На самом деле, я очень верю, что популярность Ruby положительно повлияла на популярность таких языков, как Haskell, OCaml, Scala и F #, в дополнение к другим динамическим языкам.

и хотя у него нет №3, его система типов настолько гибкая, что вы, вероятно, не сочтете отсутствие мета ограничивающим. Я считаю, что вы можете выполнять метапрограммирование в OCaml во время компиляции с помощью языкового расширения. Scala - очень недавнее дополнение, и оно очень многообещающее. F # для .NET-лагеря. Но пользователи этих языков составляют меньшинство, и поэтому они не внесли особого вклада в это изменение в ландшафте языков программирования. На самом деле, я очень верю, что популярность Ruby положительно повлияла на популярность таких языков, как Haskell, OCaml, Scala и F #, в дополнение к другим динамическим языкам.

Scala - очень недавнее дополнение, и оно очень многообещающее. F # для .NET-лагеря. Но пользователи этих языков составляют меньшинство, и поэтому они не внесли особого вклада в это изменение в ландшафте языков программирования. На самом деле, я очень верю, что популярность Ruby положительно повлияла на популярность таких языков, как Haskell, OCaml, Scala и F #, в дополнение к другим динамическим языкам.

Scala - очень недавнее дополнение, и оно очень многообещающее. F # для .NET-лагеря. Но пользователи этих языков составляют меньшинство, и поэтому они не внесли особого вклада в это изменение в ландшафте языков программирования. На самом деле, я очень верю, что популярность Ruby положительно повлияла на популярность таких языков, как Haskell, OCaml, Scala и F #, в дополнение к другим динамическим языкам.

Put yourself in the place of a brand new programmer selecting a language to start out with, who doesn't care about dynamic versus staic versus lambdas versus this versus that etc.; which language would YOU choose?

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)

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

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

Кроме того, я устал писать такие вещи, как MyFancyObjectInterface f = new MyFancyObject (). DRY принцип кто нибудь?

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

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

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

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

В любом случае, Одно из преимуществ слабо типизированных языков состоит в том, что нам все равно, какой это тип, если он ведет себя так, как должен. Это причина того, что у нас есть утиная типизация в динамически типизированных языках. это отличная функция, и я могу использовать одни и те же имена переменных для хранения разных типов данных по мере необходимости. также, статически типизированные языки заставляют вас думать как машина (как компилятор взаимодействует с вашим кодом и т. д.), тогда как языки с динамической типизацией, особенно ruby ​​/ ror, заставляют машину думать как человек.

Вот некоторые из аргументов, которыми я оправдываю свою работу и опыт работы с динамическими языками!

Мне нравятся как статические, так и динамические языки. Каждый проект, в котором я участвовал примерно с 2002 года, был приложением C / C ++ со встроенной интерпретацией Python. Это дает мне лучшее из обоих миров:

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

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

Чтобы ответить на вопрос «Что за любовь к динамическим языкам? " Для меня это возможность полностью перенастроить систему во время выполнения любым возможным способом. Я считаю, что язык сценариев «запускает шоу», поэтому исполняющее приложение может делать все, что вы пожелаете.

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

Личная часть - это обмен некоторых проверок и других шагов для скорости разработки и тестирования ( при этом, вероятно, откажется от некоторой производительности процессора). Есть люди, для которых это освобождает и повышает производительность, а есть некоторые, для которых это совершенно противоположно, и да, это действительно зависит от конкретного вкуса вашего языка. Я имею в виду, что здесь никто не говорит, что Java отлично подходит для быстрой и лаконичной разработки, или что PHP - надежный язык, в котором вы редко допускаете труднодоступные опечатки.

У меня нет большого опыта работы с динамическими языками в целом, но один динамический язык, который я знаю, JavaScript (он же ECMAScript), мне очень нравится.

Подожди, о чем здесь идет речь? Динамическая компиляция? Или динамический набор текста? JavaScript охватывает обе основы, поэтому я думаю, что я расскажу об обоих:

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

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

Но когда компиляция отложена, результаты можно увидеть быстрее. Это одно из преимуществ. Мне нравится просто сохранять файл и довольно быстро наблюдать за моей программой в действии.

Еще одно преимущество состоит в том, что вы можете писать и компилировать код во время выполнения . Возможно ли это в статически скомпилированном коде, я не знаю. Я полагаю, что это должно быть так, поскольку все, что компилирует JavaScript, в конечном итоге является машинным кодом и статически компилируется. Но на динамическом языке это тривиальная вещь. Код может писать и запускать сам. (И я почти уверен, что .NET может это сделать, но CIL, в который компилируется .NET, в любом случае динамически компилируется на лету, а в C # это не так тривиально)

Динамическая типизация :

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