T>>Сходил к коллегам, осведомился про IDEA. Специально спросил насчёт intellisense. Получил ответ в смысле "интеллисенс у них нормальный, как у всех."
T>>Подозрительно.
V>Эти же ребята сделали Решарпер, так что могу осмысленно говорить лишь про него. Польза отнего не только и не столько в intellisense, сколько в тех хинтах, где он предлагает выполнить некое действие. Как пример — просто объявляю некое приватное поле, а потом alt+enter дважды, чтобы мне инициализацию этого поля встявили в конструктор, и потом сделали геттер на него. И таких действий у него, скажем прямо, немало. Так что, некая "говорливость" кода неплохо компенсируют подбные тулзы.

Читать-то его обратно всё равно приходится.

IDE pervasiveness мешает людям переходить на языки получше. Эта дурацкая привычка полагаться на IDE в выполнении "мелких задач, с которыми может справиться и компьютер", мешает понять, что этих задач может не быть в принципе.

Здравствуйте, thesz, Вы писали:

C>>Видимо, вопроса не поняли. Или IDEA пользоваться не умеют.
T>Когда я написал вот этот параграф выше, мне было некоторое время интересно, что же коллективный разум RSDN придумает.
T>Коллективный разум RSDN не подкачал. Он не пропустил это мимо своего внимания, это раз. И он показал свой обычный высокий уровень аргументации, это два.
Если хочешь, могу более подробно объяснить. Я считаю, что функциональность IDEA во многом делает Java языком более высокого уровня.

C>>>Видимо, вопроса не поняли. Или IDEA пользоваться не умеют.
T>>Когда я написал вот этот параграф выше, мне было некоторое время интересно, что же коллективный разум RSDN придумает.
T>>Коллективный разум RSDN не подкачал. Он не пропустил это мимо своего внимания, это раз. И он показал свой обычный высокий уровень аргументации, это два.
C>Если хочешь, могу более подробно объяснить. Я считаю, что функциональность IDEA во многом делает Java языком более высокого уровня.

Ну, валяй.

Выбери инвариант поинтересней и попробуй поддержать его по участку программы с помощью Java+IDEA. Или попробуй реализовать DSEL и опиши, что надо запомнить конечному пользователю, чтобы быть успешным пользователем этого DSEL.

Хотя меня больше беспокоит что ты огульно назвал моих коллег "не умеющими пользоваться IDEA". Мои коллеги умные, это я тебе точно говорю.

Здравствуйте, thesz, Вы писали:

T>Выбери инвариант поинтересней и попробуй поддержать его по участку программы с помощью Java+IDEA. Или попробуй реализовать DSEL и опиши, что надо запомнить конечному пользователю, чтобы быть успешным пользователем этого DSEL.
Я могу написать кастомную инспекцию, если прямо так захочется. Например, я уже тут приводил пример с тем, как Hibernate анализирует HQL-запросы в коде:


Ещё можно вспомнить разные удобные рефакторинги — выделение метода, выделение method object'а, упрощение выражений, анализ мёртвого кода и т.п.

T>Хотя меня больше беспокоит что ты огульно назвал моих коллег "не умеющими пользоваться IDEA". Мои коллеги умные, это я тебе точно говорю.
Так это никак не влияет на умение пользоваться IDEA....

T>>Выбери инвариант поинтересней и попробуй поддержать его по участку программы с помощью Java+IDEA. Или попробуй реализовать DSEL и опиши, что надо запомнить конечному пользователю, чтобы быть успешным пользователем этого DSEL.
C>Я могу написать кастомную инспекцию, если прямо так захочется. Например, я уже тут приводил пример с тем, как Hibernate анализирует HQL-запросы в коде:
C>[img]
C>http://files.rsdn.ru/37054/HQLBug.png
C>[/img]

Отличный пример. Он, как бы, говорит сам за себя. Совершенно не требует никаких объяснений.

По нему сразу видно, как можно быстро и удобно сделать DSEL, отдать пользователю и он всё поймёт с полуслова.

C>Ещё можно вспомнить разные удобные рефакторинги — выделение метода, выделение method object'а, упрощение выражений, анализ мёртвого кода и т.п.

Мне это всё совершенно непонятно.

T>>Хотя меня больше беспокоит что ты огульно назвал моих коллег "не умеющими пользоваться IDEA". Мои коллеги умные, это я тебе точно говорю.
C>Так это никак не влияет на умение пользоваться IDEA....

Это ещё хуже, если вдуматься.

Я не про коллег, если что.

Здравствуйте, thesz, Вы писали:

T>Отличный пример. Он, как бы, говорит сам за себя. Совершенно не требует никаких объяснений.
T>По нему сразу видно, как можно быстро и удобно сделать DSEL, отдать пользователю и он всё поймёт с полуслова.

Вот тут вот есть модуль для работы с RegExp'ами для IDEA: http://svn.jetbrains.org/idea/Trunk/bundled/RegExpSupport/

C>>Ещё можно вспомнить разные удобные рефакторинги — выделение метода, выделение method object'а, упрощение выражений, анализ мёртвого кода и т.п.
T>Мне это всё совершенно непонятно.
Ну непонятно, так непонятно.

C>>Так это никак не влияет на умение пользоваться IDEA....
T>Это ещё хуже, если вдуматься.
T>Я не про коллег, если что.
Да я не спорю.

Просто недавно заметил — если писать на Питоне, то кода где-то раза в два меньше, чем на Java получается. Но только пишется он где-то раза в два медленнее.

