Релиз Grails 1.0

>Проект подсунули уже начатый под соусом "4 баги надо исправить". Оказалось что эти 4 баги - это собственно 4 основных таска проекта который был только начат

Хочешь быть бедным и несчастным - будь честным и добрым (c)Наполеон I Бонапарт.

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

RoR (2006)
SEAM (2007)
Теперь вот Grails (2008)

И все это время был и есть Spring.

> А что тебе понравилось/не понравилось Scala?

Я весьма неуютно себя в жабе чувствую без нормальных лямбд, функций как функций как first order object, pattern matching и алгебраических типов и list comprehension . Вернее даже не так - с этим всем все было бы шикарно. Кложуры добавятся (пропосал я смотрел) надеюсь (сейчас я выкручиваюсь jexl и своим collection framework без остального приходится обходится. Еще бы type inference. Вообще я считаю что пора появлятся next generation языку для common use. В .NET существует F# - это железная заявка на поддержку более крутого языка большой корпорацией (и в С# тянут из перечисленного), но сану тут надо шевелится. Когда-то они сделали платформу + язык который избавлял от тучи гемороя. В 21 веке фича языка "не надо заниматься фигней" - уже не настолькор привлекательна. Нужен следующий язык с мощной платформой типа Java Platform. Иначе вылетит с рынка как Borland с Object Pascal, который был в конце девяностых на железном коне а сейчас в относительной жопе. VB уже перешов в разряд коболов.

> нормальных лямбд, функций как функций как first order object, pattern matching и алгебраических типов и list comprehension

Это всё не для Average Joe. Ну не перейдём мы никогда на Lisp/Haskell просто потому что они сложные для большинства программистов. Scala... Да, заявка неплохая, смесь ООП и функционального, Actors Library, возможность писать DSL, Java Platform. Наверное поэтому на неё что в Гугле, что в Яндексе обратили внимание в отличие от ror/grails/seam... Но всё же даже Scala по-моему мнению слишком сложна. Хотя если напишут плагины к IDEA/Eclipse/NB, выйдет доступная книжка, кто-то из "монстров" начнёт её использовать - всё может быть. Пока что 2 записи в день на dzone - не плохой старт.

>Это всё не для Average Joe.

Для average. Просто это не в кинкарнации haskell lisp. Это в том или ином виде есть везде. Посмотри на С# 3.5 там уже почти все засунули в том или ином виде.

>Но всё же даже Scala по-моему мнению слишком сложна.

В конце концов в реальных проектов все могут до нее дорасти. Ни до лиспа ни до хаскела народ не дорастает по причине того что их слишком сложно примениять в реальной жизни - люди которые на них разрабатывают слишком специализированы. По простому язык + библиотека должны быть ready для созданию корпоративного быдлосайта. Потому руби получил такой хайп - он на это претендовал - никакие лиспы или хаскелы на это не претендуют - у них нет энтерпрайз платформ.

Ну что начнем теоретическую дискуссию - существует некий гап между универом и реальной жизнью (берем статистическое большинство). sv95 может преподавать курсы на эрланге и это правильно, но факт в том что выпускник занявшийся профессиональным программированием попадет в 95% случаев в software house где С++/.NET/J2EE - то есть эрланг ему останется только теоретическим знанием. Только 5%(хорошо если - реально думаю и процента нет) смогут найти работу на лиспе или эрланге, и то именно с намерением пожизненной занятости. Хорошо если. ТАкова реальность.

Далее если выпускник попадает в софтваре хауз - он там не пишет на хаскеле не потому, что не может его асилить - а потому что проектов таких нет, а разные эксперименты выльются ему лично бюоком - нахрена рисковать делая проект не на апробированном пыхе по поводу которого никто вопросов не задаст а на какой-то херне "нафиг ты на этом тогда писал вот пхп". Эта ситуация напоминает мне с отношением windows linux. Например если берется MSSQL сервер для реализации чего либо в случае проблем - они объективная реальность. Их просто решают. Не дайбог возьмешь например постгрес - то в случае тех же проблем принявшему такое решение оторвут яйца за "какую-то херню которую он использовал вместо нормального виндовс". Это все тупая необъективная вера в мейнстрим - религия.

Например я когда-то в (неповерите сайт для Samsung World Cyber Games) написал модуль на хаскеле - вот легче и быстрее мне так было написать турниры - но это был мой личный риск. Грубо говоря за любое необычное решение программист расплатится своими яйцами, за обычное кивнет на "все так делают".

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

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

Вернемся к скале. Это язык (как и MS F#) дает такой шанс среднему человеку - за ним энтерпрайз платформа. Он в любом случае не влетит - в крайнем случае напишет неработующую штуку или проблемную на жабе. Опять же можно начать с малого - написать на скале библиотечку которая скомпилируется в нормальные классы и вызвать его из большого стандартного приложения - риска практически нет. Можно начать с малого и развится дальше.

То есть реализация таких штук поверх мощной платформы дает возможность развиваться - оно дает возможность изучать много новго не рискуя тем что если начнем ваять апликуху на OCaml - попадем с каким-то отсутствием стандартной либы и торба. Взять вот хотя бы топичный grails - ведь прикинте сколько софта написано уже стандартного который в нем юзается - надо коннект к базе - да пожалуста - годами обкатанный JDBC, надо графическая библиотека - да невопрос - не полурабочий биндинг - а вполне прозрачное подключения платформенных библиотек.

Вот в чем преймущество перед всякими рельсами.

И в таких условиях я думаю average joe сможет осилить все лиспы что надо.

s/sv95/sv75/g

re:Scala... Да, заявка неплохая, смесь ООП и функционального, Actors Library, возможность писать DSL, Java Platform. Наверное поэтому на неё что в Гугле, что в Яндексе обратили внимание в отличие от ror/grails/seam...

Ну так scala - язык, а ror/grails/seam развод трудящихся по хорошо отлаженной схеме.
Это сейчас мода такая - "на нашем YAPF вы можете делать это ещё круче".
И сравнивать с каким нибудь EJB подобным монстром.

А причем тут yandex?
я общался с одним из их team lead'ов у них жуткий легаси, используют Spring ( но AOP не знают и не пользуют), + Corba(возможно оправдано из за большого количества C приложений) + XSLT (для ajax так же удобно как асфальт зубочисткой подметать, что все yandex морды и показывают), плюс какой то самописный orm , на мой вопрос, а чем вам Hibernate не ORM, мне скзалаи что Hibernate - это не серьёзно. Дальше IMHO говорить было не о чём.
Возможно я не прав судя о яндексе по одному человеку. Но для java world они пока ничего не создали.


Google - для java сделал GWT, спасибо ему. Для hibernate - несколько вкусных либ, ещё раз спасибо. А ещё Google налабал свой DI контейнер - и был с ним послан.
Пока это все.

>Реализация работы с БД в лучших традицЫях похапэбыдлокодеров - по запросу на итерацию.

Попрошу PHP не трогать :) В моём фреймворке хоть сотни объектов (одного типа) дёргаются из БД одним запросом :) Вот тысячи дёргать уже накладно, пока их в шаблон запихнёшь при выводе...

