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

[avva]

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

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

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

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

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

Comments

[kot-begemot.livejournal.com]

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

[kaathewise.livejournal.com]

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

[darky1982.livejournal.com]

Haskell же.

[kot-begemot.livejournal.com]

Почему печальная? Это факт жизни, надо учиться с этим жить. Программирование сегодня из разряда полу-искусства прочно перешло в раздел даже не ремесла, а массового конвеерного производства. Коммодитизация-с...
А насчёт порекомендовать - так это для чего смотря. На каждую задачу - свой особый инструмент. Хотя находятся умельцы, пишущие эмуляторы x86 (ну ок, портирующие QUEMU) на JavaScript и запускающие в браузере Linux. Но это всё-таки очевидное извращение (тем и интересно).
Вот например, для написания операционных систем, к сожалению, в современных условиях только C и применяется, хотя некоторый ограниченный вариант C++ (без RTTI и exceptions) подошёл бы куда лучше.
В прикладном программировании жаба успешно додушивает плюсы, хотя кое-где плюсы всё же выживают (ну то есть там, где производительность важна).
А кое-где и на PL/SQL пишут вполне успешно - и ничего.
Вполне допускаю, что и для Питона существует своя особая ниша, в конце концов, написали же на нём целый синтетический NFS-client, и даже весьма неплохой. Ну то есть реально для работы он неприменим в силу полной тормознутости, но в качестве системы тестирования соответствия серверов стандарту 4.0/4.1 - штука незаменимая.

[kot-begemot.livejournal.com]

Вполне допускаю, что и для него есть своя особая ниша.

[bolk.livejournal.com]

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

[kot-begemot.livejournal.com]

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

[huzhepidarasa.livejournal.com]

C++ без исключений ― кастрированный язык, лучше уж C.

Вообще мне кажется, что страх перед исключениями часто иррационален.

[kaathewise.livejournal.com]

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

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

[kot-begemot.livejournal.com]

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

[kot-begemot.livejournal.com]

По-моему, у вас трудности с пониманием прочитанного. Это пройдёт с годами. Или не пройдёт.

[kaathewise.livejournal.com]

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

[kot-begemot.livejournal.com]

Я считаю что для каждого класса задач существует свой инструментарий.

[kaathewise.livejournal.com]

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

[dmzlj.livejournal.com]

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

[ly0lik.livejournal.com]

а какой NFS-client вы имеете в виду?

[kot-begemot.livejournal.com]

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

[kot-begemot.livejournal.com]

pynfs
Там, по-моему, теперь и сервер тоже есть, но его я не использовал, так что за качество не поручусь. Клиент же для тестирования хорош.

[akalenuk.livejournal.com]

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

[huzhepidarasa.livejournal.com]

1) не всякая ОС состоит только или в основном из ядра; 2) в ядре обработка устроена как везде. Например, для каждого фрейма генерируется отдельно код, отматывающий этот фрейм. Объект на стеке, требующий деструкции, создает нофый фрейм. Код отмотки ищется по IP, каковой ищется в стеке по FP и SP. Это современный способ, а есть и старинный, когда try это setjmp, throw это longjmp, а для деструктурируемых объектов есть отдельный стек с адресами деструкторов и самих объектов. Если есть еще вопросы, задавайте :) Можно и в сгенерированный код на ассемблере посмотреть и понять, как он работает. Не rocket science. Конечно, этот подход имеет свои проблемы, а у кого их нет?

[cmm.livejournal.com]

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

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

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

[cmm.livejournal.com]

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

[kaathewise.livejournal.com]

Я понимаю. Наверное, меня просто задело начало вашего комментария.

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

По опыту работы в Яндексе могу сказать, что на питоне поиск, конечно, никто не пишет, но достаточно сложные распределенные системы, требующие на порядок меньше ресурсов, - вполне. Думаю, что и в Гугле все примерно так же выглядит.

[francis-drake.livejournal.com]

Аминь.

[migmit.livejournal.com]

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