Вышла Scala 2.10

Я вам отвечу ссылкой
https://stat.ethz.ch/pipermail/r-help/2008-December/181982.html

А мне бы хотелось знать, чем именно такая форма лучше, чем map или each с лямбдой или замыканием. Тем более, что раскрытое представление почти не отличается.

Ты еще не понял? «Раскрытое представление почти не отличается»? Повторю еще раз, не нужен код, который делает то же самое, а нужен код, которые реализует конкретное тех.задание в виде конструкции foreach, который используется, как я описал.

Вот тебе альтернативная задача, которую тоже нельзя реализовать только с помощью фвп: сделать конструкцию «with-open-...»

Вот варианты как это должно выглядеть и использоваться:

http://clojuredocs.org/clojure_core/clojure.core/with-open
http://www.lispworks.com/documentation/HyperSpec/Body/m_w_open.htm

Ты просто завалил сертификацию.

Нет. Просто поработал с J2EE-сертифицированными.

Ты, видимо, спец по LINQ круче Эрика Мейера.

Крепко советую сменить стилистику речи.

Ага, и поэтому ты тут (Вышла Scala 2.10 (комментарий)) проводишь детальное сравнение

Согласен, терминология не очень точна.

Сравнивать Java ORM и SQLKorma вполне можно. Действительно, мы только что это проделали и получили результаты: SQLKorma — поделка для двухзвенок, JPA/JDO — мощные фреймворки для построения систем уровня предприятия.

Нельзя противопоставлять их. Как было показано выше, это технологии совершенно разных масштабов. Поэтому только некомпетентный собеседник может утверждать, что якобы «SQLKorma мощнее Java ORM».

Как вот, например, ты.

Будьте добры, ещё вот этому господину посоветуйте то же самое. Спасибо.

Поэтому я думаю, что ты маленький убогий тупица с гипертрофированным ЧСВ. Можешь это аргументированно опровергнуть?

Давай нормально разговаривать, ладно? Тред пока не удаляю, но интонации пора бы сменить.

Я вам отвечу ссылкой

R has first-class function closures.
R is runtime-typed and garbage-collected.
R does not have macros.
R is not properly tail-recursive.

Но ведь в таком случае можно сказать, что R произошёл от Питона.

Кстати, в соседний тред про самых неадекватных адептов того или инного ЯП - можно добавить скриншоты/квотезы из этого треда.

Нет. Просто поработал с J2EE-сертифицированными.

...и понял, что не дотягиваешь до них? Потом попробовал сертифицироваться сам и зафейлился?

Вот тебе альтернативная задача, которую тоже нельзя реализовать только с помощью фвп: сделать конструкцию «with-open-...»

Но ведь для Java сделали то же самое (try-with-resources), но безо всяких ФВП. Следовательно, твоё заявление — чушь.

...и понял, что не дотягиваешь до них? Потом попробовал сертифицироваться сам и зафейлился?

Нет, выкидывать деньги на сановскую сертификацию у меня не возникло. Лет 7 назад получил несколько халявных сертификатов от брейнбенча, включая мастера по J2EE. Последний раз получил сертификат по Java 5 на брейнбенче лет 5 назад — меня на собеседовании посадили за комп и попросили пройти этот тест. Сдал на 4.95 из 5 никуда не заглядывая.

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

Теперь ты успокоишься?

Но ведь в Java 7 появился try-with-resources, который является прямым аналогом «скопа with-db» в данном случае.

Одно «но» - насколько я помню энтерпрайз - особо не морочаться там с новыми версиями Java... Часто можно встретить 1.4 в текущей разработке. Новые проекты да, могут начать на 1.6. К сожалению, когда я работал Java-программистом, 7 JDK была полгода как выпущена только, и поэтому даже в новый проект она не вошла. Да и не уверен, что сейчас будет широко использоваться.

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

