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

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

__>>неправильно пишется
WH>Знаешь, почему на РСДН запрещено придираться к орфографии?
WH>Правильно. По тому, что слившим товарищам не остается ничего другого.

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

WH>А что ты понимаешь глядя в библиотеку?
1)Там тот-же ЯП на котором я пишу, а не другой DSL.
2)Там готовые функции/классы, а не генерирующие макросы.

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

AC>>Я побродил там, нашел сотни незнакомого мне кода и несколько не понятных комментариев, ничего не понял. Я так понимаю архитектурной документации(диаграмм особенно(особенно с паттернами),описаний) у вас нету?
WH>Рука лицо.
WH>Я тут уже сколько раз говорил, что архитектура == язык.
Т.е. чтобы понять как это работает, мне нужно: 1)изучить все/основные используемые там DSL'и(это ведь они?), 2)перечитать сотни кода, по ходу делая кучу заметок(потому что в моей голове столько кода не поместится). Вместо того чтобы бегло просмотреть несколько диаграмм?

WH>Вот язык, написанный на себе.
WH>https://github.com/rampelstinskin/ParserGenerator/blob/8d02b02b76ed08ab9f71a54ca62b5091538e6cf4/N2/N2.Grammar/GrammarParser2.n2
Ещё десятки незнакомого кода. Каким образом написанное там превращается в исполняемый файл?

WH>>>После чего подумай, чего тебе будет стоить переписать это на С.
AC>>Так что не могу оценить объём критического кода.
WH>А там нет ни строчки критического кода.
Зачем мне строчки кода? Мне нужно знать как это работает, из каких частей состоит. Тогда я смогу оценить какие из частей критические, как это можно изменить чтобы эти части было возможно переписать на Си etc.

