RU/2: Форум. Общение пользователей и разработчиков OS/2 (eCS). : Ответить на сообщение

Имя:
e-mail:
FIDO:
Home page:
сохранить данные о вас

Тема:

> > > > В принципе, на перле это делается так же. Обработку данных делают одни функции, представление результатов - другие. Причем и то, и другое - максимально гибкое, поскольку даже HTML относящийся к "оформлению" генерируется динамически и можно использовать разные красивые и удобные трюки. Хотя это не всем нужно конечно. Но тогда можно и PHP обойтись.
> > > Брр. perl и php весьма близки по возможностям.
> > Не смеши меня. Это все равно как если бы я сказал что Java и PHP близки по возможностям :). Перл - полномасштабный язык программирования и среда разработки, на нем можно писать _абсолютно_ любые программы: развитый стандартный API, доступ ко всем нативным API, горы библиотек с расширениями.
> 
> К php тоже есть "горы библиотек"... правда не сравнимые с теми горами которые есть для Java.
> 
> > > Java же, в отличие от этих скриптовых языков предоставляет реальные средства для объектно-ориентированного дизайна и разработки приложений. Такие, как например сокрытие информации, наследование и полиморфизм.
> > Это все есть в Perl. Perl5 - объектно-ориентированый язык програмирования, весьма развитой. Может ты про перл последний раз слышал лет пять назад - тогда да, это было нечто вроде улучшеной версии awk. Но те времена - уже доисторические.
> 
> Ага. Я тут недавно общался с командой, которая ваяет большой проект на перл. Они вообще сказали, что им объекты не нужны. А на мои вопросы об областях видимости пропертей и методов вообще сказали, что они все отовсюду видны и "нужно только договориться" что можно вызывать, а что нельзя. Никаких тебе  public, private или protected мемберов. И это тоолько одно...
> 
> > > > Неэффективно в чем? Главная проблема 
> > > Тем, что приложение запускается и прибивается на каждый запрос пользователя. 
> > На то есть FastCGI и иже с ним (mod_perl). А если http сервер грамотно написан так он вообще это делает совершенно прозрачным образом. Еще раз повторяю - попробуй PW, увидишь что такое _эффективный_ сервер. Апач рядом не валялся, даже с mod_perl.
> 
> Какой бы сервер ни был эффективный, запустить и положить отдельное приложение - тема еще та. На юниксах правда это не особо заметно, но тем не менее.
> 
> > > Первая проблема которая возникает - куда положить данные, которые хотелось бы сохранить в промежутке между запросами. 
> > Это как раз весьма изящно делается модулем CGI.pm. В его идеологии - каждая сессия с пользователем - это объект, его можно сериализовать и сохранить - на диске в файл или в базу данных, потом восстановить вместе со всем контекстом. Очень удобно, сам наслаждаюсь.
> 
> Ууу... файлики на диске. Крутота. 1000 пользователей - 1000 файликов. Рулез.
> 
> > >Кроме того есть некоторые весьма удобные вещи, как, например утилизация конектов к базе данных в запросах. В CGI ты будешь вынужден конектиться каждый раз. Что не есть хорошо для производительности, а на корпоративных системах, ворочающих большими объемами можно натолкнуться еще и на предел одновременных конектов, устанавливаемый SQL сервером (не зря же изобретали 3х уровневую архитектуру).
> > Это тоже обходится соотв. расширениями сервера. Опять же, грамотный сервер делает это прозрачно, вообще ничего програмировать не надо. Написаный левой ногой Netscape Enterprise Server с которым мне приходится иметь дело - требует подкручивания и поглаживания, но однако тоже это умеет. Кроме того, для этого есть средства и в DBI.
> 
> "Расширение сервера"? Это как, пересобирать весь сервер каждый раз, когда понадобится другое "расширение"?
> 
> > > Нет, мне это нарвится. "часть модулей тоже бинарные". Да хоть одна функция будет бинарной и не дай бог не соберется (в Java то bytecode и собирать никуда не надо), то скажи перлу до свидания. :)
> > При чем тут bytecode? У перла тоже байткод, ну и что? Речь идет о самом интерпретаторе, или о JVM. Оно естественно должно быть перенесено на систему в бинарном виде. Модули расширения являются частью интепретатора Perl, так что естественно они должны быть собираемы на этой системе. JDBC тоже кстати бинарные по большей части, и это тоже проблема, как я уже писал.
> 
> В лучае Java нет требования "собирабельности на этой системе". Знаешь - очень приятно один код и на os/2, и на win32, и на Unix иметь.
> 
> > > А JDBC для Oracle еще никто не отменял. :)
> > Есть только для WinNT. И экспериментальный lightweight на pure Java. Подозреваю что оно нерабочее. Я же писал уже, ты что текст ответов не читаешь?
> > > JDBC
> > Нету ни для чего кроме WinNT. DBI есть для всего.
> 
> На счет JDBC ты не прав.
> 
> > > Я про байткод. Ты не отдаешь исходные тексты. Ничего не надо собирать. А байткод работает везде, где есть JVM, удовлетворяющая спецификации.
> > Это да, проблема. Исходники отдавать не хочется. Но вообще-то уже есть компилятор perl в байткод и он уже даже работает. Правда пока это все же бета.
> 
> Для Java в бэта-варианте много чего есть. :)
> 
> > > Ну знаешь. regexp'ы ему нужны... Взял да написал сам. Один раз. И всем другим дал, 
> > :-))))))))))
> > > чтобы не мучались. Хотя лично я не верю, что нет нормальных regexp'ов. Ту же Cшную либу, 
> > Ну и не верь на здоровье. Я-то проверял...
> 
> Что ты проверял? Что должна такого нетривиального уметь такая "библиотека"? Где ты проверял? И ты так и не сказал зачем тебе regexpы.
> 
> > > которой все пользуются (perl в том числе) вполне можно перетащить на Java. Будет один в один, если не лучше даже. :)
> > > > Стану, да еще как! Мои коллеги попробовали поставить JVM на свой сервер под CGI, Октан у них там какой-то или еще круче, не помню. Он упал так что они его потом месяц восстанавливали.
> > > Уууу... CGI - это абстракция. Это абсолютно ничего конкретного. То есть совсем. Это даже не программа. :)
> > Я описАлся. Имелось в виду SGI, Silicon Graphics Inc., это железяки такие, синенькие... Хардверная платформа в общем.
> 
> Ну что ж поделать. Надо было думать, когда выбирали серверную платформу. Сейчас чего кулаками то махать. Это примерно из серии - хотеть запустить программу на Visial Age for Smalltalk на Macintosh.
> 
> > > Ну еще бы они его не слышали. Этому слову лет 7..8 пожалуй будет. Java - всего 5. А JDBC и того меньше. А учится админам никогда не вредно. Или хотябы научно-популятные журналы читать. :)
> > И где ты видел сисадмина читающего научно-популярные журналы? :-))) Они все - с красными глазами и мозолью на заднице :))))
> 
> Это проблемы этого сисадмина. Или той конторы где он работает.
> 
> > > Слышал я как Нечаев три дня бился головой об стену в попытках собрать mod_perl для осевого Apache. Нафиг, нафиг нам такая 
> > У меня база с которой я работаю не под осью.
> 
> Это к вопросу о переносимости решений на perlе написанных.
> 
> > > радость. А ты не смотрел в каком месте твой PersistentCGI хранит результаты меду запросами? Так вот посмотри, порадуйся. 
> > Рассказал бы, я им как раз не пользуюсь.
> 
> Я тоже не пользуюсь. Как и ничем другим, что имеет приставку CGI.
> 
> > > FastCGI у меня только нервный смех вызывает. Что, еще есть SlowCGI? :)
> > > А как насчет load balancing? N серверов приложений или, скажем K SQL серверов для одного...M httpd.
> > Не понял, поподробнее можно? Видимо передо мной такой задачи еще не вставало, а разбираться во всех мыслимых проблемах мироздания я не успеваю :-).
> 
> Подробнее так. Любой твой CGI - это своего рода middle слой трех уровневой архитектуры (например веб сервер - CGI - RDBMS SQL). Так вот при некотором пороге кол-ва запросов в единицу времени эти CGI не в состоянии выполняться из-за нехватки ресурсов. Хотя веб сервер вроде и работает. Вот тогда стараются средний слой растащить на несколько серверов приложений.
> 
> > > Ты видимо мельком и смотрел раз такие вещи говоришь. Вон Дима Платонов не даст соврать. Или хотябы сходи на сайт http://java.sun.com/ и в разделе документации про JDBC там отдельная страница есть, посвященая списку JDBC драйверов для немерянного кол-ва серверов.
> > 
> > Так я же и говорю что - работающего _вообще_ не видел, ни мельком ни как. Вот пусть мне кто видел - расскажет и покажет. А за ссылочку - спасибо, сейчас посмотрю.
> 
> И таки он есть!

__, _,_ __, _,_ _, \|_) \| \| \| \ \| / /_\ \| \ \| \| \|_/ \|/ \| \| ~ ~ `~' ~ ~ ~ ~