perl vs php
Если меня Alone c 2NetFly дополнят
1. В php нельзя получить информацию с SDTIN'а. На перле можно сделать оболочку для пхп а наоборот нельзя.
2. В перле есть срезы массивов (массив через массив). В php нельзя задать массив как (1 .. 10).
3. При аплоаде файла его нельзя получить в переменную. Нужно обязательно сохранить в файл в /tmp, а потом с диска
прочитать (уроды).
4. Встроенные регулярки. =~m/ ... / возвращает массив.
5. В пхп нет таких функций как map и grep. В перле функции с подобным синтаксисом можно определять самому.
6. Огромное число готовых модулей, многие из которых написаны полностью на перле (важно для халявного хостинга).
7. Perl не смешивается принудительно с хтмл.
8. tie. Одно из применений, связывание потоков.
9. Экспорт переменных и создание их синонимов *{"$pack_name".'::'."$var_name"}=$value
10. В перле нет тупой встроенной реализации сессий, как в пхп.
11. В перле есть анонимные функции и их непосредственный вызов как sub{ ... }->().
12. AUTOLOAD и $AUTOLOAD.
13. Регулярки компилятся при компиляции скрипта или через qr/ ... /.
14. DBI/DBD.
15. Конструктор не обязательно должен совпадать с именем класса. Объект создается через bless.
16. Безопасное выполнение через eval{ ... }.
17. Кстати, php ни чем не лучше C.
18. PERL позволяет использовать две из встроенных функций в качестве леводопустимых выражений, это функции substr и keys.
19. goto ($SomeLabel1, $SomeLabel2, $SomeLabel3) [$i]; goto &SomeFunction();
20. Константа __PACKAGE__ позволяет не привязываться к имени пакета.
21. Документирование с помощью =head<1,2> =cut
22. Возможность изменять переданный аргумент без ссылки на него sub{ $_[1]='1000'; }.
23. Возможность переопределения $SIG{'__DIE__'}, $SIG{'__WARN__'}
imho
не смог удержаться и не ответить..
Заодно и узнаем кто на чем пишут, что думаю будет весьма интересно..
1. Чтобы все стало понятно небольшое пояснение, php создавался специально под веб, перл в помощь сис админу работа с строками. как то так :)
что касается: "SDTIN" полагаю stdin имелся ввиду то, то тут думаю никаких проблем:
$in=fopen("php://stdin","r") or die();
и про оболочку тоже не вижу сложности.
2. мне не очень ясен вопрос:
возможно этот линк снимет все вопросы:
http://www.php.net/manual/en/language.types.array.php
3." При аплоаде файла его нельзя получить в переменную. Нужно обязательно сохранить в файл в /tmp, а потом с диска
прочитать (уроды)."
Тоже интересная притензия.. фаил сам сохрянется, в какой то временой дериктоии, и в дальнейшем одной функцией копируется куда нужно.
т.е тебе не надо его удалять после копирования из этой дериктории, в итого конечная цель при аплоуде скопировать фаил на сервер. вот код чтобы все было наглядно:
$store_dir='/pub/home/programm/htdocs/incoming/';
if (!$userfile) {
?>
<input type="file" name="userfile">
<input type="hidden" name="MAX_FILE_SIZE" value="2000000">
<input type="submit" value="Отправить">
</form>
<?php
}
else {
if (is_uploaded_file($userfile)) {
move_uploaded_file($userfile, $store_dir.$userfile_name);
print "Файл отправлен
\\n";
}
else {
print "Ошибка, файл не отправлен
\\n";
}
что тут собственно смущает ?
4."Встроенные регулярки. =~m/ ... / возвращает массив."
в пхп с регулярными выражениями никаких проблем( но по роботе со строками перл всетаки мощней, он под это делался, ну а пхп под веб):
http://ru2.php.net/manual/en/ref.pcre.php
http://ru2.php.net/manual/en/ref.regex.php
5. поясни
6. http://pear.php.net/packages.php
думаю вопрос отпал :)
7. "Perl не смешивается принудительно с хтмл." но это скорее достоинство пхп, он умеет смешивать. ,хочешь можешь не смешивать, это право программист.
8. поясни.
9. поясни
10. Чем же тупая реализация сессий в пхп ? очень мощный механизм!
11. В чем приемущество ? поясни
12-23 поясни в чем тут приемущиства и какое это имеет отношение к пхп
Рекомендации к ознакомлению:
http://forum.ru-board.com/topic.cgi?forum=31&topic=0770&start=80
http://www.dklab.ru/work/php2perl.html
http://sitemaker.ru/forum/showthread.php?threadid=700&perpage=15&pagenumber=1
Вопрос поставлен некорректно. У каждого языка есть назначение. Я пишу на всех перечисленных. Все зависит от задачи.
PHP неплох для реализации задач низкого и среднего уровня сложности. Но из-за своей слабой производительности, молодости (как следствие несовершенности) он очень редко применяться в серьезных промышленных разработках.
в пхп с регулярными выражениями никаких проблем( но по роботе со строками перл всетаки мощней, он под это делался, ну а пхп под веб):
В PHP есть перловские функции для работы с регулярными выражениями. Ларри подарил ;=)
3. При загрузке файла не обязательно нужно сохранять его на сервере. Пример: пользователь загружает рисунок, но перед тем, как сохранить его, нужно удостовериться, что файл является рисунком, а не, например, текстовым файлом. Теряем в скорости.
5. А что тут пояснять? Например:
foreach my $num (@nums) {
push(@chars, chr($num));
}
можно записать как (при этом получив выигрыш в производительности):
@chars = map(chr, @nums); #perldoc
C grep дела обстоят еще лучше.
7. Как раз Perl может смешиваться, когда захочет (ЕрроросТуБраузер и все дела ;=), а PHP делает это принудительно.
13. Можно скомпилировать регулярно выражение и 1000 раз использовать скомпилированное в цикле (получаем существенный выигрыш в производительности).
16. Можем выполнить блок кода и перехватить все исключительные ситуации.
Теперь немного от себя. PHP – язык, предназначенный исключительно для веб программирования. Потоки, треды, обработка сигналов, запуск внешних приложений, каналы, да и вообще межпроцессорное взаимодействие – все это не реализовано, или реализовано настолько криво, что вообще хочется в него плюнуть =) Гостевые книги, форумы, простенькие системы управления контентов для не особо посещаемых сайтов – это да, PHP здесь пригоден. Но для всего остального.. Я когда увидел биллинг на PHP – очень долго плакал ;=)
Не советую читать каки ;=) Во-первых, сравнивается 3 версия PHP, во вторых, человек который пишет такое:
"Базы данных. Чтобы обращаться к базам данных, нужно использовать модули, многие из которых имеют просто феноменально большой размер, что, конечно, сказывается на быстродействии. А в PHP поддержка БД встроена. Имеется практически полный набор функций для работы с почти всеми известными человечеству базами данных. На все случаи жизни."
"Пожалуй, все. Всего два крупных недостатка, но каких..."
Кроме жалости ничего не заслуживает ;=) Куда уж там перловской DBI, с ее реальной поддержкой практически всех существующих БД, до 5-7 баз, поддерживаемых PHP. Печально.
По поводу системных вызовов... очень даж не плохо они в пхп реализованы...
То что С лучше пхп это еще вопрос, но на эту тему спорить не стану, т.к. сам С очень люблю...
Языки использующие CGI были созданы не для создания динамических сайтов -> в них отсутствуют некоторые инструменты полезные для создания именно веб приложений...
По поводу создания больших приложений на пхп: легко.... лично сам писал систему складского учета на пхп.... тот кто скажет что я ламер после этого, что такие вещи на пхп не пишут те см. рис.1. Не знаете не говорите.
Перл с бд работает хуже чем пхп. Пхп работает хуже в среде ОС. Это факт и утверждать обратное бессмысленно.
Насчет того какие функции есть у Перл какие у пхп: сторонникам перла предлагаю всеже ознакомиться со списком функций пхп.
Если пхп установлен модулем Апача, то почти все CGI приложения проигрывают в производительности, да еще и создают доп нагрузку на сервер. К сведению одно запущенное CGI приложение открывает на сервере процесс, который в ОП занимает примерно 1,5 - 2 мб.
на самом деле это не все отличия и и скать их ИМХО глупо.... Это все равно, что спорить о том, что лучше C Builder или Visual C.... ИМХО!
Тракторы очень даже неплохо летают ;=)
То что С лучше пхп это еще вопрос, но на эту тему спорить не стану, т.к. сам С очень люблю..
Есть очень хорошее ввыражение: не нужно сравнивать хер с пальцем.
Языки использующие CGI были созданы не для создания динамических сайтов -> в них отсутствуют некоторые инструменты полезные для создания именно веб приложений...
cpan.org
По поводу создания больших приложений на пхп: легко.... лично сам писал систему складского учета на пхп.... тот кто скажет что я ламер после этого, что такие вещи на пхп не пишут те см. рис.1. Не знаете не говорите.
Во-первых, сложные приложения называются сложными именно потому, что их не легко писать. Во-вторых, у нас представления о сложных приложениях расходятся ;=)
Перл с бд работает хуже чем пхп. Пхп работает хуже в среде ОС. Это факт и утверждать обратное бессмысленно.
Круг квадратный. Это факт и утверждать обратное бессмысленно.
Насчет того какие функции есть у Перл какие у пхп: сторонникам перла предлагаю всеже ознакомиться со списком функций пхп.
Ну найди, попробуй, grep и map ;=)
Сторонникам PHP советую пяток лет пописать на перле, пару лет на PHP, а затем выражать свое авторитетное мнение.
Если пхп установлен модулем Апача, то почти все CGI приложения проигрывают в производительности, да еще и создают доп нагрузку на сервер. К сведению одно запущенное CGI приложение открывает на сервере процесс, который в ОП занимает примерно 1,5 - 2 мб.
О mod_perl слышал? А о FastCGI? Видимо, нет. Даже если PHP установлен модулем, он проигрывает мод перлу по производительности все те ж 20 раз.
на самом деле это не все отличия и и скать их ИМХО глупо.... Это все равно, что спорить о том, что лучше C Builder или Visual C.... ИМХО!
А я всю жизнь думал, что С - это не объектно-ориентированный язык и существуют Visual C++ и C++ Builder. Заблуждался, видимо ;=)
преодолев низменные инстинкты хочу все-таки поправить тебя, убери "он проигрывает мод перлу по производительности все те ж 20 раз" иначе я попрошу примеры статистики или кодов(но таких чтобы в коде php небыло что то типа sleep(20) :D )
так как я видел статистику и там они почти равны...
хотя во всех этих тестах есть одна проблема...
То что 1 скрипт выводит в 10 раз быстрее хелло ворд это еще не значит
что язык 1 языка быстрее 2 :)
И все-таки я не соглашусь что на php нельзя написать что то сложное
(например биллинг) тем более по роду деятельности я видел много
биллингов написанных на perl,php, java а один из самых крупнейших
биллингов в инете (ibill) вообще написан на asp(ну или что то вроде
этого)
2Lsd[52r]
то что cgi-преложения обычно проигрывают mod это верно только причем
тут perl и php?
Например из-за проблем с правами в apache v.<2 php часто ставят как cgi
...Перл с бд работает хуже чем пхп...
А вот можно пример?
уж больно мне интересно на каких данных основывается это утверждение
:)
2Joker
пример grep
opendir (dir,".");
for ( grep { (-f "$_") or (/^asdf_/) } readdir(dir) )
{
выведет из текущего каталога только файлы и только начинающиеся с ^asdf_
}
closedir(dir);
если нет альтернативы это плохо :(
и еще
в perl
$aaa=\&asd; # ссылка на функцию
&{$aaa}(....);
в php (насколько я понял из документации)
$aaa=&asd(); # ссылка на результат возращенной функцией
а вот как хранить в переменной сслку на функцию? и так чтобы без eval-а
2Joker
пример grep
opendir (dir,".");
for ( grep { (-f "$_") or (/^asdf_/) } readdir(dir) )
{
выведет из текущего каталога только файлы и только начинающиеся с ^asdf_
}
closedir(dir);
если нет альтернативы это плохо :(
и еще
в perl
$aaa=\&asd; # ссылка на функцию
&{$aaa}(....);
в php (насколько я понял из документации)
$aaa=&asd(); # ссылка на результат возращенной функцией
а вот как хранить в переменной сслку на функцию? и так чтобы без eval-а
1) я вот одного не понимаю если говорить про grep почему бы не воспользоваться system ? (и подобные задачи решаются без проблем)
2) Зачем в переменной хранить ссылку на фуцию ?
2NetFly
>Как раз Perl может смешиваться, когда захочет
>(ЕрроросТуБраузер и все дела ;=), а PHP делает
> это принудительно.
что значит принудительно хочешь смешивый хочешь нет.
> "он проигрывает мод перлу по производительности > все те ж 20 раз"
Давайте устроим тест, так говорить без тестов что одно быстрее другово меня не сколько не убеждает, пока все то что я видел, говорит об обратном что пхп поживей порой.
> что касается что на пхп нельзы писать крупные
> проекты, это субъективно..
Это вообще не аргумент, я не вижу что может мешать пхп не использовать для крупных веб проектов.
Единственное с чем согласен:
что в php плохо реализованы системные вызовы, в частности работа с процессами.
хотя ситуация меняется:
http://ru.php.net/manual/en/ref.pcntl.php
а Линкольн круче Лимузина (потому что так президента завали) а Трансформер побьет Макрона (потому что х.з.)
а Perl круче PHP (потому что у разработчиков которые юзают Perl ... длиннее) а на PHP
крупных проектов не делается и вообще он для лохов и.т.д.
Коллеги, это называется [COLOR=red]ФЛЭЙМ[/COLOR].
Нужно заниматься своим делом, не пальцавать на дела которыми занимаются другие и будет всем счастье и мир, блин, во всём мире.
2NetFly
преодолев низменные инстинкты хочу все-таки поправить тебя, убери "он проигрывает мод перлу по производительности все те ж 20 раз" иначе я попрошу примеры статистики или кодов(но таких чтобы в коде php небыло что то типа sleep(20) :D )
так как я видел статистику и там они почти равны...
хотя во всех этих тестах есть одна проблема...
То что 1 скрипт выводит в 10 раз быстрее хелло ворд это еще не значит
что язык 1 языка быстрее 2 :)
И все-таки я не соглашусь что на php нельзя написать что то сложное
(например биллинг) тем более по роду деятельности я видел много
биллингов написанных на perl,php, java а один из самых крупнейших
биллингов в инете (ibill) вообще написан на asp(ну или что то вроде
этого)
Ладно, будем копать глубже. Выше была ссылка на статью, которую я критиковал. Несмотря на некомпетентность автора, в некоторых аспектах он был прав: например, пустой цикл в пхп работает в надцать раз медленнее, чем аналогичный в Perl. Как обосновать? Делаем цикл с несколькими миллионами итераций. Даже HiRes таймер не понадобиться. Далее, регулярные выражения: здесь PHP существенно проигрывает перлу в скорости, ибо отсутствует возможность их компиляции. С конструкциями выбора дела обстоят лучше: перл обгоняет PHP всего в 4 раза. Можно продолжать, но этого, для начала, хватит.
Имеем вот что: основные конструкции языка PHP работают медленнее аналогичных конструкций Perl. Т.к. они основные, они чаще всего используются в программном коде и модулях. Выводы сделать не сложно.
Теперь о mod. Думаю, почему mod дают существенный выигрыш в производительности, никому рассказывать не нужно. Так вот, mod_perl встраивает Perl в Apache, mod_php, не сложно догадаться, PHP. Скорость обработки скритов, написанных на разных языках, увеличивается практически одинаково (Тим Кинг называл цифру 4-20). Но, встраивание PHP в сервер не избавляет интерпретатор от кривости – он как компилировал код, который работает медленнее перловского, так и компилирует, только теперь всего 1 раз. Как вывод: выигрыш mod_perl у mod_php такой же, как Perl у PHP.
Единственное с чем согласен:
что в php плохо реализованы системные вызовы, в частности работа с процессами.
хотя ситуация меняется:
http://ru.php.net/manual/en/ref.pcntl.php
Прошу заметить, не только системные вызовы, но:
- обработка сигналов
- fork
- треды
- каналы (pipe)
- Sys V IPC
Т.е. для системного программирования и интеграции частей системного программирования в ввв, PHP вообще не пригоден.
FreeBSD 4.8, Apache 1.3
#!/usr/bin/perl
print "Content-type: text/html\n\n";
$start = time();
for ($i = 0; $i < 10000000; $i++) {}
print time() - $start;
<?php
$start = time();
for ($i = 0; $i < 10000000; $i++) {}
print time() - $start;
?>
Perl : 3
PHP : 8
Это, учитывая то, что PHP громко кричали о том, что они исправили проблему пустых циклов. Вот вам и весь тест. Можете проверить у себя на машинах ;=)
print "Content-type: text/html\n\n";
$start = time();
for ($i = 0; $i < 10000000; $i++) {
if ($ x == 100 || $x == 200 || $x == 300 || $x == 400) {
print $x . "\n";
} else {
$x = $x;
}
}
print time() - $start;
$start = time();
for ($i = 0; $i < 10000000; $i++) {
if ($ x == 100 || $x == 200 || $x == 300 || $x == 400) {
print $x . "\n";
} else {
$x = $x;
}
}
print time() - $start;
?>
Perl : 14
PHP : 25
На супер точность никто не претендует, но все же ;=)
Оба немного знаем perl и немного пхп, вот и были в диковинку некоторые вещи в последнем языке.
часть заметок, относится к реализации объектного подхода, часть - возникла после посещения
форумов в котором такие споры уже произошли, а часть после копания в коде других людей.
И вот после такого експиренса и получилось, что получилось.
Я сторонник принципа на чем умеешь на том и пиши, главное результат.
Но раз человек работает не на самого себя, то наверное стоит подумать о людяхс которые не знают того языка, или еще хуже которым перейдет сие творение по наследству.
Будь пожалста добр смотреть в логи (пхп проект написавший в егор лог 600 м за сутки, это сильно)
соблюдай какою нить структуру программы (а то здесь мы выполняем проверку на какой то параметр, проверка выполнена то суем еще всего 200 строчек кода, а вот если не прошла проверочка, то блин где же эта закрывающая скобочка, напихаем гордых сообщений об ошибке).
Если какая то часть кода не используется, на тоже специальные тулзовины для сохранения версий есть. (В одном из топиков про хранения пароля в зашифрованном виде, столкнулся в пхп проекте, получил 3.14стон за то что мне платят деньги я не знаю какой у человека пароль, сказали переделавть как считаешь нужным, потом сидел думал, какой из 6 одинаковых кусков кода отвечает за это дело)
Я против таких походов. А пхп - как раз и способствует такому небрежному отношению imho.
1) я вот одного не понимаю если говорить про grep почему бы не воспользоваться system ? (и подобные задачи решаются без проблем)
Может засада с операционной системой может возникнуть или нет??
2) Зачем в переменной хранить ссылку на фуцию ?
Встеречаются ситуации в которой требуется создание нового массива, хеща, функции,
но именовать эти структуры просто не имеет смысла.
Ну например: &some_func({some_hash}) # Здесь передается ссылка на хеш
Аналогичный пример анонимной функции. (Т.е. по ключу generate содержится ананимная функция)
name =>'struct',
descr =>'Category structure',
value =>undef,
generate=> sub {
my $self = shift;
use IpCats;
my $cat = IpCats->new($config);
my ($values, $labels) = $cat->tree();
$self->set_value({values=>$values, labels=>$labels});
}
});
Коллеги, это называется ФЛЭЙМ.
Так этож клева, специяально для флеймеров топик сделали :)=
2NetFly respect ;)=
Э-э-э, ehouse - лохи???
Вот и мои куски для тестирования
Slackware 9.0
[выполняется 4с]
>date;(echo -e "<?\n\nfor(\$i=0;\$i<1000000;\$i++){ \n \$x='dweeq12edca'; preg_match(\"/a|b|c/\",\$x);\n }\n?>"|php -q);date
[выполняется 8с]
это все при условии, что пхп собирался с исходников под данную машину (с оптимизацией), а перл шел в поставке под 386.
вот что неужто больше нечем заняться кроме проведения тестов, которые были 100 раз проведены до вас и результат очевиден. я очень люблю пхп, не люблю(оч плохо знаю) перл но результат-то очевиден!!
это спор аналогичен вечному спору о том какой провайдер мобильной связи лучше, потому что признать, что твой хуже - признать себя уродом. очевидно, который лучше по качеству, цены примерно одни и те же, везде свои плюсы и минусы, но споры не утихают и доходит до драк.
у перла есть один минус, который и не дает мне его изучить как следует.
это его сложность. как сложность в изучении, так и сложность в программировании. в отличие от синтаксиса пхп, который аналогичен всем привичному С, синтаксис перла ужасен. чтобы получить данные из формы, нужна целая эпопея не без регулярных выражений, тогда как это джелается одним движением руки в пхп.
и этот минус скорее всего не даст мне никогда писать на перле. просто освоив пхп, нет времени и желания изучать что-то новое, тем более, что написание биллинговой системы вряд ли свети, во всяком случае, в ближайшие несколько лет.
конечно-конечно, я знаю - я ламер, я непрограммист, я чмо, мне лень прочитать лишние 10мегабайт документации, и т.д. комментарии такого рода не принимаются.
имхо
Господа, возможно вы меня пошле те в *** после этого, но все же.
вот что неужто больше нечем заняться кроме проведения тестов, которые были 100 раз проведены до вас и результат очевиден. я очень люблю пхп, не люблю(оч плохо знаю) перл но результат-то очевиден!!
это спор аналогичен вечному спору о том какой провайдер мобильной связи лучше, потому что признать, что твой хуже - признать себя уродом. очевидно, который лучше по качеству, цены примерно одни и те же, везде свои плюсы и минусы, но споры не утихают и доходит до драк.
у перла есть один минус, который и не дает мне его изучить как следует.
это его сложность. как сложность в изучении, так и сложность в программировании. в отличие от синтаксиса пхп, который аналогичен всем привичному С, синтаксис перла ужасен. чтобы получить данные из формы, нужна целая эпопея не без регулярных выражений, тогда как это джелается одним движением руки в пхп.
и этот минус скорее всего не даст мне никогда писать на перле. просто освоив пхп, нет времени и желания изучать что-то новое, тем более, что написание биллинговой системы вряд ли свети, во всяком случае, в ближайшие несколько лет.
конечно-конечно, я знаю - я ламер, я непрограммист, я чмо, мне лень прочитать лишние 10мегабайт документации, и т.д. комментарии такого рода не принимаются.
имхо
Use CGI qw(param);
$field = param('field_name');
Это к вопросу о сложности получения данных из форм. А так, респект.
поясните
>>...а затем выражать свое авторитетное мнение.
никто не заявлял себя авторитетом
>>О mod_perl слышал? А о FastCGI? Видимо, нет.
слышал
>>мод перлу по производительности все те ж 20 раз.
опять же где док-во 20-ти раз????? мах которые ты привел 4.
>>А я всю жизнь думал, что С - это не объектно->>ориентированный язык и существуют Visual C++ и >>C++ Builder. Заблуждался, видимо ;=)
молодец, с умничал..... ну если ты не такой дошадливый, то могу пояснить что имелось в виду
по поводу CPAN, то ето никаким образом не относится к сути того что я сказал.
>>Ну найди, попробуй, grep и map ;=)
я не думаю, что принципиально эти ф-ии повлияют на выбор языка программирования... потому что в перл например нет конструкции for(var in obj) которая есть в JavaScript, но ето еще ни очем не говорит.
>>Сторонникам PHP советую пяток лет пописать на >>перле, пару лет на PHP,
изходя из задач веб программирования, то твое предложение можно сравнить с предложением бухгалтеру поработать каменьщиком на стройке.
Все выше сказанное ИМХО!
Как раз относиться. На cpane можно найти все средства для эффективной разработки веб приложений: начиная от модулей для проверки валидности кредитных карт и заканчивая модулями, позволяющими работать с YahooWebMail. Там есть все (!).
Влияют, очень даже. Grep и map позволяют уместить большинство обходов массивов и хешей для редактирования и поиска в них данных в одну строку (эта задача встречается очень часто), при этом предоставляю существенный выигрыш в производительности.
Исходя из задач веб-программирования, я довольно долго пишу веб-приложения как на PHP так и на Perl. Не жалуюсь ;=)
Э-э-э, ehouse - лохи???
Нет, ehouse рулят. Это была ирония, так как в ehouse ВСЁ написано на PHP а тут прозвучало мнение, что на PHP серьезных проектов не пишется.
Нет, ehouse рулят. Это была ирония, так как в ehouse ВСЁ написано на PHP а тут прозвучало мнение, что на PHP серьезных проектов не пишется.
Серьезным проектом я считаю проект, у которого 1-1,5 млн посещений в день. Никто не утверждал, что PHP – язык слабый (однако, он все же слабее перла). Было сказано, что PHP – язык медленный и из-за этого непригоден для серьезных проектов. А по поводу ссылки – прочитай подпись ;=) Многие пишут на PHP только потому, что этот язык проще в изучении и на нем легче (да, это одно их его достоинств) писать. Это и есть основная причина его популярности у русских программистов (за границей, в США про крайней мере, он не особо распространен).
Серьезным проектом я считаю проект, у которого 1-1,5 млн посещений в день. Никто не утверждал, что PHP – язык слабый (однако, он все же слабее перла)....
Ок, Яндекс пойдет? Там используется Perl, PHP и Си. Каждый для задач с которыми лучше справляется.
Это есть профессиональный подход.
И вообще, ИМХО, слабых языков НЕТ. Есть слабые программисты и как раз из за популярности PHP в массах, слабых программистов и паршивого кода на PHP гораздо больше чем на Perl или Си.
Теперь насчет того, что там лучше или слабее... Я в принципе уже написал своё имхо, но давай с примерами.
Интересно, а если сравнить, по скорости, связку Java (JSP) + Oracle и PHP + MySQL, что окажется быстрее?
Я думаю, что PHP. При этом, MySQL не выдержит той нагрузки и не обеспечит той ПРОМЫШЛЕННОЙ надежности которую обеспечит Oracle, но иногда (достаточно часто) того и не требуется.
Теперь, по поводу 1 - 1,5 млн в день. Точно, как про Яндекс или Ихаус, не знаю, но наверное HotLog и SpyLog приближаются к этой отметке...
А часть команды разработчиков SpyLog-а была в своё время активнейшими участниками PHPClub-а.
По поводу США -- есть такая компания: ValueAd которая обслуживает, если я не ошибаюсь, баннерные и статистические системы СУПЕР грандов дот.кома (у них на сайте раздела Clients не нашел, поэтому рассказывать не буду, но это действительно КРУПНЕЙШИЕ веб ресурсы).
Так вот они используют PHP с Маськой.
И всё это я пишу не для того что бы сказать - "PHP лучше или сильней" а для того, что бы сказать - Сей разговор бессмысленнен по своей сути, ибо если ты РЕАЛЬНО грамотный программер или проджект, ты адекватно выберешь технологию и адекватно применишь её там, где нужно.
Я смысл твоего сообщения понял. Попробуем по другому. Человеку, который хорошо знает Perl и хорошо знает PHP безразлично (если отбросить личные предпочтения) на чем писать и времени на написание одинакового приложения на одном из этих языков будет потрачено примерно равное количество. Выше мы перечисляли достоинства двух языков с точки зрения удобства программирования: наличия тех или иных функций, конструкций и т.д. Однако, потенциальному заказчику все равно, есть ли в языке grep или каким образом я получаю параметры формы. Ему важен конечный продукт и скорость (!) его работы. Perl обгоняет PHP по скорости везде: циклы, конструкции выбора, регулярные выражения, работа с БД (тесты проводились для mysql, могу показать результат). Скажем так, цифра в 4-20 раз относилась к третей версии PHP, для четвертой – это 3-7 раз. Т.е. Perl скрипт работает 2 секунды, а PHP – 14. Не беря во внимание системное программирование, на Perl можно написать все то, что на PHP и наоборот. При этом мы получим 2 одинаковых скрипта, но один из них будет работать в 3-7 раз быстрее другого. Вот и все арифметика. Именно поэтому Perl лучше PHP. Пусть он обходит его по 1 пункту, но этот пункт очень существенен. Или я не прав?
Кстати, в Японии не используется ни Perl ни PHP. Японцы пишут на языке, разработанном местным профессором: объектно-ориентированная смесь питона и перла. Называется сие творение Ruby.
И немного не по теме. За границей коренные жители (я не говорю о русских, которые работают там ;=), очень скептически относятся к бесплатным технологиям. Допустим, серьезные биллиговые системы, как заметил HabaHaba, пишутся либо на Java, либо на ASP. Это связанно с тем, что разработчики последних дают гарантию безопасности, в отличие от тех же Perl или PHP, которые мы используем на свой страх и риск. Однако, у Perl и в этом аспекте есть преимущество – он на 9 лет старше своего конкурента, следовательно его считают на порядок безопаснее.
Кстати, в Японии не используется ни Perl ни PHP. Японцы пишут на языке, разработанном местным профессором: объектно-ориентированная смесь питона и перла. Называется сие творение Ruby.
Во первых, я ничего такого про СЕРЬЕЗНЫЕ биллинговые системы не замечал. Я те честно скажу, я просто не в курсе, как там чего у кого на западе ибо по рабочим вопросам там не был и сурцы биллинговых систем мне никто не показывал.
Вернее, что знаю, то говорю а чего не знаю о том молчу.
Судя по твоим утверждениям, работал, причем как минимум консультантом по вопросам биллинга -- снимаю шляпу.
По поводу того, что IIS считается безопасным сервером это ты хорошо сказал, эт конечно верно :)
По моему опыту и имху, технологии выбираются исходя из их комплексного анализа. ASP, как правило, используют в связке с MsSQL а Java с Oracle или DB2. То есть, выбор этих технологий обоснован скорее тем, что есть у компании на момент принятия решения о создании веб проекта.
В Японии, я вообще не был и ни подтвердить ни опровергнуть заявление о том, что там "не используется ни Perl ни PHP" не могу.
А OpenSource это конечно! К OpenSource на западе скептически относятся... Это whitehouse.gov]для лохов ;)
В общем, по ходу дела, у нас с тобой разные подходы к выбору технологий.
Ты пишешь о том, что Perl приложение будет работать в 4-7 раз быстрее, а я могу тебе сказать, что PHP разработка обойдется конторе дешевле.
Ты говоришь о том, что Perl быстрее PHP основываясь на своих тестах а я говорю, что на PHP выгодней писать так как легче потом поддерживать.
Ты говоришь, что Perl безопасней а я говорю, что в контексте безопасности они абсолютно равны ибо ошиюки они (в большинстве случаев) в ДНК и кривых руках программера а не в ядре языка.
А я могу сказать, что наоборот, и неизвестно, кто из нас будет прав. Хороший Perl программист напишет быстрее и лучше, чем плохой PHP программист, и наоборот. Тут дело не в языке, а в команде программистов - все зависит от их компетентности, степени лени, опыта, количества наработок (!) и т.д. Я не думаю, что тот факт, что в перле для принятия параметров формы нужно предварительно записать use CGI, или что перл программисту необходимо каждый раз выводить HTTP заголовок, дает основание полагать, что на PHP писать быстрее.
Perl сложнее выучить – это факт. Но после нескольких лет (или немного больше ;=) практики ты можешь использовать все возможности языка и писать более красивый, компактный, производительный код, при этом затрачивая меньше времени.
Это твое мнение. Я основываюсь на результатах тестов – их невозможно опровергнуть и сказать "у меня PHP работает быстрее, чем Perl". Зато, я могу без угрызений совести сказать: "тебе легче поддерживать PHP код, а мне Perl". И оба мы будем правы.
Я себя перефразирую. PHP предоставляет программисту больше возможностей совершить ошибку. Однако, не буду себе противоречить (я про первый абзац этого сообщения) и соглашусь с тобой – это уже сложности программиста.
Вернее, что знаю, то говорю а чего не знаю о том молчу.
Судя по твоим утверждениям, работал, причем как минимум консультантом по вопросам биллинга -- снимаю шляпу.
Ты заметил про серьезные приложения. А серьезные биллинговые системы – это подмножество множества серьезных приложений ;=) Кстати, к вопросу о безопасности: некоторое время назад была попытка получить мерчант у wirecard-а – нам отказали, аргументируя это тем, что наш софт написан на PHP. С perl все прошло удачно. Но это так, притча о фанатиках =)
Я не говорил ничего о IIS ;=)
Впредь буду конкретизировать: используется, но не так популярен как Ruby. Что это заметить, не нужно ездить в Японию. Хотя, японцам нужно сказать спасибо: Тсукамото Макио внес ощутимый вклад в создания Perl интерпретаторов для покетов =)
А я могу сказать, что наоборот, и неизвестно, кто из нас будет прав. ..."тебе легче поддерживать PHP код, а мне Perl". И оба мы будем правы.
В данном контексте я говорю не как разработчик а как руководитель.
У меня есть конкретный опыт интервьюирования и поиска сотрудников, формирования команды и руководство этой командой. И я говорю -- разработчики PHP дешевле и легче ищутся (при правильном формировании коллектива, где есть 3-4 супер-профи и 6-8 "новобранцев" которые пишут интерфейсы и не допускаются до мест где возможно совершить критическую ошибку.
Сразу скажу, что опыта формирования "Perl-команды" у меня нет, но есть опыт проведения интервью с сотней программеров и, основываясь на этом, я могу сформировать свою статистику.
Я себя перефразирую. PHP предоставляет программисту больше возможностей совершить ошибку.
Это с обилием то в Perl функций позволяющих работать с системой? Кхе-кхе...
Ты заметил про серьезные приложения. А серьезные биллинговые системы – это подмножество множества серьезных приложений ;=)
Нет, я сказал, что MySQL не является промышленой СУБД. Про ASP и биллинговые системы это уже твои вольности :)
Я не говорил ничего о IIS ;=)
Ты говорил про ASP и гарантию безопасности (я даже жирным выделил) который пускается только на IIS.
З.Ы.
Слушай, я думаю, что после твоего следующего поста стоит заканчивать ибо это флэйм чистой воды.
Я прекрасно понимаю твою горячность и патриотичность.
Но с желанием доказать что одно ЛУЧШЕ другого ты перебарщиваешь так как истины тут просто нет.
Вряд ли ты сможешь переубедить людей ездящих на бехах, что мерен лучше и наоборот.
Ты пишешь о том, что Perl приложение будет работать в 4-7 раз быстрее, а я могу тебе сказать, что PHP разработка обойдется конторе дешевле.
[/qoute]
Сомнения вызывают эти слова.
Если действительно, экономический выигрыш на порядок выше, не было бы разброда во мнениях по языкам. А был бы явной перекосяк в пользу выигрышной технологии. То что ehouse использует то что использует, аллах как водится акбар.
Никто не застрахован, от ситуации когда надо чего то менять, и вот здесь то кажущее достоиство смешивания кода, преврашается...
Действующие лица: заказчик (З), руководитель(Р), программист (П)
Р: Вот значит вот здесь это работает так....
З: Зашибись..
Р: А вот здесь фенечка...
З: А где мулька???
Р: Какая мулька???
З: Ну ты же чтолько показывал, давай торкай мульку сюда, и будет нам счасье.
Р: П. камон сюда, щас делать мульку нада, так что резче рывок, времени 40.сек.
П: Уходя к писюку думает, зае...., мульку подавай, гады, далая copy/paste, Ctrl+S, F5, облом, F5, опять облом. А нахпох. globals = on, "знал что получится", довольно ухмыляясь набирает >net send 19.168.0.* "As you command, Mulka ready!!!"
Р: Вот наша мулечка уже фурычит.
З: Алелуйя, че-то прет меня сегодня, давай таких по три штуки во все дыры.
Р: Не извольте сомневаться, чай оно не в первый раз. П. млин, давай нажимай кнопки, чем быстрее будешь нажимать, тем времени на аську больше будет.
П: Не твой сегодня день Р.! Ctrl+H, через 30 сек >net send 192.168.0.* "READY"
Ты говоришь о том, что Perl быстрее PHP основываясь на своих тестах а я говорю, что на PHP выгодней писать так как легче потом поддерживать.
Здесь спорно. Легче поддерживать понятный простой код, который хорошо продуман и структурирован, а не просто PHP код.
В конечном счете происходит упор в опыт программиста или его руководителя, который даст по шее за непонятные выкрутасы.
Ты говоришь, что Perl безопасней а я говорю, что в контексте безопасности они абсолютно равны ибо ошиюки они (в большинстве случаев) в ДНК и кривых руках программера а не в ядре языка.
Вот здесь в адрес языка можно метнуть камень и не один ;)=
Сомнения вызывают эти слова.
Если действительно, экономический выигрыш на порядок выше, не было бы разброда во мнениях по языкам. А был бы явной перекосяк в пользу выигрышной технологии. То что ehouse использует то что использует, аллах как водится акбар.
Хех. Вот тут вот как раз вступает человеческий фактор.
Во первых, руководитель может быть фаном одного или другого, во вторых, руководитель может быть полным ламером и язык будет использоваться тот, который предпочитал первый пришедший в контору программер или руководительский друг/сын/пёс/брат/сват/тёща.
Я редко встречал грамотный подход к выбору технологий. Вернее сказать, вообще не встречал.
А грамотный, это когда проводится подробный анализ и технических и экономических факторов и на основе этого выбирается технология. Вот это хорошо.
....
>net send 192.168.0.* "READY"
:))
Смешно. Но канает, по моему, только в "маленькой но гордой дизайн-студии".
Везде, где к разработке п.о. подходят ответственно, программер просто не сможет сделать register_globals а такого менеджера как ты описал -- вышибут на хрен через неделю.
Здесь спорно. Легче поддерживать понятный простой код, который хорошо продуман и структурирован, а не просто PHP код.
Это верно. Тут согласен на все 100.
Хотя я имел ввиду стоимость поддержки, время освоения и скорость поиска человека.
Вот здесь в адрес языка можно метнуть камень и не один ;)=
Опять же, на любом автомобиле кроме "Оки" можно, в среднем, задавить 5-6 старушек за раз, но виноват при этом всегда водитель (или старушка) а не автомобиль.
Я пишу и на PHP и на Perl. И, когда приспичит, на Си. И людьми командую. Иногда. Да, я больше люблю Perl. Люблю перл гольф. Люблю (не поймите неправильно) Ларри Уолла. Но не фанатею ;=)
В данном контексте я говорю не как разработчик а как руководитель.
У меня есть конкретный опыт интервьюирования и поиска сотрудников, формирования команды и руководство этой командой. И я говорю -- разработчики PHP дешевле и легче ищутся (при правильном формировании коллектива, где есть 3-4 супер-профи и 6-8 "новобранцев" которые пишут интерфейсы и не допускаются до мест где возможно совершить критическую ошибку.
Сразу скажу, что опыта формирования "Perl-команды" у меня нет, но есть опыт проведения интервью с сотней программеров и, основываясь на этом, я могу сформировать свою статистику.
На PHP легче писать, его легче выучить => больше людей его учат => больше людей на нем пишет => процветает здоровая конкуренция => найти исполнителей проще и дешевле => ты прав. С перлом ситуация обстоит немного иначе – людям лень его учить, т.к. он сложнее (на первый взгляд) PHP, поэтому новичков среди перловников гораздо меньше. А старики, естественно, заламывают потолочные цены. Однако, это уже проблема менеджеров проектов ;=) Факт в том, что две равные по силе команды Perl и PHP разработчиков напишут одно и то же приложение за равные промежуток времени. Но одно из них будет работать быстрее ;=)
После появления транзакций, она может вполне использоваться для промышленных проектов малого и среднего размера. В книге Дюбуа , по моему, пару страниц отведено на описание серьезных проектов (и их владельцев), которые используют mySQL. Кстати, там, где mySQL справиться не может – на помощь может прийти постгри.
Да ну?
http://www.yandex.ru/yandsearch?rpt=rad&text=Apache+%2B+ASP
Гарантия безопасности не означает ее наличие. Мелкософт ведь гарантирует, а не я. Я к тому, что если биллинг сломают из-за наличия уязвимости, например, в сервере, владельце (при наявности договора) буду знать на кого катить бочку.
Давай все таки сделаем какой-то вывод ;=) Неужели я домен perlvsphp.com зрая заказал?
Я вижу это так:
1. PHP хороший язык.
2. Perl хороший язык.
3. PHP пригоден исключительно для веб программирования.
4. Perl пригоден для веб программирования, системного администрирования, сетевого программирования.
5. PHP программистов больше.
6. Perl программистов меньше, но практически все они высококвалифицированные (офтопик: плохие программисты учили PHP ;=)
7. PHP программисты дешевле.
8. Perl программисты дороже (офтопик: они пьют больше пива).
9. PHP работает медленнее Perl в 4-7 раз.
10. Perl работает быстрее PHP в 4-7 раз.
И самое главное: есть версия Perl для карманных ПК, поэтому я могу играть в перл гольф даже тогда, когда еду в лифте ;=)
Но вот сылочка что можно наворотить на perl. это кслову о интуитивно понятном коде :) http://forum.codenet.ru/showthread.php?s=&threadid=12786 (думую тут она будет в тему :) )
1)hotbox.ru -> php и MysqL
Что касаемо скорости(жаль не могу провести реальные тесты, смогу только к концу следующей недели, обязательно заброшу их сюда). Но даже если проигрывает то это весьма не критично если говорить о биллинге: он делится на 2 части первая веб вторая сбор данных.
Та что сбор данных тут должен быть скрипт стартуемый кроном(ну или чем то таким), разбирающий логи и заганяющий их в базу (тут выгрыш в парла секунды весьма приятен но это не это веб программирование и пхп тут явно проигрывает, эту часть лучше писать на перле, хотя это не критично и это можно писать на пхп)
Что касаемо, веб части почти во всех веб проектах основная нагрузка ложится бд, и проигрыш будет пхп от перла будет просто не заметен.
Что касаемо апаче и АСП эта связка для сверх экстрималов, я как сис админ не скоро такую свяхку рискну поставить, да и не к чему это они не созданы друг для друга.
Посколько под веб с перлом не работал просто интересно как у него обстоит дело с : XML и Сессиями ?
Посколько под веб с перлом не работал просто интересно как у него обстоит дело с : XML и Сессиями ?
Читай книгу Perl & XML (Джейсон Макинтош, Эрик Т. Рэй, 204 стр.). Perl работал с XML еще тогда, когда PHP о нем не знал ;=) Кстати, перед тем как принимать участие в споре о Perl и PHP необходимо иметь хоть небольшое представление о первом ;=)
На остальное отвечу потом - времени нет.