Провокация флейм: Mono vs Java, мнение девелопера

Не знаю как нащёт моны, но вот сейчяс прикодится с асп.нетом якшаться, всё время удивляюсь: ужель наносуксь никогда-никогда прог не научится делать? Вроде бы пора уже...

Да что бы ещё C# был в стандартной поставке ....
НЕЕЕЕЕ у него зависимостей много :)
я уж лучше на Limbo в Inferno попишу :)

Моно игрушка неплохая, однако список JIT для разных платформ не столь широк, как для Java. Без JIT - это всего лишь игрушка. Хотя пусть развивается, если кому-то интересно. Может и функциональные язычки программирования получат распространение для .NET и mono. По крайней мере Just for Fun, на радость господину Луговскому.:) Мне же Java вполне достаточно. Я "развиваюсь" в сторону АОП-расширений. IMHO, AOP будет весьма распространен в течение ближайших 5 лет.

Хм, странный чел, пишет софт на работе на J2EE, а дома для себя, любимого, на Ruby. Чем его Java дома-то не устраивает?

>Я "развиваюсь" в сторону АОП-расширений. IMHO, AOP будет весьма распространен в течение ближайших 5 лет.

Не будет

http://www.linux.org.ru/profile/_white2/jump-message.jsp?msgid=887101

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

Вам совет - не читайте кульхацкерские посты. Изучайте:

http://www.eclipse.org/aspectj/

http://www.jboss.org/products/aop

http://www.springframework.org/

Для спринга тулза: http://exadel.com/

Обзор на русском (очень общий):

http://www.optim.ru/cs/2003/4/AOP2/AOP.asp

"AOP might seem like an esoteric debate among programmers,"

ГСМ, типичный ГСМ. Информационный шум без обоснований по существу. кг/ам.

АОП - жалкая тень истинного метапрограммирования. Если тебе нужна реально мощная тулза для Java - используй Jatha. Сам его юзаю весьма активно.

Да? И как соотносится, например, Spring AOP и метапрограммирование?

Тем, что средства АОП - тривиально реализуются (а чаще - просто заменяются) макрами, однако обратное - неверно. Макры - более общее решение для тех же проблем.

>Тем, что средства АОП - тривиально реализуются (а чаще - просто заменяются) макрами, однако обратное - неверно. Макры - более общее решение для тех же проблем.

Если заменить решение, основанное на Spring AOP, на решение, основанное на макросах, то это будет другое решение. Совсем. Или я просто в упор не вижу, чем же Spring AOP похож на макросы.

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

a.secured()

public void secured() { // Some secured operation... }

С помощью Spring AOP можно сделать так, что вызов метода secured будет сопровождаться некоторой проверкой (например, проверкой credentials-ов). Куда макрос пихать будем? Место вызова править не можем, оно не должно зависеть от наличия/отсутствия проверки. Вызываемый сервис - аналогично.

Семантика различается - для АОП изменения в runtime, для макр - ещё при компиляции, но для программиста всё будет выглядеть совершенно одинаково - как АОП расширяет язык, сохраняя синтаксис, так и с макрами мы просто вклиниваемся в определения методов и классов, подставляя дополнительный код вокруг. Аналогично контрактное программирование реализуется либо на уровне языка (или препроцессора, как и AspectJ), либо на уровне макр, подменяющих конструкции для определения методов. Но с макрами ты можешь сделать много всякого другого, а с одним только АОП далеко не уедешь, при том, что АОП разделяет недостатки метапрограммирования - затруднённую отладку. Так если фичей больше, а недостатки те же - то лучше выбирать более универсальное решение. Так что лично мой выбор - AspectJ - фтопку, Jatha - рулит.

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

Спасибо за ссылки. Сажусь самообразовываться. =)

Не разные. Одно есть подмножество другого.

>Не разные. Одно есть подмножество другого.

Да? А как же:

>Семантика различается - для АОП изменения в runtime, для макр - ещё при компиляции

?

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

Пример, приведенный выше демонстрирует использование Spring AOP для уменьшеня связности компонентов (т.е для уменьшения цены переиспользования и модификации), т.е для вполне конкретной цели. Я считаю, что в данной ситуации макросы таким плюсом обладать не будут.