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


WH>>Да и порог вхождения в сам питон просто огромен. Хотя и выглядит маленьким ибо простые вещи можно начать писать сразу но то что больше "привет мир"

FR>Ты не прав, но флеймить нет желания

Шота тебя мало бывает последнее время. Уклоняешься от холиваров ? Нехорошо !

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

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

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

WH>Ибо вторая такая мулька обязательно начнет иногда конфликтовать с первой и привет пара недель отладки.

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

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

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

Рефакторинг, если применяется правильно, то это не раз в год а постоянный процесс. Через год у тебя и ДСЛ будет совсем не тот, что нужен. И дальше точно так же или переписывать, или рефакторить или забить.

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

Подпорки и костыли растут вовсе не от недостатка ДСЛ и метапрограммирования. И мне совсем не ясно, как ты вычислил эту простоту, вроде инструментов рефакторинга ДСЛ и метакода пока что нет

Здравствуйте, VladD2, Вы писали:
CAB>>В моём понимании это процесс собственно создания метасредств, например макросов, DSL'ей и других программ создающих программы.
VD>ДСЛ-и тут не причем. Точнее ДСЛ-и вполне могут использоваться для МП, но ДСЛ != МП. Вот МП может быть применено при разработке ДСЛ. Это — да.
DSL'и тут для примера, того что можно сделать с помощью МП.

CAB>>А так как метасредства не являются voodoo, нужна некоторая вычислительная модель(модель вычислений), чтобы заставить это всё работать.
VD>Тут лучше остановиться и определиться с термином вычислительная модель. Машина Тюринга или лябмбда-исчисления Черча вполне пригодная модель для МП.
Вероятно WolfHound вкладывал

Автор: WolfHound
Дата: 17.03.13

несколько иной смысл в этот термин.

VD>Если серьезно, то тут главное понимать, что модель вычислений мета-средства никак не связан с моделью вычисления получаемой программы.
Тем не менее эта модель существует, и создаёт свои проблемы и ограничения, точно так-же как и в ООП.

Думаю ты согласишься что в вашем подходе есть два этапа: создание метасредств(МП) и их использование.

VD>Это, пожалуй, главное достоинство МП. Пы просто генерируем то решение (алгоритм), которое нам нужно.
Кода мы "просто генерируем" это уже не МП, это использование готовых метасредств.

VD>А то как мы это делает рояли не играет.
А "то как мы это делает" это как раз МП.

И по моему скромному мнению, вы недооцениваете сложность этапа "то как мы это делает".

CAB>>Программирование с использованием метасредств(т.е. кода уже используется только модель задачи), ИМХО, называть МП не корректно, т.к. в это случае совершенно не обязательно знать о том как работает МП, и даже о том что оно существует.
VD>Это какой-то поток сознания. Видимо ты имел в виду ДСЛ (или язык программирования вообще). Ну, да программирование на языке программирования не обязано быть метапрограммированием.
Почему только DSL? Это могу быть и макросы. Например я, когда писал на FASM'е, довольно долго использовал его макры особе не вникая как оно там работает внутри.

VD>А вот написание компилятора или интерпретатора является разновидностью МП.
Не совсем с этим согласен, всё таки, ИМХО, чаще под эти термином подразумевают макросы, шаблоны и т.п.

VD>Только это бесполезные знания.
Таких не бывает.

CAB>>Это ведь уже не программирование, это кодогенерация.
VD>Как сказал мой брат — "Помилуйте! Какой хлопок?! Это стопроцентный coon!". Если серьезно, то кодогенерация — это разновидность метапрограммирования.
Кодогенерация это процесс. Это часть МП, но не как не разновидность.

VD>МП > кодогенерации, так как МП может осуществляться за счет других средств. Например, за счет модификации кода/объектов на лету.
Возможно и может существовать, не знаю, но модификация кода/объектов также включают этап кодогенерации.

CAB>>Зачем все? Думаю достаточно МП + то во что оно будет разворачиваться.
VD>Затем, что ты, как автор метапрограммы, определяешь, что будет генерировать тво метапрограмма. И если ты не знаком с ООП, то не сможешь сгенерировать полноценныое ОО-решение.
Ok, в этом случае достаточно МП + ООП(напомню Tanker писал

Автор: Tanker
Дата: 18.03.13

"все базовые композиции — структурная, объектная, функциональная и тд нужно знать на зубок задолго до того, как берешься за метапрограммирование").

