PHP масштабируется не хуже Java

> Да, да, а если не существенно, то зачем поднимать тему? Тем более,
что не раз уже обсосано про APC PHP accelerator и MCache. Если уж
так волнует производительность, почему не потрудиться прочитать
о средствах её поднятия?

я правильно понимаю, что ты действительно не видишь (не хочешь видеть) разницы в количестве телодвижений (соответсвенного процессорного времени), потраченного жабой и ПХП на путь от принятия сокета до точки входа в приложение? в жабе это инстанциирование объекта HttpRequest и передача его в статический метод сервлета. в ПХП это подгрузка и линковка сотен килобайт - хорошо, опустим компиляцию - байт-кода.

>> Я не говорю о домашних страницах и гордо так называемых "порталах"
с 3-4 сущностями (юзер, пост, коммент).

> А чего так бедно с воображением? Стремление умышленно принизить
кого-то говорит о наличии комплекса неполноценности.

еще раз для тех кто в танке - я никого не принижаю. я привожу пример тех систем, для которых - ввиду простоты архитектуры - ПХП вполне себе решение.

> Уровня Hibernate может и нет, но есть ведь propel, ez_pdo, DB_DataObject. Их вполне достаточно в большинстве случаев.

Понятно, то есть потребности в колбасе нет. Я в курсе о существовании этих систем, более того, я их все пробовал. propel после диких приседаний с его phing-правилами, которые по умолчанию требуют для своей работы root прав (для записи нагенеренного кода к себе в /usr), рожает мегабайты (не шутка) кода. DB_DataObject - детская поделка, когда научится хотя бы many-to-many отношениям, можешь вспомнить ее вновь. лишь ez_pdo, действительно, хоть как-то вменяема.

все эти ORM страдают, например, тем, что требуют тщательного описания всех атрибутов объекта. о том, чтобы хранить что-то, невписывающееся в mysql типы (например, массив), не может идти и речи. конечно, это решаемо через геттеры/сеттеры, _постоянно_ делающие serialize/deserialize, но это немного напоминает секс в гамаке.

еще одна проблема связана с наследованием.
возьмем следующее дерево:
class Derived1 extends Base
..
class Derived99 extends Base
запишем пачку объектов этих классов в ezpdo.
в следующем HTTP запросе для выполнения операции типа Base::getById($id) потребуется подключение _всех_ 99 унаследованных классов, иначе создастся объект типа PHP_incomplete_object. это связано, опять-таки, с отсуствием в ПХП системы пакетов и стандартного класс-лоадера и чего-то вроде Class.forName(). итого, в ezpdo-системе, базовый класс должен иметь в себе перечень всех возможных потомков. шедевр ОО дизайна, ничего не скажешь.

>> Система _должна_ иметь средство для хранения полноценных бизнес-объектов (beans); а бизнес-объекты должны быть именно объектами, а не КОПИЯМИ друг друга на каждый HTTP-запрос.

> Кто это сказал? Одна бабка? А кто запрещает решать задачу другими
способами?

Работая с _копиями_ объектов, у вас всегда будут остаточные баги, связанные с синхронизацией. Я еще раз говорю - если пишется форум, то на это нас***ть. А если аукцион?
public synchronized bool placeBid(int newBid) {
if (newBid > this.bid) {
this.bid = newBid;
return true;
}
return false;
}
реализация подобной логики на ПХП либо чревата race condition, либо спагетти-кодом для синхронизации через базу. для одного метода - сойдет. для системы, в которой _не_на***ть_ на корректную многопоточность - это всё выливается в большой некрасивый код - и, напрямую, в повышенную концентрацию багов и повышенную стоимость поддержки.

> нука расскажите как запустить процесс который бы запускался именно через 5 минут после запуска предыдущего запуска (т.е. зависил от нагрузки)? т.е. если у меня процесс проработал 7 минут, не получилась так что еще не закончился первый процесс а уже запустился следующий ?

а.. зачем? модель какой бизнес-задачи заложена в такой логике? я бы написал что-то вроде:
public function run() {
for(;;) {
doSomething();
Thread.sleep(5*60*1000);
}
}
(опустил для читаемости try/catch)
спящий тред ровным счетом никому не мешает...

> опять глупость и недоразвитость java, права тривиально проверяет субд, мало того оракл может делать это с row level security или вообще c помощью label security, в java есть хотябы намеки на такие технологии чтоб работало с любой субд ?

