Чем же плох PHP ?

Прояснение ситуации:
самое похабное - то , что PHP совмещает дизайн с кодом..
то есть ну нельзя в нём работать над большими проектами, (ну нет, то есть конечно можно..
но существует вероятность, что к концу проекта из 2 команд "верстальщики" и "программеры" 
выживет сильнейшая..а другая будет разорвана на куски после продолжительных ссор...)

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

PHP можно и даже прикольно применять вот где:
например первая страничка сайта с простенькими программными вставками...типа, например, демонстрации произвольного
рекламируемого продукта из списка...(ну в общем...с одной стороны требуется немного программного кода, а с другой 
 стороны вроде как первая страница сайта, толпы народа ходят..сервер перегружать не хоца)
А PHP если его вообще без всего лишнего собрать он чуть меньше памяти жрёт, и если кода мало, то и бегает быстро оченно..

Ну это то, что сразу в голову приходит...а когда я учил этот язык, после перла, и джавы с сервлетами,
и пару вещей на нём сделал, мне очень много всего ОЧЕНЬ не нравилось.

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

Ну вот пока и хватит.

anonymous
(23.01.01 03:06:06 UTC)

Ссылка

Единственный довод, который я услышал - про то, что код и дизайн лежат вместе. Но никто не мешает хранить в файле только код а элементы дизайна почитывать снаружи, например, из той же MySQL. Чем не решение? Более того, там же можно хранить и куски кода (модули). Что народ скажет по этому поводу?

ShadowJack ★
(24.01.01 15:25:28 UTC)

Ссылка

По поводу хранения в mySQL реального наполнения сервера. Тут был один случай. Пареньку его провайдер выделил только 4Мб для домашней страницы и разрешил использовать mySQL. Так вот он все картинки, mp3, архивы программ, html-страницы - ВСЕ запихал в mySQL. И ничего у него на аккаунте свободно 3Мб. Правда его сейчас попросили съехать и у него проблема. Как ВСЕ это вытащить если всего в аккаунте 4Мб. Вот такие дела. А по поводу PHP. Если проект маленький, то ему там самое место и язык быстро учится и html-верстка. Так игрушка или если надо быстро сделать прототип реального сервера. Пишешь на PHP. Показываешь. Получаешь добро. Переделываешь на НОРМАЛЬНЫЙ язык и НОРМАЛЬНУЮ базу данных.

Korwin ★★★
(25.01.01 04:02:24 UTC)

Что же у нас счтаетя нормальным языком?

ShadowJack ★
(25.01.01 14:56:42 UTC)

Ссылка

Ответ на: комментарий от Korwin 25.01.01 04:02:24 UTC

2 Korwin: Yo, man...exactly...my point..
2 ShadowJack..
  Не в этом суть...Templates - единственный возможный вариант создания чего-нить большого..
где там ни храни графику и дизайн...хоть в MySQL, хоть где.. суть не изменится..
у меня в перловом скрипте нет...и не бывает ни одного хэтээмэльного тэга..
ваапче...я не завишу от дизайнера дизайнер не зависит от меня..

anonymous
(26.01.01 02:10:44 UTC)

Ответ на: комментарий от anonymous 26.01.01 02:10:44 UTC

2ShadowJack: Perl, Java (Servlets + Velocity) но не jsp...отстой того же плана что и PHP

anonymous
(26.01.01 02:12:55 UTC)

Ссылка

А что мешает в JSP всю логику выносить в бины, разделив таким образом логику и дизайн?

Havoc ★★★★
(26.01.01 11:46:46 UTC)

Ответ на: комментарий от Havoc 26.01.01 11:46:46 UTC

Скажи мне Havoc...а если мы в них насильно выновим всю логику в бины...
то зачем они..jsp?????
Мы просто переходим от них к template'ам...несколько в извращенной форме конечно..
так почему бы не юзать сразу темплэйты...
Темболее не слишком вынесешь ВСЮ логику в бины (в jsp)...(без единого тэга в програмной части)

anonymous
(26.01.01 13:12:14 UTC)

Ссылка

Тогда ты по аналогии в сервлетах тоже будешь вынужден писать тэги, что не есть хорошо.
С JSP всетаки легче при необходимости дизайн поменять, не трогая код.
Да и на PHP можно шаблоны юзать, и как ни странно, даже на C++

Havoc ★★★★
(26.01.01 17:59:56 UTC)

Ответ на: комментарий от Havoc 26.01.01 17:59:56 UTC

2 Havoc:
Ну что ты...какие тэги я буду писать?
perl file:
$template->param('myvarname', 'my value');
$template->output();

Template file .. something.ht
<HTML>
<TMPL_VAR NAME="myvarname">
</HTML>

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

А зачастую просто заранее договариваемся какие будут переменные и что выводить,
и пока я пишу код..всё уже рисуется и полностью свёрстывается..

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

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

а вы хотите ишо в начало добавить другой шаблон... хмм..

да и на C/C++ тоже можно шаблоны юзать... только веб приложения писать на нём геморойно..
кстати и на ассемблере тоже можно..

вот..

anonymous
(27.01.01 03:01:22 UTC)

Ссылка

