dmz>>Да и мне как-то почти по барабану, нажать shift-space, или написать getUnits.
C>Нет. Если там есть getSomeSpecialUnits() — то можно и имя забыть, и писать дольше будет.

На случай подобной забывчивости всегда есть тупая допечатка

dmz>>А генерация кода — приводит к "много подобного кода в разных местах"
C>Ну приводит. Что дальше? Я не говорил, что макросы — совсем не нужны.

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

Я это к тому, что как ни крути, джава — низкоуровневый язык. И при помощи IDE это никак не исправить.

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

dmz>>>Да и мне как-то почти по барабану, нажать shift-space, или написать getUnits.
C>>Нет. Если там есть getSomeSpecialUnits() — то можно и имя забыть, и писать дольше будет.
dmz>На случай подобной забывчивости всегда есть тупая допечатка
То есть? В том же Питоне IDE не справляются даже с банальнейшими случаями. Так как вывода типов-то нет.

dmz>>>А генерация кода — приводит к "много подобного кода в разных местах"
C>>Ну приводит. Что дальше? Я не говорил, что макросы — совсем не нужны.
dmz>Ну так в джаве их нет, макросов. А наличие мега-допечатки провоцирует писать тонны кода, потому что это просто и быстро, вместо того, что бы попытаться его обобщить.
А я утверждаю, что Java — это идеал?

Я просто говорю, что DSELи — это может быть далеко не единственный способ реализации DSLей. И возможно даже, что не самый удачный.

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

C>>>Причём нужно создать почти идеально совместимый по синтаксису DSL, так как в браузеры у нас пока Haskell не встроен. В общем, задача очень быстро станет наааааамного сложнее написания модуля для IDEA.
L>>Почему? Не понял, если честно.
C>Не, ну тебе нужно будет повторить весь HTML, CSS и JS в виде DSL.

HTML, CSS и, тем более JS не очень хороший пример, ну да бог с ним.

В общем весь повторять не надо — только то, что нужно. Мы можем определить явный комбинатор html, который будет принимать применения комбинаторов head и body, а можем определить генератор комбинаторов и писать tag "ul", например.

C>Смысл в том, что для Injected-языка я могу использовать ЛЮБОЙ парсер, в том числе и интеллектуальный, пропускающий плохие куски, могу использовать ЛЮБОЕ промежуточное представление и т.д.

А для eDSL вообще парсеры не нужны.

C>Ну и вопросы с рефакторингом остаются.

Или рефаторинги хост языка. Или дописываем _отдельно_.

L>>Я не понял почему (ведь для хоста-языка у нас уже всё есть) и переспросил.
C>Не верно. Для хост-языка может быть есть парсеры, но это O-малое для качественного DSL.

Не, я не про парсеры, а про среду. Ведь мы когда создаём модуль для injected language, наверное, не только язык описываем, но и к среде его привязываем? В случае с eDSL у нас уже есть готовая среда. Правда, в случае с injected language сообщения будут более осмысленными, а рефакторинги более специфическими, но и писать, наверное, больше. С другой стороны, писать можно на родном языке, а не на хост. Тут тоже есть и плюсы и минусы.

В общем, мне кажется, у меня в голове уже всё сложилось Injected languages -- это опять такой подход "всё в одном", у него есть свои плюсы, конечно. Но тут дело в предпочтениях, наверное. Мне, например, комбайны мало нравятся.

Спасибо.

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

dmz>>>>А генерация кода — приводит к "много подобного кода в разных местах"
C>>>Ну приводит. Что дальше? Я не говорил, что макросы — совсем не нужны.
dmz>>Ну так в джаве их нет, макросов. А наличие мега-допечатки провоцирует писать тонны кода, потому что это просто и быстро, вместо того, что бы попытаться его обобщить.
C>А я утверждаю, что Java — это идеал?
C>Я просто говорю, что DSELи — это может быть далеко не единственный способ реализации DSLей. И возможно даже, что не самый удачный.

Макросы — это лакмусовая бумажка, которая показывает места, где язык невыразителен. В Яве нет даже этой бумажки :) Поэтому там так часто приходится пользоваться генераторами. Или IDEA — кому как. В питоне — лямбды и функции высшего порядка поднимают уровень языка в разы, а декораторы добивают там, где не справляются ФВП.

Насчёт Явы и IDEA. Я сидел на IDEA с версии 2.5. Восхищался (и до сих пор восхищен) её редактором. Однако, я заметил, что Java и без того болтливый язык, а IDEA провоцирует меня на

1) написание большого количества boilerplate
2) лёгкое и частое использование рефакторингов, что снизило мою дисциплинированность
3) доверие инспекциям, на которые я стал обращать внимание и элементарно отвлекаться

Я понимаю, что проблема во мне, и что я просто не умею пользоваться IDEA. Но, вот такой я человек — считаю, что IDEA — замечательная среда, может лучшая для Java, и одновременно, что она мне больше мешает, чем помогает.

Поэтому я слез с IDEA и начал больше

1) заниматься кодогенерацией, МП, DSL
2) думать, прежде чем писать :)
3) обращать внимание на важные вещи, а не на финтифлюшки

T>>Вот в игростроении, например. Делал всё, как все остальные: DirectX прямо в коде, без всякой обвязки. Так у меня на две тысячи строк кода взрывов было всего порядка пяти или шести вызовов D3D — DrawIndexPrimitive и установка параметров шейдеров. Да, я использовал уже написанный collision detection и выборку по миру. Так это был нами написанный код.
E>Собственно, об этом и речь, что предметная область довольно специфическая. Как в свое время АСУТП была -- народ писал сам все, начиная от драйверов устройств и заканчивая рисованием исторических трендов. Затем, постепенно, развились SCADA системы и некоторые классы информационно-измерительных систем стали решаться на раз, с помощью только визуального программирования.
E>В той же игровой индустрии для ПК инструменты типа OpenGL, DirectX или SDL так же не сразу появились, но постепенно подобные библиотеки берут на себя изрядную часть забот разработчика.

