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

81

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

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

Роберт Харви
источник
9
Довольно грустно (и странно) видеть так мало защищающих динамические языки.
davidtbernal
11
Поскольку это единственный способ разобраться, прежде всего, с динамическими ненавистниками, приведенными ниже, я отвечу здесь: динамические языки позволяют писать код быстрее, и здесь нет двух способов. Мне не нужно беспокоиться о типе какой-либо из моих переменных, и мне не нужно запускать большую тяжелую IDE для написания кода. Таким образом, намного лучше выполнять быстрые задачи, которые потребовали бы больше времени с системами статического типа из-за громоздкости систем типов, заставляющих вас сообщать компилятору ВСЕ.
RCIX
2
Что за ограниченная близорукость программистов на C #?
Azeem.Butt
2
Я так понимаю, вы тогда недостаточно читали steve.yegge.googlepages.com/is-weak-typing-strong- ?
RCIX
5
Проблема с неправильным написанием имен переменных связана с неявным объявлением переменных, а не со статическими / динамическими. В динамических языках, требующих явного объявления переменных (например, Smalltalk), этой проблемы нет.
Фрэнк Шеарар,

Ответы:

101

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

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

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

Apocalisp
источник
26
Откажитесь от безопасного типа ради свободы, не заслуживаете ни того, ни другого .. О да, чувак .. Отлично, близко к сообщению
baash05
6
lisp сам по себе довольно многословен, он не имеет ничего общего с его динамической типизацией ... попробуйте его в python. def qsort (l): return qsort ([x for x in l [1:] if x <l [0]]) + l [0] + qsort ([x for x in l [1:] if x> = l [0]]) if l else l
fortran
13
В том-то и дело. Это не имеет ничего общего с динамической или статической типизацией.
Apocalisp
9
Я бы сказал, что ваши примеры довольно скудные. Люди, восхваляющие динамические языки, вряд ли выберут Lisp of Haskell. Скорее всего, они предпочтут Python или Ruby, а не Java или C #.
Кори Д.
8
Утверждают, что существует связь между многословием и многогранностью. Как видите, любое такое совпадение - чистая случайность. Именно поэтому я выбрал эти языки нетипично. Haskell имеет более строгую типизацию, чем что-либо еще, поэтому он является хорошим представителем статически типизированных языков. LISP - это типичный динамический язык, который все остальные обязательно имитируют, но никогда не дублируют.
Apocalisp
70

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

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

FlySwat
источник
4
Рад, что я не единственный. Улучшает сон по ночам.
erikkallen
Это действительно большое преимущество статической типизации перед динамической. Я не могу сказать, сколько раз я пропускал typedef в C ++, просто чтобы компилятор мог найти мне еще несколько ошибок. (Давай, компилятор, давай! Принеси мне еще несколько ошибок! :-)
Dimitri C.
Бред какой то. Если вы тестируете метод и тестируете методы, вызывающие этот метод, вы знаете, что передача параметров в порядке. По определению, хорошо протестированный код не получит никаких дополнительных преимуществ от статической типизации.
Гарт Кидд,
4
@Garth: странное определение. Не многие люди согласятся с этим. OTOH, большинство людей согласятся, что средство проверки типов компилятора реализует множество (иногда очень сложных) тестов.
Конрад Рудольф
3
@yar, если вы не тестируете свой код, вы уязвимы для логических ошибок. Я работаю на Python уже десять лет. Я не думаю, что у меня когда-либо была TypeError в производстве. Однако у меня было много логических ошибок. Вывод: мне не особо нужна статическая проверка типов, но модульные тесты мне точно нужны.
Гарт Кидд,
40

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

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

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

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

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

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

erikkallen
источник
цитата: На динамических языках результаты можно сразу увидеть. Новости: Вы можете сделать это и с C # в Visual Studio (с 2005 года). Просто установите точку останова, запустите программу в отладчике и измените программу во время отладки. Я делаю это все время, и это прекрасно работает. Это было в Delphi с первого дня (1995?) И, вероятно, в Turbo Pascal до этого (я точно не помню).
Ноам Ньюман,
6
10к строк javascript? Я думаю, что это примерно на 9000 строк слишком много, и я люблю языки сценариев ...
Унция.
@ No'am: я знаю. Вы могли бы сделать это и в Visual C ++ 6 (что для меня было главным моментом не переходить на C # до выхода VS2k5). Во всяком случае, это только добавляет сути. @Oz: Как узнать, сколько работы должен сделать мой JS?
erikkallen
Я думаю, что люди, которым нравится видеть, как их изменения вступают в силу немедленно, как и при использовании текстового редактора, а не VS. Каждому свое. Вы можете подумать об использовании чего-то вроде JSLint.
dlamblin 01
2
Хороший момент с рефакторингом. Мне действительно нравится Ruby для быстрого прототипирования и создания небольших скриптов, но я бы никогда не стал пытаться поддерживать большой продукт несколькими разработчиками без статической типизации.
LoveMeSomeCode
19

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

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

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