P.S.: Когда я был на собеседовании осенью 2012 в одной более-менее крупной компании, мне говорили, что основная версия Java - 1.4, и только некоторые новые проекты там начинаю на 1.6. Компания конечно не IBM далеко, но в узких кругах думаю достаточно широко известна.

Наверное, ты хотел сказать, что JPQL не является подмножеством host-языка?

Т.е. ты утверждаешь, что писать запросы в стринге это лучше, чем иметь dsl? А как же автодополнение таблиц, полей, запросов? Как же автоматическая синхронизация наименований таблиц и полей с теми, что в базе? Как же возможность конструировать запрос обычными возможностями языка, а не специальными костылями из библиотеки?

Так это и не утверждалось. Впредь формулируй свои претензии точнее, чтобы они не выглядели бредом

Впредь сядь, набери примеры запросов на джаве и на clojure, поиграйся с кодом, который собирает какой-нибудь параметризированный запрос, поиграйся с результатами, сравни после этого возможности и удобства и только уже после все этого можешь написать в ветку про ORM vs SQL DSL.

Это только лисперы тащат любую срань в язык, засирая его. Подход промышленных систем другой: используются различные языки, самостоятельные, но интегрированные друг с другом. Как в случае с JPQL.

Это такой промышленный подход любые простые вещи оформлять в виде отдельных монстрообразных костылей, а потом бороться с простынями кода, который отношения не имеет ни к предметной области, для которой создан, ни к удобству, а только к маркетоложному бреду?

Я думал, что код должен отображать решение задачи как можно яснее и быть заточен под решение предметной области задачи. А городить миллиард OO абстракций у вас нужно не для решения задачи, а для борьбы с проблемами, которые порождает кастрированный ООпнутый язык.

Если вместо запроса и обработки полученного результата нужно городить из соплей и строк запросы, потом через жопу передавать туда параметры, затем через всякие DAO, DTO, buisness objects и прочую мутотень донести наконец данные до бизнес слоя - то это явно здесь что-то не то.

Кстати, и SQLKorma ты тоже не знаешь. Ведь это не только SQL DSL, но и рантайм (транслятор, исполнитель запросов и data mapper).

Кстати, я приводил примеры не из SQLкормы, а на другом SQL DSL-e. SQLKorma я привел только в одном посте как пример sql dsl-а. Можно использовать не только один подход или библиотеку, а то, что тебе подходит к задаче. Сюрприз.

И да, как язык SQL DSL должен был бы содержать конструкции для настройки политики кеша.

SQL DSL должен заниматься формированием скуль запросов. Кэш отношения к этому не имеет и должен находиться на другом уровне. Слышал выражение «разделяй и властвуй»?

Так вот, рантайм мог бы кешировать результаты SELECT'ов и инвалидировать их при соответствующих UPDATE/DELETE'ах. В Java ORM подобный кэш есть.

Ну так создам кэш на том слое, где это нужно, для тех данных, для которых это нужно.

И вообще, это такой образ мышления уходить от темы разговора? Где ты прочитал про то, что я против кэша? Ты наверно пропустил, но речь шла про ORM vs SQL DSL. Прочитай определение ORM.

Да, в случае, который ты описываешь, ты будешь завязан на конкретный ORM и ни дай бог какая-то часть программы или подсистема будет работать с БД вне ее. То корректность работы твоего кэша накроется пушистым зверьком.

А что это за em.begin() и em.commit()? Точно автоматически? Лукавишь.

Ты не понял. «Автоматически» относилось к отслеживанию изменившихся сущностей.

Т.е. «автоматически» относилось к механизму кэширования?

С SQLKorma тебе придётся фиксировать, какие сущности изменились после вызова бизнес-метода, и апдейтить их вручную. Java ORM делает это само..

Я не использую sqlkorma. Нет, не придется, т.к. я не использую оо модель при работе с бд.

Ну-ка, глянем туториал по JDO. Ой, что это

