Вышла Scala 2.10

то есть на самом деле тройка из полиморфизма, наследования и инкапсуляции не так важна, как сама возможность реализовать задачу в терминах оод?

Существует несколько парадигм, которые называют себя «объектными». Есть среди них маргинальные: CLOS в Common Lisp (там методы не принадлежат классам, зато присутствует multiple dispatch), Smalltalk и Ruby (отправка сообщений). Наиболее практичной и жизнеспособной показала себя парадигма «инкапсуляция-наследование-полиморфизм».

Давайте возьмём самую популярную ООД-методологию — UML. Что у нас там есть? UML описывает: 1) классы, у которых есть поля и методы и интерфейсы, у которых есть только методы, 2) отношения наследования (между классом-родителем и классом-потомком) и реализации (между классом и интерфейсом), 3) отношения ассоциации/агрегации/композиции. Там есть много чего ещё, но это самое основное.

Таким образом, если язык имеет в своём арсенале вышеописанное (или хотя бы умеет эмулировать недостающее — например, интерфейсы через классы), то можно сказать, что такой язык способен реализовать данную объектную модель.

Вы сильно упрощаете насчёт альтернатив - их гораздо больше

И что же это за альтернативы?

Вы сильно упрощаете насчёт альтернатив - их гораздо больше

И что же это за альтернативы?

да разные бывают, как насичот: состоятельные люди, владеющие крупным бизнесом в IT, и готовые вложиться во вменяемый стартап

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

Не буду придираться к цифре десять, хотя вакансий намного поболее.

Вообще, странная аргументация с цифрами по вакансии. Мне вот интересно, зачем тебе миллионы вакансий? Если тебе нужна именно одна вакансия с интересной высокооплачиваемой работой в нужном для тебя городе/стране?

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

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

Я не утверждаю, что, например, на java/php только скучные проекты. Но реально интересных проектов на этих языках тоже мало, как и вакансий с haskell/lisp.

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

да разные бывают, как насичот: состоятельные люди, владеющие крупным бизнесом в IT, и готовые вложиться во вменяемый стартап

Венчурные капитализды, ага.

Знаешь значение слова «венчурный»? Это означает, что добрый дядя в любой момент может отозвать своё бабло. Например, если прознает, что ваши кодеры обкурились теорката и теперь обмазываются зигоморфизмами, вместо того, чтобы решать поставленную задачу.

Не буду придираться к цифре десять, хотя вакансий намного поболее.

Пруфы?

раз используются такие мощные языки

1) что значит «мощные»? 2) пруф того, что лисп/хаскель мощнее мейнстримных языков.

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

В чем отличие от первого-второго вариантов? И где тут гораздо большее количество альтернатив?

И да, свой слив насчёт SQLKorma прокомментировать не желаешь?

Мне вот интересно, зачем тебе миллионы вакансий? Если тебе нужна именно одна вакансия с интересной высокооплачиваемой работой в нужном для тебя городе/стране?

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

Говорить о количестве вакансий имеет смысл только в одном случае, когда ты низкоквалифицированный специалист.

LOL
А потом вот такие «высоковалифицированные специалисты» по паре лет на пособии сидят.
А все изза того что рынком работы не интересуются.
Хотя вы возможно считаете себя более квалифицированным чем я так как не интересуетесь ваканчиями. Совершенно не имею проблем не собираюсь конкурировать с вашим самомнением.

Но если вакансий мало, это говорит что ни на высокую ни на низкую оплату специалисты не нужны.

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

Как правило это индикатор того что программисты творят что хотят не спрашивая начальство.

Исключение - трейдеры и финансы где математика вообще и ФП в частности востребованы, но и там Лисп не очень популярен а Хаскел я даже не слышал чтобы применяли.

особенно трудны для освоения

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

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

Согласен, наследование вообще общее понятие. Я про то, что оно в программировании в основном как термин применяется в ООП.
Я не создаю классы в своем коде, если не нужна работа с джавой. Если не создаю классы, то и не применяю наследование.

Если наследование - «общее понятие», то для наследования не обязательно создавать java-классы. Простой вопрос: каким механизмом ты воспользуешься для построения отношений «родительского дерева», когда потомки наследуют свойства или возможные варианты «поведения» родителей?

