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

9

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

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

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

dynamic-typing static-typing Эрик Реппен
источник
5
Ответ - «Да». Каждый тип языка - в действительности каждый язык - имеет свои сильные и слабые стороны и поэтому лучше подходит для некоторых задач, чем для других.
ChrisF
Интересно, что вы используете C в качестве примера, так как это своего рода наиболее слабо типизированный язык, который вы могли бы придумать, и при этом называть его статически типизированным. C не быстрый из-за системы типов, проверки типов происходят во время компиляции. C работает быстро, потому что существует мало или нет мер безопасности и проверок, которые не позволяют вам выстрелить себе в ногу. и потому что он компилируется в собственные двоичные файлы.
Сара

Ответы:

10

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

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

Мейсон Уилер
источник
3
@Erik: Я не уверен, что я бы даже сказал это. Вещи меняются в процессе разработки. Требования могут измениться, или вы обнаружите, что вы не выполняете требование правильно, и код необходимо обновить. Возможность изменить одну вещь и использовать полученные ошибки компилятора, чтобы показать вам, где найти все остальное, что необходимо изменить, дает огромный импульс удобству и скорости разработки, которые вы теряете в языках, где эта техника недоступна. Это одна из причин, почему вы просто не видите сложные приложения, разработанные на динамических языках.
Мейсон Уилер
9
@ Мейсон Уилер: Очень хороший ответ. + 1 Я бы добавил, что статическая проверка типов также помогает быстрее находить ошибки, проверяя корректность типов при проверке компилятором. Например, вчера я отлаживал 200-строчную программу Ruby, и было две ошибки, связанные с типом, которые я мог обнаружить только при запуске программы. Я не хочу думать, что происходит в проекте с 100000 строками. Таким образом, динамическая типизация дает вам больше гибкости, что хорошо в описанных вами контекстах по той цене, что вы не можете найти определенные ошибки во время компиляции. Таким образом, статическая типизация связана не только с эффективностью, но и с правильностью.
Джорджио
1
@MasonWheeler Два года и гораздо больше C # и Java, чем я рассчитывал позже, я бы сейчас не согласился с парой вещей. Сложные веб-приложения полностью созданы на динамических языках. Компиляция против времени выполнения не имеет смысла, когда вы можете вносить изменения, которые видны сразу. И у меня сложилось мнение, что все суеты над типами имеют гораздо больше смысла в процедурном языке, чем в языке, который должен управляться ООП, где данные не должны постоянно переходить из рук в руки.
Эрик Реппен
1
@Erik: * wince * Во-первых, оценивать статическую типизацию как концепцию с помощью Java - все равно что оценивать автомобили как концепцию с помощью Пинто. И, во-вторых, все, что изменения могут быть «видны немедленно», по определению не является очень сложной программой, потому что даже с современным оборудованием сложные программы занимают достаточно много времени для подготовки кода, будь то компилятор или интерпретатор ( или JIT-компилятор) делает подготовку. Даже самые впечатляющие веб-приложения, как правило, являются очень простыми программами, поддерживаемыми очень сложными базами данных, что совсем другое дело.
Мейсон Уилер
1
Способность создавать сложные абстракции ортогональна наличию статической или динамической системы типов, а также ортогональна скорости. Существуют системы статических типов, которые допускают невероятно мощные (хотя иногда и загадочные) абстракции. Наличие изменений, которые появляются мгновенно, также не зависит от системы типов: вы, безусловно, можете создавать интерпретаторы для статически типизированных языков.
Rufflewind
4

Я смотрю на это так: если вы можете работать естественным образом в статически типизированном языке, тогда стоит использовать статическую типизацию. Как правило, целью системы типов является предотвращение выполнения операций с неопределенной семантикой, например (string) "hello" + (bool) true. Наличие дополнительного уровня безопасности, препятствующего выполнению этих операций, может стать хорошим способом предотвращения ошибок в вашем коде даже без обширных модульных тестов. То есть безопасность типов обеспечивает еще один уровень уверенности в семантической корректности вашего кода.