Ключевое слово — «туториал». В образовательных целях был приведён упрощённый пример. В продакшене такой метод не рекомендуется; для продакшена JPA/JDO поддерживают 1) позиционные параметры (напр., «WHERE foo = :1»), 2) именованные параметры («WHERE foo = :foo»), 3) criteria API.
Таким образом, твои претензии низвергнуты.

Правда? А вроде просто сменили тему на тему про кэш.

Уже ответили на вопросы? Напомню, что основные вопросы были. Где в запросах автодополнение наименований таблиц и полей? Почему в запросах параметры в стрингах? Т.е. они не автодополняются и не валидируются на этапе компиляции? Почему вообще все запросы оформлены в виде строк? Для их автоматического конструирования необходима работа с конкатенацией? Это промышленное решение?

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

Еще остался вопрос, зачем в результате выполнения работы объекты. Т.е. по поводу темы про DAO, DTO и т.д. мне никто так и не ответил.

Но ведь в Java 7 появился try-with-resources, который является прямым аналогом «скопа with-db» в данном случае.

Реально в 99% тут будут или container managed transactions или аннотация @Transactional через AOP, причем готовая например из Spring

Ох и запутаешься с действующими персонажами.

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

Плюс есть джаванутый, причем из упоротых у которые поклоняются устоявшимся практикам, не то чтобы они плохие, но мышление закостеневает от них сильно если не допускать мысли что может быть не все так гладко и ежедневно решаемые проблемы - следствие инструмента. Короче высокооплачиваемый по его словам специалист с личной яхтой и самолетом, который он заработал на джава формошлепстве, которым вообщем и занимаются почти все джава программисты. Эксперт по Хаскеллю (и по всему), хотя его сильно ненавидит, хотя хаскеллисты вроде его не били и не крали его денег, но надо как то оправдать какой-то свой комплекс. Не может понять лиспера, потому что жабка решает его задачи, больше ничего она не умеет, а ему и не надо. Синдром Блаба

Вроде есть еще один анонимус, который вроде просто джава программист без воспаленных мозгов.

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

Зарегистрируйтесь уже? Будет проще вас банить модераторам а у самих будет мотивация корректировать лексикон и таким образом выглядеть солиднее. А то не важно что вы пишете, школота вы школотой с этими гоп-стайл речами

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

атем, что ООП предлагает гораздо более богатый набор отношений, чем реляционная модель.

В том то и дело, что модель. Не все задачи сводятся созданию моделей в понимании ОО.

Ты опять ничего не понял. Таблицы и отношения в РСУБД — это как раз и есть имитация, или модель, реального мира.

Правильно, а в программе, работающей с СУБД, данные из СУБД являются той самой реальностью, с которой нужно работать.

А ФП вообще неспособно моделировать окружающий мир

Цель не моделировать, а получить результат или осуществить действие. Иногда нужно моделирование чего-то, иногда нет. Пойми, моделирование не плохо, плохо частный подход делать глобальным для решения всех задач.

Поэтому мы работаем в краткой, удобной и понятной объектной семантике

Краткой? Это такое самовнушение? В большинстве своем решения с соблюдением ОО парадигмы приводят к созданию промежуточных абстракций и связанного с ним большого количества кода, которое не имеет отношение конкретно решаемой задаче, а представляет плод воспаленного разума ООПнутого автора, «моделирующего» реальный мир.

Это ложь, и я не утверждал этого.

Ты не утверждаешь, что ORM это ынтырпрайз, а DSL это поделки?

Исходная посылка заключалась в том, что для написания проектов уровня предприятия необходимы технологии, обеспечивающие требования масштабируемости, надёжности, производительности, безопасности, управляемости. И Java ORM обеспечивает это всё естественным образом.

Я всегда думал, что «для написания проектов уровня предприятия необходимы технологии, обеспечивающие требования масштабируемости, надёжности, производительности, безопасности, управляемости» требуется хороший специалист, а не какая-то все за тебя делающая технология. Также убежден что утверждение «И Java ORM обеспечивает это всё естественным образом» ложно.

