In <Pine.LNX.4.21L0.0001241308530.31066-100000@xxxxxxxxxxxxxx> Victor Wagner (vitus@xxxxxx) wrote:
VW> On Mon, 24 Jan 2000, Khimenko Victor wrote:
>> VW> Заточенность php под web. Сложная система управления контентом как правило
>> VW> включает в себя не только web-интерфейсы. То же самое конфигурирование
>> VW> апача, пакетные интефейсы репликации и резервного копирования, интерфейсы
>> VW> для доступа к базе данных локально (необходимы для раскрутки системы и
>> VW> лечения серьезных сбоев), различные кроновские задания, то самое
>> VW> конфигурирование web-сервера, с которого весь шум начался.
>>
>> Ну и кто мешает вам все это сделать на PHP ? Если уж вам ТАК нужно
>> конфигураировать web-сервер, что вы об этом в перечне проблем дважды написали,
>> то кто мешает потратить день (один, от силы два) и перенести все необходимые
VW> Ровно то, что на perl я сделаю это за два часа. Если уж тратить _дни_, я
VW> лучше возьму за основу python или tcl. Только вот начальство мне этих дней
VW> не даст.
Ваши проблемы :-) Если вы не можете объяснить начальству, что выиграв сейчас
два часа оно потом потеряет не одну неделю, то что тут можно поделать...
>> запчасти из mod_perl'а в php ? Все пакетные интерфейсы и интерфейсы для доступа
>> к базе локально также пишутся на PHP (конечно нужно будет binding GTK сделать).
VW> Это еще зачем? Почему именно GTK? Потому что он столь же моден, сколь и
VW> php? Нет, я лучше что-нибудь нормальное возьму - Motif, Tk или Xview. fltk
VW> или xforms на худой конец.
А чем GTK менее нормален, чем Motif или Tk ?
VW> Хотя в данной конкретной задаче больших преимуществ у локального GUI
VW> перед web-интерфейсом нет. Локальные инструменты имеют преимущество тогда,
VW> когда им GUI нафиг не нужен.
VW> и т.д. В конечном итоге если чуть-чуть (не сильно) копнуть, то выяснится,
>> что у Perl'а есть РОВНО одно преимущество - CPAN. Сильное преимущество,
VW> Ты сказал.
>> согласен - без него Perl вообще не было бы смысла использовать. Но вот
VW> Хмм, но почему-то его же начали использовать. Причем настолько активно,
VW> что написали CPAN.
Ну Windows тоже почему-то начали использовать и тоже много чего понаписали :-)
>> преищуство ли это ЯЗЫКА ? Не думаю. Конечно PHP моложе и пока не смог накопить
>> такого количества готовых запчастей. Но не смог накопить и такого количества
>> "quirks" (типа "my" и "local" - лучше использовать"my" но для некоторых
>> переменных "my" использовать нельзя, например для $_).
VW> Нет, как язык perl безобразен. Согласен. Проблема в том, что php не лучше.
VW> Он, как и perl создавался на основе концепции "возьмем все, что нам
VW> нравится и свалим в кучу". Python, tcl и Scheme этим недостатком не
VW> страдают.
Да ну ? Все может быть. Только вот "C" создавался точно также - путем сваливания
в кучу разных свойств разных языков. А Pascal вот был спроектирован. Как и Ada.
Вы на Ade пишете или на Pascal'е, когда нужно, чтобы было быстро и ни Python,
ни TCL ни Scheme "не катят" ? То, что язык сделан из надерганных кусочков еще
ни о чем не говорит. Важно еще кто эти кусочки выдергивал и как сваливал :-)
>> И кто мешает все это сделать на PHP ? Не понимаю...
VW> Отсутствие у php каких-либо преимуществ перед тем же perl и наличие
VW> по крайней мере одного недостатка - отсутствия CPAN.
Преимущества у PHP вполне очевидные: там нет завязки на глобално-локальные
переменные (типа $_ и @_), которые, с одной стороны, глобальны (исторически
сложилось), а с другой - локальны (используются часто by default в разных
местах). Из-за этого много разного веселья получается. Есть в perl'е и другие
грабли, которых в PHP нет (есть правда и в PHP свои грабли, например отсуствие
отдельных операций для сравнения строк и чисел, но они более локальны).
Перевешивают ли эти достоинства CPAN - нужно в каждом конкретном случае решать
отдельно, а решать за всех - что им использовать и когда.
"Russian Apache" includes software developed
by the Apache Group for use in the Apache HTTP server project
(http://www.apache.org/) See
Apache LICENSE.
Copyright (C) 1995-2001 The Apache Group. All rights reserved.
Copyright (C) 1996 Dm. Kryukov; Copyright (C)
1997-2009 Alex Tutubalin. Design (C) 1998 Max Smolev.