Но системы типов очень трудно понять правильно. Я не считаю , что это идеальный тип системы в природе на момент написания этой статьи. (Под «совершенной системой типов» я подразумеваю систему строгих типов, которая не требует подробных аннотаций кода, которая не генерирует ложноположительных ошибок типа и чьи ошибки типа легко понять программисту.) Кроме того, она может Трудно понять действительно хорошие системы типов, которые существуют. Когда я изучал Haskell, я не могу сказать вам количество неясных ошибок типов, которые я получил, пытаясь написать то, что выглядело (для меня) как правильный код. Обычно код на самом деле не был корректным (что говорит в пользу системы типов), но это заняло много времениработы, чтобы понять сообщения об ошибках от компилятора, чтобы я мог исправить основные проблемы. В ОО-языках вы можете в конечном итоге подумать: «Этот аргумент должен быть противоречивым с типом ввода, а не ковариантным!», Или (более вероятно) возвращаться к типам типов для выхода за пределы системы типов. Системы типов могут оказаться намного сложнее, чем вы думаете.

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

Эйдан Калли
источник
Модульные тесты WRT, я полностью согласен. Вы всегда видите, как люди говорят: «Если у вас есть хорошие модульные тесты, они могут проверить правильность типа для вас». Это всегда напоминает мне о том, как Пол Грэм (который твердо верит, что динамическая типизация всегда полезна) говорит, что язык, заставляющий вас вручную выполнять работу компилятора, потому что это некорректный язык. Сорта заставляет вас остановиться и подумать ...
Мейсон Уилер
Я думаю, что многие из опасений по поводу «опасностей» динамически типизированных языков не учитывают то, как мы пишем эти вещи. Многое из Python и JS может быть написано в стиле консоли. Винтовая компиляция и время выполнения, я могу попробовать прямо сейчас и посмотреть, что получится. Однако я думаю, что вы подошли к одному очень хорошему моменту. Ничто не делает меня более безумным в веб-разработке на стороне клиента, чем когда все якобы хорошие поставщики браузеров дают сбивающий с толку пропуск ужасного кода, в то время как IE6 или 7 делают неожиданное, которое должно сгореть, когда это нужно, а не просто, ну ... сосать более типичным способом.
Эрик Реппен
Типы несоответствия @ mason-wheeler - это триальные ошибки, и дело не в том, что динамические языки не проверяют типы, это просто во время выполнения. По моему опыту, большинство статических языков имеют одинаковый уровень охвата модульных тестов, они не теряют никаких тестов из-за того, что компилятор проверяет их типы заранее, а динамические языки не должны добавлять специальные тесты для проверки типов. , среда выполнения проверяет ваши типы, если ваш модульный тест покрывает ваш метод, он их поймает.
jbtule
4

Это разные инструменты, но дело не в производительности. Все дело в сложности .

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

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

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

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

Смотрите здесь для получения более подробной информации: https://softwareengineering.stackexchange.com/a/105417/17428

Eonil
источник
1
«Динамические языки обычно подходят для небольших (я имею в виду очень маленьких) программ». По моему опыту, вы можете использовать динамические языки и для приложений среднего размера (и, конечно, есть люди, успешно использующие их для больших приложений). Я согласен, что чем больше становится кодовая база, тем больше вы можете извлечь выгоду из статических проверок, предоставляемых статическими языками.
Джорджио
2
@ Джорджио Ну, это может быть потому, что я зависим от статической проверки. Это так мило для меня, и я буквально не могу жить без них даже в небольших масштабах: p
Eonil
Я вижу преимущества статических языков (и я проголосовал за ваш ответ). Недавно я использовал Python и Common Lisp, и я признаю, что на практике вы получаете хорошие результаты, если используете чистый дизайн и, особенно в Python, если вы пишете достаточно тестов. Эти языки могут быть очень эффективными для создания прототипа, который затем можно легко превратить в ваш производственный код. Но, да, для более сложных проектов я хотел бы получить как можно больше помощи, поэтому я предпочитаю статический язык.
Джорджио
1