A SQLKorma — либо обеспечивает при помощи костылей, либо не обеспечивает вообще.

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

Если отмести шелуху — останется десяток вакансий на континент. Точно так же, как и в других местах.

Ну-ка отмети, и если у тебя по clojure/lisp/haskell останется больше, то кем ты будешь? Да оно и так ясно.

Тебе блаб-парадокс (http://www.nestor.minsk.by/sr/2003/07/30710.html) не даст понять, что значит более мощный язык. Так что бесполезно объяснять.

Т.е. объяснить ты не можешь? Слив засчитан.

Т.е. прочитать ты не можешь? Или прочитал, но не понял? Хорошо, слив засчитан.

Запрос является обычной функцией (select).

Но ведь executeQuery() и find() в EntityManager тоже являются обычными методами.

Нет, сам запрос является обычным стрингом, а не методами.

Что значит — «контроль над структурой запроса»? Ты хочешь сказать, что JPQL/JDOQL как язык плохо понятен тебе, и строковое выражение запроса вызывает у тебя банальные оли? Но ведь есть Criteria API, при помощи которого достигается полностью контролируемое программное конструирование запроса. Ты просто не знаком со спецификациями Java Persistence и Java Data Objects.

Ты просто не знаком, как работают с запросами в БД на нормальных языках. Ты все пытаешься доказать, что набирать запросы в стринге это хорошо. А тебе пытаюсь показать, что набирать запрос конструкциями языка (ты же не врубаешься, что такое sql dsl, поэтому представь, что эта возможность встроена в язык программирования) это хорошо, т.к. есть автодополнение как конструкции запроса, так и имен таблиц и полей, валидация на этапе компиляции, возможность параметризировать запрос не через левые костыльные методы, а сразу в запросе, и т.к. запрос является структурой языка (лиспа), имеется возможность сгенерировать такую конструкцию по какому-либо правилу и у тебя доступна вся мощь языка для этого.

Зачем тогда ты вступаешь в дискуссию на темы, в которых некомпетенен?

Ога, ты компетентен в споре о двух предметах, зная только один. Советую изучить вопрос, написать для самообразования свой SQL DSL для того, чтобы понять, что это и какие плюсы и минусы имеет, сравнить с существующими DSL-ами, и только после этого участвовать в дискуссиях ORM vs SQL DSL.

Полудурок, БД это и есть реальный мир

Но ведь это чушь. Реальный мир — это самолёты, корабли, поезда, грузы, счета, транзакции и так далее.

Неправильно. Ты работаешь из слоя программы, взаимодействующего с БД, при подготовке запроса к БД для тебя реальность - логика работы БД. Как только данные получены, ты их передаешь на следующий уровень, где идет, например, работы по отдаче данных в SOAP/REST сервис, на этом уровне для тебя реальность логика работы этого SOAP/REST сервиса. Ты путаешь мягкое и теплое.

StackOverflow? Лол, ты бы ещё на RSDN ссылку дал.

Неважно где, главное, что уже отвечали на такие вопросы и ответы уже были даны.

задача, которую тоже нельзя реализовать только с помощью фвп: сделать конструкцию «with-open-...»

Так оно же будет работать за счёт unwind-protect, try-catch-finally, bracket и т.п. специальных форм или функций вокруг исключений, stack unwinding и т.п. механизмов рантайма. Сами with-* макросы тут просто сахар который не привносит ничего что нельзя было бы написать достаточно просто и без них. То же самое с foreach - есть обычные циклы и функции вроде std::for_each и map - какая разница стоит имя переменной до коллекции или после? Чисто сахарное же отличие, тогда как полноценные макросы это не дешёвая фича (то есть «либо это лисп, либо макросы неполноценные»). То же самое с printf - реализуется cl:format, varargs, шаблонными функциями, классами типов (тут, разве что, вопрос с type safety может быть).

Простые примеры не особо впечатляют - чтобы макросы выглядели какой-то реальной киллер фичей это нужен более-менее сложный компилируемый eDSL, а какие задачи требуют или хотя бы хорошо ложатся на построения компилируемых eDSL-ей? При наличии такой задачи раздельная компиляция с выхлопами транслятора DSLя (интерпортабельного, но уже не «embedded») делается не особо сложно.

Ну да, «задроты», пока ты пьешь пиво, корпят, изучают, не останавливаясь на достигнутом. Тяжело и упорно расширяют границы своих знаний. Каждому свое.

Перевожу: высококлассный специалист, имея широкий кругозор и спектр интересов, путешествует по свету, занимается спортом, смотрит кино, слушает музыку, посещает театры и выставки, наслаждается высокой кухней и благородными напитками, пользуется вниманием прекрасных дам.

Не правильно перевел. Правильно: некоторые считают, что радость не ограничивается употреблением пива в свободное от работы время с неинтересным собеседником в лице начальства, которое считает, что работа это не для души, а пашка с 9 до 6. Если и интересно с кем провести время за столиком в хорошем кафе, так это с интересными людьми, увлекающимися и изучающими интересные области, работающие над безумно интересными проектами. Про исключение кино, театра, спорта и т.д. разговора не было.

В то время как задрот сидит в своей норе и задрачивает анаморфизмы, катаморфизмы, эндоморфизмы и параморфизмы.

Выражение «в то время» некорректно. Правильнее «всегда находит время на расширение своих границ, т.к. понимает, что реализовать свой потенциал является для человека самой главной целью, добиваясь которой получаешь такое удовольствие, которое „пашущим с 9 до 6“ и не снилось.» А застрять на одном уровне, «обрастать жирком», смеяться над всеми, кто не хочет этого и еще гордиться этим, это не для всех.

А с макросами запросто, вот пример варианта реализации на clojure (на коммон лиспе аналогично):

Поздравляю, ты дёрнул себе анус левой ногой через пищевод.
Но зачем?

Поздравляю тебя, ты прекрасные пример блаб-парадокса.

Высококлассный IT-специалист не является зацикленным на чём-то одном (лисп, хаскель etc.) Как правило, он живёт полной жизнью, круг интересов имеет разносторонний, кругозор — широкий (в том числе научный и культурный). Поэтому ему требуются средства на реализацию в других областях, отличных от IT. Это могут быть спорт, творчество, путешествия, интересные частные научные исследования и так далее. Всё это требует хорошего финансового обеспечения.

Не спорю.

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

При чем тут лисп? У тебя проблемы с лиспом? Хочешь поговорить об этом?

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

У Стругацких было в одном романе классное высказывание: Жизнь дает человеку всего три радости: друга, любовь и работу; но очень редко кому-то достаются все три.

Допустим, ты открыл скоп (with-db ...), при помощи (select ...) выбрал 1000 сущностей, и они загрузились в структуры/коллекции Clojure. После этого ты вызываешь бизнес-метод (или функцию, если термин «бизнес-метод» вызывает непонятный зуд в области чуть ниже спины). Бизнес-метод модифицирует, скажем, 100 из 1000 структур. Теперь тебе надо скинуть изменения в базу.
Внимание, вопрос: каким образом ты узнаешь, какие именно сущности надо апдейтить?

У меня бизнес-метод вернет коллекцию новых данных (оверхеда не будет, см. Clojure Persistent Data Structure), по которым останется лишь проапдейтить данные в бд.

Сравнивать Java ORM и SQLKorma вполне можно.

То можно, то нельзя. Определись уже.

Действительно, мы только что это проделали и получили результаты: SQLKorma — поделка для двухзвенок, JPA/JDO — мощные фреймворки для построения систем уровня предприятия.

Действительно, во все посты плавно ушли в сторону обсуждения кэша, а на базовые вопросы недостатков ORM в сравнении в SQL DSL так и не поговорили.

Нельзя противопоставлять их. Как было показано выше, это технологии совершенно разных масштабов.

DSL это не технология это техника программирования. Долго еще будешь сравнивать теплое с мягким? Чо уж, давай еще про кэш.

Поэтому только некомпетентный собеседник может утверждать, что якобы «SQLKorma мощнее Java ORM».

Только некомпетентный собеседник не понимает, что sqlkormf это один из примеров SQL DSL, не понимая принципа их создания, и для чего они делаются.
Только некомпетентный собеседник не поймет, что речь идет подходе ORM вообще против заточенного на формирование запросов SQL DSL.
Только некомпетентный собеседник не понимает, что ORM создает больше проблем, проявляющихся в бессмысленных DAO, TAO, BO и т.д., когда есть просто данные.
Только некомпетентный собеседник не усвоит простой вещи, что моделировать мир как это делается в ООП для решения всех задач является патологией с последующей терминальной стадией ООПнутости.

Все проблемы решаются макросами, строго доказал что foreach без макросов не написать,

foreach был предложен как пример на конкретное заявление. А про «Все проблемы решаются макросами» впервые слышу и то от тебя.

списки - все что вообще человеку может быть надо.

Ты наверно не в курсе, что речь шла не про списки, а про коллекции: списки, векторы, сеты, хэшмапы, массивы и т.д.

Джавистов понять не может, потому что вообще не пишет ничего кому-то нужного, живет на мамином борще,

Телепатия - признак душевного расстройства.

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

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

Сами with-* макросы тут просто сахар который не привносит ничего

Не согласен. Привносят, чему служат примеры реализованных в лиспах тех же with-*, doseq, for, loop и т.д. Вообще Пол Грэм хорошо описал, когда нужно использовать макросы и какие у них плюсы и минусы http://www.bookshelf.jp/texi/onlisp/onlisp_9.html

что нельзя было бы написать достаточно просто и без них.

Конечно, теоретически можно все писать через функции, но практически тяжело обойтись без абстракций, которые дает этот «сахар».

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

Ты здесь никого этим не впечатлишь. Люди шарахаются не то что бы от макросов, а от фп и лиспа вообще.

Конечно, теоретически можно все писать через функции

А раньше слиться было слабо?

Ты здесь никого этим не впечатлишь. Люди шарахаются не то что бы от макросов, а от фп и лиспа вообще.

Люди шарахаются от твоего невежества и лживой демагогии.

нужен код, которые реализует конкретное тех.задание

Ты не способен ни сформулировать конкретное техзадание, ни ответить на конкретный вопрос.

чему служат примеры реализованных в лиспах тех же with-*, doseq, for, loop

Ну with-open-file и loop это очень разные вещи - первое это простая инициализация вокруг let и open перед unwind-protect с телом и гарантированным close - основную работу делает примитив unwind-protect. С тем же успехом можно писать на С++ класс с простой инициализацией в конструкторах и RAII с гарантированным освобождением ресурсов. Ну или вот ещё пример. Главное, что это возможно из-за поддержки в рантайме. Точно так же все эти with* можно писать на хаскеле как обычные ленивые IO функции - там bracket/etc. есть.

Я говорил скорее о том, что если макросы есть и естественны в языке, то с ними можно и по воробьям стрелять - типа твоих for_each или with-*, но просить проделать то же самое в языке без поддержки макросов просто бессмысленно и вызывает естественное «нафейхуа» (там всё это же решается и так, без всяких блабов :)). Вот разные формы кодогенерации, конфигурации и AOP на макросах - это да, делается быстрее и проще, в языке без макросов альтернативой будет библиотечное построение желаемого (типов данных, да) и интерпретация в рантайме (функциями, вместо кодогенерации макросами), либо внешние компилируемые DSLи (типа lex/yacc, protobuf и т.п.).