Если нет, то что это за класс задач таких, где объекты, массивы данных не обладают общими свойствами?

«Обладать общими свойствами» не прерогатива ОО.

С помощью какого механизма тогода ты будешь выражать обладание общими *зависимыми* свойствами каких-нибудь абстрактных структур-объектов?

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

Эта фраза - пример т.н. «белого шума». Правильное начало перечисления параметров диспетчеризации должно было звучать так: «мультиметоды (множественная диспетчеризация) - это выбор реализации ф-ии в зависимости от: типа параметров, значения параметров, ...».

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

С типами и значениями все понятно. Откуда «вытаскивать»? Чем кортежи - не значения? Да, и еще не так давно ты называл «кортежи» сленгом сельских учителей :)

а чем объекты заменяются?

Функциональным программированием.

Хорошо хоть не святым духом. Если бы ты написал структурами и функциями над ними - было бы более конкретно. Но я все равно задал бы вопрос о наследовании, тогда уже не объектов, а структур. Как эта задача решается в ф-ном программировании?

А мощь инструмента реюза «макросы» на уровне функций, которые есть в любом яп.

'«макросы» на уровне функций' что это? Что есть в любом ЯП?

Функции есть во всех яп. Уровень мощности инструмента «функция» для решения задачи реюза (в общем случае) эквивалентен мощности инструмента «макрос».

Преимущества dsl над чистым sql в том, что dsl является частью языка: функции, коллекции -

Из приведенного тобой примера я вижу только как это «преимущество» засоряет область видимости.

т.е. можно применять весь арсенал языка (например композиции, map/filter, etc).

Это реализуется на уровне библиотеки. Все функции для манипуляции sql-таблицами просто импортируешь в текущую область видимости. DSL тут не понадобятся. Ни (e), ни без (e).

У меня возникает смутное чувство, что ты не очень-то понимаешь, что такое DSL. Библиотека с набором специфичных функций это не DSL. И тем более - не eDSL.

Например

Ты осознаешь, что работаешь с объектом-структурой, sql-таблицей,- с изменяемым состоянием или нет? Если да, то почему тогда не отобразить *структуры* таблиц (и триггеры) в обычных для sql терминах изменяемых объектов через наличествующие языковые конструкции? Если так сделать - получится ORM. А у тебя, как я ранее и предполагал «библиотечка» для формирования запросов.

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

Именно - это обычная (библиотечная) функция.

Позволяет в выражении использовать коллекции языка (client-ids - может быть вектором или списком).

Это часть любого orm - внутренний (в термах яп) язык запросов, преобразующий (иногда не очень прозрачно) структуры яп в структуры sql, возможно через промежуточные структуры яп.

Контроль над структурой запроса

Что имеется ввиду?

Автодополнение имен таблиц и полей

Есть в ORM.

Т.е. у вас переход с sql на nosql происходит часто?

Нет, но если проект с потенциальной большими объемами данных - на этапе прототипа можно работать с sql-like-bd, а потом уже (когда понадобиться) переносить. Это сэкономит время.

В данном контексте речь идет о eDSL.

Как выяснилось, нет.

Итак, рассмотрим, что же такое SQLKorma и насколько корректно сравнение его с Java ORM. Мы будем рассматривать технологии Java Persistence Architecture (JPA) и Java Data Objects (JDO).

1. Отображение таблиц реляционной СУБД на сущности языка.

У меня сущности языка - коллекции. Запишем, в лиспе такой пункт есть.

2. Язык запросов (ориентированный на сущности) и его трансляция в SQL.

В JPA нет языка запросов, там есть named query с запросами в виде string-ов. Запишем, в лиспе язык запросов есть, в джава - нет.

3. Кэш... В SQLKorma нет ни намёка на кэширование.

Это такой ынтырпрайз подход делать валить все в одну кучу? Зачем внутри sql dsl-а кэш?

...Вторая нить делает запрос на загрузку одной из тех сущностей, и получает кэшированный объект. Если вторая нить модифицирует сущность, то первая нить увидит изменение без перезагрузки объекта из базы.

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

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

2-го уровня (грубо говоря — кэш уровня приложения), распределённый кэш (Oracle Coherence, Cacheonix, EHCache, SwarmCache). SQLKorma: (не поддерживается)