T>>Отличный пример. Он, как бы, говорит сам за себя. Совершенно не требует никаких объяснений.
T>>По нему сразу видно, как можно быстро и удобно сделать DSEL, отдать пользователю и он всё поймёт с полуслова.
C>
C>Вот тут вот есть модуль для работы с RegExp'ами для IDEA: http://svn.jetbrains.org/idea/Trunk/bundled/RegExpSupport/

Ты обмолвился, что можешь подробно объяснить

Автор: Cyberax
Дата: 20.03.09

.

Пока я наблюдаю либо картинки, либо ссылки. Объяснений ровно ноль целых, ноль десятых.

C>>>Так это никак не влияет на умение пользоваться IDEA....
T>>Это ещё хуже, если вдуматься.
T>>Я не про коллег, если что.
C>Да я не спорю.
C>Просто недавно заметил — если писать на Питоне, то кода где-то раза в два меньше, чем на Java получается. Но только пишется он где-то раза в два медленнее.

О, да.

Питон — наше всё. Вершина языков программирования! Он недавно сместил оттуда Лисп, как ты уже, наверняка, знаешь.

Как я понимаю, ни Камлом, ни Хаскелем ты не пользуешься?

thesz wrote:

> Отличный пример. Он, как бы, говорит сам за себя. Совершенно не требует
> никаких объяснений.
>
> По нему сразу видно, как можно быстро и удобно сделать DSEL, отдать
> пользователю и он всё поймёт с полуслова.
А какой инструмент будет для этого DSL забирать из СУБД структуру данных, использовать описание маппинга (hbm, ещё один DSL), чтобы на лету проверить правильность имён и подсказать имена/свойств, кусочки комментов из javadoc?

Как этот DSL поможет при рефакторинге? Банально переименовать название поля и в бинах, и в маппингах и т.п.?

В общем-то IDEA этот DSL и позволяет прикрутить в любое место кода, только это у неё называется не DSL, а injected language.

Здравствуйте, thesz, Вы писали:

C>>Вот тут вот есть модуль для работы с RegExp'ами для IDEA: http://svn.jetbrains.org/idea/Trunk/bundled/RegExpSupport/
T>Ты обмолвился, что можешь подробно объяснить

Автор: Cyberax
Дата: 20.03.09

.
T>Пока я наблюдаю либо картинки, либо ссылки. Объяснений ровно ноль целых, ноль десятых.
Если кратко рассказывать — то IDEA предоставляет инфраструктуру для работы с синтаксическим деревом и его интеграцию со средствами IDE. Скажем, удобную поддержку автокомплита и рефакторинга. Это не совсем просто для использования в простых случаях (где макросы типа Немерля рулили бы).

Зато позволяет inect'ить в код практически ЛЮБОЙ язык. Например, в модуле поддержки GWT это используется для разбора JavaScript-кода внутри комментариев в Java-коде — http://www.jetbrains.com/idea/features/gwt.html Причём в этом JS-коде полностью работает автокомплит, поддержка JQuery с подвязками автокомплита к CSS, рефакторинг и т.д.

Я не думаю, что это было бы возможно в каком-либо DSLе. Даже в Haskell'е.

C>>Да я не спорю.
C>>Просто недавно заметил — если писать на Питоне, то кода где-то раза в два меньше, чем на Java получается. Но только пишется он где-то раза в два медленнее.
T>О, да.
T>Питон — наше всё. Вершина языков программирования! Он недавно сместил оттуда Лисп, как ты уже, наверняка, знаешь.
Я не считаю Питон вершиной языков. Но код таки на нём короче получается.

T>Как я понимаю, ни Камлом, ни Хаскелем ты не пользуешься?
Я писал на OCaml'е, Erlang'е и Scala. OCaml не прижился, так как у меня задач под него не было. Erlang я в production'е использовал, но потом отказался из-за тормознутости. Haskell я изучал, понял как работают монады , потом забросил.

Сейчас следующим языком, который я буду использовать после Питона и Java станет, скорее всего, Scala. Слишком избалован я нормальными IDE.

Здравствуйте, thesz, Вы писали:

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

T>Про теорию типов ты, конечно, слышал мало.

T>Про классический пример, когда вывод типов ML показывает на зацикливание, ты тоже не видел.

Во-первых, с чего ты взял? Во-вторых, еще раз русским по белому: как это относится к реализации функциональных требований?

T>Система типов ЯП — это логика. Правильная система типов исправляет ошибки логики.
T>Более того, правильная система типов может регулировать нефункциональные требования наподобие сложности отдельных операций.

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

T>Прикольно?

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

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

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

И вот на фоне огромного вороха нефункциональных требований ФП "автоматом" решает слишком малую их часть, чтобы говорить об этом с такой загадочной миной. Хаскель, например, даже не в состоянии обеспечить уровней видимости, т.е. даже просто нормальной инкапсуляции. Получается, что решая одни нефункциональные требования задачи, он лишает нас решения по другим, существующим во многих популярных языках. Но это всё семечки, повторюсь: мощная платформа с тоннами надёжных библиотек пока что решает куда как больше тех самых нефункциональных требований, чем св-ва любого ЯП. И это стало очевидно в те самые последние лет 10, когда напичканные функциональностью продукты создаются смехотворными по размеру командами и работают при этом весьма надёжно. И тут банальная разгадка ситуации в том, что эта самая смехотворная команда своими ручками написала менее 10% функционала и общей архитектуры, а остальное взяла готовое из платформы и других библиотек под неё.