Хаха три раза, ага.

T>>Теперь посчитай возможности этих библиотек, которые ты действительно используешь и прикинь, насколько их объём можно сократить. С учётом стиля вашего кодирования, поскольку, как я понимаю, вы используете Java и некоторые из этих библиотек вынуждены поддерживать её целиком.
E>С++ используем.

Ещё хуже, поскольку язык обширней.

T>>Библиотеки — это те же самые языки программирования. Их возможности используются процентов на 10, хорошо если так много. Просто разным людям нужны разные возможности, вот и пестрота с объёмом наперевес.
E>Тем не менее, объем сторонних библиотек в последние десятилетия значительно возрос. А процент прикладного кода по отношению к объему используемых библиотек во многих типах проектов значительно снизился. И продолжает снижаться. Что, имхо, очень хорошо.

Это хорошо, что ты не стал оценивать объём кода библиотек, который вам действительно нужен. Значит, это знание находится у тебя в подсознании и будет влиять на твои решения в будущем.

T>>И в заключении: деньги платят за решение проблем, которые никто ещё не решал. Не решённые проблемы не существуют в виде библиотек. Уже существующими библиотеками можно только облегчить свою судьбу, но не уйти от неё совсем.
E>Выделенное жирным -- заблуждение. Деньги очень хорошо платят и за решение конкретных задач конкретного заказчика. Поскольку при всем богатстве выбора обязательно находятся клиенты, которые хотят "точно такой же, но с перламутровыми пуговицами".
E>Реальные прорывы (вроде изобретения парового двигателя, дизеля, телефона, компьютерной мыши или графического оконного интерфейса) встречаются очень редко.

Выделенное жирным — заблуждение. Заблуждение, что я об этом говорил.

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

Вот и тонны кода.

E>Зато потом начинается соревнование производителей за более выгодную для пользователей реализацию идеи. Достаточно вспомнить, что MS DOS не был чем-то новым, MS Windows не был чем-то новым. Все это уже решалось и достаточно хорошо. Зато эти продукты стали хорошими адаптациями уже известных идей для конкретных условий.

Хорошо пристроенными и хорошо раскрученными адаптациями, а не просто хорошими адаптациями.

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

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

Я уже не помню, о чём вы говорили :-) Но, наверное, имеется в виду описание инвариантов поведения в типах.

V>Где ты увидел вопрос про "плоское пространство имён"? Похоже, ты не отличаешь "область видимости" от "уровня доступа/видимости".

Что такое уровень видимости в Haskell? Там же блоков нет.

Если ты про do-нотацию, то там немножко другое.

Хотя вот этот пример работает, как и ожидается.

main = do
    v <- return 1
    print v
    do v <- return 2
       print v

V>В любом случае, модели из этой области на ООП реализуются более естественным образом, ибо приличная часть из них лежит на автоматной модели.

Почему автомат проще на ООП?

V>Кстати, интересная мысль в голову пришла. Вот у нас есть некий направленный граф. Есть 2 распространённых способа моделирования направленного графа:
V>- отдельно список вершин и отдельно список дуг, дуга при этом содержит обе вершины;
V>- список исходящих дуг принадлежит узлу, дуга при этом содержит только конечную вершину.
V>Как на Хаскеле зациклить этот граф во втором случае?

Haskell — язык ленивый.

vertex1 = Vertex [Edge vertex2]
vertex2 = Vertex [Edge vertex1]

Но вообще-то каждому подходу свои структуры данных. На Haskell чистые структуры пишутся легко, мутабельные — сложнее (см. doubly linked list, например).

V>Ладно, много раз порывался забросить этот театр абсурда, ибо кое-кто нить рассуждения постоянно теряет... Но мне пока кое-что надо увидеть (надеюсь этот бонус всё-таки будет). В общем, конкретно здесь речь шла о том (просто напоминаю), что я предположил, что на некоторых задачах ты всё-равно будешь использовать больше, чем упомянутые 10% возможностей. Я понимаю, что эти модули по приведённым тобой ссылкам сделал не ты лично, но зато ты имеешь возможность взглянуть в их исходники, сравнить кол-во использованных возможностей языка со своим "стилем кодирования" и, теперь восстановив нить обсуждения, сказать — удачный ли был мой пример в плане демонстрации того, что не только стиль кодирования определяет набор используемых языковых ср-в для решения задач, но иногда выход за эти 10% обуславливается характером самих задач.

С Хаскелем проще — там 90% конструкций сахар. Что касается этих библиотек, то там кода вообще кот наплакал, потому что основные операции зашиты в натив. В MVar так вообще 1% языковых средств используется. Самое сильное — do-нотация :))

T>>Почему State monad уродство? Твоё личное предпочтение?
V>Обычное lvalue.

Потому что на императивном языке это примитивная операция?

V>Это было бы так, если бы не странные ограничения name conventions (сдаётся мне, что это еще один из минусов для целей популяризации). C# и то отличает тип от ф-ии, не обладая такой системой вывода типов.

О, это сделано для удобства. Не надо писать map :: forall a b. (a -> b) -> [a] -> [b], достаточно просто (a -> b) -> [a] -> [b] и то, что a,b — параметры типа, а не конкретные типы определится по регистру. Что касается конструкторов против функций — то верхний регистр — это что-то вроде new в С#: x = Foo 42 против x = foo 42.

