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

In general, I prefer talking about "interactive" languages rather than "dynamic" languages. When you only have an edit/compile/run cycle, any turn-around takes a long time. Well, at least on the order of "need to save, compile, check the compilation report, test-run, check test results".

With an interactive language, it's usually easy to modify a small part, then immediately test results. If your test runs still take a lomg time, you haven't won that much, but you can usually test on smaller cases. This facilitates rapid development. Once you have a known-correct implementation, this also helps optimisation, as you can develop and test your new, improved function(s) quickly and experiment with different representations or algorithms.

Вот части моего ответа на предыдущий аналогичный вопрос ( Я знаю C #. Стану ли я более продуктивным с Python? ):

Я сам работал с C # /. NET. Начал программировать в .NET в прим. 2001, и примерно в то же время был представлен Python. В 2001 году мое время, потраченное на C # по сравнению с Python, составляло около 90% C # / 10% Python. Теперь соотношение составляет 5% C # / 95% Python. В моей компании мы по-прежнему поддерживаем линейку продуктов на основе .NET. Но все новое основано на Python.

Мы создали нетривиальные приложения на Python.

По моему опыту, что делает меня более продуктивным в Python по сравнению с C #, это:

• Это динамический язык . Использование динамического языка часто позволяет удалить целые архитектурные слои из вашего приложения. Динамическая природа Pythons позволяет вам создавать многократно используемые абстракции высокого уровня более естественным и гибким (синтаксически) способом, чем вы можете в C #.
• Библиотеки. Стандартные библиотеки и многие библиотеки с открытым исходным кодом, предоставляемые сообществом, имеют высокое качество. Диапазон приложений, для которых используется Python, означает, что диапазон библиотек широк.
• Более быстрый цикл разработки. Отсутствие этапа компиляции означает, что я могу быстрее тестировать изменения. Например, при разработке веб-приложения сервер разработки обнаруживает изменения и перезагружает приложение при сохранении файлов. Запуск модульного теста из моего редактора осуществляется одним нажатием клавиши и выполняется мгновенно.
• «Легкий доступ» к часто используемым функциям: списки, составление списков, генераторы, кортежи и т. Д.
• Менее подробный синтаксис. Вы можете создать веб-фреймворк Python на основе WSGI с меньшим количеством строк кода, чем обычный файл .NET web.config : -)
• Хорошая документация. Хорошие книги.

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

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

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

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

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

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

Интерактивные оболочки! Это огромный прирост производительности. Просто запустите irb / python, чтобы сесть перед интерактивной оболочкой (для Ruby и Python соответственно). Затем вы можете в интерактивном режиме протестировать свои классы, функции, поэкспериментировать с выражениями (отлично подходит для регулярных выражений), различным синтаксисом и алгоритмами. Это настоящая площадка для программистов и отличный инструмент для отладки.

Только мне два цента об ошибках:

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

Обнаруживаемые компилятором ошибки - это ошибки, которые вы обнаружите при выполнении различных автоматических тестов (модульных, функциональных и т. д.), и те, которые вы должны написать в любом случае. Вероятно, Линус Торвальдс может сказать: Регрессионное тестирование »? Что это? Если он компилируется, это хорошо, если он загружается, он идеален , но у него есть тысячи тестеров, которые сделают эту работу за ему. Ах да, используя интерактивные оболочки, вы автоматически получаете обратную связь о своем синтаксисе, например, когда вы компилируете приложение, но код выполняется на месте.

Рассмотрим случай, когда у вас есть подпрограмма, которая принимает единственный аргумент:

sub calculate( Int $x ){ ... }

Теперь ваши требования меняются, и вам приходится иметь дело с несколькими аргументами:

multi sub calculate( Int $x ){ ... }
multi sub calculate( Int @x ){
  my @ret;
  for @x -> $x {
    push @ret, calculate( $x );
  }
  return @ret;
}

Обратите внимание, что было очень мало изменение между различными версиями.

А что, если бы вы узнали, что действительно должны были использовать числа с плавающей запятой:

multi sub calculate( Num $x ){ ... }
multi sub calculate( Num @x ){
  my @ret;
  for @x -> $x {
    push @ret, calculate( $x );
  }
  return @ret;
}

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

Эти примеры были написаны в Perl6

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

Для обнаружения ошибок большинство «неверных типов прошло» и ошибки «вызван неправильный метод» не являются тонкими, поэтому основное отличие состоит в том, что исключения заменяют ошибки компилятора. Вы должны убедиться, что действительно выполняете каждый путь кода и все важные пути данных, но, конечно, вы все равно делаете это для серьезных проектов. Я подозреваю, что это Редко бывает сложно протестировать все классы, которые могут быть присвоены данной переменной. Основная проблема в том, что люди, привыкшие к C ++, научились полагаться на компилятор и не стараются избегать больших классов ошибок, которые компилятор улавливает. В Python у вас есть возможность думать об этом во время написания кода или подождать, пока пройдут тесты, чтобы узнать об этом. Аналогичным образом, операция C ++ «автоматический рефакторинг» типа «изменить параметры и посмотреть, что не удается скомпилировать» требует некоторой модификации в Python, если вы хотите найти все сайты вызовов.

Следовательно, вы должны убедиться, что выполняете правильный подмножество тестов, поскольку полный запуск модульного теста большого приложения Python займет гораздо больше времени, чем допустимо на этапе «компиляции» вашего текущего цикла C ++ code / compile / code / compile / code / compile / test. Но это точно такая же проблема, как нежелание перестраивать все на C ++.

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

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