WH>Так на всякий случай там из 190 строк на ДСЛ получается 25380 строк декомпилированного C#. Это в 133 раза больше.
Это ооооочень плохой результат. Подозреваю там сотни спагетти-кода, которые можно относительно(разработки DSL'а это генерирующего) легко заменить алгоритмами. И получатся те-же 190 строк например на питоне + плюс быстрая библиотека на Си.

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


WH>>Так на всякий случай там из 190 строк на ДСЛ получается 25380 строк декомпилированного C#. Это в 133 раза больше.
AC>Это ооооочень плохой результат. Подозреваю там сотни спагетти-кода

Естественно там спагетти код. А в чем проблема? Тя ж не коробит, что оптимизирующий компилятор С++ генерит спагетти-код, там почему тебя волнует какой код генерит DSL ??

Здравствуйте, AlexCab, Вы писали:
AC>А вы не делаете? о_О
Нет конечно. Зачем тестировать компилятор?
А UB мы не пользуемся.

AC>И во вторых, я уверен M$ тратит не мало усилий на тестирование компилятора. Вы готовы тратить столько-же(конечно DSL'и будут проще чем C#, но их будет больше)?
Вы поймите, если у вас код размера X, то надо тестировать весь X. Если у вас код размера X порождается компилятором из кода размера x, так что X = R * x, то вам надо тестировать x пользовательского кода плюс код компилятора, размером в Y.
Отсюда получаем неравенство — условие оправданности DSL:
x + Y < X
или
Y < x*(R-1)
Вся идея в том, чтобы заменить произведение суммой.

AC>Линг он один и хорошо документирован(наверно), а DSL'и будут как библиотеки — писаться кем попало и как попало.


AC>Я начинал, и много программировал на ассемблере
Это не объясняет беспокойства по поводу размера кода.
AC>В том-то и беда, это не нужный код, потому как автоматическая оптимизация менее эффективна(если бы было иначе pure C давно бы стал историей).
Сказки. Я неоднократно общался с распальцованными ассемблерщиками.
В реальной жизни они не могут порвать современный компилятор ЯВУ даже в простых сценариях.
В чуть более сложных сценариях всё заканчивается ещё в начале забега. К моменту, когда ассемблерщик вручную закончил рассчитывать constant propagation и loop unfolding, компилятор уже две недели тому назад наколбасил speculative virtual method inlining.

Это мы, конечно, говорим про "взрослые" компиляторы.
Тем не менее, идея остаётся — лучше вложить две недели в отладку алгоритма оптимизации, чем их же в ручную оптимизацию. Которую, к тому же, придётся переписывать, как только поменяются условия задачи.

S>>Мы сократили объём ручной работы и уменьшили шансы сделать ошибку.
AC>И это замечательно, но было-бы ещё лучше если бы мы нашли решение позволяющее: и сократить объём работы, и получить хороший код на выходе.
Какие бы критерии "хорошести" кода вы ни приводили, научить генератор кода им следовать можно. Обычно хотят быстродействие, а во вторую очередь — компактность. "Красоту", которая "понятность", все игнорируют. Посмотрите, во что превращается iterator pattern в C# — там же ужас с goto и switch.
Вручную так никто никогда не пишет. Тем не менее, это подкапотные неинтересные подробности. Интересует красота прикладного кода, где я написал yield return — и оно сйилдило мне ретёрн.

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

AVK>Нет, не получается. Задачу я не описывал, я описывал решение. Задача — дать возможность пользователям настраивать механику проводок. Я лично видел целую тучу реализаций подобного в разных системах. Например, пачка параметров по модификации захардкоженного алгоритма проводок. Или вообще единственный способ модификации — изменение 1С-конфигурации и написание кода. Сменяемый пользователем алгоритм формирования ХО как публично видимая сущность — это уже конкретное решение, а не входная задача.
Непонятно. В приведённых трёх случаях разные требования.
В одном случае вообще нет требования выбора разных способов генерации проводок в рантайме.
В другом случае есть один алгоритм с дополнительными параметрами.
В твоём случае есть семейство разных алгоритмов с ручным выбором конкретного.

S>>В таком описании для проектирования достаточно трёх паттернов: Стратегия (она же Policy), Следование (она же Последовательность), и Ничто.
AVK>Поясни мысль.
Поясняю: это базис, из которого можно построить всё остальное. операторы if, приращения, и 0.

S>>А в SQL оно к чему приведёт?
AVK>К таблицам и прочим сущностям sql.
А можно продемонстрировать как-то способ применения паттерна Стратегия в терминах таблиц и прочих сущностей SQL?

AVK>Этот вопрос в топике уже был — на какие нижележащие концепции опирается паттерн Chain of Resposibility? MVC?
На ООП, очевидно. Везде фигурируют объекты, связанные между собой определённым образом, и которым раздаются определённые обязанности.
AVK>Но интереснее другое — как из того, что какой то паттерн опирается на нижележащие концепции следует, что при применении DSL не нужна архитектура? Может хоть ты пояснишь?
При применении DSL код программы совпадает с её архитектурой. Вся идея DSL — избежать разрыва между архитектурой (выраженной в "мысленных конструкциях") и кодом (написанным на далёком от архитектуры языке).
Вот в простых случаях старорежимных консольных С программ нам не нужна была никакая архитектура — придумали функциям имена, параметры, и вызываем их друг из друга. Вся архитектура и есть эти функции.
Если мы начинаем строить какие-то сложные штуки (например, недо-ООП на указателях на функции и структурах указателей) и описывать архитектуру в их терминах, то лучше перейти на язык, где такие штуки есть из коробки.

AVK>А никто тут ничего подобного и не говорит. Если соответствовать приведенному определению паттерна, то "континентальный завтрак" это термин, который нужен чтобы написать его в меню, и клиенты по нему сразу поймут, о чем речь, не вдаваясь в детальное изучение всех ингредиентов и способов их приготовления.
Правильно. И тем не менее, это определённое решение определённой задачи.

AVK>Это определение я взял из википедии. Оно там давно и вполне устаканено. Так что если у тебя притензии к общепринятым определениями — это не ко мне.
Да, у меня к нему претензии. Пойду писать в претензионный отдел википедии.

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

WH>>А что ты понимаешь глядя в библиотеку?
AC>1)Там тот-же ЯП на котором я пишу, а не другой DSL.
AC>2)Там готовые функции/классы, а не генерирующие макросы.
И?

