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

Кажется, что в последнее время все прыгают на динамичную, не скомпилированную подножку. В основном я работал только на скомпилированных, статических типизированных языках (C, Java,.Net). У меня есть динамические языки, такие как ASP (Vb Script), JavaScript и PHP. Использование этих технологий оставило плохой вкус во рту, когда мы думаем о динамических языках. Вещи, которые обычно были пойманы компилятором, такие как имена переменных с ошибками и присвоение значения неправильного типа переменной, не выполняются до времени выполнения. И даже тогда вы можете не заметить ошибку, поскольку она просто создает новую переменную и присваивает определенное значение по умолчанию. Я также никогда не видел, чтобы intellisense хорошо работала на динамическом языке, поскольку, ну, переменные не имеют явного типа.

Что я хочу знать, что люди находят настолько привлекательными для динамических языков? Каковы основные преимущества в отношении того, что позволяют динамические языки, что невозможно сделать, или их сложно сделать на скомпилированных языках. Мне кажется, что мы давно решили, что такие вещи, как uncompiled asp pages, бросающие исключения во время выполнения, были плохой идеей. Почему происходит возрождение этого типа кода? И почему мне кажется, по крайней мере, что Ruby on Rails на самом деле не похож на все, что вы не могли сделать с ASP 10 лет назад?

Ответ 1

Я думаю, причина в том, что люди привыкли к статически типизированным языкам, которые имеют очень ограниченные и невыразительные системы типов. Это языки, такие как Java, С++, 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 был как статически типизирован, так и интерпретирован дольше, чем я был жив.

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

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

Ответ 2

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

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

Ответ 3

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

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

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

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

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

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

Ответ 4

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

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

Но я не ответил на ваш вопрос. Почему динамические языки привлекательны? Потому что через некоторое время написание кода становится скучным, и вы просто хотите реализовать алгоритм. Вы уже сидели и все работали в ручке, описывали потенциальные проблемные сценарии и доказывали, что они разрешимы, и осталось только составить код двадцать строк реализации... и две сотни строк шаблона, чтобы он скомпилировал, Затем вы понимаете, что система типов, с которой вы работаете, не отражает то, что вы на самом деле делаете, а кто-то еще ультра-абстрактное представление о том, что вы могли бы делать, и вы давно отказались от программирования для жизни подделки, навязчиво-компульсивным, что он позорит даже вымышленного детектива Адриана Монка.

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

Ответ 5

Я полный программист .Net, полностью укоренившийся в муках статически типизированного С#. Тем не менее, я люблю современный JavaScript.

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

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

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

Ответ 6

Вот статически типизированный 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 из здесь

Ответ 7

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

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

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

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

Ответ 8

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

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

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

Ответ 9

Я считаю, что "новая найденная любовь" для динамически типизированных языков имеет меньше общего с тем, являются ли статически типизированные языки лучше или хуже - в абсолютном смысле - чем рост популярности некоторых динамических языков. Ruby on Rails, очевидно, было большим явлением, которое вызывает возрождение динамических языков. То, что сделало рельсы настолько популярными и создало так много конвертеров из статического лагеря, было в основном: очень кратким и сухим кодом и конфигурацией. Это особенно актуально в сравнении с веб-фреймворками Java, которые требуют гор XML-конфигурации. Многие программисты Java - умные - тоже переработаны, а некоторые даже евангельские рубины и другие динамические языки. Для меня три различных функции позволяют динамическим языкам, таким как Ruby или Python, быть более краткими:

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

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

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

Ответ 10

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

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

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

Ответ 11

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

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

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

Ответ 12

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

Ответ 13

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

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

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

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

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

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

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

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

Ответ 14

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

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

 lindex $mylist end-2

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

Ответ 15

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

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

Ответ 16

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

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

Основными преимуществами динамических языков являются: a) способность (которая необязательно должна использоваться постоянно) и b) Закон Боя Итерации.

Последняя причина массивная.

Ответ 17

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

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

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

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

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

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

Ответ 18

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

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

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

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

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

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

Ответ 19

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

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

Ответ 20

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

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

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

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

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

Ответ 21

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

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

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

Ответ 22

Динамические языки набрасываются назад

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

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

Ответ 23

Поставьте себя на место совершенно нового программиста, который выбирает язык для начала, который не заботится о динамическом сравнении с staic против лямбда против этого против этого и т.д.; на каком языке вы бы выбрали?

С#

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)

Ответ 24

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

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

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

Ответ 25

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

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

Ответ 26

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

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

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

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

Ответ 27

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

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

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

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

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

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

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

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

var Person = {};

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

Person["First_Name"] = "John";
Person["Last_Name"] = "Smith";

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

Person.First_Name

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

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

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

Ответ 28

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

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

Ответ 29

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

Ответ 30

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

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

Относительно многословия: Я нахожу Java и С# довольно многословными в больших (пусть не чередуются маленькие алгоритмы, чтобы "доказать" точку). И, да, я написал в обоих. С++ борется в той же области; VHDL уступает здесь.

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