2ShadowJack - нормальный язык.
Во первых (пожалуй самое главное) язык на котором ты умеешь ПИСАТЬ БЫСТРО и БЕЗ ОШИБОК программы.
Во вторых. Скорость выполнения этой программы (необходимо учесть, что при работе в паре с ВЕБ-сервером(Апачь например) скорость зависит также от способа обмена данными между ними).

К последнему анонимосу присоединяюсь. Писать на C/C++ веб-приложения веселенькое занятие. Мешают две вещи. 1 - отсутствие необходимых библиотек (сравните с CPAN). 2 - Сложность тестирования и дебагинга.

Поэтому дабы не отклоняться от subj. Можно сказать - PHP хорош для небольных, проектов. Быстрого написания веб-оболочек для доступа к базам данных и т.д. и т.п. которые будут использоваться для внутренних служб. По поводу скорости между Perl vs PHP. Можно сказать так: PHP многие вещи делает быстро, но когда речь заходит о сложной логике и работы с большими циклами, то он хорошо отстает от Perl.

А еще есть такая класная штука как ASP-perl, html-embeded-perl которые можно подключить с тем же mod_perl. Вот и думайте господа что использовать, а что нет.

Удачи в реализации творческих планов.

Korwin ★★★
(27.01.01 04:02:19 UTC)

Ответ на: комментарий от Korwin 27.01.01 04:02:19 UTC

ну Korwin..ну зачем же так опошлять???????.
ну зачем было вставлять этот ASP-perl и embedded perl..от этого как раз уходить надо!!!

anonymous
(28.01.01 04:01:40 UTC)

Ссылка

Ну почему же надо рассматривать возможность объединения кода и дизайна в php как что то главное, что необходимо обязательно использовать! Это же только одно из достоинств PHP, одна из его возможностей! Да, задумывался он именно для объединения и дизайна/кода, но разве php не перерос в более серьезную вещь? Работа php даже на глаз существенно быстрее perl. И хотя синтаксис мне больше нравится в перле... Но из за скорости я всетаки склоняюсь к php. К тому же работа с базами данных несколько упрощена. И неужели php при большом объеме вычислений тормознее perl ? И может стоит смотреть на php4, который всетаки был оптимизтрован? Где недостатки php? Огромное спасибо за все ответы!!!

aim ★
(28.01.01 16:50:15 UTC) автор топика

Ссылка

Все очень просто --- нравится пользуйся. Если босс не велит, чтож пользуйся чем-либо другим или попробуй переубедить.

P.S.
Вот она, свобода выбора... Наслаждались? А теперь мучайтесь... :-)

Korwin ★★★
(29.01.01 00:25:54 UTC)

Ответ на: комментарий от Korwin 29.01.01 00:25:54 UTC

ну какое же это преимущество и достоинство...объединение дизайна с кодом????
это же просто изиняюсь отстой!
но это ладно...
PHP - быстрее перла только в простых задачах и оптимизирован пэхэпэ 4-й
был кстати скорее под облегчение процессинга страницы и отделение того самого кода от дизайна..

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

в php добавлено куча ненужных функций по работе с бд...именно ненужных, которые вы изволите именовать облегчением работы с БД..
ну куда это годится если все инпуты в форме автоматически получают одноимённые переменные в скрипте????????
ну вать машу...ну и тд.
Ещё раз повторюсь...PHP хорош на первой странице сервера, где нужно реализовать какую-нить простейшую динамику,
и не хоца сервер мучать кучей запусков перла...(и это только если скомпилить PHP без всего чего только можно..то бишь оставив один лишь скелет)

далее перл - в некотором роде строгий язык...(ну понятно не как с)
но в общем и целом. особенно после use strict. :))
а люди которые начинают программить с php - производят на свет такие создания,
после просмотра которых хочется вообще бросить программирование и перейти к работе мусорщиком в макдональдсе,
как к более интелектуальной.

вот..

anonymous
(29.01.01 03:15:16 UTC)

Ссылка

А лучше вообще перейти на DB Oracle 8i (9i). Ведь он имеет отличные средства позволяющие при доступе к базе данных через веб генерить страницу налету. То есть есть таблицы с данными и есть таблицы с шаблоном. Все очень просто. А есть еще специальная фича типа интернет-каталога. Просто кидаешь в нее файлы, как на фтп и у тебя появлятся возможность работать с ними через SQL-запросы. Вот тебе и индексация .html, .pdf, .txt, .rtf, .doc и т.д. А поскольку работа идет в самой базе данных и код является уже закомпелированным (можно писать на C, C++, PL/SQL, Perl, Java), то и выполняется он очень быстро. Не стоит забывать еще и функции кеширования не только таблицных данных, но и результатов выполнения этих подпрограмм (если указать особо). Поэтому все что нужно при работе с ДБ Оракл - это создать структуру данных, нарисовать шаблоны, написать пару-тройку процедур и все. Можно просто обновлять данные в таблице. Вся статистика есть. Для дизайнера милое дело, он может перепроверять хоть сотни вариантов дизайна не мешая нормальному функционированию сервера.
Эх жалко только что все это не для обычного юзверя - уж больно лицензия дорога. Вот если бы mySQL сделало что-то подобное, но у них этого нет впланах. Даже улучшенная поддержка стандарта SQL ANSI99 у них стоит на последнем месте :-( (смотри список TODO).

Korwin ★★★
(29.01.01 11:22:22 UTC)

Ссылка

Похожие темы