WH>>Придется переписать кодогенерацию. Насколько это сложно зависит от того сколько нужно писать.
WH>>Но зачем? Профит где?
AC>Например: упрощение архитектуры, быстродействие, сокращение количества строк кода, меньший объём тестирования etc.
Всё с точностью до наоборот.
Чем больше расстояние между языками, тем сложнее переписывать.

AC>Т.е. чтобы понять как это работает, мне нужно: 1)изучить все/основные используемые там DSL'и(это ведь они?), 2)перечитать сотни кода, по ходу делая кучу заметок(потому что в моей голове столько кода не поместится). Вместо того чтобы бегло просмотреть несколько диаграмм?
Нет. Тебе нужно только изучить ДСЛи.
Это будет быстрее, чем бегло посмотреть несколько диаграмм, ибо объем информации в диаграммах описывающие низкоуровневое решение будет на порядки больше.
Так что ты устанешь диаграммы пролистывать.

AC>Ещё десятки незнакомого кода. Каким образом написанное там превращается в исполняемый файл?
А зачем тебе это знать? Это не нужные знания.
Тебе нужно знать, что код делает. А не в какой машинный код преобразуется.

AC>Зачем мне строчки кода? Мне нужно знать как это работает, из каких частей состоит. Тогда я смогу оценить какие из частей критические, как это можно изменить чтобы эти части было возможно переписать на Си etc.
Там нет ни строчки кода которая будучи переписанной на С разогнала бы результирующую программу.
Я гарантирую это.

WH>>Так на всякий случай там из 190 строк на ДСЛ получается 25380 строк декомпилированного C#. Это в 133 раза больше.
AC>Это ооооочень плохой результат.
Нет. Это очень хороший результат. Я сократил объем работы на два порядка.

AC>Подозреваю там сотни спагетти-кода, которые можно относительно(разработки DSL'а это генерирующего) легко заменить алгоритмами. И получатся те-же 190 строк например на питоне + плюс быстрая библиотека на Си.
Нельзя. Такой подход приведет к 10-100 кратным тормозам.
А учитывая, что я собираюсь делать оптимизации, которые асимптотику улучшают...

Но ты можешь попробовать. Будешь 100500тым, который потерпит неудачу, встав на этот заведомо тупиковый путь.

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

I>>В итоге паттерн перекочевал в макры фремворка.

VD>Можно и так сказать. А можно сказать, что реализация паттерннов автоматизированна макросами.

Паттерн != реализация паттерна.

I>>В ООП он переходит в классы фремворка. В ФП он переходит в функции фремворка. Вероятно эта глубокая разница тебя и смущает ?

VD>Вот это огромное заблуждение. Паттерн на то и паттерн, что он не может перекочевать в библиотеку.

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

VD>Интересно, что иногда то что является паттерном на одном языке просто веселит пользователей другого языка. Например, паттерн "Команад" очень веселит тех кто программирует на языках поддерживающих ФП (в частности ФВП и лямбды в частности).

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

VD>Но это как раз и показывает, что паттерн может быть отлично встроен в язык. Встраивание позволяет забыть о паттерне и оперировать самаим понятием, которое эмулируется паттерном.

Это понятие и есть паттер, а в коде только его реализация.

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

Не я а Wolfhound. Я уже говорил что такое паттерн и почему он появляется еще когда кода нет ни строчки.

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

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

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

VD>Ага — в библиотеках. Жалко только, что большинство современных языков не способны их туда положить. По сему появляется попипаста и много красивых слов об архитектуре и дизайне.

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

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

I>>Передергиваешь в очередной раз. С чего ты взял что текстовые заведомо лучше графических ?

VD>Не важно. Важно, что ты таки принял точку зрения, что для решения сложных задач ДСЛ-и подходят куда лучше чем ЯОН-ы.

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

I>>В некоторых областях текстовые будут лучше, до тех пор пока не появится качественная графическая информация.

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

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

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

I>Ты как то сокрушался на счет качества кода и монолитности компилера Немерле. Продолжай, очень интересно послушать, почему же вам макры не помогли.
По тому что Н1 изначально был написано на языке общего назначения, а не на ДСЛ.
Те там просто не была использована вся мощь макросов.

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

I>Зато давно придумали общение с помощью естетсвнной речи, которая,внезапно!, так же не требует текст.
Ну, да... только она один к одному в него переводится... вот в чем прикол.

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

AC>>Т.е. чтобы понять как это работает, мне нужно: 1)изучить все/основные используемые там DSL'и(это ведь они?), 2)перечитать сотни кода, по ходу делая кучу заметок(потому что в моей голове столько кода не поместится). Вместо того чтобы бегло просмотреть несколько диаграмм?
WH>Нет. Тебе нужно только изучить ДСЛи.

