Perl-а в короната

Тази събота и неделя направихме една дъъълга разходка и мразовитата София с Павката и децата. Имахме време да си говорим за IT колкото си искаме. Това, което ми направи впечатление, че почти в един и същи момент от време, аз, Павката, Митака, Ники - лека-полека загърбваме Perl като основен език за програмиране и преминаваме към Java. Може би, защото почти в един и същи момент си сменихме работата - Павката отиде в FredHopper, аз - в Сирма. Или може би, защото е трудно да се намерят хора с Perl - все пак Java се изучава в някои университети за разлика от Perl, който се изучава в никои университети.
Аз обичам Perl! Това е едни прекрасен език с богати "изразни" средства, гъвкавост и елегантност. Не се дразня, когато познати ме питат: "Каква е разликата между Perl и PHP?". Може би доларчетата ($) пред променливите са доста странни за С/C++/C# или Java програмисти. Perl черпи сили и от CPAN - богат архив от готови модули за ежедневни (да се чете - отегчителни) задачи. Регулярните изрази в Perl са такова улеснениe, че човек трудно може да работи със символни низове по стария начин (някой спомня ли си i := i + 1 на Паскал докато пише i++?).
Защо Perl не е толкова популярен? Като човек, който е програмирал на Perl почти 5 години мога да направя няколко заключения без да рискувам да попадна в секцията "дървен философ":

• слаб обектно-ориентиран модел - трудна капсулация, никакъв шанс за полиморфизъм, труден до невъзможен reflection. Наистина, обекно-ориентирания модел на Perl 5 е лека и ефективна надстройка на процедурно-ориетирания език, но за съжеление това има и негативи. Идеалния вариант за мен е реализиран в Ruby - единично наследяване, плюс възможност за mixins. Като следствие на този пролем и ниското ниво на модуларност на кода и негово повторно използване в други приложения се свежда до нула
• неудобен механизъм за exception handling - метода с eval/die е доста тромав, а други модули създават "изтичане на памет".
• липса на удобна/свободна интегрирана среда за разработка (IDE) - заради спецификата на езика трудно може да се направи autocomplete в IDE-то, или сигурен и автоматизиран refactoring модул. Същото важи и за debugger.
• липса на лесни за употреба frameworks за разработване на уеб приложения - почти всеки разработчик е принуден да открива "топлата вода", защото трябва сам да си асеблира framework по негово усмотрение от mod_perl, CGI, Template::Toolkit и прочие. Не, че това е лошо - проблема е, че се губи възможноста се комбинират усилията и занинята на повече от шепа хора за да се направи framework, който да решава по-голям кръг от проблеми. Така весеки се бори с ежедневни проблеми, като сесии, релационно/обектна абстракция на база от данни, които със своята тривиалност отнемат възможноста за по съзидателна дейност. В последната една година активно се разработва Catalyst, който, за мое огромно съжаление, се появи твърде късно - ако беше излязъл година по-рано, си мисля, че намаше да има Ruby on Rails

Да се надяваме, че Perl 6 ще промени статуквото - това, което се задава изглежда наистина страхотно, но дали не е малко закъснял? Времето ще покаже.

~
Заради мразовитото време, Алекс беше с шапката си с пингвини!