Ага, кэш 2-го уровня без ORM-а никак не может существовать. Вот это промывка мозгов.

@PersistenceContext EntityManager em;
em.begin(); // Здесь происходит загрузка сущности и всех связанных с ней сущностей
MyEntity obj = em.find(MyEntity.class, id); // Бизнес-метод модифицирует как саму сущность, так и часть связанных с ней
obj.businessMethod(); // Транзакция записывает в хранилище изменившиеся сущности
em.commit();

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

А что это за em.begin() и em.commit()? Точно автоматически? Лукавишь. А где описано, что будет при исключении?

В SQLKorma нет ничего, что хоть отдалённо напоминало бы подобное поведение.

Правда? Давай посмотрим:

(with-db db
    (select ...)
    ...
    (update ...)
    ...
    (insert ...)
    ...)

Если все пройдет хорошо, то при выходе за скоп «with-db» все изменения закоммитятся, если произойдет исключение, то будет rollback. Без всяких ручных em.begin() и em.commit() во всех точках выхода. Тут опять твой ORM-монстр сливает.

5. Non-SQL источники данных. JDO (DataNucleus): Excel, OOXML, ODF, XML, HBase, MongoDB, AppEngine/DataStore, Neo4j, JSON, Amazon S3, GoogleStorage, LDAP, NeoDatis SQLKorma: (не поддерживается)

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

...
Query q = pm.newQuery("SELECT FROM " + Product.class.getName() + 
                          " WHERE price < 150.00 ORDER BY price ASC");
...

Все такая же низкоуровневая неконтролируемая ручная работа с запросами в виде стрингов. И здесь опять SQL DSL в выигрыше.

Сорри. Ты опять показал, какую убогую технологию используешь.

6. Типы отношений.
JPA/JDO: uni- and bidirectional; one-to-one, one-to-many, many-to-one, many-to-many, embedded entity

Отношения это задача СУБД, для этого реляционные базы и создавались. Зачем какая-то ограниченная имитация, если можно использовать оригинальные возможности, описанные стандартом SQL, при этом не привязываясь к конкретной реализации? Тебе промыли мозг основательно, рассказывая что нет жизни вне ORM-а.

SQLKorma — студенческое поделие.

Куда авторам этой поделки до такого профессианала как ты.

Для создания трёхзвенных архитектур SQLKorma не пригодна, так как не реализует необходимых механизмов.

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

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

Ага, и поэтому ты тут (Вышла Scala 2.10 (комментарий)) проводишь детальное сравнение, то по твоей логике тебе применимо определение «некомпетентен в области программных систем уровня предприятия, а также не имел дела с крупными распределёнными гетерогенными проектами. Скорее всего, является школьником, наслушавшимся ЛОРовских троллей и решившим».

И тут ты опкакался. Да что же это такое.

а чем объекты заменяются?

Функциональным программированием.

Ну это просто царь-пушка!
Знаешь ли ты основное предназначение ООП? Открою секрет. Это — information hiding, separation of concerns, low coupling.

Да ты шо?! Такая круть! И только в ООП?! Уау!

Перевожу:

Придурок, не надо переводить. Это все такое понятное и базовое. Но видимо для тебя все это вершина знаний (но не умений).

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

Жертва маркетологов, запомни, это не прерогатива ООП. Если ты без ООП не пишешь так, то для тебя конечно это будет откровением. Хотя, ты кроме ООП больше ничего не знаешь, и сравнивать тебе не с чем. Домашнее задание, попробуй заменить в своем высере «ООП» на «хороший дизайн» и прочитай.

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

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

Впрочем, я могу ошибаться.

Хорошо.

В таком случае объясни мне, каким образом функции высшего порядка, отсутствие сайд-эффектов и каррирование (а ведь это как раз то, что отличает функциональное программирование от процедурного, ты ведь знаешь это, не так ли?) призваны решить задачи information hiding, separation of concerns и low coupling. Спасибо.

ФВП позволяют писать короткий высокоуровневый код с большим КПД повторного использования, с возможностью создания DSL для конкретных задач. Отсутствие сайд-эффектов позволяет намного проще писать многопоточные приложения, упрощает тестирование, уменьшает связанность между частями программы, убирает зависимость от порядка выполнения.

