Что выбрать для WEB-программирования

perl устарел? )))))
это тебе php-coderы сказали?

Можно по-другому сказать: perl проигрывает java.
Выскажитесь у кого есть реальные проекты или может
кто перешел с Perl на Java или наоборот...

Как программист который писал на перле и сейчас пишет на ява:

Перл однозначно лучше =))))
На самом деле, я серьёзно - у явы есть куча глюков про которые
народ обожает умалчивать - кросс-VM несовместимость, странные
memory-leaks (есть в orion и resin, как минимум), неожиданные
тормоза и прочее... Вплоть до того что стандартные библиотеки
падают при масштабировании jpg размером больше 1280x1024 и
нет поддержки <form encoding="multipart">...

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

На сторонних проектах предпочитаю связку PLSQL+XSLT с прослойкой
из perl. то есть PLSQL выдаёт уже готовый XML =)

ICQ: 73038614 если интересует.

+1.

Автору:

Ява хороша для мобильников, и еще есть хорошая вещь JSF - но она сложная.

Перл для web - почти идеален.
Советую освоить HTML::Template/CGI/DBI/CGI::Session (если еще не знаешь, хотя я почему то увереня что знаешь) - больше тебе врядли нужно будет для такой простой задачи как локальный сайт.

Из Баз данных хорошо и просто используется mysql, но только для _простых_ задач, можно и таких у которых много данных.
Если задачи явно сложнее, то советую посмотреть на postgres.
Оракл я так понимаю тебе пока не грозит. (и не бросайся на него, тока мозги поломаешь)

PLSQL как уже было сказано очень и очень рулезная вещь, и XSLT конечно не отстает. но все можно делать и проще :)

Удачи.

Проще можно - но нужно ли? У меня в результате получается 100% разделение логики кода и визуализации....
mysql надо использовать только в одном случае - если по другому никак, например если это требование такое - чтоб работало
на стандартном хостинге...

Делал сайт знакомств, большой и навороченный, сам его не
админю - владельцам на меня денег жалко, так что он на mysql.
У них table corruption уже за год раз пять было....

Оракл рулит нипадеццки если есть друг с колокэйшном и ораклом...
У меня друга нет поэтому есть свой 1U сервер =))

XSLT - это сложно и не так тривиально как HTML::Template, но
это-таки стандарт....

Вообще советую сесть и помедитировать, выбрать конкретную область
которую собираешься покрыть и уже спрашивать конкретно...
Мож тебе вообще в том случае посоветуют bash+Makefile+sed+awk.
Такое я тоже видел (правда там ещё +xsltproc был)
и база данных была в виде xml-файла вида
...<book><name>Книжка такая-то</name><pages>280</pages></book>....

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

Я назвал локальным сайтом, но это скорее WEB-приложение.
В примерах из документации по JDBC и DBI говорится,
что обращение к базам в обоих языках одинаково:
запрос, построчное извлечение.
Далее в HTML::Template или JSP.

Ну не совсем, точнее совсем неее....
DBI гораздо сильнее чем JDBC по возможностям...
Если oracle конечно использовать а не mysql.

Точнее задача нужна чтоб оценить.

Кстати, а почему народ так php не любит?

Я правильно понимаю, что у него с масштабированием проблемы?

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

php идеологически это суть смешение логики и визуализации, то есть
ты пишешь всё вместе. Это во-первых плохо тем что когда заказчик
говорит "а теперь мы поменяем дизайн сайта" тебе придётся всё
полностью переписывать (кстати, jsp даже вместе с ejb и c-tags
не очень далеко оттуда ушло - нет-нет да проскакивают "грязные хаки",
а программеры на яве говорят - "ну, типа, даа не идеальный вариант
ну и ладно" и закрывают на всё глаза).
Дальше всего ушёл XSLT.

Кроме того php опять-таки идеологически вещь функциональная а не ОО.
(Правда я на perl тоже ОО не использую но оно там и не нужно
в _моём_ случае).
А раз оно функциональное то начинается бардак и хаос, особенно
учитывая то что народ начинает делать по 20 раз одно и то же,
copy paste. А потом в 19 местах поменял, в 20-ом забыл...
Опять таки, сравнивая с ява - у нас главный архитектор проекта
умудрился точно так же copy-paste'ом наплодить (по моей оценке)
пару-тройку лишних мегов исходников. Круто, да? А потом начинаются
вопросы - когда я редактирую "Ч/Б картинку" всё работает, а когда
"Цветную картинку" то нет? Почему? Ведь логика одинаковая? Ага,
он просто скопировал файл .java а когда баг (бажок, как их называют
закоренелые явовцы) нашёлся - в одном месте исправил, в другом - забыл.

Идеологически правильные модели суть (по моему 5-ти летнему опыту) таковы:
====Модель А, хорошо получится на Яве====
1) Существуют некие запросы берущие данные из базы
2) Существуют (ну например) некие модули на перле/яве которые
вызывают sql и обрабатывают, выдавая пункты 3)
3) Существуют объекты-сущности, например Пользователь, Сообщение, ДругПользователя, СтрокаОтчётаПродаж и тд
4) Существуют классы/функции (не суть) которые работают на уровне логики HTML-страницы, то есть выбирают то что надо используя 2)
и складывают в некий объект или хеш и возвращают имя, например,
шаблона страницы ("my-report.jsp").
5) Существуют данные (шаблоны страниц) визуализатора
(JSP/XSLT/HTML::Template/...) которые используя данные выданные 4)
создают саму страницу.