Я чет смотрю, в 99% случав проще, быстрее, надежнее будет написать мульку заново, чем изучать ДСЛ. Это если не считать internal DSL. С этими просто — залез в метод а посмотрел, что к чему. Раз-два и все понятно.

WH>Это будет быстрее, чем бегло посмотреть несколько диаграмм, ибо объем информации в диаграммах описывающие низкоуровневое решение будет на порядки больше.
WH>Так что ты устанешь диаграммы пролистывать.

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

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

I>>Зато давно придумали общение с помощью естетсвнной речи, которая,внезапно!, так же не требует текст.
WH>Ну, да... только она один к одному в него переводится... вот в чем прикол.

Не переводится. Текст не передаёт эмоции, интонацию, паузы и тд и тд. Если добавить позы, жесты и тд, то окажется, что 80% информанции передаётся невербально ? Похоже что ты просто не в курсе этого.

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

I>>Ты как то сокрушался на счет качества кода и монолитности компилера Немерле. Продолжай, очень интересно послушать, почему же вам макры не помогли.
WH>По тому что Н1 изначально был написано на языке общего назначения, а не на ДСЛ.
WH>Те там просто не была использована вся мощь макросов.

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

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

I>Я чет смотрю, в 99% случав проще, быстрее, надежнее будет написать мульку заново, чем изучать ДСЛ. Это если не считать internal DSL. С этими просто — залез в метод а посмотрел, что к чему. Раз-два и все понятно.
И куда ты смотришь? В свое воображение?

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

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

I>>Я чет смотрю, в 99% случав проще, быстрее, надежнее будет написать мульку заново, чем изучать ДСЛ. Это если не считать internal DSL. С этими просто - залез в метод а посмотрел, что к чему. Раз-два и все понятно.
WH>И куда ты смотришь? В свое воображение?

Я выделил.

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

Я просил модель поиска решения задачи, а не построение языка.

Здравствуйте, Jack128, Вы писали:
WH>>>Так на всякий случай там из 190 строк на ДСЛ получается 25380 строк декомпилированного C#. Это в 133 раза больше.
AC>>Это ооооочень плохой результат. Подозреваю там сотни спагетти-кода
J>Естественно там спагетти код. А в чем проблема? Тя ж не коробит, что оптимизирующий компилятор С++ генерит спагетти-код, там почему тебя волнует какой код генерит DSL ??
То ж ассемблер, а то C#, который развернётся ещё в ~X10 строк.

S>Вы поймите, если у вас код размера X, то надо тестировать весь X. Если у вас код размера X порождается компилятором из кода размера x, так что X = R * x, то вам надо тестировать x пользовательского кода плюс код компилятора, размером в Y.
1)Это утверрждение основано на предположении: Xавтогенерированного = Xручнного. Это предположение верно, по вашему мнению?
S>Отсюда получаем неравенство — условие оправданности DSL:
S>x + Y < X
2)Откуда уверенность что не будет так: x + Y > Xр (особенно если транслятор оптимизирующий)?
3)А теперь расширим условие: x -> x', Y -> Y' Xр -> Xр', производные это цена(дизайна + разработка + реализация + (тестирование + отладка) + сопровождение).
Введём ещё добавочную цену новизны языка Z, это когда: после того как новый язык был разработан отлажен и протестирован, во время работы на нём иногда всплывают разные мелкие жуки(которые приходится либо обходить, либо править ЯП), и когда после обновления версии компилятора (которая хорошо прошла тесты), на реальном коде всплываю разные мелкие(а может и крупные) несовместимости с предыдущей версией.
Итак: x' + Y' + Z [<,=,>] Xр' ?

