о динамических языках

[avva]

Любопытная презентация о том, почему динамически языки все еще тормозят.

Основная мысль автора: в наше время умных JIT нет никакой причины на уровне самого языка, чтобы Питон или Руби выполнялись медленнее C или Джавы; но это неизбежно продолжает происходить, потому что в динамических языках сложилась культура не считать копии объектов и для всего использовать ассоциативные массивы.

Интересная мысль, но спорная. Мне мешают с ней согласиться два соображения.

Во-первых, я поверю, что Питон выполняется со скоростью C/C++, когда это увижу. На примере серьезного размера программы, делающей что-то нетривиальное с вычислениями или обработкой большого количества данных. И желательно в официальной среде Питона, а не PyPy каком-нибудь. То же касается Руби.

Во-вторых, если представить себе такой Питон, в котором мы боимся сделать лишний split(), всем функциям, создающим большие строки, передаем готовые буферы для них, а данные типа ключ-значение не кидаем в первый попавшийся словарь, а аккуратно планируем для них класс с полями - если все это себе представить и содрогнуться, то станет неясно, зачем таким Питоном пользоваться, и почему не писать сразу на C++ (или Джаве, если хочется защиты побольше). Динамические языки типа Питона и Руби так выросли в популярности в последние 15 лет не потому, что у них динамическая типизация (Смоллток их в этом всех перещеголял, а как был маргинальным, так и остался) - а потому, что в них просто, удобно и приятно работать со строками и простыми их коллекциями. Если бояться сделать лишний ' '.join(), то мало кто захочет писать на таком Питоне.

Comments

[kot-begemot.livejournal.com]

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

[kaathewise.livejournal.com]

Ой, какая печальная ситуация... А что порекомендуете-то вместо унылого питоно-перла?

[bolk.livejournal.com]

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

[migmit.livejournal.com]

Их, по крайней мере, можно распарсить.

[javax-slr.livejournal.com]

Вот взять груви. Одно его применение - "удобная" джава.
Другое - DSL. На нем чертовски удобно делать DSL

[eterevsky.livejournal.com]

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

[kodt-rsdn.livejournal.com]

Можно подумать, на сях и жабе нельзя выучиться говнокодить за 21 день? Весь полуостров Индостан тому пример.
Только паттернв говнокода разные. И области применения тоже: какой-нибудь веб против какого-нибудь энтерпрайза или эмбеддеда. Что, в эмбеддеде мало хиндусятины?

[dmzlj.livejournal.com]

Я что-то пропустил, и JIT умеют делать с динамическими языками unboxing, удаление информации о типах и доступ к массивам без контроля границ?

[cmm.livejournal.com]

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

[huzhepidarasa.livejournal.com]

Да, V8 все это делает, насколько я знаю.

[akalenuk.livejournal.com]

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

[http://users.livejournal.com/_winnie/]

> Ну и да, никакая самая хитрая компиляция не обеспечит того же прироста, что и замена алгоритмов с логарифмической сложностью их аналогами со сложностью константной

Вроде бы интерпретаторы SQL именно про то, что бы выполнение запросов

for x in X: 
  for y in Y: 
    if x.id == y.id and y.owner == 3: 
      print x.name 

было за O(1) а не за O(N^2), более того подсказывают админу как настроить индексы

[cmm.livejournal.com]

в наше время умных JIT нет никакой причины на уровне самого языка, чтобы Питон или Руби выполнялись медленнее C или Джавы

я не знаю про наше время, но нормальные динамические языки (в том числе, ЧБСХ, тот же Смолток) выполняются вполне себе быстро уже лет тридцать.

а основной причиной всех проблем экосистемы "скриптовых" говноязычков является удивительное невежество её участников.

[migmit.livejournal.com]

В принципе, совпадает с тем, что я неделю назад писал в твиттере: "Looks very bullshitty to me. JIT used as a buzzword". В общем, тупо не верю.

[alex shayda (from livejournal.com)]

У вас ошибка в исходных:
Перл (а он "динамический") быстрее С++, а С++ конечно быстрее Джавы. (ИМХО медленнее Джавы ничего не создано пока)

[kaathewise.livejournal.com]

Перл быстрее плюсов, чо, правда? Пруф?
Питон быстрее джавы? Wuuut?

[orleanz.livejournal.com]

Питон гораздо медленне Джавы

про скорость Перла - скажите это создателям игровых движков которые их на с++ пишут, по старинке

[eterevsky.livejournal.com]

А что с PyPy не так? CPython — очень консервативный интерпретатор, я сомневаюсь, что в нём будут делать JIT. Что не значит, что питон в принципе медленный.

Насколько я знаю, из реализаций современных динамических языков самая быстрая — LuaJIT. Быстрее чем V8, во всяком случае.

А на счёт использования ассоциативных массивов где не попадя и аналогичных методов — профайлинг никто не отменял. Чтобы сделать программу быстрой, нужно сначало сделать её правильной, а потом переписать 5% самого исполняемого кода.

[ext-1684936.livejournal.com (from livejournal.com)]

Я в целом согласен с автором, но я ещё более радикален. По моему, он ошибается только в перекладывании оптимизации split(), join(), append(), etc. на писателя на языке. Эту оптимизацию должны делать сами JIT, run-time support и стандартные библиотеки.

Да, это сложно, но вполне возможно.

Я работаю в Talaria Technologies http://talariatech.com/ которая делает нечто подобное не для для Питона и Руби, а для значительно более популярного PHP.

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

[nec-p1us-u1tra.livejournal.com]

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

[asox.livejournal.com]

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

А разве питон не пытается в случае присваивания усиленно раздавать ссылки на объекты, а не копировать оные?

Во-вторых, если представить себе такой Питон, в котором мы боимся сделать лишний split(), всем функциям, создающим большие строки, передаем готовые буферы для них, а данные типа ключ-значение не кидаем в первый попавшийся словарь, а аккуратно планируем для них класс с полями - если все это себе представить и содрогнуться, то станет неясно, зачем таким Питоном

Мне почему-то кажется, что без статической типизации подобные дейсвтия будут попросту бессмысленны. Ну и, соответственно, на чём-нибудь крупном мы уткнёмся в эти самые "внезапные" прблемы.

[haiut.livejournal.com]

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

во многих случаях она предполагает short-lived programs/processes, где возиться с "правильными" структурами данных и думать об оптимальном выделении памяти есть неинтересная трата времени .. а когда культура (и с ней примеры в tutorials) сложилась, бороться с ней - дело неблагодарное.

кстати, я вполне могу поверить, что большинство простых операций JIT-компилированый код Питона может выполнять со скоростью, сопоставимой с, например, Java или C++ ..

[cema.livejournal.com]

станет неясно, зачем таким Питоном пользоваться

Именно!

[meshko.livejournal.com]

+500, удивительно, умный же мужик, а пишет глупости.

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

[angerona.livejournal.com]

если вместо питона взять МАТЛАБ, например, то вполне все быстро получается.