Вот когда вы идти напиваться начать смотреть серьезно на динамических языках.

Shog9
источник
Интересный материал ... Я посмотрю, убедит ли меня Руби. У PHP нет, но я чувствую, что во многом это связано с тем, что об объектах объектно-ориентированного программирования задумались позже.
Дэн Розенстарк 01
3
«двадцать строк реализации ... и двести строк шаблона для компиляции»: я не согласен с этим утверждением. Конечно, это было правдой во времена Java, но C # 3 и Scala значительно сократили количество требуемых шаблонов.
cdmckay
5
Дни Java закончились? взламывает пиво и готовится отпраздновать О ... подождите ... C ++.
Shog9,
2
«VBScript отстой, если вы не сравниваете его с другим вариантом VB» А? Вы говорите, что VBScript - лучший вариант Visual Basic? Я, должно быть, неправильно тебя недооценил.
MusiGenesis
19

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

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

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

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

Питер Мейер
источник
1
Я бы хотел, чтобы кто-нибудь добавил в JavaScript обработку файлов, сокеты и библиотеку GUI, а затем построил компилятор ... JS на рабочем столе .......
UnkwnTech
2
code.google.com/p/jslibs
Бретон,
Кроме того, всегда можно было написать приложение с графическим интерфейсом для Windows, используя jscript. Ну, по крайней мере, очень-очень долго. см. "windows hta" для получения дополнительной информации. Вы получаете дополнительный apis, работающий в hta, которого нет в браузере. Виджеты на панели инструментов получают большую мощность. Веб-приложения на iphone намного мощнее, чем думает большинство людей. Apple сделала множество мощных API-интерфейсов для браузера JS в мобильном сафари.
Breton
commonjs.org
Xiong Chiamiov
+1 для намерения здесь. Хотя в один прекрасный день ваш код может быть переведен на статический язык, динамики (особенно Python) отлично подходят для разовых экземпляров и прототипов.
new123456
18

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

Крис Апчерч
источник
25
Это не возражение, а аргумент в поддержку. Это говорит о том, что система типов языка (или ее отсутствие) очень мало говорит нам о том, будет ли она многословной или краткой.
Apocalisp
2
Я согласен с Apocalisp, многословие не зависит ни от динамических, ни от статических языков. Я бы даже сказал, что статическая / динамическая типизация практически не влияет на многословность языка. Так что да, это не лагерь статической печати, разрушающий реплику.
BefittingTheorem
или Perl! сортировка (@array);
Джеймс Андерсон,
Все сравнение Апокалиспа было чушью. Во-первых, быстрая сортировка (как определено в исходной статье Тони Хоара) - это алгоритм на месте, специально разработанный для использования минимального дополнительного пространства, но Apocalisp использовал убранную версию сообщества Haskell, которая неуместна тратит асимптотически больше памяти и выполняется сотни раз. медленнее, чем настоящая быстрая сортировка. Haskell изо всех сил пытается выразить настоящий алгоритм быстрой сортировки, потому что он полагается на мутации (!). Посмотрите эти попытки Haskell и вернитесь ко мне по поводу предполагаемой краткости Haskell: haskell.org/haskellwiki/Introduction/Direct_Translation
JD
Во-вторых, вы не можете делать каких-либо серьезных заявлений о многословности на основе двух реализаций алгоритма, который был убран специально для одного из языков. Посмотрите на APL, J, K, Mathematica или любой другой лаконичный (= современный) язык с динамической типизацией. Они должны быть более краткими, чем любой язык со статической типизацией. Вывод типа сокращает разрыв, но он все равно должен оставаться.
JD
15

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

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

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

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

