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

Question

[iegor]

В процессе изучения Python'а возник такой вопрос в чем его преимущество его перед C, как динамического. Ну то есть, неужели дело только в том, что не надо объявлять тип переменных? Я понимаю, что Python и не задумывался как быстрый язык, но ведь объявление переменных это не такая большая работа для программиста, чтобы ради этого снижать скорость работы программы. И в догонку вопрос как, велика разница в скорости в связи с этим.

Answer 1

[Алексей Елецкий]

Преимущество у динамически типизированных языков, конечно, не в синтаксисе, а в семантике.

Благодаря определению типов во время исполнения программы сильно облегчается метапрограммирование. Очень сильно облегчается. Оно, в свою очередь, упрощает всю остальную работу.

Благодаря гибкости кода в рантайме (см. тот же duck typing) и интроспекции (анализ свойств объектов и кода) получается на порядок проще и быстрее писать универсальные алгоритмы и конструкции вроде декораторов, всяческих ORM и подобных вещей. Это сильно упрощает интерфейсы библиотек, что в совокупности ведёт к более простому коду и к плавной кривой обучения новичков.

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

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

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

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

Answer 2

[Станислав Макаров]

Во многих, даже в большинстве задач, где узким местом не является производительность интерпретатора/рантайма языка, основное преимущество одно: на динамических языках могут писать те программисты, которые не могут на статических. Не в смысле не могут выучить или не понимают, а в смысле - совершенно не хотят. Это что-то такое глубокое в сознании программиста, от чего зависит его выбор динамической/статической типизации (и соотв. языка). Я все больше убеждаюсь, что в зависимости от варианта типизации, программисты, выбравшие для себя "правильный" язык, пишут гораздо более эффективный код.
У меня, как и у того разработчика из Яндекса (по ссылке в ответе beduin01 ), слишком плохая память для разработки на динамическом языке. Я не могу держать много сущностей в своей голове, чтобы эффективно и правильно использовать динамические языки. Я привык и не могу без хоть каких-нибудь проверок на стадии компиляции (и чем больше, тем лучше).
Другие считают ограничения статической типизации идиотскими, необходимость создавать всякие непонятные "интерфейсы", чтобы поиметь абстракцию и полиморфное поведение - извращением. Они чувствуют себя легко с объектами и классами. Возможность "прикрутить" любое свойство или метод к существующему объекту вдохновляет их на нестандартные и эффективные архитектурные и инфраструктурные решения.
Видимо это действительно зависит от особенностей памяти и сознания конкретного человека.

Разумеется, есть масса технических различий, почитайте остальные ответы.

Answer 3

[beduin01]

На динамическом быстрее слепить прототип, но сложнее его дальше поддерживать.
Гляньте вот тут: dlang.ru/why-d-is-better

Comments

[iegor]

Под "сложнее поддерживать" имеете ввиду, что может не хватить скорости в дальнейшем?

[Сергей Сергей]

iegor: сложнее в том, что можно налепить слишком непонятный код с меняющейся во времени типизацией.

Answer 4

[Dimonchik]

Питон - это и есть C. Это простой интерфейс к написанным на С/С++ библиотекам.

Но Питон силен не этим. Питон силен своим Дзен. Где еще вы сможете писать Web, Desktop, Android (а в перспективе и WinPhone и iOS) приожения, зная один язык? Или, например, покодить для CUDA?

По скорости ничто не быстрее С, тут гадать нечего, всякие Java/Go приближаются и завляют, что на некоторых тестах они "как минимум не хуже", но... вот вам пятилетней давности топик habrahabr.ru/post/90942
а вот что стало реальностью только в прошлом году: speed.pypy.org и это тоже Дзен Питона

Что касается "объявлять тип переменных", вы путаете понятия, посмотрите habrahabr.ru/post/161205
в Питоне очень быстро наткнетесь на проявления строгой типизации (прочитайте из ВЕБ без decode(), например), и еще неясно, кто (Python или C) тут больший ламер

Comments

[Артур Нуруллин]

зная C# все перечисленное можно сделать

[Dimonchik]

а с Linux как быть?

[lamazavr]

mono

[AVKor]

lamazavr: А зачем?

Тем более, что это моно всегда будет отставать.

[AxisPod]

AVKor: Учитывая, что сейчас за поддержку взялась MS, велика вероятность, что догонит скоро.

[AVKor]

AxisPod: Поддержку mono в Linux?

Первый раз слышу.

Answer 5

[asd111]

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

Comments

[iegor]

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

[Станислав Макаров]

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

[asd111]

iegor: Компьютер исполняется машинный код. Компилируемые языки на выходе превращаются в машинный код, а интерпретируемые не генерируют машинный код - вместо этого программу выполняет интерпретатор, написанный на С/С++, по-командно. Из за этого возникает разница по скорости работы до 100 и 1000 и более раз. Но на простых задачах при низких нагрузках эта разница не заметна. Можете попробовать написать что нибудь простое на python и С. Визуально разницы по скорости работы скорее всего не заметите.
Зато кода на python будет меньше.

[iegor]

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

[asd111]

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

[iegor]

asd111: thx

Answer 6

[Сергей Сергей]

Кажется, все путают "динамическая типизация в ЯП" и "интерпретируемый ЯП".

Так что пусть будет 2 разновидности вопроса:
1. "Динамическая типизация лучше статической и почему?",
2. "Интерпретируемый язык лучше компилируемого и почему?".

1. Сегодня, когда спектр решаемых на ЭВМ задач очень широк, способ типизации зависит только от деталей.

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

Answer 7

[Михаил Маланюк]

Ну то есть, неужели дело только в том, что не надо объявлять тип переменных

Тип переменных (примитивов) можно и указать, это не сложно. Гораздо сложнее указывать тип объектов. Не всегда известно, с каким объектом придётся работать. В питоне мне достаточно знать, что у объекта имеется некоторый метод или поле (а можно и того не знать). В статическом языке от меня сам компилятор бы не отстал до тех пор, пока я бы не указал тип объекта. Для этого мне пришлось бы следить, чтобы все объекты наследовались от одного базового класса (что не всегда возможно), или мне пришлось бы выделять интерфейс, имплементируя у всех возможных объектов данный интерфейс. Появлялись бы ситуации, где мне пришлось бы выдумывать, как бы сделать так, чтобы явно не указывать тип, но и чтобы компилятор пропустил. Ну и где мои коллеги на С# пишут всякие dependency injection, visitor, перегружают методы, наворачивают какие-то абстракции, вводят интерфейсы, я со своим питоном просто проверяю, есть ли свойство через hasattr(), или узнаю тип через type(). Так что, сила питона в интроспекции и рефлексии.

Answer 8

[Владимир Мартьянов]

Разницу в скорости можно посмотреть тут: benchmarksgame.alioth.debian.org/u64q/compare.php?... но я не думаю что проблема в динамической типизации, скорее в том что питон не компилируется в нативный код.

Answer 9

[Oleksiy Chechel]

Как по мне, преимущество интерпретируемых перед C вот в чем (js, питона не знаю):

var obj = {
    a: 10,
    b: "Hello",
    c: true,
    d: {
        e: {
            f: 10000
        }
    }
}

obj.a = "user";
obj.b += " world";
obj.b.x = obj.d.e.f;
obj.b.x++;
console.log(obj.b, obj);

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