Опрос от создателей PHP: Зачем Вам нужен PHP?

[wanderer]

а про мелкософт это правда, что будет ежегодная оплата???!!! если да, то они сильно заелись....
правильно говорят: 95, 98 - это не версии, это количество багов... в процентах

 

[alex]

Сколько программирую для инета - не видел ничего проще и лучше РНР.
особенно радует возможность включения кода прямо в html страницы без особого труда. И отсутствие cgi-bin

 

[Alexandre]

я вот тут намедне немного попрактиковался в ДАО помедитировал и пришел к выводу....

Бренд у ПХП есть (и возможно уже оформленный ), теперь под это дело надо денежек подзаработать..... А почему бы и нет, ребята правы.

А почему бы не оставить "исходный движок" в первоначальной комплектациии в исходниках и фрееваре, а начать разрабатывать полноценную интегрированную среду ПХП (короче говоря ZendStudio будет теперь обзываться PHPStudio-) а за любое использование названия PHP в программных продуктах сторонних фирм (типа PHPEdit или PHPCoder) брать денежки....
на этом можно хорошего бабла срубить....

но сдругой стороны

На текущий момент есть все исходники...

время то всем движит и завтра (ну сморозил не завтра а послезавтра) эти исходники устареют... кому-то из нас их придется дорабатывать... лично мне это в одиночку не потянуть....

 

[Grey_EM]

Автор оригинала: admin
Что вы так всполошились... %)
На текущий момент есть все исходники...
Даже если выйдет ком.версия PHP все равно будет
развиваться текущая ветка....

Zend сейчас на таком уровне развития что наличие исходников уже ничего не решает. Ну возьмешь ты эти мегабайты кода, ну и через какое время ты сможешь сделать что-то осмысленное, разобраться в архитектуре?
Почитай скажем http://www.consumer.nm.ru/osp_svk2.htm

Реальная проблема --- это понимание программ. Всегда неплохо иметь исходники, но проблема состоит в том, что зачастую этого недостаточно

Каждый, кто участвовал в крупном проекте по реконструкции программного обеспечения, навсегда запомнит чувство беспомощности и потерянности, которое испытываешь, когда впервые видишь гору плохо документированных (хотя не всегда плохо написанных) исходных текстов. Доступность исходных текстов не сильно поможет, если отсутствует доступ к ведущим разработчикам. Если программа или система написаны на сравнительно низкоуровневом языке, вроде C, Cobol или Fortran, и плохо документирована, то все основные проектные решения растворились в деталях кодирования и требуют реконструкции. В таких ситуациях ценность документации более высокого уровня, такой, как спецификации интерфейсов и описание архитектуры, может превышать ценность самого исходного текста.