В принципе, это известные банальности, но ты их умудрился пропустить каким-то образом. Иначе трудно объяснить твоё полное непонимание относительно того, что спецификация языка и его реализация+инфраструктура — это две очень большие разницы. Вот обскачет по популярности твой долгосуществующий и неплохой Хаскель толькочторождённая поделка вроде Scala, может лучше понимать станешь. И ведь обскачет как стоячего, ибо "большие" программы на Scala будут куда как надёжнее и функциональнее, чем аналогичные на Хаскеле только лишь из-за работы языка поверх довольно мощной платформы.


T>Вот именно поэтому и не надо EDiv. Надо EInv (1/x) и ENeg (-x). Это из алгебры, там на этом собаку съели.

Блин, моя очередь спрашивать кому здесь сколько лет.
Если бы не торопился с ответом, а хотя бы в течении 10 сек пытался попроектировать предложенное дерево арифм. выражений на N-арных узлах, ты бы увидел, что операция "цепляется" к одному аргументу, а не к паре, и не предлагал бы очевидное.

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

T>Это ты уже о чём-то своём.

Хочешь сказать, что Хаскель оперирует целыми числами бесконечной разрядности? Результат деления двух целых какой тип имеет?

T>Опыт оптимизации говорит о том, что ты неправильно мыслишь.

Угу, поползновения увильнуть от прямого вопроса. Я привёл простой пример, который не оптимизирует твой подход, в то время как как компиляторы Java, C#, C++ прекрасно его оптимизируют. Может, ты чего-то не знаешь и пытаешься делать умное лицо?

T>Но это твои личные проблемы.

Я так и понял, проехали. Если ФП не в состоянии "автоматом" исправлять ошибки логики, то это проблемы программиста, а не ЯП... ЧТД.

T>(задумался над очевидным фактом незнания тобой алгебраических типов.)

Мде, офигенные у кое-кого манеры... Не пора ли кое-кому в сад? Говоря твоим же языком, еще много постов назад задумался над очевидным фактом незнания тобой теории групп и понятия размеченных объеденений, когда ты упирался насчёт алгебраических св-в семейств явным образом инстанциированных шаблонных типов в С++ или игнорировал замечание относительно реализаций dispatched unions.

Т.к. ты, очевидно, не понимаешь места, которое занимает реализация алгебраических типов Хаскеля в теории групп, то я тебе могу подсказать: алгебраические типы в реализации Хаскеля — суть размеченные объединения, селектор которых доступен в run-time, и модель селектора при этом выполнена в виде типа. Сделано это, очевидно, из-за принятой в Хаскеле "шаблонности" кода, что позволяет в минимальном синтаксисе выступать селектору в виде конструктора типа в процессе его параметризации.

В общем, я же написал, что Хаскель не знаю, соотв. могу не знать подробности синтаксиса алгебраических типов в нём. Спросил конкретно про "Just", трудно было сказать, что это имя конструктора (по совместительству селектора) типа Maybe? Неужели не слышал про языки, в которых для алгебраических типов указывают конечные типы их вариантов? Или где селекторы выполнены в виде интегральных типов?


V>>Maybe понятен, непонятен Just. Почему не так:
V>>

V>>data Maybe a = Nothing | a
V>>

T>Потому, что нельзя. Как мы отличим a, который Maybe a, от a, который, допустим, List a?

Не поэтому, а потому что в Хаскеле алгебраическую группу составляют взаимно уникальные типы. Собственно, т.к. он ничего кроме матчинга не умеет, то неудивительно, эта уникальность необходима для корректной работы. По-сути, значения алгебраических типов "заворачиваются в обёртку" дважды, сначала в тип селектора, а потом как все алгебраические типы. Вот это оборачивание в уникальный селектор и гарантирует необходимую логике паттерн-матчинга уникальность. Теперь тебе понятно, почему так нельзя?

Мне пришлось потратить вечер на изучение Хаскеля, чтобы объяснять тебе то, что ты должен был знать еще лет 10 назад.

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

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

Тем не менее, обещанное решение.
1. Раскроем "_" в первоначальном примере и Just/Nothing во всех местах:

(newAcc,output) = case (oldAcc,input,loopback) of
            (Just acc, Just inp, Just lb) -> (Just acc, Just (inp, lb))
            (Just acc, Just inp, Nothing) -> (Nothing, Just (acc, inp))
            (Just acc, Nothing, Just lb) -> (Nothing, Just (acc, lb))
            (Just acc, Nothing, Nothing) -> (Just acc, Nothing)
            (Nothing acc, Just inp, Just lb) -> (Nothing, Just (inp, lb))
            (Nothing acc, Just inp, Nothing) -> (Just inp, Nothing)
            (Nothing acc, Nothing inp, Just lb) -> (Just lb, Nothing)
            (Nothing acc, Nothing inp, Nothing lb) -> (Nothing, Nothing)