Хтаната
источник
По крайней мере, одна известная мне Python IDE (а именно, IDLE, которая поставляется с обычной сборкой интерпретатора Python) действительно имеет возможности автозаполнения, хотя объявленные переменные имеют ее только в окне интерпретатора.
JAB
удобочитаемый? вы видели пример быстрой сортировки? я понятия не имею, что там происходит. Вы можете возразить, что это плохо написано, чтобы показать, как быстро вы можете что-то написать, но это не читается.
IAdapter 05
1
@ 01: он использует общие конструкции языка. Его довольно удобно читать, если вы знаете основы языка.
Эстебан Кюбер,
1
Читаемость не имеет ничего общего с динамической типизацией. Например, лямбды в Scala обычно короче (и, возможно, более выразительны), чем блоки Ruby, то же самое при сравнении дополнений списков Haskell и Python. Консоль REPL существует, например, для F #, Scala, Haskell. Быстрая загрузка измененного кода в работающее приложение - сильная сторона динамических языков. Хотя есть некоторые технологии, которые позволяют использовать статические языки (например, JavaRebel).
Алексей
1
Интересно, что я считаю код МЕНЬШЕ читабельным. Номер один, потому что я часто не могу использовать свою IDE, чтобы быстро найти объявления, встроенную документацию и т. Д., И номер два, потому что синтаксис настолько компактен, что довольно часто я забываю, что он означает! Я бы также дал БОЛЬШОЙ вес на потерю автозаполнения IDE. Это не только находка, я думаю, что это значительно увеличивает ремонтопригодность.
spronkey 06
12

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

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

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

wvdschel
источник
7
@wvdschel: По вашей логике, я могу утверждать, что компилируемые языки, такие как C # и Java, не нуждаются в компиляции, поскольку все, что мне нужно сделать, это нажать кнопку «Play» в моей среде IDE, и они просто запустятся. Поскольку я не замечаю, что IDE компилируется для меня, это «просто не имеет значения».
cdmckay
2
@cdmckay: Можете ли вы подключиться к вашей запущенной программе C # / Java и запускать для нее команды, изменяя или запрашивая ее во время работы. Интерпретируемые (каковыми являются многие динамические языки) языки позволяют проводить интроспекцию во время выполнения, в отличие от компилируемых языков.
RHSeeger,
4
@RHSeeger - Да, все это можно сделать с помощью Visual Studio. Edit-and-continue не ограничивается динамическими языками.
Грег Бич,
4
@ baash05, я думаю, вы полностью пропустили момент этого ответа, 1. означает, что вы можете запускать код, когда исправляете его быстрее, не нужно ждать, пока компилятор увидит эффекты каждого небольшого изменения. 2. Согласны ли вы с эффектом этого или нет, будет меньше кода для написания и чтения, не оспаривая этот факт.
Fire Crow,
1
2. Это не проблема статического и динамического, а процедурного против функционального. Верно: Python (и многие другие динамические языки) более функциональны, чем Java. Ложь: это как-то связано с динамической типизацией.
erikkallen 03
8

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

аэропортых
источник
7

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

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

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

Мэтью Шинкель
источник
6

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

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

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

Юкондуде
источник
Я никогда раньше не слышал, чтобы кто-нибудь даже предполагал, что ему нравятся прототипы объектов JavaScript.
erikkallen
6

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

Кибби
источник
Вы правы, что в языках с динамической типизацией нет ничего, что позволяло бы вам изменять код в работающей системе. С интерпретируемыми языками намного проще (не путать с динамическими), но это можно сделать даже с помощью скомпилированного кода. Как один из примеров, Oracle PL / SQL - это статически типизированный компилируемый язык, и Oracle уже несколько десятилетий имеет функцию, позволяющую изменять процедуры PL / SQL в работающей системе.
Apocalisp
Теперь в Mono есть ответ
Стив Гилхэм,
Динамические языки могут делать такие вещи вне отладчика и внутри вашего приложения . Кроме того, возможность делать патчи обезьяны к классам при модульном тестировании экономит время.
Эстебан Кюбер,
6

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

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

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

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

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

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

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

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

оборота майкинетор
источник
6
Вы часто создаете калькуляторы? Я обнаружил, что аргументы типа «Я могу создать приложение hello world из 20 символов» вообще не имеют никакого значения.
erikkallen
Вы только что показали, насколько у вас крайне слабое воображение. Плохая штука для программирования м8. GL.
majkinetor
Не нужно переходить на личности. Думаю, это справедливо. Очень легко (и очень часто) придумать аргументы типа «посмотрите, сколько кода вам нужно написать, чтобы вывести строку на консоль на C #, в lua я могу просто сказать print (« Привет, мир ») '. Но соотношение реального кода к шаблонному не остается таким, когда проекты вырастают до реалистичных размеров.
erikkallen 03
2
Фигня. Вот какой-то статически типизированный F #, работающий на .NET: Linq.QuotationEvaluator.Evaluate <@ 2 + 3 @>
JD
6

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

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

 lindex $mylist end-2

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