Такое осознание неадекватности исходных текстов для понимания программ привело к попыткам объединить код и документацию более высокого уровня. Одна из наиболее известных попыток такого рода была предпринята Дональдом Кнутом (Donald Knuth), см. его статьи в книге Грамотное программирование [Literate Programming.--- Stanford, Calif.: Center for the Study of Language and Information (CSLI), 1992]. Возможно, самой известной запрещенной книгой в истории компьютерных наук была книга [Lions' Commentary on Unix], которая содержала высокоуровневое описание исходных текстов Unix наряду с используемыми там алгоритмами. Она нелегально копировалась и распространялась в течение более чем двадцати лет с момента ее первой публикации в 1977 году.

Сложность и объем фактически "закрывают" исходные тексты системных проектов, вроде ОС и компиляторов после превышения ими объема, скажем, в 100 тысяч строк, при условии, что отсутствует документация высокого уровня, и Вы не принимали личного участия в проекте с его ранних стадий. Такая "бинаризация" исходных текстов в крупных системных проектах может означать, что стратегическая важность сохранения исходных текстов закрытыми может теряться после того, как проект достигает некоторого уровня зрелости, а также соответствующего этой стадии разработки размера и уровня сложности. Настоящие конкуренты всегда были в курсе происходящего по ту сторону баррикад, от нехватки информации всегда страдали, в основном, разработчики прикладных программ.

Этот подход, вероятно, наиболее жизнеспособен (но не ограничивается) программными продуктами вроде операционных систем, когда разработчики приложений могут получить существенные выгоды от легкого доступа к важной информации, позволяющей упростить отладку. Как таковой, он может считаться вариацией на тему принципа "важности наличия пользователей", обсуждавшегося ранее, поскольку приложения --- это золотой ключик, открывающий дорогу в царство пользователей. А как тонко отметил в свое время Генрих IV (сменивший вероисповедание для того, чтобы стать королем Франции --- прим. автора): "Париж стоит мессы".

Более того, сложность зрелого программного продукта служит "барьером вхождения" для конкурентов почти так же эффективно, как "подписка о неразглашении" (Non-Disclosure Agreement, NDA, которая, вообще говоря, не создает непреодолимых трудностей в доступе к исходным текстам продукта, а является лишь некоторым дополнительным ограничением, дополнительным барьером для доступа к исходникам). Скорость разработки некоторого коммерческого продукта может сделать незаконное присвоение фрагментов кода не столь привлекательным, как это может показаться на первый взгляд, особенно в случае, когда конкуренты тоже достигли определенной зрелой стадии, но основанной на других архитектурных решениях.

Кстати всем рекомендую почитать, также как и головной документ "Собор и Базар". Фактически это манифест open-source движения.
P.S. Я уже поднимал волну на эту тему. Крайне нежелательно для open-source проектов когда почти все находится в руках только двух человек. Что будет скажем когда оба дадут дуба?

 

[tony2001]

>Zend сейчас на таком уровне развития что наличие исходников
>уже ничего не решает. Ну возьмешь ты эти мегабайты кода, ну
>и через какое время ты сможешь сделать что-то осмысленное,
>разобраться в архитектуре?
да ну, не все так плохо.
на данный момент исходники лежат на каждом шагу и каждый второй админ/программер, который собирает их туда заглядывает.
при этом каждый десятый че-то свое дописывает (примеры: anight, su1d).
имхо не все так плохо, ЕСЛИ ВДРУГ ЧТО-ТО СЛУЧИТСЯ, то продолжить разработку можно.
другое дело, что сам факт коммерциализации - это уже нехорошо.
для нас.
будем надеяться, что зендовцам хватит ума.

 

[Crazy]

Я бы оценил процент дописывающих не в 10%, в в 0.01%

 

[Артем]

вот и я хотел сказать. если php станет платным zend заменит кто-то другой и все.

 

[Ямерт]

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

Дорога в ад вымощена кирпичами благих намерений.

 

[aloner]

Автор оригинала: Alexandre
Бренд у ПХП есть (и возможно уже оформленный ), теперь под это дело надо денежек подзаработать..... А почему бы и нет, ребята правы.

А почему бы не оставить "исходный движок" в первоначальной комплектациии в исходниках и фрееваре, а начать разрабатывать полноценную интегрированную среду ПХП (короче говоря ZendStudio будет теперь обзываться PHPStudio-) а за любое использование названия PHP в программных продуктах сторонних фирм (типа PHPEdit или PHPCoder) брать денежки....
на этом можно хорошего бабла срубить....

Полный бред написал.

PHP.net:
"PHP is a project of the Apache Software Foundation."

Zend делает IDE, Encode, Optimizer, Accelerator. PHP Зенд тоже делает, но как волонтер, а не хозяин.

 

[aloner]

Автор оригинала: Артем
вот и я хотел сказать. если php станет платным zend заменит кто-то другой и все.

mod_python(snake) / mod_ruby / mod_perl (!!!)

;-)

 

[aloner]

А вообще.

Никто PHP платным не сделает. Может придумают HA/Enterprise-версию, с клатеризацией, балансировкой и т.п.

А сам PHP - нет. Потому что подобных языков для веба хватает.

P.S. Кстати, вставка в HTML PHP - самое уродливое из его достоинств. Гы.

 

[Ямерт]

Автор оригинала: aloner
А вообще.

Никто PHP платным не сделает. Может придумают HA/Enterprise-версию, с клатеризацией, балансировкой и т.п.

А сам PHP - нет. Потому что подобных языков для веба хватает.

Хватает? Мне так не кажется.
Perl архаичный, ASP как минимум медленный, JSP для маленьких проектов годится явно хуже чем PHP.

P.S. Кстати, вставка в HTML PHP - самое уродливое из его достоинств. Гы.

Так ведь никто не просит эту самую вставку использовать

 

[aloner]

Автор оригинала: Ямерт
Хватает? Мне так не кажется.
Perl архаичный, ASP как минимум медленный, JSP для маленьких проектов годится явно хуже чем PHP.

LOoOL!

Ты очевидно имеешь весьма слабое представление о Perl и JSP.