Ну блин заинтересовали, ничего не скажешь, такая речь. :) Смотрю, что за Scala...

> Вернемся к скале. Это язык (как и MS F#) дает такой шанс среднему человеку - за ним энтерпрайз платформа.

F# значительно проще - неожиданно так, вроде его Microsoft делал o_O

Напоминает erlang, скрещённый с java. Только вот plug-in для eclipse как-то сразу не порадовал.

>F# значительно проще - неожиданно так, вроде его Microsoft делал o_O

НЯЗ, MS к нему прямого отношения не имеет. Совершенно сторонняя разработка, которую MS у себя приютила в .NET-рекламных целях :)

Seam, кстати, ни EJB, ни JSF не требует. Но вот компонентные фреймворки для веба сильно удобнее, чем Spring MVC. А ajax к jsf прикручивается вообще на раз.

>F# значительно проще - неожиданно так, вроде его Microsoft делал o_O

Да мне тоже хотелось бы в идеале чего-то окамлоподобного и под жвм с легкой интеграцией "foreign functions".

>Seam, кстати, ни EJB, ни JSF не требует.

Не требует, но без них что он дает?


>А ajax к jsf прикручивается вообще на раз

На раз - это только готовые компоненты, а если их нет?
А если нужно то что они не умеют (а это нужно всегда).
А какова цена разработки своего компонента?
А как ты будешь отлаживать свой AJAX компонент и сколько JS тебе туда придётся вбухать?