В двух словах получились общие формулировки. Но какой вопрос, такой и ответ. Если есть более конкретные вопросы, то постараюсь ответить.

У eDSL в который запихивают другой DSL (в данном случае SQL) есть принципиальная проблема. Вообще _правильный_ DSL это способ короткой (очищенной от несущественных деталей) записи для сложной предметной области, предназначенный для профессионалов в этой области.
Когда один DSL(первый) упаковывают во второй, значит либо признают, что используют первый DSL как стрельбу из пушки по воробьям, либо вешают на пользователя второго DSL _все_ проблемы, ради решения которых создавался первый, при этом специалиста по проблемам первого DSL могут отморозить проблемы второго (а если их нет - то зачем было второй DSL создавать?).
В любом из этих случаев сложность не прячется, а накапливается. Это с натяжкой допустимо, если разработчиков мало и особенной специализации у них нет. Но если потом потребуются высококвалицированный узкий специалист, то от одного из этих DSL придется срочно отказываться. А если два разных специалиста - то переписывать все с нуля.

Ты много писал DSL. Можешь привести примеры к своим суждениям?
Пойми, DSL это необязательно для «профессионалов в этой области». Вот тебе аналогия. Например в твоем языке нет оператора foreach, а он бы сделал твой код намного понятнее. Вот ты реализуешь foreach и код становится чуть яснее. Вот ты видишь, что в foreach ты не выполняешь только создаешь новую коллекцию, хэшмап или еще что и делаешь это часто. Ты создаешь map. И программа становится чуточку яснее. Потом ты понимаешь, что ты со своими данными делаешь много операций, и ты создаешь filter/reduce/etc. И код становится еще чуточку яснее. Так понемногу ты добавляешь в язык систему конструкций/функций. И конце концов в итоге, когда программа готова, у тебя на руках короткий, ясный высокоуровневый код. Разве плохо?

Есть SQL, есть HTML, есть CLIPS, но нафига все-все-все eDSL'ить в кложуру (другой супер-пупер мета-язык)? Чтоб при удачном стартапе раз'eDSL'ивать обратно?

Ты просто еще не врубаешься. И городишь чушь. Лучше спрашивай побольше и проси примеры по полученной информации.

Или чтобы разработчик на гусенечном велосипеде на подводных крыльях с прямоточным РД утонул в деталях?

Знаешь, не тонут. Наоборот, благодаря DSL-ам и не тонут. Для этого они и пишутся, чтобы не тонуть. Ты опять не попал.

Не буду придираться к цифре десять, хотя вакансий намного поболее.

Пруфы?

Зайди на http://www.indeed.com поищи по clojure/scheme/lisp/haskell. Посмотри на других ресурсах. Вакансий достаточно, чтобы найти интересную для себя работу.

раз используются такие мощные языки

1) что значит «мощные»?
2) пруф того, что лисп/хаскель мощнее мейнстримных языков.

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

И да, свой слив насчёт SQLKorma прокомментировать не желаешь?

Это в твоих мокрых снах. Когда в твоем ORM появятся преимущества, которые я описал в Вышла Scala 2.10 (комментарий), тогда и поговорим. А пока по всем этим пунктам адепты ORM-ов жестоко сливают.

Мне вот интересно, зачем тебе миллионы вакансий? Если тебе нужна именно одна вакансия с интересной высокооплачиваемой работой в нужном для тебя городе/стране?

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

Откуда такая цифра - 10? Шансы почти 100% при высокой квалификации.

Говорить о количестве вакансий имеет смысл только в одном случае, когда ты низкоквалифицированный специалист.

LOL
А потом вот такие «высоковалифицированные специалисты» по паре лет на пособии сидят.
А все изза того что рынком работы не интересуются.

Хотя вы возможно считаете себя более квалифицированным чем я так как не интересуетесь ваканчиями. Совершенно не имею проблем не собираюсь конкурировать с вашим самомнением.

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

Но если вакансий мало, это говорит что ни на высокую ни на низкую оплату специалисты не нужны.

Мало это сколько? Мало по сравнению с чем? Глупое высказывание. Какая разница, сколько вакансий, если их достаточно, чтобы найти интересную хорошооплачиваемую работу.

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

Как правило это индикатор того что программисты творят что хотят не спрашивая начальство.