VD>Кстати, вычислительные модели ДСЛ-ей не обязаны быть парадигмамами. Это может быть куда более простая модель. Например, моделью вычислений может быть конечный автомат (как в регулярных выражениях) или сеть зависимостей (как в make/Ant/MSBuild).
Это уже реализация, не парадигма.

VD>Кстати, ты наверно даже не думал о том, что файл проекта в VS написан на ДСЛ. Верно?
Честно говоря я даже никогда не пользовался VS, так получилось

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

M>>>Кто занимается поиском ошибок в реализации этих DSLей? Их развитием, поддержкой, выявлением проблем с производительностью? Банальным обучением?

I>>Кто занимается поиском ошибок в реализации библиотек? Их развитием, поддержкой, выявлением проблем с производительностью? Банальным обучением?

I>>Неужели использоние библиотеки настолько проще, чем использование DSL? Там и там придётся читать вводную статью и полистать примеры. Количество знаний в обоих случаях практически одинаково.

M>Да неужели. Тут уже несколько лет апологеты DSL наперебой рассказывают сказки, что нет, вы что, все гораздо легче, быстрее, документируемее. А уж инструменты для разработки!!! (отсутсвующие, естественно).

Не для всех DSL нужны отдельные инструменты. Тот-же PEG работает в студии без дополнительных извращений.

M>Любая IDE для худшего из языков С++ даст многокилометровую фору любому инструменту для самого успешного из DSL-ей — SQL'ю, например. Не хочешь пофиксить баги в оптимизаторе SQLя для MySQL, например?

То есть, будь твоя воля, ты бы запросы вручную писал, минуя SQL, я правильно понимаю?

I>>Только DSL помимо функционала, предлагает сокращённый синтаксис, для того, чтобы повысить выразительность кода.
M>Да-да-да. Свежо предание. Справедливо лишь для некоторого количества DSLей, но эти DSLи имеют свои проблемы.

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

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

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

I>>Разговор ведь не о том, чтобы решать любую задачу написанием под неё DSL.

T>А разве не про это говорит WH ?

По моему нет, но я всю тему не читал.

WH> Он предлагает вместо того чтобы фиксить баг написать код который будет патчить код который поступает на вход парсеру.

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

DG>>Если делать по твоему, то при каждом обновлении — попадаешь на кучу ручной работы.
WH>Что касается твоего случая, то git это делает одной командой. Где ты нашел кучу ручной работы, я не понимаю.

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

WH>Я уже больше года так мержу изменение интеграции немерла, которое сделал лично для себя.

WH>Короче всё выглядит, так что кто-то накосячил и развел под это дело кучу идеологии.

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

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

И второе более критично, чем первое.

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

WH>> Он предлагает вместо того чтобы фиксить баг написать код который будет патчить код который поступает на вход парсеру.
DG>Такое тоже часто встречал в проектах, в которых используется кодогенерация.
Чего? Причем тут вообще кодогенерация?
Или ты еще и на генерированный код патчи накладываешь?

DG>во-первых, теряется явное знание о том, что, как и зачем патчится.
А история комитов на что?

DG>во-вторых, проект прибивается гвоздями к конкретному экземпляру и ветке git-а.
А иначе он типа не прибивается?
Как ты собрался патчи накатывать на другой код?

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

WH>Или ты еще и на генерированный код патчи накладываешь?

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

DG>>во-первых, теряется явное знание о том, что, как и зачем патчится.
WH>А история комитов на что?

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

DG>>во-вторых, проект прибивается гвоздями к конкретному экземпляру и ветке git-а.
WH>А иначе он типа не прибивается?
WH>Как ты собрался патчи накатывать на другой код?

всё написано в makefile-е или его аналоге.

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

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

VD>Обожаю телепатов.
VD>Не говоря уже об отдельных тестах PegGrammar

Ога. Отдельные. Уж не эти ли, полностью закомментированные?

