Укрощение @Интернет@

       

Часть вторая. Техническая: недостатки Perl


Исторические корни языка Perl тесно сплетаются с командными оболочками UNIX. Командные оболочки всем хорошо знакомы на примере command.com, – рудименту, сохранившемуся со времен MS-DOS. Приблизительно такими же оболочками когда-то управлялась и UNIX. Вот только командный язык у последних был не в пример богаче, да и возможностей побольше, но суть та же – вместо графического интерфейса утомительная набивка однотипных команд.

Пытаясь облегчить собственную участь, юниксоиды активно использовали макросы и скрипты, перекладывая часть своей работы на компьютер. Увы, возможности языков оболочек были огранены, да к тому же несовместимы друг с другом. Энтузиасты создавали собственные языки, более удобные и мощные, но где они сейчас? Канули в вечность… Только Perl-у удалось завоевать известность, да и то в совершенно другой области – разработке cgi-скриптов.

А на это Perl не был рассчитан! Не то, чтобы он совсем не подходил для такой цели - для создания cgi-приложения можно использовать любой язык, способный читать и отправлять данные в стандартный поток ввода-вывода, например, Си, Паскаль, Бейсик... да все, что угодно, в том числе и Perl. Но между локальными и серверными приложениями есть одна принципиальная разница. Первые исполняются самим владельцем машины, который не станет сознательно причинять ей вред, а вторые обслуживают запросы клиентов со всех концов сети. В сети же в изобилии водятся злоумышленники, получающие удовольствие от нанесения чужому компьютеру тяжких информационных повреждений.

Серверные приложения должны быть спроектированы с учетом всех требований безопасности – никакой запрос клиента не должен приносить ущерба машине. Добиться этого вовсе не так просто, как кажется! Психологическая инерция, т.е. подсознательное откидывание всего, не вписывающегося в жизненный опыт, не позволяет создателю защиты обнаружить все дыры, – можно в упор рассматривать дыру, но не осознавать, что это

дыра. Вспомнить хотя бы печально известную Троянскую Лошадь – никому и в голову придти не могло, что она – не подарок вовсе, а смертоносное оружие!


Второй фундаментальный недостаток – Perl, как и любой другой интерпретируемый язык, не показывает чудес производительности и порядком нагружает процессор сервера. Компиляция "на лету", т.е. при первом запуске программы, частично справляется только с проблемой производительности, но значительно увеличивает нагрузку на процессор. Шквал запросов к какому-нибудь "прожорливому" скрипту – эффективная атака на отказ в обслуживании, и дешевой защиты против нее нет! Узким местом, ограничивающим количество одновременно обрабатываемых клиентов, чаше всего оказывается отнюдь не "толщина" Интернет - канала, а перегруженность процессора, замученного выполнением Perl-скриптов. Вот компилируемые Си\Си++ в этой ситуации ведут себя куда лучше!

Третий минус – поддержка ООП (объективно - ориентированного программирования) у Perl-а находится в состоянии глубокого зачатья. В смысле: она-то есть, но кастрированная до безобразия! Нет, это не плохо само по себе, - нельзя же в самом деле везде и всюду насаждать идеологию ООП, – процедурные языки не в меньшей мере имеют право на существование! Но в сложных проектах отсутствие ООП - объективный минус, дающий о себе знать множеством трудноуловимых ошибок, неожиданно всплывающих в самых непредсказуемых местах.

Да какое там ООП, когда Perl не поддерживает даже типизации переменных! А это развращает программиста и увеличивает вероятность появления ошибок, которые не так-то просто выловить и распознать!

Нет, сказанное вовсе не означает, что Perl плох! Но знание его недостатков никому не помешает, - не стоить строить иллюзий: уж чего-чего, а недостатков у Perl-а хватает. Да у кого их нет?


Содержание раздела