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

VE>А как бы стоило сделать на твой взгляд?
Никак. Языки общего назначения не имеют смысла.
Чем больше изучаю, тем сильнее утверждаюсь в этом мнении.

Вот буквально только что презенташка попалась.
http://suif.stanford.edu/~jwhaley/PLDITutorial.ppt
http://bddbddb.sourceforge.net/index.html
56 страниц сильно оптимизированного кода на жабе (год разработки) против 17 строк на ДСЛ (год разработки компилятора).
ДСЛ работал в 2 раза быстрее. Плюс на этом ДСЛ еще кучу кода, потом понаписали. Как следствие сэкономили десятилетия работы.
Про то, что код на ДСЛ проще понять, поддерживать, развивать и там намного меньше багов я думаю можно даже не заикаться.

А для распространённых задач ДСЛи уже будут написаны.

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

WH>56 страниц сильно оптимизированного кода на жабе (год разработки) против 17 строк на ДСЛ (год разработки компилятора).
WH>ДСЛ работал в 2 раза быстрее. Плюс на этом ДСЛ еще кучу кода, потом понаписали. Как следствие сэкономили десятилетия работы.
Для большинства задач написание DSL не закончится к сроку завершения проекта.
Для большинства задач требуется в разы меньшая квалификация, тем для разработки DSL.

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

WH>Про то, что код на ДСЛ проще понять, поддерживать, развивать и там намного меньше багов я думаю можно даже не заикаться.
А компилятор поддержки не требует?

WH>А для распространённых задач ДСЛи уже будут написаны.
Когда будут? Мне вот срочно dsl для разработки веб-сайтов нужен, с кучей готовых модулей.

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

G>Для большинства задач написание DSL не закончится к сроку завершения проекта.
G>Для большинства задач требуется в разы меньшая квалификация, тем для разработки DSL.
Это означает что задачи типовые.
А для типовых задач будут типовые ДСЛ.
Один из таких типовых ДСЛ SQL. Променяешь его на прямые запросы по физической структуре БД?

G>А компилятор поддержки не требует?
Ты не поверишь, но компилятор поддерживать проще.
Просто по тому, что код компилятора (особенно при использовании правильных ДСЛ) получается намного проще, чем результат.
Один из моих первых компиляторов генерировал по модели квадратичное количество кода и гонял оптимизацию со сложностью O(N^4) от размера модели.
При этом малейшие изменения модели приводили к изменению чуть менее чем всего генерируемого кода.
Руками такое ни написать, ни тем более поддерживать невозможно.

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

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

WH>А для распространённых задач ДСЛи уже будут написаны.

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

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

Х>я вот чот не вдупляю чем твои дсли лучше либы/пекейджа/сборки с набором неймспейсов/классов/функций, специфичных для этого самого domain? тем что у них fancy синтаксис? ололошеньки.
А ты перечитай сообщение, на которое отвечаешь. Оно короткое. Там все написано. С цифрами, между прочим.
И это далеко не единичный случай.

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

WH>А ты перечитай сообщение, на которое отвечаешь. Оно короткое. Там все написано. С цифрами, между прочим.
WH>И это далеко не единичный случай.

А ещё есть куда большее количество случаев когда один и тот же функционал на одном и том же языке написан разными людьми/командами с разительными различиями в плане отношения затрат к результату, только мне и это не интересно. Мне интересно именно то что я у тебя спросил. Циферьки оставь эффективным менеджерам.

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

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

G>>Для большинства задач написание DSL не закончится к сроку завершения проекта.
G>>Для большинства задач требуется в разы меньшая квалификация, тем для разработки DSL.
WH>Это означает что задачи типовые.
WH>А для типовых задач будут типовые ДСЛ.
В бизнесе чуть ли не все задачи типовые, но вот dsl для них не придумали.
Когда будут?

WH>Один из таких типовых ДСЛ SQL. Променяешь его на прямые запросы по физической структуре БД?
Что-то этот типовой DSL во многих случаях превратился в полноценный ЯП. Есть даже тенденция создания DSL, который превращается в SQL.

G>>А компилятор поддержки не требует?
WH>Ты не поверишь, но компилятор поддерживать проще.
WH>Просто по тому, что код компилятора (особенно при использовании правильных ДСЛ) получается намного проще, чем результат.
WH>Один из моих первых компиляторов генерировал по модели квадратичное количество кода и гонял оптимизацию со сложностью O(N^4) от размера модели.
WH>При этом малейшие изменения модели приводили к изменению чуть менее чем всего генерируемого кода.
WH>Руками такое ни написать, ни тем более поддерживать невозможно.
WH>И не надо мне втирать, что у меня проект уникальный. Люди просто не видят альтернатив и колбасят код руками.