Ты здесь никого этим не впечатлишь

В контексте этого разговора впечатлять должны нетривиальные примеры метапрограммирования. Например, если говорить про макросы Clojure - в чём преимущество sql-as-s-expression против сырых строк с SQL или функций генерирующих SQL код в рантйме? По части статических проверок такого кода, по части удобства набора в IDE? Есть что-нибудь такое? Если сравнивать с сабжем, то есть определённые подвижки от типизированных функций строящих запросы к типизированным макросам строящим код строящим запросы - http://slick.typesafe.com/talks/scaladays2012/ScalaDays2012-SLICK.pdf.

Охлол. Что попало назвал, а самую адекватную реализацию назвать побоялся. Ибо не тормозит ведь.

Да и вообще, только полный долбонавт мог в контексте обсуждения скорости работы упомянуть Jython и IronPython, которые сами по себе работают на тормозных рантаймах.

качество станд.библиотек Питона явно хромает по сравнению с Java. Просто добавляли первые попавшиеся в нете либы - отсюда разброд и шатание в названиях, структуре, и в шаблонах проектирования.

Это ты о каких библиотеках? Точно о модулях в стандартной поставке? Они-то оттачивались годами. А вот за зоопарк в PyPi отвечают только его авторы, да.

Инсталлятор JRE7 весит всего 30М

