Небезызвестный Стив Егге опубликовал стенограмму своего доклада в Стенфордском университете. Он затронул целый ряд вопросов, которые недавно активно обсуждались на Хабре: оптимизация программного кода, «нетрадиционные» языки программирования и др. Кроме того, для тех, кто «в теме», доклад содержит ссылки на интересные публикации по компиляции и методам оптимизации.
Ниже я постарался сделать выжимку из весьма объёмного текста. Местами с намеренно провокационными, в духе Стива, заявлениями.
Принято считать, что:
Постараемся опровергнуть эти утверждения.
История знает примеры очень хороших оптимизирующих компиляторов для динамических языков: Common LISP, Strongtalk (расширение Smalltalk с необязательной статической типизацией), Scheme, Self. Их никто не использует, они никому не известны. Как бы ни была хороша идея и даже реализация, без маркетинга она ничего не значит.
Маленькие команды исследователей добивались десятикратного прироста скорости от своих прототипов компиляторов. В то же время, Sun потратила на HotSpot VM десять лет. Никто не знает, насколько быстрыми могут быть динамические языки, если ими всерьёз заняться.
Инерция слишком велика: в маркетинг вложены большие средства. Никакой энтузиаст не сможет протолкнуть использование LISP или Haskell, или Erlang в корпорации. Миллионы программистов по всему миру не намерены изучать второй язык. Как следствие, в обозримом будущем нам остаётся довольствоваться тем, что есть. Это очень печально, но с этим придётся смириться.
Любимый аргумент противников динамических языков:
— Вы не можете переименовать метод в IDE!
— С учётом того, что эта возможность впервые появилась в среде Smalltalk, никаких проблем.
— Но он что-нибудь пропустит!
— Java IDE ошибаются не менее часто: они не всегда могут заглядывать в файлы конфигурации XML, в SQL, в строки рефлексии и т. д.
Среду разработки для динамических языков, в том числе с поддержкой рефакторинга, сделать не сложнее, чем для статически типизированных.
Код на динамических языках не всегда динамичен по своей сути. В большинстве случаев возможен статический анализ, а симуляция выполнения кода позволяет повысить точность ещё больше.
Программисты любят заниматься микро-оптимизациями, потому что это требует меньше умственных усилий, чем проработка архитектуры.
Необходимо понимать, как работает система в целом. Небольшие системы не просто легче оптимизировать — только их и можно оптимизировать по-настоящему. Таким образом, большинство разговоров о производительности — ерунда. Главное — размер системы.
Как, всё же, можно ускорить динамические языки?
Увеличение сложности клиентских приложений на Javascript приведёт к тому, что он станет одним из самых быстрых языков. Серьёзно.
Вот что случилось: с этой AJAX-революцией, в индустрии стали всерьёз пытаться оптимизировать Javascript. И это послужило толчком к серьёзным сдвигами в исследованиях по оптимизации динамических языков.
Оптимизировать динамические языки — это снова круто. Это главный вывод из настоящего доклада. Круто в том смысле, что можно получить венчурные инвестиции и гранты на исследования. Круто в том смысле, что это поможет тем, кто пишет клоны Марио на Javascript.
Если вы разбираетесь в языках программирования и компиляторах, дерзайте. В этой области полно работы, в том числе такой, до которой просто ни у кого ещё не дошли руки.
С удовольствием приму замечания и пожелания по поводу того, что ещё можно включить из оригинального доклада. Перевести целиком было бы замечательно, но более 70 тыс. знаков — для меня лично это работа на неделю минимум.
Ниже я постарался сделать выжимку из весьма объёмного текста. Местами с намеренно провокационными, в духе Стива, заявлениями.
Принято считать, что:
- Динамические языки медленные по своей природе.
- Для них нельзя создать нормальную среду разработки.
- Большие (миллионы строк) проекты на динамических языках сложно поддерживать.
Постараемся опровергнуть эти утверждения.
Маркетинг
История знает примеры очень хороших оптимизирующих компиляторов для динамических языков: Common LISP, Strongtalk (расширение Smalltalk с необязательной статической типизацией), Scheme, Self. Их никто не использует, они никому не известны. Как бы ни была хороша идея и даже реализация, без маркетинга она ничего не значит.
Маленькие команды исследователей добивались десятикратного прироста скорости от своих прототипов компиляторов. В то же время, Sun потратила на HotSpot VM десять лет. Никто не знает, насколько быстрыми могут быть динамические языки, если ими всерьёз заняться.
Языки больше не будут меняться каждые 10 лет
Инерция слишком велика: в маркетинг вложены большие средства. Никакой энтузиаст не сможет протолкнуть использование LISP или Haskell, или Erlang в корпорации. Миллионы программистов по всему миру не намерены изучать второй язык. Как следствие, в обозримом будущем нам остаётся довольствоваться тем, что есть. Это очень печально, но с этим придётся смириться.
Среды разработки
Любимый аргумент противников динамических языков:
— Вы не можете переименовать метод в IDE!
— С учётом того, что эта возможность впервые появилась в среде Smalltalk, никаких проблем.
— Но он что-нибудь пропустит!
— Java IDE ошибаются не менее часто: они не всегда могут заглядывать в файлы конфигурации XML, в SQL, в строки рефлексии и т. д.
Среду разработки для динамических языков, в том числе с поддержкой рефакторинга, сделать не сложнее, чем для статически типизированных.
Код на динамических языках не всегда динамичен по своей сути. В большинстве случаев возможен статический анализ, а симуляция выполнения кода позволяет повысить точность ещё больше.
Производительность
Программисты любят заниматься микро-оптимизациями, потому что это требует меньше умственных усилий, чем проработка архитектуры.
После окончания Вашингтонского университета я работал в компании Geoworks. В течение пяти лет я писал на ассемблере. В Geoworks мы написали целую операционную систему, библиотеки, драйверы, приложения — в общем, целую настольную операционную систему на ассемблере 8086! […]
Нам даже это нравилось в какой-то мере. У нас был Объектно Ориентиованный Ассемблер. […] Мы знали, что сможем обогнать любой компилятор — потому что тогда мы действительно могли.
Что же случилось? Geoworks обанкротился. Почему? Я сейчас, наверное, скажу то, с чем не согласится ни один бывший работник этой компании, я единственный, кто верит в это. Потому что мы написали пятнадцать миллионов строк на ассемблере 8086. У нас были отличные инструменты, одни из лучших в мире, поверьте мне. Но в какой-то момент…
Необходимо понимать, как работает система в целом. Небольшие системы не просто легче оптимизировать — только их и можно оптимизировать по-настоящему. Таким образом, большинство разговоров о производительности — ерунда. Главное — размер системы.
Как, всё же, можно ускорить динамические языки?
- Улучшения языка: опциональная статическая типизация, поддержка параллелизма.
Ни один из популярных ныне динамических языков не имеет нормальных возможностей для создания масштабируемых приложений. Потоки в них работают так, что лучше их не использовать в реальных задачах. - Улучшения виртуальной машины: сборщик мусора с поколениями, асинхронный ввод-вывод…
- Продвинутые компиляторы.
Javascript
Увеличение сложности клиентских приложений на Javascript приведёт к тому, что он станет одним из самых быстрых языков. Серьёзно.
Вот что случилось: с этой AJAX-революцией, в индустрии стали всерьёз пытаться оптимизировать Javascript. И это послужило толчком к серьёзным сдвигами в исследованиях по оптимизации динамических языков.
Оптимизировать динамические языки — это снова круто. Это главный вывод из настоящего доклада. Круто в том смысле, что можно получить венчурные инвестиции и гранты на исследования. Круто в том смысле, что это поможет тем, кто пишет клоны Марио на Javascript.
Если вы разбираетесь в языках программирования и компиляторах, дерзайте. В этой области полно работы, в том числе такой, до которой просто ни у кого ещё не дошли руки.
С удовольствием приму замечания и пожелания по поводу того, что ещё можно включить из оригинального доклада. Перевести целиком было бы замечательно, но более 70 тыс. знаков — для меня лично это работа на неделю минимум.
