Perl: лучший язык программирования

Мощный, функционально полный язык с огромным количеством настроек. Бесплатные и компактные программы интерпретации для всех платформ. Устойчивая к ошибкам программиста система + удобный встроенный отладчик. Возможность контроля за синтаксисом. Средства манипуляции базами данных и OLE объектами. Программный доступ в Интернет и работа с электронной почтой.

Заранее извинюсь перед теми читателями, которые искали учебник или краткое руководство по Перлу. Здесь я не буду рассказывать о синтаксисе языка и не приведу пример программы, печатающей знаменитую фразу “Hello, world!”. Предоставим это авторам издательства О’Райли и профессиональным technical writers. [1,2]

Эту статью первоначально намечалось написать в качестве оправдания перед самим собой - почему прикладной программист с десятилетним стажем работы на Си перешел на Перл для решения повседневных задач. Но перечитав внимательнее, я понял, что из “самооправдания” статья превратилась в эдакий манифест для широких масс. Вот так мой опус “вышел в люди”.

Итак, о чем собственно идет речь? Неужели в современной программистской среде нет лучшей альтернативы? (естественно, речь идет о программистах “широкого профиля” имеющих выбор в области языка программирования) Что дает мне Перл? В чем его недостатки?

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

Позвольте, спросит удивленный читатель, а как насчет всеми (не)любимой, но бесспорно самой массовой платформы - Windows? А так, - используется, но в основном в серверных приложениях (ну там NT, Win2K и прочая), хотя Перл безо всяких проблем работает и на стандартных редакциях “окошек”.

[3] Ну почему, спросит еще более удивленный читатель, программисты всего мира дружными рядами не ринулись строчить Win-приложения на этом языке? А причина до смешного проста: Перл - скриптовый (интерпретируемый) язык, что очень удобно в WWW, но совсем не удобно для стандартного пользователя “окошек”, уровень способностей которого обычно колеблется между умением “поставить винды” и знанием “операционной системы эксель” ;-).

В результате Перл-программа будет работать только на компьютере, где установлен интерпретатор Перла. Поэтому пользователи многочисленных клонов Юниксов охотно пользуются Перлом в своих ежедневных задачах - ведь им не надо напрягаться с установкой интерпретатора - он подобно Квик Бейсику (извиняюсь за сравнение) автоматически включается в дистрибутив системы. Да-да, я не оговорился, обыкновенные “пользователи” используют Перл - ведь он объединяет в себе синтаксис и функциональность таких базовых команд Юникса как grep, sed, awk, tr, да и самого Юникс-шелла csh.

Тут программисты на Си/Си++ сразу скривятся - интерпретатор? Но ведь это дико неэффективно! Вынужден согласиться - да, не супер эффективно, когда речь идет о Бейсике.

Но Перл сочетает в себе преимущества компилируемых и интерпретируемых языков - программа переводится во внутренний код перед выполнением (как в Java) и в то же время остается возможность загрузки и выполнения фрагментов “на лету”.

Добавьте сюда поддержку объектов, возможность подключения подпрограмм написанных на других языках (си, ассемблер), наконец огромное количество прикладных библиотек (от доступа к базам данных и платформенно-независимой графики до работы с Web: разбор HTML, посылка/прием почты, загрузка/посылка по HTTP и FTP), плюс мощнейшие встроенные функции по обработке текста - вот вам вкратце весь Перл. [4,5]

К преимуществам Перла можно отнести и Си-подобный синтаксис (с множеством удобных расширений, хотя любители чистого Си/Си++ могут их не использовать). Несколько смущает “квикбейсиковый” способ объявления переменных (то есть - никакого!) и примерно такая же “явная” типизация объектов. Но при желании эта первая “фича” может быть выключена и тогда (ну совсем как в старом добром Си) каждая переменная должна быть описана явно. А явная типизация объектов вообще очень удобна (сравните стандарты на имена переменных, диктуемые Win-API: p - pointer, s - string, b - byte).

Чтобы проиллюстрировать простоту написания программ на Перле приведу пример из личного опыта: для собственных нужд (и из-за дремучести в области UNIX) мной был написан неплохой Download Manager (как позже выяснилось - со всеми функциями WGET). Написан быстро - по принципу “2 строки вокруг одной работавшей ранее”. При этом ничем выдающимся в области программирования я не блистаю, а Интернет и сетевые технологии для меня вообще “лес густой”. И ведь работает “как часы”, так как основную задачу - разбор HTML - на Перле можно решить в две-три строки.

