rusty_angel ([info]rusty_angel) wrote in [info]ru_root,
@ 2008-01-29 01:00:00
Previous Entry  Add to memories!  Tell a Friend!  Next Entry
Чем PHP хуже sh или perl?
Нет, я не тролль. Пишу скорее для того, чтобы привести в порядок свои мысли.

Предстоит писать весьма энное количество небольших скриптов для выполнения всяких рутинных действий типа добавления-изменения виртуальных юзеров, переписывания конфигов, сбора кое-какой статистики, etс. И делать это на PHP не хочется по субъективным причинам. Так вот хочется найти причин объективных, чтобы этого таки не делать, и писать на баше или перле.

Pros:

  1. Будет кроме всего прочего морда на PHP, гомогенную систему (скорее всего) будет легче поддерживать

  2. Второй разработчик прилично знаком только с PHP.

  3. Более простой интерфейс к MySQL (?)



Cons:

  1. PHP поощряет всякие нехорошие привычки, от которых я до сих пор не могу отделаться до конца. Мой код на bash или даже перле мне читать приятнее и легче (я уже покаялся в субъективности, так что приберегите камни для следующих пунктов).

  2. Гетерогенная (как минимум - набор скриптов на sh/Perl плюс морда на PHP) система (возможно) будет лучше структурирована, а разные её уровни - лучше изолированы.

  3. Проще разделить обязанности программистов. Для двух разработчив более жёсткое разделение обязанностей может быть более эффективным (опять же - субъективно и основано на небольшом опыте работы в команде).

  4. PHP не имеет никаких преимуществ при обработке текстовой информации: регулярные выражения записываются сложнее, чтение из stdin по сравнению с перлом - просто ужасно (снова субъектив, возможно это всё из-за моих старых быдлокодерских привычек)

  5. Для большинства вещей, связанных с mysql, будет вполне достаточно `mysql -e '...'`



Пожалуйста, убедите меня писать на PHP и не рыпаться или найти достаточно веские аргументы для человека, не умеющего баш и перл.

(Post a new comment)


[info]dmarck
2008-01-28 10:42 pm UTC (link)
На мой взгляд, главное - непредсказуемость PHP скриптов. Даже не недоказываемость -- с этим если не у всех, то у большей части реализаций проблемы будут неизбежно -- а именно что неизвестно в какой момент выпрыгнувшая несовместивость и/или неожиданная реализация нечетко описанного.

Для меня -- более чем повод писать на чем-нибудь тщательнее формализуемом. Хоть сколь-нибудь.

(Reply to this) (Thread)

[info]supermega
2008-01-29 07:28 am UTC (link)
Может, пример приведешь? А то как-то очень голословно

(Reply to this) (Parent)

[info]oal
2008-01-28 10:52 pm UTC (link)
Pros:
# Более простой интерфейс к MySQL (?)
Cons:
# Для большинства вещей, связанных с mysql, будет вполне достаточно `mysql -e '...'`

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

(Reply to this) (Thread)

[info]rusty_angel
2008-01-28 11:02 pm UTC (link)
Поругать - есть за что, но они достаточно просты и, главное, привычны.
А вот DBI::mysql напугал когда-то, и до сих пор кажется каким-то странным и неудобным, сколько себе ни доказывал, что в целом - то же, а fetchall_arrayref - вообще оргазм после похапешных плясок с while. Но... Инерция и субъективизм.

(Reply to this) (Parent)(Thread)

[info]oal
2008-01-28 11:07 pm UTC (link)
Даже не DBI. Есть какие-то модули — перлфаги подскажут, а я не помню название — для отображения таблицы в перловые типы.

(Reply to this) (Parent)

[info]dvorkin
2008-01-29 05:01 am UTC (link)
насчет оргазма... может быть для вас это и оргазм, но вот я знаю системы, в которых из-за такой вот "оптимизации" - fetchall_... статистика у пользователей открывается по 2-3 минуты. и это вам не мускуль какой-нибудь, а оракл. и скрипты не на ПХП, а на смоллтолке.
вот просто человек любит такую псевдооптимизацию. и даже не догадывался, почему все так плохо. теперь вот докажите мне, что программирование на ПХП способствует появлению дурных привычек ;)
API у PHP для работы с базами самый что ни наесть нативный.
ругают только идиоты.
вы сами посмотрите в mysql.h и сравните

(Reply to this) (Parent)(Thread)
Re: мои две копейки.
[info]rusty_angel
2008-01-29 05:17 am UTC (link)
Ну а чего не поругать за излишнюю нативность? Это не всегда плюс. Абстракций ведь иногда хочется. Чем в этом смысле BDI лучше - не знаю, правда, может и ничем. Как я уже говорил, не связывался с ним практически.
fetchall тоже с умом надо. Тогда оргазм и всё что положено. Никаких тебе while с ifом внутри или unsetом после, если надо быстренько получить 10-20-30 записей.
Собственно, если с умом - то от всего оргазм, а то я знаю системы, в которых берётся из базы всё и сортируется пузырьком. И интерфейс к СУБД тут, сам понимаешь, не при чём :)