====Модель Б, хорошо получится на PLSQL====
1) Существуют справочники (таблицы) описывающие
ШаблоныСтраниц, Страницы(связано с шаблоном), Элементы (напр.
текст, картинка, форма авторизации, прайс-лист), РежимыЭлементов
(напр. ПросмотрЛентыНовостей, ДетальныйПросмотрНовости,
ФормаПоискаТекстаНовости, РезультатПоиска, и тд, + там же хранятся
данные о необходимых ролях пользователя для выполнения, напр.
требуется чтоб был Админом), ЭлементыНаСтранице
2) Существуют некие PLSQL пакеты являющие собой Элементы
3) Существует некий PERL(например) скрипт, единственная цель которого
разобраться что к чему и какой пакет и какую функцию внутри дёргать,
а после этого какому шаблоно-генератору выдать результат...

При этом пакеты (в сумме своей) выдают что-то типа:
/В данном примере отработали пакеты text, nav,login_register/
теги xml,page,place,widget, и всё в /xml/* кроме /xml/page
генерит сам перл, а то что внутри /xml/page/place/widget - PLSQL.
Благо PLSQL умеет выдавать СРАЗУ XML-дерево.
<xml>
<page>
<place name="body" id="5">
<widget aid="12">
<text mode="default"> <ID>4</ID>
<BODY>Текстовый блок...
Тра та та....
</BODY>
<IS_HTML>0</IS_HTML>
</text></widget>
</place>
<place name="image" id="8">
</place>
<place name="lookups" id="7">
<widget aid="2">
<login_register mode="default"><register-link>/register.page</register-lin k></login_register></widget>
<widget aid="30">
</widget>
</place>
<place name="motd" id="6">
</place>
<place name="nav" id="4">
<widget aid="1">
<nav mode="default"> <item>
<NAME>Главная</NAME>
<URL>/index.page</URL>
</item>
<item>
<NAME>О сайте</NAME>
<URL>/about.page</URL>
</item>
<item>
<NAME>Альбомы</NAME>
<URL>/albums.page</URL>
</item>
</nav></widget>
</place>
<place name="textpreview" id="9">
</place>
</page>
<action>/index.page</action>
<username></username>
<uid>0</uid>
<pageid>1</pageid>
</xml>

#ifdef FLAME

На чем, на чем.... На Haskell (см. Haskell Server Pages)

#endif

нет, в этой теме:
$FLAME=undef;

vahvarh:

> php идеологически это суть смешение логики и визуализации, то есть ты пишешь всё вместе.

А кто мешает разделить логику и визуализацию в рамках php? Почему не использовать, например, тот же XSLT "поверх" php?

круто, если бы не

* No support for POST data yet.

А тогда сам смысл PHP пропадает. PHP этож что?
хтмл-хтмл-хтмл-кусокPHP-хтмл-хтмл-кусокPHP-хтмл-хтмл-кусокPHP-хтмл...
то есть файл прям вот так пишется:

файл:
<html>
<head>
<title>Example #1 TDavid's Very First PHP Script ever!</title>
</head>
<body><? print(Date("1 F d, Y")); ?></body>
</html>

ну это вопрос "как используют", а не "как можно использовать" ;)

Ха три раза. "как используют"....

Можно и на COBOL'е писать CGIшки....
И даже на лиспе и на vim-скрипте...
Но какой смысл?
Какой смысл от PHP если его придётся использовать "в режиме перла"?
В чужом огороде PHP будет заведомо кривым и неработоспособным...
Можно привезти кучу примеров...
Это примерно то же самое как начать сейчас переписывать инсталляционные
скрипты debian с PERL на PHP. Можно, конечно можно, но нахрена?
PERL лучше справляется со своими задачами.

2vahvarh(19.09.2005 21:57:54):

> Какой смысл от PHP если его придётся использовать "в режиме перла"?

Отнюдь! php -- всего лишь embedded язык. Например, есть embedded SQL, и никто не жалуется.

Т.е., php не совсем "хтмл-хтмл-хтмл-кусокPHP-хтмл-хтмл-кусокPHP-хтмл-хтмл-кусокPHP-хтмл", а, скорее, "чтоотдаетапач-чтоотдаетапач-чтоотдаетапач-кусокPHP-чтоотдаетапач..."

Если подразумевается, что сервер отдает только HTML, то да. Но никто не мешает отдавать XML с XSL!

1) Мешать не мешает но никто этого не делает (99%)
2) embedded SQL - в каком виде, опять-таки...
Например, во всех моих проектах SQL хранится отдельно.
3) Опять-таки, ну не катит PHP в сравнении с
procedure Palbums (r in out nocopy clob,uid in integer,Luser_id in integer) as
	qry dbms_xmlgen.ctxHandle;
	cur SYS_REFCURSOR;
	xt XMLType;
begin
	dbms_lob.append(r,'<photoalbums mode="albums">');

	if uid=Luser_id then
		dbms_lob.append(r,'<item>');
		dbms_lob.append(r,'<ADD/>');
		dbms_lob.append(r,'</item>');
	end if;

	open cur for
		select
			pa.id,
			pa.name,
			pa.user_id,
			Frandom_album_photo_thumb(pa.id) as filename_rand,
			nvl(paic.cnt,0) as photos_cnt
		from
			Tphotoalbums pa,
			(
				select
					pai.photoalbum_id, count(*) as cnt
				from
					Tphotoalbum_images pai,
					Tphotoalbums pa
				where
					pa.user_id=Luser_id and
					pai.photoalbum_id=pa.id
				group by
					pai.photoalbum_id
			) paic
		where
			pa.user_id=Luser_id and
			(pa.is_public=1 or pa.user_id=uid) and
			pa.id=paic.photoalbum_id(+)
		order by
			pa.name;
	qry:=dbms_xmlgen.newContext(cur);
	dbms_xmlgen.setRowTag(qry,'item');
	dbms_xmlgen.setRowSetTag(qry,null);
	xt:=dbms_xmlgen.getXMLType(qry);
	if xt is not null then dbms_lob.append(r,xt.getclobval());end if;
	dbms_xmlgen.closeContext(qry);
	open cur for
		select
			name as album_owner
		from
			Tusers
		where
			id=Luser_id;
	qry:=dbms_xmlgen.newContext(cur);
	dbms_xmlgen.setRowTag(qry,null);
	dbms_xmlgen.setRowSetTag(qry,null);
	xt:=dbms_xmlgen.getXMLType(qry);
	if xt is not null then dbms_lob.append(r,xt.getclobval());end if;
	dbms_xmlgen.closeContext(qry);
	dbms_lob.append(r,'</photoalbums>');
end;

>1) Мешать не мешает но никто этого не делает (99%)

дык пыхпых плох потому, что так делают или иначе нельзя?

>Например, во всех моих проектах SQL хранится отдельно.

php этому не мешает

>procedure Palbums (r in out nocopy clob,uid in integer,Luser_id in integer) ... end;

а те мозги голову изнутри не давят? :)

>>procedure Palbums (r in out nocopy clob,uid in integer,Luser_id in integer) ... end; 
>а те мозги голову изнутри не давят? :) 

из ICQ, специально для тебя: 
09:44:32 [----] 
Vahvarh: Ты на процедурку посмотри =) 

09:44:46 [----] 
Leroi: Уже посмотрел. А что там сложного? 

09:44:59 [----] 
Vahvarh: не знаю. Наверное что то сложное есть... 

09:45:27 [----] 
Leroi: По моему, все понятно. Комментариев, правда, нет, ну да ладно :)))



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

select /*+ NO_MERGE(stat)*/
        sca.name,
        tgp1.name as tgp_name,
        round(mtr.amount*decode(mtr.amount_type,
                'USD',count(*),
                'PERCENT',0.01*sum(decode(ssn.currency,'USD',ssn.price,0))),2) as money_usd,
        round(mtr.amount*decode(mtr.amount_type,
                'USD',0,
                'PERCENT',0.01*sum(decode(ssn.currency,'RUB',ssn.price,0))),2) as money_rur,
        mtr.amount,
        mtr.amount_type,
        count(*) as cnt