У тебя есть статистика, чтобы так уверенно это утверждать? Т.к. логикой этот бред не объяснить.

Исключение - трейдеры и финансы где математика вообще и ФП в частности востребованы, но и там Лисп не очень популярен а Хаскел я даже не слышал чтобы применяли.

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

Например в твоем языке нет оператора foreach, а он бы сделал твой код намного понятнее. Вот ты реализуешь foreach и код становится чуть яснее. Вот ты видишь, что в foreach ты не выполняешь только создаешь новую коллекцию, хэшмап или еще что и делаешь это часто. Ты создаешь map. И программа становится чуточку яснее. Потом ты понимаешь, что ты со своими данными делаешь много операций, и ты создаешь filter/reduce/etc. И код становится еще чуточку яснее. Так понемногу ты добавляешь в язык систему конструкций/функций. И конце концов в итоге, когда программа готова, у тебя на руках короткий, ясный высокоуровневый код. Разве плохо?

Не проще ли сразу взять язык, на котором можно сразу писать короткий, ясный высокоуровневый код; в котором есть все эти map/filter/reduce etc, foreach - вообще одна из фундаментальных конструкций, а модулярность самого языка позволяет его расширять, не заботясь о пространствах имён?

Если наследование - «общее понятие», то для наследования не обязательно создавать java-классы. Простой вопрос: каким механизмом ты воспользуешься для построения отношений «родительского дерева», когда потомки наследуют свойства или возможные варианты «поведения» родителей?

С помощью какого механизма тогода ты будешь выражать обладание общими *зависимыми* свойствами каких-нибудь абстрактных структур-объектов?

Я кажется понимаю в чем загвоздка. Ты живешь в «королевстве существительных» (http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html) и думаешь соответственно. Поэтому иного способа в принципе понять не можешь и постоянно задаешь вопросы, кажущимися в твоей парадигме нормальными.

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

Эта фраза - пример т.н. «белого шума». Правильное начало перечисления параметров диспетчеризации должно было звучать так: «мультиметоды (множественная диспетчеризация) - это выбор реализации ф-ии в зависимости от: типа параметров, значения параметров, ...».

С типами и значениями все понятно. Откуда «вытаскивать»?

Лол. Надо же с таким важным видом сморозить чушь. Моя фраза основана на конкретном описании мультиметодов. Займись самообразованием что-ли http://clojuredocs.org/clojure_core/1.2.0/clojure.core/defmulti

а чем объекты заменяются?

Функциональным программированием.

Хорошо хоть не святым духом. Если бы ты написал структурами и функциями над ними - было бы более конкретно.

Специалист ты наш, ФП никак не определяется как структуры и функции над ними. Не позорился бы.

Но я все равно задал бы вопрос о наследовании, тогда уже не объектов, а структур. Как эта задача решается в ф-ном программировании?

Да, я знаю, тяжело менять парадигму. Посмотри пример ФП из учебника http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-15.html#%_sec_2.2.4 , может поможет и не будешь глупости спрашивать.

'«макросы» на уровне функций' что это? Что есть в любом ЯП?

Функции есть во всех яп.

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

Уровень мощности инструмента «функция» для решения задачи реюза (в общем случае) эквивалентен мощности инструмента «макрос».

Ну и позор. Быстро читать, что такое макросы в лиспе!

т.е. можно применять весь арсенал языка (например композиции, map/filter, etc).

Это реализуется на уровне библиотеки.

Грамотей, это и есть библиотечные функции.

Все функции для манипуляции sql-таблицами просто импортируешь в текущую область видимости. DSL тут не понадобятся. Ни (e), ни без (e).
У меня возникает смутное чувство, что ты не очень-то понимаешь, что такое DSL. Библиотека с набором специфичных функций это не DSL. И тем более - не eDSL.

Дурашка, edsl как раз и реализуется в виде библиотеки и представлен в виде набора функций и макросов. Отличие этих функций/макросов от просто функций, про которые ты говоришь, в том, что dsl описывает решение в терминах и абстракциях предметной области при этом, благодаря тому, что это простые функции, имеет в запасе всю мощь языка.

Ты осознаешь, что работаешь с объектом-структурой, sql-таблицей,- с изменяемым состоянием или нет? Если да, то почему тогда не отобразить *структуры* таблиц (и триггеры) в обычных для sql терминах изменяемых объектов через наличествующие языковые конструкции?