Perl - архаичный? Есть перлисты тут? Ма-а-ачи!

Видишь ли, для маленьких проектов годится и Парсер от АЛГ. На JSP нет смысла писать гостевую книгу на страничке Васи Пупкина. Он совсем под другие задачи создан.

А языков хватает, смотри тут:
http://dmoz.org/Computers/Programming/Internet/Server_Side_Scripting/

и не говори, что не видел. =)

 

[Crazy]

Автор оригинала: Ямерт
Perl архаичный

Что в нем архаичного?

ASP как минимум медленный

В самом деле? Насколько и на каких задачах?

JSP для маленьких проектов годится явно хуже чем PHP.

В чем конкретно заключаются недостатки JSP в мелких проектах и где проходит водораздел между крупными и мелкими проектами?

 

[aloner]

О, тяжелая артилерия на подходе.

 

[Sirius]

Сколько людей, столько и мнений...

Мне бы дожить до 5-го релиза бесплатного PHP...

Я пришёл в ПХП будучи новичком перла... Скажу так - писать на ПХП удовольствие, писать на перле - мучение. Наверное поэтому многие перловские скрипты платные, а пхп - бесплатные...

 

[Ямерт]

Автор оригинала: aloner
LOoOL!
Ты очевидно имеешь весьма слабое представление о Perl и JSP.
Perl - архаичный? Есть перлисты тут? Ма-а-ачи!

А если поменьше эмоций и побольше встречных аргументов и фактов?
На Perl я писал 2 месяца, переделывая старый IRC-чат в новый. У меня создалось такое впечатление, что Perl ориентирован больше на обработку текста (регулярные выражения, и т.п.) - да кому я это говорю? Достаточно просто разобрать аббревиатуру названия. Архаичен не по возможностям, а по своим приоритетам.
Если задел чувства закоренелых перлистов, прошу воздержаться от кровной мести 2 месяца есть 2 месяца.

Видишь ли, для маленьких проектов годится и Парсер от АЛГ. На JSP нет смысла писать гостевую книгу на страничке Васи Пупкина. Он совсем под другие задачи создан.

Насчёт JSP - зачем повторять то, что только что сказал я?
Да, для малых сайтов годится хоть C, но по-моему главное в удобстве и лаконичности программирования, а не в самом принципе возможности реализации.

А языков хватает, смотри тут:
http://dmoz.org/Computers/Programming/Internet/Server_Side_Scripting/

Ты говорил о языках, *подобных* PHP, или вообще о языках для server-side Web-программирования? Если второе - да, есть другие. Но в любом случае, по популярности (которая о чём-то всё же говорит) лидируют всё те же PHP, ASP, JSP, Perl.

 

[Romantik]

Ну я думаю найдутся люди, которые на интузиазме будут продолжать другую ветку развития РНР, которая только может будет называться по другому....
по аналогии Sybase и MS SQL.

 

[Crazy]

Автор оригинала: Ямерт
На Perl я писал 2 месяца

Так. Диагноз ясен. "Я Пастернака не читал, но тоже категорически осуждаю".

Насчёт JSP - зачем повторять то, что только что сказал я?

Я выше задал конкретный вопрос. Судя по отсутствию конкретного ответа, с JSP ты знаком (если здесь применимо это слово) в той же степени, что и с Perl?

Как я понял, далее задавать тебе конкретные вопросы нет смысла?

 

[Ямерт]

Автор оригинала: Crazy
Что в нем архаичного?

Об этом см. в моём ответе на пост aloner.

В самом деле? Насколько и на каких задачах?

Думаю, если бы ты хоть немного поинтересовался этим вопросом ранее, сейчас бы его попросту не было. Отвечу.
1. Потому что сам принцип ASP - это COM-модель. Это лишнее время на работу с объектами.
2. Безобразная работа с памятью под Web-сервером IIS4 (важно учесть, ибо IIS официально неразлучный спутник ASP).
Частный случай, но всё же эта версия довольно часто встречается.
По первой причине ASP-скрипты тормозят при ВСЕХ задачах.
Конкретные цифры, зарактеризующие разницу в быстродействии между аналогичными скриптами PHP и ASP, можно найти в Интернете.

В чем конкретно заключаются недостатки JSP в мелких проектах и где проходит водораздел между крупными и мелкими проектами?

Медленно. PHP будет быстрей. А где проходит этот самый водораздел - об этом можно спорить долго