P.S. И эта... Кончайте лаяться :-) Вы же оба умные, что аж смотреть страшно. Даёшь больше конструктива!

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

E>>В той же игровой индустрии для ПК инструменты типа OpenGL, DirectX или SDL так же не сразу появились, но постепенно подобные библиотеки берут на себя изрядную часть забот разработчика.

T>Хаха три раза, ага.

Ну похоже, я жуву в параллельной вселенной. В которой когда-то были игры под MS DOS, для которых параметры звука пользователям нужно было выставлять вручную. И в которой некоторые игры не могли работать, если звуковая карта была не совместима с Sound Blaster. Наверное, тогда разработчикам игр не приходилось самим писать код для работы со звуковухой. И что появление вещей, типа DirectSound и SDL ну нисколько не облегчило жизнь разработчикам игр, ну совсем

T>Это хорошо, что ты не стал оценивать объём кода библиотек, который вам действительно нужен. Значит, это знание находится у тебя в подсознании и будет влиять на твои решения в будущем.

Это всего лишь значит, что для многих библиотек это очень тяжело сделать физически. Т.к. не все разработчики библиотек заботятся о модульной огранизации, чтобы можно было выделить только то, что необходимо, а все остальное выкинуть. Так что применительно к ACE я просто не могу сказать, какой процент кода в нем занимают такие вещи, как ACE_Thread_Mutex, ACE_SOCK_Acceptor, ACE_SOCK_Connector, ACE_Reactor, ACE_Select_Reactor, ACE_TP_Reactor, ACE_Timer_Thread_Adapter и пр. Но, подозреваю, что эти вещи очень тесно связаны с еще большим куском кода из ACE, обеспечивающим кросс-платформенность.

Пример на эту же тему. Я попробовал вытянуть из Boost-а библиотеку для работы с hash-map-ами. Так она со всеми своими зависимостями потянула на 7Mb исходников (~4Kloc сам boost::unordered и ~193Kloc дополнительных зависимостей).

T>>>И в заключении: деньги платят за решение проблем, которые никто ещё не решал. Не решённые проблемы не существуют в виде библиотек. Уже существующими библиотеками можно только облегчить свою судьбу, но не уйти от неё совсем.
E>>Выделенное жирным -- заблуждение. Деньги очень хорошо платят и за решение конкретных задач конкретного заказчика. Поскольку при всем богатстве выбора обязательно находятся клиенты, которые хотят "точно такой же, но с перламутровыми пуговицами".
E>>Реальные прорывы (вроде изобретения парового двигателя, дизеля, телефона, компьютерной мыши или графического оконного интерфейса) встречаются очень редко.

T>Выделенное жирным — заблуждение. Заблуждение, что я об этом говорил.

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

T>>Ну, возможно, видел. Но ведешь себя так, как будто не видел. В голове у тебя не отложилось, как это можно использовать.
V>И сколько раз за 10 лет твоего использования Хаскеля он помог тебе избежать зацикливания? Я вообще таких ошибок за всю свою жизнь помню меньше, чем пальцев на одной руке, среди огромного множества остальных.

Да, это редкая ошибка. Но она ловится.

T>>Круто!
T>>Совсем-совсем не применимо? Даже пытаться не стоит?
V>Придумай куда применить. У нас и констант-то не много в коде обычно, параметры алгоритмов зачастую через конфиги настраиваются в run-time. И не от хорошей жизни.

То есть, мы не можем выразить сложность алгоритма через эти самые параметры?

T>>Все косяки в esimp, что ты увидел, существовали только в твоих глазах, дорогой товарищ.
V>Сколько сахар не говори... Ты там неплохо про "тиражирование идиотизма сказал". Если есть входные данные, на которых алгоритм не работает, то это обычный косяк, и не надо заниматься мантрой "не критично, не критично".

Я повторяю не слово "сахар", чтобы тебе слаще стало, а очень просто утверждение, что ты увидел "косяки", которых в реализации не было.

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

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

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

О, да. Все вокруг либо дети, лиоб уже взрослые, все вокруг либо пишут полную туфту, либо сразу пишут всё, как надо.

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

Вот тут

Автор: thesz
Дата: 10.03.09

Цитирую самого себя:

Пример.

Внутреннее представление ghc типизировано. При желании можно включить проверку типов для него после каждого преобразования. Если преобразование неправильное, то проверка типов нам об этом сообщит. Эта фича позволила сэкономить разработчикам ghc много времени.

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

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

Внутреннее представление есть у всех. Степень типизации, правда, разная.

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

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

Это вынуждает этим пользоваться.

Это сокращает количество ошибок.

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

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

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

В ghc 6.10.1 появились data families и type families. data families позволяют безопасно преобразовывать данные. Мы можем гарантировать, что входные и выходные данные будут в boxed формате для обычного кода, а все промежуточные — в unboxed для скорости.

Это используется в реализации OpenCL и Data Parallel Haskell, как я понял из описаний Manuel Chakravarty.

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

Система типов Хаскеля представляет собой логику, называется она как-то в районе Fomega, или Fc, не помню.

Такую же логику пытался сделать для ООП Luca Cardelli. Это заняло у него больше 25 лет, насколько я помню.

За другие 25 лет система типов Хаскеля прошла путь от обычного алгоритма W Милнера до открытых функций над типами. Сейчас Хаскель способен типобезопасно выражать операции над векторами в стиле GPGPU, что ставит его на одну доску с C++, как минимум. А легкость, которой это достигается, позволяет передвинуть его вперёд C++.