(Reply to this) (Parent)(Thread)
Re: мои две копейки.
[info]dvorkin
2008-01-29 05:28 am UTC (link)
не спорю. просто еще один довод "не спихивать все на ПХП" :)
мол, бажный, расслабляет и все такое.
чаще надо тренироваться на Сях - и маразм вам не грозит до старости.

(Reply to this) (Parent)

[info]deadgeny
2008-01-29 06:30 am UTC (link)
Если вам действительно нужны все данные, то делаете ли вы fetch в цикле или fetchall один раз - роли не играет.

А в чем преимущество нативного апи?

(Reply to this) (Parent)(Thread)

[info]dvorkin
2008-01-29 07:07 am UTC (link)
> Если вам действительно нужны все данные
а если мне совсем не нужны все данные, но я делаю это только потому, что знаю такую классную конструкцию и ничего не понимаю?
вот умеет, условно говоря, язык @#$% конструкцию вида
xlt:out(db)
чудесный язык! можно написать программу вывода статистики за 10 секунд! ниче страшного, что при этом за первую секунду система пожрет 500 Мб памяти, а оставшиеся 3 минуты - будет эти 500 мегабайт ворочать через RPC?
ну я немного перегибаю, но примерно вот такие Perl'ы встречаются в коде моих коллег - упертых фанатов Parser или smalltalk.

> А в чем преимущество нативного апи?
ни в чем, когда человек понимает, что происходит.

(Reply to this) (Parent)(Thread)

[info]deadgeny
2008-01-29 07:30 am UTC (link)
а если мне совсем не нужны все данные
(пожимает плечами) любой инструмент должен использоваться по назначению.

(Reply to this) (Parent)

[info]eternal_leave
2008-01-28 11:00 pm UTC (link)
мой довод против PHP один: неизвестно, что случится с вашими скриптами после обновления текущей версии.
за SH - удобство разработки, четкая формализация языка, и - главное - прозрачная обработка потоков данных с помощью хозяйства из /bin (/sbin).

(Reply to this) (Thread)

[info]rusty_angel
2008-01-28 11:05 pm UTC (link)
Есть такой довод. Но так и не смог вспомнить, чтобы у меня что-нибудь ломалось после обновления. Не считая случаев, когда я забывал пересобрать ещё и экстеншены. Что тоже аргумент.
Про прозрачность и хозяйство я упоминал, но от противного :) Ты лучше это сформулировал.

(Reply to this) (Parent)(Thread)

[info]filonov
2008-01-29 12:35 am UTC (link)
Это повезло. Нам вот в пачке мест приходится держать 4.4.0 и ни версией больше.

(Reply to this) (Parent)(Thread)

[info]ibh
2008-01-29 10:09 am UTC (link)
Ну ведь вам никто не запрещает рядом держать другую версию?

(Reply to this) (Parent)

[info]ospf_ripe
2008-01-29 08:03 am UTC (link)
В sh нет диагностики ошибок. Если где то допустил опечатку, например в имени переменной, то узнаешь об этом только когда скрипт не отработает (статисчтика не будет записана в базу и т. п.).
Поэтому sh хорошо подходит только для небольших (одна, максимум две страницы) скриптов.

А для более сложных скриптов я предпочитаю перл (разумеется с use warnings/use strict).

(Reply to this) (Parent)(Thread)

[info]eternal_leave
2008-01-29 09:05 am UTC (link)
Это да, не спорю. В таких случаях именно перл. А PHP для системных скриптов - даже как-то слабо себе представляю :)

(Reply to this) (Parent)(Thread)

[info]rusty_angel
2008-01-29 09:14 am UTC (link)
Я тоже, но... Почему? Тем более, что сейчас у нас достаточно написано именно на PHP, и новая версия планируется не потому что нынешняя плохо работает, а потому что растём.

(Reply to this) (Parent)

[info]dmih
2008-01-28 11:38 pm UTC (link)
Я лично воспринимаю плюс PHP в том, что из всех перечисленных он наиболее дружелюбно относится к синтаксису а-ля Си. На котором между делом написана большая часть того же UNIX-а.
Если придерживаться этой позиции и не %%%%% мозги себе и окружающим, то это позволяет одному нормальному традиционному программисту программу написать, а другому традиционному программисту программу понять. Без каких либо предварительных договоренностей, изучений, знакомств со спецификой и т.д.
У PERL-а с этим немного хуже. Если не использовать его специфику то язык получается достаточно дурацкий, а если использовать - нужен PERL программист.
У sh с этим сильно хуже - нормальному традиционному программисту код на sh напоминает клинику.
Но это как грится субъективно.