Запросы к скулю и отображены.

Если так сделать - получится ORM.

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

А у тебя, как я ранее и предполагал «библиотечка» для формирования запросов.

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

Именно - это обычная (библиотечная) функция.

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

Позволяет в выражении использовать коллекции языка (client-ids - может быть вектором или списком).

Это часть любого orm - внутренний (в термах яп) язык запросов, преобразующий (иногда не очень прозрачно) структуры яп в структуры sql, возможно через промежуточные структуры яп.

Запросы пишутся стрингами. Прозрачности нет. Нужны промежуточные структуры. Можешь не продолжать.

Контроль над структурой запроса

Что имеется ввиду?

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

Автодополнение имен таблиц и полей

Есть в ORM.

Врешь. Напиши мне запрос к скулю с автодополнением полей, таблиц и скуль команд в named query.

Т.е. у вас переход с sql на nosql происходит часто?

Нет, но...

Вес аргумента с переходом с sql на nosql ясен.

В данном контексте речь идет о eDSL.

Как выяснилось, нет.

Как выяснилось, ты представления не имеешь, что такое ФП, что такое функции в ФП, что такое макросы, не понимаешь смысл eDSL. Промолчал бы, не заметили. Правда?

Не проще ли сразу взять язык, на котором можно сразу писать короткий, ясный высокоуровневый код; в котором есть все эти map/filter/reduce etc, foreach - вообще одна из фундаментальных конструкций, а модулярность самого языка позволяет его расширять, не заботясь о пространствах имён?

Да, ты прав. Проще. Но на работе с последовательностями предметные области не заканчиваются же. Таким же образом язык затачивается под любую задачу любой предметной области. Задача будет решена не на многословном низкоуровневом синтаксисе, а на специально созданном для решении языке (eDSL). А решение будет выглядеть естественно, коротко и понятно.

Программирование на лиспе выглядит как создание таких вот слоев DSL, где каждый следующий слой опирается на нижележащий. Это программирование снизу вверх. Совсем не похоже на программирование снизу вверх в императивном низкоуровневом программировании. Уже приводил ссылку на пример такого подхода из учебника http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-15.html#%_sec_2.2.4 .

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

Он всё равно не просит тебя «сделай мне rule engine».

Но самовольно впендюрить движок, извините, это полная жесть.

Не более, чем самовольно использовать ORM.

ответ с галочкой, последний абзац.

Это: «Despite this my vote still remains that Javascript is object oriented. Why? Because given an OOD I can implement it in Javascript»? По этому определению и Си/Паскаль/Ассемблер являются объектно-ориентированными, так что определение - чушь.

Ну элементарно невоспитанных на ЛОРе полно, включая анонимусов, так что это не аргумент.

А суть доклада как раз в выборе инструментов.

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

Что не так? Можешь аргументированно опровергнуть какое-то из высказываний? Или так, вонюче бзднул и убежал.

Что опровергнуть, вот этот бред?

Выгребание из хэшмапа — O(log(n)) (в нормальных языках, разумеется, не знаю насчет кожуры).

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

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

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

С помощью какого механизма тогода ты будешь выражать обладание общими *зависимыми* свойствами каких-нибудь абстрактных структур-объектов?

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

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

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

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

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

Эта фраза - пример т.н. «белого шума». Правильное начало перечисления параметров диспетчеризации должно было звучать так: «мультиметоды (множественная диспетчеризация) - это выбор реализации ф-ии в зависимости от: типа параметров, значения параметров, ...». С типами и значениями все понятно. Откуда «вытаскивать»?

Лол. Надо же с таким важным видом сморозить чушь.

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

Моя фраза основана на конкретном описании мультиметодов. Займись самообразованием что-ли http://clojuredocs.org/clojure_core/1.2.0/clojure.core/defmulti

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

а чем объекты заменяются?

Функциональным программированием.

Хорошо хоть не святым духом. Если бы ты написал структурами и функциями над ними - было бы более конкретно.

Специалист ты наш, ФП никак не определяется как структуры и функции над ними. Не позорился бы.