В настоящее время я программирую на языках статического типа (C # и F #), но мне нравится программирование на динамических языках (Smalltalk, Ruby). Есть много плюсов и минусов, которые люди связывают с одним типом против другого, которые больше связаны с языком, чем когда вы применяете типы. Например, динамические языки обычно имеют более чистый и более лаконичный синтаксис, однако F # и OCaml с их системой вывода типов имеют такой же чистый синтаксис, как и любой динамический язык. А со статической типизацией у вас есть реальное автоматическое рефакторинг и автозаполнение, но Smalltalk с его полным исходным кодом в базе данных и каждым методом, скомпилированным отдельно, был первым языком, который действительно имел серьезные автоматизированные рефакторинги, и он работал отлично. В конечном счете, современные динамические и статические языки сегодня безопасны от типов, что является наиболее важным аспектом вашей системы типов,

jbtule
источник
Иногда я подозревал, что статическая типизация - это лишь малая часть того, что делает язык более или менее гибким. Я думаю, что я также начинаю осознавать, что многие разработчики предпочитают удобный набор направляющих, а не свободный выбор для выполнения нелепо опасных вещей, таких как перегрузка операторов. VS заставляет меня иногда хотеть пнуть щенков, но мне определенно было любопытно F #, и то, что вы сказали об этом, заставило меня еще более любопытно. Я предполагаю, что это нечто большее, чем просто C #, где вы можете неявно приводить к более инклюзивному типу.
Эрик Реппен
@erik, О, да, это больше, чем имплицитная типизация и var: F # Вывод типа
jbtule
-1

Сейчас 2015 год, который добавляет некоторые интересные фрагменты к разговору:

  1. Существенные части корпоративного бэкэнда рассматривают или начинают использовать Python (динамический) вместо Java (строгий статический)
  2. Мир корпоративного интерфейса видит такие вещи, как AngularJS v2, основанный на TypeScipt: типизированном расширении Javascript.

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

Совершенно иронично: интересно, встретятся ли они посередине или устремятся мимо друг друга с звуковым бумом крайнего срока, проходящего через ...? ;)

Кизил Массон
источник
Если вы не предоставите никаких доказательств, я бы сказал, что в худшем случае бэкэнд-мир переходит на Go, но не дай бог всяких динамических скриптов. Миф о том, что у статического языка программирования всегда много церемоний, давно развенчан с помощью более мощных систем логического вывода и надежных реализаций REPL
Ден
В больших масштабах используется множество динамически набираемых серверных частей. Джанго, в частности, очень популярен в журналистике и работает в бэк-эндах Нью-Йорк Таймс, Гардиан и Вашингтон Пост. Walmart работает на узле. Единственный миф - идея, что вы не можете писать для масштаба без статических типов. И после того, как я потратил некоторое время на размышления о некоторых бедствиях унаследованного кода Java, с которыми я столкнулся, я думаю, что людям, которые чувствуют себя комфортно, лучше для этого, работают ли они со статической или динамической.
Эрик Реппен
Действительно, я предпочел бы иметь опытную команду Python для моего крупного корпоративного проекта, а не плохой Java. Просто чтобы прояснить мою позицию: я опубликовал приведенный выше ответ в качестве оценки
Корнел Массон
На самом деле, я предпочел бы иметь опытную команду Python для моего крупного корпоративного проекта, а не плохой Java. Просто чтобы уточнить: я опубликовал приведенный выше ответ в качестве наблюдения за тенденциями, которые я вижу в своей клиентской базе, отраслевой сети и общих исследованиях. Традиционно строгий бэкэнд подразумевает меньшую строгость, традиционно более свободный фронт, больше. Это даже не мнение о том, что является «правильным» (если оно есть) - не уверен, почему я получил отрицательный голос. Возможно, ирония потеряна ...
Корнел Массон