S>Сказки. Я неоднократно общался с распальцованными ассемблерщиками.
S>В реальной жизни они не могут порвать современный компилятор ЯВУ даже в простых сценариях.
Какие-то у вас слабые ассемблерщики, наверно потому что распальцованые
S>Тем не менее, идея остаётся — лучше вложить две недели в отладку алгоритма оптимизации, чем их же в ручную оптимизацию. Которую, к тому же, придётся переписывать, как только поменяются условия задачи.
Не общались ли вы с разработчиками компиляторов ЯВУ, рвущих ассемблерщеков? Сколько сил и средств затрачивается на разработку таких компиляторов?

WH>>>А что ты понимаешь глядя в библиотеку?
AC>>1)Там тот-же ЯП на котором я пишу, а не другой DSL.
AC>>2)Там готовые функции/классы, а не генерирующие макросы.
WH>И?
И я там вряд ли что-то пойму.
WH>>>Придется переписать кодогенерацию. Насколько это сложно зависит от того сколько нужно писать.
WH>>>Но зачем? Профит где?
AC>>Например: упрощение архитектуры, быстродействие, сокращение количества строк кода, меньший объём тестирования etc.
WH>Всё с точностью до наоборот.
WH>Чем больше расстояние между языками, тем сложнее переписывать.
А не, я понял вопрос как "Но зачем переписать кодогенерацию?"
AC>>Т.е. чтобы понять как это работает, мне нужно: 1)изучить все/основные используемые там DSL'и(это ведь они?), 2)перечитать сотни кода, по ходу делая кучу заметок(потому что в моей голове столько кода не поместится). Вместо того чтобы бегло просмотреть несколько диаграмм?
WH>Нет. Тебе нужно только изучить ДСЛи.
Например, у нас есть DSL для предметной области "Написание сообщения"(для форума), включающий возможности управления кареткой, вставки-удаления текста, и собственно отправки. Как его знание поможет мне понять смысл сообщения написанного при помощи этого DSL?
WH>Это будет быстрее, чем бегло посмотреть несколько диаграмм, ибо объем информации в диаграммах описывающие низкоуровневое решение будет на порядки больше.
Обычно диаграммы не описывают низкоуровневые решения(ну разве-что диаграммы алгоритмов). С пол года назад я писал на Sacala'е небольшое приложение, ~600-700 строк, диаграмма для него сотояла из ~15 кубиков, и показвала что за объекты есть в программе и как они взаимодействуют, не более. А недавно я открыл для себя Визуал парадигм, и(как это было с Солид ворком) подумал "блин как я раньше работал без этого", сейчас переношу туда проект.
AC>>Ещё десятки незнакомого кода. Каким образом написанное там превращается в исполняемый файл?
WH>А зачем тебе это знать? Это не нужные знания.
WH>Тебе нужно знать, что код делает. А не в какой машинный код преобразуется.
Я так понял, этот код как раз делает то — что преобразует себя в машинный код(через посредство других DSL'ей)?
WH>>>Так на всякий случай там из 190 строк на ДСЛ получается 25380 строк декомпилированного C#. Это в 133 раза больше.
AC>>Это ооооочень плохой результат.
WH>Нет. Это очень хороший результат. Я сократил объем работы на два порядка.
Т.е. ты утверждаешь что автогенерированые 25380 строк на C#, эквиваленты по возможностям/сложности 25380 строкам на C# написанным руками?

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

AC>И я там вряд ли что-то пойму.
Но в библиотеке то понимаешь.

AC>Например, у нас есть DSL для предметной области "Написание сообщения"(для форума), включающий возможности управления кареткой, вставки-удаления текста, и собственно отправки. Как его знание поможет мне понять смысл сообщения написанного при помощи этого DSL?
У тебя есть язык С. Который может вызывать метода, складывать числа,...
Как это знание помогает тебе понимать что написано на языке С?

AC>Я так понял, этот код как раз делает то — что преобразует себя в машинный код(через посредство других DSL'ей)?
Этот ДСЛ описывает разбор текста.

AC>Т.е. ты утверждаешь что автогенерированые 25380 строк на C#, эквиваленты по возможностям/сложности 25380 строкам на C# написанным руками?
Ага. Ужать его можно только ценой серьезной потери производительности.

В любом случае я не понимаю, почему тебя так беспокоит объем генерируемого кода?