у вас какая-то неразбериха в голове. я не говорю о доступе к записям в базе. я говорю о доступе к каким-то частям логики системы. юзер petya может вызвать контроллер ajax.GetLoggedUsersAsXml, а юзер vasya - нет.

далее, насчет статики. в жабе, за счет наличия чего-то, имеющего время жизни длиннее одного HTTP-запроса, реализуются пулы. хорошо, пусть не юзеров. пулы БД-соединений - в ПХП лишь для _некоторых_ баз есть костыли навроде mysql_pconnect, где какой-то дядечка заложил свою неизменяемую логику. или пул лог-файлов - в ПХП каждый поток считает своим долгом открыть себе персональный файл-дескриптор и писать в него. убогие даже и подумать не могут, что, вообще-то, для записи в один лог-файл достаточно одного файл-дескриптора и synchronized метода...

Оставив переругивание, попытаюсь подытожить характерные особенности ПХП по сравнению с жабой:

1. Нет частей системы, время жизни которых было бы более одного HTTP запроса.
- многие действия бессмысленно повторяются для каждого запроса, в частности загрузка кода и, чаще всего, коннект к базе
- отсутствие полноценно разделяемых данных (про memcached я в курсе - но данные это нечто большее, чем строки)
- отсутствие в языке IPC, в частности, средств синхронизации между потоками
+ лёгкая масштабируемость "вширь"

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

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

4. Библиотек и фреймворков меньше и они, в целом, беднее.

5. Очень хорошо разрекламирован, стоит на 99% хостингов, меньше начальные затраты (оверхед) на создание проекта
+ проще написать (и даже продемонстрировать) "hello, world" или другой мелкий пример

что-то забыл?

>>Frameworks/Specs&impls позволяющие создавать масштабируемы решения (читать кластеризация, прозрачна отказаустойчивость и т.д.)- PHP проигрывает.

>Тут не php проигрывает, а mysql который используют в большей части проектов для БД. Как надо будет так и появится под php, если уже не появилось, под Java это тоже не сразу родилось.

Причем тут mysql?
Кластеризацию можно делать и без БД.

>>Безопасность - PHP проигрывает.
>И чем же она проигрывает?! Тем что под php программят недоучки? Так и аод java таких найдётся туча.

См новый пост про очередную дыру в PHP.
Тут вопрос не в том, кто пишет на PHP, а в том кто пишет сам PHP.

>Стоимость поддержки - PHP проигрывает. >Стоимость разработки - PHP проигрывает (это к вопросу о качественных IDE).

>Да?! И чем же? IDE от zend есть, не хуже сановской или от MS.
Да?! А мне почему-то кажется что IDE от ZEND хуже чем IDEA или Eclipse или VS.

>Стоимость? Так все кажется убеждены что php дешевле. Всё зависит от программистов, так же как и с java, грамотный код IDE за тебя не напишет.

Знакомые пишут проект на PHP, ORM свой,template engine свой, mvc frame work свой... Спрашиваю - ПОЧЕМУ? Отвечают - все что есть на рынке бесплатно - слишком плохое (может врут? ).
Писали бы на java - в ORM, template engine,MVC framework были бы из коробки. Экономия на изобретении велосипеда.


>Вообще эти два утверждения высосаны из пальца, так же как про безопастность.

Поищи сколько дыр в безопасности PHP и в JAVA- сравни.

>1. Нет частей системы, время жизни которых было бы более одного HTTP >запроса. >- многие действия бессмысленно повторяются для каждого запроса, в >частности загрузка кода и, чаще всего, коннект к базе >- отсутствие полноценно разделяемых данных (про memcached я в курсе - >но данные это нечто большее, чем строки) >- отсутствие в языке IPC, в частности, средств синхронизации между >потоками

Про memcached Вы не в курсе, ибо это не только строки. Предлагаю прочесть http://ru2.php.net/memcache до просветления.

IPC - http://php.rinet.ru/manual/en/ref.sem.php

Таким образом первый пункт некорректен, бессмысленность же повторейний одних и тех же действий - интимные проблемы недопрограммистов, которые такое генерируют.

>4. Библиотек и фреймворков меньше и они, в целом, беднее. Сколько фреймворков Вы видели? а ещё луче - использовали и чем они Вас не устраивают? И Чего такого Вам не достаёт в PEAR и PECL ?

