Обсуждение

А объем кода они как меряют? А то питоновое выравнивание пробелами может существенно увеличить этот самы объем

Если уж сравнивать JIT-языки, то и Python надо брать — PyPy.

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

Ну, и что мы при этом выясним? См. http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=python&lang2=pypy

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

То, что PyPy в суровой разработке :) Но в целом уже «выходит на уровень». И при этом из всей этой кучи, пожалуй, действительно самый лаконичный. Изображение — открыть источник Изображение — открыть источник Изображение — открыть источник Изображение — открыть источник Изображение — открыть источник Изображение — открыть источник Изображение — открыть источник

У CPython'а нет JIT компилятора, потому и тормознее. А у многих JavaScript движков есть. У Питона проблема в том, что зрелого JIT компилятора не предвидится похоже в ближайшем будущем. Т.е. psycho не развивается как-то, а PyPy слишком уж исследовательский проект.

Тормознутей (и то не очень) только Ruby и SmallTalk. А вот у Руби 1.9 уже есть JIT и он уже побыстрее Питона будет. Так что тут не столько от высокоуровневости зависит, сколько от реализации. При этом выскокуровневость Питона принципиально не ограничивает возможности JIT реализации (т.е. пара JIT'ов для него есть, только незрелых).

Вероятно свою роль играет то, что автор языка (Guido van Rossum) не нацелен на оптимизацию CPython по скорости. Логика такая, что если какой-то участок программы медленный, то надо просто вынести этот участок за пределы питона в модуль, который можно писать на компилируемом языке. В гугле пытались ускорить питон, но не вышло почему-то: http://code.google.com/p/unladen-swallow/wiki/ProjectPlan#Goals

ИМХО : нужно либо всех компилированные (или JIT) версии брать, либо наоборот. а так конечно - я возьму сравнивать какой-нить Ch (интерпретатор С) с luaJIT и потом скажу "какой ужасный тормоз этот язык С" %)))

На Питоне писать и проще, и быстрее, и приятнее. А скорость исполнения очень часто не имеет значения.

У Руби 1.9 есть ВМ с байткодом (в отличие от MRI), но разве там есть JIT?

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

Быстродействие системы в целом не коррелирует с быстродействием одной опереации на отдельно взятом языке программирования. При построении достаточно сложных систем на первый план выходят архитектурные преимущества. У Пайтон основная цель языка изначально - читаемость. В этой цели он успешен. И цель достойная. Начет же JavaScript... У меня высоконагруженные сетевые приложения (требование на текущую итерацию 50тыс пользователей онлайн, на следующую 100 тыс.) Использую в основном Python, хотя есть и NodeJS. У последнего, казалось бы, все приспособлено для создания event-based асинхронного кода, и впечатляющие показатели. Но в нашей практике это не дало никаких преимуществ перед python+twisted. Наоборот.

Для Python есть библиотеки. Ядрёная числодробильня с NumPy, качественные и стабильные биндинги wxWidgets и Qt, а также множество других. Это ключевая особенность. Перечисленные выше Factor, Lua, SBCL (и другие реализации Lisp), V8 (и другие реализации JavaScript), а также реализации Smalltalk отстают, например, в плане пользовательских интерфейсов. Либо доморощенные GUI c дизайном десяти-/двадцатилетней давности, либо те же биндинги, но менее развитые, чем питоновские. Если же требуется воспользоваться в своём продукте сторонней технологией или продуктом (будь то AllegroGraph, или иной storage, whatever), то интерфейс на Python скорее всего будет, чего нельзя сказать о других вышеупомянутых языках. В случае CPU bound задач часть кода уходит в C или C++, сохраняя при этом удобный интерфейс из Питона. Применительно к .15926 я рассматривал это в details2010-10-01 (в Google Docs). В то же время, для других условий выбор языков мог бы быть иным. Например, в одном из традиционных для геймдева случаев "библиотеки не требуются, нужна удобная интеграция и порты на консоли" прекрасно подходит Lua, ничуть не менее хороший язык.

То есть смотреть нужно не на язык, а на привычки в его использования? "Численная математика -- значит фортран или Mathematica, интерфейсы -- Питон, web-разработка -- PHP", так? Тщательно выбирается тусовка, а сам язык "в приданом", и ему в зубы не смотрят?

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

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

В обратной последовательности. Сначала - насколько язык подойдёт для выражения предметной области через mini-DSL в нём. Например: Python, Ruby, Lua, ... Сразу отваливается JavaScript, в нём нет operator overloading. Затем уже полученный список фильтруется по языковым коммьюнити. Доступные возможности, потенциально доступные возможности и их maturity. Так совершается выбор.

И мотаешь, мотаешь, мотаешь его PgDn бесконечно, ага.