Положительно, но не очень. Попробовав PHP садиться обратно за перл не хочется.
А вот PHP мне очень нравиться, хотя конечно отсутсвие централизации в разработке расширений очень плохо сказывается на понимаемости и единообразии кода.
В сравнительном плане, я бы расставил средства разработки так (по убыванию предпочтения)
PHP / ASP.Net (не буду ставить кого то выше во избежание флейма, хотя мнение имеется)
ASP
Perl
C++ CGI Application
C++ ISAPI Extension
adontz -> Re: Perl
a> Положительно, но не очень. Попробовав PHP садиться обратно за перл не a> хочется. a> А вот PHP мне очень нравиться, хотя конечно отсутсвие централизации в a> разработке расширений очень плохо сказывается на понимаемости и a> единообразии кода.
Это ты, мил человек, HTML::Mason не пробовал
<!-- Yury Kopyl aka hrg | Только взял боец гитару, сразу — видно
гармонист -->
Здравствуйте, dyattle, Вы писали:
D>Здравствуйте, artSGTU, Вы писали:
SGT>>Вот скажите мне как вы относитесь Perl?
D>Если стоит задача по работе с текстом, то очень положительно.
А с веб страничками.
да и вообще мне кажется perl морально устарел
artSGTU -> Re[2]: Perl
SGT>>>Вот скажите мне как вы относитесь Perl?
D>>Если стоит задача по работе с текстом, то очень положительно. a> А с веб страничками. a> да и вообще мне кажется perl морально устарел
Да программировать вообще не модно. Это просто люди подсели — а бросить не
могут
Здравствуйте, hrg, Вы писали:
hrg>Да программировать вообще не модно. Это просто люди подсели — а бросить не могут
Давайте без фанатизма, а?
Многие действительно хорошие вещи, о которых в других языках зачастую можно только мечтать в перл встроены, но расширять его крайне неудобно.
В тоже время в PHP пишется отдельное расширения интерпритатора (а не языковая библиотека), которое может использовать все особенности окружения (ОС, установленное ПО) и быть написано на языке удобном для конкретной задачи.
A>Многие действительно хорошие вещи, о которых в других языках зачастую можно только мечтать в перл встроены, но расширять его крайне A>неудобно.
A>В тоже время в PHP пишется отдельное расширения интерпритатора (а не языковая библиотека), которое может использовать все особенности окружения A>(ОС, установленное ПО) и быть написано на языке удобном для конкретной задачи.
Когда-то приходилось использовать из перла модули, написанные на С++. Множество поблем снимается если использовать SWIG.
adontz -> Re[4]: Perl
a> Здравствуйте, hrg, Вы писали:
hrg>>Да программировать вообще не модно. Это просто люди подсели — а hrg>>бросить не могут
a> Давайте без фанатизма, а?
Кто тут про perl что то нехорошее сказал?
a> Многие действительно хорошие вещи, о которых в других языках a> a> зачастую можно только мечтать в перл встроены, но расширять a> его a> крайне неудобно.
Например?
a> В тоже время в PHP пишется отдельное расширения a> интерпритатора (а не a> языковая библиотека), которое может использовать a> все особенности a> окружения (ОС, установленное ПО) и быть написано на a> языке удобном для a> конкретной задачи.
Например?
a> В этом смысле PHP несомненно a> рулит.
Здравствуйте, hrg, Вы писали:
a>> Многие действительно хорошие вещи, о которых в других языках зачастую можно только мечтать в перл встроены, но расширять его крайне неудобно. a>> В тоже время в PHP пишется отдельное расширения интерпритатора (а не языковая библиотека), которое может использовать все особенности окружения (ОС, установленное ПО) и быть написано на языке удобном для конкретной задачи.
hrg>Например?
Просто сравни количество расширений для Perl и PHP. Для PHP их на порядок больше.
К тому же указание типа через префикс ИМХО не удобно.
adontz -> Re[6]: Perl
a>>> Многие действительно хорошие вещи, о которых в других языках a>>> зачастую можно только мечтать в перл встроены, но расширять a>>> его крайне неудобно. a>>> В тоже время в PHP пишется отдельное расширения интерпритатора (а не a>>> языковая библиотека), которое может использовать все особенности a>>> окружения (ОС, установленное ПО) и быть написано на языке удобном a>>> для конкретной задачи.
hrg>>Например?
a> Просто сравни количество расширений для Perl и PHP. Для PHP их на a> порядок больше.
Расширений чего? Пример?
a> К тому же указание типа через префикс ИМХО не удобно.
Здравствуйте, hrg, Вы писали:
a>> Просто сравни количество расширений для Perl и PHP. Для PHP их на порядок больше. hrg>Расширений чего? Пример?
Например я хочу написать расширение, которое позволит обращаться к новой БД. В PHP я беру Си/Си++ библиотеку-интерфейс поставляемую с БД и делаю над ней PHP обёртку (простой прокси). Описываю имена фукций и параметры и... готово. Даже никах include/requare не надо — сразу пользуйся. А в перле?
a>> К тому же указание типа через префикс ИМХО не удобно. hrg>Чего не удобно?
Что есть три ($, %, @) префикса имени переменной. Такой код читать сложнее.
по читаемости совершенно не сравнимы.
Да, есть средства автоматической вставки заголовка и концовки HTML, но это лишь мелкая заплатка, а не решение. И читаемость всё равно хуже.
adontz -> Re[8]: Perl
a>>> Просто сравни количество расширений для Perl и PHP. Для PHP их на a>>> порядок больше. hrg>>Расширений чего? Пример?
a> Например я хочу написать расширение, которое позволит обращаться к a> новой БД. В PHP я беру Си/Си++ библиотеку-интерфейс поставляемую с БД a> и делаю над ней PHP обёртку (простой прокси). Описываю имена фукций и a> параметры и... готово.
PerlXS — подключай что хочешь на здоровье. И все таки — для какой БД ты не
смог найти уже готовый модуль?
a> Даже никах include/requare не надо — сразу a> пользуйся. А в перле?
Это плохо, потому что у тебя в память грузиться сразу все.
a>>> К тому же указание типа через префикс ИМХО не удобно. hrg>>Чего не a> удобно?
a> Что есть три ($, %, @) префикса имени переменной. Такой код a> читать a> сложнее.
a> К тому же a>
a> <html>
a> <body>
a> <?php print
a> $_SERVER["PHP_SELF"];?>
a> <body>
a> </html>
a>
a> и a>
a> print
a> "html>";
a> print"<body>";
a> print $ENV{"SCRIPT_FILENAME"};
a> print
a> "<body>";
a> print"</html>";
a>
Ок. Но самом по себе смешивание кода и HTML — уже плохой признак, так ты
думал, как без префиксов реализовывать такие конструкции:
${$ref}; #раскрытие ссылки как скаляра
@{$ref}; #раскрытие ссылки как массива
%{$ref}; #раскрытие ссылки как хеша
&{$ref}; #раскрытие ссылки как кода
*{$ref}; #раскрытие ссылки как typeglobe
и т.д.
или ты никогда не пользовался сложными структурами?
a> по читаемости совершенно не a> сравнимы. a> Да, есть средства автоматической вставки заголовка и концовки a> HTML, a> но это лишь мелкая заплатка, а не решение. И читаемость всё a> равно a> хуже.
аемость всё равно a> хуже.
Используй HTML::Mason — будет тебе вселенское щастье. Он кстате и под
mod_perl работает, т.е. имеет доступ к тому, к чему PHP придется писать кучу
"обвязок".
adontz -> Re[8]: Perl
a>>> Просто сравни количество расширений для Perl и PHP. Для PHP их на a>>> порядок больше. hrg>>Расширений чего? Пример?
a> Например я хочу написать расширение, которое позволит обращаться к a> новой БД. В PHP я беру Си/Си++ библиотеку-интерфейс поставляемую с БД a> и делаю над ней PHP обёртку (простой прокси). Описываю имена фукций и a> параметры и... готово.
PerlXS — подключай что хочешь на здоровье. И все таки — для какой БД ты не
смог найти уже готовый модуль?
a> Даже никах include/requare не надо — сразу a> пользуйся. А в перле?
Это плохо, потому что у тебя в память грузиться сразу все.
a>>> К тому же указание типа через префикс ИМХО не удобно. hrg>>Чего не a> удобно?
a> Что есть три ($, %, @) префикса имени переменной. Такой код a> читать a> сложнее.
a> К тому же a>
a> <html>
a> <body>
a> <?php print
a> $_SERVER["PHP_SELF"];?>
a> <body>
a> </html>
a>
a> и a>
a> print
a> "html>";
a> print"<body>";
a> print $ENV{"SCRIPT_FILENAME"};
a> print
a> "<body>";
a> print"</html>";
a>
Ок. Но самом по себе смешивание кода и HTML — уже плохой признак, так ты
думал, как без префиксов реализовывать такие конструкции:
${$ref}; #раскрытие ссылки как скаляра
@{$ref}; #раскрытие ссылки как массива
%{$ref}; #раскрытие ссылки как хеша
&{$ref}; #раскрытие ссылки как кода
*{$ref}; #раскрытие ссылки как typeglobe
и т.д.
или ты никогда не пользовался сложными структурами?
a> по читаемости совершенно не a> сравнимы. a> Да, есть средства автоматической вставки заголовка и концовки a> HTML, a> но это лишь мелкая заплатка, а не решение. И читаемость всё a> равно a> хуже.
аемость всё равно a> хуже.
Используй HTML::Mason — будет тебе вселенское щастье. Он кстате и под
mod_perl работает, т.е. имеет доступ к тому, к чему PHP придется писать кучу
"обвязок".
Здравствуйте, hrg, Вы писали:
a>> Например я хочу написать расширение, которое позволит обращаться к новой БД. В PHP я беру Си/Си++ библиотеку-интерфейс поставляемую с БД и делаю над ней PHP обёртку (простой прокси). Описываю имена фукций и параметры и... готово.
hrg>PerlXS — подключай что хочешь на здоровье. И все таки — для какой БД ты не смог найти уже готовый модуль?
Я привёл пример задачи. Подключать можно что угодно.
a>> Даже никах include/requare не надо — сразу пользуйся. А в перле?
hrg>Это плохо, потому что у тебя в память грузиться сразу все.
Это как раз хорошо. подумай сам. Два php-cgi.exe загрузят только одну копию DLL, а две программы на перле — две копии библиотеки.
a>> К тому же a>>
hrg>Ок. Но самом по себе смешивание кода и HTML — уже плохой признак,
Это нормально удобно для веба. И не в теории, а на практике, когда в статике на HTML делается дизайн, а потом в него вставляют динамические места.
hrg>думал, как без префиксов реализовывать такие конструкции:
hrg>
hrg>${$ref}; #раскрытие ссылки как скаляра
hrg>@{$ref}; #раскрытие ссылки как массива
hrg>%{$ref}; #раскрытие ссылки как хеша
hrg>&{$ref}; #раскрытие ссылки как кода
hrg>*{$ref}; #раскрытие ссылки как typeglobe
hrg>и т.д.
hrg>
hrg>или ты никогда не пользовался сложными структурами?
Есть операторы приведения типа аналогичные C++'ным. (int)ref, (string)ref и так далее.
hrg>Используй HTML::Mason — будет тебе вселенское щастье.
Ну вот сравнил и выбрал PHP
hrg>Он кстате и под mod_perl работает, т.е. имеет доступ к тому, к чему PHP придется писать кучу "обвязок".
Это что например?
P.S. А почему у тебя цитирование заново переразбивается на строчки? На большом мониторе выглядит ужасно — весь текст слева.
Здравствуйте, artSGTU, Вы писали:
SGT>Вот скажите мне как вы относитесь Perl?
Никак. Я на нем не программил и не программлю и пока не собираюсь, потому ничего сказать не могу.
Best regards, p_kolya [ http://p-kolya.narod.ru ] WinAmp сообщает: Beatles — We Can Work It Out
Здравствуйте, artSGTU, Вы писали:
SGT>А все таки на asp.net удобнее программировать чем на perl и php
HTTP это поток (stream), а в .Net этого не видно. Разные идеологии нельзя сравнивать. Тут уже дедо вкуса. Лично я поковырявшись в ASP.Net ничего особо гениального, облегчающего мой труд в разы, не увидел. Может я не там смотрел, моят я просто дурак, не способный оценить великой идеи, но как бы то ни было ответ на вопрос не однозначен.