![[info]](http://l-stat.livejournal.com/img/userinfo.gif?v=92.1){kind=small}
Кросс-пост из moscow.pm о преимуществах Perl (и динамических языков в целом).
3 февраля 2010 г. 10:54 пользователь Andrew Shitov <andy@shitov.ru> написал:
> Дано:
> Аудитория начинающих программистов, которые еще не сделали выбор
> своего основного языка.
>
> Задача:
> Показать им прелести перла.
>
> О чем бы вы сказали в первую очередь?
В своё время читал курс "Перспективные информационные технологии" в
универе и моя задача была как раз "распрограммировать" мозги
студентов, которым долго и упорно вдалбливали Java и которые просто не
умеют и не хотят мыслить другими категориями, чем те, которые приняты
в Java World.
Мои основные аргументы были:
1. "Сильная типизация" vs "Сильное тестирование".
Типа тестирование, гораздо круче позволяет уберечься от ошибок, чем
мнимый костыль под названием "строгая типизация"; при этом код при
динамической типизации _в несколько раз_ короче и проще в написании за
счёт отсутствия объявления и явной конвертации типов (вообще
приходиться ДУМАТЬ о типах и следить за ними).
2. "Динамический язык" vs "Нединамический язык".
Разбить в "пух и прах" второе, показав, что в динамических языках
возможно в принципе ВСЁ (всё что можно помыслить даже в самом
извращённом воображении)). Эти возможности позволяют целый ряд задач
решить настолько просто и красиво, для чего в Java/C# например
потребовалось бы использовать всякие хитровывернутые структуры классов
AKA "паттерны проектировния", которые зачастую являются просто
напросто костылём для языков не имеющих динамический типизации и
динамических возможностей. Т. е. вместо одной строчки пишешь 3-5
связанных классов, которые нужны проcто чтобы преодолеть ограничения
языка. Я не отрицаю паттерны как таковые, но многие из них
действительно являются просто костылями (способом выживания) для
нединамических языков.
3. Встроенные структуры данных.
Показать, что это В РАЗЫ удобнее, чем всякие C++ шаблоны (зачастую
костыль для преодоления статической типизации), несчислимые
Java-классы для работы с данными (коих МОРЕ) и т. п. В Perl всего
навсего: скаляры, массивы, хеши. Всё! Этого хватает на все случаи
жизни. И никаких библиотек классов не нужно, никаких STL и т. п. Всё
встроено в язык.
Возможность использования языка как DSL.
Отсутствие встроенных сложных структур данных в Java выражается в
обильном применении там XML для постоянной сериализации /
десериализации всяческих структур данных.
Т.е. бесконечный XML там -- это просто ещё один костыль.
Причём покажите людям: что такое сериализация / десериализация в Perl
(XML::Simple как пример) и в Java (DOM, о боже...). Причем например
в/из YAML / JSON (широко используемые в мире в Perl) преобразование в
динамических языках проходит вообще взаимо-однозначно и
взаимообратимо, очень просто и естественно. Кстати в XML нет
однозначного способа преобразования в/из встроенных структур данных Perl -- есть
бесконечное множество вариантов конвертации. Одна из причин, почему недолюбливаю
XML.
4. Высокоуровневые возможности, встроенные в язык.
Встроенная удобная работа с массивами и хэшами (push / pop, shift / unshift).
Операции, обрабатывающие массив целиком (что неимоверно сокращает код).
Встроенные в язык регекспы, что на порядок удобнее использования
всяких внешних regexp-библиотек.
5. Мультипарадигменность.
Есть в Java/C# нужно создавать классы "на каждый чих" (в результате рыхлый код с небольшой "полезной нагрузкой"), то в Perl можем использовать ООП только там, где это действительно удобно / нужно и даже использовать ФП при желании (см. Higher Order Perl).
Всё это вместе вытекает в следующее:
- РАДИКАЛЬНОЕ сокращение объёма кода в динамических языках: приведите
примеры аналогичных проектов например на Java и на Perl / Ruby /
Python. На Java это десятки и сотни мегабайт, в динамических языках --
сотни килобайт и мегабайты и крайне редко десятки (почти нет такого). Т. е. на порядок меньше.
И это для ОДИНАКОВЫХ проектов, аналогичных по функционалу.
- Код в Perl более концентрированный, интеллектуальный, осмысленный.
"Священный". Код, который может менять только человек. С ним приятно
работать. Это всегда Challenge, работа для ума. Как интересная математическая задача. Код в Java -- очень рыхлый, с низким коэффициентом функциональность / объём. Объект для бесконечного автоматического рефакторинга.
- Различие культур Perl (хакеры, "there is more that one way to do it") и Java (кодеры-индусы, которых можно собрать толпы за небольшие деньги, чтобы делать быдлокод и которые
зачастую не принимают никаких высокоуровневых решений -- тупо "кодируют" по заданной спецификации). Труд становится нетворческим, механическим. Мозги "закостеневаеют".
В общем, это было действенно. Иногда за одно занятие люди радикально
меняли своё мнение.
Собственно, по теме в основном тут:
http://despair.pp.ru/docs/Languages.ppt
UPD: Мотивация была следующая. Факультет информатики СГАУ (как бы "основной" IT-факультет нашего славного города Самары) просто "куплен" конторой, которая продвигает Java и фактически готовит будущих работников для себя. Никакие другие технологии кроме Java им не интересны в принципе и студентов ничему другому не обучают. В других ВУЗах -- в принципе то же самое.
В результате в городе Perl (Python/Ruby и иже с ними) программистов можно пересчитать по пальцам. Появилось желание что-то с этим сделать.
UPD2: Забавно, что тема вызвала так много отрицания ;) На самом деле всё как бы в несколько гротескной форме, намеренно сгущены краски, а воспринимается почему-то очень серьёзно, вдумчиво.
UPD3: На самом деле в лекциях реально расписаны и преимущества и недостатки всех вышеописанных фич. Просто в этом тексте сосредоточены лишь преимущества.
Неудивительно, что запись удалили - представляю себе, какой срач там развели.
PS. Вот за что я люблю moscow.pm - все-таки классная тут аудитория собралась. Можно спокойно без флейма обсуждать оффтопиковые технологии. Видно, что пишут люди, для которых язык программирования - не религия, а инструмент для решения задач.
И вообще там интересно всю ветку почитать.
2010-02-05 09:07 (UTC)
2010-02-05 09:37 (UTC)
2010-02-05 13:46 (UTC)
Не расшифруете?
2010-02-06 07:48 (UTC)
А много ли у нас задач для функциональных языков? Т.е. и так понятно, что они полны по тьюрингу, что написать на тих тоже можно все. Но сама степень их распространения весьма существенно ограничивает области применения. Честно говоря, за всю свою жизнь я не сталкивался с их использованием в реальных больших проектах, не связанных с GNU.
2010-02-06 09:30 (UTC)
2010-02-06 09:42 (UTC)
2010-02-05 09:35 (UTC)
но например про типизацию - "вообще приходиться ДУМАТЬ о типах и следить за ними" - и это подается как плюс? Пусть за меня компилятор думает, чем постоянно проверять "а вот число тут или неведома фигня"?
Про структуры данных - хм, вот struct как раз не хватает периодически (хэш вместо них - это конечно хорошо, но 1) эффективность 2) проверять "а не забыли ли вот такое поле положить"
Имхо писал все-таки больше фанат перла с подходом "о, вот этого в языке нет - значит оно и не надо".
Кстати, а можно пример одинакового большого проекта на Перле и Java/т.д.?
2010-02-05 10:01 (UTC)
Кроме того, можно сравнить размер мини-приложения на Prima и аналога на яве. Например, обычный "hello world", который каждые две секунды уменьшает ширину окна на 50 пикселей:
use strict; use Prima; use Prima::Application name => 'Generic'; my $w = new Prima::MainWindow( text => "Hello, world!", onClose => sub { $::application-> destroy; }, onPaint => sub { my ( $self, $canvas) = @_; my $color = $self-> color; $canvas-> color( $self-> backColor); $canvas-> bar( 0, 0, $canvas-> size); $canvas-> color( $color); $canvas-> text_out( $self-> text, 10, 10); }, ); $w-> insert( Timer => timeout => 2000, onTick => sub { $w-> width( $w-> width - 50); }, ) -> start; run Prima;Что касается типизации - она реализуема. И есть пачка модулей, имплементящих этот функционал - есть из чего выбрать в зависимости от потребностей.
Эффективность хешей? Очень высокая. Я не спорю, что в треминах структур быстрее будет вытащить *(struct_addr+field_offset), но при необходимости изменить саму структуру иногда такие бока лезут - хоть вешайся.
Далее, забытые поля. Хеш сам по себе используется, все-таки, нечасто и, как правило, в небольших скриптах. Если разговор заходит о чем-то серьезном, то тут уже надо переходить на ОО, в котором предполагается обязательная инициализация структур в конструкторе. Так что, если чего проглядел - сам себе доктор. И это приводит к "пусть за меня компилятор думает".
Ты ж вообще должен помнить мою парадигму в отношении языка: "свобода, эффективность, ответственность". По-моему, любой холивар должен остановиться на этом этапе: спорящие должны сначала определить позицию каждого в плане требований к языку. Я, как-раз, предпочту продумать какие-то моменты сам, а не следовать непонятно откуда взявшимся требованиям компилятора-интерпретатора.
Так что, в сухом остатке имею только две претензии к современному перлу: невысокая производительность и дико отставшая от жизни реализация ОО. Оба момента должны быть решены в Perl6. Вот доводки его до production-ready жду уже несколько лет. :) Вроде на эту весну обещают. А уж какие там парадигмы закладывают - это вообще праздник.
2010-02-05 10:45 (UTC)
ну вот ты в конструкторе/методах и опечатаешься где-нибудь в имени "поля" - и искать такое можно в большом коде дооолго и грустно :( (как раз по свежим впечатлениям от поиска подобного в чужом коде :( )
> и дико отставшая от жизни реализация ОО.
о, вот это я вообще не трогал, ибо грустно :(
а Perl6 "уже на горизонте", ага :(
2010-02-05 10:59 (UTC)
Хотя, кстати сказать, айфону тоже предсказывали нишевость. А результат - ...
Так что - жизнь покажет.
Опечатка в имени поля - вопрос решаемый. Ряд модулей, реализующих разные модели ОО, предоставляют возможность пре-декларации полей. Так что, опечатка, при их использовании, таки вызовет нужную ошибку, а не приведет к багу-привидению. Поэтому, опять же, считаю, что перл - это тот случай, когда надо сесть, продумать проект, выстроить его - а уже потом кодить. К сожалению, вне зависимости от языка, делают это очень и очень немногие.
2010-02-05 11:20 (UTC)
Я на Pеrl6 не смотрел пока, поэтому ничего говорить не могу.
А можешь быстрый пример кинуть, как работать, чтобы такие опечатки давали ошибку?
"сесть, продумать" - это ж хорошо, но иногда резко меняются условия - а переписывать с нуля нет времени/ресурсов...
P.s. ненавиздь к PHP - там и аналога use strict; вменяемого нет :(
2010-02-05 11:28 (UTC)
Там смотреть надо в сторону Class::* семейства, как минимум. Тут внутри перлового сообщества свои холивары ходят - что лучше, что хуже. Смотреть надо под свою конкретную задачу. Я, когда до этой темы добрался, от активного программежа уже успел отойти, поэтому сведения черпал уже на киевких воркшопах, на которые уже третий год езжу.
В стандартной поставке, например, есть Class::Struct.
2010-02-05 11:30 (UTC)
посмотрю, спасибо
2010-02-05 11:35 (UTC)
Я уже давно старый
пертеоретик. :)2010-02-06 22:15 (UTC)
class PerlHaveIt {
has x;
method do_x() {};
}
2010-02-07 08:37 (UTC)
Вариант, конечно. Только, насколько я помню, на последнем киевском воркшопе кто-то довольно нелестно отозвался о производительности муза.
2010-02-07 14:19 (UTC)
логически -муз медленней потому как что-то делает за кулисами. вопрос - медленней чего и на сколько и насколько это покрывается чистотой синтаксиса и скоростью разработки?
со злым умыслом можно затормозить все что угодно.
у нас нет професиналов на украине по перл, так То у всех закостеневшее понимание и любовь к велосипедам.
муз дает те же возможности что и ооп в перл6. роли, мета программирование. сейчас они взаимно влияют друг на друга. но на муз уже делаются серьезные проекты болееп трех лет.
2010-02-05 10:06 (UTC)
Боюсь, что в той же яве пришлось бы, все-таки, нафиг все с нуля писать. А так - экономия времени и сил. Правда, пришлось обвешать оный хак в коде километровыми баннерами "Ахтунг! ХАК! Как работает - читать в документации." ;)
2010-02-05 10:47 (UTC)
2010-02-05 11:01 (UTC)
2010-02-05 11:17 (UTC)
2010-02-05 11:21 (UTC)
2010-02-05 11:26 (UTC)
если функциональность в dll-ке, которая в комплекте - почему бы и нет? :(
Жаль, интересно узнать причины, из-за которых такой хак таки лучше оказался...
2010-02-05 11:33 (UTC)
Предполагаемые причины я и так могу назвать. Они у нас тогда вполне типичные были:
1. Время - это понятно.
2. Модуль мог использоваться в параллельном проекте. Значит надо было исключить конфликт.
3. Надо было думать о будущем обновлении версий модуля - что, в частности, и произошло.
Кстати, если не ошибаюсь, то хакать пришлось HTML::Mason. Он был нашим основным тулкитом на тот момент. Так что, п.2 - это наиболее вероятная причина.
2010-02-06 22:18 (UTC)
2010-02-07 08:41 (UTC)
В итоге, подход действительно себя оправдал. И текущую задачу решил быстро, и, при правильном отношении к жизни, помог в дальнейшем развитии.
2010-02-07 14:22 (UTC)
2010-02-05 10:13 (UTC)
2010-02-05 11:19 (UTC)
Много лет назад я плотно запал на плюсы. Потом устал от их нелогичности в ряде моментов и, в первую очередь, от неочевидностей в вопросе множественного наследования. Да и шаблоны, как костыль в силу отсутсвия динамической типизации... Но для кругозора - незаменимо. Все-таки именно плюсы в свое время сцементировали базовые принципы ОО.
2010-02-05 13:13 (UTC)
2010-02-06 07:53 (UTC)
Кстати, для перла есть биндинги на Qt. Не знаю только, насколько они качественные и в каком состоянии находятся - просто пробежался быстренько по CPAN и получил список из 3-4 возможных кандидатов.