VD>используется в самом Nemerle для прсинга C# (Nemerle умеет компилировать C#-файлы). Так что он тестируется непосредственно в тестах немерла.

Я ждал этого ответа.



VD>Зайди вот сюда и поищи файлы с расширением ".cs".
M>>2. В случае возникновения ошибок в парсере/генерации кода, сколько времени тебе понадобится найти и изменить ошибку,

VD>Пока что больше часа эта задача не занимала.

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

M>>имея на руках два-три десятка исходников без комментариев и завязанных на неизвестно количество макросов, определенных неизвестно где, и неизвестно, во что разворачивающихся?

VD>А это все твои выдумки. И комментарии можно добавить (и они есть).

Две строчки комментариев на два десятка файлов — это не комментарии

VD>На что код завязан тоже легко ищется. Он же квази-цитатами генерируется. Так что соответствие между генерируемым кодом и шаблонами находится под подвыражениям на раз.

Что такое «подвыражение»? Более того, «находится на раз» != «моментально становится понятно, что это такое, и что оно там делает»


M>>Автор этого добра написал это добро, которое, цитирую «может генерировать любой говнокод с нарушением всех правил хорошего тона результирующего языка, за нарушение которых при ручной работе нужно отрывать руки», и уволился из компании. Через два дня это добро начало вылезать боком изо всех щелей. Что будешь делать? Продолжать вещать сказки про «ах-ах-ах, все так прекрасно»?

VD>Тебе уже устали повторять. История когда кто-то написал много не очевидного кода и уволился может произойти где угодно и когда угодно. Без разницы наколбасил ли человек кучу, который никто понять не может, кода руками или сгенерировал его. В любом случае, если нет лиц способных понять этот код, то дело плохо.

Нет. Это не мне устали повторять. Это мы устали повторять это сказочникам.

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

Решение только и исключительно административное, заметь.


VD>То что кучу сложного кода может поддерживать кто угодно вот это и есть реальная сказка.

Ну вот вы ее постоянно и рассказываете


M>>Я и PEG пользуюсь и, скажем, SQL'ем или каким-нибудь гремлином с cypher'ом. Вот только не надо рассказывать ничем не подкрепленные сказки про мега...мега...мега... DSLей.

VD>Ярлыки "сказки" и "мега" приклеиваешь ты сам. Лично я пользуюсь МП и ДСЛ-ями каждый день и вижу очевидное преимущество этого подхода на реальных задачах. Не скажу, что ДСЛ и МП — это мега круто, но это очень мощный инструмент применение которого с умом дает очень много.

О, как интересно риторика у аплогетов ДСЛя начала меняться...

VD>ДСЛ и МП — это ни разу не панацеи. Есть задачи которые вообще бессмысленно решать с их помощью (калькулятор, приведенный тут как-то, например). Но есть проблемы которые просто глупо решать без ДСЛ-ей и/или МП.

VD>Умные люди применяют ДСЛ-и и сейчас. Вот только возможности поддержки этих ДСЛ-ей крайне ограничены, а затраты времени на их создание велико.

VD>Мы же пытаемся изменить это. Снижение сложности создания и поддержки ДСЛ с уровня "хардкор" до уровня "средний пользователь, не дурак" вполне возможно.


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

M>>Я прекрасно оцениваю сложность поддержки рукописного кода, благо работаю сейчас но кровавый энтерпрайз ©
VD>Ага. Вот и остальные странно оценивающие сложность люди и постоянно кивающие на дураков работают в этом самом энтерпрайзе. В нем явно что-то не так .

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

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

VD>>>Чем более концептуальная ошибка/изменение, тем сложнее ее устранить/сделать в рукописном коде. В решение же на базе ДСЛ и кодогенерации это не критично, так как изменив код генератора можно устранить ошибку без полного переписывания кода.

M>>Да-да-да. Ведь кодогенераторы написаные гениями без единого коммнетария так легко править!

VD>Опять выдумываешь. Дело не в том кто написал кодогенерацию, а в том, что объем кода несопоставим. Код годогенертора в десятки или сотни раз меньше генерируемого кода. И что намного важнее между кодом генерирующим код и генерируемым кодом нет зависимостей. Мы просто имеем некоторую модель (выраженную в виде ДСЛ или еще как-то) и генерирующий код. Последний читает модель и генерирует конечный код. В любой момент можно начать генерировать координатор иной код.

