Почему Perl является наиболее часто используемым для записи сценариев CGI?

Во-первых, безопасность. Если вы пишете на C, вы должны быть очень осторожны, чтобы убедиться, что вся ваша обработка строк правильная, чтобы вы не вводили переполнение буфера и т. Д. На любом достойном языке сценариев кто-то уже сделал это за вас. У вас могут быть другие дыры в безопасности, но если в среде выполнения или в модуле расширения нет ошибки, у вас не будет переполнения буфера. Это преимущество не ограничивается языками сценариев; скомпилированные языки, такие как Java и C #, также предоставляют его, и его можно получить (хотя часто и труднее) в C ++ с помощью std :: string и C с хорошей библиотекой строк.

С точки зрения безопасности Perl имеет еще одну полезную функцию, которой нет во многих других системах: режим «заражения». Это предохраняет вас от слепой передачи пользовательского ввода в другие системы как части запроса к базе данных, командной строки и т.д. исполнение. Режим заражения не идеален, так как процесс восстановления зависит от правильности действий программиста, но он, по крайней мере, помогает выявлять пропущенные пути кода.

Кроме того, на данный момент Perl уже давно используется для написания сценариев CGI, поэтому уже существует большое количество библиотек, фреймворков и т. Д., Чтобы упростить написание новых сценариев. Кроме того, в CPAN есть код, позволяющий делать что угодно.

В те дни, когда CGI становился популярным, Perl был самым простым языком в использовании. Люди могли очень быстро подобрать «маленький Perl», а поскольку программа была текстовым файлом, они могли легко загрузить его и передать. С тех пор, как Perl начал свое существование как язык системного администрирования, он уже был установлен на многих серверах. Когда пришло время создать сценарий CGI на каком-нибудь хостинге, Perl, скорее всего, уже был там. Мало того, сценарий Perl практически одинаков на любой платформе, поэтому то, что вы написали локально, скорее всего, работает точно так же на другой машине.

Было быстрее программировать для «случайных программистов» в большой схеме вещей, потому что им нужно было меньше узнать, прежде чем они смогут создать полезную программу; они могли бы начать с нуля и запустить Perl-программу за час, даже если бы они просто загружали ее. Им не нужно было беспокоиться обо всем, что связано с написанием и компиляцией программы на C, а затем с ее передачей на другой хост (который может быть другой платформой).

Perl быстро закрепился, и вы до сих пор видите последствия этого. Если бы Perl сегодня начинался с нуля, я не думаю, что он обязательно победил бы что-нибудь еще. PHP, безусловно, занял первое место среди низкопробных и быстро запускаемых компаний (и для большинства из них это, вероятно, поначалу правильный инструмент).

Не повредило и то, что в Perl было много функций обработки текста. Некоторые говорят о CPAN, но этого почти не существовало, когда Perl начал привлекать внимание для программирования CGI.

Однако Perl уже не так уж важен для программирования CGI, как раньше.Он по-прежнему делает все те замечательные вещи, которые были всегда, но теперь различные другие языки догнали как по функциональности, так и по доступности и осведомленности сообщества.

Я начал программировать CGI в 1994 году и до сих пор вижу, насколько удивительно и ошеломляюще сложны большинство фреймворков. Мне очень жаль, что тогда у нас не было Seaside , потому что вы даже не знаете обо всех глупостях, которые заставляют вас делать другие фреймворки. Насколько лучше был бы мир, если бы мы все вместо этого выучили Smalltalk. :)

Хорошо, остальные ответы дали довольно веские объективные причины. Для полноты картины, вот субъективная оценка, чтобы придать ему немного окраски:

Я написал:

• Программное обеспечение CGI на чистом C (за деньги, профессионально). Это включало создание всей библиотеки CGI (это было еще до того, как библиотеки CGI стали доступны).
• Мои собственные библиотеки CGI на Perl
• Материалы CGI на Perl с использованием CPAN.