from
        
        sms_in smsin,
        (
                select
                        trunc(smsin.timestamp,'MONTH') as period,ssn.tgp_id,count(*) as cnt
                from
                        sms_in smsin, smsc_srv_numbers ssn
                where
                        smsin.ssn_id=ssn.id and
                        smsin.mpr_id=? and
                        smsin.timestamp>? and
                        smsin.timestamp-1<?
                group by
                        trunc(smsin.timestamp,'MONTH'),ssn.tgp_id
        ) stat,
        mpartners_tariff_rules mtr,
        tariff_groups tgp1,
        smsc_srv_numbers ssn

,
        sm_requests smr,
        smsc_accounts sca
where
        
        smsin.mpr_id=? and
        smsin.timestamp>? and
        smsin.timestamp-1<? and
        smsin.ssn_id=ssn.id and
        smsin.timestamp>=stat.period and
    smsin.timestamp<add_months(stat.period,1) and
        smsin.timestamp>=mtr.date_begin and
        smsin.timestamp<mtr.date_end and
        stat.cnt>=mtr.border_begin and
        stat.cnt<mtr.border_end and
        stat.tgp_id=ssn.tgp_id and
        ssn.tgp_id=mtr.tgp_id and
        tgp1.id=mtr.tgp_id


 and
        smr.grq_id=smsin.id and
        ssn.sca_id=sca.id