> я правильно понимаю, что ты действительно не видишь (не хочешь видеть) разницы в количестве телодвижений (соответсвенного процессорного времени), потраченного жабой и ПХП

А я правильно понимаю, что ты не прочитал написанного выше про APC PHP
accelerator и MCache? Почитай. Одну и ту же глупость спрашиваешь который раз.

> еще раз для тех кто в танке - я никого не принижаю. я привожу пример тех систем, для которых - ввиду простоты архитектуры - ПХП вполне себе решение.

Во чудак. Ты глянь на сайт, где мы сейчас общаемся - на LOR. И улыбнись.
Те самые три сущности... только на жабе ;))

> все эти ORM страдают, например, тем, что требуют тщательного описания всех атрибутов объекта.

А как ты себе представляешь иначе? Подключить телепатию?

> Работая с _копиями_ объектов, у вас всегда будут остаточные баги, связанные с синхронизацией

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

> либо спагетти-кодом для синхронизации через базу

Почему спагетти-кодом? Что мешает сделать не спагетти-код? Неубедительно совсем.

>Причем тут mysql? Кластеризацию можно делать и без БД.

Ну и воткни себе несколько серверов, всё зависит от задачи.

>См новый пост про очередную дыру в PHP. Тут вопрос не в том, кто пишет на PHP, а в том кто пишет сам PHP.

Тебе про яву на той неделе пост в новостях поискать?

>Да?! А мне почему-то кажется что IDE от ZEND хуже чем IDEA или Eclipse или VS.

Возьми и посмотри, с их сайта можно скачать trial, ограниченную только по времени.

>Знакомые пишут проект на PHP, ORM свой,template engine свой, mvc frame work свой... Спрашиваю - ПОЧЕМУ? Отвечают - все что есть на рынке бесплатно - слишком плохое (может врут? ). Писали бы на java - в ORM, template engine,MVC framework были бы из коробки. Экономия на изобретении велосипеда.

Потому что твои знакомые любители изобретать велосипед, пускай возьмут smarty и mojavi (можно не только их, под php полно всего).

>Поищи сколько дыр в безопасности PHP и в JAVA- сравни

Тут один товарищь уже ссылку на секуриты лаб давал, как в лужу пёрнул.

> Я в курсе о существовании этих систем, более того, я их все пробовал.

А тогда вопрос: что заставило заниматься php при наличии стойкой
неприязни к нему?

Выше анонимусы уже вполне доходчиво объясняли, я к ним тоже присоеденюсь.

>2. нетипизированность языка - проще пишется г***нокод, язык к этому подталкивает - быстрее растет энтропия архитектуры - затруднен анализ и рефакторинг - требуется более плотный контроль над проектом со стороны архитектора + проще освоить быдлокодерам + проще, в случае чего, написать костыль (исключение, не ложащееся на построенную модель)

Про IDE я уже сказал, плюс phpdocumentor (и его стандарт, его поддерживает IDE от zend) за пример для которого брали javadoc, придерживаться стандартов комментариев, определения переменных и всё будет нормально. А под JAVA все такие правильные, они лучше убьют месяц ненужной работы, всё будет работать через одно место и с такой же скоростью, но ИДЕОЛОГИЧЕСКИ верно, а оно надо? Как я уже сказал это не проблема языка, а кодеров, на JAVA тоже можно понаписать г** код.

>3. бедность языка

Поподробнее, что он не позволяет сделать что его так можно обозвать?

>- неполноценные исключения

И чего там не хватает.

>- отсутствие generics

Это что-то наподобии templates в C++? Насколько я знаю да, и если это так, то внимание вопрос, зачем мне в мягко типизированном языке это нужно?

>- отсутствие лямбда-выражений и анонимных классов - отсутствие системы пакетов и класслоадера

Оно ему это надо? Тем более лямбда-выражения есть, по поводу анонимных классов не скажу, не пробовал.

>- отсутствие стандартной библиотеки для таких абстрактных вещей, как Collection и т.д. SPL - некоторый шаг в эту сторону.

Опять же, насколько я знаю Collection это что то вроде динамичиских шаблонных массивов? Опять же вопрос нах***на языку с мягким типисзированием (или вообще без него) это нужно?

>- отсутствие стандартной библиотеки для таких абстрактных вещей, как Collection и т.д. SPL - некоторый шаг в эту сторону.

>Опять же, насколько я знаю Collection это что то вроде динамичиских шаблонных массивов? Опять же вопрос нах***на языку с мягким типисзированием (или вообще без него) это нужно?