Основываясь на этом опыте, чистый C доставил наибольшее удовлетворение с точки зрения «Посмотрите на это крутое техническое достижение, которое я сделал». Тем более, что это было в те дни, когда CGI была совершенно новой, а статический HTML был основным контентом повсюду.

CGI на Perl с собственным интерфейсом был намного проще технически, чем C, из-за всех объективных причин, перечисленных в других ответах.

И проекты CPAN Perl были единственными, которые обеспечили довольно приличное время выполнения работ и позволили мне сконцентрироваться на построении бизнес-логики, а не на сантехнике.

Самым большим преимуществом использования Perl является CPAN .

В дополнение к уже упомянутым ответам, для основных веб-приложений скорость передачи по сети является более распространенным узким местом, чем выбор языка. Обычно веб-приложения писать на Perl проще, чем на C, поэтому небольшая разница в скорости выполнения не стоит дополнительных усилий, необходимых для создания приложения. На самом деле C иногда используется для определенных частей очень ресурсоемких веб-приложений.

Манипуляции со строками, часто составляющие большую часть веб-разработки, в C довольно болезненны и подвержены ошибкам, отчасти из-за отсутствия автоматического управления памятью. Имейте в виду, что часто время выполнения скрипта не является узким местом или его можно обойти с помощью надлежащих механизмов кэширования. Во многих случаях рекомендуется выбрать язык, который максимизирует продуктивность разработчика, вместо того, чтобы без необходимости жертвовать временем разработки ради повышения производительности, которое останется незамеченным пользователем сайта.

Этот общий принцип, однако, не применим в вашем случае в полной мере, поскольку поисковая система может извлечь выгоду из оптимизированного низкоуровневого кода. Однако это не означает, что вам придется делать все на C: интерпретатор PHP, как известно, очень медленный, но, поскольку большинство библиотечных функций реализовано на C, вы можете обойтись без него. Я бы рекомендовал написать приложение на языке высокого уровня по вашему выбору и повторно реализовать только те части в C, которые были идентифицированы как ошибки.

В то время, когда CGI был изобретен еще на заре Интернета, это был единственный способ выполнять какую-либо динамическую обработку веб-запросов, например отвечать на отправляемые формы или нажимать на карту изображений. Само программное обеспечение веб-сервера могло доставлять только статический контент, поэтому для обработки интерактивного материала требовались внешние программы.

Первые веб-мастера, вероятно, были также системными администраторами, которые часто хорошо разбирались в Perl. Я помню, что первые httpd-серверы NCSA поставлялись с примерами программ CGI, написанных на Perl, C и оболочке. Скрипты оболочки были отброшены довольно быстро, потому что они были небезопасными и не годились ни для чего, кроме действительно коротких программ CGI. Программы на C работали нормально, но Perl был намного удобнее.

Я предполагаю, что Perl стал фактически стандартным языком для использования с CGI по нескольким причинам:

• Системные администраторы были знакомы с ним.
• Быстрые и безопасные библиотеки стали широко доступны; модуль CGI.pm стандартно поставляется с Perl.
• Perl предлагает хороший компромисс между скоростью и простотой разработки.

Нет причин для использования Perl; подходит любой язык, который может работать с переменными среды Unix.

Тем не менее, CGI потерял популярность, потому что он очень медленный по сравнению с языками, которые работают в адресном пространстве веб-сервера, такими как PHP.

Я думаю, что преимущество использования языка сценариев состоит в том, большинство людей гораздо более продуктивны, используя динамический язык более высокого уровня, чем они используют C.

Многое. людей, кажется, беспокоит скорость, но на самом деле это нормально ... и если это действительно становится проблемой, большинство языков сценариев имеют механизм расширения, в котором вы можете писать модули на C и по-прежнему использовать их на языке сценариев более высокого уровня (например, XS в perl или pythons c-api)