Попробуй зделать только средствами JSF дерево с drag and drop.
Так что бы ноды дерева были произвольные widget'ы (text input, check box, combobox). На GWT я это сделаю в 200 строчек JAVA кода.

А как насчёт ajax библиотеки афектят life circle JSF и не могут работать друг с другом?

Говорить что к JSF на раз прикручивается AJAX - это все равно что говорить что к JSP, Velocity,FreeMarker на раз прикручивается AJAX :-)


Ну попробуй попользоваться одновременно IceFaces и Infragestics.
У JSF life circle не заточен под Web2.0.
П

> Seam, кстати, ни EJB, ни JSF не требует.

Не знаю, что Seam может без EJB и JSF - ведь для него это центральные компоненты.

> Но вот компонентные фреймворки для веба сильно удобнее, чем Spring MVC

Это зависит от того, кто будет лепить вьюсы, если программер - то тогда да, удобнее, а нормальный верстальщий/дизайнер всё равно сделает лучше. Кстати, ИМХО, лучше рассматривать Spring Web Flow вместо Spring MVC.

И какая есть альтернатива Wicket'у среди не компонентных фреймворков в плане удобства для верстальщика? Spring MVC?)))

> Не знаю, что Seam может без EJB и JSF - ведь для него это центральные компоненты.

IoC, удобная модель жизненного цикла компонентов, правила безопасности на Drools, да и еще много чего.

> Это зависит от того, кто будет лепить вьюсы, если программер - то тогда да, удобнее, а нормальный верстальщий/дизайнер всё равно сделает лучше. Кстати, ИМХО, лучше рассматривать Spring Web Flow вместо Spring MVC.

Нормальный верстральщик/дизайнер великолепно справится с темплейтами для Tapestry, Facelets или Wicket (даже спасибо скажет). И лично я рассматривать буду скорее JBPM через тот же Seam.

Дык ведь компоненты, что рассуждать о том, если их нет? И ведь работают. И ICEfaces и RichFaces и Trinidad. А что такое life circle? то же что хеймскрингла или что другое?

> На GWT я это сделаю в 200 строчек JAVA кода.

А на Wicket и меньше того потребуется, поди, и что с того?

> А что такое life circle?

s/circle/cycle

http://www.ibm.com/developerworks/library/j-jsf2/

> А на Wicket и меньше того потребуется

Господа, а что в самом деле кто-то использует викет? Мне он показался просто кошмаром с первого взгляда, смешение вёрстки и java-кода. В чём его фишка?

> s/circle/cycle

Я догадался.

> Господа, а что в самом деле кто-то использует викет? Мне он показался просто кошмаром с первого взгляда, смешение вёрстки и java-кода. В чём его фишка?

Может быть, в том, что они не смешиваются?

Просто partial submission и partial render ни фига не противоречат жизненному циклу JSF. Вот я и подумал, что уважаемый оппонент вычитал между строк спецификации что-то эдакое.

Господа, а в каком Java-проекте Вы бы поучавстововали? OpenSource, на пользу сообществу) Первым в списке GWT, так же интересны(Jython/JRuby), Groovy совсем не нравится, Scala(есть возможность позаниматься lift, но всё же бы хотелось Java-the-language).

> Может быть, в том, что они не смешиваются?

Ну в каком-то смысле да, не смешиваются, скорее дополняют.