А я по мелочи — размеры битовых векторов проверяю.

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

"Куда, как более гладко", как мы неоднократно выясняли на RSDN, означает "куда, как привычней мне лично".

Серьёзно. Ну вот откуда ты знаешь, что на ЯП получится хуже, чем на ООЯП? Ты делал сравнительные реализации?

А я могу похвастаться тем, что мы делали. ООЯП C++ с мощной библиотекой SystemC проиграл по практически по всем пунктам Хаскелю с одним файликом в двадцать строк кода. В пункты входили быстродействие программы, объём кода, сроки разработки и душевное здоровье членов коллектива.

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

Ты спрашивай, а не отвечай сам на свои вопросы самым худшим вариантом, что ты смог придумать.

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

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

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

V>Где ты увидел вопрос про "плоское пространство имён"? Похоже, ты не отличаешь "область видимости" от "уровня доступа/видимости".

Так объясни.

T>>Ты, уж, ознакомься с критикуемым-то. Вся информация в интернете есть.
T>>А то мне скоро наскучит мириться с твоим тиражированием идиотизма.
V>Хамишь, парниша... Это помимо того, что опять бросаешься отвечать, не понимая сути вопроса. Даю еще одну попытку.

Давай-давай, объясняй.

А я посмотрю. по твоему объяснению, был ли я прав про "плоское пространство имён" и был ли прав ты про "не в состоянии обеспечить нормальной инакпсуляции".

T>>Ты уж извини, но библиотеки не могут быть написаны на все случаи жизни.
T>>Например, Java и .Net до сих пор не имеют библиотеки моделирования систем на дискретных событиях.
V>Разных математических тонна, какой именно класс систем на дискретных событиях интересует?

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

V>И зря ты этот пример привёл, ой как зря. Помнишь спор о графическом представлении программной модели? Вот для как раз этой предметной области графическое представление — самое то. Если интересуешься системами на дискретных событиях, марковскими процессами и прочим, то сразу гоу ту симулинк и не занимайся онанизмом на текстовом ЯП.

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

Я уж лучше потрачу месяц и помучаюсь с ЯП.

V>В любом случае, модели из этой области на ООП реализуются более естественным образом, ибо приличная часть из них лежит на автоматной модели.

Автоматы на алгебраических типах делаются естественней и безопасней, чем на ООП.

V>Кстати, интересная мысль в голову пришла. Вот у нас есть некий направленный граф. Есть 2 распространённых способа моделирования направленного графа:
V>- отдельно список вершин и отдельно список дуг, дуга при этом содержит обе вершины;
V>- список исходящих дуг принадлежит узлу, дуга при этом содержит только конечную вершину.
V>Как на Хаскеле зациклить этот граф во втором случае?

import Data.List

infixr 3 #

data G n = G [(n,[n])]

emptyG :: G n
emptyG = G []
extendG :: n -> [n] -> G n -> G n
extendG node nodes (G graph) = G $ (node,nodes):graph

(node,nodes) # graph = extendG node nodes graph

prettyG :: Show n => G n -> String
prettyG (G graph) = unlines $
    map (\(n,ns) -> show n++" -> "++show ns) graph

cyclic = (1,[2]) # (2,[1]) # emptyG

Вывод:
*Main> putStr $ prettyG cyclic
1 -> [2]
2 -> [1]

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

V>using(Stream s = File.OpenStream(path))
V>  return EDIParser.Parse(s);
V>

Ты path как-то собрал? Ты исключение как-то проверил?

V>В любом случае, пример неудачный. Огромная часть бизнес задач сегодня — это распределённые системы, веб-морды, данные в СУБД (метаданные тоже), насраиваемое логгирование и т.д. и т.п., под небольшой прикладной логикой плавают целые айсберги тяжеловесного middleware.

Я в соседнем комментарии объяснил, почему айсберги.

T>>Приведи пример.
T>>Есть у меня подозрение, что функциональности там кот наплакал.
V>У меня есть подозрения, что даже одну вшивую, но интерактивную страничку, работающую с различными платёжными системами, и использующую со стороны сервера сразу несколько защищённых протоколов передачи и протоколов аутентификации, на Хаскеле долго и нудно ручками долбить надо будет, в отличие от .Net или Java, где это всё 2 пальца об асфальт.

В крайнем случае, я сделаю интерфейс.

V>Можно насчёт этой пресловутой странички не отвечать, просто хвастаться наличием неких спец.мат.билиотек для априори академического языка — это как-то совсем аргументы исчерпать надо было.

Ты это о чём?

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

Люди в тысяче километров от меня делали атомную бомбу. Мир очень маленький.

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

Самое простое: обратная группировка. ab+ac => a(b+c). Чтобы уменьшить количество умножений и делений. Да ещё надо учесть, что a, b и c не просто переменные, а сложные функции от бесконечных степенных рядов, могут быть и sin/cos, и экспонентой.

Мне на данном этапе хватило упорядоченного упрощения. Что-то типа:

esimp (Mul a b) = case orderPair (esimp a,esimp b) of
    (Const a,Mul (Const b) c) -> ...
    -- (Mul a b,Const c) быть не может, как не может быть (Const a, Mul b (Const c)).

Это был следующий вариант.

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

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

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