Многовато для инсталлятора, к тому же оракловский JRE7 на системе с uClibc не заработает.

Ты не способен ни сформулировать конкретное техзадание, ни ответить на конкретный вопрос.

А, это ты про то, как ты влез в тему, ниасилил нормальное решение, потом на нем настаивал, не смотря на то, что я тебя тыкал в задание несколько раз. С тобой все ясно. Конечно, виноват я, что ты облажался.

я тебя тыкал в задание несколько раз. С тобой все ясно. Конечно, виноват я, что ты облажался.

Присоединяюсь к предыдущему оратору - ты посмешище. Добавлю, что ты позор Clojure-сообщества.

Ну with-open-file и loop это очень разные вещи

Очевидно.

С тем же успехом можно писать на С++ класс с простой инициализацией в конструкторах и RAII с гарантированным освобождением ресурсов.

Написать аналог можно хоть на чем. Именно аналог. Вопрос в том, что with-* дает новую абстракцию, а как там внутри уже не должно волновать пользователя конструкции. Ты с этим не согласен, насколько я понял и в лиспе не используешь with-open*/with-*?

Я говорил скорее о том, что если макросы есть и естественны в языке, то с ними можно и по воробьям стрелять - типа твоих for_each или with-*

Странно, почему тогда в том же лиспе и clojure это реализовали и этим повсеместно пользуются?