Легко предание, да верится... Нет, не верится.

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

О, а в вашем PEG-парсере, который раскидан по двум десяткам файлов без комментариев и без тестов (кроме как какого-то количества тестов в самом Немерле), который завязан на неизвестно количество вещей в самом Немерле, есть таки модель? Сколько времени понадобится человеку, который в глаза этот парсер не видел, исправить в нем ошибки и/или припилить к нему новый кодогенератор? Ну, например, чтобы можно было писать грамматику не inline в N-коде.

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

VD>>Мы же пытаемся изменить это. Снижение сложности создания и поддержки ДСЛ с уровня "хардкор" до уровня "средний пользователь, не дурак" вполне возможно.

M>Вот против такого объяснения, такого подхода к обсуждению и такого описания проблем тут никто на форуме вообще возражать не будет.

Да ладно. Еще как будут. И возражают.

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

M>Наличие не десятка мелких а хотя бы двух DSL-ей, в синтаксисе и компиляторах/кодогенераторах которых разбирается даже не 10% человек, а два-пять человек приводит к серьезным и плохо прогнозируемым проблемам.

Реальность она несколько иная. При переходе на ДСЛ-и и кодогенерацию 100 человек заменяются десятью. Объем кода и его противоречивость так же ужимается в 10 раз. Выявляются и устраняются противоречивые ситуации. И проект из кучи навоза превращается в конфетку.

Нужно только найти толковых людей.

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

VD>>>Мы же пытаемся изменить это. Снижение сложности создания и поддержки ДСЛ с уровня "хардкор" до уровня "средний пользователь, не дурак" вполне возможно.

M>>Вот против такого объяснения, такого подхода к обсуждению и такого описания проблем тут никто на форуме вообще возражать не будет.

VD>Да ладно. Еще как будут. И возражают.

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

M>>Наличие не десятка мелких а хотя бы двух DSL-ей, в синтаксисе и компиляторах/кодогенераторах которых разбирается даже не 10% человек, а два-пять человек приводит к серьезным и плохо прогнозируемым проблемам.

VD>Реальность она несколько иная. При переходе на ДСЛ-и и кодогенерацию 100 человек заменяются десятью. Объем кода и его противоречивость так же ужимается в 10 раз. Выявляются и устраняются противоречивые ситуации. И проект из кучи навоза превращается в конфетку.


Вот это я и называю сказками

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

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

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

VD>Не говоря уже об отдельных тестах PegGrammar используется в самом Nemerle для прсинга C# (Nemerle умеет компилировать C#-файлы). Так что он тестируется непосредственно в тестах немерла.

Это не тот Nemerle-C# который не может скомпилировать BLT ? Аргумент не в пользу Peg, скажем так.

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

VD>Реальность она несколько иная. При переходе на ДСЛ-и и кодогенерацию 100 человек заменяются десятью. Объем кода и его противоречивость так же ужимается в 10 раз. Выявляются и устраняются противоречивые ситуации. И проект из кучи навоза превращается в конфетку.

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

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

T>Это не тот Nemerle-C# который не может скомпилировать BLT ? Аргумент не в пользу Peg, скажем так.

Есть огромная разница между распарсить, и скомпилировать. Любой C# 4-код парсится без проблем.

К тому же компиляция BLT проходит. Но в немерле есть некоторые косяки которые приводят к падению скомпилированного кода в рантайме.

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

T>100 человек не потому, что надо кода много писать, а потому, что количество требований и ограничений велико.

Это чушь. 100 человек вообще не могут написать вменяемый софт.

— Степан! У гостя карета сломалась.
— Вижу, барин. Ось полетела. И спицы менять надо.
— За сколько сделаешь?
— За день сделаю.
— А за два?
— Ну… За… Сделаем и за два.
— А за пять дней?
— Ну, ежели постараться — можно и за пять.
— А за десять?
— Ну, барин, ты задачи ставишь! За десять дён одному не справиться, тут помощник нужен — хомо сапиенс!
— Бери помощников, но чтобы не раньше!

(с) Формула любви