T>>Вместо того, чтобы спросить у меня, встречаются ли на входе упростителя значения разных типов, ты на голубом глазу предположил, что встречаются. Исходя из своего опыта, конечно.
V>Очередной выпад типичного ФП-проповедника. Смысл как обычно: "все дураки".
V>Дык, у меня есть чудесный ответ: "сам дурак". Мы конкретный твой исходник обсуждаем, а не предполагаемые вербальные ограничения его использования. И ведь насколько мне позволяют судить мои познания в Хаскеле, в твой исходник можно подавать любые типы, для пары которых определена операция умножения "*". И уж тем более не понятно, почему ты явно не указал в контракте, что тип аргументов будет одинаков, раз того требует твой сценарий использования этого оптимизатора. А ведь этот косяк посильнее первого будет, не находишь? В общем, хреновый из тебя продавец ФП, будь ты в моей команде — был бы наруган за подобное разгильдяйство в контрактах. Так что, список мест, где тебе стоило бы взять свои слова обратно, неуклонно растёт.

Я не беру свои слова обратно. Не тру комментарии в ЖЖ, ни свои, ни чужие. Мне настолько же важен мой и чужой ум, насколько важна моя и чужая глупость.

Теперь к теме задачи. Операция умножения под кодовым названием Asterisk, она же *, она же Звёздочка, принимает на входе два аргумента одного типа и выдаёт результат того же типа. Это, прошу прощения, элементарная алгебра. Именно по алгебре и сделано определение Звёздочки в Хаскеле: (*) :: Num a => a -> a -> a

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

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

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

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

Новую.

У тебя, видимо, ещё не было опыта, когда ты неправильно что-то предполагал. Ты, видимо, никогда не ошибался в своих предположениях.

Ну, так поздравляю: ты не так давно что-то предположил и ошибся! Это новый, очень ценный опыт.

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

Да и вообще, думать наперёд лучше, чем думать опосля.

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

Опыт gcc показывает, что ты неправильно мыслишь об оптимизации вообще. Это понятно?

Да и в этом конкретном случае тоже неправильно мыслишь. Поскольку лично мне это не было нужно.

T>>>>Но это твои личные проблемы.
V>>>Я так и понял, проехали. Если ФП не в состоянии "автоматом" исправлять ошибки логики, то это проблемы программиста, а не ЯП... ЧТД.
T>>Оно может указывать на ошибки логики.
V>Я знаю, на какие ошибки логики оно может указывать. И вывод типов не только в Хаскеле есть, если помнишь. И логика не только на if или паттерн матчингах строится, сами вычисления — это тоже часть логики. Ты же всё время пытаешься меня убедить, что мы тут в основном совершаем ошибки того плана, который обязательно найдёт компилятор. Это заблуждение. Подавляющее большинство ошибок по моему опыту — это или высокоуровневые, т.е. ошибки той логики, которая компилятору недоступна, и связана с некорректным пониманием требований или (что гораздо чаще) с неполной их реализацией. Или же те описки, которые пропускает система типов компилятора.
V>Вот суть одного моего косяка из недавнего:
V>

