Добрый день.


На данный момент существует много языков с динамической типизацией: Python, Ruby, Groovy, PHP, Perl....

Но вот я никак не могу понять - а какие плюсы дает динамическая типизация. Лично я вижу одни только минусы.

Например, сейчас использую web фрэймворк grails заточенный под использование Groovy. 

Так вот - для нормальной работы GORM (orm фрэймворк на базе Hibernate) и работы scaffolding-а в Entity классах все равно нужно явно указывать тип.

Из за динамической типизации механизм подсказок IDE сильно урезан (в сравнении с Java), так же как и проверки кода на стадии написания. 

Да и ИМХО лучше ловить ошибки на стадии компиляции (а при хорошей IDE - на стадии написания), чем во время работы программы. 




Может я чего-то не понимаю?  Покажите пожалуйста, где зарыты плюсы динамической типизации?

она удобная.

GoldFinch, 



А более развернуто можно - чем удобная? Я пока вижу только  неудобства  

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

удобство в том, что не надо писать лишний код.

Добавлено через 1 минуту и 21 секунду
сам я юзаю python+IDLE и javascript+msvs+VisualAssistX

Vasay, определённые преимущества всё-таки есть. Ленно как-то сильно расписывать. Коротенечько.

Основное, пожалуй, что нет необходимости в наличие строгих многоуровневых иерархий типов данных. Что значительно повышает т.н. скорость прототипирования. Собственно, если при работе со статически типизированным ЯП очень много времени тратится на проектирование интерфейсов, абстрактных классов, глубоковложенных иерархий и т.п., то с динамическим ЯП можно проще. Посмотри, хотя бы на те же знаменитые GoF Design Patterns. Собственно, большая часть из них - шаблонные решения по преодолению сложностей статической типизации. Эдакие проверенные временем иерархии типов данных и т.п.

В дипамичсеки типизированных ЯП практически всегда работает т.н. позднее связывание (late binding). Точнее, тут "рулит" динамический поиск и вызов метода, называемый ещё динамической диспетчеризаций сообщений (dynamic method invocation, dynamic message dispatch). Динамическая диспетчеризация сообщений лаконично вписывается в языки с динамической типизацией. Это суть т.н. утиной типизации.

Т.е. наличие некого метода у некой переменной (ссылки на объект) не проверяется на этапе трансляции. Мы не знаем, объект какого типа окажется по этой ссылке в конкретный момент времени. Но даже если б и знали, проверять наличие метода не стали бы. А во время исполнения всё просто: если у объекта по ссылке есть нужный метод (объект понимает посылаемое сообщение) - вызываем метод, нет - объект может "проглатывать" сообщения (такое тоже бывает  ), но чаще кидаем исключение. 

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

Следует отметить, что чистая прибыль от такого преимущества будет почти нулевая. Тут работает знаменитое strong static typing vs strong unit testing. То есть городить сложных иерархий не надо, а вот на unit-тестирование придётся поднажать. Где-то теряем, где-то находим. Ну и тут банально - всё зависит от задачи.

Бла-бла-бла...

Код не всегда пишешь только ты.  Если IDE не знает тип объекта, она не может тебе выдать ни ****Doc, ни списка методов. 

А такие подсказки заметно ускоряют процесс написания кода. 




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



kemiisto, 

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

Может, конечно. Но там не принято огородгородить.

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



Это сообщение отредактировал(а) Vasay - 14.5.2010, 15:30

Вот это и есть плюшка динамической диспетчеризаций сообщений. Polymorphism without inheritance. Ещё можно встретить термин ad-hoc polymorphism. Иногда с добавочкой for late bound languages. Потому как есть и ad-hoc polymorphism for early bound languages, но там несколько другой ad-hoc...

Короче, это всё очень запутанная штука.  Так в 2-х словах и не рассказать. Но вернёмся к нашим баранам.