Давай детали. Что за проект. Какой DSL? Что генерил?

DSL еще написать надо, это сложно. Средний уровень программистов постоянно понижается. Количество людей, способных написать dsl сейчас чуть ли не меньше, чем 10 лет назад.

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

G>В бизнесе чуть ли не все задачи типовые, но вот dsl для них не придумали.
G>Когда будут?
Когда этим кто-нибудь займется. Твой КО.

G>Что-то этот типовой DSL во многих случаях превратился в полноценный ЯП. Есть даже тенденция создания DSL, который превращается в SQL.
Просто его плохо спроектировали.
Но ответь на вопрос: Променяешь его на прямые запросы по физической структуре БД?

G>Давай детали. Что за проект. Какой DSL? Что генерил?
Да это не важно. Или ты думаешь, что сможешь придумать способ написать это на обычном языке?
Я тебе и так скажу что это возможно. Но придётся руками надолбить квадратичное количество кода и прогнать в уме алгоритм четвертой степени.
Я на это не способен. Те "программисты", к которым ты постоянно апеллируешь тем более.
Паттерны и прочая хрень тоже не помогут.

G>DSL еще написать надо, это сложно. Средний уровень программистов постоянно понижается. Количество людей, способных написать dsl сейчас чуть ли не меньше, чем 10 лет назад.
Это происходит из-за того что используются лопаты вместо роторных экскаваторов.
Если пересесть на роторные экскаваторы, то вся эта толпа исчезнет за ненадобностью. И средний уровень очень сильно повысится.
Также нужно понимать, что создание ДСЛ это работа архитектора. Ибо создание ДСЛ == создание архитектуры.

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

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

G>>В бизнесе чуть ли не все задачи типовые, но вот dsl для них не придумали.
G>>Когда будут?
WH>Когда этим кто-нибудь займется. Твой КО.
Так почему до сих пор не занялись? Бинес-задачи меняются мало, а кроме SQL пока ниче не придумано.
В чем проблема?

G>>Что-то этот типовой DSL во многих случаях превратился в полноценный ЯП. Есть даже тенденция создания DSL, который превращается в SQL.
WH>Просто его плохо спроектировали.
Почему?

WH>Но ответь на вопрос: Променяешь его на прямые запросы по физической структуре БД?
Это технически невозможно, сервер на другом компе стоит, порты закрыты.

G>>Давай детали. Что за проект. Какой DSL? Что генерил?
WH>Да это не важно. Или ты думаешь, что сможешь придумать способ написать это на обычном языке?
WH>Я тебе и так скажу что это возможно. Но придётся руками надолбить квадратичное количество кода и прогнать в уме алгоритм четвертой степени.
WH>Я на это не способен. Те "программисты", к которым ты постоянно апеллируешь тем более.
WH>Паттерны и прочая хрень тоже не помогут.

Не уходи от ответа.
1) Что за проект?
2) Какой DSL? (на чем сделан, какие возоможности)
3) Что генерил в итоге?

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


G>>DSL еще написать надо, это сложно. Средний уровень программистов постоянно понижается. Количество людей, способных написать dsl сейчас чуть ли не меньше, чем 10 лет назад.
WH>Это происходит из-за того что используются лопаты вместо роторных экскаваторов.
WH>Если пересесть на роторные экскаваторы, то вся эта толпа исчезнет за ненадобностью. И средний уровень очень сильно повысится.
WH>Также нужно понимать, что создание ДСЛ это работа архитектора. Ибо создание ДСЛ == создание архитектуры.
Аналогии идут лесом. Покажи реальный пример в реальном (не академическом) проекте.

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

G>Так почему до сих пор не занялись? Бинес-задачи меняются мало, а кроме SQL пока ниче не придумано.
G>В чем проблема?
В том, что бизнес задачами занимаются люди, которые дальше языков общего назначения ничего не видят.
Вот ты, например даже не задумаешься о том, что можно сделать ДСЛ.
И в институтах этому не учат. И вообще распространяют миф, что это что-то очень сложное.

WH>>Просто его плохо спроектировали.
G>Почему?
А почему программы плохо проектируют?
В данном случае неверные требования (чтобы любая кухарка писать могла) и недостаток знаний.
Причем недостаток знаний фундаментальная проблема. Ибо часто пока не сделаешь хоть что-то, не поймёшь что действительно нужно.

WH>>Но ответь на вопрос: Променяешь его на прямые запросы по физической структуре БД?
G>Это технически невозможно, сервер на другом компе стоит, порты закрыты.
И это человек обвиняет меня в уходе от вопросов.
Если для дела нужно открыть порт, то он будет открыт.
Ответь на вопрос.

G>Не уходи от ответа.
G>1) Что за проект?
Обработка изображений.