V>public bool SomeProp {
V>  set {
V>    if(value
V>      DoSomething();

V>    _value = false; // должно быть _value = value;
V>  }
V>}
V>

Оная someProp на Хаскеле содержала бы _value в качестве составной части результата. Ты бы смог её протестировать отдельно, на всех интересных входных данных.

Даже если бы это была монада State:
MyModule>let inputState = emptyInputState { value = True, _value = True }
MyModule>runState (someProp arg2 arg3) inputState
MyState { _value = False } -- а должно быть True!

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

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

И помогает ловить ошибки.

V>Причём, то-ли глаз замылился, то ли что... Но даже при просмотре кода я эту описку упускал дважды, не мог понять, что за фигня (было подозрение на ошибку синхронизации и перезапись из другого потока). Типизация в порядке — компилятор себе компилит. Чистое ФП не предлагать, я бы и на Хаскеле тут State сделал бы, это один из атрибутов состояния активного соединения.

"Настоящий программист способен написать фортрановскую программу на любом языке программирования."

State это та же чистая функция, вид в профиль.

V>Или взять твой пример BallinF, там ведь в правой части каждой строки матчинга можно допустить описку/ошибку логики, которая прекрасно скомпилится. И где тут будет помощь компилятора?

В Хаскеле — мало. Хотя я тут навострился применять семейства типов, кое-что полезное ловится.

В теории типов ты можешь задать (почти) произвольный инвариант в типе. Например, если должно быть сложение на (EBin Plus a b), то нельзя делать вычитания.

T>>Спасибо. Буду знать. А то не знал, что не знаю, теперь буду знать. Не думаю, что буду знать, что знаю, правда, но буду знать о своём незнании.
T>>Самому-то не видно, что не знаешь.
V>Наплюй, просто в твоей манере решил абзац написать. Как оно смотрится со стороны, когда банальности за откровения выдаются, теперь представляешь.

О! Спасибо, объяснил. Теперь я буду знать, как ты пишешь, когда пародируешь меня.

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

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

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

V>Дык, на вопрос лучше не отвечать вообще, чем отвечать так, как ты там ответил.
V>Раз не смог объяснить, значит сам не знаешь. Как тебе такая логика?

Раз я не смог объяснить, значит, что я не смог объяснить. Всякие "сам не знаешь" это для выведения оппонента из себя. Вина может быть моей, вина может быть твоей.

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

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

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

То есть, как я всегда и поступал.

T>>Слушай, вот эта картинка выдаёт уровень твоего внимания как нельзя лучше.
V>Да, надо заканчивать в 6 утра постить. Сделал правильно, кол-во сравнений у себя посчитал неправильно.

А вот на Хаскеле можно программировать с температурой или даже выпив литр пива. Всё равно работать будет.

Очень удобно.

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

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

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

V>Ладно, много раз порывался забросить этот театр абсурда, ибо кое-кто нить рассуждения постоянно теряет... Но мне пока кое-что надо увидеть (надеюсь этот бонус всё-таки будет). В общем, конкретно здесь речь шла о том (просто напоминаю), что я предположил, что на некоторых задачах ты всё-равно будешь использовать больше, чем упомянутые 10% возможностей. Я понимаю, что эти модули по приведённым тобой ссылкам сделал не ты лично, но зато ты имеешь возможность взглянуть в их исходники, сравнить кол-во использованных возможностей языка со своим "стилем кодирования" и, теперь восстановив нить обсуждения, сказать — удачный ли был мой пример в плане демонстрации того, что не только стиль кодирования определяет набор используемых языковых ср-в для решения задач, но иногда выход за эти 10% обуславливается характером самих задач.

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

STM пристально не интересовался. Потом посмотрю.

T>>Почему State monad уродство? Твоё личное предпочтение?
V>Обычное lvalue.

За исключением прозрачности по ссылкам. И скрытости. Так что это не обычное lvalue.

T>>Типобезопасность в ленивых ФЯ достигается проще всех остальных. Все остальные системы сложнее. BitC, например — авторы сами признают, что задача у них очень мощная и почти неподъёмная.
V>Наверно ты хотел сказать — вывод типов в ленивых ФЯ достигается проще всех остальных. Однако, ты же можешь и явно типы специфицировать, начиная от примитивных, типа int (или как они там в Хаскель называются). И тогда ленивость/нелинивость будут до фени.

Я сказал ровно то, что я хотел сказать. Это не то, что ты считаешь, что я, наверное, сказал.

T>>Всё, что может Фортресс, выражается в зависимых типах.
V>Хороший аргумент.
V>Это из разряда "всё, что могут делегаты C# выражается в библиотечном виде на С++".

Да. Только в C++ библиотеки плохо собираются вместе, а в теории типов будут собираться хорошо. Плюс, когда мне понадобится что-то очень похожее на Фортресс, но с запахом жасмина, то я смогу сделать это сам.

Как самостоятельно собирал циклы с многими точками входа на Хаскеле, вместо использования PL/1.

T>>Собственно, почему я на них так и сфокусирован: разобравшись с ЗТД, я получаю забесплатно и Фортресс, и Boo и практически всё, что смогу захотеть.
V>Это было бы так, если бы не странные ограничения name conventions (сдаётся мне, что это еще один из минусов для целей популяризации). C# и то отличает тип от ф-ии, не обладая такой системой вывода типов.

Похоже, ты вообще не утруждаешь себя размышлениями. Что будет означать (just nothing list) в сравнении с образцом? nothing — это конструктор, или переменная? Над Хаскелем изначально работали люди, которых приглашают специально поработать над C# или Java, чтобы решить очередные проблемы. Приглашают потому, что они overqualified для работы на полную ставку.

T>>Увы, практика доказывает обратное.
T>>Алгоритм W (Хиндли-Милнера) сперва доказали для чистого подмножества ML, а потом отдельно доказывали для ML со ссылками.
V>Насколько я понял, еще в конце 80-х все эти вещи произошли.

Алгоритм W — 1978. А со ссылками позже на несколько лет.

E>>>В той же игровой индустрии для ПК инструменты типа OpenGL, DirectX или SDL так же не сразу появились, но постепенно подобные библиотеки берут на себя изрядную часть забот разработчика.
T>>Хаха три раза, ага.
E>Ну похоже, я жуву в параллельной вселенной. В которой когда-то были игры под MS DOS, для которых параметры звука пользователям нужно было выставлять вручную. И в которой некоторые игры не могли работать, если звуковая карта была не совместима с Sound Blaster. Наверное, тогда разработчикам игр не приходилось самим писать код для работы со звуковухой. И что появление вещей, типа DirectSound и SDL ну нисколько не облегчило жизнь разработчикам игр, ну совсем

А, вот ты о чём.

Сейчас объём кода самих игр не изменился. Логика чуть повыше, но и объёмы побольше. Процент вызова DX такой же, какой был процент IN/OUT под MS-DOS.

Это справедливо для всех известных мне игр и движков.

T>>Это хорошо, что ты не стал оценивать объём кода библиотек, который вам действительно нужен. Значит, это знание находится у тебя в подсознании и будет влиять на твои решения в будущем.
E>Это всего лишь значит, что для многих библиотек это очень тяжело сделать физически. Т.к. не все разработчики библиотек заботятся о модульной огранизации, чтобы можно было выделить только то, что необходимо, а все остальное выкинуть. Так что применительно к ACE я просто не могу сказать, какой процент кода в нем занимают такие вещи, как ACE_Thread_Mutex, ACE_SOCK_Acceptor, ACE_SOCK_Connector, ACE_Reactor, ACE_Select_Reactor, ACE_TP_Reactor, ACE_Timer_Thread_Adapter и пр. Но, подозреваю, что эти вещи очень тесно связаны с еще большим куском кода из ACE, обеспечивающим кросс-платформенность.
E>Пример на эту же тему. Я попробовал вытянуть из Boost-а библиотеку для работы с hash-map-ами. Так она со всеми своими зависимостями потянула на 7Mb исходников (~4Kloc сам boost::unordered и ~193Kloc дополнительных зависимостей).

boost::unordered — hash map, так?

То есть, ядро составляет 193KLOC, что, примерно, 5% от самого boost::unordered. Ядро ACE должно быть таким же, наверное.

Небольшим.

T>>>>И в заключении: деньги платят за решение проблем, которые никто ещё не решал. Не решённые проблемы не существуют в виде библиотек. Уже существующими библиотеками можно только облегчить свою судьбу, но не уйти от неё совсем.
E>>>Выделенное жирным -- заблуждение. Деньги очень хорошо платят и за решение конкретных задач конкретного заказчика. Поскольку при всем богатстве выбора обязательно находятся клиенты, которые хотят "точно такой же, но с перламутровыми пуговицами".
E>>>Реальные прорывы (вроде изобретения парового двигателя, дизеля, телефона, компьютерной мыши или графического оконного интерфейса) встречаются очень редко.
T>>Выделенное жирным — заблуждение. Заблуждение, что я об этом говорил.
E>Твоя фраза, имхо, воспринимается весьма однозначно: деньги платят за решения еще нерешенных никем проблем. Это очень сильное преувеличение, о чем я тебе и сказал. Если же ты пытался сказать о чем-то другом, то лично я этого не понял.

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

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

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

lomeo wrote:

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

> .>Как этот DSL поможет при рефакторинге? Банально переименовать название
> поля и в бинах, и в маппингах и т.п.?
> Для этого нужен редактор с поддержкой рефакторинга. vim
А откуда этот редактор узнает, что в hbm.xml-файле такой-то тег, такой-то атрибут означает имя поля и там его тоже поменять?
Вот ИДЕЮ этому можно "обучать".

> Что касается "и в бинах, и в маппингах". Есть мнение, что надо одно из
> другого генерировать, а не синхронизировать.
Это невозможно. Маппинг содержит другую информацию, кроме названий/типов полей объекта. А значит он должен быть помещён отдельно от бина, ради декларативности и SRP.

> .>В общем-то IDEA этот DSL и позволяет прикрутить в любое место кода,
> только это у неё называется не DSL, а injected language.
> Мне кажется, что injected language написать сложнее, чем eDSL.
Injected lanugage это DSL, встроенный в IDE.
Скажем, у тебя есть
[html]
<img src="../images/img.gif" style="border:1px dotted #fea0e0" class="foo bar" onclick="clicked(1,2,3)">test</img>
[/html]
тут в одном языке, html, в одной из его синтаксических элементов (значении атрибута style) вставлен другой язык — css. При наведении мышой IDEA покажет квадратик закрашенный цветом #fea0e0, чтобы сразу понять как оно выглядит.
src содержит путь до файла, который должен существовать (при наведении мышой IDEA покажет в тултипе размер картинки и её thumbnail).
В атрибуте class встречается названия классов css, которое должно быть определено в неком другом файле .css.
А в onclick ещё один язык — js.

Соответственно, IDE тебе сможет найти где находится определение функции clicked, выведет определения css-классов foo и bar, покажет все места, где используются эти имена. Не забудет их переименовать везде где нужно, при переименовании. Будет правильно раскрашивать, подчёркивать синтаксические ошибки и покажет помощь (документацию) по функции clicked.

Или ты предлагаешь переписать все DSL в eDSL? Я сомневаюсь, что есть такой язык, куда одинаково просто и удобно можно будет заембеддить языки для regex, sql, css и html.

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

E>Ну похоже, я жуву в параллельной вселенной. В которой когда-то были игры под MS DOS, для которых параметры звука пользователям нужно было выставлять вручную. И в которой некоторые игры не могли работать, если звуковая карта была не совместима с Sound Blaster. Наверное, тогда разработчикам игр не приходилось самим писать код для работы со звуковухой. И что появление вещей, типа DirectSound и SDL ну нисколько не облегчило жизнь разработчикам игр, ну совсем

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

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

>> Есть мнение, что это разные задачи и для них нужны разные инструменты.
.>Так вот ИДЕЯ и является таким инструментом, для организации всего этого дела. Какие есть альтернативы? Ведь DSL к этому никакого отношения не имеет.

IDEA — это комбайн :-)