Как бы догонку, ему это не нужно, потому что там и так это можно сделать, в массив запихнуть всё что хочешь.

ЗЫ А по поводу ООП и т.д. надо просто брать и смотреть возможности 5ки, и все будут рады.

ЗЗЫ И вообще, отстуствие таких воозможностей как ,например, анонимные классы, явно не влияет на возможности PHP как языка для web и его масштабировани. Те же анонимные классы, насколько я знаю используются (да и придумывали их) в основном для swing'а. Большой класс явно на них не сделаешь, и применять его не сможешь.

>у вас какая-то неразбериха в голове. я не говорю о доступе к записям в базе. я говорю о доступе к каким-то частям логики системы. юзер petya может вызвать контроллер ajax.GetLoggedUsersAsXml, а юзер vasya - нет.

ну нельзя быть таким серым, речь не только о записях, речь о правах на pl/sql пакетов, функций и прочим частям приложения.

>далее, насчет статики. в жабе, за счет наличия чего-то, имеющего время жизни длиннее одного HTTP-запроса, реализуются пулы.

теже пулы используют и в пхп, в чем проблема ?
http://freshmeat.net/projects/sqlrelay/

>в ПХП каждый поток считает своим долгом открыть себе персональный файл-дескриптор и писать в него. убогие даже и подумать не могут, что, вообще-то, для записи в один лог-файл достаточно одного файл-дескриптора и synchronized метода...

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

Action.

>2. нетипизированность языка
убогенький, тебе сказали же, что пхп это только уровень представления, вся бизнес логика должнабыть в pl/sql. на уровне представления типизированость жабы только тормоза и куча лишнего кода.

>3. бедность языка
на уровне представления пхп делает одной командой то, что в жаве приходится приходится делать десяткми строк, на уровне бизнес логики опять же 3 строчки pl/sql сделают, то что в джава и в сотнб строк неуложится

>4. Библиотек и фреймворков меньше и они, в целом, беднее.
ну и нахера на этом уровне что-то сложнее MVC ?

Action.

> Про memcached Вы не в курсе, ибо это не только строки. Предлагаю прочесть http://ru2.php.net/memcache до просветления.

Звонко пукнул, молодец. Предлагаю тебе самому прочесть http://ru2.php.net/memcache до просветления. В частности про то, что object and other non-scalar types are serialized before saving, so it's impossible to store resources (i.e. connection identifiers and others) in the cache.

_Разделяемые_ данные - это, как минимум, когда в одном потоке я говорю $a=5, а в другом print $a выводит 5. memcached же ничем не лучше tmpfs поднятой на /var/tmp и записи сериализованных строк в файлы.

> И Чего такого Вам не достаёт в PEAR и PECL ?

Ну не смешно, право слово. http://pear.php.net/packages.php
Total number of packages: 368

Можно мне библиотеки для соединения с Yahoo IM и MSN IM? Пишем систему аукционов, надо нотификейшены биддерам отправлять. Заодно расскажите, как сделать, чтобы нотификейшены отправлялись отложенно в фоне, и переотправлялись через минуту при неудачной отсылке? Не надо только про ignore_user_abort(), пожалуйста :)

Из более общих вещей - не хватает ORM. Все как-то велосипеды приходится писать, к сожалению.

Не ответил, почему на php переквалифицировался ;)

> Во чудак. Ты глянь на сайт, где мы сейчас общаемся - на LOR. И улыбнись. Те самые три сущности... только на жабе ;))

....и что? Я тоже могу трюизм ввернуть. Волга, например, впадает в Каспийское море. :)

>> все эти ORM страдают, например, тем, что требуют тщательного описания всех атрибутов объекта.

> А как ты себе представляешь иначе? Подключить телепатию?

В моей PHP ORM, например, корректно сохраняются и восстанавливаются все свойства объекта. Реализовано посредством reflection и отдельного BLOB поля в таблице. Не требует от программиста _никаких_ дополнительных телодвижений. Для прозрачного хранения таких данных, как, например, дерево разбора выражения - решение незаменимо.

Собственно, озвученные мною выше ORM проблемы - это те, которые я встретил в существующих публичных ORM и в своё время успешно решил. Ничего особо сложного в этом не было. Моей поделке при этом до Hibernate и даже до рельсовой Active record весьма далеко. К чему я это все? Просто это показывает удручающе низкий уровень свободных библиотек для PHP. Все раз за разом пишут велосипеды.