А вообще, ты в курсе, к чему был пример с foreach? Не про возможности макросов, а как пример, что такую именно такую приведенную конструкцию нельзя сделать только с помощью фвп.

В контексте этого разговора впечатлять должны нетривиальные примеры метапрограммирования.

В контексте какого разговора? Темы про мощь макросов не было и этот контекст начал ты.

Например, если говорить про макросы Clojure - в чём преимущество sql-as-s-expression против сырых строк с SQL или функций генерирующих SQL код в рантйме?

В том, что sql-dsl позволяет использовать запросы в других выражениях (т.е. сразу что-то делать с результатом).

Sql dsl позволяет параметризировать запрос коллекциями и типами языка непосредственно в самом запросе, т.е. например, в селекте в качестве набора полей или в условии c in передать соответствующий лист, или сгенерировать запрос как s-expression. Такие действия в самом языке гибче, проще и безопаснее, чем работать с конкатенацией строк. Например (пример высосан из пальца),

(defn get-some-clients [p1 p2 p3]
 (map (fn [client]
        (retr-info-from-client client)) 
      (with-db db (select table-client 
                    :where [:in client-id (map :id (get-from-oth-src p1 p2 p3))]))))

По части статических проверок такого кода, по части удобства набора в IDE? Есть что-нибудь такое?

Есть. Синтаксис запроса, актуальность наименований полей и таблиц проверятся на этапе компиляции. Как уже говорил, по всему есть автодополнение.