.>А откуда этот редактор узнает, что в hbm.xml-файле такой-то тег, такой-то атрибут означает имя поля и там его тоже поменять?
.>Вот ИДЕЮ этому можно "обучать".

Если что-то по сути есть одна сущность и встречается в двух и более местах, то я стараюсь все "вторые места" генерировать.

>> Что касается "и в бинах, и в маппингах". Есть мнение, что надо одно из
>> другого генерировать, а не синхронизировать.
.>Это невозможно. Маппинг содержит другую информацию, кроме названий/типов полей объекта. А значит он должен быть помещён отдельно от бина, ради декларативности и SRP.

Можно пример, а то вот даже для бин/маппинг есть Hibernate Annotations.

.>Injected lanugage это DSL, встроенный в IDE.
.>Соответственно, IDE тебе сможет найти где находится определение функции clicked, выведет определения css-классов foo и bar, покажет все места, где используются эти имена. Не забудет их переименовать везде где нужно, при переименовании. Будет правильно раскрашивать, подчёркивать синтаксические ошибки и покажет помощь (документацию) по функции clicked.

Да, я понимаю это. И про IDEA регулярно читаю. Хочу прояснить свою позицию. Я не говорю — DSL — труъ, IDEA must die. Но лично мне IDEA скорее вредит, т.к. поощряет держать несколько зависимых источников, вместо генерации их. Подчёркиваю — это очень субъективное, допускаю, что программисту с более сильной внутренней организацией и дисциплиной IDEA может сильно помочь.

.>Или ты предлагаешь переписать все DSL в eDSL? Я сомневаюсь, что есть такой язык, куда одинаково просто и удобно можно будет заембеддить языки для regex, sql, css и html.

perl? :))

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

Подытожу:

1. IDEA поощряет написание boilerplate кода.
2. Мы должны полагаться на то, что будем пользоваться IDEA при разработке данного проекта, и что она всегда корректно синхронизирует наш код.

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