G>2) Какой DSL? (на чем сделан, какие возоможности)
Простой. Сделан на С++.

G>3) Что генерил в итоге?
Кучу кода по трансформации цветовых пространств.
Есть два десятка цветовых пространств и нужно сгенерировать код по трансформации из каждого в каждое.
Вперед. Покажи, как паттерны решат эту задачу.

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

G>Иначе просто нет оснований тебе верить.
Аргументов нет. Пошли наезды...
Слив сразу засчитываем?

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

G>Аналогии идут лесом.
Это не аналогия. Это иллюстрация.
А доказательств и без нее достаточно. Просто нужно перестать действовать по принципу если факты противоречат теории тем хуже для фактов.

G>Покажи реальный пример в реальном (не академическом) проекте.
Критерий реальности в студию.

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

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

G>>Так почему до сих пор не занялись? Бинес-задачи меняются мало, а кроме SQL пока ниче не придумано.
G>>В чем проблема?
WH>В том, что бизнес задачами занимаются люди, которые дальше языков общего назначения ничего не видят.
WH>Вот ты, например даже не задумаешься о том, что можно сделать ДСЛ.
WH>И в институтах этому не учат. И вообще распространяют миф, что это что-то очень сложное.
У меня как раз был курс построения языков и мы там dsl рассматривали. Именно оттуда я выяснил что это сложная тема.
Ты считаешь по-другому, можешь обосновать? Желательно с примерами?

WH>>>Но ответь на вопрос: Променяешь его на прямые запросы по физической структуре БД?
G>>Это технически невозможно, сервер на другом компе стоит, порты закрыты.
WH>И это человек обвиняет меня в уходе от вопросов.
WH>Если для дела нужно открыть порт, то он будет открыт.
WH>Ответь на вопрос.
не буду, а зачем ? SQL уже есть, если бы не было, то был бы вопрос — писать dsl или писать код.

G>>Не уходи от ответа.
G>>1) Что за проект?
WH>Обработка изображений.

G>>2) Какой DSL? (на чем сделан, какие возоможности)
WH>Простой. Сделан на С++.
Больше деталей, что на входе, что на выходе?
Сколько строк исходников?

G>>3) Что генерил в итоге?
WH>Кучу кода по трансформации цветовых пространств.
WH>Есть два десятка цветовых пространств и нужно сгенерировать код по трансформации из каждого в каждое.
WH>Вперед. Покажи, как паттерны решат эту задачу.
Понятия не имею что такое цветовые пространства.

G>>Иначе просто нет оснований тебе верить.
WH>Аргументов нет. Пошли наезды...
WH>Слив сразу засчитываем?
Ты еще не все рассказал.

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


G>>То что ты дас ссылку на академический проект не является подтверждением твоего мнения.
WH> Ага, конечно. Кто бы сомневался.
WH>Что еще придумаешь, чтобы проигнорировать факты?
Ты еще не привел фактов, которые подтверждают твое мнение.

G>>Аналогии идут лесом.
WH>Это не аналогия. Это иллюстрация.
Это аналогия.

G>>Покажи реальный пример в реальном (не академическом) проекте.
WH>Критерий реальности в студию.
Ограниченный срок и ресурсы, реальный value.

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

G>У меня как раз был курс построения языков и мы там dsl рассматривали. Именно оттуда я выяснил что это сложная тема.
G>Ты считаешь по-другому, можешь обосновать?
1)В институте плохому учат. У них там все действительно сложнее, чем надо получается.
2)Сложность рукопашного кода всё равно больше. Чем сложность компилятора.

G>Желательно с примерами?
Примерами чего? Насколько проще могут быть парсеры по сравнению с классическими подходами?
https://github.com/rampelstinskin/ParserGenerator
И это еще ранний этап разработки.
К нему еще декларативный типизатор будет приделан.
Так что создание языков станет вообще детской игрой.

G>не буду, а зачем ?
Те с тем что ДСЛ решает задачу лучше ты согласен.

G>SQL уже есть, если бы не было, то был бы вопрос — писать dsl или писать код.
У тебя бы не было. Ты про это даже бы не задумался.
Ибо если бы ты мог об этом задуматься то ты бы сейчас не пытался найти любую зацепку для того чтобы показать что я не прав.

G>Больше деталей, что на входе, что на выходе?
G>Сколько строк исходников?
Что это поменяет? Сотни связей и тысячи вариантов решения никуда не денутся.
Первый раз я написал это руками (с кучей ошибок). После изменения модели понял что руками я еще один такой подвиг не совершу (да и блох ловить надоело).
Написал компилятор и все сразу заработало. Потом еще раз 10 модель менял. И в результирующем коде ошибок больше не было.
Более того алгоритм отыскал такие решения которые мне и в голову не приходили.

