[room] язычки и библиотечки

[Eugene Prokopiev]

Денис Смирнов пишет:
> On Tue, Oct 24, 2006 at 12:58:59PM +0400, Eugene Prokopiev wrote:
> 
>>>Если честно, я бы уже совсем обиделся и ушел на Java, написав к ней
>>>несколько классов для обраобтки FastCGI, темплейтов и прочей радости, а
>>>также компилятор в неё с простого PHP-like язычка. Только вот
>>>инфраструктура вокруг неё какая-то кривенькая, не могу я к ней привыкнуть.
> 
> EP> А конкретнее? Что показалось кривым в инфраструктуре? Может не туда смотрел?
> 
> Вполне возможно, в том что касается жабы я ламерюга редкостный.
> 
> Буду рад если ткнешь меня носом в то, с чем следовало бы ознакомиться.

В первую очередь скажи, что такое для тебя инфраструктура? Может мы о 
разном?

Сразу скажу, что с Java я начал работать тогда, когда мода на тяжелые 
решения вроде EJB стала проходить. Много было написано на эту тему, 
например Better Faster Lighter Java и J2EE Development without EJB - у 
меня есть pdf, если надо, пиши ...

Для подавляющего большинства немонолитных проектов бывают полезны 
технологии вроде IoC - эдакий универсальный клей для модулей ;) . Почти 
чистая реализация - это HiveMind. Spring - тоже IoC + готовые заготовки 
для упрощения кода работы с БД, ORM, JMS, AOP (и реализованное поверх 
него декларативное управление транзакциями, которое в Java относится не 
только к БД). EJB3, кстати, в каком-то смысле нацелен именно на нишу 
Spring, но, думаю, уже поздно. Хотя для неподсевших на Spring это 
большой прогресс по сравнению с EJB2.

У Spring есть собственный web framework и интеграция практически со 
всеми другими web frameworks, ежели собственный не угодил. Есть прямая 
поддержка модулей, написанных на JRuby, Groovy, BeanShell, и нет 
препятствий для дописывания поддержки других. Scala (это функциональный 
язык для JVM) нет пока, и, честно говоря, на практике я до этого еще не 
дошел.

Есть в Java такая вкусная штука, как JMX - это средство для написания 
своего рода админских интерфейсов, чем-то по идеологии смахивающее на 
SNMP. Грубо говоря, определяешь параметры, которые надо мониторить, и 
операции, которые можно применять к запущеному сервису, транспорт и 
механизмы авторизации, а UI (хоть web, хоть Swing) тебе нарисуют куча 
готовых JMX-клиентов, начиная от встроенного jconsole. И опять, в Spring 
ты определяешь это декларативно.

> EP> Другое дело, что FastCGI - это штука для JEE несколько чужеродная ...
> EP> Не смотрел, к примеру, на Tapestry?
> 
> Нет. Гляну.

По поводу web опыта у меня практически нет. Но концепция web-приложений, 
собираемых и размещаемых в виде war-архивов в любой контейнер (Tomcat, 
Jetty, Resin) мне нравится. И годится далеко не только для обычного webа 
с UI, а и для сервисов, которые доступны по любому протоколу, 
реализованному поверх HTTP (SOAP, Hessian/Burlap либо что-то 
самопальное). Внутренности web-приложения к этой концепции ортогональны 
- можно и на голых сервлетах остаться или построить поверх них свой 
framework, а можно сначала ознакомиться с существующими (среди которых 
есть и AJAX, и даже трансляторы Swing -> Web).

> EP> А если хочется "FastCGI, темплейтов и прочей радости, а также компилятор 
> EP> в неё с простого PHP-like язычка" - то бишь именно своего велосипеда - 
> EP> то вообще непонятно, что в PHP есть такого, что ты предпочел именно его 
> EP> ... К слову, компиляторов в байт-код JVM с различных функциональных и 
> EP> императивных языков довольно много
> 
> Скорее уж проще самому налабать интерпретатор на той же жабе.

Свой DSL? Возможно, есть смысл посмотреть в сторону antlr ...

> PHP было выбрано как меньшее из зол. То бишь либо самому делать весь стек,
> либо не строить из себя идеалиста а просто сделать чтобы хорошо работало.
> 
> Но я все равно ищу что-то куда свалить.

:)

Прелесть Java не в языке. Язык средний, в частностях вроде интерфейсов и 
анонимных классов лучше предшественника (C++), а в некоторых более 
глобальных вопросах (класс String ;) ) просто потрясающий своей 
нелогичностью. Хотя привыкнуть можно :)

Прелесть именно в окружении. В наличии спецификаций, в конкурирующих и 
относительно совместимых реализаций этих спецификаций. В количестве 
библиотек (один jakarta.apache.org чего стоит). В средствах сборки типа 
ant/maven. В неплохих IDE вроде Eclipse и IDEA, хотя, конечно, для 
любителей vim/emacs это не аргумент :)

>>>Зато с масштабируемостью проблем вообще никаких :)
>>>А разве не любое приложение, хранящее свои данные исключительно в SQL
>>>легко кластеризуется?
> 
> EP> Любое, пока ему не потребуется кэш перед SQL ;) Правда, реализации этого 
> EP> в JEE есть, но на практике не сталкивался ...
> 
> Ну, в жабе в этом смысле все можно сделать красиво, если я правильно
> понял. Спрятать вообще доступ к SQL в объеты, реализовать для них
> интерфейсе serializable после чего сделать кэш. Вот во всяких PHP-подобных
> это уже оказывается куда тяжелее.

А в Java даже есть готовое вроде JBoss Tree Cache :)

-- 
С уважением, Прокопьев Евгений