.>>Это невозможно. Маппинг содержит другую информацию, кроме названий/типов полей объекта. А значит он должен быть помещён отдельно от бина, ради декларативности и SRP.
L>Можно пример, а то вот даже для бин/маппинг есть Hibernate Annotations.
Например, скрипты создания индексов (зависят от БД), названия таблиц и специальные запросы. Нечего им в коде делать.

Чего ты тут будешь генерировать?

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

L>>Можно пример, а то вот даже для бин/маппинг есть Hibernate Annotations.
C>Например, скрипты создания индексов (зависят от БД), названия таблиц и специальные запросы. Нечего им в коде делать.

C>Чего ты тут будешь генерировать?

SQL?

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

lomeo wrote:

> .>А откуда этот редактор узнает, что в hbm.xml-файле такой-то тег,
> такой-то атрибут означает имя поля и там его тоже поменять?
> .>Вот ИДЕЮ этому можно "обучать".
> Если что-то по сути есть одна сущность и встречается в двух и более
> местах, то я стараюсь все "вторые места" генерировать.
Так объясняю же, нечего генерировать-то. Просто это разная информация, но связанная. Одна информация описывает структуру объекта (поля и их типы), а другая — как этот объект взаимодействует с субд.

> Можно пример, а то вот даже для бин/маппинг есть Hibernate Annotations.
Их полезность несколько спорная...

> Да, я понимаю это. И про IDEA регулярно читаю. Хочу прояснить свою
> позицию. Я не говорю — DSL — труъ, IDEA must die. Но лично мне IDEA
> скорее вредит, т.к. поощряет держать несколько зависимых источников,
> вместо генерации их. Подчёркиваю — это очень субъективное, допускаю, что
> программисту с более сильной внутренней организацией и дисциплиной IDEA
> может сильно помочь.
Генерации чего? Я просто не понимаю, что ты хочешь сказать. Нечего генерировать-то!

> perl?


> 1. IDEA поощряет написание boilerplate кода.
Не так уж он и страшен этот код. Писать такой код, конечно, может не столь красиво, но облегчение рефакторинга даёт серьёзное преимущество.

> 2. Мы должны полагаться на то, что будем пользоваться IDEA при
> разработке данного проекта, и что она всегда корректно синхронизирует
> наш код.
Ничего подобного. Если идеи нет или она что-то не умеет — меняешь файлы как нравится. Она ничего "своего" не создаёт, обыкновенные исходники. Файлы проектов идеи даже не обязательно класть в систему контроля версий.

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

C>>Чего ты тут будешь генерировать?
VD>SQL?
Это далеко не всегда возможно.

VD>Лично мне нравится идея когда БД описывается специальным ДСЛ-ем, а уже ее структура генерируется и изменяется с помощью универсального кода который читает это описание, сравнивает его с метаинформацией взятой из БД и модифицирует БД так чтобы она соответствовала исходному описанию.
Это противоречит использованию легковесных mapper'ов, за которые тут не так давно были битвы Вариант, на самом деле, интересный. Я примерно сейчас его и использую — DSLем являются файлы mapping'а Hibernate.

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

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

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

.>>>Это невозможно. Маппинг содержит другую информацию, кроме названий/типов полей объекта. А значит он должен быть помещён отдельно от бина, ради декларативности и SRP.
L>>Можно пример, а то вот даже для бин/маппинг есть Hibernate Annotations.
C>Например, скрипты создания индексов (зависят от БД), названия таблиц и специальные запросы. Нечего им в коде делать.
C>Чего ты тут будешь генерировать?

Упс, а я их генерировал. Даже специальные запросы, но они у меня не очень часто встречаются.

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

L>>>Можно пример, а то вот даже для бин/маппинг есть Hibernate Annotations.
C>>Например, скрипты создания индексов (зависят от БД), названия таблиц и специальные запросы. Нечего им в коде делать.
C>>Чего ты тут будешь генерировать?
L>Упс, а я их генерировал. Даже специальные запросы, но они у меня не очень часто встречаются.
Упс, а у меня их человек на fulltime'е пишет. Так как они не генерируются нифига.

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

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

Ну, я генерировал. Плюс ещё и морду. Из одного места всё.

>> Можно пример, а то вот даже для бин/маппинг есть Hibernate Annotations.
.>Их полезность несколько спорная...

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

.>Генерации чего? Я просто не понимаю, что ты хочешь сказать. Нечего генерировать-то!

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

>> 1. IDEA поощряет написание boilerplate кода.
.>Не так уж он и страшен этот код. Писать такой код, конечно, может не столь красиво, но облегчение рефакторинга даёт серьёзное преимущество.

Да. Но для меня это минус. Вместо написания двадцати строк кода я пишу пицот.
Даже если эти пицот пишутся быстрее благодаря IDEA — для меня это недостаток.

>> 2. Мы должны полагаться на то, что будем пользоваться IDEA при
>> разработке данного проекта, и что она всегда корректно синхронизирует
>> наш код.
.>Ничего подобного. Если идеи нет или она что-то не умеет — меняешь файлы как нравится. Она ничего "своего" не создаёт, обыкновенные исходники. Файлы проектов идеи даже не обязательно класть в систему контроля версий.

Тогда мы теряем в синхронизации! Поменяешь ты без IDEA где нибудь название класса стиля и привет! В хтмл он не отобразится.

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

L>>Упс, а я их генерировал. Даже специальные запросы, но они у меня не очень часто встречаются.
C>Упс, а у меня их человек на fulltime'е пишет. Так как они не генерируются нифига.

У меня генерилка не фултайм работает, а так когда понадобится, но зато и платить не надо :-)