> Почему спагетти-кодом? Что мешает сделать не спагетти-код? Неубедительно совсем.

Потому что любая синхрониазция в самом лучше случае будет реализована не одним ключевым словом, а чем-то вроде:

$o->lock(); // например, LOCK TABLES ...
try {
//
// do something in critial section
//
$o->unlock();
} catch (Exception $e) {
$o->unlock();
throw $e;
}
тут же, кстати, виден дибилизм копи-маста, вызванный отсутствием в ПХП finally. я уж молчу, что будет, если потребуется сихронизация двух объектов..

> А тогда вопрос: что заставило заниматься php при наличии стойкой
неприязни к нему?

Да нет особой неприязни. Есть просто отстутствие шор на глазах, улюлюканья и бросания чепчиков, а также желание почесать языком с не самыми глупыми, я надеюсь, людьми. :)

Занимаюсь ПХП по роду дейтельности - некрупный оффшор; да и дешевые подконтрольные программисты, по большей части, все равно ничему другому не обучены :)

> на уровне представления пхп делает одной командой то, что в жаве приходится приходится делать десяткми строк, на уровне бизнес логики опять же 3 строчки pl/sql сделают, то что в джава и в сотнб строк неуложится

гм. примеры будут, или как обычно?

ладно, идея понятна - всю какую-никакую серьезную логику держать в pl/sql. не буду спорить, такой подход действительно имеет право на жизнь. хотя напомню, что в статье, которую мы комментируем, афтар выбрал mysql.

> и даже до рельсовой Active record весьма далеко.

А что такого интересного есть в рельсовой Active record. Я что-то не
заметил особо выдающихся моментов.

> Просто это показывает удручающе низкий уровень свободных библиотек для PHP

Ну, не скажи. Есть неплохие вещи. К примеру html_quickform. Для какого
языка есть что-то подобное?

>Вот тебе пример кстати кода который работает под 3.X-5.0.X if (preg_match_all('/regexp here/',$haystack,$matches=array())) doSomething(); Давай теперь переезжай на 5.1.X.

Тоже наткнулся на эту граблю, написал на багтрекер - ответили: Set error_reporting to E_ALL|E_STRICT and you'll see the error message. А вот и ишибка:

PHP Strict Standards: Only variables should be passed by reference in...

Тоесть такая конструкция есть ошибочна в ПХП, а в ПХП5.1.2 кажется проверку на эту граблю ужесточили.

Кстати такой код свойственнен програмистам которые до этого писали на типизированых языках, ИМХО, как и я :) Такчто RTFM как всегда...

gmarik эт gmail дот com

Чтобы писать на пхп не нужны мозги. А для жавы нужны. Поэтому наверное у тебя и проблемы с жавой... :))

southern_sun > - многие действия бессмысленно повторяются для каждого запроса, в частности загрузка кода и, чаще всего, коннект к базе

встроенных возможностей, да не хватет, но(!) есть сторонние разработки, например SRM (www.vl-srm.net). на русском http://tony2001.phpclub.net/doc/srm/user.introduction.html и еще, если вы чего-то не знаете, то не говорите так категорично. а если этого действительно нет, напишите. и вообще что за глупость сравнивать java vs php, у всех свои задачи и области применения. от себя могу добавить, в бысто меняющимся мире особенно когда у клиента "горит" (бизнес загибается) он долго ждать не будет (время-деньги), ему рентабельнее платить php-разработчику.

Нет, не хуже масштабируется.
Но при расчёте вполне можно держать весовые коэффициенты:

Perl потребует масштабирования на кол-ве пользователей примерно в 10 раз бОльшем, чем ПХП.
Ява протянет без масштабирования в 5-10 раз дольше Перла.
.NET - в 1,5-2 раза больше Явы.

> Да-да :) Раскажи это не-фанатикам жабы. Кстати, если уж о сложности, то если некая задача на перле была реализована в 20 строк, а на жабе -- в 20 классов, то попроще будет перл, наверное... Давай по-другому посчитаем. 20000 строк на перле и 20000 строк на Java. Разными разработчиками. С "читабельными" регекспами, которые в Перле используются по поводу и без повода. Ы? :)

Несомненно, код на Java сделать нечитабельным и неподдерживаемым можно, но почему на Перле такого кода больше?

PS Кстати, Руби типизированный?