(Reply to this) (Thread)

[info]filonov
2008-01-28 11:47 pm UTC (link)
"В говне содержится тот же углерод, что и в нормальной человеческой еде. Сто миллиардов мух не могут ошибаться..."

(Reply to this) (Parent)(Thread)

[info]dmih
2008-01-28 11:52 pm UTC (link)
Ну вы где-то мысль верно уловили, аргумент примерно таков и есть, что говно, но зато родное.

(Reply to this) (Parent)(Thread)

[info]rusty_angel
2008-01-29 04:41 am UTC (link)
Да, это самый сильный аргумент

(Reply to this) (Parent)

[info]ospf_ripe
2008-01-29 08:09 am UTC (link)
> Я лично воспринимаю плюс PHP в том, что из всех перечисленных он наиболее дружелюбно относится к синтаксису а-ля Си.

На perl тоже можно писать программы в синтаксисе похожем не Си.
То что перл позволяет опускать скобки, использовать разные сокращенные варианты и переменные по умолчанию еще не значит, что так нужно писать всегда.

(Reply to this) (Parent)

[info]sadok
2008-01-29 05:03 pm UTC (link)
Мне клинику напоминает код 1С. Остальное вышеперечисленное все-таки делали гуманоиды :)

(Reply to this) (Parent)
мои две копейки.
[info]filonov
2008-01-28 11:39 pm UTC (link)
Если разработчик прилично знаком только с php - у меня большие сомнения что его вообще можно подпускать к серьезным проектам. Аццкие отжыги "специалистов по php" я регулярно наблюдаю. От неумения сравнить бинарные строки, до невозможности корректно обработать ошибки сокетов.

Да, еще про богатый bugtraq'овый опыт php тут вроде еще не упоминали.

Собственно преимущество у php ровно одно - есть масса быдлокодеров, которые делают вид что его умеют.

(Reply to this) (Thread)
Re: мои две копейки.
[info]agaspher
2008-01-29 12:20 am UTC (link)
> преимущество у php ровно одно - есть масса быдлокодеров, которые делают вид что его умеют.

И это же является одним из главных его недостатков.

(Reply to this) (Parent)(Thread)
Re: мои две копейки.
[info]filonov
2008-01-29 12:32 am UTC (link)
+1000

(Reply to this) (Parent)
Re: мои две копейки.
[info]stas
2008-01-29 01:16 am UTC (link)
Никакого особенно богатого опыта у php на багтреке нет. Есть много программ, написаных на php, в которых есть баги, в том числе богато представленные на багтреке. php в этом виноват примерно так же, как C/C++ виноват в том, что у кого-то винда глючит.

(Reply to this) (Parent)(Thread)
Re: мои две копейки.
[info]filonov
2008-01-29 01:51 am UTC (link)
А вот давайте не будем путать баги програм, написанных на php и баги самого php.
Вот первый попавшийся пример:

http://www.sfu.ca/~siegert/linux-security/msg00064.html

C/C++ виноват несколько иначе.

(Reply to this) (Parent)(Thread)
Re: мои две копейки.
[info]stas
2008-01-29 02:11 am UTC (link)
Ну да, локальный эксплоит пятилетней давности в php 4.0.x... Вы б еще из php 3 принесли :)
Я вам страшное скажу - в PHP были баги гораздо круче. Как, впрочем, и в других продуктах. Только они давно починены.

(Reply to this) (Parent)(Thread)
Re: мои две копейки.
[info]filonov
2008-01-29 02:19 am UTC (link)
Ну во-первых - я сразу сказал что это первый попавшийся.
Во-вторых, тезис о "никакого особенно богатого опыта нет" - можно считать сдувшимся.
В-третьих - ссылка на "другие продукты" не катит, поскольку речь идет именно о php.
Ну и на закуску - не напомните, Security Officer какого програмного продукта громко материл разработчиков, его игнорировавших?

(Reply to this) (Parent)(Thread)
Re: мои две копейки.
[info]stas
2008-01-29 06:29 pm UTC (link)
Понятия не имею. Я даже не в курсе, что в PHP есть Security Officer. Или вы о другом продукте? Но тогда о каком и почему?

(Reply to this) (Parent)(Thread)
Re: мои две копейки.
[info]filonov
2008-01-31 08:52 am UTC (link)
так бы и сказал что не в теме.
http://www.opennet.ru/opennews/art.shtml?num=9234