group by
        sca.name,tgp1.name,mtr.amount,mtr.amount_type
order by
        sca.name,tgp1.name,mtr.amount,mtr.amount_type

>php идеологически это суть смешение логики и визуализации, то есть ты пишешь всё вместе.

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

>Кроме того php опять-таки идеологически вещь функциональная а не ОО.

Ну 5ая версия вроде продвинулась в этом вопросе.

>И даже на лиспе

А почему бы и нет?;)

http://brl.sf.net/

+1.

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

чо за язык? похож на помесь Ады с скуэль

PHP это: кривой XML, кривой уникод, кривая объектная модель... ну вы поняли =)

Скажу как перл-девелопер. Пишу для веба на перле (sql, генерация страниц). Дык вот, писание на перле намного приятнее и нагляднее чем писание того-же кода но на JSP. Приходится часто сталкиваться с кодом от других людей, код на перле читается намного лучше, чем на жаве. Дело не в кодинг-стайле, а в синтаксисе языка. Перл позволяет использовать компактные структуры, в отличие от джавы, отсюда скорость разработки и сопровождения.

int19h:

> ну вы поняли =)

Не-а ;)

> похож на помесь Ады с скуэль

это и есть "помесь Ады с скуэль" - pl/sql

> Опять-таки, ну не катит PHP в сравнении с > procedure Palbums (r in out nocopy clob,uid in integer,Luser_id in integer) as

Что ты хотел показать этим .. хм .. кодом?

Apache/Perl vs Tomcat/Java: послeдние года четыре работаю только с явой, но выбрал бы Perl(Python, что-угодно) не раздумывая.

> Когда я писал на пыхпых никогда ничего не мешал (ну почти:) всё в шаблонах.

Ну и нафиг тогда нужен пых-пых, если есть perl? BTW, в perl есть замечательный модуль Text::Template, который позволяет писать код в шаблонах.

>Ну и нафиг тогда нужен пых-пых, если есть perl?
> BTW, в perl есть замечательный модуль Text::Template, который
> позволяет писать код в шаблонах.

Читал www.template-toolkit.ru, но не понял практическое применение.
Изобрели еще один язык, чтобы не писать на perl?
Полезная вещь - замена имени переменной $var ее содержимым,
циклы, условия. Остальное не могу понять.

В JSP считать bean с присвоением переменным, заменить в коде переменную
на содержимое. Тоже самое?

anonymous1

>Читал www.template-toolkit.ru, но не понял практическое применение.

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

Офигеть. Дизайнер должен для этого еще и новый язычек учить. Может быть он все-таки должен заниматься проработкой того, как будет визуально восприниматься проект? Дизайнер знает html (причем часто в виде Dreamweaver'a) - больше ему знать не нужно.

Про пых пых.. свое порекламировать:
http://bubla.sourceforge.net/
https://sourceforge.net/project/showfiles.php?group_id=95701&package_id=1...

PHP это кошмар.
1) все собирается из одного исходника. Что делает PHP тяжелым в поддержке.
2) нет CPAN
3) убогая объектная модель. В перле она просто странная, а в PHP убогая.
4) нет namespace, то есть на библиотеку решений можно не надеяться.

Зато у него есть один огромный плюс, благодаря которому мы его используем -- PHP-кодеры дешевы как грязь.