DSL это не технология это техника программирования. Долго еще будешь сравнивать теплое с мягким? Чо уж, давай еще про кэш.

Лошарик, Hibernate - это тоже DSL. Ты сравниваешь DSL и DSL. Только SQLKorma - это убогая студенческая поделка, а Hibernate - отточенная годами, надежнейшая, мощнейшая технология, в которую вложены сотни тысяч человекочасов.

есть автодополнение как конструкции запроса, так и имен таблиц и полей

Не знаю, поверишь или нет, но там когда строку пишешь, то оно в строке догадывается сделать completion ;)

либо это лисп, либо макросы неполноценные

Правда, годная фраза, запишу. Ваше авторство?

Или неполноценность потому что лисп или неполноценность макросов. Страшно жить

> а джавистам надо проект релизить для каких-то глобальных корпораций в постоянном режиме

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

Ты прав. Потому компаниям нужен строгий estimate и гарантированная работоспособность проекта. А уж петабайтиков жабка побольше перемолола чем нампример SBCL, LispWorks. Если мы будем давать фору лиспу, тоесть будем сравнивать возможности, фичи, будем допусать что программисты одинаково легко будут осваивать оба инструмента, что потенциально инструменты могут быть развиты у обоих, тогда у лиспа есть все шансы. Ведь это хороший язык.

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

А вот Clojure тут конечно совмещает хорошие качества обоих сторон. Если вам он нравится, то пишите дома.

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

а от фп и лиспа вообще

а от фп

Ни в коем случае, его все любят. В SQL, Python, Groovy, Ruby, Scala, C#. Уже особо консервативная каста начала даже Guava использовать. Ждем Java 8

лиспа вообще

Это да. Можно это принимать, можно признавать, не признавать, негодовать. Но ничего не поменяется, причем у же никогда

есть автодополнение как конструкции запроса, так и имен таблиц и полей

Не знаю, поверишь или нет, но там когда строку пишешь, то оно в строке догадывается сделать completion ;)

Completion чего и в какой среде и по какому механизму срабатывает?

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

Переформулирую. Именно для ваших проектов именно с вашим подходом к набору персонала и процессу разработки наиболее оптимальным является выбор джава платформы.

А вот Clojure тут конечно совмещает хорошие качества обоих сторон. Если вам он нравится, то пишите дома.

Спасибо за разрешение.

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

В нашей команде талантливые специалисты с пытливым умом, для которых переход на clojure не является rocket science-ом. Если вы набираете кодеров, для которых тот же фп является непреодолимым барьером, то да, ваши рассуждения правильны.

В нашей команде талантливые специалисты с пытливым умом, для которых переход на clojure не является rocket science-ом. Если вы набираете кодеров, для которых тот же фп является непреодолимым барьером, то да, ваши рассуждения правильны.

Вы же говорили о экономических основаниях? Или уже отказываетесь от того что это важно? Плюс такие люди обычно делают дело. А лисперы-ылитарии будут форсить свои суперрешения из-за мании величия, вместо конструктивизма и взаимодействия. Зато они наверное на олимпиаде одиночной хорошо себя показали, это да

Вы же говорили о экономических основаниях? Или уже отказываетесь от того что это важно?

Вы это к чему?

Плюс такие люди обычно делают дело.

Все делают дело. И что?

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

Вы пробовали держать команду из лисп-программистов и они вам загубили проект? У вас есть опыт разработки проекта на лиспе? Или вы просто боитесь непонятного вам?

Зато они наверное на олимпиаде одиночной хорошо себя показали, это да

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

Просыпаюсь в холодном поту представляя хамовитую и матераюящуюся команду, это прилагается к знанию лиспа

Противоречит, да и вообще анонимус начал с того, как это круто юзать серверы приложений, jta, jms, etc. А кто не использует JEE-шелуху, значит вообще ничего не понимает в разработке. JEE the best111. Его «анализ опыта» сводится к тому, что они использовали JEE и будут использовать. Типичный подход от инстумента, а не от задачи.