(Reply to this) (Parent)(Thread)
Re: мои две копейки.
[info]stas
2008-01-31 09:23 am UTC (link)
Насчет того, что я не в теме - это хорошая шутка, жаль вы не понимаете, почему. Но теперь я понял, что вы Эссера в виду имеете. Эссер это очень интересный человек, но насколько мне известно, поста под названием Security Officer в PHP Group не было и нет, и поэтому Эссер его не занимал. Он входил в security group - в которую может войти любой разработчик PHP, обладающий достаточными знаниями и опытом - но, как вы прочитали, решил из нее выйти из-за некоторых разногласий. Бывает. Хотя, конечно, занимался и продолжает заниматься исследованиями в области безопасности, в том числе и PHP, за что ему большая благодарность, даже учитывая его некоторую склонность к драме.
Впрочем, это все лирика. Физика же в том, что "богатый bugtraq'овый опыт php" - это миф. В частности произошедший из-за того, что большинство тех вещей, о которых пишут на багтрек, в других языках не считаются проблемами безопасности вообще, да и частью языковой платформы зачастую не считаются.

(Reply to this) (Parent)
Re: мои две копейки.
[info]ospf_ripe
2008-01-29 08:12 am UTC (link)
Если сравнивать баги в perl и баги в php то соотношение будет близко к 1:100.
За последние лет 5 в perl-е помню две или три баги которые можно считать уязвимостями. В php их находят почти каждый месяц, и не по одной.

(Reply to this) (Parent)(Thread)
Re: мои две копейки.
[info]stas
2008-01-29 06:30 pm UTC (link)
Просто то, что считают "багами" в PHP, в перле вообще не обсуждают. Типа требования от языка предоставить local sandbox или отвечать за third-party libraries.

(Reply to this) (Parent)
Re: мои две копейки.
[info]deadgeny
2008-01-29 04:59 am UTC (link)
Сравним с перлом?
http://www.securityfocus.com/cgi-bin/index.cgi?o=0&l=30&c=12&op=display_list&vendor=PHP&version=&title=PHP&CVE= и
http://www.securityfocus.com/cgi-bin/index.cgi?o=0&l=30&c=12&op=display_list&vendor=Larry+Wall&version=&title=Perl&CVE=

(Reply to this) (Parent)
Re: мои две копейки.
[info]awind
2008-01-29 09:48 am UTC (link)
http://www.debian.org/security/2007/

(Reply to this) (Parent)
Re: мои две копейки.
[info]rusty_angel
2008-01-29 05:26 am UTC (link)
Подпускать можно. Этого разработчика. А быдлокодеры - это уже за рамками данного обсуждения.

(Reply to this) (Parent)

[info]stas
2008-01-29 01:15 am UTC (link)
И делать это на PHP не хочется по субъективным причинам.

Не делайте! Зачем портить себе нервы? Если вы пишете на перле лучше - так пишите на перле. А то получается, как если бы вы спросили, почему вам надо писать стихи по-японски, если ваш родной язык - русский. Пишите по-русски, вас не осудят :)

(Reply to this) (Thread)

[info]rusty_angel
2008-01-29 05:20 am UTC (link)
А зачем портить нервы напарнику и возможно последователям, (возможно) снижать общую эффективность, (возможно) усложнять поддержку и развитие всего этого добра, etc?.. Вот и ищу, почему на чём-то другом писать будет объективно лучше.

(Reply to this) (Parent)

[info]supermega
2008-01-29 07:34 am UTC (link)
Какие это нехорошие привычки поощряет php?

(Reply to this)


[info]ospf_ripe
2008-01-29 08:24 am UTC (link)
и еще пара ссылочек про работу с целыми числами в php:
http://www.mysqlperformanceblog.com/2007/03/27/integers-in-php-running-with-scissors-and-portability/
http://www.mysqlperformanceblog.com/2008/01/10/php-vs-bigint-vs-float-conversion-caveat/

IMHO такой язык не пригоден для написание систем типа биллинга и статистики...

(Reply to this)


[info]ospf_ripe
2008-01-29 08:30 am UTC (link)
Да, и еще не стоит забывать такое "изобретение" php как php.ini, за которое иногда авторам php хочется оторвать руки.

Когда после переноса скриптов на другой сервер или обновления php скрипты перестают работать, а после пары часов отладки выясняется, что все дело в том, что в php.ini прописаны разные настройки или даже не прописаны никакие, а значения по умолчанию разные в разных версиях.

(Reply to this) (Thread)

[info]supermega
2008-01-29 09:43 am UTC (link)
Большую часть настроек можно задать самому в .htaccess или в самом скрипте. А если скрипт запускается из коммандной строки, то можно свой указать целиком.
Всё же стоит изучить язык, прежде чем ругать

(Reply to this) (Parent)

[info]dmih
2008-01-29 05:57 pm UTC (link)
Это, кстати, кроме шуток хороший аргумент.

(Reply to this) (Parent)

[info]pzrk
2008-01-29 11:22 am UTC (link)
- Чем хуже?
- Чем перл!

(Reply to this)

Create an Account
Forgot your login or password?
Login w/ OpenID
English • Español • Deutsch • Русский…