Для примеру возьмём классы Class Vector<E> и Class ArrayList<E> из java.util. Иерархия наследования там не такая простая. Множественно наследование через интерфейсы по сути. Но что можно видеть, так это что оба класса реализуют методы интерфейса Interface List<E>. Всякие там add(), size(), clear(),...

Задумаемся, почему так? Зачем нам такая сложная иерархия с наследованием от интерфейса? Всё правильно - нам нужны эти методы и в стеке, и в списке. Мы так решили на этапе проектирования. Мы выносим эти общие методы в интерфейс, а в каждом из классов этот интерфейс реализуем. Компилятор контролирует нас на предмет реализации этих методов и далее на предмет вызова этих методов только у классов, реализующих наш интерфейс Interface List<E>.

Куда важнее, что оба класса - наследники абстрактного класса Class AbstractList<E>. Объявив в программе переменную этого типа данных, мы можем хранить там хоть Vector<E>, хоть ArrayList<E>. И вызываемые методы, хоть и с одинаковым названием, будут разные. И именно те, что нужны. Короче, полиморфизм, знаете, что такое. Такой тип полиморфизма называют inclusion polymorphism, так как переменная одного типа данных (более абстрактного) может хранить (включать) экземпляр и унаследованного типа данных. 

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

Что там будет в этой переменной одному богу известно. Там может оказаться и что-то отличное от экземпляров наших классов вектор и список. У этого отличного может и окзаться метод add()... Поэтому нужно тестировать...

Посмотрите хоть Python что-ли... А лучше Smalltalk.

Это сообщение отредактировал(а) kemiisto - 14.5.2010, 16:36

kemiisto, 

Спасибо! Теперь я понял первую часть вашего предыдущего поста. 

Пока, правда, не осознал, плюс это или минус  

Тут, как я уже говорил, зависит от задачи. Звучит банально, но это так. Посмотрите, большая часть ЯП с динамической типизацией - скриптовые. По большей части они нужны для автоматизации каких-либо рутинных операций. Скажем, хочу я удалённо по ssh логиниться на кластер, запустить сотню-другую задач, "выдрать" что-то нужное из полученных данных, закинуть это дело в табличку, построить график. Вот это самое оно для скриптовых языков. И я не хочу тут особо чего-то проектировать, городить иерархии классов, ... Не стоит оно того.

"Python, он для скриптов, а не для "взрослого" программирования." (с) Lazin

Добавлено @ 16:54

Безусловно. Никлаус Вирт солидарен с тобой, %username%  :


Это сообщение отредактировал(а) kemiisto - 14.5.2010, 16:55

kemiisto, 



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

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


Или я чего-то не понимаю, раз языки с динамической типизацией так активно плодятся?

Это уже использование не по назначению.


Ничего тут не кажется, всё очевидно.  


Сейчас в ИТ преобладает бизнес-модель: быстро пишем хоть что-то работающие -> срубаем бабло. Языки с динамической типизацией в эту схему укладываются очень неплохо. К тому же, чтоб сурбать бабло нужны громкие лозунги: dynamic web, agile development, TDD, ... А что там за красивыми словами скрывается - не суть. В общем, чего тут особо распыляться. Популярность никогда не была критерием качества.

Vasay, еще для примера, вот типизация на Си написанная, как дополнение   http://search.cpan.org/~rkitover/MooseX-Ty...MooseX/Types.pm

http://search.cpan.org/~flora/Moose-1.03/l...anual/Types.pod

http://search.cpan.org/~flora/Moose-1.03/l...eConstraints.pm


Это сообщение отредактировал(а) gcc - 14.5.2010, 18:36

man Common Lisp: весьма строгая иерархическая типизация. но при этом динамическая. и никакого огорода.

Добавлено через 2 минуты и 10 секунд

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

Добавлено через 4 минуты и 9 секунд
ЗЫ. хорошие языки в ИДЕ не нуждаются. точнее они сами себе ИДЕ... =)