Получился обычный двоичный дешифратор. И сдаётся мне, что линейный, да еще избыточный в первоначальном варианте матчинг не очень хорош, в случае двоичного дешифратора.
Для нашей задачи (3 бита дешифрации) достаточно сделать 2 сравнения для любой ветки алгоритма (C#):

    using Pair = KeyValuePair<int, int>;

    struct  Ballin {
        public int? acc; 
        public Pair? pair;

        Ballin(int? a, Pair? p) { acc = a; pair = p; }

        public static Ballin Produce(int? acc, int? inp, int? lb) {
            if (!inp.HasValue) return TryPair(acc, lb);
            if (!lb.HasValue) return TryPair(acc, inp);
            return new Ballin(acc, new Pair(inp.Value, lb.Value));
        }

        private static Ballin TryPair(int? arg1, int? arg2) {
            if (!arg1.HasValue) return new Ballin(arg2, null);
            if (!arg2.HasValue) return new Ballin(arg1, null);
            return new Ballin(null, new Pair(arg1.Value, arg2.Value));
        }
    }

А сколько сравнений сделает Хаскель для последнего варианта в первоначальном коде? 12? Так может, это не столько Хаскель тормозит, сколько программисты на нём? Мой вариант вполне переводим на Хаскель с сохранением 2-х сравнений для каждой ветки, и код сожмется практически до первоначального кол-ва строк, ввиду особенностей синтаксиса Хаскеля. И не надо опять начинать про "преждевременную оптимизацию", ибо мой алгоритм не просто быстрее, он несколько нагляднее, т.к. объясняет суть алгоритма: паруем первое попавшееся, остаток в аккумулятор.


T>>>Как называется эта "наука о качестве"?
V>>Тебя смущает слово "наука"?

T>Да. У науки, обычно, бывает название.

Тут 2 варианта, или кто-то не умеет гуглить, или ты признаёшь наличие только фундаментальных наук, а прикладные таковыми не считаешь. Что делает науку — наукой? Наличие полноты в методологии, более ничего. Сама эта прикладная наука о качестве собственно так и называется, альтернативное название — наука об управлении качеством. К сожалению, большинство замечательных трудов по этой теме были изданы еще очень давно, до признания её наукой, поэтому гуглить не очень удобно по этой фразе, но ведь тебе всё-равно не интересно, правда?


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

T>Признаюсь честно, всеё разницы я вижу только в приставке "не".

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

T>>>Стиль кодирования? Нет?
V>>Нет.

T>Почему?

Потому что задачи разные бывают. Вот простая задача: кеш неких связанных данных, обслуживающий сетевые запросы, приходящие из разных потоков, требующий транзакционности выборок связанных данных. Уверен, что на Хаскеле это будут танцы с бубнами и куча лишних строк кода, по сравнению с mainstream-языками. Более того, на этой задаче ты начёнешь задевать крылом те конструкции, которые не задевал раньше, независимо от стиля кодирования.

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

Если ничего не изменится, он не станет успешным никогда. 10 с лишним лет Хаскель топчется на месте и перемен не предвидится — слишком уж консервативна среда вокруг него. Пока читал про систему типов Хиндли-Милнера наткнулся на куда более интересные вещи, например на Fortress, Boo. Эта система может запросто лечь на "не чисто" функциональные языки, и даже на презираемое некоторыми ООП. ИМХО, реализовать систему Хиндли-Милнера только над алгебраическими типами оказалось проще-всего (ибо всего одна разновидность полиморфизма, т.е. упрощается вывод типов), но сама эта система не требует никакой алгебраичности, она ортогональна ей. Не пошатнулись там еще твои "устои"?

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

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

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

Здравствуйте, Belsen, Вы писали:

B>Или так?
B>

B>balinF'' :: Maybe i -> Maybe i -> Maybe i -> (Maybe i, Maybe (i, i))
B>balinF'' a b c = case (mapMaybe id [a,b,c]) of
B>    [x,y,z] -> (Just x, Just (y, z))
B>    [x,y] -> (Nothing, Just (x, y))
B>    [x] -> (Just x, Nothing)
B>    [] -> (Nothing, Nothing)
B>

Коллега, ты абсолютно прав, сначала я хотел представить именно эту версию алгоритма (на C#), но т.к. речь шла об эмуляторе железки, то остановился на дешифраторе.

Здравствуйте, thesz, Вы писали:


T>IDE pervasiveness мешает людям переходить на языки получше. Эта дурацкая привычка полагаться на IDE в выполнении "мелких задач, с которыми может справиться и компьютер", мешает понять, что этих задач может не быть в принципе.

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

Здравствуйте, ., Вы писали:

.>А какой инструмент будет для этого DSL забирать из СУБД структуру данных, использовать описание маппинга (hbm, ещё один DSL), чтобы на лету проверить правильность имён и подсказать имена/свойств, кусочки комментов из javadoc?

Есть мнение, что это разные задачи и для них нужны разные инструменты.

Некоторые пользуют thunderbird, а некоторые fetchmail + procmail + mutt + pgp + mailcap + msmtp.

.>Как этот DSL поможет при рефакторинге? Банально переименовать название поля и в бинах, и в маппингах и т.п.?

Для этого нужен редактор с поддержкой рефакторинга. vim + HaRe, например.

Что касается "и в бинах, и в маппингах". Есть мнение, что надо одно из другого генерировать, а не синхронизировать.

.>В общем-то IDEA этот DSL и позволяет прикрутить в любое место кода, только это у неё называется не DSL, а injected language.

Мне кажется, что injected language написать сложнее, чем eDSL.

Здравствуйте, Cyberax, Вы писали:
Здравствуйте, thesz, Вы писали:

Мужики, вы о разном говорите. Да, Haskell тоже не помешают некоторые инструменты. Да, некоторые из финтифлюшек IDEA — костыли, следствие низкого уровня Java.

C>Зато позволяет inect'ить в код практически ЛЮБОЙ язык. Например, в модуле поддержки GWT это используется для разбора JavaScript-кода внутри комментариев в Java-коде — http://www.jetbrains.com/idea/features/gwt.html Причём в этом JS-коде полностью работает автокомплит, поддержка JQuery с подвязками автокомплита к CSS, рефакторинг и т.д.
C>Я не думаю, что это было бы возможно в каком-либо DSLе. Даже в Haskell'е.

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

C>Сейчас следующим языком, который я буду использовать после Питона и Java станет, скорее всего, Scala. Слишком избалован я нормальными IDE.

Я постепенно прихожу к выводу, что Scala возникла тоже из-за низкого уровня Java А это не та причина, по которой надо создавать новый язык, IMHO. А то получится Scala — монстр типа С++. Язык с набором несвязанных фич вместо языка с фичами, уложенными в некую систему. Хотя, вполне допускаю, что я пока просто эту систему не вижу.

T>>IDE pervasiveness мешает людям переходить на языки получше. Эта дурацкая привычка полагаться на IDE в выполнении "мелких задач, с которыми может справиться и компьютер", мешает понять, что этих задач может не быть в принципе.
V>Как это не может быть в принципе? Подобный "Решарпер" для Хаскеля помогал бы
V>интиллисенсом для длинных идентификаторов,

Плохая практика. Теорему Шеннона о длине кода никто не отменял.

V>подсвечивал бы ошибки компиляции прямо в процессе редактирования кода,

Отвлекая от написания кода.

V>вставлял пропущенные варианты для паттерн-матчинга,

С большой вероятностью наиболее идиотским способом.

V>отмечал бы неиспользуемые переменные в замыканиях,

Несмотря на то, что это разрешённая и часто используемая практика.

V>подсказывал бы, когда монада не имела побочного результата и можно было бы преобразовать просто в ф-ию (бывают иногда атавизмы в процессе работы над кодом), и т.д. и т.п.

Из всех монад только ST и IO имеют побочные эффекты. Прикинь! Только 2 из всего их множества!

Ты бы пописал на Хаскеле, вместо фантазирования на эту тему.

Здравствуйте, vdimas, Вы писали:

V>Получился обычный двоичный дешифратор. И сдаётся мне, что линейный, да еще избыточный в первоначальном варианте матчинг не очень хорош, в случае двоичного дешифратора.
V>Для нашей задачи (3 бита дешифрации) достаточно сделать 2 сравнения для любой ветки алгоритма (C#):

V>А сколько сравнений сделает Хаскель для последнего варианта в первоначальном коде? 12? Так может, это не столько Хаскель тормозит, сколько программисты на нём?

Спасибо! Давно так не смеялся: тормозные програмисты на Haskell — херово оптимизируют матчинг.

Здравствуйте, z00n, Вы писали:

Z>Спасибо! Давно так не смеялся: тормозные програмисты на Haskell — херово оптимизируют матчинг.

Сорри, если кого-то задел в "пылу боя", но ты бы сам взглянул на генерируемый бинарный код приведённого примера, для начала. Просто уже давно есть устойчивая неприязнь к продавцам серебрянных пуль, ибо мы всегда чем-то за что-то расплачиваемся.

Здравствуйте, lomeo, Вы писали:


L>Я постепенно прихожу к выводу, что Scala возникла тоже из-за низкого уровня Java А это не та причина, по которой надо создавать новый язык, IMHO. А то получится Scala — монстр типа С++. Язык с набором несвязанных фич вместо языка с фичами, уложенными в некую систему. Хотя, вполне допускаю, что я пока просто эту систему не вижу.

Да, как-то пока сложно разглядеть идею Scala и причину его разработки как таковую, кроме причины отсутствия языковых альтернатив для Java — платформы.

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

С чего я взял что? Что не видел?

Ну, возможно, видел. Но ведешь себя так, как будто не видел. В голове у тебя не отложилось, как это можно использовать.

V>Во-вторых, еще раз русским по белому: как это относится к реализации функциональных требований?

Ты великолепен!

T>>Система типов ЯП — это логика. Правильная система типов исправляет ошибки логики.
T>>Более того, правильная система типов может регулировать нефункциональные требования наподобие сложности отдельных операций.
V>Очень редкое нефункциональное требование, из области забавного. (да, ты приводил уже ссылку)
V>Абсолютно не применимо, когда логика алгоритма зависит от входных данных — а это большинство сценариев в современных бизнес-приложениях.

Круто!

Совсем-совсем не применимо? Даже пытаться не стоит?

T>>Прикольно?
V>Что именно прикольно? Из твоих слов может показаться, что система типов даётся сверху, в то время как её разрабатывают те же люди, и точно так же допускают в ней косяки, навроде твоего esim.

Type theory should eat itself. Она может быть метациркулярна в более сильном, чем стандартные ЯП, смысле.

Все косяки в esimp, что ты увидел, существовали только в твоих глазах, дорогой товарищ.

V>Например, есть некая прикладная область, в которой я считаю себя довольно продвинутым. Естественно, регулярно просматриваю массу материала и исходников на интересующие темы, и вот в этой области особенно заметно, когда разработчики прекрасно владеют и языком и подходами написания эффективного кода и кучей всего (т.е. могут считаться отличными спецами по меркам участников этого форума), но пишут полную туфту при этом. К чему это я? Просто никакое владение ФП или ООП анализом не поможет в реализации качественного подукта, если разработчики не владеют предметной областью (кругами разводимых рук (С)).

Это очень важный момент. Точнее, это очень важное непонимание — то, что ты продемонстрировал параграфом выше.

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

Разница между ЯП в этом случае будет составлять в скорости надёжного распространения новых знаний по системе.

В случае ассемблера это одна скорость. В случае современного ФЯ — другая, на порядки выше.

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

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

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

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

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

V>И вот на фоне огромного вороха нефункциональных требований ФП "автоматом" решает слишком малую их часть, чтобы говорить об этом с такой загадочной миной. Хаскель, например, даже не в состоянии обеспечить уровней видимости, т.е. даже просто нормальной инкапсуляции.

О! "Плоское пространство имён".

import qualified Data.Map
import qualified Data.Map as Map
-- или import qualified Data.IntMap as Map

Ты, уж, ознакомься с критикуемым-то. Вся информация в интернете есть.

А то мне скоро наскучит мириться с твоим тиражированием идиотизма.

V>Получается, что решая одни нефункциональные требования задачи, он лишает нас решения по другим, существующим во многих популярных языках. Но это всё семечки, повторюсь: мощная платформа с тоннами надёжных библиотек пока что решает куда как больше тех самых нефункциональных требований, чем св-ва любого ЯП.

Ты уж извини, но библиотеки не могут быть написаны на все случаи жизни.

Например, Java и .Net до сих пор не имеют библиотеки моделирования систем на дискретных событиях.

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

V>И это стало очевидно в те самые последние лет 10, когда напичканные функциональностью продукты создаются смехотворными по размеру командами и работают при этом весьма надёжно. И тут банальная разгадка ситуации в том, что эта самая смехотворная команда своими ручками написала менее 10% функционала и общей архитектуры, а остальное взяла готовое из платформы и других библиотек под неё.

Приведи пример.

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

V>В принципе, это известные банальности, но ты их умудрился пропустить каким-то образом. Иначе трудно объяснить твоё полное непонимание относительно того, что спецификация языка и его реализация+инфраструктура — это две очень большие разницы. Вот обскачет по популярности твой долгосуществующий и неплохой Хаскель толькочторождённая поделка вроде Scala, может лучше понимать станешь. И ведь обскачет как стоячего, ибо "большие" программы на Scala будут куда как надёжнее и функциональнее, чем аналогичные на Хаскеле только лишь из-за работы языка поверх довольно мощной платформы.

Мне будет совершенно не жалко.

Потому, что в случае популярности Хаскеля им начнёшь пользоваться ты. А меня это беспокоит.

T>>Вот именно поэтому и не надо EDiv. Надо EInv (1/x) и ENeg (-x). Это из алгебры, там на этом собаку съели.
V>Блин, моя очередь спрашивать кому здесь сколько лет.
V>Если бы не торопился с ответом, а хотя бы в течении 10 сек пытался попроектировать предложенное дерево арифм. выражений на N-арных узлах, ты бы увидел, что операция "цепляется" к одному аргументу, а не к паре, и не предлагал бы очевидное.

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

Поэтому я вернулся к предложенному выше.

V>>>Потому что числовые типы могут быть различными для аргументов, и от порядка вычислений может зависеть результат (мы же пока конечным кол-вом бит в типах располагаем). В общем, скобки явно определяют последовательность операций и их игнорировать нельзя.
T>>Это ты уже о чём-то своём.
V>Хочешь сказать, что Хаскель оперирует целыми числами бесконечной разрядности? Результат деления двух целых какой тип имеет?

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

Например, только что ты предположил, что 10*A*12 нельзя упростить в 120*A. Это верно в случае, когда 10 и 12 с A могут иметь разные типы, например 10 :: Double, а 12, A :: Float.

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

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

T>>Опыт оптимизации говорит о том, что ты неправильно мыслишь.
V>Угу, поползновения увильнуть от прямого вопроса. Я привёл простой пример, который не оптимизирует твой подход, в то время как как компиляторы Java, C#, C++ прекрасно его оптимизируют. Может, ты чего-то не знаешь и пытаешься делать умное лицо?

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

T>>Но это твои личные проблемы.
V>Я так и понял, проехали. Если ФП не в состоянии "автоматом" исправлять ошибки логики, то это проблемы программиста, а не ЯП... ЧТД.

Оно может указывать на ошибки логики.

T>>(задумался над очевидным фактом незнания тобой алгебраических типов.)
V>Мде, офигенные у кое-кого манеры... Не пора ли кое-кому в сад? Говоря твоим же языком, еще много постов назад задумался над очевидным фактом незнания тобой теории групп и понятия размеченных объеденений, когда ты упирался насчёт алгебраических св-в семейств явным образом инстанциированных шаблонных типов в С++ или игнорировал замечание относительно реализаций dispatched unions.

Ты давай код приводи, да высказывайся по чётче, экскурсовод по саду ты наш.

V>Т.к. ты, очевидно, не понимаешь места, которое занимает реализация алгебраических типов Хаскеля в теории групп, то я тебе могу подсказать: алгебраические типы в реализации Хаскеля — суть размеченные объединения, селектор которых доступен в run-time, и модель селектора при этом выполнена в виде типа. Сделано это, очевидно, из-за принятой в Хаскеле "шаблонности" кода, что позволяет в минимальном синтаксисе выступать селектору в виде конструктора типа в процессе его параметризации.

Спасибо. Буду знать. А то не знал, что не знаю, теперь буду знать. Не думаю, что буду знать, что знаю, правда, но буду знать о своём незнании.

Самому-то не видно, что не знаешь.

Хоть читай Monin, Formal methods, хоть не читай. Всё равно, пока на RSDN участник коллективного разума не покажет, что ты этого не знаешь, так и не узнаешь о том, что ты этого не знаешь.

V>В общем, я же написал, что Хаскель не знаю, соотв. могу не знать подробности синтаксиса алгебраических типов в нём. Спросил конкретно про "Just", трудно было сказать, что это имя конструктора (по совместительству селектора) типа Maybe? Неужели не слышал про языки, в которых для алгебраических типов указывают конечные типы их вариантов? Или где селекторы выполнены в виде интегральных типов?

Ответ на предпоследний вопрос: да, знаю. Хаскель называется.

data Maybe a where
    Nothing :: Maybe a
    Just :: a -> Maybe a

Maybe в GADT стиле.

На последний вопрос — нет, потому, что это, скорее всего, плохие языки. Если это, конечно, не языки с зависимыми типами данных. Но и там селекторы — отдельные константы, а не целые числа и не перечисления.

V>>>Maybe понятен, непонятен Just. Почему не так:
V>>>

V>>>data Maybe a = Nothing | a
V>>>

T>>Потому, что нельзя. Как мы отличим a, который Maybe a, от a, который, допустим, List a?
V>Не поэтому, а потому что в Хаскеле алгебраическую группу составляют взаимно уникальные типы. Собственно, т.к. он ничего кроме матчинга не умеет, то неудивительно, эта уникальность необходима для корректной работы. По-сути, значения алгебраических типов "заворачиваются в обёртку" дважды, сначала в тип селектора, а потом как все алгебраические типы. Вот это оборачивание в уникальный селектор и гарантирует необходимую логике паттерн-матчинга уникальность. Теперь тебе понятно, почему так нельзя?

Да, большое спасибо. Еще про одно своё незнание узнал.

"О, сколько нам открытий чудных!.."

V>Мне пришлось потратить вечер на изучение Хаскеля, чтобы объяснять тебе то, что ты должен был знать еще лет 10 назад.

Спасибо. Спасибо тебе, дорогой товарищ!

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

Спасибо!

V>И вообще, вот эта постоянная манера выдавать банальности за откровения как бы не очень... Если ты не понял сути вопроса собеседника, то это не всегда от того, что он чего-то не знает, как показывает практика форумного общения — зачастую ровно наоборот. Одним словом, в форумах стоит быть или лояльнее к собеседнику, или не тратить время на подобное общение, результатом которого в конце концов становится сплошной неконструктив.

Спасибо ещё раз.

Теперь я буду уверен, что отвечать "я не понял твоего вопроса" много лучше, чем отвечать, так и не поняв вопроса оппонента.

V>Тем не менее, обещанное решение.
V>1. Раскроем "_" в первоначальном примере и Just/Nothing во всех местах:
V>

V>(newAcc,output) = case (oldAcc,input,loopback) of
V>            (Just acc, Just inp, Just lb) -> (Just acc, Just (inp, lb))
V>            (Just acc, Just inp, Nothing) -> (Nothing, Just (acc, inp))
V>            (Just acc, Nothing, Just lb) -> (Nothing, Just (acc, lb))
V>            (Just acc, Nothing, Nothing) -> (Just acc, Nothing)
V>            (Nothing acc, Just inp, Just lb) -> (Nothing, Just (inp, lb))
V>            (Nothing acc, Just inp, Nothing) -> (Just inp, Nothing)
V>            (Nothing acc, Nothing inp, Just lb) -> (Just lb, Nothing)
V>            (Nothing acc, Nothing inp, Nothing lb) -> (Nothing, Nothing)
V>

Слушай, вот эта картинка выдаёт уровень твоего внимания как нельзя лучше.

V>Получился обычный двоичный дешифратор. И сдаётся мне, что линейный, да еще избыточный в первоначальном варианте матчинг не очень хорош, в случае двоичного дешифратора.
V>Для нашей задачи (3 бита дешифрации) достаточно сделать 2 сравнения для любой ветки алгоритма (C#):
V>

V>    using Pair = KeyValuePair<int, int>;

V>    struct  Ballin {
V>        public int? acc; 
V>        public Pair? pair;

V>        Ballin(int? a, Pair? p) { acc = a; pair = p; }

V>        public static Ballin Produce(int? acc, int? inp, int? lb) {
V>            if (!inp.HasValue) return TryPair(acc, lb);
V>            if (!lb.HasValue) return TryPair(acc, inp);
V>            return new Ballin(acc, new Pair(inp.Value, lb.Value));
V>        }

V>        private static Ballin TryPair(int? arg1, int? arg2) {
V>            if (!arg1.HasValue) return new Ballin(arg2, null);
V>            if (!arg2.HasValue) return new Ballin(arg1, null);
V>            return new Ballin(null, new Pair(arg1.Value, arg2.Value));
V>        }
V>    }
V>

V>А сколько сравнений сделает Хаскель для последнего варианта в первоначальном коде? 12?

Почему ты всегда предполагаешь самый плохой вариант и думаешь, что твой ответ будет верным? Это не самое выгодное поведение.

Сравнений будет три для любого варианта. Табличное сравнение с образцом разворачивается в дерево сравнений.

V>Так может, это не столько Хаскель тормозит, сколько программисты на нём? Мой вариант вполне переводим на Хаскель с сохранением 2-х сравнений для каждой ветки, и код сожмется практически до первоначального кол-ва строк, ввиду особенностей синтаксиса Хаскеля. И не надо опять начинать про "преждевременную оптимизацию", ибо мой алгоритм не просто быстрее, он несколько нагляднее, т.к. объясняет суть алгоритма: паруем первое попавшееся, остаток в аккумулятор.

Да её и не надо, этой оптимизации. Она компилятором выполняется.

T>>>>Как называется эта "наука о качестве"?
V>>>Тебя смущает слово "наука"?
T>>Да. У науки, обычно, бывает название.
V>Тут 2 варианта, или кто-то не умеет гуглить, или ты признаёшь наличие только фундаментальных наук, а прикладные таковыми не считаешь. Что делает науку — наукой? Наличие полноты в методологии, более ничего. Сама эта прикладная наука о качестве собственно так и называется, альтернативное название — наука об управлении качеством. К сожалению, большинство замечательных трудов по этой теме были изданы еще очень давно, до признания её наукой, поэтому гуглить не очень удобно по этой фразе, но ведь тебе всё-равно не интересно, правда?

Про неё, наверняка, есть статья в Википедии или где-то ещё?

T>>>>Стиль кодирования? Нет?
V>>>Нет.
T>>Почему?
V>Потому что задачи разные бывают. Вот простая задача: кеш неких связанных данных, обслуживающий сетевые запросы, приходящие из разных потоков, требующий транзакционности выборок связанных данных. Уверен, что на Хаскеле это будут танцы с бубнами и куча лишних строк кода, по сравнению с mainstream-языками.

MVar

хгкд=http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent-Chan.html]Chan[/url]

Software Transactional Memory.

Последнее только-только добирается до мейнстрима.

Ещё раз: предполагать самый плохо вариант ответа — не самая лучшая стратегия. Да и тактика тоже так себе.

V>Более того, на этой задаче ты начёнешь задевать крылом те конструкции, которые не задевал раньше, независимо от стиля кодирования.

Это всё слова. Это надо доказывать. Во-первых, тебе надо показать, как эта задача обязательно выведет за стиль кодирования решения на обычных языках. Во-вторых, тебе надо показать, как эта задача выведет за стиль кодирования решение на Хаскеле.

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

Давай, потрать ещё вечер.

T>>Ты уж извини, но когда Хаскель станет успешным, им станешь пользоваться ты. Меня это беспокоит. Ты очень странный.
V>Если ничего не изменится, он не станет успешным никогда.

Ура! Спасибо тебе, дорогой товарищ!

V>10 с лишним лет Хаскель топчется на месте и перемен не предвидится — слишком уж консервативна среда вокруг него. Пока читал про систему типов Хиндли-Милнера наткнулся на куда более интересные вещи, например на Fortress, Boo. Эта система может запросто лечь на "не чисто" функциональные языки, и даже на презираемое некоторыми ООП. ИМХО, реализовать систему Хиндли-Милнера только над алгебраическими типами оказалось проще-всего (ибо всего одна разновидность полиморфизма, т.е. упрощается вывод типов), но сама эта система не требует никакой алгебраичности, она ортогональна ей. Не пошатнулись там еще твои "устои"?

Я не понял, о чём ты говоришь.

V>Понимаешь, есть задачи, которые принципиально выражаются в терминах состояний и сообщений, в этих задачах есть такие понятия как атомарность и синхронизация. А, беда многих функциональщиков в том, что они приписывают типобезопасность и декларативность исключительно функциональным языкам, а это разновидность зашоренности. ФП — это просто еще одна вычислительная модель, которая хороша только там, где предметная область близка к её вычислительной модели, иначе получаются уродства наподобии монады State.

Почему State monad уродство? Твоё личное предпочтение?

Типобезопасность в ленивых ФЯ достигается проще всех остальных. Все остальные системы сложнее. BitC, например — авторы сами признают, что задача у них очень мощная и почти неподъёмная.

Всё, что может Фортресс, выражается в зависимых типах.

Собственно, почему я на них так и сфокусирован: разобравшись с ЗТД, я получаю забесплатно и Фортресс, и Boo и практически всё, что смогу захотеть.

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

Увы, практика доказывает обратное.

Алгоритм W (Хиндли-Милнера) сперва доказали для чистого подмножества ML, а потом отдельно доказывали для ML со ссылками.

Здравствуйте, thesz, Вы писали:

V>>Получается, что решая одни нефункциональные требования задачи, он лишает нас решения по другим, существующим во многих популярных языках. Но это всё семечки, повторюсь: мощная платформа с тоннами надёжных библиотек пока что решает куда как больше тех самых нефункциональных требований, чем св-ва любого ЯП.

T>Ты уж извини, но библиотеки не могут быть написаны на все случаи жизни.

T>Например, Java и .Net до сих пор не имеют библиотеки моделирования систем на дискретных событиях.

T>Мой опыт говорит, что количество написанного кода всегда в разы превышает количество кода с использованием библиотек. Да только на открытие файла требуется действий больше, чем просто fopen.

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

Вот в моем проекте, которым я занимаюсь последние несколько лет, порядка 100K строк прикладного кода. Самые большие из задействованных в нем библиотек -- ACE (330K строк), SObjectizer (50K), ObjESSty (60K). Не считая того кода, который спрятан в ODBC, реляционных БД, http-серверах.