RHSeeger
источник
1
Чем это лучше, чем $ mylist.length-2? Мне кажется, что такой синтаксис только добавляет дополнительные ключевые слова без реальной пользы, что означает, что язык сложнее выучить.
erikkallen
Я буду немного педантичен и укажу, что он не добавляет никаких ключевых слов к самому языку, он добавляет их к этой команде. При этом, это вопрос ясности. Термин «конец» выражает намерение / значение, а не то, как этого добиться; там написано «последний элемент».
RHSeeger
1
Если я правильно понял, в этом случае все еще хуже. Вы должны изучить новый синтаксис для каждой команды. что означает строка ключевых слов при использовании в команде foo?
erikkallen 03
@erikkallen: Это то же самое, что узнать, какие входы в стандартную библиотеку имеют для любого другого языка. Фактически, каждая команда в ядре Tcl в большей или меньшей степени является частью стандартной библиотеки. Теоретически нет команд, которые нельзя было бы удалить и повторно реализовать как чистый код Tcl. При этом входные данные и то, что они означают, довольно согласованы во всей библиотеке (т.
Е.
5

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

оборота UnkwnTech
источник
3
О боже, на практике ... ну, может я просто некомпетентен, но в PHP проблемы с неправильным написанием переменных - огромная трата времени. Особенно когда вы унаследовали огромную базу кода, которая не позволяет включать строгие предупреждения.
Дэн Розенстарк, 01
1
Вы можете ВСЕГДА включить строгий error_reporting (), и любая хорошая IDE предотвратит 99% ошибок в написании переменных.
UnkwnTech 04
Не говоря уже о том, что можно ошибиться в написании чего-либо на любом языке, однако легче (возможно, быстрее) найти эти ошибки, потому что мой интерпретатор находится на том же этапе при компоновке / компиляции, поэтому снова ваше возражение безразлично.
UnkwnTech 04
4
-1: аргумент компиляции отвлекает от реального аргумента, который касается типизации, статического или динамического. Как динамические, так и статические языки можно компилировать и интерпретировать. Жалобы на орфографию и время компиляции выходят за рамки этих вопросов.
BefittingTheorem
Буквально часы? На чем вы компилируете, на оригинальном IBM PC?
xcramps, 04
3

Аргумент более сложный, чем этот (прочтите статью Егге «Слабый ввод достаточно силен», чтобы получить интересный обзор).

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

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

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

Мэтт Митчелл
источник
3
Вывод типа - это не то же самое, что динамическая типизация, потому что предполагаемый тип по-прежнему должен быть однозначно известен во время компиляции.
Маркус Даунинг,
4
-1: C # типизируется статически, а не динамически.
Джульетта
2

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

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

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

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

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

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

Дэн Герберт
источник
2
Я считаю, что любой аргумент «для опытных разработчиков это не проблема» обычно немного опасен. Например, я мог бы сказать, что ООП / управление памятью и т.д. в C ++ не проблема для опытного разработчика. Почему с такой простой вещью, как объявление переменных и базовая проверка типов, мне нужно быть таким осторожным и опытным? Я бы предпочел, чтобы язык помогал мне программировать, а не позволял мне делать ошибки, которые можно легко предотвратить с помощью статического подхода. И я думаю, что многословие очень мало связано с динамической или статической типизацией, посмотрите Haskell или Scala.
BefittingTheorem
Я согласен, я также считаю этот аргумент немного опасным. Я хочу сказать, что проблема проверки типов во время кодирования не так уж и плоха. Вы увидите ошибку сразу в 90% случаев. Это проблема в 10% случаев, когда неявное преобразование типа может вызвать стресс, однако, если вы знаете, что делаете, вы этого не допустите. JavaScipt - отличный пример из 10%, где это может быть опасно, но я никогда не сталкивался с этим за все время разработки для него.
Дэн Герберт
@Brian Heylin: тогда ты должен ненавидеть C! Так много способов прострелить себе ногу, но они так используются и (в некоторых случаях) любимы.
Эстебан Кюбер,
2

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

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

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

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

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

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

Умар
источник
1
Ваши точки 1 и 3 идентичны, и IMO является причиной предпочтения статической типизации. Что, если вы измените тип на несовместимый? Если вы меняете переменную с int на строку, вы, вероятно, делаете это не просто так. А если нет, просто перестройте проект, пока все ошибки сборки не исчезнут. Обычно это не занимает много времени, и иногда в процессе вы обнаруживаете настоящую проблему, о которой вы рады, что компилятор указал вам. Пункт 2 недействителен, рост строки выполняется автоматически на всех языках (я думаю, по крайней мере, на всех, с которыми я сталкивался за последние 15 лет), кроме C.
erikkallen
Я согласен с тем, что в зависимости от приложения у вас может быть причина предпочесть любой тип языка другому, а статические языки, которые работают быстрее, могут обеспечить лучшую производительность. Но я говорил, что если вам нужно создать веб-приложение, подобное любому другому, возможно, вам будет лучше быстрее предоставлять функциональные возможности, используя динамический язык, чем статический. Также предположим, что вам нужно использовать переменную x таким образом, чтобы x.func = "yes" и x.func _ = "no". Тебе все равно, какой это тип, это утка, если она плавает как утка. Вот почему динамическую типизацию также называют утиной типизацией. 0 осталось!
umar
1

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

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

Джефф Котула
источник
1

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

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

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

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

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

Bdwakefield
источник
1
Я бы сказал, что время компиляции действительно зависит от используемого языка. В .Net для компиляции проекта такого размера может потребоваться всего пара минут. Если он сделал это на C, то я мог бы видеть, что для компиляции всего требуется время.
Kibbee
Хорошо, я дам тебе это. Но если подумать, сколько проектов, которые, по вашему мнению, можно было бы написать на C, можно было бы написать на PHP со значительным временем компиляции? Я думаю, что есть определенный момент, когда интерпретируемые языки не подходят для работы, и наоборот. Я большой поклонник того, чтобы использовать правильный инструмент для работы и то, с чем вы лучше всего работаете. Я не вижу причин пытаться заставить один язык делать все, когда другой может сделать это проще. Нет причин переучивать то, что вы знаете.
bdwakefield
Кстати, есть плагин php для VS jcxsoftware.com/vs.php. Я еще не пробовал его, так как он не бесплатный, но из того, что я слышал, он так же хорош с php, как и Zend (5.5 как 6 отстой) со всем совершенство VS
UnkwnTech
Вы просто понимаете, что является одной из главных причин, по которой никто не использует так много динамических языков. Никто не построил большую причудливую 2-метровую IDE кода, которая могла бы сделать для вас почти все, с любым из них, поэтому все жалуются на то, что «они небезопасны по типу, поэтому слишком легко ошибаться»
RCIX,
Я не забочусь о бессмысленном типе безопасного. Меня это не особо беспокоит. Моя самая большая жалоба заключается в том, что это просто физически занимает больше времени, и часто намного сложнее отслеживать проблемы. Я считаю, что стиль разработки противоречит тому, как я люблю работать.
bdwakefield
1

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

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

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

Стефан Эггермонт
источник
1

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

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

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

RHSeeger
источник
1

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

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

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

Стефано Борини
источник
1

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

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)
RCIX
источник
3
На самом деле это не аргумент. Мы не новички в программировании; Эти дебаты наиболее ожесточенно бушуют между не новичками в программировании.
peSHIr
Это лишь одна из причин, почему программисты, возможно, предпочли динамические языки; их, как правило, легче понять, чем других, и поэтому они привлекают к себе больше новых программистов.
RCIX
1

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

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

dlamblin
источник
1

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

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

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

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

Дэниел Полл
источник
1

У меня нет большого опыта работы с динамическими языками в целом, но один динамический язык, который я знаю, 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 не является строкой. Его не сразу поймают, если вообще, но вы можете проверить себя. Это вопрос обмена выразительной силы и гибкости в пользу безопасности. Я сам не против добавления кода для проверки типов и т. Д., И я еще не столкнулся с ошибкой типа, которая сильно меня огорчила (и я знаю, что это мало что говорит. Это может быть вопросом времени: )). Однако мне очень нравится эта способность адаптироваться на лету.

Боб
источник
1

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

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

Агнель Куриан
источник
0

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

Энди Лестер
источник
19
Сборка мусора ортогональна статической / динамической проверке типов.
mmagin
0

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

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

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

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

Пол Натан
источник
Эквивалент присвоения 9-битной шины 6-битной - попытка присвоить int короткому или чему-то подобному. Это ошибка C # (и, я думаю, Java), и любой компилятор C или C ++ должен иметь возможность выдавать предупреждение об этом.
erikkallen
-1. Weakly typed language != Dynamically typed language.
Joe D