Покажешь, где я определял фп как «структуры и ф-ции над ними»? Определение фп знает любой школьник (возможно, кроме тебя). А я спрашивал, чем ты заменишь объекты в разрезе вопроса о наследовании и отображении императивных сущностей (sql-таблицы с внезапно изменяемым состоянием или будешь как страус прятать голову в песок от реального мира?). Ответ «функциональным программированием» такая же глупость как и «святым духом». Ну, я уже понял, что ты тупой - можешь не отвечать.

Есть яп с функциями, про которые ты говоришь, а есть яп с функциями высокого порядка

Речь конечно про языки высокого уровня с фвп, это *очевидно*.

функциями гражданами первого класса.

Это то же самое, что и фвп, у тебя овердоз баззвордов. Почисти словарь.

Теперь иди почитай книжки по фп и возвращайся.

Там не о чем читать, все элементарно.

Уровень мощности инструмента «функция» для решения задачи реюза (в общем случае) эквивалентен мощности инструмента «макрос».

Ну и позор. Быстро читать, что такое макросы в лиспе!

Кроме кукареканья мы сегодня увидим хоть один ответ?

т.е. можно применять весь арсенал языка (например композиции, map/filter, etc).

Это реализуется на уровне библиотеки.

Грамотей, это и есть библиотечные функции.

Не сливайся так позорно, ты верещал что-то о макросах и dsl, а оказалось это все можно реализовать на библиотечных ф-циях. Признайся, ты на самом деле убогая php или жабомартышка, а clojure выбрал чтоб заделаться с илитоту?

Дурашка, edsl как раз и реализуется в виде библиотеки и представлен в виде набора функций и макросов. Отличие этих функций/макросов от просто функций, про которые ты говоришь, в том, что dsl описывает решение в терминах и абстракциях предметной области при этом, благодаря тому, что это простые функции, имеет в запасе всю мощь языка.

Вначале показываешь обычные функции и называешь это DSL, а затем eDSL'ем. Я тебе открою секрет, только не плачь, практически любой макрос (если не любой) можно написать используя только фвп, это обсуждалось даже здесь на лоре уже неоднократно. Макросы используют только как *крайний* случай - для введения новых языковых конструкций с сохранением обратной совместимости с хостовым языком (eDSL), для генерации функциональности сложной или не-элегантной через реализацию с помощью фвп (eDSL) и для создания нового *языка* _над_ хостовым - это DSL. Библиотеки - это не DSL и не eDSL, наша ты хамоватая невежда.

Запросы к скулю и отображены.

Ну правильно, это все что твое анальная поделка и может. Вот тебе, дурашка, пример нормального ORM - http://marijnhaverbeke.nl/postmodern/ - единственный косяк которой это бекенд только для postgres'a, автору, видимо, остальное не очень нужно.

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

Именно - это обычная (библиотечная) функция.

В лиспе все в программе решается с помощью функций и макросов

Макросы здесь не при чем, это просто библиотечная функция.

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

Сюрпризом для тебя может быть только то, что библиотека это не DSL, и не eDSL, иначе у нас во всех языках можно писать DSL :) и паскале каком-нибудь с фортраном.

Это часть любого orm - внутренний (в термах яп) язык запросов, преобразующий (иногда не очень прозрачно) структуры яп в структуры sql, возможно через промежуточные структуры яп.

Запросы пишутся стрингами. Прозрачности нет.

Да что вы говорите? o_0 Посмотри postmodern и sqla, тысячи их. В нормальной orm стрингами херячатся только специфичные к бд raw-запросы.

Контроль над структурой запроса

Что имеется ввиду?

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

Ясно, очердной бред про джаву (при чем тут она вообще?) и о контроле доступа ни слова.

Как выяснилось, ты представления не имеешь, что такое ФП, что такое функции в ФП, что такое макросы, не понимаешь смысл eDSL.

В принципе, это отличный показательный пост с твоей стороны - диагноз поставлен, высыхай :)

А с учетом того, что числа у нас не бесконечной размерности и апроксимируются на бесконечность за счет использования нескольких машинных слов - не может выплыть этот самый log n?

Выгребание из хэшмапа — O(log(n)) (в нормальных языках, разумеется, не знаю насчет кожуры).

В clojure доступ к значению хэшмапа - O(log32 n)

Спор двух пионэров-недоучек. А ну марш оба на пары.