G>Понятия не имею что такое цветовые пространства.
В гугле забанили? http://en.wikipedia.org/wiki/Color_space
Но в реальности там все куда сложнее, чем написано в википедии.

G>Я пока вижу что ты написал генератор кода по каким-то исходным данным.
Под это определение попадают _все_ компиляторы.

G>Ну таких генераторов и сейчас немеряно, только бизнес-задачи они не решают, в основном утилитарный код генерят.
Это ты от недостатка кругозора так говоришь.

G>Причем код как раз на языке общего назначения.
В качестве ассемблера они обычно весьма не плохи. Хотя тоже проблемы возникают. Например зачем мне проверки выхода за приделы массива если я и так знаю что генерируемый код за приделы массива никогда не полезет? Да и соглашения о вызовах обычно весьма гадкие и тормозные.

G>Ты еще не привел фактов, которые подтверждают твое мнение.
Это как? 17 строк против 56 страниц это не факт?
А ведь я могу еще показать что мой генератор парсеров генерирует по простому ДСЛ.
И что характерно руками получится не намного меньше кода.
Если пошарить по интернету можно еще кучу примеров найти.
Но ты же на все скажешь, что это все академизм или еще какую отмазку придумаешь.

G>Ограниченный срок и ресурсы, реальный value.
BLToolKit подойдет? Если мне не изменяет склероз, начинался он как раз как часть конкретного проекта. Ибо IT'у надоело писать руками маппинг объектов.

И да BLT это ДСЛ. Причем компилируемый.

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

WH>Это происходит из-за того что используются лопаты вместо роторных экскаваторов.
WH>Если пересесть на роторные экскаваторы, то вся эта толпа исчезнет за ненадобностью. И средний уровень очень сильно повысится.
WH>Также нужно понимать, что создание ДСЛ это работа архитектора. Ибо создание ДСЛ == создание архитектуры.

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

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

WH>>>Просто его плохо спроектировали.
G>>Почему?
WH>А почему программы плохо проектируют?
WH>В данном случае неверные требования (чтобы любая кухарка писать могла) и недостаток знаний.
WH>Причем недостаток знаний фундаментальная проблема. Ибо часто пока не сделаешь хоть что-то, не поймёшь что действительно нужно.

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

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

VE>Это происходит из-за того, что 10 экскалаторов сделают меньше, чем 10 же эскалаторов и ещё 1000 лопат.
VE>Поэтому есть потребность занять даже клинических идиотов, лишь бы приносило прибыль.
VE>Поэтому для одних есть сложные инструменты, и их это устраивает, а для других инструменты попроще, и их тоже это устраивает.
Те, которые попроще могут приносить прибыль то в аутсорсе когда заказчик платит за человеко-часы. Если же оплата идет за результат то те, которые попроще это одни убытки.

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

VE>Рассматривать программирование в отрыве от людей, им занимающимся, это надо оригинальное видение реальности иметь.
Этим как раз занимались авторы SQL.
Они считали, что программы может писать любая кухарка.
Практика показала, что не может.
Более того попытки сделать язык для кухарок привели к тому что им стало трудно пользоваться профессионалам.

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

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

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

G>>>В бизнесе чуть ли не все задачи типовые, но вот dsl для них не придумали.
G>>>Когда будут?
WH>>Когда этим кто-нибудь займется. Твой КО.
G>Так почему до сих пор не занялись? Бинес-задачи меняются мало, а кроме SQL пока ниче не придумано.
G>В чем проблема?

Да нет никаких проблем. Вот, например, уже как более чем 10 лет как есть отличный DSL под названием "1С: Предприятие".

Только что-то мне подсказывает, что он Wolfhound-у ой как не понравится . А почему, спрашивается? Воистину, чужая душа потемки.

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

Х>>я вот чот не вдупляю чем твои дсли лучше либы/пекейджа/сборки с набором неймспейсов/классов/функций, специфичных для этого самого domain? тем что у них fancy синтаксис? ололошеньки.
WH>А ты перечитай сообщение, на которое отвечаешь. Оно короткое. Там все написано. С цифрами, между прочим.

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

WH>И это далеко не единичный случай.

А вот в этом ты прав .

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

G>Ага. Но вот беда — в нем нет ответа на вполне конкретный вопрос, который тебе только что товарищ задал. Ты перечитай сообщение, на которое отвечаешь.
Ну, то есть, то, что нужно написать в несколько десятков раз меньше кода это не преимущество?
Я тебя правильно понял?

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

G>Да нет никаких проблем. Вот, например, уже как более чем 10 лет как есть отличный DSL под названием "1С: Предприятие".
Остается выяснить в каком месте этот язык ДСЛ?
Я его очень давно не видел, но по воспоминаниям это язык общего назначения.
Причем очень плохо сделанный.