Другой пример - за пару-тройку ночей сляпана довольно корявая (с художественной точки зрения) игрулька для ребенка. Игрулька (написанная на скриптовом! языке) содержит (тупейшую) анимацию, активные объекты, окошко настройки и прочая и прочая. Программа спокойно работает на любом (при наличии Tk не ниже 8.00) Юниксе и на любой Windows-системе (после компиляции в один большой экзешник). При этом (из-за моей серости в программировании) не потребовалось учить все эти дурацкие Win-API, классы окон и подобную философию). Кстати и программирование “специально для Юниксов” мне не знакомо - знай себе манипулируй абстрактными событиями и окошками. [6]

Добавлю, что любой эксперимент с графикой в Перле выглядит не сложнее программы “Hello, world!” - достаточно запустить поставляемую с перл-Tk программку ptksh и мы уже “в Хопре” со всеми функциями графики и даже “историей” команд. При этом можно спокойно переносить куски кода из понравившихся примеров без боязни что что-то “завалится” и придется перезагружаться так как программа “стрельнула” по системной памяти - ведь в Перле нет понятия “выход за границы массива” или “неверный указатель”. Это свойство Перла делает его незаменимым с точки зрения простоты отладки - все скаляры, будь то данные, указатели или даже объекты классов всегда являются символьными строками, а баг в программе никогда не приводит к порче реальной памяти. В результате можно отлаживать и “доводить до ума” даже явно “нерабочие” куски.

Не стоит забывать и о таком “необычном” для российского пользователя факторе как легальная бесплатность Перла. Да-да, все вышеописанные чудеса можно безвозмездно (то есть даром) загрузить из Всемирной Паутины и пользоваться ими с чистой совестью.

Итак, перейдя на Перл я получил:

* мощный, функционально полный язык с огромным количеством надстроек, вплоть до “перегрузки операций”
* бесплатные и компактные программы интерпретации для всех платформ
* устойчивую к ошибкам программиста систему + удобный встроенный отладчик
* возможность строгого контроля за синтаксисом
* средства манипуляции базами данных и OLE объектами (последнее - только в Win)
* программный доступ в Интернет и работу с электронной почтой
* автоматизированную сборку-разборку HTML
* поддержку сокетов (для связки клиент-сервер)
* несложную и легко переносимую (Юниксы,Win,Mac) библиотеку графики - Tk

Ну ладно, скажет нетерпеливый читатель, а где же обещанные недостатки? Помимо интерпретируемости, Перл имеет еще один естественный недостаток - программа на нем всегда ОТКРЫТА. Если Вы захотите написать программу-викторину вроде “Поля Чудес” или “Миллионера”, то такую игру “взломает” любой малограмотный пользователь.

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

Кстати, сам Win-компилятор является отдельным продуктом (и небесплатным!), к которому (хакеры не дремлют) уже придуман декомпилятор. [7]

Вопросы переносимости также не решены в Перле на 100% (как почти в любом другом языке). Например, программисту в Юниксе гораздо естественнее вызвать какой-нибудь любимый grep или gfind обратившись прямо в шелл, чем искать аналогичную библиотечную (а значит - переносимую) функцию на CPAN (стандартной библиотеке Перл-модулей). В результате один такой вызов приведет к “падению” всей программы под Windows или Mac. И наоборот, стоит Win-программисту “по старой привычке” использовать функции работы с реестром, OLE-объектами и т.п., как программа становится “невыполнимой” в Юниксе.

Несомненным недостатком, вытекающим из ранее указанного достоинства, является “мягкое” отношение к ошибкам программиста. Если не включить модуль строгого контроля (а кому понравится ситуация когда компилятор то и дело требует описать переменную или “ругается” на “подозрительные” вольности с указателями), то обращение к строке как к указателю может привести к неожиданной порче соответствующей переменной. А чего стоят “отрицательные” индексы массива, адресующие массив “с конца”? Если это сделано не умышленно то программа не “завалится”, но и не пожалуется на такую вольность.

Если от прочтения последних абзацев у читателя появилось отвращение к этому языку советую перечитать начало статьи (во всем плохом есть немного хорошего и наоборот). Кстати, философия Перла не так примитивна как может показаться - стоит начать изучать этот язык и программировать на нем и у вас тут же возникнет ощущение, что “кто-то тут все хорошо продумал”. Но, впрочем, это тема для другой статьи.
Источник:webfocus.ru