Какой дядя строгий. Наверно, знает, о чем говорит. А, нет, не знает. Вот прув в последней таблице http://webcem01.cem.itesm.mx:8005/apps/s201213/tc2006/notes_collections , а вот причина http://blog.higher-order.net/2009/09/08/understanding-clojures-persistenthash...

Вообще, странная аргументация с цифрами по вакансии. Мне вот интересно, зачем тебе миллионы вакансий? Если тебе нужна именно одна вакансия с интересной высокооплачиваемой работой в нужном для тебя городе/стране?

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

Говорить о количестве вакансий имеет смысл только в одном случае, когда ты низкоквалифицированный специалист.

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

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

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

Я тебе открою секрет, только не плачь, практически любой макрос (если не любой) можно написать используя только фвп, это обсуждалось даже здесь на лоре уже неоднократно.

Вранье. Грязное вранье. Сделай свой if через функции на не-ленивом языке. Сделай эффективный компилятор eDSL на фвп.

Вообще-то любая хэш-таблица - то еще говно и простой алгоритмической сложностью она, строго говоря, не обладает из-за rehash. Ну или если вспомнить об Кормене можно сказать что у хэш таблицы О(N) и Ω(1).

Но вы продолжайте глагольствовать про амортизированное О(1), интересно наблюдать за битвой титанов.

Куда авторам этой поделки до такого профессианала как ты.

Куда авторам этой поделки до того же Hibernate?!?

Ох, блеать, о коллизиях нужно вспоминать рехеш там при записи возникает.

Исключение - трейдеры и финансы где математика вообще и ФП в частности востребованы, но и там Лисп не очень популярен а Хаскел я даже не слышал чтобы применяли.

Математика - это Фортран. Какого хера ты сюда говнофункциональщину-то приплетаешь?

1) что значит «мощные»? 2) пруф того, что лисп/хаскель мощнее мейнстримных языков.

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

Знаешь значение слова «венчурный»? Это означает, что добрый дядя в любой момент может отозвать своё бабло.

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

Ого! И как живётся благородному дону? Vim, Emacs, lynx, pine, finch, видео через libcaca? :)

На хера на сервере все это? Для гуйни у меня вообще виндовый десктоп.

функциональную декомпозицию

LMD. Это вообще из процедурного программирования, лошара!

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

Вы бы еще умолять начали о его просмотре.

Такие доклады давно перестали быть новинкой. Делаются они разработчиками с гребнем и шпорами и предназначены для развлечения аудитории и стимуляции их ЧСВ. Где еще пообсуждаешь архитектуропроблемы, будучи рядовым девелопером, где еще посмеешься над недотепистостью авторов языков программирования и своих руководителей? Кроме перечисленного никаких идей, особенно касающихся выбора инструментов, в таких докладах нет.

Хачкелята вообще зря хвастаются Barclays. На редкость говняная и жуликоватая конторка. Читать все по google:barclays bailout. Там не только блатота, там вообще ад и мрак царил много лет.

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

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

Жопа Хэнка, в чистом виде. Сектанты такие сектанты!

Когда один DSL(первый) упаковывают во второй, значит либо признают, что используют первый DSL как стрельбу из пушки по воробьям, либо вешают на пользователя второго DSL _все_ проблемы, ради решения которых создавался первый, при этом специалиста по проблемам первого DSL могут отморозить проблемы второго (а если их нет - то зачем было второй DSL создавать?).

Неверно. Клевета. Те же регулярные выражения - вполне себе DSL. И очень неплохо выглядят в качестве полноценного eDSL внутри языка (в JavaScript или в Perl).

LINQ тот же очень неплох в качестве eDSL.

Откуда такая цифра - 10? Шансы почти 100% при высокой квалификации.

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

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

Ок, в clojure PersistentHashMap != хэш-таблица. И понятно, почему. Давай зачетку.

Все понятно, там, откуда ты, полный бардак. У нас - это крупнейший инвест-банк. Лид архитекторы в основном лет около 30, многие выпускники мгу, мфти.

Ты путаешь project managment с requirements managment-ом, который у нас рсуществляют аналитики.

За презумпцию идиотизма у заказчика или аналитика, опять же, турнули бы тебя с испыталки, умника такого.

Сложные да. А если какую-то задачу мржно решить без осиляторства, выходит не такая уж она и сложная?