Языки общего назначения не имеют смысла!
От: WolfHound  
Дата: 06.04.12 20:52
Оценка: 17 (4) +1 -3 :))) :))) :))) :)
Здравствуйте, VoidEx, Вы писали:

VE>А как бы стоило сделать на твой взгляд?

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

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

А для распространённых задач ДСЛи уже будут написаны.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

08.04.12 17:44: Ветка выделена из темы Golang &mdash; вышел первый стабильный релиз.
Автор: FR
Дата: 29.03.12
— WolfHound
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re: Языки общего назначения не имеют смысла!
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 07.04.12 17:12
Оценка: +4
Здравствуйте, WolfHound, Вы писали:

WH>56 страниц сильно оптимизированного кода на жабе (год разработки) против 17 строк на ДСЛ (год разработки компилятора).

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

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

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

А компилятор поддержки не требует?

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

Когда будут? Мне вот срочно dsl для разработки веб-сайтов нужен, с кучей готовых модулей.
Re[2]: Языки общего назначения не имеют смысла!
От: WolfHound  
Дата: 07.04.12 17:59
Оценка: 4 (1)
Здравствуйте, gandjustas, Вы писали:

G>Для большинства задач написание DSL не закончится к сроку завершения проекта.

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

G>А компилятор поддержки не требует?

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

И не надо мне втирать, что у меня проект уникальный. Люди просто не видят альтернатив и колбасят код руками.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re: Языки общего назначения не имеют смысла!
От: Хвост  
Дата: 07.04.12 21:20
Оценка: -1
Здравствуйте, WolfHound, Вы писали:

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


я вот чот не вдупляю чем твои дсли лучше либы/пекейджа/сборки с набором неймспейсов/классов/функций, специфичных для этого самого domain? тем что у них fancy синтаксис? ололошеньки.
People write code, programming languages don't.
Re[2]: Языки общего назначения не имеют смысла!
От: WolfHound  
Дата: 07.04.12 21:51
Оценка: :)
Здравствуйте, Хвост, Вы писали:

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

А ты перечитай сообщение, на которое отвечаешь. Оно короткое. Там все написано. С цифрами, между прочим.
И это далеко не единичный случай.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: Языки общего назначения не имеют смысла!
От: Хвост  
Дата: 08.04.12 00:03
Оценка: :)
Здравствуйте, WolfHound, Вы писали:

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

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

А ещё есть куда большее количество случаев когда один и тот же функционал на одном и том же языке написан разными людьми/командами с разительными различиями в плане отношения затрат к результату, только мне и это не интересно. Мне интересно именно то что я у тебя спросил. Циферьки оставь эффективным менеджерам.
People write code, programming languages don't.
Re[3]: Языки общего назначения не имеют смысла!
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 08.04.12 06:42
Оценка:
Здравствуйте, 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 лет назад.
Re[4]: Языки общего назначения не имеют смысла!
От: WolfHound  
Дата: 08.04.12 09:51
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>В бизнесе чуть ли не все задачи типовые, но вот dsl для них не придумали.

G>Когда будут?
Когда этим кто-нибудь займется. Твой КО.

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

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

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

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

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

Это происходит из-за того что используются лопаты вместо роторных экскаваторов.
Если пересесть на роторные экскаваторы, то вся эта толпа исчезнет за ненадобностью. И средний уровень очень сильно повысится.
Также нужно понимать, что создание ДСЛ это работа архитектора. Ибо создание ДСЛ == создание архитектуры.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[5]: Языки общего назначения не имеют смысла!
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 08.04.12 10:44
Оценка:
Здравствуйте, 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>Также нужно понимать, что создание ДСЛ это работа архитектора. Ибо создание ДСЛ == создание архитектуры.
Аналогии идут лесом. Покажи реальный пример в реальном (не академическом) проекте.
Re[6]: Языки общего назначения не имеют смысла!
От: WolfHound  
Дата: 08.04.12 11:18
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Так почему до сих пор не занялись? Бинес-задачи меняются мало, а кроме SQL пока ниче не придумано.

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

WH>>Просто его плохо спроектировали.

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

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

G>Это технически невозможно, сервер на другом компе стоит, порты закрыты.
И это человек обвиняет меня в уходе от вопросов.
Если для дела нужно открыть порт, то он будет открыт.
Ответь на вопрос.

G>Не уходи от ответа.

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

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

Простой. Сделан на С++.

G>3) Что генерил в итоге?

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

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

G>Иначе просто нет оснований тебе верить.

Аргументов нет. Пошли наезды...
Слив сразу засчитываем?

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

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

G>Аналогии идут лесом.

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

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

Критерий реальности в студию.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[7]: Языки общего назначения не имеют смысла!
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 08.04.12 11:30
Оценка: :))
Здравствуйте, 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.
Re[8]: Языки общего назначения не имеют смысла!
От: WolfHound  
Дата: 08.04.12 12:19
Оценка: +1
Здравствуйте, 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 это ДСЛ. Причем компилируемый.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[5]: Языки общего назначения не имеют смысла!
От: VoidEx  
Дата: 08.04.12 13:12
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Это происходит из-за того что используются лопаты вместо роторных экскаваторов.

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

Это происходит из-за того, что 10 экскалаторов сделают меньше, чем 10 же эскалаторов и ещё 1000 лопат.
Поэтому есть потребность занять даже клинических идиотов, лишь бы приносило прибыль.
Поэтому для одних есть сложные инструменты, и их это устраивает, а для других инструменты попроще, и их тоже это устраивает.
Re[7]: Языки общего назначения не имеют смысла!
От: VoidEx  
Дата: 08.04.12 13:14
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>>>Просто его плохо спроектировали.

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

Рассматривать программирование в отрыве от людей, им занимающимся, это надо оригинальное видение реальности иметь.
А как ты думаешь, почему хотят, чтобы любая кухарка могла писать? Почему недостаточно знаний? Потому что, кхм, люди дураки?
Так ваш инструмент, вот сюрприз, людей умнее не сделает.
Re[6]: Языки общего назначения не имеют смысла!
От: WolfHound  
Дата: 08.04.12 13:34
Оценка:
Здравствуйте, VoidEx, Вы писали:

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

VE>Поэтому есть потребность занять даже клинических идиотов, лишь бы приносило прибыль.
VE>Поэтому для одних есть сложные инструменты, и их это устраивает, а для других инструменты попроще, и их тоже это устраивает.
Те, которые попроще могут приносить прибыль то в аутсорсе когда заказчик платит за человеко-часы. Если же оплата идет за результат то те, которые попроще это одни убытки.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[8]: Языки общего назначения не имеют смысла!
От: WolfHound  
Дата: 08.04.12 13:43
Оценка:
Здравствуйте, VoidEx, Вы писали:

VE>Рассматривать программирование в отрыве от людей, им занимающимся, это надо оригинальное видение реальности иметь.

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

VE>А как ты думаешь, почему хотят, чтобы любая кухарка могла писать? Почему недостаточно знаний? Потому что, кхм, люди дураки?

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

VE>Так ваш инструмент, вот сюрприз, людей умнее не сделает.

Я в курсе. Но он сильно упростит жизнь умным людям. Ничего другого я и не добиваюсь.
Ибо прекрасно знаю, что кухарка всё равно программы писать не сможет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: Языки общего назначения не имеют смысла!
От: Gaperton http://gaperton.livejournal.com
Дата: 08.04.12 14:01
Оценка: +4
Здравствуйте, gandjustas, Вы писали:

G>>>В бизнесе чуть ли не все задачи типовые, но вот dsl для них не придумали.

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

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

Только что-то мне подсказывает, что он Wolfhound-у ой как не понравится . А почему, спрашивается? Воистину, чужая душа потемки.
Re[3]: Языки общего назначения не имеют смысла!
От: Gaperton http://gaperton.livejournal.com
Дата: 08.04.12 14:03
Оценка:
Здравствуйте, WolfHound, Вы писали:

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

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

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

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


А вот в этом ты прав .
Re[4]: Языки общего назначения не имеют смысла!
От: WolfHound  
Дата: 08.04.12 14:28
Оценка:
Здравствуйте, Gaperton, Вы писали:

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

Ну, то есть, то, что нужно написать в несколько десятков раз меньше кода это не преимущество?
Я тебя правильно понял?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[7]: Языки общего назначения не имеют смысла!
От: WolfHound  
Дата: 08.04.12 14:28
Оценка: 1 (1)
Здравствуйте, Gaperton, Вы писали:

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

Остается выяснить в каком месте этот язык ДСЛ?
Я его очень давно не видел, но по воспоминаниям это язык общего назначения.
Причем очень плохо сделанный.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[5]: Языки общего назначения не имеют смысла!
От: Vain Россия google.ru
Дата: 08.04.12 14:35
Оценка:
Здравствуйте, WolfHound, Вы писали:

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

WH>Ну, то есть, то, что нужно написать в несколько десятков раз меньше кода это не преимущество?
А ДСЛ кто писать и поддерживать будет? И главное много этих щас дсл писателей, что взял и заменил? И ты согласен за свой счёт таких учить?
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[6]: Языки общего назначения не имеют смысла!
От: WolfHound  
Дата: 08.04.12 14:52
Оценка:
Здравствуйте, Vain, Вы писали:

V>А ДСЛ кто писать и поддерживать будет?

Архитектор.

V>И главное много этих щас дсл писателей, что взял и заменил? И ты согласен за свой счёт таких учить?

Да запросто. Любой толковый программист осилит за несколько дней, если использовать правильный инструмент. Это намного проще, чем принято думать.
Он в проект дольше въезжать будет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[5]: Языки общего назначения не имеют смысла!
От: Хвост  
Дата: 08.04.12 14:58
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


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

WH>Ну, то есть, то, что нужно написать в несколько десятков раз меньше кода это не преимущество?
WH>Я тебя правильно понял?

вульфхунд, я с тебя пупею. дсл это же не только синтаксис, да? ещё семантика, угу? а семантику ты эту как будешь реализовывать? всё тем же объёмом кода, что и в случае с обычным подходом, или твой суперметагенератор автоматом тебе ещё и логику нагенерит? окстись. На выходе в обычном подходе ты получишь библиотеку, в подходе с дсл — собственно дсл, но разницы в результате окромя синтаксиса не будет совершенно. Я кажись очевидное же толкую, а ты всё упорото мантру свою повторяешь.
People write code, programming languages don't.
Re[6]: Языки общего назначения не имеют смысла!
От: WolfHound  
Дата: 08.04.12 15:29
Оценка: 3 (1)
Здравствуйте, Хвост, Вы писали:

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

Ты несешь очевидный, для любого кто делал ДСЛ, бред.
Библиотека не может повторить возможности ДСЛ просто по тому, что библиотека заточена под конкретный язык с конкретной моделью вычислений. И как следствие не может выйти за приделы возможностей языка, на котором написана. Единственный способ для библиотеки перейти на другую модель вычислений это интерпретатор другой вычислительной модели. Но это уже будет ДСЛ. Кривой. Тормозной. Многословный. ДСЛ!
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re: Языки общего назначения не имеют смысла!
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 08.04.12 15:29
Оценка: +3
Слова поддержки:
ребята с Software Engineering Radio такой подход пропагандируют уже много лет, они его называют Model Driven Development. DSL там используется как язык описания задачи в подходящих терминах, а вместо "компиляция" они говорят "кодогенерация". Смысл тот же, но не так пугает.

Кстати, Ruby on Rails — хрестоматийный уже пример именно DSLя, в данном случае DSeL (embedded language). Кто тут спрашивал DSL для веба? Забирайте. Еще хрестоматийней — makefile, тоже DSL.

Слова сомнения:
Следует помнить, что подход этот оправдан, когда есть множество похожих задач из одной области. Ведь вместо прямого решения задачи предлагается делать универсальный решатель задач подобного рода. Его сделать сложнее (и дело отнюдь не в парсинге), поэтому чтобы это дело окупилось, нужно решать им не одну задачу, а серию. Если же задача штучная, то смысла в таком подходе не видно, тут языки общего назначения и пригодятся. Так что совсем уж их объявлять бессмысленными не стоит.
Re[2]: Языки общего назначения не имеют смысла!
От: WolfHound  
Дата: 08.04.12 15:51
Оценка: +1
Здравствуйте, D. Mon, Вы писали:

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

Дело в том что практически любое приложение состоит из кучи таких задач.

DM>Его сделать сложнее

Да я бы не сказал.

DM>(и дело отнюдь не в парсинге),

Еще в типизации и кодогенерации.
И то и другое можно сделать очень простым.
Так что сложность будет не больше чем при написании библиотеки.
А чаше даже меньше. Ибо не придется ломать голову над тем как нужную модель вычислений запихнуть в конкретный язык таким образом, чтобы не получить говнокод.
Скажу по секрету: обычно это не получается. И максимум что народу удается, это сделать так чтобы от кода откровенно не тошнило.
В случае с ДСЛ мы можем с чистой совестью генерировать говнокод. Всё равно его никто ни читать, ни тем более править не будет. Все что требуется от генерируемого кода это чтобы он правильно и быстро работал.

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

Только если вычислительная модель задачи совпадает с вычислительной моделью языка. Если же это не происходит, то начинаются проблемы.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: Языки общего назначения не имеют смысла!
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 08.04.12 16:16
Оценка: +1
Здравствуйте, WolfHound, Вы писали:

DM>>Его сделать сложнее

WH>Да я бы не сказал.
DM>>(и дело отнюдь не в парсинге),
WH>Еще в типизации и кодогенерации.

И даже не в них, тем более, что их вообще может не быть (много ли кодогенерирует make?). Дело именно в обобщении задачи, нацеливании на решение не только имеющейся задачи, но и других из той же области. Иначе DSL будет одноразовым и не оправдает себя. Скажем, есть у меня задача посчитать определенную цепочку матричных операций. В ее конкретном случае часть матриц могут быть особенными (диагональными или симметричными или даже единичными), и эффективное решение может быть довольно простым. Если делать для этого DSL, возникнет желание научить его решать и другие похожие задачи с матрицами (ведь кому нужен DSL для одного частного случая), а в общем случае такой халявы с единичной матрицей не будет, нужно придумывать и реализовывать эффективные решения для намного более сложных задач, чем была изначально.

WH>Так что сложность будет не больше чем при написании библиотеки.


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

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

WH>Только если вычислительная модель задачи совпадает с вычислительной моделью языка. Если же это не происходит, то начинаются проблемы.

Возможно. Просто у многих задач не видно их собственной "вычислительной модели", там любая сгодится (что опыт написания похожих задач на очень разных языках и подтверждает). Скажем, возьмем DVCS. Есть довольно успешные решения на Си, Питоне и Хаскеле — git, mercurial, darcs. Есть ли в той задаче особенная вычислительная модель?
Re[3]: Языки общего назначения не имеют смысла!
От: alex_public  
Дата: 08.04.12 16:38
Оценка: +2
Здравствуйте, WolfHound, Вы писали:

WH>Дело в том что практически любое приложение состоит из кучи таких задач.


Ну так тогда у нас "приложения будущего" будут состоять из зоопарка dsl и системного языка, играющего роль клея между ними?

Кстати, вот конкретный пример. Я добавил в проект библиотеку для работы с регулярными выражениями — означает ли это что я добавил новый dsl (пусть и не мною созданный) в проект? )

WH>Только если вычислительная модель задачи совпадает с вычислительной моделью языка. Если же это не происходит, то начинаются проблемы.


А вот есть один интересный примерчик... GUI — в очень многих случаях решается практически одинаковая задача (главное окно, менюшки, тулбары, обработка сообщений и т.п.). T.e. казалось бы тут самое оно создать некий DSL. И где он?

Да, всякие языки размётки контролов не приводить — нам нужна и обработка сообщений и ещё много чего, а не только их расположение.
Re[7]: Языки общего назначения не имеют смысла!
От: Vain Россия google.ru
Дата: 08.04.12 16:41
Оценка:
Здравствуйте, WolfHound, Вы писали:

V>>А ДСЛ кто писать и поддерживать будет?

WH>Архитектор.
А когда его не будет, то кто?

V>>И главное много этих щас дсл писателей, что взял и заменил? И ты согласен за свой счёт таких учить?

WH>Да запросто. Любой толковый программист осилит за несколько дней, если использовать правильный инструмент.
А нахрена когда есть уже готовые специалисты "общего назначения"?
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[4]: Языки общего назначения не имеют смысла!
От: Don Reba Канада https://stackoverflow.com/users/49329/don-reba
Дата: 08.04.12 16:43
Оценка: 1 (1) +1
Здравствуйте, alex_public, Вы писали:

_>А вот есть один интересный примерчик... GUI — в очень многих случаях решается практически одинаковая задача (главное окно, менюшки, тулбары, обработка сообщений и т.п.). T.e. казалось бы тут самое оно создать некий DSL. И где он?


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


Tcl/Tk
Ce n'est que pour vous dire ce que je vous dis.
Re[5]: Языки общего назначения не имеют смысла!
От: alex_public  
Дата: 08.04.12 16:55
Оценка:
Здравствуйте, Don Reba, Вы писали:

DR>Tcl/Tk


Tcl как-то не очень похож на DSL. Это скорее полноценный язык.
Ну и результат с Тк мягко говоря сомнительный...
Re[8]: Языки общего назначения не имеют смысла!
От: WolfHound  
Дата: 08.04.12 17:08
Оценка:
Здравствуйте, Vain, Вы писали:

V>А нахрена когда есть уже готовые специалисты "общего назначения"?

Ответ в первом сообщении темы.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[4]: Языки общего назначения не имеют смысла!
От: WolfHound  
Дата: 08.04.12 17:25
Оценка:
Здравствуйте, D. Mon, Вы писали:

DM>И даже не в них, тем более, что их вообще может не быть (много ли кодогенерирует make?). Дело именно в обобщении задачи, нацеливании на решение не только имеющейся задачи, но и других из той же области. Иначе DSL будет одноразовым и не оправдает себя. Скажем, есть у меня задача посчитать определенную цепочку матричных операций. В ее конкретном случае часть матриц могут быть особенными (диагональными или симметричными или даже единичными), и эффективное решение может быть довольно простым. Если делать для этого DSL, возникнет желание научить его решать и другие похожие задачи с матрицами (ведь кому нужен DSL для одного частного случая), а в общем случае такой халявы с единичной матрицей не будет, нужно придумывать и реализовывать эффективные решения для намного более сложных задач, чем была изначально.

А зачем ты собрался делать больше чем тебе нужно для конкретной задачи?
Прелесть ДСЛ в том, что ты можешь задать универсальный язык для работы с матрицами (это просто) и реализовать его только для той части, которая тебе нужна. Если ты вдруг напишешь что-то, что твоя текущая версия не поддерживает, то просто получишь ошибку компиляции.
Я так не раз поступал.

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

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

DM>Возможно. Просто у многих задач не видно их собственной "вычислительной модели", там любая сгодится (что опыт написания похожих задач на очень разных языках и подтверждает). Скажем, возьмем DVCS. Есть довольно успешные решения на Си, Питоне и Хаскеле — git, mercurial, darcs. Есть ли в той задаче особенная вычислительная модель?

DVCS это интересная тема.
И там на самом деле можно очень легко найти, где можно применить ДСЛ с очень большой отдачей.
Все DVCS это по сути базы данных. Но очень конкретные. Типа как SQL серверы с несколькими фиксированными таблицами.
Но если подумать, то не сложно сделать обобщенную базу данных не уступающую конкретным.
При этом мы сможем в DVCS хранить не только исходники, но и трекер и вики и форум и отчеты continuous integration систем и много чего еще что обычно размазано по куче разных слабо связанных программ. При этом все это будет связано между собой. И можно будет простыми запросами к БД получить информацию обо всех активностях связанных с конкретным коммитом.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[5]: Языки общего назначения не имеют смысла!
От: alex_public  
Дата: 08.04.12 17:30
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>DVCS это интересная тема.

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

Да, fossil почти такой и есть. Внутри использует sqlite.
Re[4]: Языки общего назначения не имеют смысла!
От: WolfHound  
Дата: 08.04.12 17:31
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Ну так тогда у нас "приложения будущего" будут состоять из зоопарка dsl и системного языка, играющего роль клея между ними?

Что там будет клеем не важно. Да и не факт что он вообще понадобится.

_>Кстати, вот конкретный пример. Я добавил в проект библиотеку для работы с регулярными выражениями — означает ли это что я добавил новый dsl (пусть и не мною созданный) в проект? )

Ты добавил текстовый интерпретируемый ДСЛ.

_>А вот есть один интересный примерчик... GUI — в очень многих случаях решается практически одинаковая задача (главное окно, менюшки, тулбары, обработка сообщений и т.п.). T.e. казалось бы тут самое оно создать некий DSL. И где он?

Re[2]: Веб фрэймворк для Nemerle
Автор: WolfHound
Дата: 14.02.11

Re[3]: Веб фрэймворк для Nemerle
Автор: WolfHound
Дата: 15.02.11

Все это можно легко обобщить для произвольного ГУИ.

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

Если у нас есть бинбинг к реактивной view model то не нужно.
Все само заработает.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: Языки общего назначения не имеют смысла!
От: WolfHound  
Дата: 08.04.12 17:33
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Да, fossil почти такой и есть.

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

_>Внутри использует sqlite.

А вот это, честно говоря, весьма сомнительно. Он на больших базах тормозит жутко.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: Языки общего назначения не имеют смысла!
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 08.04.12 17:36
Оценка: +1
Здравствуйте, gandjustas, Вы писали:

G>Так почему до сих пор не занялись? Бинес-задачи меняются мало, а кроме SQL пока ниче не придумано.


Ну почему не придумали? Язык запросов собственный не так уж и редко в корпоративных платформах встречается.
... << RSDN@Home 1.2.0 alpha 5 rev. 27 on Windows 7 6.1.7601.65536>>
AVK Blog
Re: Языки общего назначения не имеют смысла!
От: Abyx Россия  
Дата: 08.04.12 18:07
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Никак. Языки общего назначения не имеют смысла.

WH>Чем больше изучаю, тем сильнее утверждаюсь в этом мнении.

давайте разберем такой проект — надо написать IM клиент, например для jabber'а
допустим у нас нет готовой библиотеки и мы пишем его с нуля
у него есть UI, несколько слоев сетевого кода, куча мелких модулей типа конфига и т.п.
где там можно применить DSL?

или возьмем пример побольше — браузер, типа firefox или chrome.
как дсл поможет при разработке браузера?

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


я также хочу заметить, что цикл отладки-правки автогенерированного кода — это очень непростое занятие, даже если речь идет об обычных макросах C (#define)
а написание source-level отладчика для DSL — это что-то не очень-то реальное, IMO
In Zen We Trust
Re[2]: Языки общего назначения не имеют смысла!
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 08.04.12 18:17
Оценка:
Здравствуйте, Abyx, Вы писали:

WH>>Никак. Языки общего назначения не имеют смысла.

WH>>Чем больше изучаю, тем сильнее утверждаюсь в этом мнении.

A>давайте разберем такой проект — надо написать IM клиент, например для jabber'а

A>допустим у нас нет готовой библиотеки и мы пишем его с нуля
A>у него есть UI, несколько слоев сетевого кода, куча мелких модулей типа конфига и т.п.
A>где там можно применить DSL?

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

A>или возьмем пример побольше — браузер, типа firefox или chrome.

A>как дсл поможет при разработке браузера?

Вы эта... намеренно подставляетесь? Погуглите, что такое XUL.

A>я это к тому, что у многих задач нет одного большого domain'а,

A>а есть много подзадач у каждой из которых свой domain, никак не связанный с остальными,
A>и написание десятка DSL никак не поможет.

Поможет.
Вообще-то конфиг это уже DSL. Только маленький, не вырос ещё.

A>я также хочу заметить, что цикл отладки-правки автогенерированного кода — это очень непростое занятие, даже если речь идет об обычных макросах C (#define)

A>а написание source-level отладчика для DSL — это что-то не очень-то реальное, IMO

Термин "отладчик" обычно относится к тьюринг-полным языкам. Что от DSL не всегда требуется.
The God is real, unless declared integer.
Re[3]: Языки общего назначения не имеют смысла!
От: Abyx Россия  
Дата: 08.04.12 18:31
Оценка:
Здравствуйте, netch80, Вы писали:

A>>давайте разберем такой проект — надо написать IM клиент, например для jabber'а

A>>где там можно применить DSL?

N>Описание стандартных реакций и нестандартных реакций


конечный автомат? тут конечно DSL может помочь

A>>или возьмем пример побольше — браузер, типа firefox или chrome.

A>>как дсл поможет при разработке браузера?

N>Погуглите, что такое XUL.


Я в курсе что такое XUL, только вот он ни как не связан с "языками общего назначения".
Мы же не обсуждаем "ЯП vs языки разметки", мы обсуждаем "ЯП vs ЯП"

A>>я это к тому, что у многих задач нет одного большого domain'а,

A>>а есть много подзадач у каждой из которых свой domain, никак не связанный с остальными,
A>>и написание десятка DSL никак не поможет.

N>Поможет.

N>Вообще-то конфиг это уже DSL. Только маленький, не вырос ещё.

Lua тоже когда-то был "просто DSL для конфига"

A>>я также хочу заметить, что цикл отладки-правки автогенерированного кода — это очень непростое занятие, даже если речь идет об обычных макросах C (#define)

A>>а написание source-level отладчика для DSL — это что-то не очень-то реальное, IMO

N>Термин "отладчик" обычно относится к тьюринг-полным языкам. Что от DSL не всегда требуется.


"debugger", ага. "bugs" наверное тоже относятся только к тьюринг-полным языкам.
In Zen We Trust
Re: Языки общего назначения не имеют смысла!
От: Буравчик Россия  
Дата: 08.04.12 18:55
Оценка: +1
Здравствуйте, WolfHound, Вы писали:

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


Я тоже за DSL. Но и с DSL тоже куча (пока) нерешенных проблем.

Одна из них — взаимодействие между языками. Как передавать данные из одного языка в другой? Взять ту же связку "язык общего назначения (ЯОН) — SQL". Сколько напридумывали вариантов передачи данных из ЯОН в SQL — и в компилятор встраивали, и формировали текст SQL в программе и передача параметров в хранимые процедуры. Аналогично и с превращением данных из SQL в данные ЯОН — всякие ридеры, датасеты и т.п. В итоге удобным вариантом оказался что-то типа LINQ, т.е. с одной стороны DSL, а работа все в том же ЯОН. Т.е. по сути получилась та же библиотека.

Про взаимодействие двух DSL я вообще молчу. Пример, есть регэкспы и SQL. Хочу регэкспы использовать в SQL. Как их скрестить используя уже созданные наработки?

Нужна какая-то база (стандарты) для обмена информацией между языками. И речь идет не только о самих данных, но и, возможно, об их семантике. К сожалению, работ по этой теме (пока) что-то совсем не видно.
... << RSDN@Home (RF) 1.2.0 alpha 5 rev. 17>>
Best regards, Буравчик
Re[7]: Языки общего назначения не имеют смысла!
От: Хвост  
Дата: 08.04.12 19:09
Оценка: :)
Здравствуйте, WolfHound, Вы писали:

WH>Ты несешь очевидный, для любого кто делал ДСЛ, бред.

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

и как, много ты уже моделей видел на практике? их по сути три: абстрактная машина, реляционная модель, редко но метко лямбда-исчисления. совсем редко всякий экстрим вроде пролога можно не рассматривать. Так вот, для покрывания подавляющей потребности в твоих дслях с моделями вычислений достаточно взять гибридный язык с поддержкой рефлексивной метаинформации рантаймом, например скалу или фшарп и усё, все модели как на ладони. ДСЛ не нужен!
People write code, programming languages don't.
Re[9]: Языки общего назначения не имеют смысла!
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 08.04.12 19:15
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


G>>У меня как раз был курс построения языков и мы там dsl рассматривали. Именно оттуда я выяснил что это сложная тема.

G>>Ты считаешь по-другому, можешь обосновать?
WH>1)В институте плохому учат. У них там все действительно сложнее, чем надо получается.
А где учат хорошему?

WH>2)Сложность рукопашного кода всё равно больше. Чем сложность компилятора.

Практика показывает обратное. Более-менее сложный компилятор сделать под силу единицам.

G>>Желательно с примерами?

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

WH>К нему еще декларативный типизатор будет приделан.

WH>Так что создание языков станет вообще детской игрой.
Что-то слишком много будущего времени.

G>>не буду, а зачем ?

WH>Те с тем что ДСЛ решает задачу лучше ты согласен.
Да, я никогда по-другому не говорил.


G>>Больше деталей, что на входе, что на выходе?

G>>Сколько строк исходников?
WH>Что это поменяет? Сотни связей и тысячи вариантов решения никуда не денутся.
Ну еще не факт что их нельзя обобщить.
Вот я и спрашиваю, сколько строк кода, что принимает на вход и что получается на выходе.

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

WH>Под это определение попадают _все_ компиляторы.
Я имею ввиду генератор текста программы по структурированным данным. Это как-бы проще, чем полноценный компилятор из текста в байт-код или конкретные операции.

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

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

G>>Причем код как раз на языке общего назначения.

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

G>>Ты еще не привел фактов, которые подтверждают твое мнение.

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

G>>Ограниченный срок и ресурсы, реальный value.

WH>BLToolKit подойдет? Если мне не изменяет склероз, начинался он как раз как часть конкретного проекта. Ибо IT'у надоело писать руками маппинг объектов.
А где там DSL? В маппинге объектов как раз нету. А IQueryable провайдер как раз подтверждает то что писать DSL на порядок сложнее, чем непосредственно решающий задачу код.
Причем IQueryable провайдер это только часть сложности работы с БД. Потому что сам язык IQueryable запросов уже есть, а саму работу с данными берет на себя SQL.

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

Буква L в DSL обозначает язык. Ты какой язык имеешь ввиду?
Re[7]: Языки общего назначения не имеют смысла!
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 08.04.12 19:17
Оценка: :)
Здравствуйте, AndrewVK, Вы писали:

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


G>>Так почему до сих пор не занялись? Бинес-задачи меняются мало, а кроме SQL пока ниче не придумано.


AVK>Ну почему не придумали? Язык запросов собственный не так уж и редко в корпоративных платформах встречается.

Да, но почти всегда он довольно ущербен и по сути нужен чтобы не дать программисту нарушить целостность платформы.
А язык запросов в том же 1c непосредственно мапится на SQL.
Re[8]: Языки общего назначения не имеют смысла!
От: WolfHound  
Дата: 08.04.12 19:27
Оценка: -1
Здравствуйте, Хвост, Вы писали:

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

Ты даже не представляешь насколько ты смешон.
The principal programming paradigms
Автор: remark
Дата: 05.12.09

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

Но есть и более конкретные языки. Например, этот https://github.com/rampelstinskin/ParserGenerator имеет свою ни на что не похожую модель вычислений. Чтобы ее эмулировать нужно, генерировать кучу кода или написать интерпретатор. И то и другое ДСЛ.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[10]: Языки общего назначения не имеют смысла!
От: WolfHound  
Дата: 08.04.12 19:51
Оценка:
Здравствуйте, gandjustas, Вы писали:

WH>>1)В институте плохому учат. У них там все действительно сложнее, чем надо получается.

G>А где учат хорошему?
Нигде.

WH>>2)Сложность рукопашного кода всё равно больше. Чем сложность компилятора.

G>Практика показывает обратное. Более-менее сложный компилятор сделать под силу единицам.
Я планирую это исправить.

G>А приложения есть? Реальные, которые людям нужны.

Предыдущую версию (которая намного слабее) реально используют.
Эта появилась весьма недавно и находится в очень не стабильной фазе разработки.
Но и ее уже пытаются использовать.

G>Ну еще не факт что их нельзя обобщить.

Факт.

G>Вот я и спрашиваю, сколько строк кода, что принимает на вход и что получается на выходе.

На входе цветовые пространства и несколько трансформаций. На выходе все недостающие трансформации.

G>Я имею ввиду генератор текста программы по структурированным данным. Это как-бы проще, чем полноценный компилятор из текста в байт-код или конкретные операции.

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

G>Я про бизнес разработку говорю. Там DSLи очень узкую и утилитарную функцию выполняет.

Это по тому, что у всех такие же стереотипы как у тебя.
Люди просто не рассматривают ДСЛ в качестве решения.

G>А где там DSL? В маппинге объектов как раз нету.

Маппинг объектов это и есть ДСЛ.

G>А IQueryable провайдер как раз подтверждает то что писать DSL на порядок сложнее, чем непосредственно решающий задачу код.

Это по тому что:
1)Мелкософты сделали ужасное представление.
2)C# для такого не подходит.
Вот погляди на что способен немерле https://github.com/linq2db/linq2db/blob/master/Source/SqlBuilder/Optimizer.n
В какой ужОс это превратится на C# подумай сам.
И это весьма примитивный подход.
В Н2 все будет куда интереснее.

G>Причем IQueryable провайдер это только часть сложности работы с БД. Потому что сам язык IQueryable запросов уже есть, а саму работу с данными берет на себя SQL.

IQueryable всю сложность и создает. А сгенерировать SQL не сложно.

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

G>Буква L в DSL обозначает язык. Ты какой язык имеешь ввиду?
Нужно очень постараться чтобы не заметить там язык.
        [PrimaryKey] public int ParentID;
        [PrimaryKey] public int ChildID;

        [Association(ThisKey = "ParentID", OtherKey = "ParentID")]
        public Parent  Parent;

        [Association(ThisKey = "ParentID", OtherKey = "ParentID", CanBeNull = false)]
        public Parent1 Parent1;

        [Association(ThisKey = "ParentID", OtherKey = "ParentID2", CanBeNull = false)]
        public Parent3 ParentID2;

        [Association(ThisKey = "ParentID, ChildID", OtherKey = "ParentID, ChildID")]
        public List<GrandChild> GrandChildren;

все эти атрибуты никакого отношения к C# не имеют.
Это декларативный язык маппинга.

А еще внутри BLT целый компилятор есть.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[8]: Языки общего назначения не имеют смысла!
От: WolfHound  
Дата: 08.04.12 19:54
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Да, но почти всегда он довольно ущербен и по сути нужен чтобы не дать программисту нарушить целостность платформы.

Это и есть одно из важнейших свойств ДСЛ.
Они не позволяют делать очень большой класс специфичных для предметной области ошибок.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[11]: Языки общего назначения не имеют смысла!
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 08.04.12 20:06
Оценка:
Здравствуйте, WolfHound, Вы писали:

G>>Я про бизнес разработку говорю. Там DSLи очень узкую и утилитарную функцию выполняет.

WH>Это по тому, что у всех такие же стереотипы как у тебя.
WH>Люди просто не рассматривают ДСЛ в качестве решения.
Ага, прямо ты один д'артаньян

G>>А где там DSL? В маппинге объектов как раз нету.

WH>Маппинг объектов это и есть ДСЛ.

А присваивание не DSL?

G>>А IQueryable провайдер как раз подтверждает то что писать DSL на порядок сложнее, чем непосредственно решающий задачу код.

WH>Это по тому что:
WH>1)Мелкософты сделали ужасное представление.
WH>2)C# для такого не подходит.
А какие языки подходят? Что в них должно быть? C++ подходит?

WH>Вот погляди на что способен немерле https://github.com/linq2db/linq2db/blob/master/Source/SqlBuilder/Optimizer.n

WH>В какой ужОс это превратится на C# подумай сам.
WH>И это весьма примитивный подход.
WH>В Н2 все будет куда интереснее.
Кроме pattern-matching ниче особенного нет. Или я не туда смотрю?


G>>Причем IQueryable провайдер это только часть сложности работы с БД. Потому что сам язык IQueryable запросов уже есть, а саму работу с данными берет на себя SQL.

WH>IQueryable всю сложность и создает. А сгенерировать SQL не сложно.
Придумай язык проще и не потеряй в мощности. Только так чтобы он был подмножеством mainstream языка, иначе толку нет.


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

G>>Буква L в DSL обозначает язык. Ты какой язык имеешь ввиду?
WH>Нужно очень постараться чтобы не заметить там язык.
WH>
WH>        [PrimaryKey] public int ParentID;
WH>        [PrimaryKey] public int ChildID;

WH>        [Association(ThisKey = "ParentID", OtherKey = "ParentID")]
WH>        public Parent  Parent;

WH>        [Association(ThisKey = "ParentID", OtherKey = "ParentID", CanBeNull = false)]
WH>        public Parent1 Parent1;

WH>        [Association(ThisKey = "ParentID", OtherKey = "ParentID2", CanBeNull = false)]
WH>        public Parent3 ParentID2;

WH>        [Association(ThisKey = "ParentID, ChildID", OtherKey = "ParentID, ChildID")]
WH>        public List<GrandChild> GrandChildren;
WH>

WH>все эти атрибуты никакого отношения к C# не имеют.
WH>Это декларативный язык маппинга.

Ты сам утверждал что языки общего назначения не имеют смысла и приводишь в пример код на языке общего назначения.
Ты или шляпу сними, или штаны одень.
Re[9]: Языки общего назначения не имеют смысла!
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 08.04.12 20:08
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


G>>Да, но почти всегда он довольно ущербен и по сути нужен чтобы не дать программисту нарушить целостность платформы.

WH>Это и есть одно из важнейших свойств ДСЛ.
WH>Они не позволяют делать очень большой класс специфичных для предметной области ошибок.

Я же и говорю, утилитарная роль. Цель таких DSL не решение бизнес-задач, а решение сторонних задач, которые требуют много кода (иногда довольно тупого).
Роль dsl в решении бизнес-задач ты пока не показал. Это значит твой тезис о ненужности языков общего назначения не имеет реального обоснования.
Re[12]: Языки общего назначения не имеют смысла!
От: WolfHound  
Дата: 08.04.12 20:24
Оценка: +1
Здравствуйте, gandjustas, Вы писали:

WH>>В Н2 все будет куда интереснее.

G>Кроме pattern-matching ниче особенного нет. Или я не туда смотрю?
А что еще нужно для трансформации дерева?
Вся сложность написания LINQ провайдера и состоит в распознавании и трансформации деревьев.
Делать это на C# мягко говоря проблематично.

G>Придумай язык проще и не потеряй в мощности. Только так чтобы он был подмножеством mainstream языка, иначе толку нет.

Лол. Мелкософты встроили в C# ДСЛ для работы с данными.

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

G>Ты или шляпу сними, или штаны одень.
И что C# поймет, что тут написано и сгенерирует маппинг?
Нет. Этим занимается BLT.
А то, что C# позволяет создавать примитивные встроенные ДСЛ это его преимущество перед языками, которые это не могут. Но по сравнению с языками, которые заточены на создание ДСЛ это детский сад.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[10]: Языки общего назначения не имеют смысла!
От: WolfHound  
Дата: 08.04.12 20:26
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Я же и говорю, утилитарная роль. Цель таких DSL не решение бизнес-задач, а решение сторонних задач, которые требуют много кода (иногда довольно тупого).

G>Роль dsl в решении бизнес-задач ты пока не показал. Это значит твой тезис о ненужности языков общего назначения не имеет реального обоснования.
Если язык запросов не решение бизнес-задачи? То я тогда не знаю что такое решение бизнес задачи.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[2]: Языки общего назначения не имеют смысла!
От: WolfHound  
Дата: 08.04.12 20:43
Оценка:
Здравствуйте, Буравчик, Вы писали:

Б>Я тоже за DSL. Но и с DSL тоже куча (пока) нерешенных проблем.

Их нужно просто решать. Ибо если не решать (как тут некоторые предлагают) ничего не получится.

Б>Одна из них — взаимодействие между языками. Как передавать данные из одного языка в другой?

Это правильный вопрос.
И на него довольно трудно сходу ответить.
Но у меня есть мысли.

Б>В итоге удобным вариантом оказался что-то типа LINQ, т.е. с одной стороны DSL, а работа все в том же ЯОН. Т.е. по сути получилась та же библиотека.

Просто мелкософты захардкодили в ЯОН конкретный ДСЛ.
А то что у ДСЛ кроме кодогенерации бывает еще и рантайм это далеко не новость.

Б>Про взаимодействие двух DSL я вообще молчу. Пример, есть регэкспы и SQL. Хочу регэкспы использовать в SQL. Как их скрестить используя уже созданные наработки?

Тут в общем случае все плохо.
Ибо для того чтобы таким образом соединить ДСЛ они должны транслироваться в один язык.
Для SQL и регекспов это вполне возможно. Но для этого SQL сервер должен поддерживать такие фокусы.
Что на самом деле не так уж и сложно.

Б>Нужна какая-то база (стандарты) для обмена информацией между языками. И речь идет не только о самих данных, но и, возможно, об их семантике. К сожалению, работ по этой теме (пока) что-то совсем не видно.

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

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

Ессно компилятор сможет генерировать нужные трансформации только тогда когда они действительно нужны и сильно оптимизировать их. Не генерировать же N^2 трансформаций даже тогда когда они не нужны.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[8]: Языки общего назначения не имеют смысла!
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 08.04.12 21:36
Оценка:
Здравствуйте, gandjustas, Вы писали:

AVK>>Ну почему не придумали? Язык запросов собственный не так уж и редко в корпоративных платформах встречается.

G>Да, но почти всегда он довольно ущербен

Это с чем сравнивать. Как минимум, по мощности он обычно сопоставим с голым SQL, но работает в терминах прикладных метаданных, а не в терминах метаданных БД. Типичный пример — Entity SQL в EF.

G> и по сути нужен чтобы не дать программисту нарушить целостность платформы.


Не только. Он нужен прежде всего чтобы писать запросы, по возможности не вдаваясь в подробности хранения данных в конкретной БД.
... << RSDN@Home 1.2.0 alpha 5 rev. 27 on Windows 7 6.1.7601.65536>>
AVK Blog
Re[5]: Языки общего назначения не имеют смысла!
От: alex_public  
Дата: 08.04.12 22:26
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Что там будет клеем не важно. Да и не факт что он вообще понадобится.


Ну почему же... Как раз важно. Я собственно знаю только один беспроблемый способ интеграции dsl — когда он сам написан на том же языке что и основной код. Тогда это получается как просто подключение нетривиальной библиотеки. В других же случаях начинаются всякие ужасы.

WH>Re[2]: Веб фрэймворк для Nemerle
Автор: WolfHound
Дата: 14.02.11

WH>Re[3]: Веб фрэймворк для Nemerle
Автор: WolfHound
Дата: 15.02.11

WH>Все это можно легко обобщить для произвольного ГУИ.

Нуу вот как раз для веба на мой взгляд какой-то новый gui dsl и не нужен. Там уже есть html+javascript — полноценная разметка и обработчики. Причём если взять всякие там jqueryui, то уже на уровне полноценного интерфейса.

А вот как на счёт gui dsl для обычных приложений? Хотя я смотрю такими темпами html+javascript станет gui dsl и для десктоп приложений. Уже даже MS в эту сторону движется...

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

WH>Если у нас есть бинбинг к реактивной view model то не нужно.
WH>Все само заработает.

Я к тому что обычные средства "размётки контролов" из различных инструментов построения интерфейсов десктопных приложений подразумевают только именно размётку. Максимум там указываются имя функций обработчикив из основного (не dsl) кода, и то не всегда. А на самом деле это не правильно, т.к. значительная часть реакций на сообщения состоит опять же только из gui действий. Т.е. по идее при их обработке не надо вылезать из gui dsl в движок, написанный на основном языке. Т.е. что бы вызовы из gui dsl в основной код касались уже только непосредственно работы. Вот если бы был такой gui dsl, то был бы смысл на него перейти. А пока, все эти "просто размётки" никому особо не нужны — лишняя сущность. Например мы предпочитаем пользоваться GUI редактором, генерирующим код непосредственно на системном языке. Всё равно руками его никто не правит, так что лишняя сущность типа языка размётки (это же тоже типа dsl) вообще не нужна.
Re[6]: Языки общего назначения не имеют смысла!
От: WolfHound  
Дата: 08.04.12 22:47
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Нуу вот как раз для веба на мой взгляд какой-то новый gui dsl и не нужен. Там уже есть html+javascript — полноценная разметка и обработчики. Причём если взять всякие там jqueryui, то уже на уровне полноценного интерфейса.

По сравнению с MVVM это все очень неудобно.
Все эти ковыряния в ДСМ просто жуть с ружжом.

_>А вот как на счёт gui dsl для обычных приложений? Хотя я смотрю такими темпами html+javascript станет gui dsl и для десктоп приложений. Уже даже MS в эту сторону движется...

Глупости это.

_>Я к тому что обычные средства "размётки контролов" из различных инструментов построения интерфейсов десктопных приложений подразумевают только именно размётку. Максимум там указываются имя функций обработчикив из основного (не dsl) кода, и то не всегда. А на самом деле это не правильно, т.к. значительная часть реакций на сообщения состоит опять же только из gui действий. Т.е. по идее при их обработке не надо вылезать из gui dsl в движок, написанный на основном языке. Т.е. что бы вызовы из gui dsl в основной код касались уже только непосредственно работы. Вот если бы был такой gui dsl, то был бы смысл на него перейти. А пока, все эти "просто размётки" никому особо не нужны — лишняя сущность. Например мы предпочитаем пользоваться GUI редактором, генерирующим код непосредственно на системном языке. Всё равно руками его никто не правит, так что лишняя сущность типа языка размётки (это же тоже типа dsl) вообще не нужна.

Ты зря отмахнулся от тех ссылок, что я тебе дал.
Идеология Model-View-ViewModel доведенная до логического конца как раз и есть такой ДСЛ. View и ViewModel это ГУИ ДСЛ. Model это основной код.
Причем тебе в 99% случаях не придется возиться с обработчиками. Все будет гораздо проще. Посмотри примеры.
И никгда не придется из кода ViewModel лезть во View. Те никакой возни с ДОМ и прочих ужОсов.
Мы просто мапим ViewModel на контролы, а система сама пересчитывает маппинг если ViewModel меняется. Таким образом, если мы хотим что-то изменить, то просто меняем ViewModel. Контролы перестроятся сами.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[9]: Языки общего назначения не имеют смысла!
От: Vain Россия google.ru
Дата: 08.04.12 23:37
Оценка: :)
Здравствуйте, WolfHound, Вы писали:

V>>А нахрена когда есть уже готовые специалисты "общего назначения"?

WH>Ответ в первом сообщении темы.
Это не ответ, это попытка уйти от реальности.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[2]: Языки общего назначения не имеют смысла!
От: __lambda__ Россия http://zen-hacker.blogspot.com/
Дата: 09.04.12 03:17
Оценка: +2
Здравствуйте, Хвост, Вы писали:

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


А ты попробуй в либу/пекейдж/сборку запихни HTML или SQL

Только с другой стороны, если язык будет позволять менять синтаксис, встраивать в себя HTML, SQL, абракадабру Васи Пупкина, блабладсл Пети из соседнего отдела и т.д. Бедному программисту Ване Иванову, только принятому на работу, придется учить все эти супермегаязыки.

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

Необходимость в общем языке нужна, как можно более универсальном, но с другой стороны польза от DSL тоже крайне важна. Это наглядно демонстрируют HTML, SQL, и прочие DSL'и.

Но мне видится оптимальным как раз такой симбиоз, general purpose language + external DSL (что мы на сегодняшний день и наблюдаем).

Мне крайне не нравится подход по максимуму нагрузить general purpose language, например, прибитый гвоздями в C# linq.
Мне крайне не нравится подход делать general purpose language с изменяемым синтаксисом, т.к. оно противоречит его природе general.
Подход Немерле изолировать DSL в отдельные сборки интересен, но на практике сильно не опробован (я имею большие команды, большие проекты).
Computer science is no more about computers than astronomy is about telescopes (c) Edsger Dijkstra
Re[3]: Языки общего назначения не имеют смысла!
От: __lambda__ Россия http://zen-hacker.blogspot.com/
Дата: 09.04.12 03:19
Оценка: :)))
Здравствуйте, __lambda__, Вы писали:

___>Подход Немерле изолировать DSL в отдельные сборки интересен, но на практике сильно не опробован (я имею в виду большие команды, большие проекты).
Computer science is no more about computers than astronomy is about telescopes (c) Edsger Dijkstra
Re: Языки общего назначения не имеют смысла!
От: Антихрист  
Дата: 09.04.12 06:00
Оценка: 1 (1)
Здравствуйте, WolfHound, Вы писали:

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


VE>>А как бы стоило сделать на твой взгляд?

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

WH>Вот буквально только что презенташка попалась.

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

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


Это "день потерять, за пять минут долететь"

Я практикую embedded DSL в таких языках как scala, nemerle — "пять минут потерять, потом за пять минут долететь". Это еще круче.
Re[9]: Языки общего назначения не имеют смысла!
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 09.04.12 07:31
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


AVK>>>Ну почему не придумали? Язык запросов собственный не так уж и редко в корпоративных платформах встречается.

G>>Да, но почти всегда он довольно ущербен

AVK>Это с чем сравнивать. Как минимум, по мощности он обычно сопоставим с голым SQL, но работает в терминах прикладных метаданных, а не в терминах метаданных БД. Типичный пример — Entity SQL в EF.

eSQL не пример DSLя корпоративной системы. Кстати он сам очень ущербен, по сути умеет даже меньше, чем можно в Linq написать.

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

G>> и по сути нужен чтобы не дать программисту нарушить целостность платформы.

AVK>Не только. Он нужен прежде всего чтобы писать запросы, по возможности не вдаваясь в подробности хранения данных в конкретной БД.
Дальше ER модели никто из них пока не ушел, так что по мощности они на уровне SQL. Некоторые правда допускают предикаты типа "Was Ever" или работы с особыми типами, но это скорее исключение, чем правило.
Re[11]: Языки общего назначения не имеют смысла!
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 09.04.12 07:35
Оценка: :)))
Здравствуйте, WolfHound, Вы писали:

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


G>>Я же и говорю, утилитарная роль. Цель таких DSL не решение бизнес-задач, а решение сторонних задач, которые требуют много кода (иногда довольно тупого).

G>>Роль dsl в решении бизнес-задач ты пока не показал. Это значит твой тезис о ненужности языков общего назначения не имеет реального обоснования.
WH>Если язык запросов не решение бизнес-задачи? То я тогда не знаю что такое решение бизнес задачи.

Бизнес задача — посчитать баланс. SQL её решает? Нет. Её решают реляционные СУБД, независимо от способа подачи команд им.
Вот есть XAML — он решает бизнем задачи? Нет, он тупо сериализует объекты, а бизнес-задачи решает код как раз на языке общего назначения, который, возможно, взаимодействует с кучей утилитарных DSLей.

Очень сложно сейчас найти DSL, который может решать задачи самостоятельно.
Re[3]: Языки общего назначения не имеют смысла!
От: VoidEx  
Дата: 09.04.12 07:44
Оценка: +6
Здравствуйте, __lambda__, Вы писали:

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


___>Только с другой стороны, если язык будет позволять менять синтаксис, встраивать в себя HTML, SQL, абракадабру Васи Пупкина, блабладсл Пети из соседнего отдела и т.д. Бедному программисту Ване Иванову, только принятому на работу, придется учить все эти супермегаязыки.


Ему и так придётся.
Вы почему-то думаете, что если термины предметной области выражены через конструкции C#, то это язык C# и учить ничего не надо. Однако изучение сколь-нибудь большой библиотеки это и есть изучение понятий самой библиотеки, и если бы она была выражена в виде простого DSL, учить её было бы проще.
Достаточно взглянуть на какие-нибудь библиотеки, реализованные для разных целевых языков (C#, C++, ...). Между ними общего на порядки больше, чем между разными библиотеками одного языка, потому как область одна, идеология одна. И наоборот, разница в них только в целевом языке.

Практически любая сложная задача сводится к введению понятий задачи на языке имплементации, и чем язык имплементации менее выразителен, тем больше он замусоривает код лишними деталями.
Re[13]: Языки общего назначения не имеют смысла!
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 09.04.12 07:44
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


WH>>>В Н2 все будет куда интереснее.

G>>Кроме pattern-matching ниче особенного нет. Или я не туда смотрю?
WH>А что еще нужно для трансформации дерева?
WH>Вся сложность написания LINQ провайдера и состоит в распознавании и трансформации деревьев.
WH>Делать это на C# мягко говоря проблематично.
Ну можно на F# сделать. Я не вижу в Н ниче особенного тут.
И причем тут DSL? Ты PM тоже DSLем называть будешь?

G>>Придумай язык проще и не потеряй в мощности. Только так чтобы он был подмножеством mainstream языка, иначе толку нет.

WH>Лол. Мелкософты встроили в C# ДСЛ для работы с данными.
Ты монады называешь DSL? Не уверен что слова domain и specific тут уместны. Монады очень широкий класс задач решают в куче предметных областей.

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

G>>Ты или шляпу сними, или штаны одень.
WH>И что C# поймет, что тут написано и сгенерирует маппинг?
А если не будет C# то будет где написано? Ты же толкаешь тезис о ненужности языков общего назначения.
Штаны одень все таки.
Re[10]: Языки общего назначения не имеют смысла!
От: WolfHound  
Дата: 09.04.12 07:52
Оценка:
Здравствуйте, Vain, Вы писали:

V>Это не ответ, это попытка уйти от реальности.

Те ты тоже считаешь, что возможность написать в несколько десятков раз меньше кода и как следствие в несколько десятков раз удешевить разработку и поддержку, а так же в несколько десятков раз сократить количество ошибок это мелочи?
Я тебя правильно понял?
И что касается ухода от реальности, этим занимаешься ты.
Ибо у меня на руках куча фактов.
Которые ты пытаешься игнорировать.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[11]: Языки общего назначения не имеют смысла!
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 09.04.12 07:55
Оценка: +2
Здравствуйте, WolfHound, Вы писали:

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


V>>Это не ответ, это попытка уйти от реальности.

WH>Те ты тоже считаешь, что возможность написать в несколько десятков раз меньше кода и как следствие в несколько десятков раз удешевить разработку и поддержку, а так же в несколько десятков раз сократить количество ошибок это мелочи?

Чтобы написать в 10 раз меньше надо сначала написать DSL, что сложнее чем написать код. Ты пока что обратного не смог показать.

В случает готового отлаженного DSL, подходящего под задачу, вопрос обычно не стоит. А вот вопрос писать или не писать решается обычно не в пользу DSL. Видимо этому есть объективные показания.

WH>Ибо у меня на руках куча фактов.

А кроме одного академ. проекта?
Re[2]: Языки общего назначения не имеют смысла!
От: WolfHound  
Дата: 09.04.12 07:56
Оценка:
Здравствуйте, Антихрист, Вы писали:

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

А>Это "день потерять, за пять минут долететь"
Не согласен.

А>Я практикую embedded DSL в таких языках как scala, nemerle — "пять минут потерять, потом за пять минут долететь". Это еще круче.

Я автор одно из сложнейших (а возможно сложнейшего) ДСЛ для немерле.
https://github.com/rampelstinskin/ParserGenerator
И очень хорошо знаю все его проблемы, если попытаться написать макрос сложнее if/else.
Но главное я знаю, как их решать.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[14]: Языки общего назначения не имеют смысла!
От: WolfHound  
Дата: 09.04.12 08:10
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Ну можно на F# сделать. Я не вижу в Н ниче особенного тут.

G>И причем тут DSL? Ты PM тоже DSLем называть будешь?
Отличный ДСЛ для разбора деревьев.

G>Ты монады называешь DSL? Не уверен что слова domain и specific тут уместны. Монады очень широкий класс задач решают в куче предметных областей.

Вот только им отдельный синтаксис не нужен.
Ими и без того можно пользоваться.
Тем не менее, их решили засахарить.
Причем ввели только несколько конструкций.
А остальное приходится писать без синтаксиса.
А если бы C# можно было бы расширять, то такой проблемы бы не было.

G>А если не будет C# то будет где написано?

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

G>Ты же толкаешь тезис о ненужности языков общего назначения.

Ты просто не понимаешь о чем я говрю.
Если модель ЯОН точно совпадает с моделью задачи, то этот ЯОН становится, ПОЯ для этой задачи.
Но пытаться натянуть задачу на язык с другой моделью глупость полнейшая.

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

G>Штаны одень все таки.

Еще один озабоченный.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: Языки общего назначения не имеют смысла!
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 09.04.12 08:10
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Tcl как-то не очень похож на DSL. Это скорее полноценный язык.

_>Ну и результат с Тк мягко говоря сомнительный...

Почему?
Автор: Andrei N.Sobchuck
Дата: 01.06.06
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[12]: Языки общего назначения не имеют смысла!
От: WolfHound  
Дата: 09.04.12 08:15
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Бизнес задача — посчитать баланс. SQL её решает? Нет. Её решают реляционные СУБД, независимо от способа подачи команд им.

G>Вот есть XAML — он решает бизнем задачи? Нет, он тупо сериализует объекты, а бизнес-задачи решает код как раз на языке общего назначения, который, возможно, взаимодействует с кучей утилитарных DSLей.
Мда... с таким подходом можно доказать что угодно.
И ведь пофиг что чуть менее чем весь код написан на ДСЛях.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[10]: Языки общего назначения не имеют смысла!
От: WolfHound  
Дата: 09.04.12 08:17
Оценка: +1
Здравствуйте, gandjustas, Вы писали:

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

G>Получается что DSL усложняет решение, но дает программисту оставаться в контексте системы, обеспечивая некоторый уровень целостности и, возможно, обратной совместимости.
Те заявления о том что ДСЛ не нужны основаны на том что кто-то не осилил сделать хороший ДСЛ?
Прэлэсно!
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[15]: Языки общего назначения не имеют смысла!
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 09.04.12 08:21
Оценка: -1
Здравствуйте, WolfHound, Вы писали:

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


G>>Ну можно на F# сделать. Я не вижу в Н ниче особенного тут.

G>>И причем тут DSL? Ты PM тоже DSLем называть будешь?
WH>Отличный ДСЛ для разбора деревьев.
Все, понял. DSL головного мозга.
Re[13]: Языки общего назначения не имеют смысла!
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 09.04.12 08:22
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


G>>Бизнес задача — посчитать баланс. SQL её решает? Нет. Её решают реляционные СУБД, независимо от способа подачи команд им.

G>>Вот есть XAML — он решает бизнем задачи? Нет, он тупо сериализует объекты, а бизнес-задачи решает код как раз на языке общего назначения, который, возможно, взаимодействует с кучей утилитарных DSLей.
WH>Мда... с таким подходом можно доказать что угодно.
WH>И ведь пофиг что чуть менее чем весь код написан на ДСЛях.
Вопрос не в использовании DSL, а в их написании и нужности языков общего назначения. Ты все время пытаешься куда-то нитуда разговор увести.
Re[12]: Языки общего назначения не имеют смысла!
От: WolfHound  
Дата: 09.04.12 08:27
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Чтобы написать в 10 раз меньше надо сначала написать DSL, что сложнее чем написать код. Ты пока что обратного не смог показать.

Смех на палочке.
Напиши этот код руками:
  Скрытый текст
using Nemerle.Builtins;
using Nemerle.Collections;
using Nemerle.Core;
using Nemerle.Parser;
using Nemerle.Parser.Internal;
using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Runtime.CompilerServices;
public abstract class CalcParser
{
    public sealed class GrammarImpl : CalcParser, IGrammar
    {
        public sealed class GrammarDescriptorImpl : GrammarDescriptor
        {
            public class _#postfix#_add_ : RuleDescriptor
            {
                public static readonly TokenDescriptor _token_literal_"+"_;
                private static readonly CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_add_ _staticDescriptor;
                public override string Name
                {
                    get
                    {
                        return "add";
                    }
                }
                public override GrammarDescriptor Grammar
                {
                    get
                    {
                        return CalcParser.GrammarImpl.StaticDescriptor;
                    }
                }
                public static RuleDescriptor StaticDescriptor
                {
                    get
                    {
                        return CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_add_._staticDescriptor;
                    }
                }
                static _#postfix#_add_()
                {
                    CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_add_._staticDescriptor = new CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_add_();
                    CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_add_._token_literal_"+"_ = new TokenDescriptor(CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_add_._staticDescriptor, "+", true);
                }
                public CalcParser.Add ResultType()
                {
                    return null;
                }
                private _#postfix#_add_()
                {
                }
            }
            public class _#regular#_any_ : RuleDescriptor
            {
                private static readonly CalcParser.GrammarImpl.GrammarDescriptorImpl._#regular#_any_ _staticDescriptor;
                public override string Name
                {
                    get
                    {
                        return "any";
                    }
                }
                public override GrammarDescriptor Grammar
                {
                    get
                    {
                        return CalcParser.GrammarImpl.StaticDescriptor;
                    }
                }
                public static RuleDescriptor StaticDescriptor
                {
                    get
                    {
                        return CalcParser.GrammarImpl.GrammarDescriptorImpl._#regular#_any_._staticDescriptor;
                    }
                }
                static _#regular#_any_()
                {
                    CalcParser.GrammarImpl.GrammarDescriptorImpl._#regular#_any_._staticDescriptor = new CalcParser.GrammarImpl.GrammarDescriptorImpl._#regular#_any_();
                }
                private _#regular#_any_()
                {
                }
            }
            public class _#postfix#_cond_ : RuleDescriptor
            {
                public static readonly TokenDescriptor _token_literal_"?"_;
                public static readonly TokenDescriptor _token_literal_":"_;
                private static readonly CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_cond_ _staticDescriptor;
                public override string Name
                {
                    get
                    {
                        return "cond";
                    }
                }
                public override GrammarDescriptor Grammar
                {
                    get
                    {
                        return CalcParser.GrammarImpl.StaticDescriptor;
                    }
                }
                public static RuleDescriptor StaticDescriptor
                {
                    get
                    {
                        return CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_cond_._staticDescriptor;
                    }
                }
                static _#postfix#_cond_()
                {
                    CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_cond_._staticDescriptor = new CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_cond_();
                    CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_cond_._token_literal_":"_ = new TokenDescriptor(CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_cond_._staticDescriptor, ":", true);
                    CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_cond_._token_literal_"?"_ = new TokenDescriptor(CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_cond_._staticDescriptor, "?", true);
                }
                public CalcParser.Cond ResultType()
                {
                    return null;
                }
                private _#postfix#_cond_()
                {
                }
            }
            public class _#postfix#_div_ : RuleDescriptor
            {
                public static readonly TokenDescriptor _token_literal_"/"_;
                private static readonly CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_div_ _staticDescriptor;
                public override string Name
                {
                    get
                    {
                        return "div";
                    }
                }
                public override GrammarDescriptor Grammar
                {
                    get
                    {
                        return CalcParser.GrammarImpl.StaticDescriptor;
                    }
                }
                public static RuleDescriptor StaticDescriptor
                {
                    get
                    {
                        return CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_div_._staticDescriptor;
                    }
                }
                static _#postfix#_div_()
                {
                    CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_div_._staticDescriptor = new CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_div_();
                    CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_div_._token_literal_"/"_ = new TokenDescriptor(CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_div_._staticDescriptor, "/", true);
                }
                public CalcParser.Div ResultType()
                {
                    return null;
                }
                private _#postfix#_div_()
                {
                }
            }
            public class _#point#___expr_ : RuleDescriptor
            {
                private static readonly CalcParser.GrammarImpl.GrammarDescriptorImpl._#point#___expr_ _staticDescriptor;
                public override string Name
                {
                    get
                    {
                        return "expr";
                    }
                }
                public override GrammarDescriptor Grammar
                {
                    get
                    {
                        return CalcParser.GrammarImpl.StaticDescriptor;
                    }
                }
                public static RuleDescriptor StaticDescriptor
                {
                    get
                    {
                        return CalcParser.GrammarImpl.GrammarDescriptorImpl._#point#___expr_._staticDescriptor;
                    }
                }
                static _#point#___expr_()
                {
                    CalcParser.GrammarImpl.GrammarDescriptorImpl._#point#___expr_._staticDescriptor = new CalcParser.GrammarImpl.GrammarDescriptorImpl._#point#___expr_();
                }
                public CalcParser.Expr ResultType()
                {
                    return null;
                }
                private _#point#___expr_()
                {
                }
            }
            public class _#postfix#_mod_ : RuleDescriptor
            {
                public static readonly TokenDescriptor _token_literal_"%"_;
                private static readonly CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_mod_ _staticDescriptor;
                public override string Name
                {
                    get
                    {
                        return "mod";
                    }
                }
                public override GrammarDescriptor Grammar
                {
                    get
                    {
                        return CalcParser.GrammarImpl.StaticDescriptor;
                    }
                }
                public static RuleDescriptor StaticDescriptor
                {
                    get
                    {
                        return CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_mod_._staticDescriptor;
                    }
                }
                static _#postfix#_mod_()
                {
                    CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_mod_._staticDescriptor = new CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_mod_();
                    CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_mod_._token_literal_"%"_ = new TokenDescriptor(CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_mod_._staticDescriptor, "%", true);
                }
                public CalcParser.Mod ResultType()
                {
                    return null;
                }
                private _#postfix#_mod_()
                {
                }
            }
            public class _#postfix#_mul_ : RuleDescriptor
            {
                public static readonly TokenDescriptor _token_literal_"*"_;
                private static readonly CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_mul_ _staticDescriptor;
                public override string Name
                {
                    get
                    {
                        return "mul";
                    }
                }
                public override GrammarDescriptor Grammar
                {
                    get
                    {
                        return CalcParser.GrammarImpl.StaticDescriptor;
                    }
                }
                public static RuleDescriptor StaticDescriptor
                {
                    get
                    {
                        return CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_mul_._staticDescriptor;
                    }
                }
                static _#postfix#_mul_()
                {
                    CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_mul_._staticDescriptor = new CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_mul_();
                    CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_mul_._token_literal_"*"_ = new TokenDescriptor(CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_mul_._staticDescriptor, "*", true);
                }
                public CalcParser.Mul ResultType()
                {
                    return null;
                }
                private _#postfix#_mul_()
                {
                }
            }
            public class _#prefix#__neg_ : RuleDescriptor
            {
                public static readonly TokenDescriptor _token_literal_"-"_;
                private static readonly CalcParser.GrammarImpl.GrammarDescriptorImpl._#prefix#__neg_ _staticDescriptor;
                public override string Name
                {
                    get
                    {
                        return "neg";
                    }
                }
                public override GrammarDescriptor Grammar
                {
                    get
                    {
                        return CalcParser.GrammarImpl.StaticDescriptor;
                    }
                }
                public static RuleDescriptor StaticDescriptor
                {
                    get
                    {
                        return CalcParser.GrammarImpl.GrammarDescriptorImpl._#prefix#__neg_._staticDescriptor;
                    }
                }
                static _#prefix#__neg_()
                {
                    CalcParser.GrammarImpl.GrammarDescriptorImpl._#prefix#__neg_._staticDescriptor = new CalcParser.GrammarImpl.GrammarDescriptorImpl._#prefix#__neg_();
                    CalcParser.GrammarImpl.GrammarDescriptorImpl._#prefix#__neg_._token_literal_"-"_ = new TokenDescriptor(CalcParser.GrammarImpl.GrammarDescriptorImpl._#prefix#__neg_._staticDescriptor, "-", true);
                }
                public CalcParser.Neg ResultType()
                {
                    return null;
                }
                private _#prefix#__neg_()
                {
                }
            }
            public class _#prefix#__num_ : RuleDescriptor
            {
                private static readonly CalcParser.GrammarImpl.GrammarDescriptorImpl._#prefix#__num_ _staticDescriptor;
                public override string Name
                {
                    get
                    {
                        return "num";
                    }
                }
                public override GrammarDescriptor Grammar
                {
                    get
                    {
                        return CalcParser.GrammarImpl.StaticDescriptor;
                    }
                }
                public static RuleDescriptor StaticDescriptor
                {
                    get
                    {
                        return CalcParser.GrammarImpl.GrammarDescriptorImpl._#prefix#__num_._staticDescriptor;
                    }
                }
                static _#prefix#__num_()
                {
                    CalcParser.GrammarImpl.GrammarDescriptorImpl._#prefix#__num_._staticDescriptor = new CalcParser.GrammarImpl.GrammarDescriptorImpl._#prefix#__num_();
                }
                public CalcParser.Num ResultType()
                {
                    return null;
                }
                private _#prefix#__num_()
                {
                }
            }
            public class _#postfix#_postfixDec_ : RuleDescriptor
            {
                public static readonly TokenDescriptor _token_literal_"--"_;
                private static readonly CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_postfixDec_ _staticDescriptor;
                public override string Name
                {
                    get
                    {
                        return "postfixDec";
                    }
                }
                public override GrammarDescriptor Grammar
                {
                    get
                    {
                        return CalcParser.GrammarImpl.StaticDescriptor;
                    }
                }
                public static RuleDescriptor StaticDescriptor
                {
                    get
                    {
                        return CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_postfixDec_._staticDescriptor;
                    }
                }
                static _#postfix#_postfixDec_()
                {
                    CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_postfixDec_._staticDescriptor = new CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_postfixDec_();
                    CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_postfixDec_._token_literal_"--"_ = new TokenDescriptor(CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_postfixDec_._staticDescriptor, "--", true);
                }
                public CalcParser.PostfixDec ResultType()
                {
                    return null;
                }
                private _#postfix#_postfixDec_()
                {
                }
            }
            public class _#postfix#_pow_ : RuleDescriptor
            {
                public static readonly TokenDescriptor _token_literal_"^"_;
                private static readonly CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_pow_ _staticDescriptor;
                public override string Name
                {
                    get
                    {
                        return "pow";
                    }
                }
                public override GrammarDescriptor Grammar
                {
                    get
                    {
                        return CalcParser.GrammarImpl.StaticDescriptor;
                    }
                }
                public static RuleDescriptor StaticDescriptor
                {
                    get
                    {
                        return CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_pow_._staticDescriptor;
                    }
                }
                static _#postfix#_pow_()
                {
                    CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_pow_._staticDescriptor = new CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_pow_();
                    CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_pow_._token_literal_"^"_ = new TokenDescriptor(CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_pow_._staticDescriptor, "^", true);
                }
                public CalcParser.Pow ResultType()
                {
                    return null;
                }
                private _#postfix#_pow_()
                {
                }
            }
            public class _#prefix#__prefixDec_ : RuleDescriptor
            {
                public static readonly TokenDescriptor _token_literal_"--"_;
                private static readonly CalcParser.GrammarImpl.GrammarDescriptorImpl._#prefix#__prefixDec_ _staticDescriptor;
                public override string Name
                {
                    get
                    {
                        return "prefixDec";
                    }
                }
                public override GrammarDescriptor Grammar
                {
                    get
                    {
                        return CalcParser.GrammarImpl.StaticDescriptor;
                    }
                }
                public static RuleDescriptor StaticDescriptor
                {
                    get
                    {
                        return CalcParser.GrammarImpl.GrammarDescriptorImpl._#prefix#__prefixDec_._staticDescriptor;
                    }
                }
                static _#prefix#__prefixDec_()
                {
                    CalcParser.GrammarImpl.GrammarDescriptorImpl._#prefix#__prefixDec_._staticDescriptor = new CalcParser.GrammarImpl.GrammarDescriptorImpl._#prefix#__prefixDec_();
                    CalcParser.GrammarImpl.GrammarDescriptorImpl._#prefix#__prefixDec_._token_literal_"--"_ = new TokenDescriptor(CalcParser.GrammarImpl.GrammarDescriptorImpl._#prefix#__prefixDec_._staticDescriptor, "--", true);
                }
                public CalcParser.PrefixDec ResultType()
                {
                    return null;
                }
                private _#prefix#__prefixDec_()
                {
                }
            }
            public class _#prefix#__rounds_ : RuleDescriptor
            {
                public static readonly TokenDescriptor _token_literal_"("_;
                public static readonly TokenDescriptor _token_literal_")"_;
                private static readonly CalcParser.GrammarImpl.GrammarDescriptorImpl._#prefix#__rounds_ _staticDescriptor;
                public override string Name
                {
                    get
                    {
                        return "rounds";
                    }
                }
                public override GrammarDescriptor Grammar
                {
                    get
                    {
                        return CalcParser.GrammarImpl.StaticDescriptor;
                    }
                }
                public static RuleDescriptor StaticDescriptor
                {
                    get
                    {
                        return CalcParser.GrammarImpl.GrammarDescriptorImpl._#prefix#__rounds_._staticDescriptor;
                    }
                }
                static _#prefix#__rounds_()
                {
                    CalcParser.GrammarImpl.GrammarDescriptorImpl._#prefix#__rounds_._staticDescriptor = new CalcParser.GrammarImpl.GrammarDescriptorImpl._#prefix#__rounds_();
                    CalcParser.GrammarImpl.GrammarDescriptorImpl._#prefix#__rounds_._token_literal_")"_ = new TokenDescriptor(CalcParser.GrammarImpl.GrammarDescriptorImpl._#prefix#__rounds_._staticDescriptor, ")", true);
                    CalcParser.GrammarImpl.GrammarDescriptorImpl._#prefix#__rounds_._token_literal_"("_ = new TokenDescriptor(CalcParser.GrammarImpl.GrammarDescriptorImpl._#prefix#__rounds_._staticDescriptor, "(", true);
                }
                public CalcParser.Rounds ResultType()
                {
                    return null;
                }
                private _#prefix#__rounds_()
                {
                }
            }
            public class _#simple#__s_ : RuleDescriptor
            {
                public static readonly TokenDescriptor _token_literal_" "_;
                private static readonly CalcParser.GrammarImpl.GrammarDescriptorImpl._#simple#__s_ _staticDescriptor;
                public override string Name
                {
                    get
                    {
                        return "s";
                    }
                }
                public override GrammarDescriptor Grammar
                {
                    get
                    {
                        return CalcParser.GrammarImpl.StaticDescriptor;
                    }
                }
                public static RuleDescriptor StaticDescriptor
                {
                    get
                    {
                        return CalcParser.GrammarImpl.GrammarDescriptorImpl._#simple#__s_._staticDescriptor;
                    }
                }
                static _#simple#__s_()
                {
                    CalcParser.GrammarImpl.GrammarDescriptorImpl._#simple#__s_._staticDescriptor = new CalcParser.GrammarImpl.GrammarDescriptorImpl._#simple#__s_();
                    CalcParser.GrammarImpl.GrammarDescriptorImpl._#simple#__s_._token_literal_" "_ = new TokenDescriptor(CalcParser.GrammarImpl.GrammarDescriptorImpl._#simple#__s_._staticDescriptor, " ", true);
                }
                public void ResultType()
                {
                }
                private _#simple#__s_()
                {
                }
            }
            public class _#prefix#__seq_ : RuleDescriptor
            {
                public static readonly TokenDescriptor _token_literal_"{"_;
                public static readonly TokenDescriptor _token_literal_"}"_;
                private static readonly CalcParser.GrammarImpl.GrammarDescriptorImpl._#prefix#__seq_ _staticDescriptor;
                public override string Name
                {
                    get
                    {
                        return "seq";
                    }
                }
                public override GrammarDescriptor Grammar
                {
                    get
                    {
                        return CalcParser.GrammarImpl.StaticDescriptor;
                    }
                }
                public static RuleDescriptor StaticDescriptor
                {
                    get
                    {
                        return CalcParser.GrammarImpl.GrammarDescriptorImpl._#prefix#__seq_._staticDescriptor;
                    }
                }
                static _#prefix#__seq_()
                {
                    CalcParser.GrammarImpl.GrammarDescriptorImpl._#prefix#__seq_._staticDescriptor = new CalcParser.GrammarImpl.GrammarDescriptorImpl._#prefix#__seq_();
                    CalcParser.GrammarImpl.GrammarDescriptorImpl._#prefix#__seq_._token_literal_"}"_ = new TokenDescriptor(CalcParser.GrammarImpl.GrammarDescriptorImpl._#prefix#__seq_._staticDescriptor, "}", true);
                    CalcParser.GrammarImpl.GrammarDescriptorImpl._#prefix#__seq_._token_literal_"{"_ = new TokenDescriptor(CalcParser.GrammarImpl.GrammarDescriptorImpl._#prefix#__seq_._staticDescriptor, "{", true);
                }
                public CalcParser.Seq ResultType()
                {
                    return null;
                }
                private _#prefix#__seq_()
                {
                }
            }
            public class _#simple#__start_ : RuleDescriptor
            {
                public static readonly TokenDescriptor _token_rule_"any"_;
                private static readonly CalcParser.GrammarImpl.GrammarDescriptorImpl._#simple#__start_ _staticDescriptor;
                public override string Name
                {
                    get
                    {
                        return "start";
                    }
                }
                public override GrammarDescriptor Grammar
                {
                    get
                    {
                        return CalcParser.GrammarImpl.StaticDescriptor;
                    }
                }
                public static RuleDescriptor StaticDescriptor
                {
                    get
                    {
                        return CalcParser.GrammarImpl.GrammarDescriptorImpl._#simple#__start_._staticDescriptor;
                    }
                }
                static _#simple#__start_()
                {
                    CalcParser.GrammarImpl.GrammarDescriptorImpl._#simple#__start_._staticDescriptor = new CalcParser.GrammarImpl.GrammarDescriptorImpl._#simple#__start_();
                    CalcParser.GrammarImpl.GrammarDescriptorImpl._#simple#__start_._token_rule_"any"_ = new TokenDescriptor(CalcParser.GrammarImpl.GrammarDescriptorImpl._#simple#__start_._staticDescriptor, "any", false);
                }
                public CalcParser.Start ResultType()
                {
                    return null;
                }
                private _#simple#__start_()
                {
                }
            }
            public class _#postfix#_sub_ : RuleDescriptor
            {
                public static readonly TokenDescriptor _token_literal_"-"_;
                private static readonly CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_sub_ _staticDescriptor;
                public override string Name
                {
                    get
                    {
                        return "sub";
                    }
                }
                public override GrammarDescriptor Grammar
                {
                    get
                    {
                        return CalcParser.GrammarImpl.StaticDescriptor;
                    }
                }
                public static RuleDescriptor StaticDescriptor
                {
                    get
                    {
                        return CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_sub_._staticDescriptor;
                    }
                }
                static _#postfix#_sub_()
                {
                    CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_sub_._staticDescriptor = new CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_sub_();
                    CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_sub_._token_literal_"-"_ = new TokenDescriptor(CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_sub_._staticDescriptor, "-", true);
                }
                public CalcParser.Sub ResultType()
                {
                    return null;
                }
                private _#postfix#_sub_()
                {
                }
            }
            public override GrammarDescriptor[] Dependencies
            {
                get
                {
                    return new GrammarDescriptor[]
                    {
                        NumParser.GrammarImpl.get_StaticDescriptor(), 
                        IncParser.GrammarImpl.StaticDescriptor
                    };
                }
            }
            public override string Name
            {
                get
                {
                    return "CalcParser";
                }
            }
            public override string FullName
            {
                get
                {
                    return "CalcParser";
                }
            }
            public override IGrammar NewGrammar(Parser parser)
            {
                return new CalcParser.GrammarImpl(parser);
            }
            public override ParsingErrors NewParsingErrors()
            {
                return new CalcParser.GrammarImpl.ParsingErrorsImpl();
            }
        }
        private sealed class ParsingErrorsImpl : ParsingErrors
        {
            public int _token_sub_literal_"-"_;
            public int _token_start_rule_"any"_;
            public int _token_seq_literal_"{"_;
            public int _token_seq_literal_"}"_;
            public int _token_s_literal_" "_;
            public int _token_rounds_literal_"("_;
            public int _token_rounds_literal_")"_;
            public int _token_prefixDec_literal_"--"_;
            public int _token_pow_literal_"^"_;
            public int _token_postfixDec_literal_"--"_;
            public int _token_neg_literal_"-"_;
            public int _token_mul_literal_"*"_;
            public int _token_mod_literal_"%"_;
            public int _token_div_literal_"/"_;
            public int _token_cond_literal_"?"_;
            public int _token_cond_literal_":"_;
            public int _token_add_literal_"+"_;
            public override void Clear()
            {
                this._token_add_literal_"+"_ = -2;
                this._token_cond_literal_":"_ = -2;
                this._token_cond_literal_"?"_ = -2;
                this._token_div_literal_"/"_ = -2;
                this._token_mod_literal_"%"_ = -2;
                this._token_mul_literal_"*"_ = -2;
                this._token_neg_literal_"-"_ = -2;
                this._token_postfixDec_literal_"--"_ = -2;
                this._token_pow_literal_"^"_ = -2;
                this._token_prefixDec_literal_"--"_ = -2;
                this._token_rounds_literal_")"_ = -2;
                this._token_rounds_literal_"("_ = -2;
                this._token_s_literal_" "_ = -2;
                this._token_seq_literal_"}"_ = -2;
                this._token_seq_literal_"{"_ = -2;
                this._token_start_rule_"any"_ = -2;
                this._token_sub_literal_"-"_ = -2;
            }
            public override void GetErrors(ref int pos, List<TokenDescriptor> descriptors)
            {
                int arg_04_0 = pos;
                if (pos < this._token_add_literal_"+"_)
                {
                    pos = this._token_add_literal_"+"_;
                    descriptors.Clear();
                }
                if (pos == this._token_add_literal_"+"_)
                {
                    descriptors.Add(CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_add_._token_literal_"+"_);
                }
                if (pos < this._token_cond_literal_":"_)
                {
                    pos = this._token_cond_literal_":"_;
                    descriptors.Clear();
                }
                if (pos == this._token_cond_literal_":"_)
                {
                    descriptors.Add(CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_cond_._token_literal_":"_);
                }
                if (pos < this._token_cond_literal_"?"_)
                {
                    pos = this._token_cond_literal_"?"_;
                    descriptors.Clear();
                }
                if (pos == this._token_cond_literal_"?"_)
                {
                    descriptors.Add(CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_cond_._token_literal_"?"_);
                }
                if (pos < this._token_div_literal_"/"_)
                {
                    pos = this._token_div_literal_"/"_;
                    descriptors.Clear();
                }
                if (pos == this._token_div_literal_"/"_)
                {
                    descriptors.Add(CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_div_._token_literal_"/"_);
                }
                if (pos < this._token_mod_literal_"%"_)
                {
                    pos = this._token_mod_literal_"%"_;
                    descriptors.Clear();
                }
                if (pos == this._token_mod_literal_"%"_)
                {
                    descriptors.Add(CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_mod_._token_literal_"%"_);
                }
                if (pos < this._token_mul_literal_"*"_)
                {
                    pos = this._token_mul_literal_"*"_;
                    descriptors.Clear();
                }
                if (pos == this._token_mul_literal_"*"_)
                {
                    descriptors.Add(CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_mul_._token_literal_"*"_);
                }
                if (pos < this._token_neg_literal_"-"_)
                {
                    pos = this._token_neg_literal_"-"_;
                    descriptors.Clear();
                }
                if (pos == this._token_neg_literal_"-"_)
                {
                    descriptors.Add(CalcParser.GrammarImpl.GrammarDescriptorImpl._#prefix#__neg_._token_literal_"-"_);
                }
                if (pos < this._token_postfixDec_literal_"--"_)
                {
                    pos = this._token_postfixDec_literal_"--"_;
                    descriptors.Clear();
                }
                if (pos == this._token_postfixDec_literal_"--"_)
                {
                    descriptors.Add(CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_postfixDec_._token_literal_"--"_);
                }
                if (pos < this._token_pow_literal_"^"_)
                {
                    pos = this._token_pow_literal_"^"_;
                    descriptors.Clear();
                }
                if (pos == this._token_pow_literal_"^"_)
                {
                    descriptors.Add(CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_pow_._token_literal_"^"_);
                }
                if (pos < this._token_prefixDec_literal_"--"_)
                {
                    pos = this._token_prefixDec_literal_"--"_;
                    descriptors.Clear();
                }
                if (pos == this._token_prefixDec_literal_"--"_)
                {
                    descriptors.Add(CalcParser.GrammarImpl.GrammarDescriptorImpl._#prefix#__prefixDec_._token_literal_"--"_);
                }
                if (pos < this._token_rounds_literal_")"_)
                {
                    pos = this._token_rounds_literal_")"_;
                    descriptors.Clear();
                }
                if (pos == this._token_rounds_literal_")"_)
                {
                    descriptors.Add(CalcParser.GrammarImpl.GrammarDescriptorImpl._#prefix#__rounds_._token_literal_")"_);
                }
                if (pos < this._token_rounds_literal_"("_)
                {
                    pos = this._token_rounds_literal_"("_;
                    descriptors.Clear();
                }
                if (pos == this._token_rounds_literal_"("_)
                {
                    descriptors.Add(CalcParser.GrammarImpl.GrammarDescriptorImpl._#prefix#__rounds_._token_literal_"("_);
                }
                if (pos < this._token_s_literal_" "_)
                {
                    pos = this._token_s_literal_" "_;
                    descriptors.Clear();
                }
                if (pos == this._token_s_literal_" "_)
                {
                    descriptors.Add(CalcParser.GrammarImpl.GrammarDescriptorImpl._#simple#__s_._token_literal_" "_);
                }
                if (pos < this._token_seq_literal_"}"_)
                {
                    pos = this._token_seq_literal_"}"_;
                    descriptors.Clear();
                }
                if (pos == this._token_seq_literal_"}"_)
                {
                    descriptors.Add(CalcParser.GrammarImpl.GrammarDescriptorImpl._#prefix#__seq_._token_literal_"}"_);
                }
                if (pos < this._token_seq_literal_"{"_)
                {
                    pos = this._token_seq_literal_"{"_;
                    descriptors.Clear();
                }
                if (pos == this._token_seq_literal_"{"_)
                {
                    descriptors.Add(CalcParser.GrammarImpl.GrammarDescriptorImpl._#prefix#__seq_._token_literal_"{"_);
                }
                if (pos < this._token_start_rule_"any"_)
                {
                    pos = this._token_start_rule_"any"_;
                    descriptors.Clear();
                }
                if (pos == this._token_start_rule_"any"_)
                {
                    descriptors.Add(CalcParser.GrammarImpl.GrammarDescriptorImpl._#simple#__start_._token_rule_"any"_);
                }
                if (pos < this._token_sub_literal_"-"_)
                {
                    pos = this._token_sub_literal_"-"_;
                    descriptors.Clear();
                }
                if (pos == this._token_sub_literal_"-"_)
                {
                    descriptors.Add(CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_sub_._token_literal_"-"_);
                }
            }
            public ParsingErrorsImpl()
            {
                this.Clear();
            }
        }
        private sealed class GrammarStateImpl : IGrammarState
        {
            private readonly ExtensionPostfixBase<CalcParser.Expr>[] _#_expr_PostfixRules_;
            private readonly ExtensionPrefixBase<CalcParser.Expr>[] _#_expr_PrefixRules__;
            [DebuggerBrowsable(DebuggerBrowsableState.Never), CompilerGenerated]
            private readonly CalcParser.GrammarImpl _N_Grammar_4228;
            public CalcParser.GrammarImpl Grammar
            {
                [CompilerGenerated]
                get
                {
                    return this._N_Grammar_4228;
                }
            }
            public void LoadThisState()
            {
                this.Grammar._#_expr_PrefixRules__ = this._#_expr_PrefixRules__;
                this.Grammar._#_expr_PostfixRules_ = this._#_expr_PostfixRules_;
            }
            public GrammarStateImpl(CalcParser.GrammarImpl grammar)
            {
                this._N_Grammar_4228 = grammar;
                this._#_expr_PrefixRules__ = this._N_Grammar_4228._#_expr_PrefixRules__;
                this._#_expr_PostfixRules_ = this._N_Grammar_4228._#_expr_PostfixRules_;
            }
            public GrammarStateImpl()
            {
            }
            IGrammar IGrammarState.get_Grammar()
            {
                return this.Grammar;
            }
        }
        public class _#postfix#_add_ : ExtensionPostfixBase<CalcParser.Expr>
        {
            private readonly CalcParser.GrammarImpl _grammar;
            public override RuleDescriptor Descriptor
            {
                get
                {
                    return CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_add_.StaticDescriptor;
                }
            }
            public override int Parse(int startPos, int pos, string text, int[] bestOffsets, ref CalcParser.Expr result)
            {
                bool isBest = false;
                NToken token_2 = default(NToken);
                CalcParser.Expr token_3 = null;
                CalcParser.Expr prefixResult = result;
                int seqResult = 0;
                CalcParser.Expr token_4 = prefixResult;
                bool _N_cache_12268 = pos >= 0;
                bool arg_AE_0;
                if (_N_cache_12268)
                {
                    if (true)
                    {
                        if (isBest)
                        {
                            arg_AE_0 = true;
                        }
                        else
                        {
                            isBest = (bestOffsets[0] < pos);
                            arg_AE_0 = (isBest || bestOffsets[0] == pos);
                        }
                        goto IL_A3;
                    }
                }
                arg_AE_0 = false;
                IL_A3:
                bool flag = arg_AE_0;
                if (!flag)
                {
                    seqResult = -1;
                }
                else
                {
                    int arg_146_0;
                    if (pos < text.Length && text[pos] == '+')
                    {
                        arg_146_0 = pos + 1;
                    }
                    else
                    {
                        if (this._grammar._parsingErrors._token_add_literal_"+"_ < pos)
                        {
                            this._grammar._parsingErrors._token_add_literal_"+"_ = pos;
                        }
                        arg_146_0 = -1;
                    }
                    int newPos = arg_146_0;
                    if (newPos >= 0)
                    {
                        token_2 = new NToken(pos, newPos);
                    }
                    int pos2 = newPos;
                    bool _N_cache_12269 = pos2 >= 0;
                    bool arg_1D5_0;
                    if (_N_cache_12269)
                    {
                        if (true)
                        {
                            if (isBest)
                            {
                                arg_1D5_0 = true;
                            }
                            else
                            {
                                isBest = (bestOffsets[1] < pos2);
                                arg_1D5_0 = (isBest || bestOffsets[1] == pos2);
                            }
                            goto IL_1CA;
                        }
                    }
                    arg_1D5_0 = false;
                    IL_1CA:
                    bool flag2 = arg_1D5_0;
                    if (!flag2)
                    {
                        seqResult = -1;
                    }
                    else
                    {
                        int ofs = pos2;
                        int pos3 = this._grammar._#_s_(pos2, text);
                        bool _N_cache_12270 = pos3 >= 0;
                        bool arg_26E_0;
                        if (_N_cache_12270)
                        {
                            if (true)
                            {
                                if (isBest)
                                {
                                    arg_26E_0 = true;
                                }
                                else
                                {
                                    isBest = (bestOffsets[2] < pos3);
                                    arg_26E_0 = (isBest || bestOffsets[2] == pos3);
                                }
                                goto IL_263;
                            }
                        }
                        arg_26E_0 = false;
                        IL_263:
                        bool flag3 = arg_26E_0;
                        if (!flag3)
                        {
                            seqResult = -1;
                        }
                        else
                        {
                            int ofs2 = pos3;
                            int pos4 = this._grammar._#_expr_(pos3, text, 10, ref token_3);
                            bool _N_cache_12271 = pos4 >= 0;
                            bool arg_30B_0;
                            if (_N_cache_12271)
                            {
                                if (true)
                                {
                                    if (isBest)
                                    {
                                        arg_30B_0 = true;
                                    }
                                    else
                                    {
                                        isBest = (bestOffsets[3] < pos4);
                                        arg_30B_0 = (isBest || bestOffsets[3] == pos4);
                                    }
                                    goto IL_300;
                                }
                            }
                            arg_30B_0 = false;
                            IL_300:
                            bool flag4 = arg_30B_0;
                            if (!flag4)
                            {
                                seqResult = -1;
                            }
                            else
                            {
                                int ofs3 = pos4;
                                int arg_3A2_0;
                                if (isBest)
                                {
                                    bestOffsets[0] = pos;
                                    bestOffsets[1] = ofs;
                                    bestOffsets[2] = ofs2;
                                    bestOffsets[3] = ofs3;
                                    int i = 4;
                                    while (i < bestOffsets.Length && bestOffsets[i] >= 0)
                                    {
                                        bestOffsets[i] = -1;
                                        i++;
                                    }
                                    arg_3A2_0 = pos4;
                                }
                                else
                                {
                                    arg_3A2_0 = -1;
                                }
                                seqResult = arg_3A2_0;
                            }
                        }
                    }
                }
                int newPos2 = seqResult;
                if (newPos2 >= 0)
                {
                    result = new CalcParser.Add.Ast(new Location(this._grammar._parsingSource, token_4.get_Location().get_StartPos(), token_3.get_Location().get_EndPos()), list<ErrorInfo>.Nil._N_constant_object, token_4, token_2, token_3);
                }
                return newPos2;
            }
            public _#postfix#_add_(IGrammar grammar) : base(10, '\0', '?')
            {
                this._grammar = (CalcParser.GrammarImpl)grammar;
            }
        }
        public class _#postfix#_cond_ : ExtensionPostfixBase<CalcParser.Expr>
        {
            private readonly CalcParser.GrammarImpl _grammar;
            public override RuleDescriptor Descriptor
            {
                get
                {
                    return CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_cond_.StaticDescriptor;
                }
            }
            public override int Parse(int startPos, int pos, string text, int[] bestOffsets, ref CalcParser.Expr result)
            {
                bool isBest = false;
                NToken token_2 = default(NToken);
                CalcParser.Expr token_3 = null;
                NToken token_4 = default(NToken);
                CalcParser.Expr token_5 = null;
                CalcParser.Expr prefixResult = result;
                int seqResult = 0;
                CalcParser.Expr token_6 = prefixResult;
                bool _N_cache_12561 = pos >= 0;
                bool arg_BF_0;
                if (_N_cache_12561)
                {
                    if (true)
                    {
                        if (isBest)
                        {
                            arg_BF_0 = true;
                        }
                        else
                        {
                            isBest = (bestOffsets[0] < pos);
                            arg_BF_0 = (isBest || bestOffsets[0] == pos);
                        }
                        goto IL_B4;
                    }
                }
                arg_BF_0 = false;
                IL_B4:
                bool flag = arg_BF_0;
                if (!flag)
                {
                    seqResult = -1;
                }
                else
                {
                    int arg_157_0;
                    if (pos < text.Length && text[pos] == '?')
                    {
                        arg_157_0 = pos + 1;
                    }
                    else
                    {
                        if (this._grammar._parsingErrors._token_cond_literal_"?"_ < pos)
                        {
                            this._grammar._parsingErrors._token_cond_literal_"?"_ = pos;
                        }
                        arg_157_0 = -1;
                    }
                    int newPos = arg_157_0;
                    if (newPos >= 0)
                    {
                        token_2 = new NToken(pos, newPos);
                    }
                    int pos2 = newPos;
                    bool _N_cache_12562 = pos2 >= 0;
                    bool arg_1E6_0;
                    if (_N_cache_12562)
                    {
                        if (true)
                        {
                            if (isBest)
                            {
                                arg_1E6_0 = true;
                            }
                            else
                            {
                                isBest = (bestOffsets[1] < pos2);
                                arg_1E6_0 = (isBest || bestOffsets[1] == pos2);
                            }
                            goto IL_1DB;
                        }
                    }
                    arg_1E6_0 = false;
                    IL_1DB:
                    bool flag2 = arg_1E6_0;
                    if (!flag2)
                    {
                        seqResult = -1;
                    }
                    else
                    {
                        int ofs = pos2;
                        int pos3 = this._grammar._#_s_(pos2, text);
                        bool _N_cache_12563 = pos3 >= 0;
                        bool arg_27F_0;
                        if (_N_cache_12563)
                        {
                            if (true)
                            {
                                if (isBest)
                                {
                                    arg_27F_0 = true;
                                }
                                else
                                {
                                    isBest = (bestOffsets[2] < pos3);
                                    arg_27F_0 = (isBest || bestOffsets[2] == pos3);
                                }
                                goto IL_274;
                            }
                        }
                        arg_27F_0 = false;
                        IL_274:
                        bool flag3 = arg_27F_0;
                        if (!flag3)
                        {
                            seqResult = -1;
                        }
                        else
                        {
                            int ofs2 = pos3;
                            int pos4 = this._grammar._#_expr_(pos3, text, 0, ref token_3);
                            bool _N_cache_12564 = pos4 >= 0;
                            bool arg_31B_0;
                            if (_N_cache_12564)
                            {
                                if (true)
                                {
                                    if (isBest)
                                    {
                                        arg_31B_0 = true;
                                    }
                                    else
                                    {
                                        isBest = (bestOffsets[3] < pos4);
                                        arg_31B_0 = (isBest || bestOffsets[3] == pos4);
                                    }
                                    goto IL_310;
                                }
                            }
                            arg_31B_0 = false;
                            IL_310:
                            bool flag4 = arg_31B_0;
                            if (!flag4)
                            {
                                seqResult = -1;
                            }
                            else
                            {
                                int ofs3 = pos4;
                                int arg_3B3_0;
                                if (pos4 < text.Length && text[pos4] == ':')
                                {
                                    arg_3B3_0 = pos4 + 1;
                                }
                                else
                                {
                                    if (this._grammar._parsingErrors._token_cond_literal_":"_ < pos4)
                                    {
                                        this._grammar._parsingErrors._token_cond_literal_":"_ = pos4;
                                    }
                                    arg_3B3_0 = -1;
                                }
                                int newPos2 = arg_3B3_0;
                                if (newPos2 >= 0)
                                {
                                    token_4 = new NToken(pos4, newPos2);
                                }
                                int pos5 = newPos2;
                                bool _N_cache_12565 = pos5 >= 0;
                                bool arg_442_0;
                                if (_N_cache_12565)
                                {
                                    if (true)
                                    {
                                        if (isBest)
                                        {
                                            arg_442_0 = true;
                                        }
                                        else
                                        {
                                            isBest = (bestOffsets[4] < pos5);
                                            arg_442_0 = (isBest || bestOffsets[4] == pos5);
                                        }
                                        goto IL_437;
                                    }
                                }
                                arg_442_0 = false;
                                IL_437:
                                bool flag5 = arg_442_0;
                                if (!flag5)
                                {
                                    seqResult = -1;
                                }
                                else
                                {
                                    int ofs4 = pos5;
                                    int pos6 = this._grammar._#_s_(pos5, text);
                                    bool _N_cache_12566 = pos6 >= 0;
                                    bool arg_4DB_0;
                                    if (_N_cache_12566)
                                    {
                                        if (true)
                                        {
                                            if (isBest)
                                            {
                                                arg_4DB_0 = true;
                                            }
                                            else
                                            {
                                                isBest = (bestOffsets[5] < pos6);
                                                arg_4DB_0 = (isBest || bestOffsets[5] == pos6);
                                            }
                                            goto IL_4D0;
                                        }
                                    }
                                    arg_4DB_0 = false;
                                    IL_4D0:
                                    bool flag6 = arg_4DB_0;
                                    if (!flag6)
                                    {
                                        seqResult = -1;
                                    }
                                    else
                                    {
                                        int ofs5 = pos6;
                                        int pos7 = this._grammar._#_expr_(pos6, text, 0, ref token_5);
                                        bool _N_cache_12567 = pos7 >= 0;
                                        bool arg_577_0;
                                        if (_N_cache_12567)
                                        {
                                            if (true)
                                            {
                                                if (isBest)
                                                {
                                                    arg_577_0 = true;
                                                }
                                                else
                                                {
                                                    isBest = (bestOffsets[6] < pos7);
                                                    arg_577_0 = (isBest || bestOffsets[6] == pos7);
                                                }
                                                goto IL_56C;
                                            }
                                        }
                                        arg_577_0 = false;
                                        IL_56C:
                                        bool flag7 = arg_577_0;
                                        if (!flag7)
                                        {
                                            seqResult = -1;
                                        }
                                        else
                                        {
                                            int ofs6 = pos7;
                                            int arg_623_0;
                                            if (isBest)
                                            {
                                                bestOffsets[0] = pos;
                                                bestOffsets[1] = ofs;
                                                bestOffsets[2] = ofs2;
                                                bestOffsets[3] = ofs3;
                                                bestOffsets[4] = ofs4;
                                                bestOffsets[5] = ofs5;
                                                bestOffsets[6] = ofs6;
                                                int i = 7;
                                                while (i < bestOffsets.Length && bestOffsets[i] >= 0)
                                                {
                                                    bestOffsets[i] = -1;
                                                    i++;
                                                }
                                                arg_623_0 = pos7;
                                            }
                                            else
                                            {
                                                arg_623_0 = -1;
                                            }
                                            seqResult = arg_623_0;
                                        }
                                    }
                                }
                            }
                        }
                    }
                }
                int newPos3 = seqResult;
                if (newPos3 >= 0)
                {
                    result = new CalcParser.Cond.Ast(new Location(this._grammar._parsingSource, token_6.get_Location().get_StartPos(), token_5.get_Location().get_EndPos()), list<ErrorInfo>.Nil._N_constant_object, token_6, token_2, token_3, token_4, token_5);
                }
                return newPos3;
            }
            public _#postfix#_cond_(IGrammar grammar) : base(301, '\0', '?')
            {
                this._grammar = (CalcParser.GrammarImpl)grammar;
            }
        }
        public class _#postfix#_div_ : ExtensionPostfixBase<CalcParser.Expr>
        {
            private readonly CalcParser.GrammarImpl _grammar;
            public override RuleDescriptor Descriptor
            {
                get
                {
                    return CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_div_.StaticDescriptor;
                }
            }
            public override int Parse(int startPos, int pos, string text, int[] bestOffsets, ref CalcParser.Expr result)
            {
                bool isBest = false;
                NToken token_2 = default(NToken);
                CalcParser.Expr token_3 = null;
                CalcParser.Expr prefixResult = result;
                int seqResult = 0;
                CalcParser.Expr token_4 = prefixResult;
                bool _N_cache_12741 = pos >= 0;
                bool arg_AE_0;
                if (_N_cache_12741)
                {
                    if (true)
                    {
                        if (isBest)
                        {
                            arg_AE_0 = true;
                        }
                        else
                        {
                            isBest = (bestOffsets[0] < pos);
                            arg_AE_0 = (isBest || bestOffsets[0] == pos);
                        }
                        goto IL_A3;
                    }
                }
                arg_AE_0 = false;
                IL_A3:
                bool flag = arg_AE_0;
                if (!flag)
                {
                    seqResult = -1;
                }
                else
                {
                    int arg_146_0;
                    if (pos < text.Length && text[pos] == '/')
                    {
                        arg_146_0 = pos + 1;
                    }
                    else
                    {
                        if (this._grammar._parsingErrors._token_div_literal_"/"_ < pos)
                        {
                            this._grammar._parsingErrors._token_div_literal_"/"_ = pos;
                        }
                        arg_146_0 = -1;
                    }
                    int newPos = arg_146_0;
                    if (newPos >= 0)
                    {
                        token_2 = new NToken(pos, newPos);
                    }
                    int pos2 = newPos;
                    bool _N_cache_12742 = pos2 >= 0;
                    bool arg_1D5_0;
                    if (_N_cache_12742)
                    {
                        if (true)
                        {
                            if (isBest)
                            {
                                arg_1D5_0 = true;
                            }
                            else
                            {
                                isBest = (bestOffsets[1] < pos2);
                                arg_1D5_0 = (isBest || bestOffsets[1] == pos2);
                            }
                            goto IL_1CA;
                        }
                    }
                    arg_1D5_0 = false;
                    IL_1CA:
                    bool flag2 = arg_1D5_0;
                    if (!flag2)
                    {
                        seqResult = -1;
                    }
                    else
                    {
                        int ofs = pos2;
                        int pos3 = this._grammar._#_s_(pos2, text);
                        bool _N_cache_12743 = pos3 >= 0;
                        bool arg_26E_0;
                        if (_N_cache_12743)
                        {
                            if (true)
                            {
                                if (isBest)
                                {
                                    arg_26E_0 = true;
                                }
                                else
                                {
                                    isBest = (bestOffsets[2] < pos3);
                                    arg_26E_0 = (isBest || bestOffsets[2] == pos3);
                                }
                                goto IL_263;
                            }
                        }
                        arg_26E_0 = false;
                        IL_263:
                        bool flag3 = arg_26E_0;
                        if (!flag3)
                        {
                            seqResult = -1;
                        }
                        else
                        {
                            int ofs2 = pos3;
                            int pos4 = this._grammar._#_expr_(pos3, text, 20, ref token_3);
                            bool _N_cache_12744 = pos4 >= 0;
                            bool arg_30B_0;
                            if (_N_cache_12744)
                            {
                                if (true)
                                {
                                    if (isBest)
                                    {
                                        arg_30B_0 = true;
                                    }
                                    else
                                    {
                                        isBest = (bestOffsets[3] < pos4);
                                        arg_30B_0 = (isBest || bestOffsets[3] == pos4);
                                    }
                                    goto IL_300;
                                }
                            }
                            arg_30B_0 = false;
                            IL_300:
                            bool flag4 = arg_30B_0;
                            if (!flag4)
                            {
                                seqResult = -1;
                            }
                            else
                            {
                                int ofs3 = pos4;
                                int arg_3A2_0;
                                if (isBest)
                                {
                                    bestOffsets[0] = pos;
                                    bestOffsets[1] = ofs;
                                    bestOffsets[2] = ofs2;
                                    bestOffsets[3] = ofs3;
                                    int i = 4;
                                    while (i < bestOffsets.Length && bestOffsets[i] >= 0)
                                    {
                                        bestOffsets[i] = -1;
                                        i++;
                                    }
                                    arg_3A2_0 = pos4;
                                }
                                else
                                {
                                    arg_3A2_0 = -1;
                                }
                                seqResult = arg_3A2_0;
                            }
                        }
                    }
                }
                int newPos2 = seqResult;
                if (newPos2 >= 0)
                {
                    result = new CalcParser.Div.Ast(new Location(this._grammar._parsingSource, token_4.get_Location().get_StartPos(), token_3.get_Location().get_EndPos()), list<ErrorInfo>.Nil._N_constant_object, token_4, token_2, token_3);
                }
                return newPos2;
            }
            public _#postfix#_div_(IGrammar grammar) : base(20, '\0', '?')
            {
                this._grammar = (CalcParser.GrammarImpl)grammar;
            }
        }
        public class _#postfix#_mod_ : ExtensionPostfixBase<CalcParser.Expr>
        {
            private readonly CalcParser.GrammarImpl _grammar;
            public override RuleDescriptor Descriptor
            {
                get
                {
                    return CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_mod_.StaticDescriptor;
                }
            }
            public override int Parse(int startPos, int pos, string text, int[] bestOffsets, ref CalcParser.Expr result)
            {
                bool isBest = false;
                NToken token_2 = default(NToken);
                CalcParser.Expr token_3 = null;
                CalcParser.Expr prefixResult = result;
                int seqResult = 0;
                CalcParser.Expr token_4 = prefixResult;
                bool _N_cache_12867 = pos >= 0;
                bool arg_AE_0;
                if (_N_cache_12867)
                {
                    if (true)
                    {
                        if (isBest)
                        {
                            arg_AE_0 = true;
                        }
                        else
                        {
                            isBest = (bestOffsets[0] < pos);
                            arg_AE_0 = (isBest || bestOffsets[0] == pos);
                        }
                        goto IL_A3;
                    }
                }
                arg_AE_0 = false;
                IL_A3:
                bool flag = arg_AE_0;
                if (!flag)
                {
                    seqResult = -1;
                }
                else
                {
                    int arg_146_0;
                    if (pos < text.Length && text[pos] == '%')
                    {
                        arg_146_0 = pos + 1;
                    }
                    else
                    {
                        if (this._grammar._parsingErrors._token_mod_literal_"%"_ < pos)
                        {
                            this._grammar._parsingErrors._token_mod_literal_"%"_ = pos;
                        }
                        arg_146_0 = -1;
                    }
                    int newPos = arg_146_0;
                    if (newPos >= 0)
                    {
                        token_2 = new NToken(pos, newPos);
                    }
                    int pos2 = newPos;
                    bool _N_cache_12868 = pos2 >= 0;
                    bool arg_1D5_0;
                    if (_N_cache_12868)
                    {
                        if (true)
                        {
                            if (isBest)
                            {
                                arg_1D5_0 = true;
                            }
                            else
                            {
                                isBest = (bestOffsets[1] < pos2);
                                arg_1D5_0 = (isBest || bestOffsets[1] == pos2);
                            }
                            goto IL_1CA;
                        }
                    }
                    arg_1D5_0 = false;
                    IL_1CA:
                    bool flag2 = arg_1D5_0;
                    if (!flag2)
                    {
                        seqResult = -1;
                    }
                    else
                    {
                        int ofs = pos2;
                        int pos3 = this._grammar._#_s_(pos2, text);
                        bool _N_cache_12869 = pos3 >= 0;
                        bool arg_26E_0;
                        if (_N_cache_12869)
                        {
                            if (true)
                            {
                                if (isBest)
                                {
                                    arg_26E_0 = true;
                                }
                                else
                                {
                                    isBest = (bestOffsets[2] < pos3);
                                    arg_26E_0 = (isBest || bestOffsets[2] == pos3);
                                }
                                goto IL_263;
                            }
                        }
                        arg_26E_0 = false;
                        IL_263:
                        bool flag3 = arg_26E_0;
                        if (!flag3)
                        {
                            seqResult = -1;
                        }
                        else
                        {
                            int ofs2 = pos3;
                            int pos4 = this._grammar._#_expr_(pos3, text, 20, ref token_3);
                            bool _N_cache_12870 = pos4 >= 0;
                            bool arg_30B_0;
                            if (_N_cache_12870)
                            {
                                if (true)
                                {
                                    if (isBest)
                                    {
                                        arg_30B_0 = true;
                                    }
                                    else
                                    {
                                        isBest = (bestOffsets[3] < pos4);
                                        arg_30B_0 = (isBest || bestOffsets[3] == pos4);
                                    }
                                    goto IL_300;
                                }
                            }
                            arg_30B_0 = false;
                            IL_300:
                            bool flag4 = arg_30B_0;
                            if (!flag4)
                            {
                                seqResult = -1;
                            }
                            else
                            {
                                int ofs3 = pos4;
                                int arg_3A2_0;
                                if (isBest)
                                {
                                    bestOffsets[0] = pos;
                                    bestOffsets[1] = ofs;
                                    bestOffsets[2] = ofs2;
                                    bestOffsets[3] = ofs3;
                                    int i = 4;
                                    while (i < bestOffsets.Length && bestOffsets[i] >= 0)
                                    {
                                        bestOffsets[i] = -1;
                                        i++;
                                    }
                                    arg_3A2_0 = pos4;
                                }
                                else
                                {
                                    arg_3A2_0 = -1;
                                }
                                seqResult = arg_3A2_0;
                            }
                        }
                    }
                }
                int newPos2 = seqResult;
                if (newPos2 >= 0)
                {
                    result = new CalcParser.Mod.Ast(new Location(this._grammar._parsingSource, token_4.get_Location().get_StartPos(), token_3.get_Location().get_EndPos()), list<ErrorInfo>.Nil._N_constant_object, token_4, token_2, token_3);
                }
                return newPos2;
            }
            public _#postfix#_mod_(IGrammar grammar) : base(20, '\0', '?')
            {
                this._grammar = (CalcParser.GrammarImpl)grammar;
            }
        }
        public class _#postfix#_mul_ : ExtensionPostfixBase<CalcParser.Expr>
        {
            private readonly CalcParser.GrammarImpl _grammar;
            public override RuleDescriptor Descriptor
            {
                get
                {
                    return CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_mul_.StaticDescriptor;
                }
            }
            public override int Parse(int startPos, int pos, string text, int[] bestOffsets, ref CalcParser.Expr result)
            {
                bool isBest = false;
                NToken token_2 = default(NToken);
                CalcParser.Expr token_3 = null;
                CalcParser.Expr prefixResult = result;
                int seqResult = 0;
                CalcParser.Expr token_4 = prefixResult;
                bool _N_cache_12993 = pos >= 0;
                bool arg_AE_0;
                if (_N_cache_12993)
                {
                    if (true)
                    {
                        if (isBest)
                        {
                            arg_AE_0 = true;
                        }
                        else
                        {
                            isBest = (bestOffsets[0] < pos);
                            arg_AE_0 = (isBest || bestOffsets[0] == pos);
                        }
                        goto IL_A3;
                    }
                }
                arg_AE_0 = false;
                IL_A3:
                bool flag = arg_AE_0;
                if (!flag)
                {
                    seqResult = -1;
                }
                else
                {
                    int arg_146_0;
                    if (pos < text.Length && text[pos] == '*')
                    {
                        arg_146_0 = pos + 1;
                    }
                    else
                    {
                        if (this._grammar._parsingErrors._token_mul_literal_"*"_ < pos)
                        {
                            this._grammar._parsingErrors._token_mul_literal_"*"_ = pos;
                        }
                        arg_146_0 = -1;
                    }
                    int newPos = arg_146_0;
                    if (newPos >= 0)
                    {
                        token_2 = new NToken(pos, newPos);
                    }
                    int pos2 = newPos;
                    bool _N_cache_12994 = pos2 >= 0;
                    bool arg_1D5_0;
                    if (_N_cache_12994)
                    {
                        if (true)
                        {
                            if (isBest)
                            {
                                arg_1D5_0 = true;
                            }
                            else
                            {
                                isBest = (bestOffsets[1] < pos2);
                                arg_1D5_0 = (isBest || bestOffsets[1] == pos2);
                            }
                            goto IL_1CA;
                        }
                    }
                    arg_1D5_0 = false;
                    IL_1CA:
                    bool flag2 = arg_1D5_0;
                    if (!flag2)
                    {
                        seqResult = -1;
                    }
                    else
                    {
                        int ofs = pos2;
                        int pos3 = this._grammar._#_s_(pos2, text);
                        bool _N_cache_12995 = pos3 >= 0;
                        bool arg_26E_0;
                        if (_N_cache_12995)
                        {
                            if (true)
                            {
                                if (isBest)
                                {
                                    arg_26E_0 = true;
                                }
                                else
                                {
                                    isBest = (bestOffsets[2] < pos3);
                                    arg_26E_0 = (isBest || bestOffsets[2] == pos3);
                                }
                                goto IL_263;
                            }
                        }
                        arg_26E_0 = false;
                        IL_263:
                        bool flag3 = arg_26E_0;
                        if (!flag3)
                        {
                            seqResult = -1;
                        }
                        else
                        {
                            int ofs2 = pos3;
                            int pos4 = this._grammar._#_expr_(pos3, text, 20, ref token_3);
                            bool _N_cache_12996 = pos4 >= 0;
                            bool arg_30B_0;
                            if (_N_cache_12996)
                            {
                                if (true)
                                {
                                    if (isBest)
                                    {
                                        arg_30B_0 = true;
                                    }
                                    else
                                    {
                                        isBest = (bestOffsets[3] < pos4);
                                        arg_30B_0 = (isBest || bestOffsets[3] == pos4);
                                    }
                                    goto IL_300;
                                }
                            }
                            arg_30B_0 = false;
                            IL_300:
                            bool flag4 = arg_30B_0;
                            if (!flag4)
                            {
                                seqResult = -1;
                            }
                            else
                            {
                                int ofs3 = pos4;
                                int arg_3A2_0;
                                if (isBest)
                                {
                                    bestOffsets[0] = pos;
                                    bestOffsets[1] = ofs;
                                    bestOffsets[2] = ofs2;
                                    bestOffsets[3] = ofs3;
                                    int i = 4;
                                    while (i < bestOffsets.Length && bestOffsets[i] >= 0)
                                    {
                                        bestOffsets[i] = -1;
                                        i++;
                                    }
                                    arg_3A2_0 = pos4;
                                }
                                else
                                {
                                    arg_3A2_0 = -1;
                                }
                                seqResult = arg_3A2_0;
                            }
                        }
                    }
                }
                int newPos2 = seqResult;
                if (newPos2 >= 0)
                {
                    result = new CalcParser.Mul.Ast(new Location(this._grammar._parsingSource, token_4.get_Location().get_StartPos(), token_3.get_Location().get_EndPos()), list<ErrorInfo>.Nil._N_constant_object, token_4, token_2, token_3);
                }
                return newPos2;
            }
            public _#postfix#_mul_(IGrammar grammar) : base(20, '\0', '?')
            {
                this._grammar = (CalcParser.GrammarImpl)grammar;
            }
        }
        public class _#prefix#__neg_ : ExtensionPrefixBase<CalcParser.Expr>
        {
            private readonly CalcParser.GrammarImpl _grammar;
            public override RuleDescriptor Descriptor
            {
                get
                {
                    return CalcParser.GrammarImpl.GrammarDescriptorImpl._#prefix#__neg_.StaticDescriptor;
                }
            }
            public override int Parse(int pos, string text, int[] bestOffsets, ref CalcParser.Expr result)
            {
                bool isBest = false;
                NToken token_ = default(NToken);
                CalcParser.Expr token_2 = null;
                int seqResult = 0;
                int arg_A1_0;
                if (pos < text.Length && text[pos] == '-')
                {
                    arg_A1_0 = pos + 1;
                }
                else
                {
                    if (this._grammar._parsingErrors._token_neg_literal_"-"_ < pos)
                    {
                        this._grammar._parsingErrors._token_neg_literal_"-"_ = pos;
                    }
                    arg_A1_0 = -1;
                }
                int newPos = arg_A1_0;
                if (newPos >= 0)
                {
                    token_ = new NToken(pos, newPos);
                }
                int pos2 = newPos;
                bool _N_cache_13124 = pos2 >= 0;
                bool arg_12C_0;
                if (_N_cache_13124)
                {
                    if (true)
                    {
                        if (isBest)
                        {
                            arg_12C_0 = true;
                        }
                        else
                        {
                            isBest = (bestOffsets[0] < pos2);
                            arg_12C_0 = (isBest || bestOffsets[0] == pos2);
                        }
                        goto IL_121;
                    }
                }
                arg_12C_0 = false;
                IL_121:
                bool flag = arg_12C_0;
                if (!flag)
                {
                    seqResult = -1;
                }
                else
                {
                    int ofs0 = pos2;
                    int pos3 = this._grammar._#_s_(pos2, text);
                    bool _N_cache_13125 = pos3 >= 0;
                    bool arg_1C3_0;
                    if (_N_cache_13125)
                    {
                        if (true)
                        {
                            if (isBest)
                            {
                                arg_1C3_0 = true;
                            }
                            else
                            {
                                isBest = (bestOffsets[1] < pos3);
                                arg_1C3_0 = (isBest || bestOffsets[1] == pos3);
                            }
                            goto IL_1B8;
                        }
                    }
                    arg_1C3_0 = false;
                    IL_1B8:
                    bool flag2 = arg_1C3_0;
                    if (!flag2)
                    {
                        seqResult = -1;
                    }
                    else
                    {
                        int ofs = pos3;
                        int pos4 = this._grammar._#_expr_(pos3, text, 100, ref token_2);
                        bool _N_cache_13126 = pos4 >= 0;
                        bool arg_25E_0;
                        if (_N_cache_13126)
                        {
                            if (true)
                            {
                                if (isBest)
                                {
                                    arg_25E_0 = true;
                                }
                                else
                                {
                                    isBest = (bestOffsets[2] < pos4);
                                    arg_25E_0 = (isBest || bestOffsets[2] == pos4);
                                }
                                goto IL_253;
                            }
                        }
                        arg_25E_0 = false;
                        IL_253:
                        bool flag3 = arg_25E_0;
                        if (!flag3)
                        {
                            seqResult = -1;
                        }
                        else
                        {
                            int ofs2 = pos4;
                            int arg_2E8_0;
                            if (isBest)
                            {
                                bestOffsets[0] = ofs0;
                                bestOffsets[1] = ofs;
                                bestOffsets[2] = ofs2;
                                int i = 3;
                                while (i < bestOffsets.Length && bestOffsets[i] >= 0)
                                {
                                    bestOffsets[i] = -1;
                                    i++;
                                }
                                arg_2E8_0 = pos4;
                            }
                            else
                            {
                                arg_2E8_0 = -1;
                            }
                            seqResult = arg_2E8_0;
                        }
                    }
                }
                int newPos2 = seqResult;
                if (newPos2 >= 0)
                {
                    result = new CalcParser.Neg.Ast(new Location(this._grammar._parsingSource, token_.get_StartPos(), token_2.get_Location().get_EndPos()), list<ErrorInfo>.Nil._N_constant_object, token_, token_2);
                }
                return newPos2;
            }
            public _#prefix#__neg_(IGrammar grammar) : base('\0', '?')
            {
                this._grammar = (CalcParser.GrammarImpl)grammar;
            }
        }
        public class _#prefix#__num_ : ExtensionPrefixBase<CalcParser.Expr>
        {
            private readonly CalcParser.GrammarImpl _grammar;
            public override RuleDescriptor Descriptor
            {
                get
                {
                    return CalcParser.GrammarImpl.GrammarDescriptorImpl._#prefix#__num_.StaticDescriptor;
                }
            }
            public override int Parse(int pos, string text, int[] bestOffsets, ref CalcParser.Expr result)
            {
                bool isBest = false;
                NumParser.Number token_ = null;
                int seqResult = 0;
                int pos2 = this._grammar._#grammar#1._#_number_(pos, text, ref token_);
                bool _N_cache_13212 = pos2 >= 0;
                bool arg_9E_0;
                if (_N_cache_13212)
                {
                    if (true)
                    {
                        if (isBest)
                        {
                            arg_9E_0 = true;
                        }
                        else
                        {
                            isBest = (bestOffsets[0] < pos2);
                            arg_9E_0 = (isBest || bestOffsets[0] == pos2);
                        }
                        goto IL_93;
                    }
                }
                arg_9E_0 = false;
                IL_93:
                bool flag = arg_9E_0;
                if (!flag)
                {
                    seqResult = -1;
                }
                else
                {
                    int ofs0 = pos2;
                    int pos3 = this._grammar._#_s_(pos2, text);
                    bool _N_cache_13213 = pos3 >= 0;
                    bool arg_134_0;
                    if (_N_cache_13213)
                    {
                        if (true)
                        {
                            if (isBest)
                            {
                                arg_134_0 = true;
                            }
                            else
                            {
                                isBest = (bestOffsets[1] < pos3);
                                arg_134_0 = (isBest || bestOffsets[1] == pos3);
                            }
                            goto IL_129;
                        }
                    }
                    arg_134_0 = false;
                    IL_129:
                    bool flag2 = arg_134_0;
                    if (!flag2)
                    {
                        seqResult = -1;
                    }
                    else
                    {
                        int ofs = pos3;
                        int arg_1B7_0;
                        if (isBest)
                        {
                            bestOffsets[0] = ofs0;
                            bestOffsets[1] = ofs;
                            int i = 2;
                            while (i < bestOffsets.Length && bestOffsets[i] >= 0)
                            {
                                bestOffsets[i] = -1;
                                i++;
                            }
                            arg_1B7_0 = pos3;
                        }
                        else
                        {
                            arg_1B7_0 = -1;
                        }
                        seqResult = arg_1B7_0;
                    }
                }
                int newPos = seqResult;
                if (newPos >= 0)
                {
                    result = new CalcParser.Num.Ast(new Location(this._grammar._parsingSource, token_.get_Location().get_StartPos(), token_.get_Location().get_EndPos()), list<ErrorInfo>.Nil._N_constant_object, token_);
                }
                return newPos;
            }
            public _#prefix#__num_(IGrammar grammar) : base('\0', '?')
            {
                this._grammar = (CalcParser.GrammarImpl)grammar;
            }
        }
        public class _#postfix#_postfixDec_ : ExtensionPostfixBase<CalcParser.Expr>
        {
            private readonly CalcParser.GrammarImpl _grammar;
            public override RuleDescriptor Descriptor
            {
                get
                {
                    return CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_postfixDec_.StaticDescriptor;
                }
            }
            public override int Parse(int startPos, int pos, string text, int[] bestOffsets, ref CalcParser.Expr result)
            {
                bool isBest = false;
                NToken token_2 = default(NToken);
                CalcParser.Expr prefixResult = result;
                int seqResult = 0;
                CalcParser.Expr token_3 = prefixResult;
                bool _N_cache_13294 = pos >= 0;
                bool arg_AA_0;
                if (_N_cache_13294)
                {
                    if (true)
                    {
                        if (isBest)
                        {
                            arg_AA_0 = true;
                        }
                        else
                        {
                            isBest = (bestOffsets[0] < pos);
                            arg_AA_0 = (isBest || bestOffsets[0] == pos);
                        }
                        goto IL_9F;
                    }
                }
                arg_AA_0 = false;
                IL_9F:
                bool flag = arg_AA_0;
                if (!flag)
                {
                    seqResult = -1;
                }
                else
                {
                    int arg_15F_0;
                    if (pos + 1 < text.Length && text[pos] == '-' && text[pos + 1] == '-')
                    {
                        arg_15F_0 = pos + 2;
                    }
                    else
                    {
                        if (this._grammar._parsingErrors._token_postfixDec_literal_"--"_ < pos)
                        {
                            this._grammar._parsingErrors._token_postfixDec_literal_"--"_ = pos;
                        }
                        arg_15F_0 = -1;
                    }
                    int newPos = arg_15F_0;
                    if (newPos >= 0)
                    {
                        token_2 = new NToken(pos, newPos);
                    }
                    int pos2 = newPos;
                    bool _N_cache_13295 = pos2 >= 0;
                    bool arg_1EE_0;
                    if (_N_cache_13295)
                    {
                        if (true)
                        {
                            if (isBest)
                            {
                                arg_1EE_0 = true;
                            }
                            else
                            {
                                isBest = (bestOffsets[1] < pos2);
                                arg_1EE_0 = (isBest || bestOffsets[1] == pos2);
                            }
                            goto IL_1E3;
                        }
                    }
                    arg_1EE_0 = false;
                    IL_1E3:
                    bool flag2 = arg_1EE_0;
                    if (!flag2)
                    {
                        seqResult = -1;
                    }
                    else
                    {
                        int ofs = pos2;
                        int pos3 = this._grammar._#_s_(pos2, text);
                        bool _N_cache_13296 = pos3 >= 0;
                        bool arg_287_0;
                        if (_N_cache_13296)
                        {
                            if (true)
                            {
                                if (isBest)
                                {
                                    arg_287_0 = true;
                                }
                                else
                                {
                                    isBest = (bestOffsets[2] < pos3);
                                    arg_287_0 = (isBest || bestOffsets[2] == pos3);
                                }
                                goto IL_27C;
                            }
                        }
                        arg_287_0 = false;
                        IL_27C:
                        bool flag3 = arg_287_0;
                        if (!flag3)
                        {
                            seqResult = -1;
                        }
                        else
                        {
                            int ofs2 = pos3;
                            int arg_317_0;
                            if (isBest)
                            {
                                bestOffsets[0] = pos;
                                bestOffsets[1] = ofs;
                                bestOffsets[2] = ofs2;
                                int i = 3;
                                while (i < bestOffsets.Length && bestOffsets[i] >= 0)
                                {
                                    bestOffsets[i] = -1;
                                    i++;
                                }
                                arg_317_0 = pos3;
                            }
                            else
                            {
                                arg_317_0 = -1;
                            }
                            seqResult = arg_317_0;
                        }
                    }
                }
                int newPos2 = seqResult;
                if (newPos2 >= 0)
                {
                    result = new CalcParser.PostfixDec.Ast(new Location(this._grammar._parsingSource, token_3.get_Location().get_StartPos(), token_2.get_EndPos()), list<ErrorInfo>.Nil._N_constant_object, token_3, token_2);
                }
                return newPos2;
            }
            public _#postfix#_postfixDec_(IGrammar grammar) : base(200, '\0', '?')
            {
                this._grammar = (CalcParser.GrammarImpl)grammar;
            }
        }
        public class _#postfix#_pow_ : ExtensionPostfixBase<CalcParser.Expr>
        {
            private readonly CalcParser.GrammarImpl _grammar;
            public override RuleDescriptor Descriptor
            {
                get
                {
                    return CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_pow_.StaticDescriptor;
                }
            }
            public override int Parse(int startPos, int pos, string text, int[] bestOffsets, ref CalcParser.Expr result)
            {
                bool isBest = false;
                NToken token_2 = default(NToken);
                CalcParser.Expr token_3 = null;
                CalcParser.Expr prefixResult = result;
                int seqResult = 0;
                CalcParser.Expr token_4 = prefixResult;
                bool _N_cache_13409 = pos >= 0;
                bool arg_AE_0;
                if (_N_cache_13409)
                {
                    if (true)
                    {
                        if (isBest)
                        {
                            arg_AE_0 = true;
                        }
                        else
                        {
                            isBest = (bestOffsets[0] < pos);
                            arg_AE_0 = (isBest || bestOffsets[0] == pos);
                        }
                        goto IL_A3;
                    }
                }
                arg_AE_0 = false;
                IL_A3:
                bool flag = arg_AE_0;
                if (!flag)
                {
                    seqResult = -1;
                }
                else
                {
                    int arg_146_0;
                    if (pos < text.Length && text[pos] == '^')
                    {
                        arg_146_0 = pos + 1;
                    }
                    else
                    {
                        if (this._grammar._parsingErrors._token_pow_literal_"^"_ < pos)
                        {
                            this._grammar._parsingErrors._token_pow_literal_"^"_ = pos;
                        }
                        arg_146_0 = -1;
                    }
                    int newPos = arg_146_0;
                    if (newPos >= 0)
                    {
                        token_2 = new NToken(pos, newPos);
                    }
                    int pos2 = newPos;
                    bool _N_cache_13410 = pos2 >= 0;
                    bool arg_1D5_0;
                    if (_N_cache_13410)
                    {
                        if (true)
                        {
                            if (isBest)
                            {
                                arg_1D5_0 = true;
                            }
                            else
                            {
                                isBest = (bestOffsets[1] < pos2);
                                arg_1D5_0 = (isBest || bestOffsets[1] == pos2);
                            }
                            goto IL_1CA;
                        }
                    }
                    arg_1D5_0 = false;
                    IL_1CA:
                    bool flag2 = arg_1D5_0;
                    if (!flag2)
                    {
                        seqResult = -1;
                    }
                    else
                    {
                        int ofs = pos2;
                        int pos3 = this._grammar._#_s_(pos2, text);
                        bool _N_cache_13411 = pos3 >= 0;
                        bool arg_26E_0;
                        if (_N_cache_13411)
                        {
                            if (true)
                            {
                                if (isBest)
                                {
                                    arg_26E_0 = true;
                                }
                                else
                                {
                                    isBest = (bestOffsets[2] < pos3);
                                    arg_26E_0 = (isBest || bestOffsets[2] == pos3);
                                }
                                goto IL_263;
                            }
                        }
                        arg_26E_0 = false;
                        IL_263:
                        bool flag3 = arg_26E_0;
                        if (!flag3)
                        {
                            seqResult = -1;
                        }
                        else
                        {
                            int ofs2 = pos3;
                            int pos4 = this._grammar._#_expr_(pos3, text, 30, ref token_3);
                            bool _N_cache_13412 = pos4 >= 0;
                            bool arg_30B_0;
                            if (_N_cache_13412)
                            {
                                if (true)
                                {
                                    if (isBest)
                                    {
                                        arg_30B_0 = true;
                                    }
                                    else
                                    {
                                        isBest = (bestOffsets[3] < pos4);
                                        arg_30B_0 = (isBest || bestOffsets[3] == pos4);
                                    }
                                    goto IL_300;
                                }
                            }
                            arg_30B_0 = false;
                            IL_300:
                            bool flag4 = arg_30B_0;
                            if (!flag4)
                            {
                                seqResult = -1;
                            }
                            else
                            {
                                int ofs3 = pos4;
                                int arg_3A2_0;
                                if (isBest)
                                {
                                    bestOffsets[0] = pos;
                                    bestOffsets[1] = ofs;
                                    bestOffsets[2] = ofs2;
                                    bestOffsets[3] = ofs3;
                                    int i = 4;
                                    while (i < bestOffsets.Length && bestOffsets[i] >= 0)
                                    {
                                        bestOffsets[i] = -1;
                                        i++;
                                    }
                                    arg_3A2_0 = pos4;
                                }
                                else
                                {
                                    arg_3A2_0 = -1;
                                }
                                seqResult = arg_3A2_0;
                            }
                        }
                    }
                }
                int newPos2 = seqResult;
                if (newPos2 >= 0)
                {
                    result = new CalcParser.Pow.Ast(new Location(this._grammar._parsingSource, token_4.get_Location().get_StartPos(), token_3.get_Location().get_EndPos()), list<ErrorInfo>.Nil._N_constant_object, token_4, token_2, token_3);
                }
                return newPos2;
            }
            public _#postfix#_pow_(IGrammar grammar) : base(31, '\0', '?')
            {
                this._grammar = (CalcParser.GrammarImpl)grammar;
            }
        }
        public class _#prefix#__prefixDec_ : ExtensionPrefixBase<CalcParser.Expr>
        {
            private readonly CalcParser.GrammarImpl _grammar;
            public override RuleDescriptor Descriptor
            {
                get
                {
                    return CalcParser.GrammarImpl.GrammarDescriptorImpl._#prefix#__prefixDec_.StaticDescriptor;
                }
            }
            public override int Parse(int pos, string text, int[] bestOffsets, ref CalcParser.Expr result)
            {
                bool isBest = false;
                NToken token_ = default(NToken);
                CalcParser.Expr token_2 = null;
                int seqResult = 0;
                int arg_BD_0;
                if (pos + 1 < text.Length && text[pos] == '-' && text[pos + 1] == '-')
                {
                    arg_BD_0 = pos + 2;
                }
                else
                {
                    if (this._grammar._parsingErrors._token_prefixDec_literal_"--"_ < pos)
                    {
                        this._grammar._parsingErrors._token_prefixDec_literal_"--"_ = pos;
                    }
                    arg_BD_0 = -1;
                }
                int newPos = arg_BD_0;
                if (newPos >= 0)
                {
                    token_ = new NToken(pos, newPos);
                }
                int pos2 = newPos;
                bool _N_cache_13543 = pos2 >= 0;
                bool arg_148_0;
                if (_N_cache_13543)
                {
                    if (true)
                    {
                        if (isBest)
                        {
                            arg_148_0 = true;
                        }
                        else
                        {
                            isBest = (bestOffsets[0] < pos2);
                            arg_148_0 = (isBest || bestOffsets[0] == pos2);
                        }
                        goto IL_13D;
                    }
                }
                arg_148_0 = false;
                IL_13D:
                bool flag = arg_148_0;
                if (!flag)
                {
                    seqResult = -1;
                }
                else
                {
                    int ofs0 = pos2;
                    int pos3 = this._grammar._#_s_(pos2, text);
                    bool _N_cache_13544 = pos3 >= 0;
                    bool arg_1DF_0;
                    if (_N_cache_13544)
                    {
                        if (true)
                        {
                            if (isBest)
                            {
                                arg_1DF_0 = true;
                            }
                            else
                            {
                                isBest = (bestOffsets[1] < pos3);
                                arg_1DF_0 = (isBest || bestOffsets[1] == pos3);
                            }
                            goto IL_1D4;
                        }
                    }
                    arg_1DF_0 = false;
                    IL_1D4:
                    bool flag2 = arg_1DF_0;
                    if (!flag2)
                    {
                        seqResult = -1;
                    }
                    else
                    {
                        int ofs = pos3;
                        int pos4 = this._grammar._#_expr_(pos3, text, 200, ref token_2);
                        bool _N_cache_13545 = pos4 >= 0;
                        bool arg_27D_0;
                        if (_N_cache_13545)
                        {
                            if (true)
                            {
                                if (isBest)
                                {
                                    arg_27D_0 = true;
                                }
                                else
                                {
                                    isBest = (bestOffsets[2] < pos4);
                                    arg_27D_0 = (isBest || bestOffsets[2] == pos4);
                                }
                                goto IL_272;
                            }
                        }
                        arg_27D_0 = false;
                        IL_272:
                        bool flag3 = arg_27D_0;
                        if (!flag3)
                        {
                            seqResult = -1;
                        }
                        else
                        {
                            int ofs2 = pos4;
                            int arg_307_0;
                            if (isBest)
                            {
                                bestOffsets[0] = ofs0;
                                bestOffsets[1] = ofs;
                                bestOffsets[2] = ofs2;
                                int i = 3;
                                while (i < bestOffsets.Length && bestOffsets[i] >= 0)
                                {
                                    bestOffsets[i] = -1;
                                    i++;
                                }
                                arg_307_0 = pos4;
                            }
                            else
                            {
                                arg_307_0 = -1;
                            }
                            seqResult = arg_307_0;
                        }
                    }
                }
                int newPos2 = seqResult;
                if (newPos2 >= 0)
                {
                    result = new CalcParser.PrefixDec.Ast(new Location(this._grammar._parsingSource, token_.get_StartPos(), token_2.get_Location().get_EndPos()), list<ErrorInfo>.Nil._N_constant_object, token_, token_2);
                }
                return newPos2;
            }
            public _#prefix#__prefixDec_(IGrammar grammar) : base('\0', '?')
            {
                this._grammar = (CalcParser.GrammarImpl)grammar;
            }
        }
        public class _#prefix#__rounds_ : ExtensionPrefixBase<CalcParser.Expr>
        {
            private readonly CalcParser.GrammarImpl _grammar;
            public override RuleDescriptor Descriptor
            {
                get
                {
                    return CalcParser.GrammarImpl.GrammarDescriptorImpl._#prefix#__rounds_.StaticDescriptor;
                }
            }
            public override int Parse(int pos, string text, int[] bestOffsets, ref CalcParser.Expr result)
            {
                bool isBest = false;
                NToken token_ = default(NToken);
                CalcParser.Expr token_2 = null;
                NToken token_3 = default(NToken);
                int seqResult = 0;
                int arg_AE_0;
                if (pos < text.Length && text[pos] == '(')
                {
                    arg_AE_0 = pos + 1;
                }
                else
                {
                    if (this._grammar._parsingErrors._token_rounds_literal_"("_ < pos)
                    {
                        this._grammar._parsingErrors._token_rounds_literal_"("_ = pos;
                    }
                    arg_AE_0 = -1;
                }
                int newPos = arg_AE_0;
                if (newPos >= 0)
                {
                    token_ = new NToken(pos, newPos);
                }
                int pos2 = newPos;
                bool _N_cache_13656 = pos2 >= 0;
                bool arg_139_0;
                if (_N_cache_13656)
                {
                    if (true)
                    {
                        if (isBest)
                        {
                            arg_139_0 = true;
                        }
                        else
                        {
                            isBest = (bestOffsets[0] < pos2);
                            arg_139_0 = (isBest || bestOffsets[0] == pos2);
                        }
                        goto IL_12E;
                    }
                }
                arg_139_0 = false;
                IL_12E:
                bool flag = arg_139_0;
                if (!flag)
                {
                    seqResult = -1;
                }
                else
                {
                    int ofs0 = pos2;
                    int pos3 = this._grammar._#_s_(pos2, text);
                    bool _N_cache_13657 = pos3 >= 0;
                    bool arg_1D0_0;
                    if (_N_cache_13657)
                    {
                        if (true)
                        {
                            if (isBest)
                            {
                                arg_1D0_0 = true;
                            }
                            else
                            {
                                isBest = (bestOffsets[1] < pos3);
                                arg_1D0_0 = (isBest || bestOffsets[1] == pos3);
                            }
                            goto IL_1C5;
                        }
                    }
                    arg_1D0_0 = false;
                    IL_1C5:
                    bool flag2 = arg_1D0_0;
                    if (!flag2)
                    {
                        seqResult = -1;
                    }
                    else
                    {
                        int ofs = pos3;
                        int pos4 = this._grammar._#_expr_(pos3, text, 0, ref token_2);
                        bool _N_cache_13658 = pos4 >= 0;
                        bool arg_26A_0;
                        if (_N_cache_13658)
                        {
                            if (true)
                            {
                                if (isBest)
                                {
                                    arg_26A_0 = true;
                                }
                                else
                                {
                                    isBest = (bestOffsets[2] < pos4);
                                    arg_26A_0 = (isBest || bestOffsets[2] == pos4);
                                }
                                goto IL_25F;
                            }
                        }
                        arg_26A_0 = false;
                        IL_25F:
                        bool flag3 = arg_26A_0;
                        if (!flag3)
                        {
                            seqResult = -1;
                        }
                        else
                        {
                            int ofs2 = pos4;
                            int arg_302_0;
                            if (pos4 < text.Length && text[pos4] == ')')
                            {
                                arg_302_0 = pos4 + 1;
                            }
                            else
                            {
                                if (this._grammar._parsingErrors._token_rounds_literal_")"_ < pos4)
                                {
                                    this._grammar._parsingErrors._token_rounds_literal_")"_ = pos4;
                                }
                                arg_302_0 = -1;
                            }
                            int newPos2 = arg_302_0;
                            if (newPos2 >= 0)
                            {
                                token_3 = new NToken(pos4, newPos2);
                            }
                            int pos5 = newPos2;
                            bool _N_cache_13659 = pos5 >= 0;
                            bool arg_38F_0;
                            if (_N_cache_13659)
                            {
                                if (true)
                                {
                                    if (isBest)
                                    {
                                        arg_38F_0 = true;
                                    }
                                    else
                                    {
                                        isBest = (bestOffsets[3] < pos5);
                                        arg_38F_0 = (isBest || bestOffsets[3] == pos5);
                                    }
                                    goto IL_384;
                                }
                            }
                            arg_38F_0 = false;
                            IL_384:
                            bool flag4 = arg_38F_0;
                            if (!flag4)
                            {
                                seqResult = -1;
                            }
                            else
                            {
                                int ofs3 = pos5;
                                int pos6 = this._grammar._#_s_(pos5, text);
                                bool _N_cache_13660 = pos6 >= 0;
                                bool arg_426_0;
                                if (_N_cache_13660)
                                {
                                    if (true)
                                    {
                                        if (isBest)
                                        {
                                            arg_426_0 = true;
                                        }
                                        else
                                        {
                                            isBest = (bestOffsets[4] < pos6);
                                            arg_426_0 = (isBest || bestOffsets[4] == pos6);
                                        }
                                        goto IL_41B;
                                    }
                                }
                                arg_426_0 = false;
                                IL_41B:
                                bool flag5 = arg_426_0;
                                if (!flag5)
                                {
                                    seqResult = -1;
                                }
                                else
                                {
                                    int ofs4 = pos6;
                                    int arg_4BC_0;
                                    if (isBest)
                                    {
                                        bestOffsets[0] = ofs0;
                                        bestOffsets[1] = ofs;
                                        bestOffsets[2] = ofs2;
                                        bestOffsets[3] = ofs3;
                                        bestOffsets[4] = ofs4;
                                        int i = 5;
                                        while (i < bestOffsets.Length && bestOffsets[i] >= 0)
                                        {
                                            bestOffsets[i] = -1;
                                            i++;
                                        }
                                        arg_4BC_0 = pos6;
                                    }
                                    else
                                    {
                                        arg_4BC_0 = -1;
                                    }
                                    seqResult = arg_4BC_0;
                                }
                            }
                        }
                    }
                }
                int newPos3 = seqResult;
                if (newPos3 >= 0)
                {
                    result = new CalcParser.Rounds.Ast(new Location(this._grammar._parsingSource, token_.get_StartPos(), token_3.get_EndPos()), list<ErrorInfo>.Nil._N_constant_object, token_, token_2, token_3);
                }
                return newPos3;
            }
            public _#prefix#__rounds_(IGrammar grammar) : base('\0', '?')
            {
                this._grammar = (CalcParser.GrammarImpl)grammar;
            }
        }
        public class _#prefix#__seq_ : ExtensionPrefixBase<CalcParser.Expr>
        {
            private readonly CalcParser.GrammarImpl _grammar;
            public override RuleDescriptor Descriptor
            {
                get
                {
                    return CalcParser.GrammarImpl.GrammarDescriptorImpl._#prefix#__seq_.StaticDescriptor;
                }
            }
            public override int Parse(int pos, string text, int[] bestOffsets, ref CalcParser.Expr result)
            {
                bool isBest = false;
                NToken token_ = default(NToken);
                list<CalcParser.Expr> token_2 = null;
                NToken token_3 = default(NToken);
                int seqResult = 0;
                int arg_AE_0;
                if (pos < text.Length && text[pos] == '{')
                {
                    arg_AE_0 = pos + 1;
                }
                else
                {
                    if (this._grammar._parsingErrors._token_seq_literal_"{"_ < pos)
                    {
                        this._grammar._parsingErrors._token_seq_literal_"{"_ = pos;
                    }
                    arg_AE_0 = -1;
                }
                int newPos = arg_AE_0;
                if (newPos >= 0)
                {
                    token_ = new NToken(pos, newPos);
                }
                int pos2 = newPos;
                bool _N_cache_13819 = pos2 >= 0;
                bool arg_139_0;
                if (_N_cache_13819)
                {
                    if (true)
                    {
                        if (isBest)
                        {
                            arg_139_0 = true;
                        }
                        else
                        {
                            isBest = (bestOffsets[0] < pos2);
                            arg_139_0 = (isBest || bestOffsets[0] == pos2);
                        }
                        goto IL_12E;
                    }
                }
                arg_139_0 = false;
                IL_12E:
                bool flag = arg_139_0;
                if (!flag)
                {
                    seqResult = -1;
                }
                else
                {
                    int ofs0 = pos2;
                    int pos3 = this._grammar._#_s_(pos2, text);
                    bool _N_cache_13820 = pos3 >= 0;
                    bool arg_1D0_0;
                    if (_N_cache_13820)
                    {
                        if (true)
                        {
                            if (isBest)
                            {
                                arg_1D0_0 = true;
                            }
                            else
                            {
                                isBest = (bestOffsets[1] < pos3);
                                arg_1D0_0 = (isBest || bestOffsets[1] == pos3);
                            }
                            goto IL_1C5;
                        }
                    }
                    arg_1D0_0 = false;
                    IL_1C5:
                    bool flag2 = arg_1D0_0;
                    if (!flag2)
                    {
                        seqResult = -1;
                    }
                    else
                    {
                        int ofs = pos3;
                        List<CalcParser.Expr> tmpList = new List<CalcParser.Expr>();
                        CalcParser.Expr token_4 = null;
                        int num = pos3;
                        while (true)
                        {
                            int newPos2 = this._grammar._#_expr_(num, text, 0, ref token_4);
                            if (newPos2 < 0)
                            {
                                break;
                            }
                            tmpList.Add(token_4);
                            num = newPos2;
                        }
                        int newPos3 = num;
                        token_2 = NCollectionsExtensions.NToList<CalcParser.Expr>(tmpList);
                        int pos4 = newPos3;
                        bool _N_cache_13821 = pos4 >= 0;
                        bool arg_2C8_0;
                        if (_N_cache_13821)
                        {
                            if (true)
                            {
                                if (isBest)
                                {
                                    arg_2C8_0 = true;
                                }
                                else
                                {
                                    isBest = (bestOffsets[2] < pos4);
                                    arg_2C8_0 = (isBest || bestOffsets[2] == pos4);
                                }
                                goto IL_2BD;
                            }
                        }
                        arg_2C8_0 = false;
                        IL_2BD:
                        bool flag3 = arg_2C8_0;
                        if (!flag3)
                        {
                            seqResult = -1;
                        }
                        else
                        {
                            int ofs2 = pos4;
                            int arg_360_0;
                            if (pos4 < text.Length && text[pos4] == '}')
                            {
                                arg_360_0 = pos4 + 1;
                            }
                            else
                            {
                                if (this._grammar._parsingErrors._token_seq_literal_"}"_ < pos4)
                                {
                                    this._grammar._parsingErrors._token_seq_literal_"}"_ = pos4;
                                }
                                arg_360_0 = -1;
                            }
                            int newPos4 = arg_360_0;
                            if (newPos4 >= 0)
                            {
                                token_3 = new NToken(pos4, newPos4);
                            }
                            int pos5 = newPos4;
                            bool _N_cache_13822 = pos5 >= 0;
                            bool arg_3ED_0;
                            if (_N_cache_13822)
                            {
                                if (true)
                                {
                                    if (isBest)
                                    {
                                        arg_3ED_0 = true;
                                    }
                                    else
                                    {
                                        isBest = (bestOffsets[3] < pos5);
                                        arg_3ED_0 = (isBest || bestOffsets[3] == pos5);
                                    }
                                    goto IL_3E2;
                                }
                            }
                            arg_3ED_0 = false;
                            IL_3E2:
                            bool flag4 = arg_3ED_0;
                            if (!flag4)
                            {
                                seqResult = -1;
                            }
                            else
                            {
                                int ofs3 = pos5;
                                int pos6 = this._grammar._#_s_(pos5, text);
                                bool _N_cache_13823 = pos6 >= 0;
                                bool arg_484_0;
                                if (_N_cache_13823)
                                {
                                    if (true)
                                    {
                                        if (isBest)
                                        {
                                            arg_484_0 = true;
                                        }
                                        else
                                        {
                                            isBest = (bestOffsets[4] < pos6);
                                            arg_484_0 = (isBest || bestOffsets[4] == pos6);
                                        }
                                        goto IL_479;
                                    }
                                }
                                arg_484_0 = false;
                                IL_479:
                                bool flag5 = arg_484_0;
                                if (!flag5)
                                {
                                    seqResult = -1;
                                }
                                else
                                {
                                    int ofs4 = pos6;
                                    int arg_51A_0;
                                    if (isBest)
                                    {
                                        bestOffsets[0] = ofs0;
                                        bestOffsets[1] = ofs;
                                        bestOffsets[2] = ofs2;
                                        bestOffsets[3] = ofs3;
                                        bestOffsets[4] = ofs4;
                                        int i = 5;
                                        while (i < bestOffsets.Length && bestOffsets[i] >= 0)
                                        {
                                            bestOffsets[i] = -1;
                                            i++;
                                        }
                                        arg_51A_0 = pos6;
                                    }
                                    else
                                    {
                                        arg_51A_0 = -1;
                                    }
                                    seqResult = arg_51A_0;
                                }
                            }
                        }
                    }
                }
                int newPos5 = seqResult;
                if (newPos5 >= 0)
                {
                    result = new CalcParser.Seq.Ast(new Location(this._grammar._parsingSource, token_.get_StartPos(), token_3.get_EndPos()), list<ErrorInfo>.Nil._N_constant_object, token_, token_2, token_3);
                }
                return newPos5;
            }
            public _#prefix#__seq_(IGrammar grammar) : base('\0', '?')
            {
                this._grammar = (CalcParser.GrammarImpl)grammar;
            }
        }
        public class _#postfix#_sub_ : ExtensionPostfixBase<CalcParser.Expr>
        {
            private readonly CalcParser.GrammarImpl _grammar;
            public override RuleDescriptor Descriptor
            {
                get
                {
                    return CalcParser.GrammarImpl.GrammarDescriptorImpl._#postfix#_sub_.StaticDescriptor;
                }
            }
            public override int Parse(int startPos, int pos, string text, int[] bestOffsets, ref CalcParser.Expr result)
            {
                bool isBest = false;
                NToken token_2 = default(NToken);
                CalcParser.Expr token_3 = null;
                CalcParser.Expr prefixResult = result;
                int seqResult = 0;
                CalcParser.Expr token_4 = prefixResult;
                bool _N_cache_13963 = pos >= 0;
                bool arg_AE_0;
                if (_N_cache_13963)
                {
                    if (true)
                    {
                        if (isBest)
                        {
                            arg_AE_0 = true;
                        }
                        else
                        {
                            isBest = (bestOffsets[0] < pos);
                            arg_AE_0 = (isBest || bestOffsets[0] == pos);
                        }
                        goto IL_A3;
                    }
                }
                arg_AE_0 = false;
                IL_A3:
                bool flag = arg_AE_0;
                if (!flag)
                {
                    seqResult = -1;
                }
                else
                {
                    int arg_146_0;
                    if (pos < text.Length && text[pos] == '-')
                    {
                        arg_146_0 = pos + 1;
                    }
                    else
                    {
                        if (this._grammar._parsingErrors._token_sub_literal_"-"_ < pos)
                        {
                            this._grammar._parsingErrors._token_sub_literal_"-"_ = pos;
                        }
                        arg_146_0 = -1;
                    }
                    int newPos = arg_146_0;
                    if (newPos >= 0)
                    {
                        token_2 = new NToken(pos, newPos);
                    }
                    int pos2 = newPos;
                    bool _N_cache_13964 = pos2 >= 0;
                    bool arg_1D5_0;
                    if (_N_cache_13964)
                    {
                        if (true)
                        {
                            if (isBest)
                            {
                                arg_1D5_0 = true;
                            }
                            else
                            {
                                isBest = (bestOffsets[1] < pos2);
                                arg_1D5_0 = (isBest || bestOffsets[1] == pos2);
                            }
                            goto IL_1CA;
                        }
                    }
                    arg_1D5_0 = false;
                    IL_1CA:
                    bool flag2 = arg_1D5_0;
                    if (!flag2)
                    {
                        seqResult = -1;
                    }
                    else
                    {
                        int ofs = pos2;
                        int pos3 = this._grammar._#_s_(pos2, text);
                        bool _N_cache_13965 = pos3 >= 0;
                        bool arg_26E_0;
                        if (_N_cache_13965)
                        {
                            if (true)
                            {
                                if (isBest)
                                {
                                    arg_26E_0 = true;
                                }
                                else
                                {
                                    isBest = (bestOffsets[2] < pos3);
                                    arg_26E_0 = (isBest || bestOffsets[2] == pos3);
                                }
                                goto IL_263;
                            }
                        }
                        arg_26E_0 = false;
                        IL_263:
                        bool flag3 = arg_26E_0;
                        if (!flag3)
                        {
                            seqResult = -1;
                        }
                        else
                        {
                            int ofs2 = pos3;
                            int pos4 = this._grammar._#_expr_(pos3, text, 10, ref token_3);
                            bool _N_cache_13966 = pos4 >= 0;
                            bool arg_30B_0;
                            if (_N_cache_13966)
                            {
                                if (true)
                                {
                                    if (isBest)
                                    {
                                        arg_30B_0 = true;
                                    }
                                    else
                                    {
                                        isBest = (bestOffsets[3] < pos4);
                                        arg_30B_0 = (isBest || bestOffsets[3] == pos4);
                                    }
                                    goto IL_300;
                                }
                            }
                            arg_30B_0 = false;
                            IL_300:
                            bool flag4 = arg_30B_0;
                            if (!flag4)
                            {
                                seqResult = -1;
                            }
                            else
                            {
                                int ofs3 = pos4;
                                int arg_3A2_0;
                                if (isBest)
                                {
                                    bestOffsets[0] = pos;
                                    bestOffsets[1] = ofs;
                                    bestOffsets[2] = ofs2;
                                    bestOffsets[3] = ofs3;
                                    int i = 4;
                                    while (i < bestOffsets.Length && bestOffsets[i] >= 0)
                                    {
                                        bestOffsets[i] = -1;
                                        i++;
                                    }
                                    arg_3A2_0 = pos4;
                                }
                                else
                                {
                                    arg_3A2_0 = -1;
                                }
                                seqResult = arg_3A2_0;
                            }
                        }
                    }
                }
                int newPos2 = seqResult;
                if (newPos2 >= 0)
                {
                    result = new CalcParser.Sub.Ast(new Location(this._grammar._parsingSource, token_4.get_Location().get_StartPos(), token_3.get_Location().get_EndPos()), list<ErrorInfo>.Nil._N_constant_object, token_4, token_2, token_3);
                }
                return newPos2;
            }
            public _#postfix#_sub_(IGrammar grammar) : base(10, '\0', '?')
            {
                this._grammar = (CalcParser.GrammarImpl)grammar;
            }
        }
        private IncParser.GrammarImpl _#grammar#0;
        private NumParser.GrammarImpl _#grammar#1;
        private int _#_start_EndPos______ = -1;
        private CalcParser.Start _#_start_Result______;
        private int _#_start_StartPos____ = -1;
        public ExtensionPostfixBase<CalcParser.Expr>[] _#_expr_PostfixRules_ = new ExtensionPostfixBase<CalcParser.Expr>[0];
        public ExtensionPrefixBase<CalcParser.Expr>[] _#_expr_PrefixRules__ = new ExtensionPrefixBase<CalcParser.Expr>[0];
        private int _#_expr_PrefixEndPos_ = -1;
        private CalcParser.Expr _#_expr_PrefixResult_;
        private int _#_expr_EndPos_______ = -1;
        private CalcParser.Expr _#_expr_Result_______;
        private int _#_expr_BindingPower_ = -1;
        private int _#_expr_StartPos_____ = -1;
        [CompilerGenerated, DebuggerBrowsable(DebuggerBrowsableState.Never)]
        private Parser _N_Parser_4162;
        private CalcParser.GrammarImpl.ParsingErrorsImpl _parsingErrors;
        private static readonly GrammarDescriptor _descriptor;
        public override Parser Parser
        {
            get;
            private set;
        }
        public static GrammarDescriptor StaticDescriptor
        {
            get
            {
                return CalcParser.GrammarImpl._descriptor;
            }
        }
        public GrammarDescriptor Descriptor
        {
            get
            {
                return CalcParser.GrammarImpl._descriptor;
            }
        }
        public new SourceSnapshot get_ParsingSource()
        {
            return base.ParsingSource;
        }
        public void Init()
        {
            this._parsingSource = this.Parser.get_ParsingSource();
            this._parsingErrors = (CalcParser.GrammarImpl.ParsingErrorsImpl)this.Parser.GetParsingErrorsForGrammar(CalcParser.GrammarImpl.StaticDescriptor);
            this._#grammar#1 = (NumParser.GrammarImpl)this.Parser.GetGrammar(NumParser.GrammarImpl.get_StaticDescriptor()).get_Value();
            this._#grammar#0 = (IncParser.GrammarImpl)this.Parser.GetGrammar(IncParser.GrammarImpl.StaticDescriptor).get_Value();
            this.LoadExtensionRules();
        }
        public IGrammarState SaveState()
        {
            return new CalcParser.GrammarImpl.GrammarStateImpl(this);
        }
        private void LoadExtensionRules()
        {
            checked
            {
                ExtensionPrefixBase<CalcParser.Expr>[] e = this._#_expr_PrefixRules__;
                int result = 0;
                if (e != null)
                {
                    result = e.Length;
                }
                int prevLength = result;
                Array.Resize<ExtensionPrefixBase<CalcParser.Expr>>(ref this._#_expr_PrefixRules__, prevLength + 5);
                this._#_expr_PrefixRules__[prevLength + 0] = new CalcParser.GrammarImpl._#prefix#__neg_(this);
                this._#_expr_PrefixRules__[prevLength + 1] = new CalcParser.GrammarImpl._#prefix#__num_(this);
                this._#_expr_PrefixRules__[prevLength + 2] = new CalcParser.GrammarImpl._#prefix#__prefixDec_(this);
                this._#_expr_PrefixRules__[prevLength + 3] = new CalcParser.GrammarImpl._#prefix#__rounds_(this);
                this._#_expr_PrefixRules__[prevLength + 4] = new CalcParser.GrammarImpl._#prefix#__seq_(this);
                ExtensionPostfixBase<CalcParser.Expr>[] e2 = this._#_expr_PostfixRules_;
                int result2 = 0;
                if (e2 != null)
                {
                    result2 = e2.Length;
                }
                prevLength = result2;
                Array.Resize<ExtensionPostfixBase<CalcParser.Expr>>(ref this._#_expr_PostfixRules_, prevLength + 8);
                this._#_expr_PostfixRules_[prevLength + 0] = new CalcParser.GrammarImpl._#postfix#_add_(this);
                this._#_expr_PostfixRules_[prevLength + 1] = new CalcParser.GrammarImpl._#postfix#_cond_(this);
                this._#_expr_PostfixRules_[prevLength + 2] = new CalcParser.GrammarImpl._#postfix#_div_(this);
                this._#_expr_PostfixRules_[prevLength + 3] = new CalcParser.GrammarImpl._#postfix#_mod_(this);
                this._#_expr_PostfixRules_[prevLength + 4] = new CalcParser.GrammarImpl._#postfix#_mul_(this);
                this._#_expr_PostfixRules_[prevLength + 5] = new CalcParser.GrammarImpl._#postfix#_postfixDec_(this);
                this._#_expr_PostfixRules_[prevLength + 6] = new CalcParser.GrammarImpl._#postfix#_pow_(this);
                this._#_expr_PostfixRules_[prevLength + 7] = new CalcParser.GrammarImpl._#postfix#_sub_(this);
            }
        }
        private void ResetMemoization()
        {
            this._#_start_StartPos____ = -1;
            this._#_start_Result______ = null;
            this._#_start_EndPos______ = -1;
            this._#_expr_StartPos_____ = -1;
            this._#_expr_BindingPower_ = -1;
            this._#_expr_Result_______ = null;
            this._#_expr_EndPos_______ = -1;
            this._#_expr_PrefixResult_ = null;
            this._#_expr_PrefixEndPos_ = -1;
        }
        public int _#_start_(int pos, string text, ref CalcParser.Start result)
        {
            CalcParser.Expr token_ = null;
            int arg_1D5_0;
            if (this._#_start_StartPos____ == pos)
            {
                if (this._#_start_EndPos______ >= 0)
                {
                    result = this._#_start_Result______;
                }
                arg_1D5_0 = this._#_start_EndPos______;
            }
            else
            {
                int seqResult = 0;
                int pos2 = this._#_s_(pos, text);
                if (pos2 < 0)
                {
                    seqResult = -1;
                }
                else
                {
                    int pos3 = this._#_expr_(pos2, text, 0, ref token_);
                    if (pos3 < 0)
                    {
                        seqResult = -1;
                    }
                    else
                    {
                        int newPos = this._#_any_(pos3, text);
                        if (newPos < 0)
                        {
                            if (this._parsingErrors._token_start_rule_"any"_ < pos3)
                            {
                                this._parsingErrors._token_start_rule_"any"_ = pos3;
                            }
                        }
                        int newPos2 = newPos;
                        int pos4 = (newPos2 >= 0) ? -1 : pos3;
                        if (pos4 < 0)
                        {
                            seqResult = -1;
                        }
                        else
                        {
                            seqResult = pos4;
                        }
                    }
                }
                int newPos3 = seqResult;
                this._#_start_StartPos____ = pos;
                this._#_start_EndPos______ = newPos3;
                if (newPos3 >= 0)
                {
                    result = new CalcParser.Start.Ast(new Location(this._parsingSource, token_.get_Location().get_StartPos(), token_.get_Location().get_EndPos()), list<ErrorInfo>.Nil._N_constant_object, token_);
                    this._#_start_Result______ = result;
                }
                arg_1D5_0 = newPos3;
            }
            return arg_1D5_0;
        }
        public int _#_start_(int pos, string text)
        {
            int seqResult = 0;
            int pos2 = this._#_s_(pos, text);
            if (pos2 < 0)
            {
                seqResult = -1;
            }
            else
            {
                int pos3 = this._#_expr_(pos2, text, 0);
                if (pos3 < 0)
                {
                    seqResult = -1;
                }
                else
                {
                    int newPos = this._#_any_(pos3, text);
                    if (newPos < 0)
                    {
                        if (this._parsingErrors._token_start_rule_"any"_ < pos3)
                        {
                            this._parsingErrors._token_start_rule_"any"_ = pos3;
                        }
                    }
                    int newPos2 = newPos;
                    int pos4 = (newPos2 >= 0) ? -1 : pos3;
                    if (pos4 < 0)
                    {
                        seqResult = -1;
                    }
                    else
                    {
                        seqResult = pos4;
                    }
                }
            }
            return seqResult;
        }
        public int _#_s_(int pos, string text)
        {
            int seqResult = 0;
            int num = pos;
            while (true)
            {
                int arg_8E_0;
                if (num < text.Length && text[num] == ' ')
                {
                    arg_8E_0 = num + 1;
                }
                else
                {
                    if (this._parsingErrors._token_s_literal_" "_ < num)
                    {
                        this._parsingErrors._token_s_literal_" "_ = num;
                    }
                    arg_8E_0 = -1;
                }
                int newPos = arg_8E_0;
                if (newPos < 0)
                {
                    break;
                }
                num = newPos;
            }
            int pos2 = num;
            if (pos2 < 0)
            {
                seqResult = -1;
            }
            else
            {
                seqResult = pos2;
            }
            return seqResult;
        }
        public int _#_expr_(int pos, string text, int bindingPower)
        {
            CalcParser.Expr result = null;
            return this._#_expr_(pos, text, bindingPower, ref result);
        }
        public int _#_expr_(int pos, string text, int bindingPower, ref CalcParser.Expr curResult)
        {
            int _N_return = 0;
            int[] bestOffsets = new int[32];
            int curEndPos = -1;
            CalcParser.Expr newResult = null;
            if (this._#_expr_StartPos_____ == pos)
            {
                if (this._#_expr_EndPos_______ < 0)
                {
                    _N_return = -1;
                    return _N_return;
                }
                if (this._#_expr_BindingPower_ == bindingPower)
                {
                    curResult = this._#_expr_Result_______;
                    _N_return = this._#_expr_EndPos_______;
                    return _N_return;
                }
                this._#_expr_BindingPower_ = bindingPower;
                this._#_expr_EndPos_______ = -1;
                curResult = this._#_expr_PrefixResult_;
                curEndPos = this._#_expr_PrefixEndPos_;
            }
            else
            {
                this._#_expr_BindingPower_ = bindingPower;
                this._#_expr_StartPos_____ = pos;
                this._#_expr_PrefixEndPos_ = -1;
                this._#_expr_EndPos_______ = -1;
                int i = 0;
                while (i < bestOffsets.Length && bestOffsets[i] >= 0)
                {
                    bestOffsets[i] = -1;
                    i++;
                }
                if (pos < text.Length)
                {
                    char c = text[pos];
                    ExtensionPrefixBase<CalcParser.Expr>[] #_expr_PrefixRules__ = this._#_expr_PrefixRules__;
                    for (int k = 0; k < #_expr_PrefixRules__.Length; k++)
                    {
                        ExtensionPrefixBase<CalcParser.Expr> extensionPrefixBase = #_expr_PrefixRules__[k];
                        ExtensionPrefixBase<CalcParser.Expr> prefixRule = (ExtensionPrefixBase<CalcParser.Expr>)extensionPrefixBase;
                        if (prefixRule.get_LowerBound() <= c && c <= prefixRule.get_UpperBound())
                        {
                            int newEndPos = prefixRule.Parse(pos, text, bestOffsets, ref newResult);
                            if (newEndPos > 0)
                            {
                                curResult = newResult;
                                curEndPos = newEndPos;
                            }
                        }
                    }
                }
                else
                {
                    ExtensionPrefixBase<CalcParser.Expr>[] #_expr_PrefixRules__2 = this._#_expr_PrefixRules__;
                    for (int l = 0; l < #_expr_PrefixRules__2.Length; l++)
                    {
                        ExtensionPrefixBase<CalcParser.Expr> extensionPrefixBase2 = #_expr_PrefixRules__2[l];
                        ExtensionPrefixBase<CalcParser.Expr> prefixRule2 = (ExtensionPrefixBase<CalcParser.Expr>)extensionPrefixBase2;
                        int newEndPos = prefixRule2.Parse(pos, text, bestOffsets, ref newResult);
                        if (newEndPos > 0)
                        {
                            curResult = newResult;
                            curEndPos = newEndPos;
                        }
                    }
                }
            }
            if (curEndPos >= 0)
            {
                CalcParser.Expr prefixResult = curResult;
                int prefixEndPos = curEndPos;
                CalcParser.Expr bestResult = curResult;
                int bestEndPos = curEndPos;
                while (curEndPos < text.Length)
                {
                    int j = 0;
                    while (j < bestOffsets.Length && bestOffsets[j] >= 0)
                    {
                        bestOffsets[j] = -1;
                        j++;
                    }
                    char c = text[curEndPos];
                    ExtensionPostfixBase<CalcParser.Expr>[] #_expr_PostfixRules_ = this._#_expr_PostfixRules_;
                    for (int m = 0; m < #_expr_PostfixRules_.Length; m++)
                    {
                        ExtensionPostfixBase<CalcParser.Expr> extensionPostfixBase = #_expr_PostfixRules_[m];
                        ExtensionPostfixBase<CalcParser.Expr> postfixRule = (ExtensionPostfixBase<CalcParser.Expr>)extensionPostfixBase;
                        if (postfixRule.get_LowerBound() <= c && c <= postfixRule.get_UpperBound() && bindingPower < postfixRule.get_BindingPower())
                        {
                            newResult = curResult;
                            int newEndPos = postfixRule.Parse(pos, curEndPos, text, bestOffsets, ref newResult);
                            if (newEndPos > 0)
                            {
                                bestEndPos = newEndPos;
                                bestResult = newResult;
                            }
                        }
                    }
                    if (bestEndPos == curEndPos)
                    {
                        IL_3A6:
                        this._#_expr_BindingPower_ = bindingPower;
                        this._#_expr_StartPos_____ = pos;
                        this._#_expr_PrefixResult_ = prefixResult;
                        this._#_expr_PrefixEndPos_ = prefixEndPos;
                        this._#_expr_Result_______ = curResult;
                        this._#_expr_EndPos_______ = curEndPos;
                        _N_return = curEndPos;
                        return _N_return;
                    }
                    curResult = bestResult;
                    curEndPos = bestEndPos;
                }
                goto IL_3A6;
            }
            _N_return = -1;
            return _N_return;
        }
        public int _#_any_(int pos, string text)
        {
            int okPos = -1;
            if (pos < text.Length)
            {
                int curPos = pos + 1;
                okPos = curPos;
            }
            return okPos;
        }
        static GrammarImpl()
        {
            CalcParser.GrammarImpl._descriptor = new CalcParser.GrammarImpl.GrammarDescriptorImpl();
        }
        public GrammarImpl()
        {
        }
        public GrammarImpl(Parser parser)
        {
            if (parser == null)
            {
                throw new ArgumentNullException("parser", "The ``NotNull'' contract of parameter ``parser'' has been violated. See Main.n:13:2:47:2: .");
            }
            this.Parser = parser;
        }
        public override Tuple<int, CalcParser.Expr> TryParseExpr(SourceSnapshot source)
        {
            checked
            {
                if (source == null)
                {
                    throw new ArgumentNullException("source", "The ``NotNull'' contract of parameter ``source'' has been violated. See Main.n:13:2:47:2: .");
                }
                this.ResetMemoization();
                this.Parser = new Parser(this, source);
                GrammarDescriptor[] dependencies = this.Descriptor.get_Dependencies();
                for (int i = 0; i < dependencies.Length; i++)
                {
                    GrammarDescriptor grammarDescriptor = dependencies[i];
                    GrammarDescriptor descriptor = grammarDescriptor;
                    this.Parser.AddGrammar(descriptor);
                }
                this.Init();
                CalcParser.Expr result = null;
                int pos = this._#_expr_(0, this._parsingSource.get_Text(), 0, ref result);
                return new Tuple<int, CalcParser.Expr>(pos, result);
            }
        }
        public override Tuple<int, CalcParser.Start> TryParseStart(SourceSnapshot source)
        {
            checked
            {
                if (source == null)
                {
                    throw new ArgumentNullException("source", "The ``NotNull'' contract of parameter ``source'' has been violated. See Main.n:13:2:47:2: .");
                }
                this.ResetMemoization();
                this.Parser = new Parser(this, source);
                GrammarDescriptor[] dependencies = this.Descriptor.get_Dependencies();
                for (int i = 0; i < dependencies.Length; i++)
                {
                    GrammarDescriptor grammarDescriptor = dependencies[i];
                    GrammarDescriptor descriptor = grammarDescriptor;
                    this.Parser.AddGrammar(descriptor);
                }
                this.Init();
                CalcParser.Start result = null;
                int pos = this._#_start_(0, this._parsingSource.get_Text(), ref result);
                return new Tuple<int, CalcParser.Start>(pos, result);
            }
        }
    }
    public class Expr : Ast
    {
        public class Error : CalcParser.Expr
        {
            public Error(Location location, list<ErrorInfo> errors) : base(location, errors)
            {
            }
        }
        public class Splice : CalcParser.Expr
        {
            public Splice(Location location, list<ErrorInfo> errors) : base(location, errors)
            {
            }
        }
        public Expr(Location location, list<ErrorInfo> errors) : base(location, errors)
        {
        }
    }
    public class Add : CalcParser.Expr
    {
        public new class Error : CalcParser.Add
        {
            public Error(Location location, list<ErrorInfo> errors) : base(location, errors)
            {
            }
        }
        public new class Splice : CalcParser.Add
        {
            public Splice(Location location, list<ErrorInfo> errors) : base(location, errors)
            {
            }
        }
        public class Ast : CalcParser.Add
        {
            public readonly CalcParser.Expr l;
            public readonly NToken op;
            public readonly CalcParser.Expr r;
            public Ast(Location location, list<ErrorInfo> error, CalcParser.Expr l, NToken op, CalcParser.Expr r) : base(location, error)
            {
                this.l = l;
                this.op = op;
                this.r = r;
            }
            public override void GetErrors(List<ErrorInfo> errors)
            {
                base.GetErrors(errors);
                this.l.GetErrors(errors);
                this.r.GetErrors(errors);
            }
        }
        public Add(Location location, list<ErrorInfo> errors) : base(location, errors)
        {
        }
    }
    public class Cond : CalcParser.Expr
    {
        public new class Error : CalcParser.Cond
        {
            public Error(Location location, list<ErrorInfo> errors) : base(location, errors)
            {
            }
        }
        public new class Splice : CalcParser.Cond
        {
            public Splice(Location location, list<ErrorInfo> errors) : base(location, errors)
            {
            }
        }
        public class Ast : CalcParser.Cond
        {
            public readonly CalcParser.Expr cond;
            public readonly NToken q;
            public readonly CalcParser.Expr l;
            public readonly NToken colon;
            public readonly CalcParser.Expr r;
            public Ast(Location location, list<ErrorInfo> error, CalcParser.Expr cond, NToken q, CalcParser.Expr l, NToken colon, CalcParser.Expr r) : base(location, error)
            {
                this.cond = cond;
                this.q = q;
                this.l = l;
                this.colon = colon;
                this.r = r;
            }
            public override void GetErrors(List<ErrorInfo> errors)
            {
                base.GetErrors(errors);
                this.cond.GetErrors(errors);
                this.l.GetErrors(errors);
                this.r.GetErrors(errors);
            }
        }
        public Cond(Location location, list<ErrorInfo> errors) : base(location, errors)
        {
        }
    }
    public class Div : CalcParser.Expr
    {
        public new class Error : CalcParser.Div
        {
            public Error(Location location, list<ErrorInfo> errors) : base(location, errors)
            {
            }
        }
        public new class Splice : CalcParser.Div
        {
            public Splice(Location location, list<ErrorInfo> errors) : base(location, errors)
            {
            }
        }
        public class Ast : CalcParser.Div
        {
            public readonly CalcParser.Expr l;
            public readonly NToken op;
            public readonly CalcParser.Expr r;
            public Ast(Location location, list<ErrorInfo> error, CalcParser.Expr l, NToken op, CalcParser.Expr r) : base(location, error)
            {
                this.l = l;
                this.op = op;
                this.r = r;
            }
            public override void GetErrors(List<ErrorInfo> errors)
            {
                base.GetErrors(errors);
                this.l.GetErrors(errors);
                this.r.GetErrors(errors);
            }
        }
        public Div(Location location, list<ErrorInfo> errors) : base(location, errors)
        {
        }
    }
    public class Mod : CalcParser.Expr
    {
        public new class Error : CalcParser.Mod
        {
            public Error(Location location, list<ErrorInfo> errors) : base(location, errors)
            {
            }
        }
        public new class Splice : CalcParser.Mod
        {
            public Splice(Location location, list<ErrorInfo> errors) : base(location, errors)
            {
            }
        }
        public class Ast : CalcParser.Mod
        {
            public readonly CalcParser.Expr l;
            public readonly NToken op;
            public readonly CalcParser.Expr r;
            public Ast(Location location, list<ErrorInfo> error, CalcParser.Expr l, NToken op, CalcParser.Expr r) : base(location, error)
            {
                this.l = l;
                this.op = op;
                this.r = r;
            }
            public override void GetErrors(List<ErrorInfo> errors)
            {
                base.GetErrors(errors);
                this.l.GetErrors(errors);
                this.r.GetErrors(errors);
            }
        }
        public Mod(Location location, list<ErrorInfo> errors) : base(location, errors)
        {
        }
    }
    public class Mul : CalcParser.Expr
    {
        public new class Error : CalcParser.Mul
        {
            public Error(Location location, list<ErrorInfo> errors) : base(location, errors)
            {
            }
        }
        public new class Splice : CalcParser.Mul
        {
            public Splice(Location location, list<ErrorInfo> errors) : base(location, errors)
            {
            }
        }
        public class Ast : CalcParser.Mul
        {
            public readonly CalcParser.Expr l;
            public readonly NToken op;
            public readonly CalcParser.Expr r;
            public Ast(Location location, list<ErrorInfo> error, CalcParser.Expr l, NToken op, CalcParser.Expr r) : base(location, error)
            {
                this.l = l;
                this.op = op;
                this.r = r;
            }
            public override void GetErrors(List<ErrorInfo> errors)
            {
                base.GetErrors(errors);
                this.l.GetErrors(errors);
                this.r.GetErrors(errors);
            }
        }
        public Mul(Location location, list<ErrorInfo> errors) : base(location, errors)
        {
        }
    }
    public class Neg : CalcParser.Expr
    {
        public new class Error : CalcParser.Neg
        {
            public Error(Location location, list<ErrorInfo> errors) : base(location, errors)
            {
            }
        }
        public new class Splice : CalcParser.Neg
        {
            public Splice(Location location, list<ErrorInfo> errors) : base(location, errors)
            {
            }
        }
        public class Ast : CalcParser.Neg
        {
            public readonly NToken op;
            public readonly CalcParser.Expr expr;
            public Ast(Location location, list<ErrorInfo> error, NToken op, CalcParser.Expr expr) : base(location, error)
            {
                this.op = op;
                this.expr = expr;
            }
            public override void GetErrors(List<ErrorInfo> errors)
            {
                base.GetErrors(errors);
                this.expr.GetErrors(errors);
            }
        }
        public Neg(Location location, list<ErrorInfo> errors) : base(location, errors)
        {
        }
    }
    public class Num : CalcParser.Expr
    {
        public new class Error : CalcParser.Num
        {
            public Error(Location location, list<ErrorInfo> errors) : base(location, errors)
            {
            }
        }
        public new class Splice : CalcParser.Num
        {
            public Splice(Location location, list<ErrorInfo> errors) : base(location, errors)
            {
            }
        }
        public class Ast : CalcParser.Num
        {
            public readonly NumParser.Number num;
            public Ast(Location location, list<ErrorInfo> error, NumParser.Number num) : base(location, error)
            {
                this.num = num;
            }
            public override void GetErrors(List<ErrorInfo> errors)
            {
                base.GetErrors(errors);
                this.num.GetErrors(errors);
            }
        }
        public Num(Location location, list<ErrorInfo> errors) : base(location, errors)
        {
        }
    }
    public class PostfixDec : CalcParser.Expr
    {
        public new class Error : CalcParser.PostfixDec
        {
            public Error(Location location, list<ErrorInfo> errors) : base(location, errors)
            {
            }
        }
        public new class Splice : CalcParser.PostfixDec
        {
            public Splice(Location location, list<ErrorInfo> errors) : base(location, errors)
            {
            }
        }
        public class Ast : CalcParser.PostfixDec
        {
            public readonly CalcParser.Expr expr;
            public readonly NToken op;
            public Ast(Location location, list<ErrorInfo> error, CalcParser.Expr expr, NToken op) : base(location, error)
            {
                this.expr = expr;
                this.op = op;
            }
            public override void GetErrors(List<ErrorInfo> errors)
            {
                base.GetErrors(errors);
                this.expr.GetErrors(errors);
            }
        }
        public PostfixDec(Location location, list<ErrorInfo> errors) : base(location, errors)
        {
        }
    }
    public class Pow : CalcParser.Expr
    {
        public new class Error : CalcParser.Pow
        {
            public Error(Location location, list<ErrorInfo> errors) : base(location, errors)
            {
            }
        }
        public new class Splice : CalcParser.Pow
        {
            public Splice(Location location, list<ErrorInfo> errors) : base(location, errors)
            {
            }
        }
        public class Ast : CalcParser.Pow
        {
            public readonly CalcParser.Expr l;
            public readonly NToken op;
            public readonly CalcParser.Expr r;
            public Ast(Location location, list<ErrorInfo> error, CalcParser.Expr l, NToken op, CalcParser.Expr r) : base(location, error)
            {
                this.l = l;
                this.op = op;
                this.r = r;
            }
            public override void GetErrors(List<ErrorInfo> errors)
            {
                base.GetErrors(errors);
                this.l.GetErrors(errors);
                this.r.GetErrors(errors);
            }
        }
        public Pow(Location location, list<ErrorInfo> errors) : base(location, errors)
        {
        }
    }
    public class PrefixDec : CalcParser.Expr
    {
        public new class Error : CalcParser.PrefixDec
        {
            public Error(Location location, list<ErrorInfo> errors) : base(location, errors)
            {
            }
        }
        public new class Splice : CalcParser.PrefixDec
        {
            public Splice(Location location, list<ErrorInfo> errors) : base(location, errors)
            {
            }
        }
        public class Ast : CalcParser.PrefixDec
        {
            public readonly NToken op;
            public readonly CalcParser.Expr expr;
            public Ast(Location location, list<ErrorInfo> error, NToken op, CalcParser.Expr expr) : base(location, error)
            {
                this.op = op;
                this.expr = expr;
            }
            public override void GetErrors(List<ErrorInfo> errors)
            {
                base.GetErrors(errors);
                this.expr.GetErrors(errors);
            }
        }
        public PrefixDec(Location location, list<ErrorInfo> errors) : base(location, errors)
        {
        }
    }
    public class Rounds : CalcParser.Expr
    {
        public new class Error : CalcParser.Rounds
        {
            public Error(Location location, list<ErrorInfo> errors) : base(location, errors)
            {
            }
        }
        public new class Splice : CalcParser.Rounds
        {
            public Splice(Location location, list<ErrorInfo> errors) : base(location, errors)
            {
            }
        }
        public class Ast : CalcParser.Rounds
        {
            public readonly NToken l;
            public readonly CalcParser.Expr expr;
            public readonly NToken r;
            public Ast(Location location, list<ErrorInfo> error, NToken l, CalcParser.Expr expr, NToken r) : base(location, error)
            {
                this.l = l;
                this.expr = expr;
                this.r = r;
            }
            public override void GetErrors(List<ErrorInfo> errors)
            {
                base.GetErrors(errors);
                this.expr.GetErrors(errors);
            }
        }
        public Rounds(Location location, list<ErrorInfo> errors) : base(location, errors)
        {
        }
    }
    public class Seq : CalcParser.Expr
    {
        public new class Error : CalcParser.Seq
        {
            public Error(Location location, list<ErrorInfo> errors) : base(location, errors)
            {
            }
        }
        public new class Splice : CalcParser.Seq
        {
            public Splice(Location location, list<ErrorInfo> errors) : base(location, errors)
            {
            }
        }
        public class Ast : CalcParser.Seq
        {
            public readonly NToken l;
            public readonly list<CalcParser.Expr> expr;
            public readonly NToken r;
            public Ast(Location location, list<ErrorInfo> error, NToken l, list<CalcParser.Expr> expr, NToken r) : base(location, error)
            {
                this.l = l;
                this.expr = expr;
                this.r = r;
            }
            public override void GetErrors(List<ErrorInfo> errors)
            {
                base.GetErrors(errors);
                list<CalcParser.Expr> list = this.expr;
                while (list is list<CalcParser.Expr>.Cons)
                {
                    CalcParser.Expr hd = ((list<CalcParser.Expr>.Cons)list).hd;
                    list<CalcParser.Expr> list2 = (list<CalcParser.Expr>)((list<CalcParser.Expr>.Cons)list).tl;
                    CalcParser.Expr _item = hd;
                    _item.GetErrors(errors);
                    list = (list<CalcParser.Expr>)list2;
                }
            }
        }
        public Seq(Location location, list<ErrorInfo> errors) : base(location, errors)
        {
        }
    }
    public class Start : Nemerle.Parser.Ast
    {
        public class Error : CalcParser.Start
        {
            public Error(Location location, list<ErrorInfo> errors) : base(location, errors)
            {
            }
        }
        public class Splice : CalcParser.Start
        {
            public Splice(Location location, list<ErrorInfo> errors) : base(location, errors)
            {
            }
        }
        public class Ast : CalcParser.Start
        {
            public readonly CalcParser.Expr expr;
            public Ast(Location location, list<ErrorInfo> error, CalcParser.Expr expr) : base(location, error)
            {
                this.expr = expr;
            }
            public override void GetErrors(List<ErrorInfo> errors)
            {
                base.GetErrors(errors);
                this.expr.GetErrors(errors);
            }
        }
        public Start(Location location, list<ErrorInfo> errors) : base(location, errors)
        {
        }
    }
    public class Sub : CalcParser.Expr
    {
        public new class Error : CalcParser.Sub
        {
            public Error(Location location, list<ErrorInfo> errors) : base(location, errors)
            {
            }
        }
        public new class Splice : CalcParser.Sub
        {
            public Splice(Location location, list<ErrorInfo> errors) : base(location, errors)
            {
            }
        }
        public class Ast : CalcParser.Sub
        {
            public readonly CalcParser.Expr l;
            public readonly NToken op;
            public readonly CalcParser.Expr r;
            public Ast(Location location, list<ErrorInfo> error, CalcParser.Expr l, NToken op, CalcParser.Expr r) : base(location, error)
            {
                this.l = l;
                this.op = op;
                this.r = r;
            }
            public override void GetErrors(List<ErrorInfo> errors)
            {
                base.GetErrors(errors);
                this.l.GetErrors(errors);
                this.r.GetErrors(errors);
            }
        }
        public Sub(Location location, list<ErrorInfo> errors) : base(location, errors)
        {
        }
    }
    private SourceSnapshot _parsingSource;
    public abstract override Parser Parser
    {
        get;
    }
    public SourceSnapshot ParsingSource
    {
        get
        {
            return this._parsingSource;
        }
    }
    public string GetText(NToken tok)
    {
        return this._parsingSource.get_OriginalText().Substring(tok.get_StartPos(), checked(tok.get_EndPos() - tok.get_StartPos()));
    }
    public Location GetLocation(NToken tok)
    {
        return new Location(this._parsingSource, tok.get_StartPos(), tok.get_EndPos());
    }
    public option<CalcParser.Expr> ParseExpr(string text)
    {
        Tuple<int, CalcParser.Expr> _N_cache_5924 = this.TryParseExpr(text);
        int pos = _N_cache_5924.Field0;
        CalcParser.Expr res = _N_cache_5924.Field1;
        return (pos >= 0) ? new option<CalcParser.Expr>.Some(res) : option<CalcParser.Expr>.None._N_constant_object;
    }
    public option<CalcParser.Expr> ParseExpr(SourceSnapshot source)
    {
        Tuple<int, CalcParser.Expr> _N_cache_5937 = this.TryParseExpr(source);
        int pos = _N_cache_5937.Field0;
        CalcParser.Expr res = _N_cache_5937.Field1;
        return (pos >= 0) ? new option<CalcParser.Expr>.Some(res) : option<CalcParser.Expr>.None._N_constant_object;
    }
    public Tuple<int, CalcParser.Expr> TryParseExpr(string text)
    {
        return this.TryParseExpr(new SourceSnapshot(text, 0, ""));
    }
    public abstract override Tuple<int, CalcParser.Expr> TryParseExpr(SourceSnapshot source);
    public option<CalcParser.Start> ParseStart(string text)
    {
        Tuple<int, CalcParser.Start> _N_cache_5954 = this.TryParseStart(text);
        int pos = _N_cache_5954.Field0;
        CalcParser.Start res = _N_cache_5954.Field1;
        return (pos >= 0) ? new option<CalcParser.Start>.Some(res) : option<CalcParser.Start>.None._N_constant_object;
    }
    public option<CalcParser.Start> ParseStart(SourceSnapshot source)
    {
        Tuple<int, CalcParser.Start> _N_cache_5967 = this.TryParseStart(source);
        int pos = _N_cache_5967.Field0;
        CalcParser.Start res = _N_cache_5967.Field1;
        return (pos >= 0) ? new option<CalcParser.Start>.Some(res) : option<CalcParser.Start>.None._N_constant_object;
    }
    public Tuple<int, CalcParser.Start> TryParseStart(string text)
    {
        return this.TryParseStart(new SourceSnapshot(text, 0, ""));
    }
    public abstract override Tuple<int, CalcParser.Start> TryParseStart(SourceSnapshot source);
}

И сравни с этим
[ParserGrammar(Options = EmitDebugSources,
  parsergrammar
  {
    using IncParser;
    using NumParser;

    any = ['\u0000'..'\uFFFF'];
    s : void = ' '*;

    [StartRule, Ast(expr)]
    start : Ast = s expr !any;

    [StartRule, Ast()]
    expr : Ast;

    [Ast(l, expr, r)] rounds is expr = '('s expr ')'s;
    [Ast(l, expr, r)] seq is expr = '{'s expr* '}'s;

    [Ast(num)]        num is expr = number s;

    [Ast(op, expr)]   neg is expr = '-'s expr : 100;

    [Ast(op, expr)]   prefixDec is expr = "--"s expr : 200;
    [Ast(expr, op)]   postfixDec is expr = expr : 200 "--"s;

    [Ast(l, op, r)]   add is expr = expr : 10 '+'s expr : 10;
    [Ast(l, op, r)]   sub is expr = expr : 10 '-'s expr : 10;
    [Ast(l, op, r)]   mul is expr = expr : 20 '*'s expr : 20;
    [Ast(l, op, r)]   div is expr = expr : 20 '/'s expr : 20;
    [Ast(l, op, r)]   mod is expr = expr : 20 '%'s expr : 20;
    [Ast(l, op, r)]   pow is expr = expr : 31 '^'s expr : 30;

    [Ast(cond, q, l, colon, r)]   cond is expr = expr : 301 '?'s expr ':'s expr;
  }
)]
public abstract class CalcParser
{}

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

G>В случает готового отлаженного DSL, подходящего под задачу, вопрос обычно не стоит. А вот вопрос писать или не писать решается обычно не в пользу DSL. Видимо этому есть объективные показания.

Только вера, таких как ты, в то, что сделать ДСЛ это что-то сложное.

WH>>Ибо у меня на руках куча фактов.

G>А кроме одного академ. проекта?
Не одного. И не только академ.
Но тебе же пофиг.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[16]: Языки общего назначения не имеют смысла!
От: WolfHound  
Дата: 09.04.12 08:31
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Все, понял. DSL головного мозга.

Очередной слив засчитан.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[8]: Языки общего назначения не имеют смысла!
От: Gaperton http://gaperton.livejournal.com
Дата: 09.04.12 08:55
Оценка: -1
Здравствуйте, WolfHound, Вы писали:

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

WH>Остается выяснить в каком месте этот язык ДСЛ?
WH>Я его очень давно не видел, но по воспоминаниям это язык общего назначения.

Воспоминания, очевидно, ложные. По всем понятиям он никак не общего назначения.

WH>Причем очень плохо сделанный.


Я знал, я знал.
Re[10]: Языки общего назначения не имеют смысла!
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 09.04.12 09:43
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>eSQL не пример DSLя корпоративной системы.


Потому что тебе так хочется?

G> Кстати он сам очень ущербен, по сути умеет даже меньше, чем можно в Linq написать.


Он умеет примерно столько же, сколько TSQL. А в Linq можно написать такое, что не умеет ни одна существующая СУБД.

G>А ты сравни с запросами в SharePoint или CRM.

G>Там дофига усилий надо приложить чтобы простой запрос родить.

Это, типа, пример правильного DSL что ли?

G>Получается что DSL усложняет решение


Разве что кривой DSL. Осложненный уродской и кривой схемой таблиц в БД. В нашей платформе запрос на внутреннем языка всегда не длиннее аналога на голом SQL, при этом иногда он в разы короче. И это при том, что никаких извратов в плане таблиц в БД нет, все хранится так же, как если бы разрабатывалось на голом SQL.

G>Дальше ER модели никто из них пока не ушел, так что по мощности они на уровне SQL.


И что? DSL как правило менее мощный, нежели сравнительно универсальный язык, каковым является SQL.
... << RSDN@Home 1.2.0 alpha 5 rev. 27 on Windows 7 6.1.7601.65536>>
AVK Blog
Re[9]: Языки общего назначения не имеют смысла!
От: WolfHound  
Дата: 09.04.12 09:54
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Воспоминания, очевидно, ложные. По всем понятиям он никак не общего назначения.

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

WH>>Причем очень плохо сделанный.

G>Я знал, я знал.
А что тут знать то? Показал какашку и теперь радуешься, что предсказал, что ее назовут своим именем.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re: MIT'овский SICP о DSL
От: Flem1234  
Дата: 09.04.12 10:00
Оценка: 172 (6) +1
В поддержку ДСЛ отрывок из SICP, им можно кидаться в противников со словами: "Вы собираетесь спорить с азбукой?".
Оригинал тут

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

Глава 4. Метаязыковая абстракция

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

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

Метаязыковая абстракция (metalinguistic abstraction), то есть построение новых языков, играет важную роль во всех отраслях инженерного проектирования. Для компьютерного программирования она особенно важна, поскольку в программировании мы можем не только формулировать новые языки, но и реализовывать их через построение вычислителей. Вычислитель (evaluator) (или интерпретатор (interpreter)) для языка программирования — это процедура, которая, будучи примененной к выражению языка, производит действия, необходимые для вычисления этого выражения.

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

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


А вообще вменяемых тулз для построения DSL мало и литературы тоже, особено на русском. Не подкинешь ссылок, что почитать?
Re[10]: Языки общего назначения не имеют смысла!
От: Gaperton http://gaperton.livejournal.com
Дата: 09.04.12 10:04
Оценка: +1 :)
Здравствуйте, WolfHound, Вы писали:

G>>Воспоминания, очевидно, ложные. По всем понятиям он никак не общего назначения.

WH>Ну, тогда тебе не составит труда сказать, что же там такого предметно ориентированного.

Конечно не составит. Система типов.

WH>Все что я о нем помню это обыкновенный динамически типизированный, императивный язык.


Ты о скриптовой части, которая дает ему вычислительную полноту? Да какая разница, какая она?

Впрочем, 1С-сники специально сделали ее настолько простой, что на ней может писать бухгалтер.

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


Да, это вызывает большие проблемы у уникумов, умудряющихся решать на нем диффуры.

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

WH>>>Причем очень плохо сделанный.

G>>Я знал, я знал.
WH>А что тут знать то? Показал какашку и теперь радуешься, что предсказал, что ее назовут своим именем.

Вот сделаешь DSL, на котором будет писать хотя бы 1% от людей, использующих язык 1С — и мы посмотрим на сие божественное творение.

А пока это не так, я отказываюсь называть твои DSL-и иначе, чем какашкой.
Re[11]: Языки общего назначения не имеют смысла!
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 09.04.12 10:18
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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

G>>eSQL не пример DSLя корпоративной системы.
AVK>Потому что тебе так хочется?
Потому что это так и есть
Возьми пару известных систем и покажи где там eSQL

G>> Кстати он сам очень ущербен, по сути умеет даже меньше, чем можно в Linq написать.

AVK>Он умеет примерно столько же, сколько TSQL.
Быгыгы. Давай рекурсивный запрос с CTE.

G>>А ты сравни с запросами в SharePoint или CRM.

G>>Там дофига усилий надо приложить чтобы простой запрос родить.
AVK>Это, типа, пример правильного DSL что ли?
Нет, это пример DSLя реальной системы, а не воображаемой

G>>Получается что DSL усложняет решение

AVK>Разве что кривой DSL. Осложненный уродской и кривой схемой таблиц в БД. В нашей платформе запрос на внутреннем языка всегда не длиннее аналога на голом SQL, при этом иногда он в разы короче. И это при том, что никаких извратов в плане таблиц в БД нет, все хранится так же, как если бы разрабатывалось на голом SQL.
Покажи некривой. Только реальный, не академический.

G>>Дальше ER модели никто из них пока не ушел, так что по мощности они на уровне SQL.

AVK>И что? DSL как правило менее мощный, нежели сравнительно универсальный язык, каковым является SQL.
Именно, а в чем профит? Если менее мощный, то надо или больше писать для достижения того же результата, или его вообще нельзя в рамках DSLя достигнуть.

А теперь представь что DSLя просто нет и его еще надо написать (или не написать).
Re[12]: Языки общего назначения не имеют смысла!
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 09.04.12 10:30
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Возьми пару известных систем и покажи где там eSQL


1C 8 подойдет?

G>Покажи некривой. Только реальный, не академический.


Ну вот Парус 10 такой Реальный, не академический.

AVK>>И что? DSL как правило менее мощный, нежели сравнительно универсальный язык, каковым является SQL.

G>Именно, а в чем профит?

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

G> Если менее мощный, то надо или больше писать для достижения того же результата


Попробуй доказать.
... << RSDN@Home 1.2.0 alpha 5 rev. 27 on Windows 7 6.1.7601.65536>>
AVK Blog
Re[11]: Языки общего назначения не имеют смысла!
От: WolfHound  
Дата: 09.04.12 10:42
Оценка:
Здравствуйте, Gaperton, Вы писали:

Мда... ничего по теме как всегда не сказал.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[11]: Языки общего назначения не имеют смысла!
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 09.04.12 10:57
Оценка: +1
Здравствуйте, Gaperton, Вы писали:

G>>>Воспоминания, очевидно, ложные. По всем понятиям он никак не общего назначения.

WH>>Ну, тогда тебе не составит труда сказать, что же там такого предметно ориентированного.
G>Конечно не составит. Система типов.

Какая такая система типов? Ты о чем?

WH>>Все что я о нем помню это обыкновенный динамически типизированный, императивный язык.

G>Ты о скриптовой части, которая дает ему вычислительную полноту? Да какая разница, какая она?
G>Впрочем, 1С-сники специально сделали ее настолько простой, что на ней может писать бухгалтер.

Это ты про какую версию? Даже в 6-й не всякий бух мог что-то слабать. А в 7-й было что-то a-la VB6 плюс набор библиотечных OLE-объектов. Или у нас VB6 перехал в категорию DSL-ей?

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

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

Не знаю как сейчас, но в начале века (когда была 7.5 и 7.7, вроде как) тормоза были в разных местах. Там был тормознутый транслятор, тормоза из-за навигационного доступа к данным, тормоза из-за пессимистических блокировок для достижения "сериализуемого" уровня изоляции и убирания дедлоков. Тормоза транслятора это явная бочина их программистов, а навигационный доступ и изоляция это из-за их целевой аудитории (т.е. техническими средствами не лечится).
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[8]: Языки общего назначения не имеют смысла!
От: BrainSlug Израиль  
Дата: 09.04.12 11:02
Оценка:
Здравствуйте, WolfHound, Вы писали:


WH>Остается выяснить в каком месте этот язык ДСЛ?

WH>Я его очень давно не видел, но по воспоминаниям это язык общего назначения.
vba — язык общего назначения? если нет, тогда 1С тоже нет. язык 1С замкнут на самой платформе, на которой решается определенный круг проблем. Все. Без дополнительных приблуд (типа подключение внешних библиотек) на нем больше ничего сделать нельзя.
WH>Причем очень плохо сделанный.
Не с чем сравнивать. Я не знаю аналогов 1С. Современные версии (8.2), те что я видел, вполне годные для своих задач. Но наверняка можно сделать лучше.

ЗЫ. Но ваши идеи поддерживаю.
.
Re[7]: Языки общего назначения не имеют смысла!
От: alex_public  
Дата: 09.04.12 11:05
Оценка: :)
Здравствуйте, WolfHound, Вы писали:

WH>По сравнению с MVVM это все очень неудобно.

WH>Все эти ковыряния в ДСМ просто жуть с ружжом.

Нууу я бы так не сказал. HTML в качестве инструмента оформления вполне эффективен, т.к для того и создавался. А код на javascript с учётом современных библиотечек превращается в набор конструкций вида:
$('#element_id').click(function(){
    //реакция на нажатие
});

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

WH>Ты зря отмахнулся от тех ссылок, что я тебе дал.


Я понял идею. Но думаю что в реализации только для web'a это не особо нужно. Вот если бы была библиотека на такой идеи для нативных контролов или что-то подобное...
Re[7]: Языки общего назначения не имеют смысла!
От: alex_public  
Дата: 09.04.12 11:08
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

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


_>>Tcl как-то не очень похож на DSL. Это скорее полноценный язык.

_>>Ну и результат с Тк мягко говоря сомнительный...

ANS>Почему?
Автор: Andrei N.Sobchuck
Дата: 01.06.06

Tk слабая на мой вкус. ))) А Tcl слабый по сравнению с нормальными языками и при этом всё же сильнее чем надo для GUI DSL, т.к. это полноценный скриптовой язык. В общем всё не как надо. )))
Re[10]: Языки общего назначения не имеют смысла!
От: BrainSlug Израиль  
Дата: 09.04.12 11:10
Оценка: 50 (1)
Ну и еще вдогонку, выскажу свое, возможно, бестолковое мнение по теме. Считаю нужно не просто развивать идею построения dsl языков, ведь по сути это та же идея, что и просто построение языков, просто уровень абстракции меняется от задачи к задаче. Нужно продумать некую систему взаимодействия всего этого зоопарка. Здесь же — кодогенерация, трансформация, что угодно и как угодно это можно назвать, лишь бы работало. В вебе это особенно явственно чувствуется, — никто не хочет писать по двадцать раз код на js, потом опять же эту же логику повторять на серверной стороне php/java или что там. Вот придумывают свои приблуды(gwt) и даже языки. Т.е. нужно качественно повысить продуктивность разработчика именно продуманной системой, а не просто языком, пускай это будет даже и dsl .
.
Re[13]: Языки общего назначения не имеют смысла!
От: alex_public  
Дата: 09.04.12 11:16
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Смех на палочке.

WH>Напиши этот код руками:

Вот смотрю я на этот пример и думаю... А означает ли факт кодогенерации обязательное наличие DSL? Например, я уже писал тут, что мы используем для создания GUI визуальный редактор, который генерирует весь код создания интерфейса неспредственно на системном языке. Т.е. кодогенерация больших объёмов у нас тут есть, а никаких DSL вроде как и не видно.

И вообще вопрос в продолжение этой мысли... Может во многих случаях как раз такое и нужно? Т.е. именно генерация кода, а не dsl?
Re[11]: Языки общего назначения не имеют смысла!
От: Vain Россия google.ru
Дата: 09.04.12 11:17
Оценка: -1 :)
Здравствуйте, WolfHound, Вы писали:

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


V>>Это не ответ, это попытка уйти от реальности.

WH>Те ты тоже считаешь, что возможность написать в несколько десятков раз меньше кода и как следствие в несколько десятков раз удешевить разработку и поддержку, а так же в несколько десятков раз сократить количество ошибок это мелочи?
WH>Я тебя правильно понял?
WH>И что касается ухода от реальности, этим занимаешься ты.
WH>Ибо у меня на руках куча фактов.
WH>Которые ты пытаешься игнорировать.
А какие факты? Факты про то что многие языки общего назначения являются промышленным стандартом? Факты про то что ни один старап не будет рисковать своим проектом и как следствие кошельком чтобы проверять выстрелит ли дсл? Факты про то что существует куча уже написанного и, главное, отлаженного временем кода который никто не захочет менять на написание какого-то там дсл? Факты про то что программистов с языком общего назначения на порядок больше чем дсл писателей, что сказывается на их цене? Эти факты как раз все против дсл.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[8]: Языки общего назначения не имеют смысла!
От: WolfHound  
Дата: 09.04.12 11:19
Оценка:
Здравствуйте, alex_public, Вы писали:

_>
_>$('#element_id').click(function(){
_>    //реакция на нажатие
_>});
_>

_>Т.е. такой вот функциональный асинхронный стиль. Не идеал естественно, но вполне можно пользоваться...
Проблема выделена.
Вот там и начинается жуть с ружжом.
Хотя нет. Проблемы уже начинаются вот тут $('#element_id').
Ибо идут запросы к DOM который, по сути, должен быть чистым View. Но на него оказывается, завязана логика. Это явный косяк.
Идеология MVVM состоит в том, что мы полностью отвязываем логику от представления.
ViewModel о View ничего не знает.

_>Я понял идею. Но думаю что в реализации только для web'a это не особо нужно. Вот если бы была библиотека на такой идеи для нативных контролов или что-то подобное...

Это возможно.
Но чтобы сделать действительно хороший продукт нужно много работы.
Я могу спроектировать ДСЛи. Но один не напишу. Слишком много писать. А у меня и других дел хватает.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[14]: Языки общего назначения не имеют смысла!
От: WolfHound  
Дата: 09.04.12 11:22
Оценка: +2
Здравствуйте, alex_public, Вы писали:

_>Вот смотрю я на этот пример и думаю... А означает ли факт кодогенерации обязательное наличие DSL? Например, я уже писал тут, что мы используем для создания GUI визуальный редактор, который генерирует весь код создания интерфейса неспредственно на системном языке. Т.е. кодогенерация больших объёмов у нас тут есть, а никаких DSL вроде как и не видно.

Внутри редактора живет иерархия контролов.
Это и есть ДСЛ, по которому генерируется код.

_>И вообще вопрос в продолжение этой мысли... Может во многих случаях как раз такое и нужно? Т.е. именно генерация кода, а не dsl?

Код всегда генерируется по некой модели.
Так что если есть кодогенериция то есть и язык. Не обязательно в текстовом виде.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[12]: Языки общего назначения не имеют смысла!
От: WolfHound  
Дата: 09.04.12 11:29
Оценка: +1 -1
Здравствуйте, Vain, Вы писали:

V>А какие факты?

Многократное снижение издержек вот какие.

V>Факты про то что многие языки общего назначения являются промышленным стандартом?

Миллион мух не может ошибаться.

V>Факты про то что ни один старап не будет рисковать своим проектом и как следствие кошельком чтобы проверять выстрелит ли дсл?

Это вообще бред сивой кобылы.
Многие стартапы как раз и поднялись на ДСЛях.

V>Факты про то что существует куча уже написанного и, главное, отлаженного временем кода который никто не захочет менять на написание какого-то там дсл?

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

V>Факты про то что программистов с языком общего назначения на порядок больше чем дсл писателей, что сказывается на их цене?

Смешной ты человек.
Вот ты на SQL пишешь?
А это ДСЛ.
ДСЛ вообще изучить очень просто.
Обычно намного проще чем библиотеку которой его пытаются заменить.

V>Эти факты как раз все против дсл.

Это не факты. Это мифы.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[9]: Языки общего назначения не имеют смысла!
От: WolfHound  
Дата: 09.04.12 11:32
Оценка:
Здравствуйте, BrainSlug, Вы писали:

BS>vba — язык общего назначения? если нет, тогда 1С тоже нет. язык 1С замкнут на самой платформе, на которой решается определенный круг проблем. Все. Без дополнительных приблуд (типа подключение внешних библиотек) на нем больше ничего сделать нельзя.

Если к С не подключить внешние библиотеки для работы с сервисами ОС ты на нем тоже ничего не напишешь.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[11]: Языки общего назначения не имеют смысла!
От: WolfHound  
Дата: 09.04.12 11:32
Оценка:
Здравствуйте, BrainSlug, Вы писали:

BS>Ну и еще вдогонку, выскажу свое, возможно, бестолковое мнение по теме. Считаю нужно не просто развивать идею построения dsl языков, ведь по сути это та же идея, что и просто построение языков, просто уровень абстракции меняется от задачи к задаче. Нужно продумать некую систему взаимодействия всего этого зоопарка.

Этим и занимаюсь.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[13]: Языки общего назначения не имеют смысла!
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 09.04.12 11:39
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


G>>Возьми пару известных систем и покажи где там eSQL

AVK>1C 8 подойдет?
Ага, там совершенно тупая трансляция в SQL.

G>>Покажи некривой. Только реальный, не академический.

AVK>Ну вот Парус 10 такой Реальный, не академический.
Ну пример приведи, я не пользуюсь парусом.

AVK>>>И что? DSL как правило менее мощный, нежели сравнительно универсальный язык, каковым является SQL.

G>>Именно, а в чем профит?
AVK>Как обычно. В том что при решении определенного класса задач DSL значительно лучше универсального языка.
В чем лучше? Вот на примере SQL мы видим что dsl_и над ним не лучше.

G>> Если менее мощный, то надо или больше писать для достижения того же результата

AVK>Попробуй доказать.
Так ты сам сказал что

DSL как правило менее мощный, нежели сравнительно универсальный язык

Re[10]: Языки общего назначения не имеют смысла!
От: BrainSlug Израиль  
Дата: 09.04.12 11:40
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Если к С не подключить внешние библиотеки для работы с сервисами ОС ты на нем тоже ничего не напишешь.

да, но можно если захотеть самим написать такие либы. или заказать у кого-то, а 1С — вещь в себе. если бы разработчики не дали возможности подключать либы (и то, там есть свои правила и ограничения как это делать, есть также возможность подключать com сервера. в винде естессно), ничего бы не вышло. Не знаю 1С для меня как-то не тянет на язык общего назначения.
.
Re[9]: Языки общего назначения не имеют смысла!
От: alex_public  
Дата: 09.04.12 11:45
Оценка: :)
Здравствуйте, WolfHound, Вы писали:

WH>Проблема выделена.

WH>Вот там и начинается жуть с ружжом.
WH>Хотя нет. Проблемы уже начинаются вот тут $('#element_id').
WH>Ибо идут запросы к DOM который, по сути, должен быть чистым View. Но на него оказывается, завязана логика. Это явный косяк.
WH>Идеология MVVM состоит в том, что мы полностью отвязываем логику от представления.
WH>ViewModel о View ничего не знает.

Я и говорю что не идеал. Но пользоваться уже вполне можно, в отличие от того, что было лет 10 назад. Функциональность браузеров тогда не сильно отличалась от современной, а вот всяческих удобных фреймворков не было, так что все писали разную жуть, кто как может. А вот последние годы, с разрабокой множества инструментов ситуация изменилась — теперь уже вполне можно можно строить приличные web-интерфейсы без особой жути внутри.
Re[14]: Языки общего назначения не имеют смысла!
От: WolfHound  
Дата: 09.04.12 11:55
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>>> Если менее мощный, то надо или больше писать для достижения того же результата

AVK>>Попробуй доказать.
G>Так ты сам сказал что
G>

G>DSL как правило менее мощный, нежели сравнительно универсальный язык

Конечно он менее мощный. Они, как правило, даже не полны по Тьрингу.
Но то, что на ПОЯ (при решении задачи для который создан ПОЯ) кода будет меньше чем на ЯОН это к гадалке не ходи.
Автор: WolfHound
Дата: 09.04.12
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[15]: Языки общего назначения не имеют смысла!
От: alex_public  
Дата: 09.04.12 11:57
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Внутри редактора живет иерархия контролов.

WH>Это и есть ДСЛ, по которому генерируется код.

Более того, у него даже есть свой отдельный формат для хранения "нарисованного" gui. Я в него как-то заглянул ради интереса — там некий дичайший xml. Так что формально можно даже текстовый dsl найти тут. Но речь то не об этом... Речь о том, что если поменять этот формат на любой другой (бинарный например), то абсолютно ничего в процессе разработки не изменится — люди никогда не видят его. Так можем ли мы называть это DSL, если люди с этим не работают никогда и от его реализации не зависит вообще ничего?

WH>Код всегда генерируется по некой модели.

WH>Так что если есть кодогенериция то есть и язык. Не обязательно в текстовом виде.

Ну в данном случае, в смысле логики, модель задаётся иерархией классов фреймворка. Элементы которой мы двигаем мышкой в редакторе.
Re[2]: Языки общего назначения не имеют смысла!
От: _Obelisk_ Россия http://www.ibm.com
Дата: 09.04.12 12:00
Оценка: +2
Здравствуйте, Буравчик, Вы писали:

Б>Одна из них — взаимодействие между языками. Как передавать данные из одного языка в другой? Взять ту же связку "язык общего назначения (ЯОН) — SQL". Сколько напридумывали вариантов передачи данных из ЯОН в SQL — и в компилятор встраивали, и формировали текст SQL в программе и передача параметров в хранимые процедуры. Аналогично и с превращением данных из SQL в данные ЯОН — всякие ридеры, датасеты и т.п. В итоге удобным вариантом оказался что-то типа LINQ, т.е. с одной стороны DSL, а работа все в том же ЯОН. Т.е. по сути получилась та же библиотека.


Взаимодействие между языками, унаследованным кодом и сторонними библиотеками — это те камни, на которых споткнулся Model Driven Development в целом и DSL-и в частности. Решать их лучше не созданием каких-то формальных стандартов обмена информации между языками а прагматичным подходом: к примеру, создание C API для DSL-я.

Помимо этого, есть еще такая вещь как дебаг кода. К DSL неплохо было бы прикладывать и DSL-specific debugger. Но это приводит к своим специфичным проблемам.



Душа обязана трудиться! (с) Н.Заболоцкий.
Re[16]: Языки общего назначения не имеют смысла!
От: WolfHound  
Дата: 09.04.12 12:13
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Более того, у него даже есть свой отдельный формат для хранения "нарисованного" gui. Я в него как-то заглянул ради интереса — там некий дичайший xml. Так что формально можно даже текстовый dsl найти тут. Но речь то не об этом... Речь о том, что если поменять этот формат на любой другой (бинарный например), то абсолютно ничего в процессе разработки не изменится — люди никогда не видят его. Так можем ли мы называть это DSL, если люди с этим не работают никогда и от его реализации не зависит вообще ничего?

Они работают с его графическим представлением.
Графические ДСЛ с моей точки зрения очень сомнительны. Но их сомнительность не отменяет того что они ДСЛ.

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

Вот смотри:
Если сделать 3 окошка.
В одном ViewModel синхронизируемая в обе стороны с превьюшкой.
В другом превьюшка в которой можно нажимать кнопки и редактировать текст. И в это время будет меняться состояние ViewModel в соседнем окне.
В третьем маппинг ViewModel на контролы. Меняя который превьюшка автоматически перестраивается. При этом все данные остаются в ViewModel.
Плюс возможность сохранить несколько состояний ViewModel. Для того чтобы можно было быстро переключаться между ними и смотреть как ведет себя ГУИ.

Думаю это было бы весьма круто.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[14]: Языки общего назначения не имеют смысла!
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 09.04.12 12:27
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Вот смотрю я на этот пример и думаю... А означает ли факт кодогенерации обязательное наличие DSL? Например, я уже писал тут, что мы используем для создания GUI визуальный редактор, который генерирует весь код создания интерфейса


DSL бывают и графическими.
... << RSDN@Home 1.2.0 alpha 5 rev. 27 on Windows 7 6.1.7601.65536>>
AVK Blog
Re[11]: Языки общего назначения не имеют смысла!
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 09.04.12 12:29
Оценка:
Здравствуйте, BrainSlug, Вы писали:

BS>Ну и еще вдогонку, выскажу свое, возможно, бестолковое мнение по теме. Считаю нужно не просто развивать идею построения dsl языков, ведь по сути это та же идея, что и просто построение языков, просто уровень абстракции меняется от задачи к задаче. Нужно продумать некую систему взаимодействия всего этого зоопарка. Здесь же — кодогенерация, трансформация, что угодно и как угодно это можно назвать, лишь бы работало. В вебе это особенно явственно чувствуется, — никто не хочет писать по двадцать раз код на js, потом опять же эту же логику повторять на серверной стороне php/java или что там. Вот придумывают свои приблуды(gwt) и даже языки. Т.е. нужно качественно повысить продуктивность разработчика именно продуманной системой, а не просто языком, пускай это будет даже и dsl .


Когда разрабатывался Smalltalk, то до St-80 были и St-72 и St-74 и St-76 и St-78. Особенностью ранних систем St было, окромя ассинхронности, еще и то, что грамматику протокола задавал сам объект-получатель. На практике, получалась каша и всё свелось к унифицированной грамматике в St-80. При этом, проблема была не в примитивном способе разбора потока сообщений, а именно в разных грамматиках в одной программе, в сложности прочтения получившейся программы.

Это не отменяет пользы DSL, но и мульёнами в одной системе они вряд-ли будут появляться.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[8]: Языки общего назначения не имеют смысла!
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 09.04.12 12:40
Оценка:
Здравствуйте, alex_public, Вы писали:

_>>>Tcl как-то не очень похож на DSL. Это скорее полноценный язык.

_>>>Ну и результат с Тк мягко говоря сомнительный...

ANS>>Почему?
Автор: Andrei N.Sobchuck
Дата: 01.06.06

_>Tk слабая на мой вкус. ))) А Tcl слабый по сравнению с нормальными языками и при этом всё же сильнее чем надo для GUI DSL, т.к. это полноценный скриптовой язык. В общем всё не как надо. )))

Стандартная библиотека Tcl дурацкая и устаревшая. И "всё есть текст" тоже привносит проблемы. Это так. А вот что с Tk не так, я не понял. Скриптуется на Tcl (была даже куча компонент и layout-менеджеров pure-Tcl), система стилей
Автор: Andrei N.Sobchuck
Дата: 03.01.08
. Мне нравилось. Другое дело, что там с применением Tk как Gui к другим языкам (не Tcl) — этого я не знаю, не пробовал.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[12]: Языки общего назначения не имеют смысла!
От: Gaperton http://gaperton.livejournal.com
Дата: 09.04.12 12:54
Оценка: +2
Здравствуйте, Andrei N.Sobchuck, Вы писали:

G>>>>Воспоминания, очевидно, ложные. По всем понятиям он никак не общего назначения.

WH>>>Ну, тогда тебе не составит труда сказать, что же там такого предметно ориентированного.
G>>Конечно не составит. Система типов.

ANS>Какая такая система типов? Ты о чем?


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

WH>>>Все что я о нем помню это обыкновенный динамически типизированный, императивный язык.

G>>Ты о скриптовой части, которая дает ему вычислительную полноту? Да какая разница, какая она?
G>>Впрочем, 1С-сники специально сделали ее настолько простой, что на ней может писать бухгалтер.

ANS>Это ты про какую версию? Даже в 6-й не всякий бух мог что-то слабать. А в 7-й было что-то a-la VB6 плюс набор библиотечных OLE-объектов. Или у нас VB6 перехал в категорию DSL-ей?


Это я про design goals языка 7-рки, со слов Сергея Нуралиева. Любого "буха", который обучался в университете основам программирования, можно обучить написать разнесение проводок, или вносить туда простые правки.

Разумеется, "бух" не станет от этого уберпрофессионалом, способным написать на 1С все возможное и невозможное. И что? Тебе очень сильно придраться хочется, но не знаешь к чему?

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

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

ANS>Не знаю как сейчас, но в начале века (когда была 7.5 и 7.7, вроде как) тормоза были в разных местах.


Давай, рассказывай мне. Я на 7.5 и 7.7 "в конце века" сделал несколько десятков проектов. Некоторые из них были на пике возможностей платформы по тогдашним временам (к примеру, мы первыми сделали полноценное управление производством). И вот ни разу почему-то не утыкался в тормоза интерпретатора. Все время в базу.

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

Когда оно по практике так — можно урассуждаться о том, насколько это плохой DSL. Плохому танцору всегда яйца мешают — он сильных сторон технологий видеть просто не умеет, и потому полагается на слабые. И тут у него и начинается "в разных местах".
Re[12]: ну и пара поправок
От: Gaperton http://gaperton.livejournal.com
Дата: 09.04.12 13:06
Оценка: +1 -1
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS> А в 7-й было что-то a-la VB6 плюс набор библиотечных OLE-объектов. Или у нас VB6 перехал в категорию DSL-ей?


И чтобы внести ясность. А то ты как я вижу не в курсе.

В 7-ке никогда не было "библиотечных OLE-шных объектов". Единственный COM интерфейс, который она выставляла — это кривое подобие IDispatch, предназначенное для внешних приложений.

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

А "в категории DSL" у нас находится не VB6, а Visual Basic for Applications, который туда не "переехал", а изначально использовался в качестве основы DSL в майкрософтских офисных продуктах.

Специалисты, блин.
Re[12]: Языки общего назначения не имеют смысла!
От: k.o. Россия  
Дата: 09.04.12 13:11
Оценка: +1
Здравствуйте, Vain, Вы писали:

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


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


V>А какие факты? Факты про то что многие языки общего назначения являются промышленным стандартом? Факты про то что ни один старап не будет рисковать своим проектом и как следствие кошельком чтобы проверять выстрелит ли дсл?


И как тут не вспомнить "Beating the Averages" Грэма.

The average big company grows at about ten percent a year. So if you're running a big company and you do everything the way the average big company does it, you can expect to do as well as the average big company-- that is, to grow about ten percent a year.

The same thing will happen if you're running a startup, of course. If you do everything the way the average startup does it, you should expect average performance. The problem here is, average performance means that you'll go out of business. The survival rate for startups is way less than fifty percent. So if you're running a startup, you had better be doing something odd. If not, you're in trouble.

Re[13]: ну и пара поправок
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 09.04.12 13:25
Оценка:
Здравствуйте, Gaperton, Вы писали:


G>И чтобы внести ясность. А то ты как я вижу не в курсе.

G>В 7-ке никогда не было "библиотечных OLE-шных объектов". Единственный COM интерфейс, который она выставляла — это кривое подобие IDispatch, предназначенное для внешних приложений.

Это не важно. Ты б еще придрался к тому, что, в отличии от VB, в 1C ключевые слова — русские.

G>Ее язык никогда не был похож на VB6. Если искать, на что он больше похож — это подмножество JS c опаскаленым синтаксисом, переведенный на русский язык. Нет, это совсем не то же самое, что VB6.

G>А "в категории DSL" у нас находится не VB6, а Visual Basic for Applications, который туда не "переехал", а изначально использовался в качестве основы DSL в майкрософтских офисных продуктах.

Языки для скриптования прикручиваются ко многим системам. Но, по какой-то загадочной причине, они всегда называются скриптовыми языками, а не DSL.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[13]: Языки общего назначения не имеют смысла!
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 09.04.12 13:35
Оценка: +1
Здравствуйте, Gaperton, Вы писали:

G>>>>>Воспоминания, очевидно, ложные. По всем понятиям он никак не общего назначения.

WH>>>>Ну, тогда тебе не составит труда сказать, что же там такого предметно ориентированного.
G>>>Конечно не составит. Система типов.
ANS>>Какая такая система типов? Ты о чем?
G>Это я о регистрах, справочниках, документах, планах счетов... Это типы данных, со сложным поведением и сильной заточкой на предметную область.

О. Если каждую объектную систему называть DSL, то получится, что каждая программа на ООП языке состоит из множества DSL. Но нормальные люди называют это классами и пакетами.

G>>>Впрочем, 1С-сники специально сделали ее настолько простой, что на ней может писать бухгалтер.

ANS>>Это ты про какую версию? Даже в 6-й не всякий бух мог что-то слабать. А в 7-й было что-то a-la VB6 плюс набор библиотечных OLE-объектов. Или у нас VB6 перехал в категорию DSL-ей?
G>Это я про design goals языка 7-рки, со слов Сергея Нуралиева. Любого "буха", который обучался в университете основам программирования, можно обучить написать разнесение проводок, или вносить туда простые правки.

"Сделали" и "design goals" это разные вещи. И, замечу, design goal этот не достигнут. Ибо редкий бух освоит язык общего назначения.

G>Давай, рассказывай мне. Я на 7.5 и 7.7 "в конце века" сделал несколько десятков проектов. Некоторые из них были на пике возможностей платформы по тогдашним временам (к примеру, мы первыми сделали полноценное управление производством). И вот ни разу почему-то не утыкался в тормоза интерпретатора. Все время в базу.


Контеншен на глобальном локе это не "тормоза базы".

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


О, коммерческий успех стал выступать мерилом степени DSL-ности. Ты не перерабатывай так много.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[14]: Языки общего назначения не имеют смысла!
От: Gaperton http://gaperton.livejournal.com
Дата: 09.04.12 14:12
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>>>Какая такая система типов? Ты о чем?

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

ANS>О. Если каждую объектную систему называть DSL, то получится, что каждая программа на ООП языке состоит из множества DSL. Но нормальные люди называют это классами и пакетами.


А. Но только в языке 1С нет ни "классов", ни "пакетов". И ничего похожего на эти вещи. Зато там есть, например, довольно интересный язык запросов по бизнес-объектам, лежащим в базе, которые кажутся тебе классами и пакетами.

В связи с этим, я плохо понимаю, с чего это ты записал себя в "нормальные люди". Нормальные люди называют вещи своими именами, а не чем попало. И нормальные люди не спорят на темы, в которых ничерта не разбираются.
Re[15]: Языки общего назначения не имеют смысла!
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 09.04.12 14:45
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Здравствуйте, Andrei N.Sobchuck, Вы писали:


ANS>>>>Какая такая система типов? Ты о чем?

G>>>Это я о регистрах, справочниках, документах, планах счетов... Это типы данных, со сложным поведением и сильной заточкой на предметную область.
ANS>>О. Если каждую объектную систему называть DSL, то получится, что каждая программа на ООП языке состоит из множества DSL. Но нормальные люди называют это классами и пакетами.
G>А. Но только в языке 1С нет ни "классов", ни "пакетов". И ничего похожего на эти вещи. Зато там есть, например, довольно интересный язык запросов по бизнес-объектам, лежащим в базе, которые кажутся тебе классами и пакетами.

Наличие среди всего прочего "довольно интересного язык запросов" (читай "абсолютно идиотского") не делает весь язык "DSL".

G>В связи с этим, я плохо понимаю, с чего это ты записал себя в "нормальные люди". Нормальные люди называют вещи своими именами, а не чем попало. И нормальные люди не спорят на темы, в которых ничерта не разбираются.


Т.е. ты уже осознал, что ошибся записав язык 1С в DSL, и решил просто повилять хвостиком неся чушь?
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[16]: Языки общего назначения не имеют смысла!
От: VoidEx  
Дата: 09.04.12 15:06
Оценка: +3
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Наличие среди всего прочего "довольно интересного язык запросов" (читай "абсолютно идиотского") не делает весь язык "DSL".


А что делает язык DSL?
Re[16]: Языки общего назначения не имеют смысла!
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 09.04.12 15:19
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:


ANS>Наличие среди всего прочего "довольно интересного язык запросов" (читай "абсолютно идиотского") не делает весь язык "DSL".


Да нет в 8 ке это уже максимально приближенный к "нормальному языку" язык запросов.
Такое возможно соорудить чере Linq to EF правда все руки не доходят. Скажем так 1С это "предметно-ориентированный язык высокого уровня" http://ru.wikipedia.org/wiki/%C2%F1%F2%F0%EE%E5%ED%ED%FB%E9_%FF%E7%FB%EA_%EF%F0%EE%E3%F0%E0%EC%EC%E8%F0%EE%E2%E0%ED%E8%FF_1%D1:%CF%F0%E5%E4%EF%F0%E8%FF%F2%E8%E5

Блин этот .Net Bridge уже и вики засунули. Это по сути простейший прокси http://rsdn.ru/forum/dotnet/4296659.aspx
Автор: Serginio1
Дата: 02.06.11
через IReflect
и солнце б утром не вставало, когда бы не было меня
Re[14]: Языки общего назначения не имеют смысла!
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 09.04.12 15:29
Оценка: 59 (3)
Здравствуйте, gandjustas, Вы писали:

AVK>>1C 8 подойдет?

G>Ага, там совершенно тупая трансляция в SQL.

Ну да, обозвал тупым и все понятно. Запрос там строится в терминах одноэсных документов, проводок и т.п. И результат тоже возвращается ввиде объектов 1С.

AVK>>Ну вот Парус 10 такой Реальный, не академический.

G>Ну пример приведи, я не пользуюсь парусом.

Ну вот что в тестах, к примеру, валяется:
Запрос:
USING Mock;

SELECT
  bc2.BoolAttr AS ba,
  bc2.BizClass1Link.IntAttr AS ia,
  sq.Identity.BoolAttr,
  jbc2l.BizClass1Link.IntAttr AS lia,
  jbc2r.BizClass1Link.IntAttr AS ria,
  sq.Identity.BizClass1Link.IntAttr AS tjia

FROM
  BizClass2 bc2,
  (SELECT Identity FROM BizClass2) AS sq,
  BizClass2 AS jbc2l JOIN BizClass2 AS jbc2r ON jbc2l.BizClass1Link = jbc2r.BizClass1Link;


В сиквел в итоге отдаеться такое:
SELECT 
 [bc2].BoolAttr AS ba,
 [__join_0].IntAttr AS ia,
 [__join_1].BoolAttr AS BoolAttr,
 [__join_2].IntAttr AS lia,
 [__join_3].IntAttr AS ria,
 [__join_4].IntAttr AS tjia
FROM
 [MockSchema].[Tbl-Mock.BizClass2] AS [bc2]
  /*implicit*/LEFT OUTER JOIN [MockSchema].[Tbl-Mock.BizClass1] AS [__join_0] ON (([__join_0].id = [bc2].LinkTo_BizClass1Link_id) AND ([__join_0].tid = [bc2].LinkTo_BizClass1Link_tid)),
 (
  SELECT 
   [MockSchema].[Tbl-Mock.BizClass2].id AS Identity,
   [MockSchema].[Tbl-Mock.BizClass2].tid AS Identity_Type
  FROM
   [MockSchema].[Tbl-Mock.BizClass2]
 ) AS [sq]
  /*implicit*/LEFT OUTER JOIN [MockSchema].[Tbl-Mock.BizClass2] AS [__join_1] ON (([__join_1].id = [sq].Identity) AND ([__join_1].tid = [sq].Identity_Type))
  /*implicit*/LEFT OUTER JOIN [MockSchema].[Tbl-Mock.BizClass1] AS [__join_4] ON (([__join_4].id = [__join_1].LinkTo_BizClass1Link_id) AND ([__join_4].tid = [__join_1].LinkTo_BizClass1Link_tid)),
 [MockSchema].[Tbl-Mock.BizClass2] AS [jbc2l]
  /*implicit*/LEFT OUTER JOIN [MockSchema].[Tbl-Mock.BizClass1] AS [__join_2] ON (([__join_2].id = [jbc2l].LinkTo_BizClass1Link_id) AND ([__join_2].tid = [jbc2l].LinkTo_BizClass1Link_tid))
  INNER JOIN [MockSchema].[Tbl-Mock.BizClass2] AS [jbc2r]
   /*implicit*/LEFT OUTER JOIN [MockSchema].[Tbl-Mock.BizClass1] AS [__join_3] ON (([__join_3].id = [jbc2r].LinkTo_BizClass1Link_id) AND ([__join_3].tid = [jbc2r].LinkTo_BizClass1Link_tid)) ON (([jbc2l].LinkTo_BizClass1Link_id = [jbc2r].LinkTo_BizClass1Link_id) AND ([jbc2l].LinkTo_BizClass1Link_tid = [jbc2r].LinkTo_BizClass1Link_tid))


AVK>>Как обычно. В том что при решении определенного класса задач DSL значительно лучше универсального языка.

G>В чем лучше?

Во всем.

G> Вот на примере SQL мы видим что dsl_и над ним не лучше.


Это где ты такое увидел?

G>>> Если менее мощный, то надо или больше писать для достижения того же результата

AVK>>Попробуй доказать.
G>Так ты сам сказал что

G>

G>DSL как правило менее мощный, нежели сравнительно универсальный язык


Доказать, что менее мощный язык означает, что для достижения того же результата надо больше писать.
... << RSDN@Home 1.2.0 alpha 5 rev. 27 on Windows 7 6.1.7601.65536>>
AVK Blog
Re[13]: Языки общего назначения не имеют смысла!
От: mrTwister Россия  
Дата: 09.04.12 15:31
Оценка: +1
Здравствуйте, Gaperton, Вы писали:

G>И я скажу по поводу 1С так. При правильном применении она приводит к экономии затрат на разработку, в сравнении с языками общего назначения, от 2-х до 10 раз. И это многократно проверенный факт — трудно не заметить, что ты систематически выигрываешь у самоделкиных тендера, и быстрее нарезаешь бабки.


Осталось только выяснить: благодаря чему это происходит. Благодаря DSL, или благодаря тому, что в случае с 1C 80% необходимого функционала уже реализовано "из коробки"?
лэт ми спик фром май харт
Re: Языки общего назначения не имеют смысла!
От: mrTwister Россия  
Дата: 09.04.12 15:34
Оценка: -1
Здравствуйте, WolfHound, Вы писали:

WH>56 страниц сильно оптимизированного кода на жабе (год разработки) против 17 строк на ДСЛ (год разработки компилятора).


Хреновый как-ой то DSL. Можно было бы сделать DSL в 17 раз круче, который будет решать задачу в одну строчку. Пример того, как надо делать нормальные DSL можно посмотреть тут
лэт ми спик фром май харт
Re: Языки общего назначения не имеют смысла!
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.04.12 15:46
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


А для остальных можно будет быстро склепать DSL на N2
Автор: VladD2
Дата: 28.03.12
.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Языки общего назначения не имеют смысла!
От: Gaperton http://gaperton.livejournal.com
Дата: 09.04.12 15:58
Оценка: +2
Здравствуйте, mrTwister, Вы писали:

G>>И я скажу по поводу 1С так. При правильном применении она приводит к экономии затрат на разработку, в сравнении с языками общего назначения, от 2-х до 10 раз. И это многократно проверенный факт — трудно не заметить, что ты систематически выигрываешь у самоделкиных тендера, и быстрее нарезаешь бабки.


T>Осталось только выяснить: благодаря чему это происходит. Благодаря DSL, или благодаря тому, что в случае с 1C 80% необходимого функционала уже реализовано "из коробки"?


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

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

Объем "глобального модуля" 1С Оперативный учет 7.5 составлял порядка 4000 (четырех тысяч) строк кода.
А объем "глобального модуля" 1С Бухгалтерии 7.5 составлял порядка 2000 (двух тысяч) строк кода.

Отношение бизнес-логики к прочему коду в системах на 1С очень высоко, примерно 9 к 1. Выигрышь образуется за счет того, что ты проектируешь сразу в терминах справочник-документ-отчет (это сильно отличается от ООП и баз данных, за этим стоит определенная методология), и, по сути, не пишешь ничего кроме бизнес-логики. То есть, не делаешь лишней работы.

Многие сервисы тебе вообще даются почти бесплатно. Например, синхронизация баз в распределенных офисах еще в семерке делались легким мановением руки и компонентой за 500 баксов.

За это ты, естественно, расплачиваешься очень много чем, например, сильными ограничениями по организации GUI твоего приложения (он жестко привязан к тому, что можно с некоторой натяжкой назвать "схемой БД"). Часто результат того стоит. А бывает, что нет.
Re[6]: Языки общего назначения не имеют смысла!
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.04.12 16:05
Оценка:
Здравствуйте, gandjustas, Вы писали:

WH>>Когда этим кто-нибудь займется. Твой КО.

G>Так почему до сих пор не занялись? Бинес-задачи меняются мало, а кроме SQL пока ниче не придумано.
G>В чем проблема?

Почему не придумали? Придумали и массу. Проблема только в том, что:
* Для большинства задач написание DSL, с использованием "лопаты", не закончится к сроку завершения проекта.
* Для большинства задач требуется в разы меньшая квалификация, тем для разработки DSL, с использованием "лопаты".

WH>>Просто его плохо спроектировали.

G>Почему?

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

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

G>Это технически невозможно, сервер на другом компе стоит, порты закрыты.

Что-то ты гонишь. Вы СУБД не используете? Или SQL не применяете?
Он тебя спрашивает — станешь ли ты лезть в БД вручную (использовать ISAM), при наличии скуля?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: ну и пара поправок
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 09.04.12 16:08
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>В 7-ке никогда не было "библиотечных OLE-шных объектов". Единственный COM интерфейс, который она выставляла — это кривое подобие IDispatch, предназначенное для внешних приложений.


Внутри там тоже IDispatch, хоть и вычурный. Только вот это совершенно пофигу, это детали реализации.
... << RSDN@Home 1.2.0 alpha 5 rev. 27 on Windows 7 6.1.7601.65536>>
AVK Blog
Re[7]: Языки общего назначения не имеют смысла!
От: mrTwister Россия  
Дата: 09.04.12 16:45
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Он тебя спрашивает — станешь ли ты лезть в БД вручную (использовать ISAM), при наличии скуля?


Вообще-то сравнение с ISAM совершенно не в тему. SQL скорее надо сравнивать с CriteriaQuery, то есть с API, который построен на основе ЯП общего назначения.
лэт ми спик фром май харт
Re[11]: Языки общего назначения не имеют смысла!
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.04.12 16:46
Оценка: +1 -1
Здравствуйте, Gaperton, Вы писали:

G>Ты о скриптовой части, которая дает ему вычислительную полноту? Да какая разница, какая она?


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

1Эс — это ЯОН + среда ориентированная на бизнес-задачи. Того же самого можно было бы добиться создав библиотеки и внешние утилиты для явы или дотнета.

И ты глубоко заблуждаешся, если думаешь, что заточка для бизнес-задач сделала 1Эс популярным.
Популярным его сделало наличие множества готовых решений (следанных проффесионалами), и возможность их дорабатывать под себя.

G>Впрочем, 1С-сники специально сделали ее настолько простой, что на ней может писать бухгалтер.


Это полнейший гон. Ни одни бухгалтер (если он по совместительству не программист) не сможет написать на 1Эс нихрена.

G>А пока это не так, я отказываюсь называть твои DSL-и иначе, чем какашкой.


Он не собирается писать ДСЛ (кроме тех что нужны для разработки других ДСЛ-ей). Он собирается сделать процесс написания ДСЛ-ей во многие разы проще. Так чтобы их смогли разрабатывать те кто не шатир в языкостроении, но обладает талантом архитектора.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Языки общего назначения не имеют смысла!
От: VoidEx  
Дата: 09.04.12 17:45
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Разница в том, что язык имеющий вычислительную полноту по тьюрингу и позволяющий писать код не через зад (как, например, SQL с рекурсивными расширениями) и является языком общего назначения.


Вопрос "через зад — это как?" напрашивается сам собой.
Советую сразу брать такое определение: любой тьюринг полный язык — язык общего назначения, кроме SQL.

По-моему, SQL тут просто ярчайший пример того, что твоё определение несостоятельно. Потому что грань "через зад"/"не через зад" провести ты не сможешь.
Re[17]: Языки общего назначения не имеют смысла!
От: alex_public  
Дата: 09.04.12 18:12
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Они работают с его графическим представлением.

WH>Графические ДСЛ с моей точки зрения очень сомнительны. Но их сомнительность не отменяет того что они ДСЛ.

Ну для GUI и похожих задач по любому удобна визуализация.

WH>Лично я считаю, что текстовый ДСЛ с превьюшкой обновляющейся в реальном времени был бы лучше.

WH>Вот смотри:
WH>Если сделать 3 окошка.
WH>В одном ViewModel синхронизируемая в обе стороны с превьюшкой.
WH>В другом превьюшка в которой можно нажимать кнопки и редактировать текст. И в это время будет меняться состояние ViewModel в соседнем окне.
WH>В третьем маппинг ViewModel на контролы. Меняя который превьюшка автоматически перестраивается. При этом все данные остаются в ViewModel.
WH>Плюс возможность сохранить несколько состояний ViewModel. Для того чтобы можно было быстро переключаться между ними и смотреть как ведет себя ГУИ.

Если там можно будет писать какой-то достаточно сложный код (в рамках DSL, т.е. касающийся только GUI), а не просто делать размётку контролов, то да, это заметно удобнее было бы. А если у нас тут решается только задача "нарисовать" интерфейс, то все эти сущности уже лишними кажутся — проще кодогенерация из визуального редактора.
Re[15]: Языки общего назначения не имеют смысла!
От: alex_public  
Дата: 09.04.12 18:13
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>DSL бывают и графическими.


Ага. Интуитивно так и кажется. Но формально слово language тут уже несколько неуместно начинает выглядеть...
Re: Языки общего назначения не имеют смысла!
От: LaptevVV Россия  
Дата: 09.04.12 18:33
Оценка: +1
Здравствуйте, WolfHound, Вы писали:

WH>Никак. Языки общего назначения не имеют смысла.

WH>Чем больше изучаю, тем сильнее утверждаюсь в этом мнении.
И что смешно!
Мы означенный подход применили еще году в 85.
Был договор с Питерской конторой.
Мы сначала соединили ПЛ-1+ЛИСП. Лисп обрабатывался препроцессором.
Потом заменили препроцессор библиотекой и вызывали лисповские функции непосредственно из ПЛ-1.
Потом был разработан специальный язык и на этом ПЛ-1 с лиспом был написан интерпретатор.
А потом уже на этом языке была со свистом реализована задача договора.
Только тогда никто не знал термина DSL...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[16]: Языки общего назначения не имеют смысла!
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 09.04.12 18:43
Оценка: +1
Здравствуйте, alex_public, Вы писали:

_>Ага. Интуитивно так и кажется. Но формально слово language тут уже несколько неуместно начинает выглядеть...


Формально тоже все в порядке. Выражения типа "язык танца" или "язык тела" не встречал? Языки вовсе не обязаны быть исключительно текстовыми.
... << RSDN@Home 1.2.0 alpha 5 rev. 27 on Windows 7 6.1.7601.65536>>
AVK Blog
Re[17]: Языки общего назначения не имеют смысла!
От: alex_public  
Дата: 09.04.12 18:56
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Формально тоже все в порядке. Выражения типа "язык танца" или "язык тела" не встречал? Языки вовсе не обязаны быть исключительно текстовыми.


В программирование язык — это всё же вполне формальная сущность с синтаксисом, семантикой и т.п. А их довольно трудно разглядеть в GUI редакторе. )

А в общемупотребительной терминологии конечно проблем нет тогда. Там вообще можно увидеть фразу "найти общий язык с компьютером". )))
Re[18]: Языки общего назначения не имеют смысла!
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 09.04.12 19:06
Оценка: +1
Здравствуйте, alex_public, Вы писали:

_>В программирование язык — это всё же вполне формальная сущность с синтаксисом, семантикой и т.п. А их довольно трудно разглядеть в GUI редакторе. )


http://en.wikipedia.org/wiki/Visual_programming_language

И грамматику для графического языка тоже можно написать ничуть не хуже, чем для тектового.
... << RSDN@Home 1.2.0 alpha 5 rev. 27 on Windows 7 6.1.7601.65536>>
AVK Blog
Re[9]: Языки общего назначения не имеют смысла!
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.04.12 20:50
Оценка:
Здравствуйте, BrainSlug, Вы писали:

BS>vba — язык общего назначения? если нет, тогда 1С тоже нет. язык 1С замкнут на самой платформе, на которой решается определенный круг проблем. Все. Без дополнительных приблуд (типа подключение внешних библиотек) на нем больше ничего сделать нельзя.


Тут имеет место терминологическая путаница. Во многих местах языки вроде VBA названы ДСЛ-ями, так как они используются для решения специфичных задач (например, для написания макросов).

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

1Эс — это тоже язык общего назначения встроенный в предметную систему. Но в отличии от VBA он предназначен не для автоматизации основного приложения в рантайме, а для разработки в рамках интегрированной системы.

По сути 1Эс — это такой ФохПро или Эксес в который встроили специализированные библиотеки (и утилиты).

Главное что отличает настоящие ДСЛ-и от 1Эс и VBA — это то, что полноценные ДСЛ-ли позволяют описывать прикладную задачу на более высоком абстракнтом уровне.

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

Мощь 1Эс не в языке (который там совсем примитивный диалект Бэйсика), а в наличии высокуорвневых библиотек и кучи готовых решений предоставляемых в исходных кодах. Это позволяет не писать продукт с нуля, а дорабатывать наиболее близкое решение.

Мощь же ДСЛ-ей заключается именно в повышение уровня описания решения — декларативности.

Если же называть и то, и другое ДСЛ-ями, то не ясно как отделять одно от другого.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Языки общего назначения не имеют смысла!
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.04.12 21:25
Оценка:
Здравствуйте, VoidEx, Вы писали:

VE>Вопрос "через зад — это как?" напрашивается сам собой.

VE>Советую сразу брать такое определение: любой тьюринг полный язык — язык общего назначения, кроме SQL.

Тут проблема в тремине "тьюринг полнота". Сама по себе она еще не дает возможности присать полезные программы. Вот на VBA можно прочесть файл и вывести данные на любое устройство. А на SQL или на шаблонах С++ нельзя. Хотя оба вроде как теоретически полны по тьюрингу.

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

Иначе в этом делении нет никакого смысла и все языки программирования становятся ДСЛ-ями. Ведь в какой-то мере все языки заточны на что-то.

VE>По-моему, SQL тут просто ярчайший пример того, что твоё определение несостоятельно. Потому что грань "через зад"/"не через зад" провести ты не сможешь.


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

Кроме того отличным фактором является отрезанность от мира. SQL без процедурных расширений не позволяет производить универсальный ввод/вывод, в то время как любой ЯОН позволяет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Языки общего назначения не имеют смысла!
От: Vain Россия google.ru
Дата: 09.04.12 21:25
Оценка: :)
Здравствуйте, WolfHound, Вы писали:

V>>А какие факты?

WH>Многократное снижение издержек вот какие.
Это будет после того как вложишься и с вероятностью "0.0~1" дойдешь до саксесса, что вообще-то и не факт.

V>>Факты про то что многие языки общего назначения являются промышленным стандартом?

WH>Миллион мух не может ошибаться.
Это вы программистов на C/C++/java и т.д. как как щас назвали?

V>>Факты про то что ни один старап не будет рисковать своим проектом и как следствие кошельком чтобы проверять выстрелит ли дсл?

WH> Это вообще бред сивой кобылы.
WH>Многие стартапы как раз и поднялись на ДСЛях.
А вы считали сколько из них не поднялись и не собирались использоваться? Думаю процентик то поболе будет.

V>>Факты про то что существует куча уже написанного и, главное, отлаженного временем кода который никто не захочет менять на написание какого-то там дсл?

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

V>>Факты про то что программистов с языком общего назначения на порядок больше чем дсл писателей, что сказывается на их цене?

WH>Смешной ты человек.
WH>Вот ты на SQL пишешь?
Ну так я его и не поддерживаю, за меня его поддерживают, это какбе огрооомный плюс, что ставит этот дсл просто в угол ко всем языкам.

WH>А это ДСЛ.

А какой именно? Щас много всяких диалектов. Я в своё время писАл на sybase диалекте, помню помню, ещё тот геморрой был — шаг в сторону и нихрена уже не работает.

WH>ДСЛ вообще изучить очень просто.

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

V>>Эти факты как раз все против дсл.

WH>Это не факты. Это мифы.
кому как.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[8]: Языки общего назначения не имеют смысла!
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.04.12 21:31
Оценка: +1
Здравствуйте, mrTwister, Вы писали:

VD>>Он тебя спрашивает — станешь ли ты лезть в БД вручную (использовать ISAM), при наличии скуля?


T>Вообще-то сравнение с ISAM совершенно не в тему. SQL скорее надо сравнивать с CriteriaQuery, то есть с API, который построен на основе ЯП общего назначения.


Нет. Именно в тему. SQL — это специализированный язык запросов который создает языковый абстрактный уровень над ядром СУБД, который имеет ISAM-организацию (в большинстве случаев).

То на что ты дал ссылку — это тоже ДСЛ. Только кривой, неудобный и медленный, так как сделан неподходящими средствами (хост-языка).

Тут же речь идет именно о разнице между использованием ДСЛ-я и ручном кодировании того же самого.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Языки общего назначения не имеют смысла!
От: WolfHound  
Дата: 09.04.12 21:46
Оценка:
Здравствуйте, Vain, Вы писали:

V>Это будет после того как вложишься и с вероятностью "0.0~1" дойдешь до саксесса, что вообще-то и не факт.

У меня 100% успеха.
Что я делаю не так?

V>Это вы программистов на C/C++/java и т.д. как как щас назвали?

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

WH>>Обычно намного проще чем библиотеку которой его пытаются заменить.

V>Это спорное утверждение.
Ну, давай изучи АПИ для прямых обращений к физической структуре БД.
Удачи.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[15]: Языки общего назначения не имеют смысла!
От: Vain Россия google.ru
Дата: 09.04.12 22:30
Оценка: :))
Здравствуйте, WolfHound, Вы писали:

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


V>>Это будет после того как вложишься и с вероятностью "0.0~1" дойдешь до саксесса, что вообще-то и не факт.

WH>У меня 100% успеха.
Не верю (C)

V>>Это вы программистов на C/C++/java и т.д. как как щас назвали?

WH>Это я к тому что аппеляция к большенству примитивная демагогия.


WH>>>Обычно намного проще чем библиотеку которой его пытаются заменить.

V>>Это спорное утверждение.
WH>Ну, давай изучи АПИ для прямых обращений к физической структуре БД.
А в чём проблема? MFC, ADO, DAO?
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[11]: Языки общего назначения не имеют смысла!
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.04.12 22:45
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>И что? DSL как правило менее мощный, нежели сравнительно универсальный язык, каковым является SQL.


По сути согласен с тобой. По форме — нет.

Мощный тут не поределено. Да и SQL — это тоже DSL.

Тут правильнее было бы говорить об уровне специализации DSL-я. Более специализированные DSL-и (при правильном их использовании) являются более выразительными, но менее универсальными.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Языки общего назначения не имеют смысла!
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.04.12 22:51
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>>>Возьми пару известных систем и покажи где там eSQL

AVK>>1C 8 подойдет?
G>Ага, там совершенно тупая трансляция в SQL.

Способ реализации DSL-я не влияет на его свойства. По любому DSL будет удобнее, а код на нем короче. Иначе никто не стал бы лепить DSL-и, над другими языками (и уже тем более над другими DSL-ями как в случае с SQL).

G>>>Покажи некривой. Только реальный, не академический.

AVK>>Ну вот Парус 10 такой Реальный, не академический.
G>Ну пример приведи, я не пользуюсь парусом.

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

Ты логику вообще проходил?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Языки общего назначения не имеют смысла!
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.04.12 23:00
Оценка:
Здравствуйте, VoidEx, Вы писали:

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


1. Клинические идиоты скорее всего принисут один убыток.
2. Прибыть можно получать тупо уменьшив количество занятых в разработке программистов, ведь основные затраты на разработку ПО — это заработная плата.
3. Людям с ограниченными умственными способностями куда безопаснее и эффективнее давать DSL-и или визуальные дизайнеры. Это позволяет их лучше контролировать и снизить на них нагрузку.

VE>Поэтому для одних есть сложные инструменты, и их это устраивает, а для других инструменты попроще, и их тоже это устраивает.


DSL-подход позволяет задействовать башковитых людей при разработке DSL-ей, а тех что по тупее в качестве пользователей DSL-ей.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Языки общего назначения не имеют смысла!
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.04.12 23:05
Оценка:
Здравствуйте, Хвост, Вы писали:

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


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

А много вам дали библиотеки при написании тех же рефакторингов?

Нет, не подумай, что мы тут маньяки. Если задача решается либой сносно, то городить огород с DSL-ями смысла нет. Но есть куча задач (во всех без исключения областях), которые не решаются библиотеками или решаются не достаточно качественно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Языки общего назначения не имеют смысла!
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.04.12 23:14
Оценка:
Здравствуйте, Хвост, Вы писали:

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

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

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


А сбацай нам парсер какого-нить не сложного языка вроде джейсона. Сравним его со генерированным PegGrammar-ом по объему кода и скорости работы. Ты же профи в этой области!

Проверим, так сказать, на практике и циферки, и твои сомнения. Если ты прав, то без труда запихаешь все в библиотеку, кода у тебя будет хотя бы столько же как в вариенте PegGrammar-а. Ну, и скоростью похвастаешься. Хэнд-мэйд все таки.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Языки общего назначения не имеют смысла!
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.04.12 23:21
Оценка:
Здравствуйте, Vain, Вы писали:

V>>>И главное много этих щас дсл писателей, что взял и заменил? И ты согласен за свой счёт таких учить?

WH>>Да запросто. Любой толковый программист осилит за несколько дней, если использовать правильный инструмент.
V>А нахрена когда есть уже готовые специалисты "общего назначения"?

Это из той же серии что и "Нахрена лифты, когда есть лестницы?", "Нахреа роторные экскаваторы, когда есть лопаты?", "Нахрена компьютеры, когда есть счеты?"... И, главное, обоснование можно то же использовать — нахрена вифтеры, эксковаторщики, программисты, когда есть специалисты "общего назначения" у которых есть ноги, руки и голова которые отлично справляются с хождением по лестницам, рытьем лопатой и щелканье костяшками?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Языки общего назначения не имеют смысла!
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 09.04.12 23:27
Оценка: -1
Здравствуйте, AndrewVK, Вы писали:

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


AVK>>>1C 8 подойдет?

G>>Ага, там совершенно тупая трансляция в SQL.

AVK>Ну да, обозвал тупым и все понятно. Запрос там строится в терминах одноэсных документов, проводок и т.п. И результат тоже возвращается ввиде объектов 1С.

Только все это 1-в-1 мапится на SQL, только имена переписываются.

AVK>>>Ну вот Парус 10 такой Реальный, не академический.

G>>Ну пример приведи, я не пользуюсь парусом.

AVK>Ну вот что в тестах, к примеру, валяется:

Так это SQL. А где его собственный DSL?

AVK>>>Как обычно. В том что при решении определенного класса задач DSL значительно лучше универсального языка.

G>>В чем лучше?
AVK>Во всем.
Ага, грузины лучше чем армяне
Аргументация на уровне детсада.

G>> Вот на примере SQL мы видим что dsl_и над ним не лучше.

AVK>Это где ты такое увидел?
Везде. От eSQL\HQL до корпоративных систем.

G>>>> Если менее мощный, то надо или больше писать для достижения того же результата

AVK>>>Попробуй доказать.
G>>Так ты сам сказал что

G>>

G>>DSL как правило менее мощный, нежели сравнительно универсальный язык


AVK>Доказать, что менее мощный язык означает, что для достижения того же результата надо больше писать.

Тогда давай формализуем понятие мощности. Если рассматривать полноту по тьюригу, то ей не все dsl обладают , следовательно на них нельзя написать все.
Если мы рассматриваем мощность как выразительную силу языка, то есть возможности выразить некоторые вычисления наименьшим количеством конструкций этого самого языка, то очевидно что в менее мощном языке надо больше писать для достижения того же результата.
Re[15]: Языки общего назначения не имеют смысла!
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 09.04.12 23:30
Оценка:
Здравствуйте, VladD2, Вы писали:

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


G>>>>Возьми пару известных систем и покажи где там eSQL

AVK>>>1C 8 подойдет?
G>>Ага, там совершенно тупая трансляция в SQL.

VD>Способ реализации DSL-я не влияет на его свойства. По любому DSL будет удобнее, а код на нем короче. Иначе никто не стал бы лепить DSL-и, над другими языками (и уже тем более над другими DSL-ями как в случае с SQL).


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

G>>>>Покажи некривой. Только реальный, не академический.

AVK>>>Ну вот Парус 10 такой Реальный, не академический.
G>>Ну пример приведи, я не пользуюсь парусом.

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

VD>Ты логику вообще проходил?

Я не доказываю, я спрашиваю пример некривого dsl для корпоративной системы. SQL не рассматриваем, ибо он уже далеко не dsl.
Re[7]: Языки общего назначения не имеют смысла!
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 09.04.12 23:33
Оценка:
Здравствуйте, VladD2, Вы писали:

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


WH>>>Когда этим кто-нибудь займется. Твой КО.

G>>Так почему до сих пор не занялись? Бинес-задачи меняются мало, а кроме SQL пока ниче не придумано.
G>>В чем проблема?

VD>Почему не придумали? Придумали и массу. Проблема только в том, что:

VD>* Для большинства задач написание DSL, с использованием "лопаты", не закончится к сроку завершения проекта.
VD>* Для большинства задач требуется в разы меньшая квалификация, тем для разработки DSL, с использованием "лопаты".
Я говорил тоже самое, со мной начали спорит

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

G>>Это технически невозможно, сервер на другом компе стоит, порты закрыты.
VD>Что-то ты гонишь. Вы СУБД не используете? Или SQL не применяете?
VD>Он тебя спрашивает — станешь ли ты лезть в БД вручную (использовать ISAM), при наличии скуля?
Еще раз повторю, технически возможности нет. SQL — единственный интерфейс реально доступный для приложения.

А вот лазать руками по файловым базам, типа sqlce — было дело.
Re[14]: Языки общего назначения не имеют смысла!
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.04.12 23:34
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Вот смотрю я на этот пример и думаю... А означает ли факт кодогенерации обязательное наличие DSL? Например, я уже писал тут, что мы используем для создания GUI визуальный редактор, который генерирует весь код создания интерфейса неспредственно на системном языке. Т.е. кодогенерация больших объёмов у нас тут есть, а никаких DSL вроде как и не видно.


Сложный вопрос. ДСЛ может быть разным. В том числе ДСЛ может описываться набором объектов в ЯОН (языке общего назначения).

Тут важен факт наличия некой модели по которой генерируется код. Эта модель и есть по сути ДСЛ.

Визуальный редактор не всегда генеирирует код на ЯОН. Скажем тот же МС помучившись с генерацией и интерпретацией ЯОН-ов в ВинФормсах выбрала DSL основанный на XML в WCF. И сделано это было не потому что в МС ополоумили. Просто с генерацией ЯОН (и тем более с их чтением) были серьезные проблемы. А уж о рантайм-генерации и думать было сложно. На серевере это еще прокатывает (АСП.НЕТ), но на клиенте слишком много сложностей.

Кроме того в тех же ВинФормсах поддержка генерации ЯОН не полная. По сути поддерживается только подвид ЯОН-ов воспроизводящий нужную функциоальность. И при этом не делается многих проверок. Так что сгенерированный код может вполне оказаться не компилируемым. Сложность добавления поддержки нового языка тоже вилика. К тому же F#-у дизайнер винформсов так и не прикрутили (не смотря на ресурсы и знания МС).

_>И вообще вопрос в продолжение этой мысли... Может во многих случаях как раз такое и нужно? Т.е. именно генерация кода, а не dsl?


Как раз лучше полноценный ДСЛ. Но по бедности создание ДСЛ-ей выливается в слишком большой геморрой. Генерация тоже выливается в геморрой. По этому народ чаще всего тупо плюет на эти подходы и долбит все руками (набирая тучу индокодеров). И только при частом изменении модели (см. выше) отдельные личности приходят к ДСЛ-ям/генерации кода по модели.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: Языки общего назначения не имеют смысла!
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.04.12 23:43
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Если там можно будет писать какой-то достаточно сложный код (в рамках DSL, т.е. касающийся только GUI), а не просто делать размётку контролов, то да, это заметно удобнее было бы. А если у нас тут решается только задача "нарисовать" интерфейс, то все эти сущности уже лишними кажутся — проще кодогенерация из визуального редактора.


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

Паттерн MVVM решает две остальные проблемы, но при ручном его реализации приводит к довольно большому объему кодирования (бестолкового копипаста с изменениями) и/или к рантайм-высислениям которые нельзя проверить во время компиляции. Тут использование ДСЛ-ней и генерации кода может дать огромный выигрыш.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Языки общего назначения не имеют смысла!
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.04.12 23:44
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Ага. Интуитивно так и кажется. Но формально слово language тут уже несколько неуместно начинает выглядеть...


Первые естественные языки тоже были графическими . Пиктушки родились раньше букв. Буквы — это прогресс.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Языки общего назначения не имеют смысла!
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.04.12 23:45
Оценка: :))
Здравствуйте, AndrewVK, Вы писали:

AVK>Формально тоже все в порядке. Выражения типа "язык танца" или "язык тела" не встречал? Языки вовсе не обязаны быть исключительно текстовыми.


Ага — Мальчик жестами показал, что его звали "Хуан".
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Языки общего назначения не имеют смысла!
От: Vain Россия google.ru
Дата: 09.04.12 23:46
Оценка:
Здравствуйте, VladD2, Вы писали:

V>>>>И главное много этих щас дсл писателей, что взял и заменил? И ты согласен за свой счёт таких учить?

WH>>>Да запросто. Любой толковый программист осилит за несколько дней, если использовать правильный инструмент.
V>>А нахрена когда есть уже готовые специалисты "общего назначения"?
VD>Это из той же серии что и "Нахрена лифты, когда есть лестницы?", "Нахреа роторные экскаваторы, когда есть лопаты?", "Нахрена компьютеры, когда есть счеты?"... И, главное, обоснование можно то же использовать — нахрена вифтеры, эксковаторщики, программисты, когда есть специалисты "общего назначения" у которых есть ноги, руки и голова которые отлично справляются с хождением по лестницам, рытьем лопатой и щелканье костяшками?
Никто собственно не отменял прогресс. Но вы ставите знак равенства между прогрессом и дсл как что-то очевидное, не доказав что они вообще должны быть равны и равны вообще. А любые вопросы на тему почему они равны сводятся опять же к аппеляции что если не равны то это отказ от прогресса.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[12]: Языки общего назначения не имеют смысла!
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.04.12 23:58
Оценка: +1
Здравствуйте, Vain, Вы писали:

V>Факты про то что ни один старап не будет рисковать своим проектом...


Вот это ты сейчас хорошо пошутил. У стартапов весь смысл в риске ради возможного поблучения резких конкуретных преимуществ. По сему стартап не желающий рисковать исходно обречен. Ведь есть большие компании которые используют технологии с меньшим риском. Но у больших компаний есть другие конкуретные преимущества (ресурсы и маркетинг).

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


Кошелек то не их. В этом вся суть .

V> Факты про то что существует куча уже написанного и, главное, отлаженного временем кода который никто не захочет менять на написание какого-то там дсл?


А зачем менять отлаженный код без надобности? Можно его обернуть в ДСЛ, или использовать ДСЛ в тех областях где код не так отлажен или его приходится постоянно колбасить руками (менять или писать новый).


V>Факты про то что программистов с языком общего назначения на порядок больше чем дсл писателей, что сказывается на их цене? Эти факты как раз все против дсл.


Писать ДСЛ-и не должны все кому не лень. А вот использовать и изучать куда легче чем код написанный вручную.

Сейчас основная проблема в ДСЛ-подходе — это сложность разработки и сопровождения ДСЛ-ей, а так же низкое качество получаемых ДСЛ-ей (нет поддержки ИДЕ, низкая скорость, нет контроля типов, нет документации). Если их решить, то ДСЛ будет отличным решением для многих проблем.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Языки общего назначения не имеют смысла!
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.04.12 00:20
Оценка:
Здравствуйте, Хвост, Вы писали:

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


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

Х>совсем редко всякий экстрим вроде пролога можно не рассматривать.


Чёйта? Формальная логика вдруг перестала быть универсальной моделью для программистов?

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


Жаль что этого не знали создатели F#-па которые для разработки компилятора F# написанного на F#-е использовали ДСЛ (генератор парсеров аналогичный yacc-у). Видимо им была не знакома тавоя замечательная теория.

И вообще, не ясно зачем тогда нужны эти Скалы и F#-ы, если по твоей теории для представления чего угодно достаточно лябда-исчислений или машины Тюринга.

Вот, к примеру, БэйнФак полон по тьюрингу. Так почему бы не писать код на нем, а не на Скале или F#-е?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Языки общего назначения не имеют смысла!
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.04.12 00:31
Оценка:
Здравствуйте, VoidEx, Вы писали:

VE>Вы почему-то думаете, что если термины предметной области выражены через конструкции C#, то это язык C# и учить ничего не надо. Однако изучение сколь-нибудь большой библиотеки это и есть изучение понятий самой библиотеки, и если бы она была выражена в виде простого DSL, учить её было бы проще.


Остается только понять почему VoidEx периодически троллит нас исповедуя, казалось бы, те же истины.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Языки общего назначения не имеют смысла!
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.04.12 00:41
Оценка: 1 (1)
Здравствуйте, D. Mon, Вы писали:

DM>Слова сомнения:

DM>Следует помнить, что подход этот оправдан, когда есть множество похожих задач из одной области. Ведь вместо прямого решения задачи предлагается делать универсальный решатель задач подобного рода. Его сделать сложнее (и дело отнюдь не в парсинге), поэтому чтобы это дело окупилось, нужно решать им не одну задачу, а серию. Если же задача штучная, то смысла в таком подходе не видно, тут языки общего назначения и пригодятся. Так что совсем уж их объявлять бессмысленными не стоит.

Это не слова сомнения, а голос разума. ДСЛ ни разу не серебрянная пуля. Его создание и поддержка, даже на очень выскокоуровневом средстве (которым должен стать N2
Автор: VladD2
Дата: 28.03.12
) все равно не станет тривальной задачей.

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

Но такие задачи отнюдь не редки. И только наше неумение их выявлять, и крайне низкая производительность труда тех кто создает инструменты поддержки ДСЛ-ей делают этот подход крайне не распространенным.

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

Так что тут нужно не критиковать, а прорабатывать научную и техническую базу.

На мой взгляд, как ООП и ФП, в свое время, ДСЛ-естроение должно занять свою нишу в инструментарии (в широком смысле этого слова) современного разработчика. Но для этого нужно изменить современные средства разработки и современные языки. Они реально тормозят прогресс.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Языки общего назначения не имеют смысла!
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.04.12 00:53
Оценка: +2
Здравствуйте, gandjustas, Вы писали:

G>Это я не спорю, что есть некоторые DSL, код на которых короче, лучше итп

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

Да это Вольфхаунд преувеличивает, как всегда. Он ультра-максималист.

Есть и туча задач которые не требуют языковой абстрации. Скажем одноразовые задачи или вычислительные задачи (где ДСЛ — это арифметика). Кроме того обычно между ДСЛ-ями нужен "клей". ЯОН (язык общего назначения) является таким клеем.

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

G>Я не доказываю, я спрашиваю пример некривого dsl для корпоративной системы. SQL не рассматриваем, ибо он уже далеко не dsl.


Тебе уже привели примеры языков запросов из 1Эс и Паруса. SQL тоже рассматриваем, так как он классический ДСЛ. Просто он общепринятый ДСЛ.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Языки общего назначения не имеют смысла!
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 10.04.12 00:57
Оценка:
Здравствуйте, VladD2, Вы писали:


G>>Я не доказываю, я спрашиваю пример некривого dsl для корпоративной системы. SQL не рассматриваем, ибо он уже далеко не dsl.


VD>Тебе уже привели примеры языков запросов из 1Эс и Паруса.


1C плохой пример — там запросы 1-в-1 транслируются в SQL, только имена переписываются.

VD>SQL тоже рассматриваем, так как он классический ДСЛ. Просто он общепринятый ДСЛ.

Он был таким лет 20 назад. Если сейчас посмотреть на pl\sql, то DSL его назвать — язык не поворчивается.
SQL в версии стандарта 92 года — да, DSL. Но если посчитать сколько в его разработку вложено, но аналогов не найдешь.
Re[8]: Языки общего назначения не имеют смысла!
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.04.12 00:59
Оценка:
Здравствуйте, gandjustas, Вы писали:

VD>>Почему не придумали? Придумали и массу. Проблема только в том, что:

VD>>* Для большинства задач написание DSL, с использованием "лопаты", не закончится к сроку завершения проекта.
VD>>* Для большинства задач требуется в разы меньшая квалификация, тем для разработки DSL, с использованием "лопаты".
G>Я говорил тоже самое, со мной начали спорит

Я тебя и цитировал. Только ты сравни цитаты. Они ведь не точные. Я там лопату добавил.

У ДСЛ-подхода есть две проблемы:
1. Сложность выявления ДСЛ-ей в прикладной задаче. Эта проблема опыта и образования. Если в универах начнут этому учить, то проблема исчезнет.

2. Сложность реализации и поддержки ДСЛ-ей. Это техническая проблема которую можно решить самим же ДСЛ-подходом.

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

G>>>Это технически невозможно, сервер на другом компе стоит, порты закрыты.
VD>>Что-то ты гонишь. Вы СУБД не используете? Или SQL не применяете?
VD>>Он тебя спрашивает — станешь ли ты лезть в БД вручную (использовать ISAM), при наличии скуля?
G>Еще раз повторю, технически возможности нет. SQL — единственный интерфейс реально доступный для приложения.

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

А межу прочем году так в 9х (точно не помню) мне один не глупый с виду дядька из одной именитой конторы втирал, что MS SQL (тогда еще совсем древний) дерьмо, так как у него доступ на ISAM уровне не документирован. А вот Б-трив — это супер, так как в нем он четко прописан.

G>А вот лазать руками по файловым базам, типа sqlce — было дело.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Языки общего назначения не имеют смысла!
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.04.12 01:01
Оценка:
Здравствуйте, Vain, Вы писали:

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


Все по сто раз доказано. Читайте Фаулера. Он все разжевал и разложил по полочкам.

Тут вопрос в сознании людей и в инструментах. Второе можно поправить. С первым все сложнее.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Языки общего назначения не имеют смысла!
От: __lambda__ Россия http://zen-hacker.blogspot.com/
Дата: 10.04.12 02:44
Оценка: :)))
Здравствуйте, VoidEx, Вы писали:

___>>Только с другой стороны, если язык будет позволять менять синтаксис, встраивать в себя HTML, SQL, абракадабру Васи Пупкина, блабладсл Пети из соседнего отдела и т.д. Бедному программисту Ване Иванову, только принятому на работу, придется учить все эти супермегаязыки.


VE>Ему и так придётся.


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

VE>Вы почему-то думаете, что если термины предметной области выражены через конструкции C#, то это язык C# и учить ничего не надо. Однако изучение сколь-нибудь большой библиотеки это и есть изучение понятий самой библиотеки, и если бы она была выражена в виде простого DSL, учить её было бы проще.


Зачем учить внутренности библиотеки, в том то и весь смысл библиотек, что нужно лишь знать внешний интерфейс. Черный ящик, декомпозиция, модульность... Это же азбука. Если вам приходится читать внутренний код библиотек, разбираться в том, как она устроена, ты вы явно че-то не то делаете.
Computer science is no more about computers than astronomy is about telescopes (c) Edsger Dijkstra
Re[10]: Языки общего назначения не имеют смысла!
От: BrainSlug Израиль  
Дата: 10.04.12 03:57
Оценка: +1
Да, я согласен. (спасибо за разъяснение). Я думаю путаница с 1С возникает потому, что это язык общего назначения, но с встроенными dsl. Хотя бы свой язык запросов там dsl. И потом методы работы с встроенными объектами — например Документы.Счет.СоздатьДокумент(), завязанные на контекст предметной области — вроде как тоже dsl. И кстати там была попытка сделать эквивалент запросам, но чего-то идею не развили. Например. Документы.Счет.Выбрать() суть обычная выборка — select Счет from Счет, хотя я считаю в этом есть смысл. Запросы бывают иногда на несколько страниц. Это основная проблема как мне кажется sql-подобных языков, при кажущейся простоте, довольно сложно прочитать большой запрос целиком.
.
Re[9]: Языки общего назначения не имеют смысла!
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 10.04.12 04:55
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>У ДСЛ-подхода есть две проблемы:

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

Наверно, тогда не выявления DSL, а 1) выявления их желательности, 2) выявления, что именно должно туда попасть.

G>>Еще раз повторю, технически возможности нет. SQL — единственный интерфейс реально доступный для приложения.


VD>Это потому-что кто-то уже решил за тебя, что смысла использовать ISAM нет. И решил он это именно на том основании, что уже есть отличный ДСЛ радикально упрощающий взаимодействие с СУБД.


VD>А межу прочем году так в 9х (точно не помню) мне один не глупый с виду дядька из одной именитой конторы втирал, что MS SQL (тогда еще совсем древний) дерьмо, так как у него доступ на ISAM уровне не документирован. А вот Б-трив — это супер, так как в нем он четко прописан.


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

Я в те времена пробовал SQL ещё в FoxPro 2-м-каком-то и долго плевался, потому что "это" убивало производительность на порядок. Хотя внешне всё красиво, мол, оно само собой строит реальный запрос, разбирает связи, вычисляет ограничения и оптимизирует поиск... документация была даже полна восторженных воплей по поводу какого-то суперхитрого метода Rushmore (что это, никто не раскрывал, но было похоже на метод немедленного прыжка к нужному ключу).

Возможно, в высококорпоративном мире с его подходами SQL был уже тогда единственным нормальным путём, но кто это мог получить *тут* на живых примерах? Массовая миграция на подходы с SQL — это уже конец 90-х, если не 2000-е.

Вот тебе и адекватность DSL.
The God is real, unless declared integer.
Re[16]: Языки общего назначения не имеют смысла!
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 10.04.12 05:02
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Я не доказываю, я спрашиваю пример некривого dsl для корпоративной системы. SQL не рассматриваем, ибо он уже далеко не dsl.


От того, что кто-то замкнул SQL до тьюринг-полноты, он (jIMHO, конечно) не теряет свои основные подходы и применения именно как описатель запросов и соответственно остаётся DSLем именно для этой цели.

Думаю, основной из моментов, за который тут зацепились спорщики, должен быть как раз в чёткой формулировке метода отделения прямых методов применения от непрямых, основанных на тёмных углах, пристроенных сбоку возможностях и дополнительных слоях абстракций.
The God is real, unless declared integer.
Re[14]: Языки общего назначения не имеют смысла!
От: VoidEx  
Дата: 10.04.12 05:25
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Тут проблема в тремине "тьюринг полнота". Сама по себе она еще не дает возможности присать полезные программы. Вот на VBA можно прочесть файл и вывести данные на любое устройство. А на SQL или на шаблонах С++ нельзя. Хотя оба вроде как теоретически полны по тьюрингу.


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


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


Я думаю, стоит копать в направлении "полноценные ДСЛ-ли позволяют описывать прикладную задачу на более высоком абстракнтом уровне", но не по сравнению с языками общего назначения, а по сравнению с прикладной задачей в другой области.
Т.е. если на DSL для вычисления факториала приходится пользоваться терминами той предметной области, под которую он заточен (и вычисление факториала на порядки менее высокоуровнево, чем решение задачи из своей области), то это DSL. Даже если задачу из родной области решить проще на Nemerle.
Т.о. главное — нацеленность на одну область.
В этом смысле хоть на SQL и можно факториал посчитать, но это куда сложнее, чем то, для чего SQL предназначен.

Грань, правда, опять не провести, поэтому видимо придётся DSL-изм переименовать в DSL-альность

VE>>По-моему, SQL тут просто ярчайший пример того, что твоё определение несостоятельно. Потому что грань "через зад"/"не через зад" провести ты не сможешь.


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


Это не чёткая грань, а некоторая мера. В целом, согласен.
И если уж признать, что DSL — это мера, а не bool, то спорить про VBA становится проще. Потому что обе стороны могут не спорить, DSL это или нет, а сойтись на том, что он менее DSL, чем SQL, но всё же не такого уж общего назначения, как C#.
Re[5]: Языки общего назначения не имеют смысла!
От: alex_public  
Дата: 10.04.12 05:36
Оценка:
Здравствуйте, VladD2, Вы писали:

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

VD>А сбацай нам парсер какого-нить не сложного языка вроде джейсона. Сравним его со генерированным PegGrammar-ом по объему кода и скорости работы. Ты же профи в этой области!

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

Но потом подумал... А ведь Boost.Spirit — это же на самом деле тоже разновидность DSL!

Кстати, глянул только что в гугле: не мне одному такая мысль сразу в голову пришла — уже есть готовое такое http://boost-spirit.com/repository/applications/json_spirit.zip

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


Интересно, а что можно было бы использовать при разработке такого парсера, что бы не считалось что используем DSL какой-то? Регулярные выражения? Не, тоже dsl... Остаётся только в лоб реализовать разбор посимвольный, в виде какого-нибудь конечного автомата. Я бы не стал.

P.S. Boost.Spirit очень быстрый. )
Re[15]: Языки общего назначения не имеют смысла!
От: VoidEx  
Дата: 10.04.12 05:39
Оценка: +4
Здравствуйте, WolfHound, Вы писали:

V>>Это вы программистов на C/C++/java и т.д. как как щас назвали?

WH>Это я к тому что аппеляция к большенству примитивная демагогия.

Аппеляция к инструменту, который уже написан, и на который затрачено куча времени и сил, тоже демагогия.

WH>>>Обычно намного проще чем библиотеку которой его пытаются заменить.

V>>Это спорное утверждение.
WH>Ну, давай изучи АПИ для прямых обращений к физической структуре БД.
WH>Удачи.

Ну а ты давай сделай SQL с нуля, сам язык, теорию, и поддерживай это всё.

Он толсто намекает на то, что DSL написать — не поле перейти, и очень нередко написать "свой SQL" может оказаться сложнее, чем таки поработать через АПИ.
Только ты ему одну крайность кидаешь в качестве аргумента, а он тебе другую. Точнее говоря, ты опираешься на крайность (берёшь один из самых вырожденных случаев DSL) в качестве доказательства того, что DSL оправданы всегда, а это не так.
Re[7]: Языки общего назначения не имеют смысла!
От: VoidEx  
Дата: 10.04.12 05:41
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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


VD>1. Клинические идиоты скорее всего принисут один убыток.

VD>2. Прибыть можно получать тупо уменьшив количество занятых в разработке программистов, ведь основные затраты на разработку ПО — это заработная плата.
VD>3. Людям с ограниченными умственными способностями куда безопаснее и эффективнее давать DSL-и или визуальные дизайнеры. Это позволяет их лучше контролировать и снизить на них нагрузку.

VE>>Поэтому для одних есть сложные инструменты, и их это устраивает, а для других инструменты попроще, и их тоже это устраивает.


VD>DSL-подход позволяет задействовать башковитых людей при разработке DSL-ей, а тех что по тупее в качестве пользователей DSL-ей.


Этот подход работает прекрасно и сейчас. Только используют не DSL, а библиотеки.
Re[5]: Языки общего назначения не имеют смысла!
От: VoidEx  
Дата: 10.04.12 05:44
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>А сбацай нам парсер какого-нить не сложного языка вроде джейсона. Сравним его со генерированным PegGrammar-ом по объему кода и скорости работы. Ты же профи в этой области!


Мало что ли парсер-генераторов?

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


Ну когда не хватает библиотеки, можно и кодогенератор. Зачем всё в один исходник пытаться запихнуть под эгидой Универсального ДСЛ Конструктора?
Re[9]: Языки общего назначения не имеют смысла!
От: VoidEx  
Дата: 10.04.12 05:45
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Не совсем так. Лифты в одном месте, роторные экскаваторы в другом, компьютеры в третьем. А вот нахрена это всё собирать в одном, действительно не очень понятно.
Re[15]: Языки общего назначения не имеют смысла!
От: alex_public  
Дата: 10.04.12 05:47
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Визуальный редактор не всегда генеирирует код на ЯОН. Скажем тот же МС помучившись с генерацией и интерпретацией ЯОН-ов в ВинФормсах выбрала DSL основанный на XML в WCF. И сделано это было не потому что в МС ополоумили. Просто с генерацией ЯОН (и тем более с их чтением) были серьезные проблемы. А уж о рантайм-генерации и думать было сложно. На серевере это еще прокатывает (АСП.НЕТ), но на клиенте слишком много сложностей.


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

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

VD>Кроме того в тех же ВинФормсах поддержка генерации ЯОН не полная. По сути поддерживается только подвид ЯОН-ов воспроизводящий нужную функциоальность. И при этом не делается многих проверок. Так что сгенерированный код может вполне оказаться не компилируемым. Сложность добавления поддержки нового языка тоже вилика. К тому же F#-у дизайнер винформсов так и не прикрутили (не смотря на ресурсы и знания МС).


Хыхы, а тот наш редактор как раз генерит код сразу на нескольких языках. )))

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


Я в какой-то степени про это и говорю. Продумывание синтаксиса нового языка — это всё же определённая задача, которую не профи (в dsl строение) не так уж и просто решить. А вот такие инструменты по сути выполняют роль DSL, но при этом их создатели вообще не тратили время на продумывание синтаксиса и т.п.
Re[5]: Языки общего назначения не имеют смысла!
От: VoidEx  
Дата: 10.04.12 05:48
Оценка: :)
Здравствуйте, VladD2, Вы писали:

VE>>Вы почему-то думаете, что если термины предметной области выражены через конструкции C#, то это язык C# и учить ничего не надо. Однако изучение сколь-нибудь большой библиотеки это и есть изучение понятий самой библиотеки, и если бы она была выражена в виде простого DSL, учить её было бы проще.


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


Это метод получения информации в спорах. Поэтому я почти всегда занимаю противоположную точку зрения, а свою высказываю редко. Когда я вырабатываю для себя чёткую позицию, я теряю интерес к спору.
Re[5]: Языки общего назначения не имеют смысла!
От: VoidEx  
Дата: 10.04.12 06:00
Оценка: +1 :)
Здравствуйте, __lambda__, Вы писали:

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


Давайте посмотрим, например, на такой внешний интерфейс: http://msdn.microsoft.com/en-us/library/system.linq.enumerable.aspx
Вы всерьёз считаете, что с этим придётся долго возиться и учить
from num in numbers
            where num % 2 == 0
            orderby num
            select num;

а вот здесь надо "лишь посмотреть на внешний интерфейс"
numbers.Where(num => num % 2 == 0).OrderBy(n => n);



VE>>Вы почему-то думаете, что если термины предметной области выражены через конструкции C#, то это язык C# и учить ничего не надо. Однако изучение сколь-нибудь большой библиотеки это и есть изучение понятий самой библиотеки, и если бы она была выражена в виде простого DSL, учить её было бы проще.


___>Зачем учить внутренности библиотеки, в том то и весь смысл библиотек, что нужно лишь знать внешний интерфейс. Черный ящик, декомпозиция, модульность... Это же азбука. Если вам приходится читать внутренний код библиотек, разбираться в том, как она устроена, ты вы явно че-то не то делаете.


Внешний интерфейс и есть язык. Язык библиотеки. Он оперирует не объектами и методами, а терминами самой библиотеки. И вот это и надо изучать. А уж как там будет написано:
SomeObject x = new SomeObject(new RangeStep(10, 20, 3));
SomeBlabla y = Foo.Register(x, "y", "trololo");

или
y as trololo from 10 to 20 step 4

большого значения не имеет. Разве что второе проще читать и понимать, ибо первое загажено всякими языковыми деталями.
Re[15]: Языки общего назначения не имеют смысла!
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 10.04.12 07:11
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Ну вот что в тестах, к примеру, валяется:

Удалено избыточное цитирование.
AVK>В сиквел в итоге отдаеться такое:
Удалено избыточное цитирование.

Это аналог и 1С 8 го запроса (прада там еще и подмена названия полей). Правда в 1С бесит, что нет вывода типа для запросов и соответствующей подсказки. В Linq to EF тоже вроде такого плана можно строить запросы по ассоциациям. Правда могу ошибаться. Но и там нет автоматического вывода типа для результата запроса.
Кстати, что там нового для Linq to EF хотят сделать? Начал трансформировать файл edmx для "человеческого" воспиятия названия полей и ассоциаций (да и бороться без foreign key,а кое где и primary key). Сейчас обхожусь генераторами для прямых запросов, но было бы проще работать как через Linq to EF так и запросами аля 1С через измененные ScalarProperty Name. Есть возможность генерировать edmx через какой нибудь апи не трансформируя *.edmx?
и солнце б утром не вставало, когда бы не было меня
Re[15]: Языки общего назначения не имеют смысла!
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 10.04.12 07:32
Оценка:
Здравствуйте, AndrewVK, Вы писали:

Удалено избыточное цитирование.

Ну это аналогично трансформации 1С 8 ки. Правда бесит, что нет вывода типа результата запроса.
Часто приходится делать прямые запросы для апдейтов больших по объему данных, через генераторы запросов. Поэтому, мой взгляд упал на Linq to EF. Там мне понравилось, что можно использовать запросы по схеме. Правда опять же нет вывода типов (может сейчас что изменилось).Там можно переименовать свойства и ассоциации в файле .edmx. Началь делать, да что то времени не хватает да и желания. Да и в модели 1С для регистров нет первичных полей, а для ассоциаций вторичных.
Я выбрал путь через трансформацию EDMX, но может проще сделать EDMX через какой то АПИ, так по сути я могу создать и из 1С т.к. название полей и ассоциаций имеется?
и солнце б утром не вставало, когда бы не было меня
Re[9]: Языки общего назначения не имеют смысла!
От: mrTwister Россия  
Дата: 10.04.12 07:52
Оценка:
Здравствуйте, VladD2, Вы писали:

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


А по каким критериям ты относишь то или иное API к ДСЛ и к "ручному кодированию"? Если мы напишем класс, название которого соответствует некоторой доменной сущности, а методы соответствуют доменным операциям, то код, написанные с использованием этого класса является DSL? Скорее всего ты ответишь нет, но почему тогда Criteria API из hibernate является DSL?
лэт ми спик фром май харт
Re: Языки общего назначения не имеют смысла?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 10.04.12 08:05
Оценка: 83 (11) -1
Некоторые тезисы к обсуждению. Формулировки в заметной мере откорректированы с учётом уже сказанного в теме, как и вообще необходимость подобного постинга, хотя всё то же самое можно было сказать отдельно и независимо.

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

Язык команд x86 является DSL по сравнению с языком микрокоманд конкретного Core Duo или Sandy Bridge. Доменом является переносимая система команд x86.

Язык C является DSL по сравнению с языком команд конкретных x86, ARM или любого другого процессора.
Доменом является виртуальная модель среды исполнения C, со всеми её ограничениями (например, не может быть двух разных входов в функцию или неопределённых аргументов).

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

Декларативный язык является DSL по сравнению с процедурным языком. Доменом является поддержка описания зависимостей, условий и требований вместо ручного вычисления метода исполнения. Это в равной мере справедливо, например, для SQL и для Makefile.

2. Введение DSL, он же язык более высокого уровня, вызывается конкретным преимуществом его введения.

Типичными преимуществами являются:
  • Независимость от особенностей реализации (как переносимость системы команд, написания на C или доступные индексы для СУБД).
  • Устранение "геморроя", сиречь неприятных накладных расходов на реализацию. Характерный пример — ручное управление памятью.
  • Необходимость вывести определённые сущности из ментального поля автора реализации. Уже работа с указателями доступна не всем программистам, а учитывать сочетаемость акций в АЛУ конкретной модели сможет десяток человек по всему миру.

    В заголовке этого пункта сделано отождествление DSL и языка высокого уровня (высота этого уровня относительна), что является натяжкой по сравнению с утверждавшимся в пункте 1. Это может показаться чрезмерным, но подождите до конца изложения.

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

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

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

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

    Кто-то сейчас скажет, что у него всё это заглажено; верю. Как и с любым другим конкретным примером здесь, важны не средние случаи, а крайние. Кроме того, сказано "заметные недостатки", а не "существенные".

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

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

    Пример с прямой работой с внутренностями процессора был бы самым показательным, потому что маргинальность такой работы ясна каждому. Именно поэтому он мне не нравится. SQL интереснее: каждый может в своём воображении залезть внутрь базы и напрямую поработать с таблицей, но большинство понимает, почему этого не следует делать. (Может, это вообще не таблица.) Интересен также случай с make, или с тем странным зверем по ссылке WolfHound'а, который по сути — супернавороченный make. Можно писать зависимости напрямую, но лучше воспользоваться для этого явным языком и оставить вычисление среде исполнения.

    5. Понятие высокоуровневого языка программирования, сложившееся исторически и в основном разработанное в 1960-х годах, означает DSL.

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

    В основной же части отрасли высокий уровень определён обструктивно, то есть опре
    деляется запретом, а не утверждением. Аналогично тому, как воспитание есть больше правила, что *не* делать, чем то, что делать, высокий уровень — это обещание безопасности (не в смысле посторонних вторжений, а в смысле реализации только того, что требуется) за счёт отказа от возможностей. См. пункт 3.

    6. И наоборот, DSL в современном понимании неявно подразумевает отказ от возможностей, даже если это явно не формулируется.

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

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

    7. Языки более общего назначения (более низкоуровневые), несмотря на заголовок темы, имеют смысл.

    Они имеют смысл, во-первых, потому, что на чём-то надо реализовать этот DSL. Этот фактор очевиден, но его не следует упускать в данной дискуссии.

    Они имеют смысл, во-вторых, потому, что DSL всегда ограничен, а задачи — нет. Чем более низок уровень языка, тем меньше его надо менять под задачу.

    8. Радикальные примеры показывают радикальные случаи, но не годятся для доказательства в общем.

    Пример в стартовом письме данной темы является как раз таким радикальным случаем. Столько страстей, сколько в среднем фильме, вы можете не получить за всю жизнь, и такое же правило применимо и к программированию. Прорыв в 19 строк вместо ~4000 — дастся не каждому.

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

    10. Всё изложенное здесь нестрого и в принципе не может быть строгим.

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

    11. Основная часть споров, происходящих здесь — это конфликты опыта и эмоций в недостаточно однозначных случаях.
    Поэтому я не хотел вступать в тяжёлые дискуссии, которые тут заведомо неконструктивны.

    ---------------------------------------------------------------------------------------

    Можно заметить, что процентов 90 споров ведётся между немерлистами и прочими, на тему того, насколько просто можно писать DSL.

    Но синтаксис не является проблемой.
    В конце концов, всегда можно откатиться на XML/JSON/etc., не к ночи будь сказано

    Проблема — что именно в нём должно быть и чего не должно быть. А вот тут сложность фактически совпадает со сложностью придумывания нового языка программирования, и последствия те же — 99% этих языков гибнут не получив популярность.
    В случае DSL обстановка чуть более тепличная. Угадать потребности проще, давление рынка и вкусовщины на сам язык слабее.

    И это то, что никак не может быть решено никакими столь рекламируемыми здесь новшествами из N2.
    Они дадут только облегчение разборки с синтаксисом. Семантику они не решат.
    И именно поэтому описанное противостояние нелепо.
  • The God is real, unless declared integer.
    Re[15]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 10.04.12 08:11
    Оценка:
    Здравствуйте, VoidEx, Вы писали:

    VE>Грань, правда, опять не провести, поэтому видимо придётся DSL-изм переименовать в DSL-альность


    Грань размывается и в этом все и дело. Истинный ДСЛ и в понимании ЯОН заточенный тем или иным образом под задачу — это разные вещи. У них разные свойства.

    Более того языки вроде 1Эс заточены за счет внедрения в них ДСЛ-ей. Это переворачивает все с ног наголову и не дает полноценно рассуждать о ДСЛ-ях.

    Языки же вроде ВБА вообще не имеют никакой заточи и отличаются только рантаймом привязанным к МС Офис. Почему ВБА — это ДСЛ, а Ява встроенная в Опен Офис не ДСЛ?

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


    VE>И если уж признать, что DSL — это мера, а не bool, то спорить про VBA становится проще. Потому что обе стороны могут не спорить, DSL это или нет, а сойтись на том, что он менее DSL, чем SQL, но всё же не такого уж общего назначения, как C#.


    Если признать что ДСЛ — это мера, то нужно искать новые термины для выражения того же самого.

    Если же признать, что 1Эс и ВБА — это не ДСЛ, то все становится куда проще. За одно стаовится понятно, что 1Эс — это ЯОН в который гвоздями прибит ДСЛ. А как только это становится понятно, и программисту становится известно о наличии Немерла и Лиспа, то становится понятно и то, что такое решение не более чем ошибка дизайна. Ведь ДСЛ может быть прост библиотекой.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[6]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 10.04.12 08:23
    Оценка:
    Здравствуйте, alex_public, Вы писали:

    _>В начале хотел прокомментировать что в таком простом случае я бы взял Boost.Spirit, указал бы грамматику в несколько строк и тут же получил бы очень быстрый парсер.


    Да было бы смешно прочесть такой комментарий .

    _>Но потом подумал... А ведь Boost.Spirit — это же на самом деле тоже разновидность DSL!


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

    _>Кстати, глянул только что в гугле: не мне одному такая мысль сразу в голову пришла — уже есть готовое такое http://boost-spirit.com/repository/applications/json_spirit.zip


    Ежу понятно. Но сравнивать решение на Спирите с другим ДСЛем в нашем случае не особ интересно. Мы только узнаем то что и так очевидно — на немерле ДСЛ-и получаются лучше.

    Интересно сравнить именно реализацию средствами ЯОН и на ДСЛ-е.


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


    _>Интересно, а что можно было бы использовать при разработке такого парсера, что бы не считалось что используем DSL какой-то? Регулярные выражения? Не, тоже dsl... Остаётся только в лоб реализовать разбор посимвольный, в виде какого-нибудь конечного автомата. Я бы не стал.


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

    _>P.S. Boost.Spirit очень быстрый. )


    Рвали мы его как тузик грешку .

    В нем не эффективные алогоритмы. Как только горамматика выходит за LL(1) производительность парсера резко падает. Вплоть до экспоненты.

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

    ДСЛ позволяет не только сделать описание коротким и понятным, но и (при наличии должных средств трансформации/генерации) кода генерировать весьма эффективный код.

    Подход Немерла и N2 позволяет куда больше чем С++-ное метапрограммирование на шаблонах (использованное в бусте). Потому позволяет добиться лучшей скорости.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[8]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 10.04.12 08:26
    Оценка:
    Здравствуйте, VoidEx, Вы писали:

    VE>Этот подход работает прекрасно и сейчас. Только используют не DSL, а библиотеки.


    Ты и сам знаешь что это не так. В библиотеки нельзя запихать все. Библиотеки не позволяют всегда получать эффективнй код. Ну, и конечно же, многие библиотеки — это ДСЛ-и облаченные в не очень красивую форму и имеющий не очень эффективный рантайм.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[6]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 10.04.12 08:31
    Оценка:
    Здравствуйте, VoidEx, Вы писали:

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


    VD>>А сбацай нам парсер какого-нить не сложного языка вроде джейсона. Сравним его со генерированным PegGrammar-ом по объему кода и скорости работы. Ты же профи в этой области!


    VE>Мало что ли парсер-генераторов?


    Много. И они все используют ДСЛ-и. По сему и предлагаю сравнить одни из них (без ложной скромности, скажу — один из лучших) с лобовым решением.

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

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


    VE>Ну когда не хватает библиотеки, можно и кодогенератор. Зачем всё в один исходник пытаться запихнуть под эгидой Универсального ДСЛ Конструктора?


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

    При этом никто не отменяет наличия ЯОН-ов и их совместное использование с ДСЛ-ями. Так что с темой я не согласен. Но ЯОН должен гладко интегрироваться с ДСЛ-ями, а лучше — позволять их разрабатывать.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[10]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 10.04.12 08:33
    Оценка: :)
    Здравствуйте, VoidEx, Вы писали:

    VE>Не совсем так. Лифты в одном месте, роторные экскаваторы в другом, компьютеры в третьем. А вот нахрена это всё собирать в одном, действительно не очень понятно.


    Все на одной земле. Возможно даже на одной стройке. Просто в компютере все виртуально. А ДСЛ-ям место в библиотеках.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[16]: Языки общего назначения не имеют смысла!
    От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
    Дата: 10.04.12 08:41
    Оценка:
    Здравствуйте, Serginio1, Вы писали:


    S> Ну это аналогично трансформации 1С 8 ки. Правда бесит, что нет вывода типа результата запроса.

    S>Часто приходится делать прямые запросы для апдейтов больших по объему данных, через генераторы запросов. Поэтому, мой взгляд упал на Linq to EF. Там мне понравилось, что можно использовать запросы по схеме. Правда опять же нет вывода типов (может сейчас что изменилось).Там можно переименовать свойства и ассоциации в файле .edmx. Началь делать, да что то времени не хватает да и желания. Да и в модели 1С для регистров нет первичных полей, а для ассоциаций вторичных.
    S> Я выбрал путь через трансформацию EDMX, но может проще сделать EDMX через какой то АПИ, так по сути я могу создать и из 1С т.к. название полей и ассоциаций имеется?

    Кстати вроде как и сейчас можно в Linq to SQL использовать вывод типа
    http://msdn.microsoft.com/ru-ru/magazine/hh781018.aspx

    string entitySQL = " SELECT p, p.Filling " +
    "FROM PartyContext.Pinatas AS p "
    "WHERE p.Filling.Description='Candy'";
    var query=context.CreateQuery<DbDataRecord>(entitySQL);
    query.MergeOption = System.Data.Objects.MergeOption.NoTracking;
    var pinatasWithFilling=query.ToList();

    Вообще конечно смотрю я на Linq to EF с большой надеждой. И по большому счету может она заменить и 1С и парус с соответствующими конфигурациями, или что то на её основе
    и солнце б утром не вставало, когда бы не было меня
    Re[16]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 10.04.12 08:46
    Оценка:
    Здравствуйте, alex_public, Вы писали:

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


    Да ладно. Кодокенерация у них встречается частенько. Для тех же ресурсов дотнета они генерируют классы-обертки.

    Вопрос только в катастрофически низком уровне этой генерации.

    _>Хыхы, а тот наш редактор как раз генерит код сразу на нескольких языках. )))


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

    В любом случае, если имеет место генерация в разные языки, то имеет место и ДСЛ. И МС, и вы создаете некую модель в памяти и правила ее изменения. И уже эту модель сериализуете в код (или еще куда-то). Единственное что — эту модель вы не записываете на диск в исходном виде. Вот и все.

    _>Я в какой-то степени про это и говорю. Продумывание синтаксиса нового языка — это всё же определённая задача, которую не профи (в dsl строение) не так уж и просто решить.


    +1

    _>А вот такие инструменты по сути выполняют роль DSL, но при этом их создатели вообще не тратили время на продумывание синтаксиса и т.п.


    А вот это заблуждение. Время на синтаксис может и не тратит. Но потом он тратит время на выцарапывание своего ДСЛ-я из конструкций ЯОН. Так что синтаксис по сути есть. Но он более корявый.

    Я бы сделал следующую сортировку по степени убывания выразительности и удобства:
    1. ДСЛ с продуманным синтаксисом и семантикой.
    2. ДСЛ средствами ЯОН — модель с которой возятся универсальными средствами.
    3. Прямой долбеж кода на ЯОН без выделения ДСЛ-ей и моделей.

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

    Второй способ является по сути ДСЛ-ем для бедных. Он имеет кучу недостатков по сравнению с первым но предоставляет похожие на первый пункт уровни абстрагирования.

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

    Вот это мы и хотим исправить.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[18]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 10.04.12 08:56
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    G>1C плохой пример — там запросы 1-в-1 транслируются в SQL, только имена переписываются.


    В 1Эс есть джоины?

    Вот в Парусе их вроде нет. Это и есть основной смысл их ДСЛ-я (возможно не единственный).

    ДСЛ вообще не обязан преобразоываться во что-то уж совсем отличное от оригинала. Трансляция из некоторого объектного языка запросов в SQL — вполне приемлемый вариант.

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

    К тому же от ДСЛ могут быть и другие преимущества. Например, его можно транслировать в разные диалекты SQL-я.

    VD>>SQL тоже рассматриваем, так как он классический ДСЛ. Просто он общепринятый ДСЛ.

    G>Он был таким лет 20 назад. Если сейчас посмотреть на pl\sql, то DSL его назвать — язык не поворчивается.
    G>SQL в версии стандарта 92 года — да, DSL. Но если посчитать сколько в его разработку вложено, но аналогов не найдешь.

    Он был и есть таким всегда. PL/SQL — это процедурное расширение SQL. По сути это ЯОН. На нем даже десктопные приложения можно писать (в Оракл Формс). Точно так же процедурным расширением является и TSQL.

    Оба они являются примером встраивания ДСЛ-я в ЯОН. Вот только ЯОН довольно хреновые по сравнению с современными аналогами.

    По тому мы и говорим о том, что лучше брать топовые ЯОН и внедрять в них нужные ДСЛ-и.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[10]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 10.04.12 09:01
    Оценка:
    Здравствуйте, mrTwister, Вы писали:

    T>А по каким критериям ты относишь то или иное API к ДСЛ и к "ручному кодированию"? Если мы напишем класс, название которого соответствует некоторой доменной сущности, а методы соответствуют доменным операциям, то код, написанные с использованием этого класса является DSL? Скорее всего ты ответишь нет, но почему тогда Criteria API из hibernate является DSL?


    По наличию модели. Скажем если я вижу парсер рекурсивного спуска, то это лобовое решение. Если же я вижу комбинаторый парсер (который в итоге так же может выраждаться в рекурсивный спуск), то это уже ДСЛ, но эмулируемый средствами ЯОН.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[16]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 10.04.12 09:17
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    G>Только все это 1-в-1 мапится на SQL, только имена переписываются.


    Во-первых не совсем 1 в 1. Во-вторых — ну и что?

    AVK>>Ну вот что в тестах, к примеру, валяется:

    G>Так это SQL. А где его собственный DSL?

    Это не SQL, это собственный язык запросов, смотри внимательнее.

    G>>>В чем лучше?

    AVK>>Во всем.
    G>Ага, грузины лучше чем армяне
    G>Аргументация на уровне детсада.

    Какой вопрос, такой и ответ.

    AVK>>Доказать, что менее мощный язык означает, что для достижения того же результата надо больше писать.

    G>Тогда давай формализуем понятие мощности.

    Т.е. поспосрим о терминах? Все понятно, можешь не продолжать, я пас.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 27 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[16]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 10.04.12 09:17
    Оценка:
    Здравствуйте, Serginio1, Вы писали:

    S> Это аналог и 1С 8 го запроса


    В какой то мере, да. Потому что задача очень полхожа.

    S> (прада там еще и подмена названия полей)


    Здесь тоже.

    S>. Правда в 1С бесит, что нет вывода типа для запросов


    Здесь есть. Язык на 100% статически типизированный, просто на примере это не покажешь.

    S>Кстати, что там нового для Linq to EF хотят сделать?


    Насколько мне известно, очень немного.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 27 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[16]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 10.04.12 09:17
    Оценка: +1
    Здравствуйте, VoidEx, Вы писали:

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


    Абсолютно согласен. Но в отличии от библиотечного подхда ДСЛ-льный себя пока не исчерпал. Не всегда, конечно, но он позволяет добиться высокого повышения уровня абстрации.

    Ну, а сложность разработки ДСЛ-ей во многом определяется отсутствием достойных средств разрабокти и нитеграции в язык (для внутренних ДСЛ-ей). Так что решив эту проблему (упростив разработку и нитеграцию ДСЛ-ей) можно сделать ДСЛ-подход более досупным.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[19]: Языки общего назначения не имеют смысла!
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 10.04.12 09:20
    Оценка:
    Здравствуйте, VladD2, Вы писали:

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


    G>>1C плохой пример — там запросы 1-в-1 транслируются в SQL, только имена переписываются.


    VD>В 1Эс есть джоины?

    1) inner — легко "select * from a,b where a.key = b.key"
    2) left outer — табличные части

    VD>Вот в Парусе их вроде нет. Это и есть основной смысл их ДСЛ-я (возможно не единственный).

    Смысл DSL в том чего что-то нет? Тогда зачем он нужен?
    Это ведь можно и без создания DSL проверить.


    VD>>>SQL тоже рассматриваем, так как он классический ДСЛ. Просто он общепринятый ДСЛ.

    G>>Он был таким лет 20 назад. Если сейчас посмотреть на pl\sql, то DSL его назвать — язык не поворчивается.
    G>>SQL в версии стандарта 92 года — да, DSL. Но если посчитать сколько в его разработку вложено, но аналогов не найдешь.

    VD>Он был и есть таким всегда. PL/SQL — это процедурное расширение SQL. По сути это ЯОН. На нем даже десктопные приложения можно писать (в Оракл Формс). Точно так же процедурным расширением является и TSQL.

    Так чистого SQL нету нигде, везде есть эти самые расширения.
    Re[17]: Языки общего назначения не имеют смысла!
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 10.04.12 09:24
    Оценка: :)
    Здравствуйте, AndrewVK, Вы писали:

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


    G>>Только все это 1-в-1 мапится на SQL, только имена переписываются.


    AVK>Во-первых не совсем 1 в 1. Во-вторых — ну и что?


    А в том что DSL, который приводится в SQL (или другой язык общего назначения) бесполезен и не может быть примером архиполезности ДСЛ и ненужности ЯОН.

    AVK>>>Ну вот что в тестах, к примеру, валяется:

    G>>Так это SQL. А где его собственный DSL?
    AVK>Это не SQL, это собственный язык запросов, смотри внимательнее.
    А чем от SQL отличается? См выше.


    AVK>>>Доказать, что менее мощный язык означает, что для достижения того же результата надо больше писать.

    G>>Тогда давай формализуем понятие мощности.
    AVK>Т.е. поспосрим о терминах? Все понятно, можешь не продолжать, я пас.
    Так ты употребил термин "мощность", видимо без понимания что это такое
    Re[19]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 10.04.12 09:25
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Вот в Парусе их вроде нет.


    Есть (даже в приведенном мной примере). Только они не используются для доступа к явно определенным в метаданных ассоциациях.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 27 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[18]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 10.04.12 09:27
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    G>А в том что DSL, который приводится в SQL (или другой язык общего назначения) бесполезен


    Это даже не смешно. Т.е. в 1С сидят идиоты, делающие бесполезные вещи?

    AVK>>Это не SQL, это собственный язык запросов, смотри внимательнее.

    G>А чем от SQL отличается? См выше.

    Я выделил. Или ты считаешь, что верхний и нижний запросы абсолютно идентичны во всем, кроме имен полей?

    AVK>>Т.е. поспосрим о терминах? Все понятно, можешь не продолжать, я пас.

    G>Так ты употребил термин "мощность"

    Это ТЫ его употребил.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 27 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[16]: Языки общего назначения не имеют смысла!
    От: netch80 Украина http://netch80.dreamwidth.org/
    Дата: 10.04.12 09:28
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VE>>И если уж признать, что DSL — это мера, а не bool, то спорить про VBA становится проще. Потому что обе стороны могут не спорить, DSL это или нет, а сойтись на том, что он менее DSL, чем SQL, но всё же не такого уж общего назначения, как C#.

    VD>Если признать что ДСЛ — это мера, то нужно искать новые термины для выражения того же самого.

    Для чего именно?

    VD>Если же признать, что 1Эс и ВБА — это не ДСЛ, то все становится куда проще. За одно стаовится понятно, что 1Эс — это ЯОН в который гвоздями прибит ДСЛ. А как только это становится понятно, и программисту становится известно о наличии Немерла и Лиспа, то становится понятно и то, что такое решение не более чем ошибка дизайна. Ведь ДСЛ может быть прост библиотекой.


    А ты опиши чёткие критерии. Пока что всё, что сказано — только вкусовщина без описания метода измерения.
    The God is real, unless declared integer.
    Re[19]: Языки общего назначения не имеют смысла!
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 10.04.12 09:34
    Оценка: :)))
    Здравствуйте, AndrewVK, Вы писали:

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


    G>>А в том что DSL, который приводится в SQL (или другой язык общего назначения) бесполезен

    AVK>Это даже не смешно. Т.е. в 1С сидят идиоты, делающие бесполезные вещи?
    Нет, стоит просто называть веши своими именами. Назовем это переписыванием имен в запросе.

    Тезис о важности DSL как-то сразу улетучивается.
    Re[19]: Языки общего назначения не имеют смысла!
    От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
    Дата: 10.04.12 09:41
    Оценка:
    Здравствуйте, VladD2, Вы писали:

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


    G>>1C плохой пример — там запросы 1-в-1 транслируются в SQL, только имена переписываются.


    VD>В 1Эс есть джоины?


    Давным давно в 8ке. Он максимально приближен к нормальному SQL. Правда там куча ограничений (нет переменных запроса (@gthtvtyyfz=Select //), нем множества функций для работы со строками итд. Нет Merge? insert, update, exsists, поле=Select итд). Но в большинстве случаев этого хватает.
    Приходится писать прямые запросы в основном для массовых изменений данных.
    и солнце б утром не вставало, когда бы не было меня
    Re[15]: Языки общего назначения не имеют смысла!
    От: netch80 Украина http://netch80.dreamwidth.org/
    Дата: 10.04.12 10:08
    Оценка:
    Здравствуйте, VoidEx, Вы писали:

    VE>Я думаю, стоит копать в направлении "полноценные ДСЛ-ли позволяют описывать прикладную задачу на более высоком абстракнтом уровне", но не по сравнению с языками общего назначения, а по сравнению с прикладной задачей в другой области.

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

    Идея понятна, но в ней есть заметные дыры.
    Например, какой (чего) факториал? В 32 бита влезет факториал аргумента до 12 включительно. Для аргументов от 21 нужна длинная арифметика.
    В таком случае "вдруг" окажется, что Python, Erlang и Рапира — языки общего назначения, а C, Java, etc. — DSL'и. Потому что для подсчёта факториала от 21 нужно или реализовывать самому умножение с переносом, или подключать libgmp с аналогами.

    VE>Это не чёткая грань, а некоторая мера. В целом, согласен.

    VE>И если уж признать, что DSL — это мера, а не bool, то спорить про VBA становится проще. Потому что обе стороны могут не спорить, DSL это или нет, а сойтись на том, что он менее DSL, чем SQL, но всё же не такого уж общего назначения, как C#.

    +2.
    The God is real, unless declared integer.
    Re[13]: Языки общего назначения не имеют смысла!
    От: Vain Россия google.ru
    Дата: 10.04.12 10:21
    Оценка: :)
    Здравствуйте, VladD2, Вы писали:

    V>>Факты про то что ни один старап не будет рисковать своим проектом...

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

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

    VD>Кошелек то не их. В этом вся суть .
    С чего бы это?

    V>> Факты про то что существует куча уже написанного и, главное, отлаженного временем кода который никто не захочет менять на написание какого-то там дсл?

    VD>А зачем менять отлаженный код без надобности? Можно его обернуть в ДСЛ,
    Зачем оборачивать в дсл то что уже работает и есть не просит?

    V>>Факты про то что программистов с языком общего назначения на порядок больше чем дсл писателей, что сказывается на их цене? Эти факты как раз все против дсл.

    VD>Писать ДСЛ-и не должны все кому не лень. А вот использовать и изучать куда легче чем код написанный вручную.
    Опять же спорно.

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

    Да не будет он решением многих проблем, также как и sql не является решением многих проблем. Максимум что будет, это займёт свою узкоспециализированную нишу, но никак не вытеснит языки общего назначения, по объективным причинам.
    [In theory there is no difference between theory and practice. In
    practice there is.]
    [Даю очевидные ответы на риторические вопросы]
    Re[16]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 10.04.12 10:38
    Оценка: :)
    Здравствуйте, VoidEx, Вы писали:

    VE>Ну а ты давай сделай SQL с нуля, сам язык,

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

    VE>теорию,

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

    VE>и поддерживай это всё.

    При наличии хороших инструментов это весьма простая задача.

    VE>Он толсто намекает на то, что DSL написать — не поле перейти, и очень нередко написать "свой SQL" может оказаться сложнее, чем таки поработать через АПИ.

    Вы очень сильно завышает сложность создания ДСЛ.
    Это не сложнее чем создать библиотеку.
    А при наличии правильных инструментов даже проще, ибо при создании ДСЛ нет очень сложной и противной задачи: Натянуть модель выполнения задачи на язык.
    Это очень не просто. И часто просто не реализуемо без серьезных издержек. Которые могут выражаться разными способами. Либо код превращается в говно. Либо все начинает жутко тормозить. А обычно и то и другое одновременно.
    Кстати для создания грамотной библиотеки тоже нужно знать теории.

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

    Я просто показал пример ДСЛя который все знают. Только и всего.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[5]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 10.04.12 10:46
    Оценка: +1 :)
    Здравствуйте, __lambda__, Вы писали:

    ___>Зачем учить внутренности библиотеки, в том то и весь смысл библиотек, что нужно лишь знать внешний интерфейс. Черный ящик, декомпозиция, модульность... Это же азбука. Если вам приходится читать внутренний код библиотек, разбираться в том, как она устроена, ты вы явно че-то не то делаете.

    Только язык инкапсулирует логику несравнимо лучше, чем любая библиотека.
    Давно тебе приходилось читать исходники компилятора, чтобы использовать язык?
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re: Языки общего назначения не имеют смысла!
    От: Mamut Швеция http://dmitriid.com
    Дата: 10.04.12 10:54
    Оценка: +4
    WH>Про то, что код на ДСЛ проще понять, поддерживать, развивать и там намного меньше багов я думаю можно даже не заикаться.

    При условии, что нет багов в компиляторе. И при условии, что DSL правильно спроектирован. Потому что тут же рядом в разговоре про SQL что-то такое говорится
    Автор: WolfHound
    Дата: 08.04.12
    . И компилятор поддерживать тоже надо. Например, если DSL изменяется/расширяется.

    В общем, если бы все было так хорошо, DSL'и были бы везде.

    Хотя, о чем это я. Вон, Ruby on Rails — это, посути, один большой DSL, который позволяет двумя строчками описать то, что обычно описывается сотней строчек. В итоге шаг вправо-влево (за рамки DSL) — расстрел, во что разворачиваются вызовы этих двух строчек, неизвестно никому, и точки просаживания по производительности тоже неочевидны. Хотя да, это, видимо, плохо спроектированный DSL. С истинно правильным труъ DSL'ем такого не бывает, потому что такого не может быть никогда.

    Хотя не спорю — DSL'и на самом деле рулят. Только вот они тоже далеко не панацея, и применять их лучше дозированно.


    dmitriid.comGitHubLinkedIn
    Re[7]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 10.04.12 10:56
    Оценка: :)
    Здравствуйте, VladD2, Вы писали:

    VD>соображения

    Интересное слово. Надо будет запомнить.

    VD>Затем, что почти для любой задачи можно придумать свой ДСЛ.

    Не почти, а для любой.

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

    ЯОН можно использовать, только если его модель совпадает с моделью задачи. В этом случае он просто становится, ПОЯ для этой задачи.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[9]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 10.04.12 10:57
    Оценка:
    Здравствуйте, VladD2, Вы писали:

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

    И нельзя забывать про то что ДСЛ не позволяет тем которые попроще лезть куда не следует.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[11]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 10.04.12 11:00
    Оценка:
    Здравствуйте, BrainSlug, Вы писали:

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

    Просто в SQL и потомках не предусмотрены средства декомпозиции запросов.
    Да и статическая типизация им явно не помешает.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[15]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 10.04.12 11:06
    Оценка:
    Здравствуйте, VoidEx, Вы писали:

    VE>Я думаю, стоит копать в направлении "полноценные ДСЛ-ли позволяют описывать прикладную задачу на более высоком абстракнтом уровне", но не по сравнению с языками общего назначения, а по сравнению с прикладной задачей в другой области.

    Все проще. Мера ДСЛьности всегда относительна задачи. Поэтому про некий язык в вакууме нельзя сказать ДСЛ он или нет.
    Те чем модель языка ближе к модели задачи, тем этот язык более ДСЛ для этой задачи.
    Таким образом, если у нас задача складывать числа, то любой язык, где можно написать 123 + 324 будет ДСЛ для этой задачи.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[16]: Языки общего назначения не имеют смысла!
    От: netch80 Украина http://netch80.dreamwidth.org/
    Дата: 10.04.12 11:09
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

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


    WH>Все проще. Мера ДСЛьности всегда относительна задачи. Поэтому про некий язык в вакууме нельзя сказать ДСЛ он или нет.


    А твой коллега VladD2 пытается установить какие-то абсолютные критерии.

    WH>Те чем модель языка ближе к модели задачи, тем этот язык более ДСЛ для этой задачи.

    WH>Таким образом, если у нас задача складывать числа, то любой язык, где можно написать 123 + 324 будет ДСЛ для этой задачи.

    См. мой соседний комментарий про факториал и длинную арифметику.
    123+324 недостаточно.
    The God is real, unless declared integer.
    Re[17]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 10.04.12 11:19
    Оценка:
    Здравствуйте, netch80, Вы писали:

    N>А твой коллега VladD2 пытается установить какие-то абсолютные критерии.

    Он часто пытается делать странные вещи.

    N>См. мой соседний комментарий про факториал и длинную арифметику.

    N>123+324 недостаточно.
    Ох, буквоед. Причем знал же, что до пуговиц кто-то докопается.
    Таким образом, если у нас задача складывать числа, то любой язык, где можно написать 123 + 324 при условии что типы чисел совпадают с типами чисел нужными для решения задачи, будет ДСЛ для этой задачи.
    Так лучше?
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[8]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 10.04.12 11:22
    Оценка: 1 (1) +2
    Здравствуйте, VoidEx, Вы писали:

    VE>Этот подход работает прекрасно и сейчас. Только используют не DSL, а библиотеки.


    С точки зрения теории кристалла, счастье в любом случае наступает при использовании фреймворков. Можно строить фреймворки на основе библиотек; можно — на основе DSL. Можно — на основе того и другого.
    В Delphi, к примеру, была VCL (библиотека) + язык описания форм (DSL) + возможность расширять библиотеку. Благодаря наличию малозаметного DSL, хейльсберг сумел с первой попытки получить работоспособную IDE с визуальным дизайнером. Модным пацанам из Symantec потребовалось несколько лет и пара-тройка мажорных версий, чтобы получить мало-мальски стабильную реализацию того же самого на Java.
    Ровно оттого, что в качестве "языка описания дизайна формы" была выбрана cама Java, а не DSL. Сложность two-way синхронизации изменений в дизайнере и в коде существенным образом зависит от устройства языка.

    Фреймворк ASP.NET построен на основе библиотек и сразу нескольких DSL языков.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[14]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 10.04.12 11:25
    Оценка:
    Здравствуйте, alex_public, Вы писали:


    _>Вот смотрю я на этот пример и думаю... А означает ли факт кодогенерации обязательное наличие DSL? Например, я уже писал тут, что мы используем для создания GUI визуальный редактор, который генерирует весь код создания интерфейса неспредственно на системном языке. Т.е. кодогенерация больших объёмов у нас тут есть, а никаких DSL вроде как и не видно.

    А где у вас хранится описание GUI после того, как редактор закрыт? Он же не одноразовый, правда?
    Ну, то есть какой файл я открываю этим визуальным редактором, чтобы подправить расположение кнопочки на форме?
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[12]: Языки общего назначения не имеют смысла!
    От: koodeer  
    Дата: 10.04.12 11:29
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>Просто в SQL и потомках не предусмотрены средства декомпозиции запросов.

    WH>Да и статическая типизация им явно не помешает.

    Можно ли Linq2Sql считать приближенным к идеалу в этом смысле? Декомпозиция присутствует, статическая типизация присутствует.
    Re[16]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 10.04.12 11:32
    Оценка:
    Здравствуйте, alex_public, Вы писали:


    _>Более того, у него даже есть свой отдельный формат для хранения "нарисованного" gui. Я в него как-то заглянул ради интереса — там некий дичайший xml. Так что формально можно даже текстовый dsl найти тут. Но речь то не об этом... Речь о том, что если поменять этот формат на любой другой (бинарный например), то абсолютно ничего в процессе разработки не изменится — люди никогда не видят его. Так можем ли мы называть это DSL, если люди с этим не работают никогда и от его реализации не зависит вообще ничего?

    Конечно можете. Это и есть DSL. И когда вы поменяете этот формат, у вас встанут совершенно такие же проблемы, как всегда при смене языка — как мигрировать мегабайты существующего кода.
    То, что он у вас внутри какой-то некрасивый, как раз неважно. Важно, что он есть. Вы можете приделать к нему произвольное представление. Визуальное у вас уже есть. Можете приделать текстовое, и получите много замечательных бенефитов.
    В Delphi много-много мажорных версий подряд текстовое представление DFM существовало только "на экране", а в файл скидывался бинарник. У нас даже был свой нарошный тул для конверсии txt2dfm и dfm2txt, потому что бинарники крайне неудобно мерджить в системах контроля версий. А потом борланд добавило это в коробку — по той же причине.

    Пусть вас не обманывает тот факт, что вы редактируете UI мышкой, а не клавиатурой. Современный редактор текстового ЯП тоже крайне далёк от notepad — там тебе и раскраска синтаксиса, и автодополнение, и всё остальное. Если посмотреть на экран студии непредвзятым взглядом, то окажется, что редактор кода уже тоже достаточно "визуальный". Т.е. помимо чисто текста он рисует в канвас дофига всего. То, что на диске ничего этого реально нет (ну, если не считать наркомании типа Оберона), не делает язык не-языком.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[16]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 10.04.12 11:34
    Оценка:
    Здравствуйте, Vain, Вы писали:
    WH>>Ну, давай изучи АПИ для прямых обращений к физической структуре БД.
    V>А в чём проблема? MFC, ADO, DAO?
    Боюсь, ни один из них тебе не даст возможности напрямую читать/писать странички БД и расставлять локи разных уровней. А именно это и есть прямое обращение "к физической структуре БД".
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[13]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 10.04.12 11:35
    Оценка:
    Здравствуйте, koodeer, Вы писали:

    K>Можно ли Linq2Sql считать приближенным к идеалу в этом смысле? Декомпозиция присутствует, статическая типизация присутствует.

    Приближением можно.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[16]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 10.04.12 11:40
    Оценка:
    Здравствуйте, VoidEx, Вы писали:

    VE>Ну а ты давай сделай SQL с нуля, сам язык, теорию, и поддерживай это всё.

    Хороший поинт. Вы его не в ту сторону рассматриваете. Надо его рассматривать как повод удешевить разработку языков, теорий, и их поддержку.
    Иначе получается, что двадцать лет назад не стоило рассматривать стройматериалы вроде, скажем, газобетона. Ну, потому что пессимисты типа вас записывали бы в стоимость строительства здания стоимость разработки технологии автоклавного твердения бетона и постройки завода, и уверенно бы доказывали полную непригодность этой идеи для малоэтажного строительства. На практике, как мы видим, побеждает всё же газобетон.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[4]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 10.04.12 11:54
    Оценка:
    Здравствуйте, alex_public, Вы писали:

    _>А вот есть один интересный примерчик... GUI — в очень многих случаях решается практически одинаковая задача (главное окно, менюшки, тулбары, обработка сообщений и т.п.). T.e. казалось бы тут самое оно создать некий DSL. И где он?

    Тысячи их.
    _>Да, всякие языки размётки контролов не приводить — нам нужна и обработка сообщений и ещё много чего, а не только их расположение.
    Чуть менее, чем во всех GUI-фреймворках привязка обработчиков выполнена внутри "языка размётки". Сами обработчики традиционно отдаются в General-Purpose-язык, но это исключительно оттого, что не хочется делать "ещё один" turing-complete язык внутри разметочного.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[2]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 10.04.12 11:56
    Оценка:
    Здравствуйте, Abyx, Вы писали:

    A>давайте разберем такой проект — надо написать IM клиент, например для jabber'а

    A>допустим у нас нет готовой библиотеки и мы пишем его с нуля
    A>у него есть UI, несколько слоев сетевого кода, куча мелких модулей типа конфига и т.п.
    A>где там можно применить DSL?
    Например, шибко бы пригодился DSL для описания протокола взаимодействия, чтобы чётко были видны все переходы статусов соединения.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[2]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 10.04.12 12:02
    Оценка:
    Здравствуйте, Буравчик, Вы писали:

    Б>Одна из них — взаимодействие между языками. Как передавать данные из одного языка в другой? Взять ту же связку "язык общего назначения (ЯОН) — SQL". Сколько напридумывали вариантов передачи данных из ЯОН в SQL — и в компилятор встраивали, и формировали текст SQL в программе и передача параметров в хранимые процедуры.

    Это оттого, что изначально SQL проектировался как терминальный язык для клиента-человека. Это оказалось стратегической ошибкой.
    Б> Аналогично и с превращением данных из SQL в данные ЯОН — всякие ридеры, датасеты и т.п. В итоге удобным вариантом оказался что-то типа LINQ, т.е. с одной стороны DSL, а работа все в том же ЯОН. Т.е. по сути получилась та же библиотека.
    По сути получился DSL.

    Б>Про взаимодействие двух DSL я вообще молчу. Пример, есть регэкспы и SQL. Хочу регэкспы использовать в SQL. Как их скрестить используя уже созданные наработки?

    Традиционной проблемой SQL является его закрытость. В него добавить Regex — нереальная задача. Это скриптовый язык — в том смысле, что у него есть first-class objects, предоставленные "богом", и есть скрипты, написанные "людьми". Ну и von licet jovi non licet bovi.
    Там очень слабые возможности как по декомпозиции и повторному использованию того, что сделано в терминах SQL, так и по синтезу и повторному использованию того, что сделано "снаружи".

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

    Б>Нужна какая-то база (стандарты) для обмена информацией между языками. И речь идет не только о самих данных, но и, возможно, об их семантике. К сожалению, работ по этой теме (пока) что-то совсем не видно.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[17]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 10.04.12 12:06
    Оценка: :)
    Здравствуйте, Sinclair, Вы писали:

    S>На практике, как мы видим, побеждает всё же газобетон.

    Оффтоп: Только хорошие дома получаются из обычного полнотелого кирпича утепленного снаружи эковатой. У меня отец малоэтажным строительством занимается. Причем это все на уровне школьной программы посчитать можно.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[18]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 10.04.12 12:13
    Оценка: +4 :)
    Здравствуйте, WolfHound, Вы писали:

    S>>На практике, как мы видим, побеждает всё же газобетон.

    WH>Оффтоп: Только хорошие дома получаются из обычного полнотелого кирпича утепленного снаружи эковатой. У меня отец малоэтажным строительством занимается. Причем это все на уровне школьной программы посчитать можно.
    Я не специалист в малоэтажном строительстве, но строить из полнотелого кирпича межкомнатные перегородки — топить печь ассигнациями. Насчёт эковаты — same point still stands, т.е. давайте засчитаем в стоимость коттеджа стоимость завода по выпуску эковаты и мы легко обоснуем, что дешевле строить из мрамора.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[18]: Языки общего назначения не имеют смысла!
    От: netch80 Украина http://netch80.dreamwidth.org/
    Дата: 10.04.12 12:58
    Оценка: +1
    Здравствуйте, WolfHound, Вы писали:

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


    N>>А твой коллега VladD2 пытается установить какие-то абсолютные критерии.

    WH>Он часто пытается делать странные вещи.

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

    N>>См. мой соседний комментарий про факториал и длинную арифметику.

    N>>123+324 недостаточно.
    WH>Ох, буквоед. Причем знал же, что до пуговиц кто-то докопается.

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

    WH>Таким образом, если у нас задача складывать числа, то любой язык, где можно написать 123 + 324 при условии что типы чисел совпадают с типами чисел нужными для решения задачи, будет ДСЛ для этой задачи.

    WH>Так лучше?

    Для чёткости формулировки — да.
    Теперь можно переходить к вопросу её адекватности общей ситуации.
    Я не считаю адекватной классификацию, в которой такими DSLями оказываются 90% языков.
    Нужно придумать так, чтобы ограничение было сильнее.
    The God is real, unless declared integer.
    Re[2]: Языки общего назначения не имеют смысла?
    От: PSV100  
    Дата: 10.04.12 13:29
    Оценка: :)
    Здравствуйте, netch80, Вы писали:
    N> [...]

    Большое спасибо тебе, добрый человек netch80, ты прямо отдушина в этой традиционной РСДН-бойне. Это самый адекватный пост в этой теме.

    Мне много лет приходится заниматься DSL-строением. Я никогда не задумывался над философией по этому поводу, и считал, что это именно DSL, но почитав тут много всякого, у меня сложилось впечатление, что на самом деле занимался какими-то "кривыми и ограниченными" языками (здесь
    Автор: PSV100
    Дата: 26.03.12
    можно увидеть пример, недавно консультировался у немерлистов по этому поводу).

    И лично мне очень не хватает хорошего языка общего назначения, в том числе и для создания DSL.
    Re[19]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 10.04.12 13:50
    Оценка:
    Здравствуйте, netch80, Вы писали:

    N>Осталось понять, кто из вас более странный.

    Ты.

    N>Для чёткости формулировки — да.

    N>Теперь можно переходить к вопросу её адекватности общей ситуации.
    N>Я не считаю адекватной классификацию, в которой такими DSLями оказываются 90% языков.
    N>Нужно придумать так, чтобы ограничение было сильнее.
    А нельзя придумать классификацию, не привязанную к предметной области.
    Ибо Domain-specific language.
    А раз мы привязываемся к некоторому домену то для любого языка можно придумать домен (а обычно множество доменов) для которых данный язык является языком предельно высокого уровня. Те делай, что хочешь, но язык более высокого уровня не придумать. Ибо язык и так напрямую оперирует терминами предметной области.

    Но если уж так хочется разделить, то нужно смотреть на исходную постановку задачи при разработке языка.
    Для SQL это запросы к реляционной базе данных.
    Для https://github.com/rampelstinskin/ParserGenerator это разбор текстовых языков программирования.
    ...
    А для С, С++, C#,... написание произвольных программ.
    При этом нужно понимать что, например, в том же C# захардкожен linq. Задача которого типизированные запросы к данным. Те это ПОЯ внутри ЯОН.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[3]: Языки общего назначения не имеют смысла!
    От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
    Дата: 10.04.12 14:08
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>Там очень слабые возможности как по декомпозиции и повторному использованию того, что сделано в терминах SQL, так и по синтезу и повторному использованию того, что сделано "снаружи".


    Поэтому нужно развиват Linq to EF в том числе и ObjectQuery и использование ХП или динамических функций CLR. Пусть сам SQL будет низкоуровневой конструкцией.
    и солнце б утром не вставало, когда бы не было меня
    Re[19]: Языки общего назначения не имеют смысла!
    От: artelk  
    Дата: 10.04.12 14:24
    Оценка: 14 (1) +1
    Здравствуйте, netch80, Вы писали:

    N>Я не считаю адекватной классификацию, в которой такими DSLями оказываются 90% языков.

    Вообще-то больше

    Вообще, DSL — это подход к решению задач, в рамках которого под задачу (или класс задач) сначала реализуется язык, на котором решение задачи становится более выразительным, понятным и простым.
    DSL — это альтернатива сложившемуся подходу — реализации некой объектной (или еще какой) модели на каком-то языке общего назначения и последующее решение задачи "в терминах" взаимодействия объектов этой модели.
    Такая модель, по сути, также выполняет функцию языка. Особенно это относится ко всякого рода фреймворкам. Или вот: boost.spirit — яркий пример, когда граница между DSL и фреймворком почти совсем размыта.
    Но "честный" DSL начинается с грамматики и не ограничен выразительными возможностями того или иного языка общего назначения.

    N>Нужно придумать так, чтобы ограничение было сильнее.

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

    Нужно придумать так, чтобы ограничение было сильнее.
    Re[20]: Языки общего назначения не имеют смысла!
    От: netch80 Украина http://netch80.dreamwidth.org/
    Дата: 10.04.12 14:38
    Оценка: +2
    Здравствуйте, WolfHound, Вы писали:

    N>>Осталось понять, кто из вас более странный.

    WH>Ты.

    Это нарушение поискового домена.

    N>>Я не считаю адекватной классификацию, в которой такими DSLями оказываются 90% языков.

    N>>Нужно придумать так, чтобы ограничение было сильнее.
    WH>А нельзя придумать классификацию, не привязанную к предметной области.
    WH>Ибо Domain-specific language.

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

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


    Важно ещё, чтобы этот язык не оперировал чем-то ещё, кроме терминами *данной* предметной области.
    Потому что по тому, что сейчас получается, у тебя Python является DSL для арифметики.
    С этим вряд ли кто-то ещё согласится.

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


    Исходная — неинтересна. Мало ли что там изначально придумывали.
    Вон Erlang придумали для телефонного свича. Я не пишу на нём телефонные свичи.

    WH>А для С, С++, C#,... написание произвольных программ.


    Очень абстрактно и потому некорректно.
    The God is real, unless declared integer.
    Re[18]: Языки общего назначения не имеют смысла!
    От: PSV100  
    Дата: 10.04.12 14:43
    Оценка: :)
    Здравствуйте, alex_public, Вы писали:

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


    AVK>>Формально тоже все в порядке. Выражения типа "язык танца" или "язык тела" не встречал? Языки вовсе не обязаны быть исключительно текстовыми.


    _>В программирование язык — это всё же вполне формальная сущность с синтаксисом, семантикой и т.п. А их довольно трудно разглядеть в GUI редакторе. )


    _>А в общемупотребительной терминологии конечно проблем нет тогда. Там вообще можно увидеть фразу "найти общий язык с компьютером". )))


    alex_public, посмотри на ДРАКОН — Дружелюбный Русский Алгоритмический язык, Который Обеспечивает Наглядность. Это один из редчайших случаев, когда графический язык реально используется в промышленности (!), причём именно для программирования, в основном, инженерами (в инете, где-то вокруг Оберона, была инфа от тех, кто с ним реально работал в тех "космических фантазиях").

    Он используется в моей личной практике, но всё "программирование" происходит на бумаге с карандашом — язык очень простой, основная фишка: направленный граф без пересекающихся линий — это реально намного лучше того, что рисовалось до него не пойми как для своих всяких схем. Люди въезжают быстро, даже те, кто далёк от программирования и всяких блок-схем, быстро можно начать обсуждать предметную область на одном языке.
    Рекомендую.
    Re[21]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 10.04.12 14:47
    Оценка:
    Здравствуйте, netch80, Вы писали:

    N>Важно ещё, чтобы этот язык не оперировал чем-то ещё, кроме терминами *данной* предметной области.

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

    N>Потому что по тому, что сейчас получается, у тебя Python является DSL для арифметики.

    У меня получается, что чуть менее чем все языки являются ДСЛями для арифметики.

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

    N>С этим вряд ли кто-то ещё согласится.

    Не говори за всех. И перестань спорить с определениями.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[20]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 10.04.12 14:50
    Оценка:
    Здравствуйте, artelk, Вы писали:

    A>Но "честный" DSL начинается с грамматики и не ограничен выразительными возможностями того или иного языка общего назначения.

    Честный ДСЛ начинается с семантики и не ограничен семантикой, какого либо другого языка.

    A>"DSL-ность", все же, это не свойство языка, а подход к решению задач.

    ДСЛность это свойства языка по отношению к конкретной задаче.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[22]: Языки общего назначения не имеют смысла!
    От: netch80 Украина http://netch80.dreamwidth.org/
    Дата: 10.04.12 14:59
    Оценка: +2
    Здравствуйте, WolfHound, Вы писали:

    N>>Важно ещё, чтобы этот язык не оперировал чем-то ещё, кроме терминами *данной* предметной области.

    WH>Это зависит от того как задать предметную область.

    Ну ты же сам предложил сложить два числа.

    N>>Потому что по тому, что сейчас получается, у тебя Python является DSL для арифметики.

    WH>У меня получается, что чуть менее чем все языки являются ДСЛями для арифметики.

    Вот это и плохо.

    WH>Проблема в том, что очень мало задач, которые к этой самой арифметике сводятся.


    И ещё и поэтому твоё рассмотрение некорректно.

    N>>С этим вряд ли кто-то ещё согласится.

    WH>Не говори за всех. И перестань спорить с определениями.

    Мне как-то пофиг приказы с твоей стороны перестать спорить с "определениями", под которыми пока что никто кроме тебя не подписался.
    The God is real, unless declared integer.
    Re[21]: Языки общего назначения не имеют смысла!
    От: artelk  
    Дата: 10.04.12 15:30
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

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


    A>>Но "честный" DSL начинается с грамматики и не ограничен выразительными возможностями того или иного языка общего назначения.

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

    A>>"DSL-ность", все же, это не свойство языка, а подход к решению задач.

    WH>ДСЛность это свойства языка по отношению к конкретной задаче.
    Я правильно понимаю, что по твоему язык является ДСЛем, если оперирует строго теми же понятиями, что используются в предметной области в контексте конкретной задачи?
    Re[17]: Языки общего назначения не имеют смысла!
    От: alex_public  
    Дата: 10.04.12 16:51
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Да ладно. Кодокенерация у них встречается частенько. Для тех же ресурсов дотнета они генерируют классы-обертки.


    Угу, это ещё в MFC было — ClassWizard и т.п. И помнится там был ещё генератор обёрток для COM. Но это именно пустые классы, а вот код с какой-то логикой работы... Такого не помню у них ни разу.

    VD>Вопрос только в катастрофически низком уровне этой генерации.


    Вот мне не понятно почему оно у них тут низкое, для такой простой задачи.

    VD>У них тоже. Только вот подключить свой довольно не просто. Кроме того уверен, что наворотов в вашем редакторе существенно меньше. А стало быть и проблем.


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

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


    Да, само собой это какая-то разновидность dsl. Но при этом без создания синтаксиса языка. Может это не плохое решение, пока нет удобных автоматических инструментов dsl-строения? )
    Re[17]: Языки общего назначения не имеют смысла!
    От: alex_public  
    Дата: 10.04.12 17:04
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>Конечно можете. Это и есть DSL. И когда вы поменяете этот формат, у вас встанут совершенно такие же проблемы, как всегда при смене языка — как мигрировать мегабайты существующего кода.


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

    S>То, что он у вас внутри какой-то некрасивый, как раз неважно. Важно, что он есть. Вы можете приделать к нему произвольное представление. Визуальное у вас уже есть. Можете приделать текстовое, и получите много замечательных бенефитов.


    Оно кстати и есть текстовое сейчас. Только не реальное для редактированием человеком. Ну т.е. в теории конечно возможно, но на практике бред. )))

    S>Пусть вас не обманывает тот факт, что вы редактируете UI мышкой, а не клавиатурой. Современный редактор текстового ЯП тоже крайне далёк от notepad — там тебе и раскраска синтаксиса, и автодополнение, и всё остальное. Если посмотреть на экран студии непредвзятым взглядом, то окажется, что редактор кода уже тоже достаточно "визуальный". Т.е. помимо чисто текста он рисует в канвас дофига всего. То, что на диске ничего этого реально нет (ну, если не считать наркомании типа Оберона), не делает язык не-языком.


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

    DSL'ем я тут называю не тот формат для xml серелизации, а для именно "графический dsl".
    Re[5]: Языки общего назначения не имеют смысла!
    От: alex_public  
    Дата: 10.04.12 17:17
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>Тысячи их.

    И везде одна и та же ерунда. )

    S>Чуть менее, чем во всех GUI-фреймворках привязка обработчиков выполнена внутри "языка размётки". Сами обработчики традиционно отдаются в General-Purpose-язык, но это исключительно оттого, что не хочется делать "ещё один" turing-complete язык внутри разметочного.


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

    А вот если бы у нас в gui dsl можно было бы задавать хотя бы минимальные действия... Весь значительная часть обработчиков замкнута самая же на себя. Т.е. зачем обращаться в мощный основной язык ради того что бы в обработчики команды меню вызвать команду "показать диалог такой-то". И таких вызовов очень много! Значительная часть обработчиков состоит из вызова одной строки — вызова функции другого gui контрола. Это всё можно было замкнуть внутри себя, сделав вызовы наружу (в системный язык) только уже для реальной функциональности. Вот на такой dsl я бы точно перешёл. Но таких gui фреймворков я не знаю вообще.

    А с текущей ситуацией "просто размётки с указанием имён обработчиков" и при наличие визуального редактора у меня на такие dsl действует только бритва Оккама.
    Re[19]: Языки общего назначения не имеют смысла!
    От: alex_public  
    Дата: 10.04.12 17:21
    Оценка:
    Здравствуйте, PSV100, Вы писали:

    PSV>alex_public, посмотри на ДРАКОН — Дружелюбный Русский Алгоритмический язык, Который Обеспечивает Наглядность. Это один из редчайших случаев, когда графический язык реально используется в промышленности (!), причём именно для программирования, в основном, инженерами (в инете, где-то вокруг Оберона, была инфа от тех, кто с ним реально работал в тех "космических фантазиях").


    Да, отличный пример демонстрации понятия "графический dsl".

    PSV>Он используется в моей личной практике, но всё "программирование" происходит на бумаге с карандашом — язык очень простой, основная фишка: направленный граф без пересекающихся линий — это реально намного лучше того, что рисовалось до него не пойми как для своих всяких схем. Люди въезжают быстро, даже те, кто далёк от программирования и всяких блок-схем, быстро можно начать обсуждать предметную область на одном языке.


    Используется где-то помимо его основного назначения? Интересно.

    PSV>Рекомендую.


    Хы, ну только для самообразования. Не вижу где его особо можно применить на практике. В смысле у нас, а не вообще в мире. )))
    Re: Use LISP, Luke!
    От: b-3 Россия  
    Дата: 10.04.12 17:23
    Оценка: -1 :)
    Здравствуйте, WolfHound, Вы писали:

    WH>Вот буквально только что презенташка попалась.

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

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


    Один известный язык с названием из четырёх букв пытается это подтвердить.
    Уже 54 года пытается.

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

    Большая программа на LISP почти со 100% вероятностью включает собственный язык программирования.

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

    Спрашивается: а где же успехи LISP-программирования?
    Где сотни проектов, решающих научные и бизнес-задачи, рвущие конкурентов в клочья?

    А получилось так...

      Скрытый текст

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

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

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

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

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

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

    И во всем городе Вавилоне люди перестали понимать друг друга.

    Маляр кричит;

    — Краска кончилась!

    А у него получается:

    — Номорпэнт!

    — Ничего не понимаю! — кричит ему снизу другой. А получается

    — Жэнэком пренепа!

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

    — Виндадоры!

    — Маракири!

    — Бобэоби!

    — Дзын!

    Все побросали работу, ходят как в воду опущенные и ищут: кто бы мог их понять?

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

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

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

    И до сих пор на всех языках света люди рассказывают эту сказку о недостроенной Вавилонской башне.

    Забанен с формулировкой "клинический дисидент".
    Re[2]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 10.04.12 18:33
    Оценка: :)
    Здравствуйте, gandjustas, Вы писали:

    WH>>56 страниц сильно оптимизированного кода на жабе (год разработки) против 17 строк на ДСЛ (год разработки компилятора).

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

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

    G>Для большинства задач требуется в разы меньшая квалификация, тем для разработки DSL.


    Это не так.

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

    G>Когда будут? Мне вот срочно dsl для разработки веб-сайтов нужен, с кучей готовых модулей.

    PHP. Серьезно.
    Re[4]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 10.04.12 18:43
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    G>В бизнесе чуть ли не все задачи типовые, но вот dsl для них не придумали.

    G>Когда будут?

    1С и тому подобные.

    WH>>Один из таких типовых ДСЛ SQL. Променяешь его на прямые запросы по физической структуре БД?

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

    Так он должен был быть eDSL, как Linq. А получилось наоборот.

    G>DSL еще написать надо, это сложно.


    Намного проще, чем хорошую библиотеку с удобным API.
    Re[8]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 10.04.12 18:45
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    G>У меня как раз был курс построения языков и мы там dsl рассматривали. Именно оттуда я выяснил что это сложная тема.


    Если курс читают дебилы или теоретики, то и арифметика сложной темой покажется.
    Re[6]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 10.04.12 18:49
    Оценка: -1
    Здравствуйте, Хвост, Вы писали:


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


    Семантика это всего лишь последовательность правил переписывания. Тупее и проще чем синтаксис в сто раз. И оптимизации всякие это не более чем правила. Вы просто совершенно не понимаете, что такое языки.
    Re[2]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 10.04.12 18:57
    Оценка: +2
    Здравствуйте, D. Mon, Вы писали:

    DM>Слова сомнения:

    DM>Следует помнить, что подход этот оправдан, когда есть множество похожих задач из одной области. Ведь вместо прямого решения задачи предлагается делать универсальный решатель задач подобного рода. Его сделать сложнее (и дело отнюдь не в парсинге), поэтому чтобы это дело окупилось, нужно решать им не одну задачу, а серию. Если же задача штучная, то смысла в таком подходе не видно, тут языки общего назначения и пригодятся. Так что совсем уж их объявлять бессмысленными не стоит.

    Неверно. Подход окупается и для штучных задач. Во первых, такое решение проще в поддержке: не надо переносить логику на новые платформы и языки (а это неизбежность для долгоживущих проектов), достаточно пеписать dsl. Не надо оптимизировать логику, можно оптимизировать компилятор. Код проще понимать, в том числе и неспециалистам. И для почти любых сложных задач это прроще и быстрее чем тупое ручное кодирование.
    Re[7]: Языки общего назначения не имеют смысла!
    От: b-3 Россия  
    Дата: 10.04.12 19:25
    Оценка: +1 -1 :)
    Здравствуйте, oldjackal, Вы писали:

    O> Семантика это всего лишь последовательность правил переписывания. Тупее и проще чем синтаксис в сто раз.

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

    В рабочий день уложитесь, с семантикой предметной области-то? А ведь если дошло до разработки DSL, предметная область как-никак сложнее, чем учебник шестиклассника. После этого откройте формальную грамматику парсера. Например Java. Например в форме Бекуса-Науэра
    Что-то мне подсказывает, что разница "в разы тупее и проще" там будет совсем в другую сторону!
    Забанен с формулировкой "клинический дисидент".
    Re[8]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 10.04.12 20:03
    Оценка:
    Здравствуйте, b-3, Вы писали:

    b-3>Ну я б не согласился. Возмите квадратичное уравнение из учебника 6-го класса средней школы. Явно несложная штука, дети справляются.

    b-3>Запишите последовательность правил переписывания при решении уравнения. Можно в псевдокоде.

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

    b-3>В рабочий день уложитесь, с семантикой предметной области-то? А ведь если дошло до разработки DSL, предметная область как-никак сложнее, чем учебник шестиклассника. После этого откройте формальную грамматику парсера. Например Java. Например в форме Бекуса-Науэра


    Не понял, вы вообще о чем?
    Re[3]: Языки общего назначения не имеют смысла!
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 10.04.12 20:04
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

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


    G>>Для большинства задач требуется в разы меньшая квалификация, тем для разработки DSL.

    O> Это не так.

    Покажи на примере чтоли?


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

    G>>Когда будут? Мне вот срочно dsl для разработки веб-сайтов нужен, с кучей готовых модулей.
    O> PHP. Серьезно.
    PHP — язык общего назначения.
    Re[5]: Языки общего назначения не имеют смысла!
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 10.04.12 20:05
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

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


    G>>В бизнесе чуть ли не все задачи типовые, но вот dsl для них не придумали.

    G>>Когда будут?

    O>1С и тому подобные.


    1С по сути тоже ЯОН. Только в замкнутой экосистеме.
    Решает задачи не только учета, а потенциально любые.

    G>>DSL еще написать надо, это сложно.

    O> Намного проще, чем хорошую библиотеку с удобным API.
    Покажи на примере. Рад буду такое использовать.
    Re[20]: Языки общего назначения не имеют смысла!
    От: PSV100  
    Дата: 10.04.12 20:19
    Оценка:
    Здравствуйте, alex_public, Вы писали:

    PSV>>Он используется в моей личной практике, но всё "программирование" происходит на бумаге с карандашом — язык очень простой, основная фишка: направленный граф без пересекающихся линий — это реально намного лучше того, что рисовалось до него не пойми как для своих всяких схем. Люди въезжают быстро, даже те, кто далёк от программирования и всяких блок-схем, быстро можно начать обсуждать предметную область на одном языке.


    _>Используется где-то помимо его основного назначения? Интересно.


    PSV>>Рекомендую.


    _>Хы, ну только для самообразования. Не вижу где его особо можно применить на практике. В смысле у нас, а не вообще в мире. )))


    Нет, ты не понял. Мы у себя ДРАКОН используем не для программирования, в классическом понимании. Там, где его изобрели, была реальная в нём потребность и используется он там по своему естественному назначению. В их звездолётах специфичное оборудование, управляется своеобразными командами по мудрённым принципам, на ассебмлер не похоже. Инженеры понимают внутреннее устройство и логику работы железа, но не могут программировать, а программистам эта прикладная сфера даётся крайне тяжело. Решили, пусть инженеры сами лепят себе привычные им чертежи, т.е. эти ДРАКОН-схемы, где всё на прямую расписывается алгоритм в рамках конкретных машинных команд. Дальше схемы куда-то транслируется и т.д.

    Вокруг ДРАКОНа понапридумывали всяких трансляторов из схем в языки С, Pascal и т.д. Имхо, это только для учебных и образовательных процессов.

    Мы же используем схемы для проектирования, набросков для алгоритмов, задач и т.д., когда нужно в чём-то разобраться, уяснить, обсудить с кем-то. Т.е. вместо традиционных программистких блок-схем, которые рисовались раньше кто как хотел: всякие прямоугольники со стрелками туда-сюда, в которых можешь сам потом хрен разобраться. В ДРАКОНе простой и удобный принцип: граф с направлением по линиям, которые не должны пересекаться. Всё, от ДРАКОНа больше ничего не нужно (нам, во всяком случае). Соединяешь прямоугольники (плюс что-то другое) со своим смыслом (в том числе, и как переходы к другим схемам — декомпозиция) линиями по правилам ДРАКОНа — получи реально простую и понятную всем схему. Можно с людьми, из прикладной области, говорить об одном и том же, все друг друга понимают без лишних слов.
    В этом вся сила и гениальность, такое в жизни встречается редко. Это что-то вроде "графического лиспа".
    Re[3]: Просто мысль...
    От: Wolverrum Ниоткуда  
    Дата: 10.04.12 20:22
    Оценка:
    Здравствуйте, WolfHound, Вы писали:
    WH>Ты не поверишь, но компилятор поддерживать проще.
    То-то же N так и не разродился промышленным компилятором...
    Re[12]: Языки общего назначения не имеют смысла!
    От: Gaperton http://gaperton.livejournal.com
    Дата: 10.04.12 21:32
    Оценка: 10 (2) +7 -1 :))
    Здравствуйте, VladD2, Вы писали:

    G>>Ты о скриптовой части, которая дает ему вычислительную полноту? Да какая разница, какая она?


    VD>Разница в том, что язык имеющий вычислительную полноту по тьюрингу и позволяющий писать код не через зад (как, например, SQL с рекурсивными расширениями) и является языком общего назначения.


    Сама цель создания DSL подразумевает, что для решения задач через него должна требоваться квалификация, на порядок меньшая, чем обычного программиста. Ибо программист справится и с обычным языком общего назначения. Ибо не дурак.

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

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

    Еще примеры? Системы компьютерной алгебры. Maltab. Maple. Автокад, который перешел с автолиспа на VBA. Язык TradingStation для описания торговых роботов.

    И это закономерно, что базовая семантика этих языков тупа до безобразия. Про DSL, в основе которых матан, мы просто не знаем, по вполне понятной причине — они нехрен никому не нужны.

    Влад, ты в каком-то своем странном мире живешь, реально.

    VD>1Эс — это ЯОН + среда ориентированная на бизнес-задачи. Того же самого можно было бы добиться создав библиотеки и внешние утилиты для явы или дотнета.


    Не думал, что когда-либо это скажу. Но. "Сперва добейся" (с)
    Re[17]: Языки общего назначения не имеют смысла!
    От: Vain Россия google.ru
    Дата: 10.04.12 21:33
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    WH>>>Ну, давай изучи АПИ для прямых обращений к физической структуре БД.

    V>>А в чём проблема? MFC, ADO, DAO?
    S>Боюсь, ни один из них тебе не даст возможности напрямую читать/писать странички БД и расставлять локи разных уровней. А именно это и есть прямое обращение "к физической структуре БД".
    А вы объясните зачем?
    [In theory there is no difference between theory and practice. In
    practice there is.]
    [Даю очевидные ответы на риторические вопросы]
    Re[9]: Языки общего назначения не имеют смысла!
    От: b-3 Россия  
    Дата: 10.04.12 22:50
    Оценка: :)
    Здравствуйте, oldjackal, Вы писали:

    O>Вы очень неудачно пример выбрали. В любой CAS эта задача решается именно через правила переписывания, причем крайне простые: факторизация выражения ( раскрытие скобок) и подстановка коэффициентов в готовую формулу.

    O>Не понял, вы вообще о чем?

    А вы о чём? Я вообще первый раз слышу, чтоб семантику (не грамматику, а именно семантику) сводили к "правилам переписывания".
    Можно где-нибудь пример таких "правил переписывания" увидеть?
    Забанен с формулировкой "клинический дисидент".
    Re[18]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 11.04.12 04:25
    Оценка: +2
    Здравствуйте, Vain, Вы писали:

    S>>Боюсь, ни один из них тебе не даст возможности напрямую читать/писать странички БД и расставлять локи разных уровней. А именно это и есть прямое обращение "к физической структуре БД".

    V>А вы объясните зачем?
    Как зачем? Чтобы выполнять задачи управления данными в БД. Перечисленные вами аббревиатуры — это не замена SQL, а всего лишь библиотеки для использования того же самого SQL.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[6]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 11.04.12 04:29
    Оценка:
    Здравствуйте, alex_public, Вы писали:

    _>Ну так я про то и говорю, что кругом просто "размётка". И в этом случае я невижу никакого смысла для отдельного языка под это — проще сразу генерировать в редакторе готовый код на системном языке.

    Странно. Вот вы не видите смысла, тем не менее даже ваша система использует этот отдельный язык. Как так?

    _>А вот если бы у нас в gui dsl можно было бы задавать хотя бы минимальные действия... Весь значительная часть обработчиков замкнута самая же на себя. Т.е. зачем обращаться в мощный основной язык ради того что бы в обработчики команды меню вызвать команду "показать диалог такой-то". И таких вызовов очень много! Значительная часть обработчиков состоит из вызова одной строки — вызова функции другого gui контрола. Это всё можно было замкнуть внутри себя, сделав вызовы наружу (в системный язык) только уже для реальной функциональности. Вот на такой dsl я бы точно перешёл. Но таких gui фреймворков я не знаю вообще.

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

    _>А с текущей ситуацией "просто размётки с указанием имён обработчиков" и при наличие визуального редактора у меня на такие dsl действует только бритва Оккама.

    Это не бритва Оккама — это шоры. Т.е. языки есть, вы ими пользуетесь, но отказываетесь их видеть.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[18]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 11.04.12 04:37
    Оценка: +2
    Здравствуйте, alex_public, Вы писали:

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

    Это отличительная черта всех DSL, спроектированных для машинного чтения/записи. Интересно рассматривать языки двойного назначения, которые облегчают roundtrip между правкой "в визуальном редакторе" и "в текстовом режиме".

    S>>То, что он у вас внутри какой-то некрасивый, как раз неважно. Важно, что он есть. Вы можете приделать к нему произвольное представление. Визуальное у вас уже есть. Можете приделать текстовое, и получите много замечательных бенефитов.


    _>Оно кстати и есть текстовое сейчас. Только не реальное для редактированием человеком. Ну т.е. в теории конечно возможно, но на практике бред. )))

    Никакого бреда. Представьте себе, что у вас два девелопера чинят два бага. Один увеличивает ширину кнопки submit, потому что в мадагаскарской локализации не влезла надпись, а другой меняет порядок табов на экране.
    Теперь у них конфликт обновлений, и нужно выполнить слияние изменений. Если формат текстовый, но содержит произвольно изменяемые фрагменты типа автогенерённых идентификаторов объектов (см. например файлы Rational Rose), или вообще не дай байт бинарный, то это слияние будет делать крайне неудобно. (Ну, разве что вы разработаете свой специальный инструмент для этого, типа как в Microsoft Word). А если ваш язык проектировался как человекочитаемый, то с большой вероятностью существующие инструменты прекрасно подойдут. Разработчику будет совершенно очевидна суть сделанных изменений.
    Не нужно думать, что эта задача требует каких-то сверхъестественных усилий. Посмотрите на то, как выглядят DFM-файлы в текстовом режиме. А ведь они пригодны для описания более-менее произвольной разметки контролов, в том числе и расширяемой.

    _>Тут основной поинт был не в том что мышкой. А в том что мы по сути пользуемся DSL но при этом никто не продумывал для него синтаксис и т.п. не самые тривиальные детали.

    Ну как это не продумывал? Конечно же продумывали. Вот этот ваш "визуальный синтаксис" — он же существует! Как-то показаны взаимоотношения контролов — иерархия, сцеплённость, размеры, и другие характерные вещи, которые вы редактируете. То, что вы не выделяли отельную фазу "разработка синтаксиса языка", ничего не значит. По факту он есть, пусть и в виде результата множества мелких решений.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[13]: Языки общего назначения не имеют смысла!
    От: netch80 Украина http://netch80.dreamwidth.org/
    Дата: 11.04.12 05:41
    Оценка:
    Здравствуйте, Gaperton, Вы писали:

    G>Сама цель создания DSL подразумевает, что для решения задач через него должна требоваться квалификация, на порядок меньшая, чем обычного программиста. Ибо программист справится и с обычным языком общего назначения. Ибо не дурак.


    [...]

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


    Вот тут — +100 под всем написанным.

    Добавлю только, что само понятие "языка" с чёткими требованиями к синтаксису может быть чрезмерным для тех, кто пишет на DSL. Поэтому вопроса развиваются графические представления — для тех случаев, где они достаточны, и в них соблюдение синтаксических норм достигается само собой.
    The God is real, unless declared integer.
    Re[4]: Просто мысль...
    От: WolfHound  
    Дата: 11.04.12 06:14
    Оценка: :)
    Здравствуйте, Wolverrum, Вы писали:

    W>То-то же N так и не разродился промышленным компилятором...

    Так это по тому, что при его реализации не использованы ДСЛ.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[13]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 11.04.12 06:25
    Оценка: +3
    Здравствуйте, Gaperton, Вы писали:

    G>Сама цель создания DSL подразумевает, что для решения задач через него должна требоваться квалификация, на порядок меньшая, чем обычного программиста. Ибо программист справится и с обычным языком общего назначения. Ибо не дурак.

    Феерическая глупость.
    Если программист не дурак, то это совершенно не означает что он должен писать в 10-100 раз больше кода, чем нужно для решения задачи.

    G>И это закономерно, что базовая семантика этих языков тупа до безобразия. Про DSL, в основе которых матан, мы просто не знаем, по вполне понятной причине — они нехрен никому не нужны.

    Да правда что ли? SQL сплошной матан. YACC, ANTLR и тп тоже один сплошной матан.

    G>Не думал, что когда-либо это скажу. Но. "Сперва добейся" (с)

    А что тут думать то?
    Технических аргументов у тебя нет.
    Одна демагогия.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[3]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 11.04.12 06:27
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

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

    Честно говоря, современные наработки весьма кривы. Но я работаю над выпрямлением.
    https://github.com/rampelstinskin/ParserGenerator
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[14]: Языки общего назначения не имеют смысла!
    От: netch80 Украина http://netch80.dreamwidth.org/
    Дата: 11.04.12 06:34
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    G>>Сама цель создания DSL подразумевает, что для решения задач через него должна требоваться квалификация, на порядок меньшая, чем обычного программиста. Ибо программист справится и с обычным языком общего назначения. Ибо не дурак.

    WH>Феерическая глупость.
    WH>Если программист не дурак, то это совершенно не означает что он должен писать в 10-100 раз больше кода, чем нужно для решения задачи.

    Ты случайно или намеренно не заметил, что речь идёт о DSL не для профессионального программиста, а для обычного пользователя с зачатками способностей к автоматизации?

    G>>И это закономерно, что базовая семантика этих языков тупа до безобразия. Про DSL, в основе которых матан, мы просто не знаем, по вполне понятной причине — они нехрен никому не нужны.

    WH>Да правда что ли? SQL сплошной матан.

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

    WH> YACC, ANTLR и тп тоже один сплошной матан.


    Адаптаторы и power users не пишут на Yacc.

    G>>Не думал, что когда-либо это скажу. Но. "Сперва добейся" (с)

    WH>А что тут думать то?
    WH>Технических аргументов у тебя нет.
    WH>Одна демагогия.

    Нет, это ты не умеешь читать и пропускаешь ключевые слова.
    Если бы ты умел читать, ты бы начал возражать на совсем другие места из того сообщения.
    The God is real, unless declared integer.
    Re[10]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 11.04.12 06:41
    Оценка: 1 (1)
    Здравствуйте, b-3, Вы писали:

    b-3>А вы о чём? Я вообще первый раз слышу, чтоб семантику (не грамматику, а именно семантику) сводили к "правилам переписывания".

    b-3>Можно где-нибудь пример таких "правил переписывания" увидеть?
    Чуть менее чем весь код в этой папке.
    https://github.com/rampelstinskin/ParserGenerator/tree/3666b1b364d3cbf942587a385aba13a07fa22661/Nemerle.Parser.Macro/Compiler/RuleCompiler

    Код получился сложноват ибо приходится переписывать в довольно низкоуровневый язык.
    По хорошему нужно добавить прослойку из еще одного языка.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[15]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 11.04.12 06:53
    Оценка: +1
    Здравствуйте, netch80, Вы писали:

    G>>>Сама цель создания DSL подразумевает, что для решения задач через него должна требоваться квалификация, на порядок меньшая, чем обычного программиста. Ибо программист справится и с обычным языком общего назначения. Ибо не дурак.

    N>Ты случайно или намеренно не заметил, что речь идёт о DSL не для профессионального программиста, а для обычного пользователя с зачатками способностей к автоматизации?
    Ты прочитай, что Gaperton написал.
    Он прямым текстом заявляет, что программистам ДСЛ не нужны. Они типа и так умные.

    N>Формулировку "выбрать среди всех записей те, у которых тип Z" способен освоить много кто, но опять-таки речь не о тех языках.

    О тех самых. Опять же читай то, что пишет Gaperton внимательно.
    А пишет он бред.

    Про DSL, в основе которых матан, мы просто не знаем, по вполне понятной причине — они нехрен никому не нужны.

    В основе SQL матан. Реляционная алгебра называется.
    А то, что матан вдруг оказался простым в использовании это не удивительно.
    Его для того и придумывают. Чтобы сложные вещи можно было записывать относительно простым способом.

    WH>> YACC, ANTLR и тп тоже один сплошной матан.

    N>Адаптаторы и power users не пишут на Yacc.
    Чего?

    N>Если бы ты умел читать, ты бы начал возражать на совсем другие места из того сообщения.

    Да правда что ли?
    На что тут можно возразить?
    Все что можно сделать, это указать на бред.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[7]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 11.04.12 07:01
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>Это интересная идея. У меня есть некоторые подозрения о причинах отсутствия таких DSL, но я в них совершенно не уверен.

    S>Если хотите, можем пообсуждать возможности и трудности, связанные с созданием такого DSL.
    Хотим.
    Мой вариант такого ДСЛ основан на MVVM.
    Model это произвольный код, не имеющий к ГУИ отношения.
    ViewModel основана на реактивном программировании. Те если внутри ViewModel что-то изменилось, то все что на основе этого было вычислено также автоматические пересчитывается.
    View это маппинг ViewModel на контролы. Благодаря реактивности при любом изменении ViewModel View автоматически пересчитывается. Также View может менять ViewModel при помощи биндинга свойств контролов на свойства ViewModel.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[16]: Языки общего назначения не имеют смысла!
    От: netch80 Украина http://netch80.dreamwidth.org/
    Дата: 11.04.12 07:11
    Оценка: +1 -1 :)
    Здравствуйте, WolfHound, Вы писали:

    G>>>>Сама цель создания DSL подразумевает, что для решения задач через него должна требоваться квалификация, на порядок меньшая, чем обычного программиста. Ибо программист справится и с обычным языком общего назначения. Ибо не дурак.

    N>>Ты случайно или намеренно не заметил, что речь идёт о DSL не для профессионального программиста, а для обычного пользователя с зачатками способностей к автоматизации?
    WH>Ты прочитай, что Gaperton написал.
    WH>Он прямым текстом заявляет, что программистам ДСЛ не нужны. Они типа и так умные.

    Вот с этим и надо было спорить, а не с последствиями для очевидно другого предназначения — DSL для пользователей.

    WH>А пишет он бред.


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

    Разговариваю с приятелем, который занимается каратэ. Он рассказывает о разных течениях и подвидах каратэ, показывает движения, в конце гордо заявляет:
    — Так что эта классика — полное г#$но!
    Из-за соседнего гаража выходит, покачиваясь, работяга с мутным взглядом, смотрит на нас и заявляет:
    — Что ты сказал??? Да пошёл ты на#$% со своим передним приводом!


    N>>Если бы ты умел читать, ты бы начал возражать на совсем другие места из того сообщения.

    WH>Да правда что ли?
    WH>На что тут можно возразить?
    WH>Все что можно сделать, это указать на бред.

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

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

    А вот тема DSL для программистов — больше твоя тема. И если бы ты не пытался сразу одним словом определить весь мир (причём в 90% случаев это слово "бред"), тебя можно было бы читать с пользой.
    А пока что с этим явные проблемы.
    The God is real, unless declared integer.
    Re[16]: Языки общего назначения не имеют смысла!
    От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
    Дата: 11.04.12 07:21
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>В основе SQL матан. Реляционная алгебра называется.

    WH>А то, что матан вдруг оказался простым в использовании это не удивительно.
    WH>Его для того и придумывают. Чтобы сложные вещи можно было записывать относительно простым способом.

    Угу смотрю я на запросы по 10 страниц никакой простоты и наглядности. Через навигационные методы было бы проще и нагляднее или Linq.
    Но есть простые задачи где SQL рулит. Нужно и то и другое. Нужны и DSL в составе ЯОН.
    и солнце б утром не вставало, когда бы не было меня
    Re[4]: Языки общего назначения не имеют смысла!
    От: netch80 Украина http://netch80.dreamwidth.org/
    Дата: 11.04.12 07:22
    Оценка: +7
    Здравствуйте, WolfHound, Вы писали:

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


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

    WH>Честно говоря, современные наработки весьма кривы. Но я работаю над выпрямлением.
    WH>https://github.com/rampelstinskin/ParserGenerator

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

    Вместо этой ссылки следовало бы нарисовать статью в стиле хабра, с такими же подробными разжёвываниями начиная с азов и красочным рассказом о преимуществах.
    Если ты хочешь, чтобы к тебе потянулись люди — а судя по заспамлению этой ссылкой, ты таки этого хочешь — то будь проще и понятнее.
    The God is real, unless declared integer.
    Re[17]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 11.04.12 07:29
    Оценка:
    Здравствуйте, Serginio1, Вы писали:

    S> Угу смотрю я на запросы по 10 страниц никакой простоты и наглядности.

    Напиши это с использованием прямого обращения к физической структуре БД. И запросы раздуются раз в 100.

    S>Через навигационные методы было бы проще и нагляднее

    Ну-ну.

    S>или Linq.

    Так я уже говорил, что линк это более правильный SQL.
    Кстати проблемы SQL вызваны в немалой степени тем, что его пытались заточить под кухарок. Не вышло. И нормальным программистам проблем добавили.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[18]: Языки общего назначения не имеют смысла!
    От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
    Дата: 11.04.12 07:43
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

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


    S>> Угу смотрю я на запросы по 10 страниц никакой простоты и наглядности.

    WH>Напиши это с использованием прямого обращения к физической структуре БД. И запросы раздуются раз в 100.
    Ну писал огромное количество в свое время. Знаю о чем говорю. При том, что на любой структуре можно построить класс.
    S>>Через навигационные методы было бы проще и нагляднее
    WH>Ну-ну.
    Есть куча мест где они и намного наглядне. Приходится писать кучу вложенных запросов просто для ипользовании вычисленных значений, что бы не было повторений и городить еще более сложный код для понимания, или разбивать текст на несколько строк, а потом их сшивать для получения результирующего запроса итд. И это еще в 1С где есть более менее нормальный конструктор "объектных" запросов.
    S>>или Linq.
    WH>Так я уже говорил, что линк это более правильный SQL.
    WH>Кстати проблемы SQL вызваны в немалой степени тем, что его пытались заточить под кухарок. Не вышло. И нормальным программистам проблем добавили.
    Ну так сколько времени то прошло. И Linq to EF нужно развивать. Кстати Linq пока хорош совместно с ObjectQuery. Так как у Linq есть ограничения в том числе и массовых изменений данных (Merge булки итд). И хотелось бы полностью избавиться от SQL.
    и солнце б утром не вставало, когда бы не было меня
    Re[4]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 11.04.12 08:47
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    G>>>Для большинства задач требуется в разы меньшая квалификация, тем для разработки DSL.

    O>> Это не так.

    G>Покажи на примере чтоли?


    Давайте задачу — покажу, как хреноватый кодер (я, то есть), не приходя в сознание под эту задачу dsl делает.

    O>> PHP. Серьезно.

    G>PHP — язык общего назначения.

    А мы теперь только не-Тьюринг-полные языки будем за dsl считать? Я так не играю.
    Re[10]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 11.04.12 08:53
    Оценка:
    Здравствуйте, b-3, Вы писали:


    b-3>А вы о чём? Я вообще первый раз слышу, чтоб семантику (не грамматику, а именно семантику) сводили к "правилам переписывания".


    Вы бы полистали хотя бы один учебник по денотационным семантикам, что ли.

    b-3>Можно где-нибудь пример таких "правил переписывания" увидеть?


    Да то же хваленое лямбда-исчисление — не более чем TRS. Погуглите о term rewriting, много интересного узнаете. И еще советую посмотреть на язык Mathematica, он весь на переписывании построен, из его дизайна можно много полезных трюков наворовать.
    Re[14]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 11.04.12 09:01
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>Да правда что ли? SQL сплошной матан. YACC, ANTLR и тп тоже один сплошной матан.


    Все не так плохо. Для того, чтобы пользоваться sql, реляционную алгебру знать не обязательно. Можно описывать грамматики на yacc, antlr или даже Boost::Spirit и не понимать ничего про используемые алгоритмы парсинга. Эти DSL скрывают сложность, и именно по этой причине они популярны.

    Я согласен с вашим оппонентом, что dsl должны быть тупыми. Вся сложность должна прятаться в их реализации. И есть множество способов сокращения даже этой сложности — если использовать dsl для реализации dsl, и если использовать более простые или более общие dsl в качестве целевого языка при компиляции новых dsl. Такаямногоуровневая структура позволяет избавляться от сложности на всех этапах.
    Re[4]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 11.04.12 09:08
    Оценка: :)
    Здравствуйте, WolfHound, Вы писали:

    WH>Честно говоря, современные наработки весьма кривы. Но я работаю над выпрямлением.

    WH>https://github.com/rampelstinskin/ParserGenerator

    Кстати, почему не packrat? Он туп как пробка, и тем прекрасен?

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

    Сейчас даже на голом шарпе без сторонних библиотек dslы делать легко и приятно. Да что там, я их когда-то и на Фортране писал не включая мозга.
    Re[15]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 11.04.12 09:10
    Оценка:
    Здравствуйте, netch80, Вы писали:

    WH>> YACC, ANTLR и тп тоже один сплошной матан.


    N>Адаптаторы и power users не пишут на Yacc.


    Однако power users обожают регвыры, куда как более матанистые.
    Re[11]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 11.04.12 09:14
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>Код получился сложноват ибо приходится переписывать в довольно низкоуровневый язык.

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

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

    Причем, что занятно, для описания этих преобразований не нужен Тьюринг-полный язык. Посмотрите на CompCert, например.
    Re[15]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 11.04.12 09:30
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    WH>>Да правда что ли? SQL сплошной матан. YACC, ANTLR и тп тоже один сплошной матан.

    O> Все не так плохо. Для того, чтобы пользоваться sql, реляционную алгебру знать не обязательно. Можно описывать грамматики на yacc, antlr или даже Boost::Spirit и не понимать ничего про используемые алгоритмы парсинга. Эти DSL скрывают сложность, и именно по этой причине они популярны.
    Я с этим не спорю.
    Но прочитай, что он сказал.

    G>И это закономерно, что базовая семантика этих языков тупа до безобразия. Про DSL, в основе которых матан, мы просто не знаем, по вполне понятной причине — они нехрен никому не нужны.

    Он явно гонит. Что я и продемонстрировал.

    O>Я согласен с вашим оппонентом, что dsl должны быть тупыми. Вся сложность должна прятаться в их реализации. И есть множество способов сокращения даже этой сложности — если использовать dsl для реализации dsl, и если использовать более простые или более общие dsl в качестве целевого языка при компиляции новых dsl. Такаямногоуровневая структура позволяет избавляться от сложности на всех этапах.

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

    Вот только он не это сказал.
    Он сказал, что ДСЛ нужны только не программистам и в основе полезных ДСЛ нет матана.
    Читай то, что написано, а не то, что ты хочешь прочитать.
    И имей в виду гапертон талантливый болтун, который имеет убеждать других в том, что он что-то знает. Но это не так. Ибо он слил в 100% технических споров.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[5]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 11.04.12 10:04
    Оценка: 62 (1)
    Здравствуйте, oldjackal, Вы писали:

    O>Кстати, почему не packrat? Он туп как пробка, и тем прекрасен?

    1)Не смотря на линейность, он жуткий тормоз.
    2)Задолбаешься задавать приоритеты операторам. А ассоциативность ПЕГ вообще не может.
    3)У ПЕГ есть проблема с приоритетным выбором. Его очень сложно использовать.
    4)ПЕГ в чистом виде не поддерживает изменение грамматики во время разбора.
    5)У ПЕГ низкая декларативность. Фактически приходится описывать алгоритм разбора.
    ...
    Мне просто лень перечислять весь список.

    Поэтому был разработан новый алгоритм. За основу были взяты PEG и Pratt parser.

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

    Ну да. Парсер должен описываться очень просто.
    Но современные инструменты не адекватны.
    На том же ПЕГ это сделать очень не просто. Особенно если у тебя есть несколько операторов с разными приоритетами и ассоциативностью.

    O>Сейчас даже на голом шарпе без сторонних библиотек dslы делать легко и приятно. Да что там, я их когда-то и на Фортране писал не включая мозга.

    Какие ДСЛи?
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[19]: Языки общего назначения не имеют смысла!
    От: Vain Россия google.ru
    Дата: 11.04.12 10:16
    Оценка: :)
    Здравствуйте, Sinclair, Вы писали:

    S>>>Боюсь, ни один из них тебе не даст возможности напрямую читать/писать странички БД и расставлять локи разных уровней. А именно это и есть прямое обращение "к физической структуре БД".

    V>>А вы объясните зачем?
    S>Как зачем? Чтобы выполнять задачи управления данными в БД.
    Я непонимаю. Есть проблемы поважнее баз данных, которым совершенно не нужны такие раздутые "прямые обращения", а нужно просто хранение массивов данных в иерархии и быстрый доступ к ним. В 99% это будет возможно и достаточно без прямый обращений "к физической структуре БД".

    S>Перечисленные вами аббревиатуры — это не замена SQL, а всего лишь библиотеки для использования того же самого SQL.

    Это не факт. Под объектами может скрываться вообще любая база, даже та которая не имеет своего dsl.
    [In theory there is no difference between theory and practice. In
    practice there is.]
    [Даю очевидные ответы на риторические вопросы]
    Re[16]: Языки общего назначения не имеют смысла!
    От: netch80 Украина http://netch80.dreamwidth.org/
    Дата: 11.04.12 10:57
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    WH>>> YACC, ANTLR и тп тоже один сплошной матан.

    N>>Адаптаторы и power users не пишут на Yacc.
    O>Однако power users обожают регвыры,

    Слово-то какое.

    O> куда как более матанистые.


    Они менее матанистые, в тех пределах, в которых их обожают. Потому что описать как "любая хрень от 5 до 12 цифр, за которой до трёх букв" проще, чем грамматику. 90% из них скончается в моральном плане на первом же shift/reduce конфликте, не поняв, как эту грамматику правильно вывернуть.
    Чтобы перейти на уровень, где грамматика проще регулярных выражений, надо выучить нехилый пласт теории.

    BTW, типичное регулярное выражение это даже не grep/posix-style. Это BASIC-style (это там, где '#' значит цифру, а '%' любую строку).
    The God is real, unless declared integer.
    Re[17]: Языки общего назначения не имеют смысла!
    От: Andrei N.Sobchuck Украина www.smalltalk.ru
    Дата: 11.04.12 11:45
    Оценка:
    Здравствуйте, Serginio1, Вы писали:

    ANS>>Наличие среди всего прочего "довольно интересного язык запросов" (читай "абсолютно идиотского") не делает весь язык "DSL".

    S> Да нет в 8 ке это уже максимально приближенный к "нормальному языку" язык запросов.

    Так Гапертон распинается за 7.x. Там система с запросами (не API для навигационного доступа, а именно запросы) была реально странная. Хотя, afair, работала нормально — если в запросе возвращаемый тип у поля был мономорфный (т.е. поле имело тип конкретного документа или справочника), то запрос генерился по одной таблице.

    И вообще, чего все так к языку в 1С прицепились. С языками были и другие системы, а популярная — одна. Имхо основная причина популярности — доступная и вменяемая репортная часть. У бухов мало делать запросы, результат еще нужно распечатать.
    Я ненавижу Hibernate
    Автор: Andrei N.Sobchuck
    Дата: 08.01.08
    !
    Re[18]: Языки общего назначения не имеют смысла!
    От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
    Дата: 11.04.12 12:00
    Оценка:
    Здравствуйте, Andrei N.Sobchuck, Вы писали:

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


    ANS>>>Наличие среди всего прочего "довольно интересного язык запросов" (читай "абсолютно идиотского") не делает весь язык "DSL".

    S>> Да нет в 8 ке это уже максимально приближенный к "нормальному языку" язык запросов.

    ANS>Так Гапертон распинается за 7.x. Там система с запросами (не API для навигационного доступа, а именно запросы) была реально странная. Хотя, afair, работала нормально — если в запросе возвращаемый тип у поля был мономорфный (т.е. поле имело тип конкретного документа или справочника), то запрос генерился по одной таблице.


    ANS>И вообще, чего все так к языку в 1С прицепились. С языками были и другие системы, а популярная — одна. Имхо основная причина популярности — доступная и вменяемая репортная часть. У бухов мало делать запросы, результат еще нужно распечатать.

    Я в свое время выбрал в далеком 1996 1С тогда 7.0 из-за
    1. Реализации в текущей конфигурации основных задач учета
    2. Простая модификация данных и использования "объектов" конфигурации
    3. Удобство формирования, вывода отчетов и обработка дейтвий пользователя с этим отчетом (вызов других отчетов по расшифровке в ячейке)
    Наверное 2,3 пункт можно сравнивать с ДСЛ
    Как таковой их язык запросов использовал не часто. Больше для меня подходил навигационный доступ через объекты.
    На SQL там симбиоз и 1С запросов и 1С++. Самое основное это использование "объектных" запросов и использование полей с множественным типом.

    По сути сейчас это аналог Linq to EF в ObjectQuery. Но когда появился ObjectQuery и 1С.
    Вообще мне как 1С нику и просто работающему в 1С нужен только 1 ДСЛ это более продвинутый LINQ2SQL. А использовать его все равно придется в ЯОН. Если его так просто сделать, что же нет явных подвижек?
    и солнце б утром не вставало, когда бы не было меня
    Re[17]: Языки общего назначения не имеют смысла!
    От: Andrei N.Sobchuck Украина www.smalltalk.ru
    Дата: 11.04.12 12:15
    Оценка: +1
    Здравствуйте, VoidEx, Вы писали:

    ANS>>Наличие среди всего прочего "довольно интересного язык запросов" (читай "абсолютно идиотского") не делает весь язык "DSL".


    VE>А что делает язык DSL?


    Нет формального критерия. Точнее чуть чуть есть (но нет). Различаю два вида DSL — внешний (external) и встроенный(embedded)(он же внутренний(internal)). Внешний реализован с помощью языка отличного от хост-языка (a-la Linq). А внутренний реализован на самом языке хостсистемы. Понятно, что есть языки на которых это получается красивее (Lisp, Ruby, ST), а есть на которых получается хуже. Понятно, что формализации в какой момент это еще API, а в какой это уже DSL тоже особо нету. "Assert" в jUnit это еще API или уже DSL? А х.з. А вот mockito уже больше похоже на внутренний DSL. Есть мнение, что любая большая система обрастая API обрастает и DSL-ями. Но имхо это бессмысленое утверждение (ввиду нефальсифицируемости).

    При этом в основной массе, когда описывают что такое внутренний DSL, отдельно отмечают, что Word+VB это не DSL для обрабтки документов, а скриптовый язык. Какие критерии — я не знаю, но с тем, что Word+VB это не DSL для текстов я согласен. Если это всё переложить на 1С v7x, то получится, что движок+язык 1С это не DSL. Но внутренним DSL можно (если очень хочется) считать API для работы с проводками. Явным внешним DSL будет язык запросов в 1Cv7x. Та ж фигня с браузерами. Я ни разу не слышал, чтобы JS считали DSL для работы с DOM. Но, например, jquery можно считать internal DSL.

    И еще пять копеек о том, что DSL всегда полезны. Вот в lisp есть loop. Персонально мне не кажется, что это такое большое достижение перед обычными циклами. А вот в том, что это переусложнение я уверен.
    Я ненавижу Hibernate
    Автор: Andrei N.Sobchuck
    Дата: 08.01.08
    !
    Re[19]: Языки общего назначения не имеют смысла!
    От: Andrei N.Sobchuck Украина www.smalltalk.ru
    Дата: 11.04.12 12:22
    Оценка:
    Здравствуйте, Serginio1, Вы писали:

    S> Я в свое время выбрал в далеком 1996 1С тогда 7.0 из-за

    S>1. Реализации в текущей конфигурации основных задач учета
    S>2. Простая модификация данных и использования "объектов" конфигурации
    S>3. Удобство формирования, вывода отчетов и обработка дейтвий пользователя с этим отчетом (вызов других отчетов по расшифровке в ячейке)

    Думаю для многих эти три пункта были критерием. И, думаю, п.1 это следствие п.2, п.3.
    Я ненавижу Hibernate
    Автор: Andrei N.Sobchuck
    Дата: 08.01.08
    !
    Re[6]: Языки общего назначения не имеют смысла!
    От: PSV100  
    Дата: 11.04.12 14:23
    Оценка:
    Здравствуйте, alex_public, Вы писали:

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


    S>>Тысячи их.

    _>И везде одна и та же ерунда. )

    S>>Чуть менее, чем во всех GUI-фреймворках привязка обработчиков выполнена внутри "языка размётки". Сами обработчики традиционно отдаются в General-Purpose-язык, но это исключительно оттого, что не хочется делать "ещё один" turing-complete язык внутри разметочного.


    _>Ну так я про то и говорю, что кругом просто "размётка". И в этом случае я невижу никакого смысла для отдельного языка под это — проще сразу генерировать в редакторе готовый код на системном языке.


    _>А вот если бы у нас в gui dsl можно было бы задавать хотя бы минимальные действия... Весь значительная часть обработчиков замкнута самая же на себя. Т.е. зачем обращаться в мощный основной язык ради того что бы в обработчики команды меню вызвать команду "показать диалог такой-то". И таких вызовов очень много! Значительная часть обработчиков состоит из вызова одной строки — вызова функции другого gui контрола. Это всё можно было замкнуть внутри себя, сделав вызовы наружу (в системный язык) только уже для реальной функциональности. Вот на такой dsl я бы точно перешёл. Но таких gui фреймворков я не знаю вообще.


    _>А с текущей ситуацией "просто размётки с указанием имён обработчиков" и при наличие визуального редактора у меня на такие dsl действует только бритва Оккама.


    Ты вроде раньше говорил, что разработка у тебя под виндой и используется (или теперь уже использовалась) студия. Гуй, я так понимаю, какой-то свой, но по идеологии что-то напоминает MFC. Я уже смутно помню, какое там было взаимоотношение дизайнеров с их местными картами сообщений, но такие мотивы песен вроде тебя не устраивают. Среди промышленных систем Delphi умеет делать то, что ты хочешь, со времён царя гороха. Там кроме визуальных контролов/виджетов есть и невизуальные компоненты, которыми тоже можно манипулировать в дизайнере. В нашем случае это так называемые там Action-ы: програмляются типовые объекты, которые реализуют нужные универсальные действия, затем эти action-ы в дизайнере привязал к нужным кнопкам и меню и т.д. Из коробки есть много чего типового, фактически, для учебного примера можно только в дизайнере наваять полноценный редактор по типу блокнота, не написав ни строчки кода (хотя, скорее всего, я несколько преувеличиваю, но не много). А если к такой системе прикрутить тот ДРАКОН, о котором мы недавно говорили — получи полноценную, и реально мощную, графическую систему программирования.

    А вообще-то, я тебе как-то говорил про нашу DSL-систему. У нас там есть фактически встроенная мини-дельфи. Но со временем у нас развился альтернативный скриптовый язык (кроме встроенного Паскаля), и для наших (!) многих задач мы убедились, что эффективнее всё-таки вручную програмлять интерфейс, особенно, если язык, простой и эффективный, позволяет несложно это делать. Как-то это гибче, мощнее, особенно когда нужно реализовать сотни типовых форм. Но и GUI-дизайнер тоже для ряда случаев удобная вещь.

    Здесь рядом в своём сообщении WolfHound говорит о реактивном программировании на основе model-view. Вполне здравая идея, проверенная у нас. Удобно, когда подправил скрипт и сразу видишь результат неотходя от кассы, часто не нужны отладчики или debug-сообщения.

    И языки разметки, имхо, на помойку лучше не выбрасывать пока, их неплохо можно готовить несколько по другим рецептам. Вот представь, что ты делаешь ГУИ на основе какого-нибудь HTMLLayout. Здесь есть отличный шанс на разделение задач: HTML — это структура, основа, документа, CSS — оформление (возможен не один вариант). При этом, какие-то верстальщики формируют HTML, они для этого могут сами для себя воспользоваться ещё одним DSL, например, Haml, какие-то дизайнеры возятся с CSS, могут для себя использовать Sass — ещё один DSL. Внутри HTML можно указать ещё DSL — шаблон для формирования документа. Лично мне симпатичны шаблоны без встроенного кода, как CTemplate от Google, или по мотивам Mustache ( {{переменная}}, {{! комментарий }}, {{#секция}} — {{/секция}}).

    А вообще-то, лично я с вебом слабо повязан, но я заметил хороший подход в некоторых фреймворках на Кложуре (возможно это сплошь и рядом, я не в курсе, но что-то сильно не заметно). Создаётся чистый HTML (пусть верстальщиком, дизайнером), без шаблонов, без CSS-элементов, без никакого кода, где есть некоторые правила, например, условные имена для div. Программист в коде читает этот файл, он трансформируется в структуры и пр. этого языка, дальше манипулируй с документом как хочешь в рамках программного кода. Также можно работать с CSS. Можно с нуля всё запрограмлять. Можно обработчики событий назначить, при этом можно код писать в самой Кложуре, вроде есть компиляция в JavaScript.
    Таким образом, можно получить такое разделение: отдельно только разметка, отдельно только оформление, и отдельно программный код. При этом каждый может заниматься своим делом, удобным ему способом, и никто друг на друга не влияет (относительно, конечно). Может всем заниматься один человек, может всё запрограмлять на одном языке, без HTML и пр.
    В этом конкретном случае ещё здорово помогает и сам язык и его платформа, для тех, конечно, кто с лиспом дружит.

    Имхо, отличный подход, который можно взять на вооружение не только для веба.
    Re[19]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 11.04.12 16:04
    Оценка: 9 (2)
    Здравствуйте, Serginio1, Вы писали:

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

    Ну, во-первых, вы правы. При разработке SQL вопросы повторного использования не рассматривались почти что никак. Поэтому в нём, в частности, нет функций высшего порядка. Да и вообще функций, аргументом которых являлось бы relation, нет.
    Во-вторых, всё же всё не настолько плохо, как вы говорите. В новом SQL есть with как способ введения "табличной переменной".
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[20]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 11.04.12 16:12
    Оценка:
    Здравствуйте, Vain, Вы писали:


    S>>Как зачем? Чтобы выполнять задачи управления данными в БД.

    V>Я непонимаю. Есть проблемы поважнее баз данных, которым совершенно не нужны такие раздутые "прямые обращения", а нужно просто хранение массивов данных в иерархии и быстрый доступ к ним.
    Если вам нужно "просто хранение массивов данных в иерархии и быстрый доступ к ним", то вам не нужен ни SQL, ни заменяемая им равномощная библиотека.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[8]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 11.04.12 16:24
    Оценка:
    Здравствуйте, WolfHound, Вы писали:
    WH>Мой вариант такого ДСЛ основан на MVVM.
    WH>Model это произвольный код, не имеющий к ГУИ отношения.
    WH>ViewModel основана на реактивном программировании. Те если внутри ViewModel что-то изменилось, то все что на основе этого было вычислено также автоматические пересчитывается.
    Надо понять, что такое "было вычислено", и что такое "автоматически пересчитывается".
    WH>View это маппинг ViewModel на контролы. Благодаря реактивности при любом изменении ViewModel View автоматически пересчитывается. Также View может менять ViewModel при помощи биндинга свойств контролов на свойства ViewModel.
    Давайте обсудим примеры каких-нибудь конкретных gui-сценариев, где "в классике" нам нужно писать обработчики событий, от которых хочется уйти.

    1. Зависимые контролы. Типа выбор радиобаттона определяет видимость или разблокированность связанных с ним контролов. Очевидно, решается введением зависимых свойств. Типа, BillingAddressPanel.Enabled = !BillingIsTheSameAsShipping.Checked
    2. Валидация данных, с отображением результата валидации. Вариантов оформления — бездна. Суть — более-менее одна: есть некая формула, которая связывает данные с результатом валидации, а результат валидации — с внешним видом контролов. Опять — таки зависимые свойства.
    3. Нетривиальное поведение. Скажем, вводим URL — по окончанию ввода в фоне программа бежит по этой ссылке и отображает preview картинки или что там по этому URL нашлось (см.тж. facebook).
    Тут нюанс в том, что надо вешаться не каждое изменение данных, а только на более-менее паузы.
    В Delphi мы такие штуки делали путём добавления отдельного объекта-таймера и довольно муторной обработки событий OnChanged и OnTimer.
    4. Аналогичная штука — анимации.
    То есть для 3 и 4 просто зависимостей от мгновенных значений есть ещё необходимость всё-таки реагировать на события, или на их цепочки, определённым образом. Пока мне не очевидно, как это сделать хорошим способом. Не обязательно визуальным — важно обойтись без лишнего мусора, типа асинхронных таймеров и синхронных стейт-машин, описанных вручную.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[7]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 11.04.12 16:28
    Оценка: +1
    Здравствуйте, PSV100, Вы писали:

    PSV>Создаётся чистый HTML (пусть верстальщиком, дизайнером), без шаблонов, без CSS-элементов, без никакого кода, где есть некоторые правила, например, условные имена для div. Программист в коде читает этот файл, он трансформируется в структуры и пр. этого языка, дальше манипулируй с документом как хочешь в рамках программного кода.

    Я бы не сказал что это хороший подход.
    ИМХО тут слишком много не нужной работы.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[9]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 11.04.12 16:58
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>Надо понять, что такое "было вычислено", и что такое "автоматически пересчитывается".

    model HelloModel
    {
        firstName : string = "Planet";
        lastName : string = "Earth";
        fullName : string <- $"$firstName $lastName";
    }

    view HelloView(model : HelloModel)
    {
        <p>First name: <input value <-> model.firstName; /></p>
        <p>Last name: <input value <-> model.lastName; /></p>
        <h2>Hello, <span text <- model.fullName; />!</h2>
    }

    Вот скажем тут свойство fullName будет вычислино при создании объекта модели.
    При этом после каждого изменения свойств firstName или lastName оно будет пересчитано.
    В данном случае эти свойста связываются с текстовым полем. И после каждого изменения текстого поля будут обновляться.
    После чего обновиться fullName. После обновления fullName система поймет, что нудно обновить тег <span text <- model.fullName; />.
    Можешь собрать https://github.com/rsdn/nemerle/tree/master/snippets/Nemerle.WUI.Reactive и посмотреть, как это работает.

    S>1. Зависимые контролы. Типа выбор радиобаттона определяет видимость или разблокированность связанных с ним контролов. Очевидно, решается введением зависимых свойств. Типа, BillingAddressPanel.Enabled = !BillingIsTheSameAsShipping.Checked

    Чекбокса? Но не важно.
    Тут мы вводим в ViewModel свойство BillingIsTheSameAsShipping. После чего связываем его с чекбоксом и с показом контролов.

    S>2. Валидация данных, с отображением результата валидации. Вариантов оформления — бездна. Суть — более-менее одна: есть некая формула, которая связывает данные с результатом валидации, а результат валидации — с внешним видом контролов. Опять — таки зависимые свойства.

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

    S>3. Нетривиальное поведение. Скажем, вводим URL — по окончанию ввода в фоне программа бежит по этой ссылке и отображает preview картинки или что там по этому URL нашлось (см.тж. facebook).

    S>Тут нюанс в том, что надо вешаться не каждое изменение данных, а только на более-менее паузы.
    S>В Delphi мы такие штуки делали путём добавления отдельного объекта-таймера и довольно муторной обработки событий OnChanged и OnTimer.
    Тут нужно подумать.
    Как вариант можно захардкодить режим обновления не после каждого изменения, а после некоторой паузы.
    Но способ произвольно фильтровать события тоже нужен. Нужно подумать над красивым решением.

    S>4. Аналогичная штука — анимации.

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

    S>Не обязательно визуальным — важно обойтись без лишнего мусора, типа асинхронных таймеров и синхронных стейт-машин, описанных вручную.

    Это не сложно. Переписать линейный код в асинхронный автомат задача тривиальная.
    Я такое уже делал.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[5]: Языки общего назначения не имеют смысла!
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 11.04.12 19:06
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

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


    G>>>>Для большинства задач требуется в разы меньшая квалификация, тем для разработки DSL.

    O>>> Это не так.
    G>>Покажи на примере чтоли?
    O> Давайте задачу — покажу, как хреноватый кодер (я, то есть), не приходя в сознание под эту задачу dsl делает.
    Я уже говорил — разработка сайтов.

    O>>> PHP. Серьезно.

    G>>PHP — язык общего назначения.
    O> А мы теперь только не-Тьюринг-полные языки будем за dsl считать? Я так не играю.
    Я таки думаю что за DSL нужно считать именно domain-specific. То есть яызки которые имеют ярко выраженную предметную область и имеют некоторые средства, недоступные в этой области ЯОН.

    В PHP нету ничего специального для работы с HTML или HTTP. А вот если razor взять, то очень даже есть. Поэтому первый — яон, а второй DSL.
    Re[7]: Языки общего назначения не имеют смысла!
    От: alex_public  
    Дата: 11.04.12 19:36
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>Странно. Вот вы не видите смысла, тем не менее даже ваша система использует этот отдельный язык. Как так?

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

    S>Это интересная идея. У меня есть некоторые подозрения о причинах отсутствия таких DSL, но я в них совершенно не уверен.

    S>Если хотите, можем пообсуждать возможности и трудности, связанные с созданием такого DSL.

    Было бы интересно. Хотя могу сразу сказать что я в dsl строение не специалист — ни одного не создал пока что. А вот в их использование на оборот. Обычно у нас каждый проект использует десяток разных языков/технологий.

    Значит сформулирую пожелания к подобному GUI DSL. Хотелость бы удобную размётку документа (кстати, желательно с визуальным редактором, но это отдельный вопрос) с возможностью указывать в виде обработчиков не только функции из системного языка, но и вызов некоторого набора функций GUI объектов.

    Ну и первая мысль для обсуждения: html+javascript в какой-то степени реализуют подобную модель. Но с парой поправок:
    1. там это всё не особо удобно на самом деле
    2. подобную практику (javascript внутри например OnClick) в данный момент считают плохой. И понятно почему — в данном случае javascript играет роль не gui dsl, а системного языка. Т.е. писать такой код, это по аналогии что-то типа вставки c++ кода в *.rc файлы. )))
    Но в приципе, технически, в html+javascript подобный gui dsl реализуем.
    Re[19]: Языки общего назначения не имеют смысла!
    От: alex_public  
    Дата: 11.04.12 19:56
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>Никакого бреда. Представьте себе, что у вас два девелопера чинят два бага. Один увеличивает ширину кнопки submit, потому что в мадагаскарской локализации не влезла надпись, а другой меняет порядок табов на экране.

    S>Теперь у них конфликт обновлений, и нужно выполнить слияние изменений. Если формат текстовый, но содержит произвольно изменяемые фрагменты типа автогенерённых идентификаторов объектов (см. например файлы Rational Rose), или вообще не дай байт бинарный, то это слияние будет делать крайне неудобно. (Ну, разве что вы разработаете свой специальный инструмент для этого, типа как в Microsoft Word). А если ваш язык проектировался как человекочитаемый, то с большой вероятностью существующие инструменты прекрасно подойдут. Разработчику будет совершенно очевидна суть сделанных изменений.
    S>Не нужно думать, что эта задача требует каких-то сверхъестественных усилий. Посмотрите на то, как выглядят DFM-файлы в текстовом режиме. А ведь они пригодны для описания более-менее произвольной разметки контролов, в том числе и расширяемой.

    Ммм, ну да, должен признать что регулярно вижу диффы этих файлов в Mercurial и по ним даже можно понять что поменяли люди. Но я как-то никогда не воспринимал это как существенное преимущество. ) И слияние на таком файле автоматике старались никогда не доверять. )))

    _>>Тут основной поинт был не в том что мышкой. А в том что мы по сути пользуемся DSL но при этом никто не продумывал для него синтаксис и т.п. не самые тривиальные детали.

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

    Ммм, ну это скорее задано самим фреймворком, под который генерируется код, а не авторами редактора. Вообще к чему это всё я говорю. Вот я смотрю на этот редактор и в общем не вижу никаких проблем написать самому такой же вообще практические не думая. Т.е. тупо "закодить". А вот если бы я захотел придумать некий язык, по которому потом генерировался тот же код, то я бы с самого начала начал задумываться над всякими нюансами. Причём не обязательно какими-то "высоконаучными", а возможно просто стилевыми. Например использовать мне в моём dsl {} или begin/end? Я не говорю что это что-то дико сложное, но всё же время отнимает. А в случае с редактором ничего такого нет — тупо закодить визуальный редактор плюс набор шаблонов кода под контролы.
    Re[9]: Языки общего назначения не имеют смысла!
    От: Хвост  
    Дата: 11.04.12 20:07
    Оценка: -1 :)
    Здравствуйте, WolfHound, Вы писали:

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


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

    WH>Ты даже не представляешь насколько ты смешон.
    WH>The principal programming paradigms
    Автор: remark
    Дата: 05.12.09

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

    спасибо кэп, только где в этой картинке противоречие с моими словами? вся твоя картинка вписывается в те самые три модели, за исключением xml,html и прочих markup-языков, у которых вычислительной модели нет. Тот же хаскель позволяет описать декларативно вещи подобные channels в го, или императив BASIC, или sql-like конструкции для обращения к коллекциям.

    WH>Но есть и более конкретные языки. Например, этот https://github.com/rampelstinskin/ParserGenerator имеет свою ни на что не похожую модель вычислений.

    Ни на что ни похожая модель вычислений это уже подозрительно, а точнее такого не бывает. Можешь вкратце рассказать что там?
    People write code, programming languages don't.
    Re[8]: Языки общего назначения не имеют смысла!
    От: alex_public  
    Дата: 11.04.12 20:08
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>Мой вариант такого ДСЛ основан на MVVM.

    WH>Model это произвольный код, не имеющий к ГУИ отношения.
    WH>ViewModel основана на реактивном программировании. Те если внутри ViewModel что-то изменилось, то все что на основе этого было вычислено также автоматические пересчитывается.
    WH>View это маппинг ViewModel на контролы. Благодаря реактивности при любом изменении ViewModel View автоматически пересчитывается. Также View может менять ViewModel при помощи биндинга свойств контролов на свойства ViewModel.

    Интересно. Как я понимаю для model подразумевается использовать какой-то системный язык, для view что-то типа языка размётки, а для viewmodel как раз тот самый dsl?

    Или же можно ещё всё писать например на системном языке. Тогда model — это просто код. view model может быть что-то типа dsl внутри языка (типа как boost.sprit), а view может быть кодом генерируемым редактором.

    Кстати, а все эти мысли — это вот только рассуждения в этой теме или может уже что-то реальное? Vlad2 вот кидал ссылку на что-то из этой области, но там веб-фреймворк обсуждался...
    Re[9]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 11.04.12 20:14
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>3. Нетривиальное поведение. Скажем, вводим URL — по окончанию ввода в фоне программа бежит по этой ссылке и отображает preview картинки или что там по этому URL нашлось (см.тж. facebook).

    S>Тут нюанс в том, что надо вешаться не каждое изменение данных, а только на более-менее паузы.
    S>4. Аналогичная штука — анимации.

    Это по сути один пункт — настройка поведения UI. Решается он путем позволения разработки своих контролов и связываний (биндингов). А так же возможность вмешаться в ход работы реактивной модели и что-то похимичить.

    Вот живой пример:
    http://knockoutjs.com/examples/animatedTransitions.html

    Кода связанного с анимацией там кот на плакал. И он прекрасно сочетается с работой гуя основанного на биндинге.

    Все это можно спрятать за контролами с нужными биндингами, или спец-биндингами которые могли бы расширять имеющиеся контролы.

    В общем, задача решаемая. Про не нужно быть максималистом и нужно давать возможность людям расширять систему.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[3]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 11.04.12 20:22
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    A>>давайте разберем такой проект — надо написать IM клиент, например для jabber'а

    A>>допустим у нас нет готовой библиотеки и мы пишем его с нуля
    A>>у него есть UI, несколько слоев сетевого кода, куча мелких модулей типа конфига и т.п.
    A>>где там можно применить DSL?
    S>Например, шибко бы пригодился DSL для описания протокола взаимодействия, чтобы чётко были видны все переходы статусов соединения.

    http://www.rsdn.ru/forum/nemerle/4350026.1.aspx
    Автор: CodingUnit
    Дата: 20.07.11
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[9]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 11.04.12 20:24
    Оценка:
    Здравствуйте, alex_public, Вы писали:

    _>Интересно. Как я понимаю для model подразумевается использовать какой-то системный язык,

    Да что угодно.

    _> для view что-то типа языка размётки,

    Скорее что-то типа XSLT для трансформации ViewModel во View.

    _>а для viewmodel как раз тот самый dsl?

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

    _>Или же можно ещё всё писать например на системном языке. Тогда model — это просто код. view model может быть что-то типа dsl внутри языка (типа как boost.sprit), а view может быть кодом генерируемым редактором.

    Не взлетит.

    _>Кстати, а все эти мысли — это вот только рассуждения в этой теме или может уже что-то реальное? Vlad2 вот кидал ссылку на что-то из этой области, но там веб-фреймворк обсуждался...

    Я кидал. И я разу сказал, что это легко обобщить на любой ГУИ.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[7]: Языки общего назначения не имеют смысла!
    От: alex_public  
    Дата: 11.04.12 20:44
    Оценка:
    Здравствуйте, PSV100, Вы писали:

    Уууу какое сообщение. )

    PSV>Ты вроде раньше говорил, что разработка у тебя под виндой и используется (или теперь уже использовалась) студия. Гуй, я так понимаю, какой-то свой, но по идеологии что-то напоминает MFC. Я уже смутно помню, какое там было взаимоотношение дизайнеров с их местными картами сообщений, но такие мотивы песен вроде тебя не устраивают. Среди промышленных систем Delphi умеет делать то, что ты хочешь, со времён царя гороха. Там кроме визуальных контролов/виджетов есть и невизуальные компоненты, которыми тоже можно манипулировать в дизайнере. В нашем случае это так называемые там Action-ы: програмляются типовые объекты, которые реализуют нужные универсальные действия, затем эти action-ы в дизайнере привязал к нужным кнопкам и меню и т.д. Из коробки есть много чего типового, фактически, для учебного примера можно только в дизайнере наваять полноценный редактор по типу блокнота, не написав ни строчки кода (хотя, скорее всего, я несколько преувеличиваю, но не много). А если к такой системе прикрутить тот ДРАКОН, о котором мы недавно говорили — получи полноценную, и реально мощную, графическую систему программирования.


    Не знал что Дельфи такая модная в этом смысле. ) Мы то её никогда не использовали по своми причинам и видимо никогда не будем. Но возможно что часть идей оттуда хорошо бы стащить. )))

    PSV>А вообще-то, я тебе как-то говорил про нашу DSL-систему. У нас там есть фактически встроенная мини-дельфи. Но со временем у нас развился альтернативный скриптовый язык (кроме встроенного Паскаля), и для наших (!) многих задач мы убедились, что эффективнее всё-таки вручную програмлять интерфейс, особенно, если язык, простой и эффективный, позволяет несложно это делать. Как-то это гибче, мощнее, особенно когда нужно реализовать сотни типовых форм. Но и GUI-дизайнер тоже для ряда случаев удобная вещь.


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

    PSV>Здесь рядом в своём сообщении WolfHound говорит о реактивном программировании на основе model-view. Вполне здравая идея, проверенная у нас. Удобно, когда подправил скрипт и сразу видишь результат неотходя от кассы, часто не нужны отладчики или debug-сообщения.


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

    PSV>И языки разметки, имхо, на помойку лучше не выбрасывать пока, их неплохо можно готовить несколько по другим рецептам. Вот представь, что ты делаешь ГУИ на основе какого-нибудь HTMLLayout. Здесь есть отличный шанс на разделение задач: HTML — это структура, основа, документа, CSS — оформление (возможен не один вариант). При этом, какие-то верстальщики формируют HTML, они для этого могут сами для себя воспользоваться ещё одним DSL, например, Haml, какие-то дизайнеры возятся с CSS, могут для себя использовать Sass — ещё один DSL. Внутри HTML можно указать ещё DSL — шаблон для формирования документа. Лично мне симпатичны шаблоны без встроенного кода, как CTemplate от Google, или по мотивам Mustache ( {{переменная}}, {{! комментарий }}, {{#секция}} — {{/секция}}).


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

    PSV>А вообще-то, лично я с вебом слабо повязан, но я заметил хороший подход в некоторых фреймворках на Кложуре (возможно это сплошь и рядом, я не в курсе, но что-то сильно не заметно). Создаётся чистый HTML (пусть верстальщиком, дизайнером), без шаблонов, без CSS-элементов, без никакого кода, где есть некоторые правила, например, условные имена для div. Программист в коде читает этот файл, он трансформируется в структуры и пр. этого языка, дальше манипулируй с документом как хочешь в рамках программного кода. Также можно работать с CSS. Можно с нуля всё запрограмлять. Можно обработчики событий назначить, при этом можно код писать в самой Кложуре, вроде есть компиляция в JavaScript.


    Да, это сейчас стандартный подход для javascript вроде при хорошем стиле. Всяческие jquery даже делают работу с этим всем удобным.

    PSV>Имхо, отличный подход, который можно взять на вооружение не только для веба.


    Ну вообще то например древние rc файлы тоже действовали по такому принципу. Т.е. там были только id, к которым потом обращался код. Правда не было разделения на структуру (html) и стили (css), но это уже мелочи. И я бы не сказал что из этого вышел очень удачный инструмент. Хотя для своего времени...
    Re[18]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 11.04.12 20:53
    Оценка:
    Здравствуйте, alex_public, Вы писали:

    VD>>Да ладно. Кодокенерация у них встречается частенько. Для тех же ресурсов дотнета они генерируют классы-обертки.


    _>Угу, это ещё в MFC было — ClassWizard и т.п. И помнится там был ещё генератор обёрток для COM. Но это именно пустые классы, а вот код с какой-то логикой работы... Такого не помню у них ни разу.


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

    В студию даже входит простенькая утилитка для герерации текста — T4. И есть даже проект — Oslo. Который, правда, похоже замаскировали (скрыли от глаз).

    VD>>Вопрос только в катастрофически низком уровне этой генерации.


    _>Вот мне не понятно почему оно у них тут низкое, для такой простой задачи.


    Где ты увидел простую задачу? Еще раз. Речь не идет об одноразовой генерации вроде того что делают визарды.

    _>Да, само собой это какая-то разновидность dsl. Но при этом без создания синтаксиса языка. Может это не плохое решение, пока нет удобных автоматических инструментов dsl-строения? )


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

    У МС — это CodeDome. Это уродливый и кривой ДСЛ описывающий состояние контролов.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[9]: Языки общего назначения не имеют смысла!
    От: alex_public  
    Дата: 11.04.12 20:57
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>Давайте обсудим примеры каких-нибудь конкретных gui-сценариев, где "в классике" нам нужно писать обработчики событий, от которых хочется уйти.

    S>...

    Что-то это какой-то уход в мелкие детали. Я бы начал с простой общей вещи. Что в нашем языке есть какое-то отображение понятика контрол — в какой-то объект языка. И эти объекты мы в языке можем создавать и потом вызывать их функции. И отдельно можем вызывать функции "системного" языка. В принципе уже только это позволило бы убрать практически весь код связанный с интерфейсом в наш dsl, оставив системному языку только "движок".
    Re[2]: Языки общего назначения не имеют смысла?
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 11.04.12 21:35
    Оценка:
    Здравствуйте, netch80, Вы писали:

    N>Некоторые тезисы к обсуждению...


    Буду краток — полный бред. Подменил понятие "ДСЛ" на понятие "Уровень языка", и выстроил на этом стройную, но бессмысленную картину. Выводы в конце вообще из пальца высосаны. За одно к "немерлистам" записал пол форума. Синклер такой прям рьяный немерлист .

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

    На то она и предметная область, чтобы решать только ее задачу. Если ДСЛ позволяет (пусть криво или медленно) воспроизвести себя, то это ЯОН (язык общего назначения). А его уровень не имеет никакого отношения к ДСЛ-ности.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[19]: Языки общего назначения не имеют смысла!
    От: alex_public  
    Дата: 11.04.12 21:38
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Где ты увидел простую задачу? Еще раз. Речь не идет об одноразовой генерации вроде того что делают визарды.


    А зачем?

    VD>Это самообман. Синтаксис вы все равно создаете. Просто он уродливый, так как выражается через возможности хост-языка. Это, скорее всего, набор классов и иерархия объектов.


    Только его создают не авторы редактора, а авторы фреймворка. )
    Re[10]: Языки общего назначения не имеют смысла!
    От: alex_public  
    Дата: 11.04.12 21:46
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    _>>Или же можно ещё всё писать например на системном языке. Тогда model — это просто код. view model может быть что-то типа dsl внутри языка (типа как boost.sprit), а view может быть кодом генерируемым редактором.

    WH>Не взлетит.

    Почему? )

    _>>Кстати, а все эти мысли — это вот только рассуждения в этой теме или может уже что-то реальное? Vlad2 вот кидал ссылку на что-то из этой области, но там веб-фреймворк обсуждался...

    WH>Я кидал. И я разу сказал, что это легко обобщить на любой ГУИ.

    Ой, сорри, точно. И ещё же говорили про это. Это я просто запутался прочитав там сообщения некоторые)

    Не знаю насколько легко обобщить... Для меня не очевидно пока. Вообще html+javascrip — это как бы лёгкая область для экспериментов мне кажется. Когда мы переходим к компилируемым типизированным языкам и сложным нативным контролам, то уже не так очевидно всё выглядит.
    Re[3]: Языки общего назначения не имеют смысла?
    От: WolfHound  
    Дата: 11.04.12 21:52
    Оценка: +2
    Здравствуйте, VladD2, Вы писали:

    VD>На то она и предметная область, чтобы решать только ее задачу. Если ДСЛ позволяет (пусть криво или медленно) воспроизвести себя, то это ЯОН (язык общего назначения). А его уровень не имеет никакого отношения к ДСЛ-ности.

    Плохой критерий.
    Ибо так умеют все полные по Тьюрингу языки.
    Соответственно если вдруг ДСЛ окажется полным по Тьюрингу, то он сразу перестает быть ДСЛ?
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[20]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 11.04.12 21:54
    Оценка: +3
    Здравствуйте, WolfHound, Вы писали:

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


    Это бессмысленное философствование превращающее в бессмыслицу даже заголовок данной темы.

    Ты договорился до того, что ЯОН вообще нет в природе (а он есть (с) анекдот про суслика).

    Уровень ЯОН не делает из него более ДСЛ для всех задачей.

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

    Создание ДСЛ не будет бесплатным никогда! Ни какие N256 не устранят необходимости выделять модель, придумывать язык для ее описания и манипуляций с ней, реализовывать язык и т.п.

    Все что можно сделать сократить затраты на такую разработку. Но все равно будет сто тысяч задач которые проще решить в лоб, нежели писать для нее ДСЛ в стиле "Решим мне мою проблему".

    Конечно можно порассуждать на тему, что для таких задач ДСЛ-ем является ЯОН или вообще ассемблер. Но от таких рассуждений толку еще меньше.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[21]: Языки общего назначения не имеют смысла!
    От: Vain Россия google.ru
    Дата: 11.04.12 22:17
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>>>Как зачем? Чтобы выполнять задачи управления данными в БД.

    V>>Я непонимаю. Есть проблемы поважнее баз данных, которым совершенно не нужны такие раздутые "прямые обращения", а нужно просто хранение массивов данных в иерархии и быстрый доступ к ним.
    S>Если вам нужно "просто хранение массивов данных в иерархии и быстрый доступ к ним", то вам не нужен ни SQL, ни заменяемая им равномощная библиотека.
    Ну тогда и язык мне не нужен, можно всё на бумаге считать.
    Речь то как раз про удобные и несложные средства. SQL на них не тянет, т.к. является таким же тяжёлым языком как языки общего назначения.
    [In theory there is no difference between theory and practice. In
    practice there is.]
    [Даю очевидные ответы на риторические вопросы]
    Re[13]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 11.04.12 22:37
    Оценка: 3 (1)
    Здравствуйте, Gaperton, Вы писали:

    G>Сама цель создания DSL подразумевает, что для решения задач через него должна требоваться квалификация, на порядок меньшая, чем обычного программиста. Ибо программист справится и с обычным языком общего назначения. Ибо не дурак.


    Это очень спорное утверждение.

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

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

    Так что цель создания ДСЛ — упростить решение задачи. А рассуждения про квалификацию здесь излишние (если не сказать некорректны).

    G>Еще один пример


    А где был первый пример?

    G>из обыденной практики — использование LUA для написания скриптов AI в играх. Их пишут не программисты.


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

    G> Это для них в игровую платформу внедряют LUA. Цель — исключить необходимость затратного общения между гейм-аналитиками и программистами при реализации AI, пусть аналитики справляются сами.


    Луа — ЯОН. Весь смысл его применения в игровых движках — сделать их отладку более интерактивной.

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

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


    Подмена предмета обсуждения дететкетд. Луа — ЯОН. Все выводы сделанные на предположении, что Луа — это ДСЛ ничтожны.

    Ну, и 5 копеек про "с семантикой не сложнее раннего бейсика":

    Класс языка:
    мультипарадигмальный:
    скриптовый,
    императивный,
    функциональный,
    объектно-ориентированный (прототипный)

    (с) Википедия.

    Ничё так описание для языка не сложнее раннего бэйсика. Так и вижу себе реализацию GoSub на мета-таблицах.

    G>Еще примеры? Системы компьютерной алгебры. Maltab. Maple.


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

    G>Автокад, который перешел с автолиспа на VBA. Язык TradingStation для описания торговых роботов.


    Ага. И видимо после перехода с Лиспа на ВБА скрипты чудесным образом превратились в ДСЛ.

    Там что Лисп, что ВБА используются для автоматизации. А сами языки универсальны в доску.

    G>И это закономерно, что базовая семантика этих языков тупа до безобразия.


    Чё за базовая семантика такая? Чем она у Лиспа острее? Его семантику можно на любом языке за денек воспроизвест\и.

    G>Влад, ты в каком-то своем странном мире живешь, реально.


    Влад, ты в каком-то своем странном мире живешь, реально.

    VD>>1Эс — это ЯОН + среда ориентированная на бизнес-задачи. Того же самого можно было бы добиться создав библиотеки и внешние утилиты для явы или дотнета.


    G>Не думал, что когда-либо это скажу. Но. "Сперва добейся" (с)


    Что добиться то? Там основные заслуги в организации франчейзи, сети сбыта, маркетинге и т.п. Как программный продукт 1Эс скорее всего уступит какому-нибудь Парусу с огромным счетом.

    И на хрена мне этого добиваться то? У меня свои "игрушки".
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[21]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 11.04.12 23:06
    Оценка:
    Здравствуйте, VladD2, Вы писали:

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

    VD>Это бессмысленное философствование превращающее в бессмыслицу даже заголовок данной темы.
    Это не философствование, а прямое следствие из самого названия Domain-specific language.

    VD>Ты договорился до того, что ЯОН вообще нет в природе (а он есть (с) анекдот про суслика).

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

    VD>Уровень ЯОН не делает из него более ДСЛ для всех задачей.

    Чего?

    VD>Создание ДСЛ не будет бесплатным никогда! Ни какие N256 не устранят необходимости выделять модель, придумывать язык для ее описания и манипуляций с ней, реализовывать язык и т.п.

    Создание библиотеки не будет бесплатным никогда... и дальше по тексту.

    VD>Все что можно сделать сократить затраты на такую разработку. Но все равно будет сто тысяч задач которые проще решить в лоб, нежели писать для нее ДСЛ в стиле "Решим мне мою проблему".

    Только если домен задачи хорошо ложится на домен языка.
    Если же нет, то получаем от десяти до тысяч раз больше кода, чем необходимо.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[4]: Языки общего назначения не имеют смысла?
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 11.04.12 23:35
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>Соответственно если вдруг ДСЛ окажется полным по Тьюрингу, то он сразу перестает быть ДСЛ?


    Да, если это не следствие побочное эффекта вроде CTE в SQL или частичной специализации шаблонов С++ и если он имеет средства ввода вывода достаточные для решения задач разного рода.

    Ни фига ВБА не ДСЛ. Он от ВБ6 ничем не отличается, кроме библиотеки предоставляемой вордом или экселм.

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

    Иначе Перл тоже ДСЛ. Да и вообще все на свете ДСЛ.

    А на фиг нужен термин не выражающий ничего? Для обозначения понятия язык программирования уже есть термин — язык программирования.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[22]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 11.04.12 23:59
    Оценка: +3
    Здравствуйте, WolfHound, Вы писали:

    WH>Это не философствование, а прямое следствие из самого названия Domain-specific language.


    Название ни разу не является определением.

    VD>>Ты договорился до того, что ЯОН вообще нет в природе (а он есть (с) анекдот про суслика).

    WH>Так у любого языка есть свой домен.

    Ага. Разработка ПО, например. На фиг нужны такие знания?

    WH>Просто домен некоторых языков не ориентирован на решение конкретной проблемы, а создавался для решения любых проблем. Вот это и есть ЯОН.

    WH>Проблема в том, что такие домены плохо подходят для почти всех реальных задач.

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

    В твоем определение термин ДСЛ (ПОЯ) не имеет никаого смысла, так как разные люди под ним будут понимать разные вещи.

    Между ВБА и регексами общего только то, что они оба языки.

    VD>>Уровень ЯОН не делает из него более ДСЛ для всех задачей.

    WH>Чего?

    Того. ДСЛ для арифметики — это строчный калькулятор, а не С++. А язык на котором можно отформатировать винт ни фига не ДСЛ. Он в любой задаче будет скорее вреден.

    Ты пришел объяснять пользу ДСЛ-ей народу, но сам же не можешь объяснить ему, что же такое ДСЛ.

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

    Польза ДСЛ в декларативности описания. Меньше кода, меньше ошибок, больше метаинформации. Польза же от ВБА == нулю. На его месте может быть и C#, и Ява и даже С++. Это ровным счетом ничего не меняет. А раз так, то называя ВБА ДСЛ-ем мы дескредитируем саму идею использования ДСЛ-ей.

    VD>>Создание ДСЛ не будет бесплатным никогда! Ни какие N256 не устранят необходимости выделять модель, придумывать язык для ее описания и манипуляций с ней, реализовывать язык и т.п.

    WH>Создание библиотеки не будет бесплатным никогда... и дальше по тексту.

    Если библиотека решает задачу на достойном уровне, то ДСЛ — оверкил.
    Зачем вводить новый синтаксис для чтения содержимого текстового файла, если это же я могу сделать вызвав библиотечную функцию?

    Смысл в ДСЛ-е появляется тогда, когда библиотечная функция:
    * Не может выразить решение задачи без копипасты и кучи ручного кодирования.
    * Приводит к более медленному решению.
    * Выливается в эмуляцию ДСЛ-я средствами ЯОН.

    В остальных случаях я сам выберу функцию, так как на нее банально уйдет меньше времени.


    VD>>Все что можно сделать сократить затраты на такую разработку. Но все равно будет сто тысяч задач которые проще решить в лоб, нежели писать для нее ДСЛ в стиле "Решим мне мою проблему".


    WH>Только если домен задачи хорошо ложится на домен языка.

    WH>Если же нет, то получаем от десяти до тысяч раз больше кода, чем необходимо.

    Да ты уже немного заколебал этой мантрой для домен языка. Домен любого ЯОН — написание функций. И спопитсот задач может быть отлично выражены в виде функции.

    А вот ДСЛ может быть нежелателен хотя бы потому, что время затраченное на него больше лобового решения. Или его тупо сложно выделить.

    В жизни вообще нет места ультра-максимализму. Любое решение — это компромисс (ваш КО). Выбор ДСЛ-я тоже.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[22]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 12.04.12 02:28
    Оценка: +1
    Здравствуйте, Vain, Вы писали:
    V>Речь то как раз про удобные и несложные средства. SQL на них не тянет, т.к. является таким же тяжёлым языком как языки общего назначения.
    Не понимаю, откуда такой вывод. SQL является удобным и несложным средством описания сложных операций с данными. Если все ваши операции с данными — это локальные load и save, то SQL вам не нужен.
    А если вам нужно посчитать какие-то агрегаты по результату join восьми таблиц, и при этом ещё иметь гарантии ACID, то вручную вы это делать замаетесь.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[10]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 12.04.12 02:30
    Оценка:
    Здравствуйте, alex_public, Вы писали:

    _>Что-то это какой-то уход в мелкие детали. Я бы начал с простой общей вещи. Что в нашем языке есть какое-то отображение понятика контрол — в какой-то объект языка. И эти объекты мы в языке можем создавать и потом вызывать их функции. И отдельно можем вызывать функции "системного" языка. В принципе уже только это позволило бы убрать практически весь код связанный с интерфейсом в наш dsl, оставив системному языку только "движок".

    Непонятно. На каком языке написаны "функции контролов", и чем он отличается от системного языка?
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[20]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 12.04.12 02:40
    Оценка:
    Здравствуйте, alex_public, Вы писали:

    _>Ммм, ну да, должен признать что регулярно вижу диффы этих файлов в Mercurial и по ним даже можно понять что поменяли люди. Но я как-то никогда не воспринимал это как существенное преимущество. ) И слияние на таком файле автоматике старались никогда не доверять. )))

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

    _>Ммм, ну это скорее задано самим фреймворком, под который генерируется код, а не авторами редактора.

    Я не видел ваш редактор. Но во всех, которые я видел, синтаксис по факту присутствует.
    _>Вообще к чему это всё я говорю. Вот я смотрю на этот редактор и в общем не вижу никаких проблем написать самому такой же вообще практические не думая. Т.е. тупо "закодить". А вот если бы я захотел придумать некий язык, по которому потом генерировался тот же код, то я бы с самого начала начал задумываться над всякими нюансами. Причём не обязательно какими-то "высоконаучными", а возможно просто стилевыми. Например использовать мне в моём dsl {} или begin/end? Я не говорю что это что-то дико сложное, но всё же время отнимает. А в случае с редактором ничего такого нет — тупо закодить визуальный редактор плюс набор шаблонов кода под контролы.
    Я думаю, это оттого, что у вас визуальный редактор с некоторым синтаксисом уже перед глазами. Выбрав, скажем, в качестве синтаксиса языка JSON, тоже можно "тупо закодить" и ни о чём не думать.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[11]: Языки общего назначения не имеют смысла!
    От: alex_public  
    Дата: 12.04.12 03:46
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>Непонятно. На каком языке написаны "функции контролов", и чем он отличается от системного языка?


    Функции контролов (типа показать/скрыть окно и т.п.), как и сам набор базовых контролов "даны в язык богом", но их можно расширять из системного языка. Всё это для того, что бы как писал Влад сократить возможности и упростить. Причём упростить до такого уровня, что бы оно нормально интегрировалось в язык размётки.

    Попробую привести совсем упрощённый пример идеи. В стилистике Питона:
    form Main
        title "Main"
        button Calc
            title "Calc"
            onclick [Calculate]
        button About
            title "About"
            onclick About.ModalShow
    form About
        title "About"
        button OK
            title "OK"
            onclick this.Close

    Это у нас будет файла нашего dsl. Компилируем его допустим в C++ h файл. И потом у нас останется написать реализацию функции Main::Calculate() на C++ в cpp файле и собрать итоговую программу.

    P.S. Всё это придумал буквально 10 минут назад и вообще dsl строение не специалист, так что сильно не ругаете пример — это просто попытка подумать в сторону удобного gui dsl, отделяющего интерфейс программы от "движка".
    Re[21]: Языки общего назначения не имеют смысла!
    От: alex_public  
    Дата: 12.04.12 03:48
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>Я думаю, это оттого, что у вас визуальный редактор с некоторым синтаксисом уже перед глазами. Выбрав, скажем, в качестве синтаксиса языка JSON, тоже можно "тупо закодить" и ни о чём не думать.


    Да, если в качестве языка своего dsl подходит какое-то подмножество готового продуманного языка, то действительно уже можно просто "закодить". ) Но что-то мне кажется это далеко не всегда так.
    Re[7]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 12.04.12 04:39
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>Вот ты, например даже не задумаешься о том, что можно сделать ДСЛ.

    WH>И в институтах этому не учат.

    Вообще-то учат, как минимум на специальностях 2201 и 2202.

    WH>И вообще распространяют миф, что это что-то очень сложное.


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

    WH>А почему программы плохо проектируют?

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

    ИМХО, SELECT оператор SQL спроектирован превосходно, т.к. обладает реляционной полнотой и при этом отличной читабельностью. И да, SQL-ем после некоторого навыка может пользоваться даже не программист. И его разрабатывали не с потолка, это был результат обобщения многолетнего опыта разработки и эксплуатации первой промышленной БД.


    WH>Причем недостаток знаний фундаментальная проблема. Ибо часто пока не сделаешь хоть что-то, не поймёшь что действительно нужно.


    Знания тут не при чем. Это такой популярный алгоритм независимо от кол-ва знаний. Действительно, тенденция сравнивать, проверять, расчитывать и т.д. за последние лет 15 куда-то ушла. Не модно. Потому что "мощщи компов все проглотят" и прочая ересь, идущая с сегмента заказухи... которой постепенно заражалась вся индустрия.

    ИМХО, это хорошо, что последние годы в кремнии встряли, т.е. не ожидается такого роста быстродействия... Уже пошел процесс очищения "общественного мнения" от всей этой шелухи.


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

    G>>Это технически невозможно, сервер на другом компе стоит, порты закрыты.
    WH>И это человек обвиняет меня в уходе от вопросов.

    Для некоторых нужд я бы променял. Только не по физической структуре, а по некоторому АПИ итерирования по данным. Из-за того, что сложные вычисления на SQL не айс, т.к. интерпретатор. А преобразовать реляционные исчисления в реляционные уравнения — не бог весть какая наука. Но это 5% сценариев от силы, т.е. в общем случае таки да, SQL рулит.

    WH>Есть два десятка цветовых пространств и нужно сгенерировать код по трансформации из каждого в каждое.

    WH>Вперед. Покажи, как паттерны решат эту задачу.

    Там точно DSL нужен, а не таблицы составляющих и коэффициентов?


    WH>Критерий реальности в студию.


    Ну таки даже по результатам презентации по ссылке хотелось бы увидеть что-нить на входе и что-нить на выходе.
    Re[7]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 12.04.12 04:45
    Оценка:
    Здравствуйте, Gaperton, Вы писали:

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


    Почти 20.
    Встроенный язык для проводок и отчетов появился в 5-ке.
    Re[10]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 12.04.12 04:48
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    G>>Воспоминания, очевидно, ложные. По всем понятиям он никак не общего назначения.

    WH>Ну, тогда тебе не составит труда сказать, что же там такого предметно ориентированного.

    Доступ к экземплярам прикладных сущностей, к регистрам, к временн`ым значениям и т.д. Вполне предметно-ориентировано.
    Re[14]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 12.04.12 04:52
    Оценка:
    Здравствуйте, Andrei N.Sobchuck, Вы писали:

    ANS>О. Если каждую объектную систему называть DSL, то получится, что каждая программа на ООП языке состоит из множества DSL. Но нормальные люди называют это классами и пакетами.


    Какие еще классы и пакеты? Тебя синтаксис языка в заблуждение ввел, похоже.
    Re[18]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 12.04.12 05:01
    Оценка: -1
    Здравствуйте, Andrei N.Sobchuck, Вы писали:

    ANS>При этом в основной массе, когда описывают что такое внутренний DSL, отдельно отмечают, что Word+VB это не DSL для обрабтки документов, а скриптовый язык.


    Обычно хост скрипта поставляет в его систему глобально-доступные типы и ф-ии. Т.е. если сам язык не умеет создавать/подключать готовые модули и нет встроенных ср-в ввода/вывода, то вот тебе классический императивный-DSL. ИМХО, наличие операторов присваивания, арифметических операторов и способа объявления и вызова ф-ий не делает некий скриптовый язык языком общего назначения без существования в нем встроенных ср-в, позволяющих решать на нем те самые задачи общего назначения. Т.е. он может стать языком общего назначения, только если хост ему предоставит всю необходимую функциональность.
    Re[3]: Языки общего назначения не имеют смысла?
    От: netch80 Украина http://netch80.dreamwidth.org/
    Дата: 12.04.12 06:04
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    N>>Некоторые тезисы к обсуждению...


    VD>Буду краток — полный бред.


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

    Но, с другой стороны, я не соглашусь с твоей оценкой их как бреда.

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


    Конечно, написать вместо трёх страниц три предложения — это архикруто. Странно, что ты их ещё не строишь в стиле WolfHound'а.
    Мне бы хотелось увидеть критику попунктно и по существу. Пока что я не увидел ни одного опровержения тезису, что в формировании DSL ограничения не менее важны, чем упрощения и адаптации. Более того, они являются одним и тем же, и это ты тоже не опроверг.

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

    VD> Выводы в конце вообще из пальца высосаны. За одно к "немерлистам" записал пол форума.


    Нет, только двоих общеизвестных участников.

    VD> Синклер такой прям рьяный немерлист .


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

    VD>Но пока читал все это сформулировал для себя очень простой критерий выявления ДСЛ-ей. ДСЛ не позволяет воспроизвети себя же, если это не ДСЛ описания компилятора.


    VD>На то она и предметная область, чтобы решать только ее задачу. Если ДСЛ позволяет (пусть криво или медленно) воспроизвести себя, то это ЯОН (язык общего назначения). А его уровень не имеет никакого отношения к ДСЛ-ности.


    Это уже раскритиковали, могу только согласиться с твоими оппонентами.
    The God is real, unless declared integer.
    Re[16]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 12.04.12 06:13
    Оценка:
    Здравствуйте, gandjustas, Вы писали:


    AVK>>Доказать, что менее мощный язык означает, что для достижения того же результата надо больше писать.

    G>Тогда давай формализуем понятие мощности.

    Давно уже. Мощность некоторого языка — это мощность мн-ва допустимых цепочек.

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


    Отсебятина из-за непонимания. кол-во писанины зависит исключительно от соотношения встроенных в язык/библиотеки ср-в и потребностей в них для конкретной задачи. В DSL это соотношение гораздо лучше для конкретного класса задач. Но это только первая их роль, на которую могут тянуть даже eDSL. Вторая роль DSL — это заведомое ограничение языка для ограничения класса решаемых задач, чтобы многократно уменьшить поле для ошибок. Здесь eDSL уже не катят.
    Re[17]: Языки общего назначения не имеют смысла!
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 12.04.12 06:23
    Оценка:
    Здравствуйте, vdimas, Вы писали:

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



    AVK>>>Доказать, что менее мощный язык означает, что для достижения того же результата надо больше писать.

    G>>Тогда давай формализуем понятие мощности.

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


    Это мощность парсера. А еще семантика этих цепочек есть.

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


    V>Отсебятина из-за непонимания. кол-во писанины зависит исключительно от соотношения встроенных в язык/библиотеки ср-в и потребностей в них для конкретной задачи. В DSL это соотношение гораздо лучше для конкретного класса задач.

    Так это и есть та мощность языка, которую имеет смысл тут рассматривать.
    Re[19]: Языки общего назначения не имеют смысла!
    От: Andrei N.Sobchuck Украина www.smalltalk.ru
    Дата: 12.04.12 06:25
    Оценка: +2
    Здравствуйте, vdimas, Вы писали:

    V>Обычно хост скрипта поставляет в его систему глобально-доступные типы и ф-ии. Т.е. если сам язык не умеет создавать/подключать готовые модули и нет встроенных ср-в ввода/вывода, то вот тебе классический императивный-DSL. ИМХО, наличие операторов присваивания, арифметических операторов и способа объявления и вызова ф-ий не делает некий скриптовый язык языком общего назначения без существования в нем встроенных ср-в, позволяющих решать на нем те самые задачи общего назначения. Т.е. он может стать языком общего назначения, только если хост ему предоставит всю необходимую функциональность.


    Тот же Word+VB умеет работать с COM. Чем это отличается от С с библиотеками? А то получается, что С без библиотек это DSL, а с — нет.
    Я ненавижу Hibernate
    Автор: Andrei N.Sobchuck
    Дата: 08.01.08
    !
    Re[15]: Языки общего назначения не имеют смысла!
    От: Andrei N.Sobchuck Украина www.smalltalk.ru
    Дата: 12.04.12 06:33
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    V>Здравствуйте, Andrei N.Sobchuck, Вы писали:


    ANS>>О. Если каждую объектную систему называть DSL, то получится, что каждая программа на ООП языке состоит из множества DSL. Но нормальные люди называют это классами и пакетами.


    V>Какие еще классы и пакеты?


    Я к тому, что наличие "встроенного" класса "Документы" ничем таким не отличается от класса "Документы" в Java/C#, чтобы язык со встроенным классом стал DSL. Отдельное подмножество встроенных классов и методов можно считать внутренним DSL.

    V>Тебя синтаксис языка в заблуждение ввел, похоже.


    DSL нужен человеку -> вся суть DSL в синтаксисе (а если не вся, то 80% точно, т.е. таки вся).
    Я ненавижу Hibernate
    Автор: Andrei N.Sobchuck
    Дата: 08.01.08
    !
    Re[20]: Языки общего назначения не имеют смысла!
    От: Andrei N.Sobchuck Украина www.smalltalk.ru
    Дата: 12.04.12 06:39
    Оценка: -2
    Здравствуйте, Sinclair, Вы писали:

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


    Но там есть подзапросы. Остальное, имхо
    Автор: Andrei N.Sobchuck
    Дата: 24.01.08
    , это просто синтаксический сахар.
    Я ненавижу Hibernate
    Автор: Andrei N.Sobchuck
    Дата: 08.01.08
    !
    Re[6]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 12.04.12 06:43
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    G>Решает задачи не только учета, а потенциально любые.


    Угу, любой язык, который содержит арифметические выражения и условные операторы решает потенциально любые задачи.
    Нормальный такой способ спорить через неоспоримые банальности.
    Re[7]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 12.04.12 07:00
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>В нем не эффективные алогоритмы.


    Там нет никаких алгоритмов. Вообще. Просто способ декларативной комбинации функторов.

    VD>Как только горамматика выходит за LL(1) производительность парсера резко падает. Вплоть до экспоненты.


    Дык, на то они и комбинаторные парсеры, что УГ полное. И они должны заметно сливать даже на LL(1) в сравнении с табличной реализацией. Чем "шире" набор правил на каждом уровне, тем в большее число раз должны сливать. Потому что комбинаторные парсеры — это тупой рекурсивный спуск с перебором.

    VD>Но в любом случае его скорость в простых случаях обусловлена (в немалой мере) тем, что он использует генерацию кода по модели.


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

    VD>Подход Немерла и N2 позволяет куда больше чем С++-ное метапрограммирование на шаблонах (использованное в бусте). Потому позволяет добиться лучшей скорости.


    ХЗ. Сколько раз не меряли — табличные лексеры и парсеры работают фактически с той же скоростью, что построенные на if/switch/case. При том, что последние требуют кодогенерации ("Подход Немерла" (С)), а первые — нет.
    Re[16]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 12.04.12 07:12
    Оценка:
    Здравствуйте, alex_public, Вы писали:

    _>Более того, у него даже есть свой отдельный формат для хранения "нарисованного" gui. Я в него как-то заглянул ради интереса — там некий дичайший xml. Так что формально можно даже текстовый dsl найти тут. Но речь то не об этом... Речь о том, что если поменять этот формат на любой другой (бинарный например), то абсолютно ничего в процессе разработки не изменится — люди никогда не видят его. Так можем ли мы называть это DSL, если люди с этим не работают никогда и от его реализации не зависит вообще ничего?


    Можем. Большинство популярных DSL на сегодня — именно графические DSL, либо текстово-графические, например Mathcad.

    Тебя же не смущает, что в аббревиатуре UML последняя буква означает Language?
    Re[9]: Языки общего назначения не имеют смысла!
    От: Andrei N.Sobchuck Украина www.smalltalk.ru
    Дата: 12.04.12 07:29
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

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


    Кстати, в Tweak который делали для Croquet предлагали такое:
    onMouseDown
      | oldColor |
      <on: mouseDown>
      oldColor := color.
      color := Color yellow.
      self waitUntil: #mouseUp.
      color := oldColor.


    Каждое событие обрабатывается в своём треде. "self waitUntil: #mouseUp" — блокирует тред.
    Я ненавижу Hibernate
    Автор: Andrei N.Sobchuck
    Дата: 08.01.08
    !
    Re[23]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 12.04.12 07:37
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    WH>>Так у любого языка есть свой домен.

    VD>Ага. Разработка ПО, например. На фиг нужны такие знания?
    Это и есть ЯОН.

    VD>Проблема в том, что ты не понимаешь важности четкого определения терминов. Философия ни разу не помогла объяснить людям что-то. Она только путает.

    Понимаю.
    Но твое определение очень плохое.
    Там вообще не ясно, что к чему.
    У тебя получается, что полные по Тьюрингу языки все ЯОН. Но по некоторым мутным причинам ты некоторые полные по Тьюрингу языки записываешь в ДСЛ.

    VD>Если библиотека решает задачу на достойном уровне, то ДСЛ — оверкил.

    Если ДСЛ создать проще чем библиотеку то нет.

    VD>Зачем не вводить новый синтаксис для чтения содержимого текстового файла, если это же я могу сделать вызвав библиотечную функцию?

    О. Тут очень сильно от того что там происходит.

    VD>Да ты уже немного заколебал этой мантрой для домен языка. Домен любого ЯОН — написание функций. И спопитсот задач может быть отлично выражены в виде функции.

    Вот их можно решать ЯОНом.
    Если задача не может быть качественно представлена функциями, то ее нельзя решать этим ЯОНом.
    Это все что я пытаюсь сказать.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[21]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 12.04.12 07:57
    Оценка: +4
    Здравствуйте, Andrei N.Sobchuck, Вы писали:

    ANS>Но там есть подзапросы. Остальное, имхо
    Автор: Andrei N.Sobchuck
    Дата: 24.01.08
    , это просто синтаксический сахар.

    Нет. Уберите из C понятие вызова функции и вы увидите, какой получился копец.
    Вызов — это нифига не синтаксический сахар для "встраивания" кода самой функции по месту вызова.

    Вот, к примеру, чего нельзя сделать в SQL:
    public IQueryable<Customer> SearchCustomer(IQueryable<customer> source, Predicate<string> searchCondition)
    {
      return 
        from c in source
        where searchCondition(c.FirstName) 
          || searchCondition(c.LastName)
          || searchCondition(c.CompanyName)
          || searchCondition(c.Description)
        select c;
    }


    Если бы это было разрешено, то можно было бы писать потом такие запросы:
    select * from SearchCustomer(customers, t like '%Armstrong%') order by FirstName


    Вот чего нельзя сделать в SQL:
    public IQueryable<T> SearchPerson<T>(IQueryable<T> source, string searchText) 
      where T: IPerson
    {
       from p in source 
         where p.FirstName.Contains(searchText)
           || p.LastName.Contains(searchText)
         select p;
    }

    Если бы это было разрешено, то можно было бы писать потом такие запросы:

    select FirstName, LastName from SearchPerson(Employees, 'John') 
    union all
    select FirstName, LastName from SearchPerson(Customers, 'John')
    union all
    select FirstName, LastName from SearchPerson(Contacts, 'John')


    Откуда, вы думаете, берутся шестистраничные запросы на SQL? Да ровно оттуда же: нет никаких возможностей по декомпозиции. Приходится всё писать в теле запроса.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[20]: Языки общего назначения не имеют смысла!
    От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
    Дата: 12.04.12 08:07
    Оценка:
    Здравствуйте, Sinclair, Вы писали:


    S>Во-вторых, всё же всё не настолько плохо, как вы говорите. В новом SQL есть with как способ введения "табличной переменной".

    Это с чего это ты на Вы перешел. Я чем то обидел?
    Ну я в 1С к сожалению не могу использовать все вкусности, только для прямых запросов. Насчет with спасибо. Уже начал смотреть. Но все равно SQL во многом сливает Linq, а в линке отсутствует куча возможностей SQL.
    Это к тому, что так легко создавать ДСЛ. Это по сути единственная ДСЛ которая мне нужна
    и солнце б утром не вставало, когда бы не было меня
    Re[8]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 12.04.12 08:15
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    WH>>Вот ты, например даже не задумаешься о том, что можно сделать ДСЛ.

    WH>>И в институтах этому не учат.
    V>Вообще-то учат, как минимум на специальностях 2201 и 2202.
    Так учат что у людей после этого и мыслей о ДСЛ не возникает.

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

    Меньшинство? Фигасе. Да их тут армия.

    V>ИМХО, SELECT оператор SQL спроектирован превосходно, т.к. обладает реляционной полнотой и при этом отличной читабельностью. И да, SQL-ем после некоторого навыка может пользоваться даже не программист. И его разрабатывали не с потолка, это был результат обобщения многолетнего опыта разработки и эксплуатации первой промышленной БД.

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

    WH>>Причем недостаток знаний фундаментальная проблема. Ибо часто пока не сделаешь хоть что-то, не поймёшь что действительно нужно.

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

    V>Для некоторых нужд я бы променял. Только не по физической структуре, а по некоторому АПИ итерирования по данным. Из-за того, что сложные вычисления на SQL не айс, т.к. интерпретатор. А преобразовать реляционные исчисления в реляционные уравнения — не бог весть какая наука. Но это 5% сценариев от силы, т.е. в общем случае таки да, SQL рулит.

    А если тебе дать компилируемый, статически типизированный SQL имеющий средства декомпозиции запросов?
    Это ведь не так сложно.

    WH>>Есть два десятка цветовых пространств и нужно сгенерировать код по трансформации из каждого в каждое.

    V>Там точно DSL нужен, а не таблицы составляющих и коэффициентов?
    Таблицами тут не поможешь. Ибо есть куча цветовых пространств преобразования, между которыми очень не линейны. Да хотябы RGB и sRGB. sRGB хорош для восприятия человеком. Но при попытке, например, отмасштабировать в картинку в этом цветовом пространстве появляется куча артефактов. Поэтому нужно переводить в RGB, масштабировать и переводить обратно. Если в картинке есть альфа-канал то там нужно еще кое что сделать. Иначе опять артефакты лезут.
    Ну и не нужно забывать, что их у меня было 22 (точно не помню) писать 484 преобразования руками, мягко говоря, не хотелось. Так что я задал только несколько преобразований и по определенным правилам сгенерировал все остальные.
    Посмотрел что получилось. И добавил еще несколько преобразований, чтобы углы срезать. И так несколько итераций.
    А потом еще цветовые пространства появились.
    Без ДСЛ я бы это не осилил.

    Причем ДСЛ был очень циничен. Сами цветовые пространства описывались отдельным язычком. Но вот преобразования прямо в коде на С++.
    После чего я пробегался по исходнику и собирал список базовых преобразований.

    V>Ну таки даже по результатам презентации по ссылке хотелось бы увидеть что-нить на входе и что-нить на выходе.

    На входе программа. На выходе проезды по памяти, race condition'ы и тп. И все на основе статического анализа. Причем почти без ложных срабатываний.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[9]: Языки общего назначения не имеют смысла!
    От: Cyberax Марс  
    Дата: 12.04.12 08:21
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>Без ДСЛ я бы это не осилил.

    Ум. А преобразования в виде графа фильтров? Типа как в GEGL?
    Sapienti sat!
    Re[10]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 12.04.12 08:30
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    WH>>Без ДСЛ я бы это не осилил.

    C>Ум. А преобразования в виде графа фильтров? Типа как в GEGL?
    Мне лень разбираться (я картинками уже не занимаюсь) но похоже идея у нас одна.
    Только я всю работу проделал во время компиляции.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[22]: Языки общего назначения не имеют смысла!
    От: Andrei N.Sobchuck Украина www.smalltalk.ru
    Дата: 12.04.12 08:35
    Оценка:
    Здравствуйте, Sinclair, Вы писали:


    S>
    S>select FirstName, LastName from SearchPerson(Employees, 'John') 
    S>


    Имя таблицы захардкожено. Всё таки, это просто синтаксический сахар.
    А вот то, что нельзя так сделать:
    select 
      t.FirstName, 
      t.LastName, 
      (SELECT COUNT(*) FROM t.extended WHERE e.phone = t.phone) 
    from aTable t

    это ты прав.
    Я ненавижу Hibernate
    Автор: Andrei N.Sobchuck
    Дата: 08.01.08
    !
    Re[11]: Языки общего назначения не имеют смысла!
    От: Cyberax Марс  
    Дата: 12.04.12 08:42
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>>>Без ДСЛ я бы это не осилил.

    C>>Ум. А преобразования в виде графа фильтров? Типа как в GEGL?
    WH>Мне лень разбираться (я картинками уже не занимаюсь) но похоже идея у нас одна.
    WH>Только я всю работу проделал во время компиляции.
    Плюс может быть в скорости работы (впрочем, непонятно насколько большой). Минус — в меньшей гибкости.
    Sapienti sat!
    Re[20]: Языки общего назначения не имеют смысла!
    От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
    Дата: 12.04.12 08:44
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>Во-вторых, всё же всё не настолько плохо, как вы говорите. В новом SQL есть with как способ введения "табличной переменной".

    Ты про CTE? Да вкусная вещь , особенно её рекурсивное использование. а вот её то в 1С нет. Частично приходится писать в темповые таблицы
    Но там вроде есть ограничения использования только к одному запросу. А вомножестве нужно применение к пакету.
    и солнце б утром не вставало, когда бы не было меня
    Re[22]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 12.04.12 08:54
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>
    S>select FirstName, LastName from SearchPerson(Employees, 'John') 
    S>union all
    S>select FirstName, LastName from SearchPerson(Customers, 'John')
    S>union all
    S>select FirstName, LastName from SearchPerson(Contacts, 'John')
    S>

    На самом деле это тоже криво.
    У тебя, по сути, меняются только имена таблиц.
    Хороший язык должен иметь возможность свести это к чему-то типа такого.
    [Employees, Customers, Contacts].Map(SearchPerson(_, 'John')).UnionAll().Select(FirstName, LastName);
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[12]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 12.04.12 08:58
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>Плюс может быть в скорости работы (впрочем, непонятно насколько большой). Минус — в меньшей гибкости.

    Мне гибкость была не нужна. А я не делаю больше чем необходимо. Ибо это глупо.
    А вот производительность значение имела.
    Так что я просто не стал думать о более гибких и менее производительных решениях.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[17]: Языки общего назначения не имеют смысла!
    От: alex_public  
    Дата: 12.04.12 09:09
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    V>Можем. Большинство популярных DSL на сегодня — именно графические DSL, либо текстово-графические, например Mathcad.


    V>Тебя же не смущает, что в аббревиатуре UML последняя буква означает Language?


    Хгм, тут речь шла именно о формате данных, в котором редактор сохраняет данные на диск. Т.е. то что сам редактор является своеобразным графическим DSL я с самого начала не сомневался (хотя слово language тут конечно несколько сомнительно, но это мелочи). Весь вопрос был в том, задаётся ли этот самый язык неким эфемерным способом через набор контролов, которыми манипулируют. Или же мы можем просто формально считать обычным текстовым dsl'ом тот самый формат, в котором нарисованный интерфейс сохраняется на диск?

    Вот тут у меня и Sinclair мнения и разошлись. Но я не думаю что эту мелочь имеет смысл особо долго обсуждать — это скорее просто вопрос терминологии, что считать dsl, а что нет.
    Re[17]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 12.04.12 09:12
    Оценка:
    Здравствуйте, netch80, Вы писали:

    O>> куда как более матанистые.


    N>Они менее матанистые, в тех пределах, в которых их обожают. Потому что описать как "любая хрень от 5 до 12 цифр, за которой до трёх букв" проще, чем грамматику. 90% из них скончается в моральном плане на первом же shift/reduce конфликте, не поняв, как эту грамматику правильно вывернуть.


    А не надо описывать грамматики с конфликтами. Не надо пользоваться всякими устарелыми LALR — есть прекрасный, человечный, понятный интуитивно LL(n), выразимый множеством простых и естественных способов, включая и ad hoc рекурсивный рукописный код. И вот это как раз намного прозрачнее и намного менее матанисто чем даже самый простой регвыр.

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


    Вот честно — никогда этой самой теорией не владел, забыл все сразу за ненадобностью. А парсеры писать умудряюсь. Да, парсер какого либо хитровыгнутого языка вроде C++ я бы с ходу не написал, ну так надо быть садистом и мизантропом чтобы для DSL такой синтаксис выдумывать. Если синтаксис DSL не ложится на LL(1), то синтаксис плохой.
    Re[5]: Языки общего назначения не имеют смысла?
    От: vdimas Россия  
    Дата: 12.04.12 09:19
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    WH>>Соответственно если вдруг ДСЛ окажется полным по Тьюрингу, то он сразу перестает быть ДСЛ?


    VD>Да, если это не следствие побочное эффекта вроде CTE в SQL или частичной специализации шаблонов С++ и если он имеет средства ввода вывода достаточные для решения задач разного рода.


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


    VD>Ни фига ВБА не ДСЛ. Он от ВБ6 ничем не отличается, кроме библиотеки предоставляемой вордом или экселм.


    Если бы не возможность произвольного импорта внешних модулей в VBA, или не поданная хостом ф-ия CreateObject, позволяющая создать любой COM-объект, то был бы вполне себе DSL.


    VD>Иначе Перл тоже ДСЛ. Да и вообще все на свете ДСЛ.


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


    VD>А на фиг нужен термин не выражающий ничего? Для обозначения понятия язык программирования уже есть термин — язык программирования.


    Он и есть язык программирования. Только domain-specific, то бишь специально заточенный на узкую область. Как JS в браузере, после того, как в него DOM страницы подали.
    Re[6]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 12.04.12 09:20
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    G>>>Покажи на примере чтоли?

    O>> Давайте задачу — покажу, как хреноватый кодер (я, то есть), не приходя в сознание под эту задачу dsl делает.
    G>Я уже говорил — разработка сайтов.

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

    O>>>> PHP. Серьезно.

    G>>>PHP — язык общего назначения.
    O>> А мы теперь только не-Тьюринг-полные языки будем за dsl считать? Я так не играю.
    G>Я таки думаю что за DSL нужно считать именно domain-specific.

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

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


    Ну вот в PHP это языковое средство — это
    <?php ... >


    В языках "общего назначения" такого нет, хоть и можно прикрутить внешним препроцессором (как в ASP.NET или JSP). И тогда язык "общего назначения" становится шаблонным DSL.

    G>В PHP нету ничего специального для работы с HTML или HTTP.


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

    G> А вот если razor взять, то очень даже есть. Поэтому первый — яон, а второй DSL.


    Оба DSL, поскольку оба созданы специально для решения конкретной задачи, а не как "общие".
    Re[13]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 12.04.12 09:41
    Оценка: +2
    Все же прокомментирую, хоть и не собирался.

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

    G>Сама цель создания DSL подразумевает, что для решения задач через него должна требоваться квалификация, на порядок меньшая, чем обычного программиста. Ибо программист справится и с обычным языком общего назначения. Ибо не дурак.


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

    DSL это самый мощный из известных способов упрощения решения сложных задач и избавления от копипасты. Не ООПы всякие и прочая расфуфыренная ентерпрайзная ерунда, а именно DSL. И, поскольку программисты (некоторые) не всегда дураки, они и не станут решать задачи на языках "общего назначения" — они будут делать под каждую маленькую задачу маленький DSL, возможно, поверх языка "общего назначения", а не городить тонны плохого boilerplate-кода.

    Посмотрите, например, на исходный код LLVM — там этих DSLей довольно много, в том числе и очевидные внешние DSL (TableGen, на самом деле это даже не один язык а целая их коллекция). И они не для "программистов с на порядок меньшей квалификацией" сделаны, а для самих разработчиков LLVM, которые, полагаю, профессиональнее нас всех вместе взятых. Просто глупо это, правила instruction scheduling писать на "языке общего назначения", очень много однотипного табличного кода получится. А вот сгенерить этот код из полудекларативного описания — легче легкого. В результате добавление поддержки новых архитектур в LLVM становится тривиальной задачей. Если бы они еще и осилили DSL для упрощения pattern matching в C++ сделать, то избавились бы и от многокилометровых лесенок из if-ов (например, в instcombine pass), но тут скорее не на разработчиках вина, а на недостатках языка C++.

    Про gcc и говорить не буду, там просто Лисп внутри, а на Лисп у здешней публики, как я уже догадался, сильнейшая аллергия.

    G>Еще один пример из обыденной практики — использование LUA для написания скриптов AI в играх. Их пишут не программисты.


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

    G>Еще примеры? Системы компьютерной алгебры. Maltab. Maple. Автокад, который перешел с автолиспа на VBA. Язык TradingStation для описания торговых роботов.


    Самая популярная такая система — Matematica. У меня язык не повернется сравнивать ее семантику с бейсиком, хотя пользуются Математикой далеко не программисты. Это функциональный язык, построенный на правилах переписывания, ни разу не бейсик.

    R — тоже функциональщина, и тоже очень популярен среди не-программистов. Бейсиком там и не пахнет.

    G>И это закономерно, что базовая семантика этих языков тупа до безобразия.


    "Базовая" семантика не обязана быть тупой. Главное, чтобы язык предоставлял тупой и очевидный синтаксический сахар, прячущий всю эту семантику вглубине.

    Некоторые по этому пути вообще очень далеко зашли. В системе Stata по сути два языка — один, внешний — для конечных пользователей, финансистов там всяких, которые программированием заниматься вообще не должны, и второй (в который первый язык тупо транслируется) для "power users".

    G> Про DSL, в основе которых матан, мы просто не знаем, по вполне понятной причине — они нехрен никому не нужны.


    Про Mathematica знает намного больше людей, чем про Lua. А уж матана там хватило бы на зверское убиение трех курсов физтеха.
    Re[14]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 12.04.12 09:43
    Оценка:
    Здравствуйте, netch80, Вы писали:

    N>Добавлю только, что само понятие "языка" с чёткими требованиями к синтаксису может быть чрезмерным для тех, кто пишет на DSL. Поэтому вопроса развиваются графические представления — для тех случаев, где они достаточны, и в них соблюдение синтаксических норм достигается само собой.


    А вот на этом пути надо не перегибать палку. В некоторых промышленных CAD-ах так старались добиться "нечеткого" и "естественного" синтаксиса, что получились языки с тысячами ключевых слов и десятитомными документациями.
    Re[5]: Просто мысль...
    От: oldjackal Россия  
    Дата: 12.04.12 09:44
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    W>>То-то же N так и не разродился промышленным компилятором...

    WH>Так это по тому, что при его реализации не использованы ДСЛ.

    И не сможете их использовать как следует до тех пор, пока для каждого макроса нужно отдельную DLL делать. Не получатся многоуровневые макроопределения (т.е., макросы, раскрывающиеся в определения макросов, которые тут же и используются). Учитесь у common lisp.
    Re[16]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 12.04.12 09:48
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>Вот только он не это сказал.

    WH>Он сказал, что ДСЛ нужны только не программистам и в основе полезных ДСЛ нет матана.
    WH>Читай то, что написано, а не то, что ты хочешь прочитать.

    Да, мне раза три перечитать пришлось. Вижу, что был не прав.
    Re[6]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 12.04.12 09:58
    Оценка: 99 (2)
    Здравствуйте, WolfHound, Вы писали:

    O>>Кстати, почему не packrat? Он туп как пробка, и тем прекрасен?

    WH>1)Не смотря на линейность, он жуткий тормоз.

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

    WH>2)Задолбаешься задавать приоритеты операторам. А ассоциативность ПЕГ вообще не может.


    Как это не может? Как это задолбаюсь?

     term = fact '+' term / fact '-' term / fact;
     fact = atom '*' fact / atom '/' fact / atom;


    Приоритеты очевидны, никто не задолбался. Ассоциативность получаем, если добавим левую рекурсию (http://www.vpri.org/pdf/tr2007002_packrat.pdf)

    WH>3)У ПЕГ есть проблема с приоритетным выбором. Его очень сложно использовать.


    Как раз наоборот! Приоритетный выбор очевиден для простого смертного, не испорченного yacc-ами. А вот BNF как раз неочевиден и рождает неоднозначные конфликты.

    WH>4)ПЕГ в чистом виде не поддерживает изменение грамматики во время разбора.


    Это крайне легко исправляется, как раз в силу вашего следующего пункта:

    WH>5)У ПЕГ низкая декларативность. Фактически приходится описывать алгоритм разбора.


    И это прекрасно! Для не испорченных теорией программистов, каких большинство, это как раз наилучший баланс. Это как раз тот случай, когда полезно понимать, что за код генерится, и иметь возможность в любой момент откатиться на уровень ниже и что-то там недекларативное сделать. Как результат — получаем сколь угодно умные и уместные сообщения об ошибках, получаем возможность делать грязные хаки для грамматик вроде C++, и много чего еще. С чисто декларативными yacc-ами такой фокус не пройдет.

    WH>Поэтому был разработан новый алгоритм. За основу были взяты PEG и Pratt parser.


    И отброшена мемоизация? Зря. Для того же syntax highlighting и для реализации левой рекурсии это мощнейшая штука.

    WH>Ну да. Парсер должен описываться очень просто.

    WH>Но современные инструменты не адекватны.

    У меня не бывает проблем даже при написании парсеров на примитивных низкоуровневых языках вроде C. Где там неадекватность-то?

    WH>На том же ПЕГ это сделать очень не просто. Особенно если у тебя есть несколько операторов с разными приоритетами и ассоциативностью.


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

    O>>Сейчас даже на голом шарпе без сторонних библиотек dslы делать легко и приятно. Да что там, я их когда-то и на Фортране писал не включая мозга.

    WH>Какие ДСЛи?

    Языки запросов, конфигурации (Тьюринг-полные, увы, не моя вина), внутренние языки для представления данных, и много чего еще.
    Re[21]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 12.04.12 10:05
    Оценка: +1 -1
    Здравствуйте, VladD2, Вы писали:
    VD>Создание ДСЛ не будет бесплатным никогда! Ни какие N256 не устранят необходимости выделять модель, придумывать язык для ее описания и манипуляций с ней, реализовывать язык и т.п.

    Решение любой задачи вообще всегда сводится к созданию языка. Всегда. Достаточно заметить этот факт, и дальше все становится просто.

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

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

    VD>Все что можно сделать сократить затраты на такую разработку. Но все равно будет сто тысяч задач которые проще решить в лоб, нежели писать для нее ДСЛ в стиле "Решим мне мою проблему".


    Решение "в лоб" тоже всегда сводится к созданию языка. Просто в большинстве случаев это недостаточно очевидно, и если узко мыслить в терминах существующих языков то можно не заметиь, что родился новый язык.
    Re[17]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 12.04.12 10:12
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    WH>>Вот только он не это сказал.

    WH>>Он сказал, что ДСЛ нужны только не программистам и в основе полезных ДСЛ нет матана.
    WH>>Читай то, что написано, а не то, что ты хочешь прочитать.
    O> Да, мне раза три перечитать пришлось. Вижу, что был не прав.
    В этом и есть единственный талант данного персонажа.
    Он умеет говорить бред, так что у окружающих создается впечатление, что он сказал что-то умное.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[23]: Языки общего назначения не имеют смысла!
    От: Vain Россия google.ru
    Дата: 12.04.12 10:18
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

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

    S>Не понимаю, откуда такой вывод. SQL является удобным и несложным средством описания сложных операций с данными. Если все ваши операции с данными — это локальные load и save, то SQL вам не нужен.
    S>А если вам нужно посчитать какие-то агрегаты по результату join восьми таблиц, и при этом ещё иметь гарантии ACID, то вручную вы это делать замаетесь.
    Ну что вы мне сказки рассказываете? Специалист по SQL это такой же специалист по C++ или java, а это самостоятельные языки.
    [In theory there is no difference between theory and practice. In
    practice there is.]
    [Даю очевидные ответы на риторические вопросы]
    Re[23]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 12.04.12 10:19
    Оценка: 3 (1)
    Здравствуйте, VladD2, Вы писали:

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


    Если нет инфраструктуры для взаимодействия множества разных DSL, то это не плохо, это необходимость.

    Если это встраиваемый DSL, тогда да, тогда это просто протекающая абстракция и за такое надо наказывать.

    VD>Польза ДСЛ в декларативности описания.


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

    VD>Если библиотека решает задачу на достойном уровне, то ДСЛ — оверкил.

    VD>Зачем не вводить новый синтаксис для чтения содержимого текстового файла, если это же я могу сделать вызвав библиотечную функцию?

    А DSL это вовсе не обязательно новый синтаксис. И даже тупая Java-библиотека может быть полноценным DSL (любители OOP не зря так носятся с interpreter pattern).

    VD>Смысл в ДСЛ-е появляется тогда, когда библиотечная функция:

    VD>* Не может выразить решение задачи без копипасты и кучи ручного кодирования.
    VD>* Приводит к более медленному решению.
    VD>* Выливается в эмуляцию ДСЛ-я средствами ЯОН.

    Это все не важно. DSL должен использоваться тогда, когда между решением и предметной областью встает язык, примешивая туда свои нерелевантные сущности (переменные там всякие, циклы и прочую, далекую от модели реальности чушь). Только вот синтаксис новый вводить совершенно не обязательно, такого эффекта можно добиться подбором API библиотеки. Если язык позволяет использовать функции высшего порядка, если в языке есть карринг, то "библиотечные" DSL делать легко и просто, у тех же хаскеллистов этот метод общепринят. Но даже в обычном ООП-языке можно такие трюки исполнять, с чуть большим количеством синтаксического мусора.

    VD>Да ты уже немного заколебал этой мантрой для домен языка. Домен любого ЯОН — написание функций. И спопитсот задач может быть отлично выражены в виде функции.


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

    VD>А вот ДСЛ может быть нежелателен хотя бы потому, что время затраченное на него больше лобового решения. Или его тупо сложно выделить.


    Выделить DSL можно всегда, это естественный результат решения любой задачи.
    Re[6]: Просто мысль...
    От: WolfHound  
    Дата: 12.04.12 10:19
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    O> И не сможете их использовать как следует до тех пор, пока для каждого макроса нужно отдельную DLL делать.

    Это не проблема.
    Проблемы Н1 в очень плохой архитектуре.

    O>Не получатся многоуровневые макроопределения (т.е., макросы, раскрывающиеся в определения макросов, которые тут же и используются).

    В Н2 не будет никаких проблем сделать иерархию языков.

    O>Учитесь у common lisp.

    Я вижу это решение несколько иначе.
    Н2 будет полностью типизировать всю программу.
    После чего будут применены несколько трансформаций каждая, из которых будет переписывать язык в более низкоуровневый.
    И тут нет никаких проблем с тем, чтобы разложить их по разным ДЛЛ.
    Я даже куски грамматики научился по разным ДЛЛ раскидывать. Это уже работает.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[7]: Просто мысль...
    От: oldjackal Россия  
    Дата: 12.04.12 10:32
    Оценка: +1
    Здравствуйте, WolfHound, Вы писали:

    O>> И не сможете их использовать как следует до тех пор, пока для каждого макроса нужно отдельную DLL делать.

    WH>Это не проблема.

    Ну как же? Макрос, определенный в модуле, не может в том же модуле использоваться. Это очень плохо. По этой причине я Nemerle и забросил, хотя в остальном язык показался весьма интересным.

    WH>Проблемы Н1 в очень плохой архитектуре.


    Внутрь не смотрел, не в курсе. Поверю на слово.

    O>>Не получатся многоуровневые макроопределения (т.е., макросы, раскрывающиеся в определения макросов, которые тут же и используются).

    WH>В Н2 не будет никаких проблем сделать иерархию языков.

    Т.е., можно будет пользоваться макросом сразу после определния? А lexically scoped макросы будут?

    O>>Учитесь у common lisp.

    WH>Я вижу это решение несколько иначе.
    WH>Н2 будет полностью типизировать всю программу.

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

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

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


    Только "несколько"? Или ровно столько, сколько нужно для раскрытия всех вложенных макросов?

    WH>И тут нет никаких проблем с тем, чтобы разложить их по разным ДЛЛ.


    Да не надо вообще этих dll! В Common Lisp один общий, постоянно растущий image, где и макросы и все прочее. И это удобно.

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


    Раскидывать не интересно. А вот определить и в том же модуле воспользоваться, это было бы полезно и удобно.
    Re[7]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 12.04.12 10:46
    Оценка: 62 (1)
    Здравствуйте, oldjackal, Вы писали:

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

    В packrat нет откатов. Он гарантированно линейный.
    В этом его главная фича.
    Проблема в том, что мемоизация жрет времени больше чем экономит.
    Прочитай про тот же Rats! Самые сильные оптимизации это убирание мемоизации.
    Я во время своих экспериментов пришёл к тем же выводам. В результате мемоизация у меня весьма своеобразная.

    WH>>2)Задолбаешься задавать приоритеты операторам. А ассоциативность ПЕГ вообще не может.

    O> Как это не может? Как это задолбаюсь?
    O>
    O> term = fact '+' term / fact '-' term / fact;
    O> fact = atom '*' fact / atom '/' fact / atom;
    O>

    Добавь между ними еще один оператор.
    И сравни с этим:
        [StartRule, Ast()]
        expr : Ast;
    
        [Ast(l, expr, r)] rounds is expr = '('s expr ')'s;
        [Ast(l, expr, r)] seq is expr = '{'s expr* '}'s;
    
        [Ast(num)]        num is expr = number s;
    
        [Ast(op, expr)]   neg is expr = '-'s expr : 100;
    
        [Ast(op, expr)]   prefixDec is expr = "--"s expr : 200;
        [Ast(expr, op)]   postfixDec is expr = expr : 200 "--"s;
    
        [Ast(l, op, r)]   add is expr = expr : 10 '+'s expr : 10;
        [Ast(l, op, r)]   sub is expr = expr : 10 '-'s expr : 10;
        [Ast(l, op, r)]   mul is expr = expr : 20 '*'s expr : 20;
        [Ast(l, op, r)]   div is expr = expr : 20 '/'s expr : 20;
        [Ast(l, op, r)]   mod is expr = expr : 20 '%'s expr : 20;
        [Ast(l, op, r)]   pow is expr = expr : 31 '^'s expr : 30;

    В будущем я избавлюсь от цифр, и буду задавать приоритеты именами, для которых задан порядок.
    Правая ассациотивность в данном случае делается элементарно.
    expr : 31 '^'s expr : 30;
    Причем алгоритм линеен без всякой мемоизации.

    O> Приоритеты очевидны, никто не задолбался. Ассоциативность получаем, если добавим левую рекурсию (http://www.vpri.org/pdf/tr2007002_packrat.pdf)

    Это уже не пакрат. И даже не ПЕГ. Ибо семантика языка уже изменена.

    Плюс у меня есть требование изменение грамматики во время разбора.
    Твой вариант в этом случае вообще никак не работает.

    O> Как раз наоборот! Приоритетный выбор очевиден для простого смертного, не испорченного yacc-ами.

    Практика показала, что на сложных грамматиках люди не могут адекватно его использовать.
    Вот, например: https://github.com/rsdn/nemerle/blob/master/snippets/csharp-parser/CSharpParser/Parser.n
    В этой грамматике есть несколько ошибок связанных с приоритетным выбором.
    Попробуй найди.

    O>А вот BNF как раз неочевиден и рождает неоднозначные конфликты.

    Проблемы БНФ в другом месте.
    Он не работает по тому, что БНФ это порождающая грамматика. А нам нужно разбирать текст.
    Из-за этого несоответствия и получаются все эти проблемы.

    O> И отброшена мемоизация? Зря. Для того же syntax highlighting и для реализации левой рекурсии это мощнейшая штука.

    У меня левая рекурсия работает иначе.

    O> У меня не бывает проблем даже при написании парсеров на примитивных низкоуровневых языках вроде C. Где там неадекватность-то?

    Ты тут сам про проблемы яков говорил. И они фундаментальны. Ибо БНФ грамматика порождающая.
    Причем восходящие парсеры (всё семейство LR) вообще не могут выдать адекватные сообщения об ошибках. Ибо разбирают текст не в том порядке, в котором его разбирает человек.
    Поэтому парсеры нужно делать на основе разбирающих грамматик основанных на нисходящем разборе.

    O> Никогда не встречался с трудностями с приоритетами и ассоциативностью, все элементарно и прозрачно.

    Ты, может быть, и нет.
    Но! Ты нерепрезентативен. (С)одна из поговорок Яндекса

    Честно говоря, я не хочу обсуждать этот вопрос.
    ПЕГ я уже отработал. Даже генератор ПЕГ парсеров написал.
    https://github.com/rsdn/nemerle/tree/master/snippets/peg-parser
    И на анализе практики его использования, а так же попыток придумать динамическую расширяемость я и сделал свои выводы.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[8]: Просто мысль...
    От: WolfHound  
    Дата: 12.04.12 10:57
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    O> Ну как же?

    Ну вот так.

    O>Макрос, определенный в модуле, не может в том же модуле использоваться. Это очень плохо. По этой причине я Nemerle и забросил, хотя в остальном язык показался весьма интересным.

    Макрос это простая функция, которая берет несколько кусков АСТ и возвращает новое.
    Рекурсивным функциям ДЛЛ не мешают.

    O> Т.е., можно будет пользоваться макросом сразу после определния? А lexically scoped макросы будут?

    Не совсем.
    Тут другая идеология.
    Так просто не напишешь. А писать большую статью я пока не готов.

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

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

    O> Так, конечно же, можно делать, но могут вылезти некоторые занятные сложности.

    Например? Влад тоже об этом долго говорил, но продемонстрировать не смог.

    O> Только "несколько"? Или ровно столько, сколько нужно для раскрытия всех вложенных макросов?

    Столько сколько нужно.

    O> Да не надо вообще этих dll! В Common Lisp один общий, постоянно растущий image, где и макросы и все прочее. И это удобно.

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

    O> Раскидывать не интересно. А вот определить и в том же модуле воспользоваться, это было бы полезно и удобно.

    У меня просто другой подход. Он не хуже чем лисп. Просто другой.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[8]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 12.04.12 11:03
    Оценка: 76 (3)
    Здравствуйте, WolfHound, Вы писали:

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

    WH>В packrat нет откатов. Он гарантированно линейный.

    Не так просто. Откаты есть (backtracking бесконечный), но он линейный за счет мемоизации.

    WH>В этом его главная фича.

    WH>Проблема в том, что мемоизация жрет времени больше чем экономит.

    Зависит от реализации мемоизации.

    WH>Прочитай про тот же Rats! Самые сильные оптимизации это убирание мемоизации.


    Естественно. Не все термы запоминать надо. И не в таблице, а в списке, что несколько убивает линейность но в разы сокращает константный коэффициент при O(1).

    WH>Я во время своих экспериментов пришёл к тем же выводам. В результате мемоизация у меня весьма своеобразная.


    Но таки есть мемоизация?

    WH>>>2)Задолбаешься задавать приоритеты операторам. А ассоциативность ПЕГ вообще не может.

    O>> Как это не может? Как это задолбаюсь?
    O>>
    O>> term = fact '+' term / fact '-' term / fact;
    O>> fact = atom '*' fact / atom '/' fact / atom;
    O>>

    WH>Добавь между ними еще один оператор.

    [code]
    term = fact '+' term / fact '-' term / fact;
    fact1 = atom '*' fact1 / atom '/' fact1 / atom;
    term = fact1 '$' term / fact1;
    [code]

    Добавил. Не задолбался.

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

    WH>И сравни с этим:


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

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


    Это уже лучше, но все равно требует напряжения мозгов у читающего.

    WH>Правая ассациотивность в данном случае делается элементарно.

    WH>expr : 31 '^'s expr : 30;
    WH>Причем алгоритм линеен без всякой мемоизации.

    Правая то и так без мемоизации получается. Левая интереснее.

    O>> Приоритеты очевидны, никто не задолбался. Ассоциативность получаем, если добавим левую рекурсию (http://www.vpri.org/pdf/tr2007002_packrat.pdf)

    WH>Это уже не пакрат. И даже не ПЕГ. Ибо семантика языка уже изменена.

    Ну почему же? Packrat с наворотами. Причем только там, где есть левая рекурсия, в остальном тот же packrat.

    WH>Плюс у меня есть требование изменение грамматики во время разбора.

    WH>Твой вариант в этом случае вообще никак не работает.

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

    O>> Как раз наоборот! Приоритетный выбор очевиден для простого смертного, не испорченного yacc-ами.

    WH>Практика показала, что на сложных грамматиках люди не могут адекватно его использовать.

    Практика прямо таки кричит, что сложных грамматик быть вообще не должно. Сколько можно C++-ы изобретать?

    WH>Вот, например: https://github.com/rsdn/nemerle/blob/master/snippets/csharp-parser/CSharpParser/Parser.n

    WH>В этой грамматике есть несколько ошибок связанных с приоритетным выбором.
    WH>Попробуй найди.

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

    O>> И отброшена мемоизация? Зря. Для того же syntax highlighting и для реализации левой рекурсии это мощнейшая штука.

    WH>У меня левая рекурсия работает иначе.

    Но работает? Это хорошо. А как насчет highlighting? Можно распарсить только измененный регион текста, без мемоизации?

    O>> У меня не бывает проблем даже при написании парсеров на примитивных низкоуровневых языках вроде C. Где там неадекватность-то?

    WH>Ты тут сам про проблемы яков говорил. И они фундаментальны. Ибо БНФ грамматика порождающая.

    Так я без якков. Руками. Ad hoc в самом махровейшем виде.

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


    Естественно. И даже так полно исключительных случаев, когда надо ругнуться более умно, чем любой генератор парсеров позволит. Как в clang, например — "а не забыли ли вы скобки вокруг параметров оператора &&? точно-точно?"

    O>> Никогда не встречался с трудностями с приоритетами и ассоциативностью, все элементарно и прозрачно.

    WH>Ты, может быть, и нет.
    WH>Но! Ты нерепрезентативен. (С)одна из поговорок Яндекса

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

    WH>https://github.com/rsdn/nemerle/tree/master/snippets/peg-parser


    Посмотрю.

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


    Так что не так-то с динамической расширяемостью? Чем меньше декларативности, тем ее проще реализовывать, разве нет?
    Re[24]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 12.04.12 11:09
    Оценка:
    Здравствуйте, Vain, Вы писали:
    S>>А если вам нужно посчитать какие-то агрегаты по результату join восьми таблиц, и при этом ещё иметь гарантии ACID, то вручную вы это делать замаетесь.
    V>Ну что вы мне сказки рассказываете? Специалист по SQL это такой же специалист по C++ или java, а это самостоятельные языки.
    Я не понял вашу фразу.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[23]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 12.04.12 11:11
    Оценка: +1
    Здравствуйте, WolfHound, Вы писали:

    WH>На самом деле это тоже криво.

    WH>У тебя, по сути, меняются только имена таблиц.
    WH>Хороший язык должен иметь возможность свести это к чему-то типа такого.
    WH>[Employees, Customers, Contacts].Map(SearchPerson(_, 'John')).UnionAll().Select(FirstName, LastName);
    Не, это ужасный синтаксис. Надо копать ещё дальше.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[9]: Просто мысль...
    От: oldjackal Россия  
    Дата: 12.04.12 11:14
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    O>>Макрос, определенный в модуле, не может в том же модуле использоваться. Это очень плохо. По этой причине я Nemerle и забросил, хотя в остальном язык показался весьма интересным.

    WH>Макрос это простая функция, которая берет несколько кусков АСТ и возвращает новое.
    WH>Рекурсивным функциям ДЛЛ не мешают.

    Ну так я смогу определить такую функцию и в том же модуле ей воспользоваться? А смогу из макроса воспользоваться другими функциями из этого модуля?

    O>> Т.е., можно будет пользоваться макросом сразу после определния? А lexically scoped макросы будут?

    WH>Не совсем.

    То есть, их не будет?

    WH>Тут другая идеология.


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

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

    WH>Именно. Причем типизация будет полностью декларативна. Я уже и матаном на эту тему обчитался.

    Вот этого я и боюсь. Может получиться неприемлемо сложно.

    O>> Так, конечно же, можно делать, но могут вылезти некоторые занятные сложности.

    WH>Например? Влад тоже об этом долго говорил, но продемонстрировать не смог.

    Иногда типы могут зависеть от типизации вложенных макр, которых нет (и про которые мы ничего не знаем) до тех пор, пока AST не развернули. Когда я пытался прикрутить типизированную макросистему к ML я по этим граблям походил. В Nemerle система типов несколько более человечная, так что не берусь утверждать, что трудности непреодолимы.

    O>> Только "несколько"? Или ровно столько, сколько нужно для раскрытия всех вложенных макросов?

    WH>Столько сколько нужно.

    Ну хоть это радует.

    O>> Да не надо вообще этих dll! В Common Lisp один общий, постоянно растущий image, где и макросы и все прочее. И это удобно.

    WH>У меня другое мнение.

    Обоснуете? Чем плоха возможность пользоваться определениями сразу, не отходя от кассы?

    WH>Тем более что подход лиспа не канает просто по тому, что он динамически типизирован.


    Типизация то тут при чем? Не вижу вообще никакой связи. В том же ocaml есть REPL. Даже в Haskell он есть. А от REPL до инкрементальных макросов один шаг.

    WH>А я динамическую типизацию считаю ошибкой природы.

    WH>Тормозит, жрет память и главное ошибки не ловит.

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

    O>> Раскидывать не интересно. А вот определить и в том же модуле воспользоваться, это было бы полезно и удобно.

    WH>У меня просто другой подход. Он не хуже чем лисп. Просто другой.

    Пусть он другой, но если он ограничивает возможности реализации иерархических макросов, то он должен как минимум предоставлять что-то взамен. Что-то не менее ценное.
    Re[23]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 12.04.12 11:16
    Оценка:
    Здравствуйте, Andrei N.Sobchuck, Вы писали:

    S>>
    S>>select FirstName, LastName from SearchPerson(Employees, 'John') 
    S>>

    ANS>Имя таблицы захардкожено.
    Нет, никуда ничего не захардкожено. SearchPerson всё равно, какую таблицу ей дадут. В идеале всё должно быть "переменной" — и 'FirstName, LastName', и 'SearchPerson', и 'Employees', и 'John'. Но хотя бы так.

    Всё таки, это просто синтаксический сахар.
    ANS>А вот то, что нельзя так сделать:
    ANS>
    ANS>select 
    ANS>  t.FirstName, 
    ANS>  t.LastName, 
    ANS>  (SELECT COUNT(*) FROM t.extended WHERE e.phone = t.phone) 
    ANS>from aTable t
    ANS>

    ANS>это ты прав.
    Непонятна семантика — тут нет опечаток? Если нету, то что имеется в виду под aTable и e — это типа "переменные"?
    Чего хочется получить?
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[12]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 12.04.12 11:22
    Оценка: +4
    Здравствуйте, alex_public, Вы писали:

    _>Попробую привести совсем упрощённый пример идеи. В стилистике Питона:

    _>
    form Main
    _>    title "Main"
    _>    button Calc
    _>        title "Calc"
    _>        onclick [Calculate]
    _>    button About
    _>        title "About"
    _>        onclick About.ModalShow
    _>form About
    _>    title "About"
    _>    button OK
    _>        title "OK"
    _>        onclick this.Close
    _>

    _>Это у нас будет файла нашего dsl. Компилируем его допустим в C++ h файл. И потом у нас останется написать реализацию функции Main::Calculate() на C++ в cpp файле и собрать итоговую программу.

    _>P.S. Всё это придумал буквально 10 минут назад и вообще dsl строение не специалист, так что сильно не ругаете пример — это просто попытка подумать в сторону удобного gui dsl, отделяющего интерфейс программы от "движка".

    Поздравляю, вы почти изобрели .dfm. Один-в-один. С точностью до способа группировки — индентация вместо явного object ... end.
    Вы же только что критиковали "языки размётки", в которых "всего лишь привязываются обработчики, написанные на системном языке". И тут же делаете то же самое. Принципиальный момент, которого тут не хватает — согласование сигнатур. Грубо говоря, хорошо, когда у вас евенты без параметров, и методы без параметров.
    Но это как раз неинтересно. Интересно, когда вам нужно передать данные из одного контрола или формы в другой. Вот коллега Wolfhound предлагает делать это через биндинги и ViewModel, а от событий (как я понял) отказаться вовсе.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[9]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 12.04.12 11:30
    Оценка: 93 (1)
    Здравствуйте, oldjackal, Вы писали:

    WH>>Я во время своих экспериментов пришёл к тем же выводам. В результате мемоизация у меня весьма своеобразная.

    O> Но таки есть мемоизация?
    Есть. Процентов 10 выжать удалось.

    O>[code]

    O> term = fact '+' term / fact '-' term / fact;
    O> fact1 = atom '*' fact1 / atom '/' fact1 / atom;
    O> term = fact1 '$' term / fact1;
    O>[code]
    O> Добавил. Не задолбался.
    Я знаю, как это делается.
    Но меня данная операция всегда напрягала.
    И что характерно всех моих знакомых тоже.

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

    Да я бы не сказал.

    O> А вот числовые приоритеты как раз для восприятия сложнее. Это их еще сравнивать надо, а тут тупо список, те что пониже приоритетом идут вперед, что повыше в конце.

    Не могу согласиться. Люди настолько привыкли к числам, что сравнивают их на больше/меньше не приходя в сознание.

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

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

    O> Правая то и так без мемоизации получается. Левая интереснее.

    У меня обе без мемоизации работают. Ключевые слова Pratt parser.
    У меня алгоритм основа на нем.

    O> Ну почему же? Packrat с наворотами. Причем только там, где есть левая рекурсия, в остальном тот же packrat.

    Ну да. Выделенное уже меняет семантику ПЕГа. И формально это уже другой язык.

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

    А у меня ограничений нет. Все очень просто. Быстро. И линейно.

    O> Практика прямо таки кричит, что сложных грамматик быть вообще не должно. Сколько можно C++-ы изобретать?

    Да я не спорю. Но существующие языки тоже нужно разбирать.

    O> Если кто-то попробует сделать DSL с синтаксисом шарпа, то ему надо отрубить обе руки. За садизм и бесчеловечность. Потом и документацию на тысячу страниц писать, с описанием тонкостей приоритетов операторов?

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

    WH>>У меня левая рекурсия работает иначе.

    O> Но работает? Это хорошо.
    Причем очень хорошо работает.
    У меня алгоритм линейный даже без мемоизации.

    O>А как насчет highlighting? Можно распарсить только измененный регион текста, без мемоизации?

    Мне хватает скорости, чтобы все распарсить.
    Но такое тоже со временем будет.

    O> Естественно. И даже так полно исключительных случаев, когда надо ругнуться более умно, чем любой генератор парсеров позволит. Как в clang, например — "а не забыли ли вы скобки вокруг параметров оператора &&? точно-точно?"

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

    O> Я репрезентативен,

    Я о том, что далеко не всем людям понятно даже это:
    O>[code]
    O> term = fact '+' term / fact '-' term / fact;
    O> fact1 = atom '*' fact1 / atom '/' fact1 / atom;
    O> term = fact1 '$' term / fact1;
    O>[code]
    Им гораздо проще задать приоритеты явно.

    WH>>https://github.com/rsdn/nemerle/tree/master/snippets/peg-parser

    O> Посмотрю.
    Да не на что там смотреть.

    O> Так что не так-то с динамической расширяемостью? Чем меньше декларативности, тем ее проще реализовывать, разве нет?

    Нет. Чем меньше декларативности, тем мутнее семантика языка.
    Тем сложнее рассуждать о поведении грамматики при динамическом расширении.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[24]: Языки общего назначения не имеют смысла!
    От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
    Дата: 12.04.12 11:34
    Оценка:
    Здравствуйте, Sinclair, Вы писали:


    ANS>>А вот то, что нельзя так сделать:

    ANS>>
    ANS>>select 
    ANS>>  t.FirstName, 
    ANS>>  t.LastName, 
    ANS>>  (SELECT COUNT(*) FROM t.extended WHERE e.phone = t.phone) 
    ANS>>from aTable t
    ANS>>

    ANS>>это ты прав.
    S>Непонятна семантика — тут нет опечаток? Если нету, то что имеется в виду под aTable и e — это типа "переменные"?
    S>Чего хочется получить?
    Видно под extended имеется ввиду подчиненная таблица как в ObjectQuery

    string entitySQL = " SELECT p, p.Filling " +
    "FROM PartyContext.Pinatas AS p " 
    "WHERE p.Filling.Description='Candy'";
    var query=context.CreateQuery<DbDataRecord>(entitySQL);
    query.MergeOption = System.Data.Objects.MergeOption.NoTracking;
    var pinatasWithFilling=query.ToList();
    и солнце б утром не вставало, когда бы не было меня
    Re[24]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 12.04.12 11:34
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>Не, это ужасный синтаксис. Надо копать ещё дальше.

    Я не про синтаксис. А про то, что нужно свести все к этим операциям.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[10]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 12.04.12 11:44
    Оценка: 62 (1)
    Здравствуйте, WolfHound, Вы писали:

    WH>Но меня данная операция всегда напрягала.

    WH>И что характерно всех моих знакомых тоже.

    Насколько часто это приходится делать?

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

    WH>Да я бы не сказал.

    Вам нравятся грамматики со сложными правилами приоритетов? А я вот такой код читать не могу совершенно, если там есть что-то сложнее школьной арифметики. И писать такой код не могу, я всегда скобочки расставляю явным образом. Не хочу и не могу помнить, больше у '%' приоритет чем у '+' или меньше.

    O>> А вот числовые приоритеты как раз для восприятия сложнее. Это их еще сравнивать надо, а тут тупо список, те что пониже приоритетом идут вперед, что повыше в конце.

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

    Не все. Мне вот даже ценники в магазине сравнивать непросто. И таких как я много. Может это и форма дислексии, но она очень распространена. Ненавижу цифры.

    WH>Это делается в основном для динамического расширения.

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

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

    O>> Правая то и так без мемоизации получается. Левая интереснее.

    WH>У меня обе без мемоизации работают. Ключевые слова Pratt parser.
    WH>У меня алгоритм основа на нем.

    Как-то информации по нему мало, кроме самой оригинальной статьи.

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

    WH>А у меня ограничений нет. Все очень просто. Быстро. И линейно.

    Совсем нет? Так не бывает. Но вы меня заинтересовали, попробую узнать про Pratt-а побольше. Есть какие-то ссылки по теме, которые гугл и википедия не дадут?

    Естественно, воспользоваться я этим смогу только если алгоритм позволяет писать парсеры руками, на C или шарпе, без всяких генераторов.

    O>> Практика прямо таки кричит, что сложных грамматик быть вообще не должно. Сколько можно C++-ы изобретать?

    WH>Да я не спорю. Но существующие языки тоже нужно разбирать.

    К задаче реализации DSL это особого отношения не имеет, к счастью.

    O>> Если кто-то попробует сделать DSL с синтаксисом шарпа, то ему надо отрубить обе руки. За садизм и бесчеловечность. Потом и документацию на тысячу страниц писать, с описанием тонкостей приоритетов операторов?

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

    Которая в голове, однако, не помещается.

    O>>А как насчет highlighting? Можно распарсить только измененный регион текста, без мемоизации?

    WH>Мне хватает скорости, чтобы все распарсить.

    Даже если там сто тысяч строк кода?

    O>> Естественно. И даже так полно исключительных случаев, когда надо ругнуться более умно, чем любой генератор парсеров позволит. Как в clang, например — "а не забыли ли вы скобки вокруг параметров оператора &&? точно-точно?"

    WH>Я это понимаю. И собираюсь сделать язык описания ошибочных ситуаций.

    А это не ошибочная ситуация. Это предупреждение.

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


    Очень интересно. Я пока что не представляю себе, как это можно сделать декларативно.

    O>> Я репрезентативен,

    WH>Я о том, что далеко не всем людям понятно даже это:

    Для понимания всем хватает тридцати минут, раз и навсегда. Проверенно.

    WH>>>https://github.com/rsdn/nemerle/tree/master/snippets/peg-parser

    O>> Посмотрю.
    WH>Да не на что там смотреть.

    Мне Packrat интересен как раз тем, что его можно и руками делать, без DSLей, без генераторов.

    O>> Так что не так-то с динамической расширяемостью? Чем меньше декларативности, тем ее проще реализовывать, разве нет?

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

    Семантика то как раз прозрачна, поскольку не далеко ушла от привычной семантики низлежащего языка.
    Re[3]: Языки общего назначения не имеют смысла?
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 12.04.12 11:58
    Оценка: 14 (3) +2
    Здравствуйте, VladD2, Вы писали:

    VD>Но пока читал все это сформулировал для себя очень простой критерий выявления ДСЛ-ей. ДСЛ не позволяет воспроизвети себя же, если это не ДСЛ описания компилятора.


    Влад, я с этим не согласен. Ну ты же сам тут же делаешь оговорку. Чем DSL для разработки компиляторов хуже, чем DSL для описания фильтров для фотошопа?

    Если отвлечься от специфики, то окажется, что у любого языка есть какой-то домен.
    Бытовое понятие "языка общего назначения" обычно просто означает повышенную "ширину" домена, по сравнению с каким-то другим доменом.
    Ну, вот скажем, HP-GL, вроде бы, бесспорно DSL. Он не тьюринг-полный, да и вообще плохо напоминает язык программирования.

    А вот, скажем, ECMAScript — это ЯОН? Однозначно ЯОН.
    Но в его синтаксис встроена специальная поддержка для regex-ов, что заставляет задуматься над "несимметричностью" его домена.

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

    В С++ нет встроенного типа complex. Зато есть возможность ввести его, и получить вполне приличный синтаксис. Грубо говоря, С++ — это язык для разработки кастомной арифметики. Вы посмотрите, сколько в нём любовного внимания уделено перегрузке операторов и тонкостям передачи данных "по значению". Бьярни явно хотелось порвать Фортран путём разработки движка для промышленного выпуска Фортранов. Зато вот строки в плюсах — бедный родственник (что по-прежнему лучше фортрана, в котором строки были прямо-таки чужаками). Видно, что авторы языка не хотели, чтобы на нём кто-то работал с текстами.

    В итоге мы всё равно упираемся в сравнение тёплого с мягким. "Уровень" С++ в одних местах "выше", чем у С# 1.0 (позволяя описывать шаблонные функции и типы), а в других — "ниже" (требуя вручную управлять динамически распределённой памятью).
    "Ширина" домена тоже штука плохо — домены могут пересекаться лишь частично, и непонятно, в ком из сравниваемых чего-то "не хватает".

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

    На мой взгляд, оно как раз в стоимости разработки языков. Ну, то есть понятно, что исторически первыми появлялись именно DSL — фортран, алгол. Языки общего назначения были попыткой сэкономить на разработке и изучении множества DSL (помните Аду?).
    Если посмотреть на то, с чем мы вышли из 80х, то в списке популярных мы будем иметь два языка, разработанных чисто для обучения (Pascal и Basic), два DSL, выросших в GPPL (Фортран и C), и C++.
    В течение 30 лет народ тщательно пилил ЯОНы, пытаясь довести их до совершенства. Главная идея развития: давайте дадим возможность пилить библиотеки, и паническая боязнь встроить в язык хоть что-то конкретное. Надо полагать, всех пугала тень Ады. "Если дать человеку тип "строка", он проживёт один день. Если дать ему механизм реализации пользовательских типов строк и перегрузки операций, то он протрахается всю жизнь".
    В 2000х пошла некоторая обратная тенденция: вместо механизмов по построению механизмов по решению задач, стало можно потихонечку внедрять просто механизмы по решению задач. Т.е. вносить некоторую доменную специфику.

    В принципе, никто не будет спорить, что обжать разъём RJ-45 лучше при помощи обжимочного инструмента. Что заворачивать шурупы удобнее шуруповёртом, чем отвёрткой, и чем даже дрелью.
    Есть подозрение, что если бы у нас был дешёвый способ клепать высококачественные языки для решения конкретных типов задач, то вряд ли бы мы стали от него отказываться, и стараться решить всё многословно, коряво, но зато на "универсальном" языке.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[4]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 12.04.12 12:01
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    G>В бизнесе чуть ли не все задачи типовые, но вот dsl для них не придумали.

    Простите, вы не BPEL, случайно, ищете?
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[25]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 12.04.12 12:04
    Оценка:
    Здравствуйте, WolfHound, Вы писали:
    S>>Не, это ужасный синтаксис. Надо копать ещё дальше.
    WH>Я не про синтаксис. А про то, что нужно свести все к этим операциям.
    А, ну так состав операций никак не изменился.
    Вообще, все нужные операции уже давно описаны Коддом.
    Проблема SQL — только в том, что в нём нет понятия "функция" в широком смысле. И тем более нет понятия "функция высшего порядка".
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[4]: Языки общего назначения не имеют смысла?
    От: oldjackal Россия  
    Дата: 12.04.12 12:11
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>Есть подозрение, что если бы у нас был дешёвый способ клепать высококачественные языки для решения конкретных типов задач, то вряд ли бы мы стали от него отказываться, и стараться решить всё многословно, коряво, но зато на "универсальном" языке.


    Так есть он, этот способ. Причем мало от языка зависящий.
    Re[7]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 12.04.12 12:13
    Оценка: -1 :)
    Здравствуйте, WolfHound, Вы писали:

    G>>В чем проблема?

    WH>В том, что бизнес задачами занимаются люди, которые дальше языков общего назначения ничего не видят.

    Других просто нет.

    WH>Вот ты, например даже не задумаешься о том, что можно сделать ДСЛ.

    WH>И в институтах этому не учат. И вообще распространяют миф, что это что-то очень сложное.

    Враньё. Курс вроде компиляторов есть почти во всех серьехзных ИТ-вузах. Из своих наблюдений
    1. большинство программистов плохо знает математику
    2. компиляторы хорошо идут только у тех кто хорошо знает математику
    The animals went in two by two, hurrah, hurrah...
    Re[8]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 12.04.12 12:20
    Оценка: +2
    Здравствуйте, Tanker, Вы писали:

    WH>>В том, что бизнес задачами занимаются люди, которые дальше языков общего назначения ничего не видят.


    T>Других просто нет.


    Да все и везде одинаковые. Просто этим не объяснили, куда и как смотреть.

    T>Враньё. Курс вроде компиляторов есть почти во всех серьехзных ИТ-вузах. Из своих наблюдений


    Есть. Плохой, паршивый курс. Драконовщина везде царит.

    T>1. большинство программистов плохо знает математику


    И пусть себе. Не беда.

    T>2. компиляторы хорошо идут только у тех кто хорошо знает математику


    У меня хорошо идут. Математику не знаю и не люблю.
    Re[25]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 12.04.12 12:23
    Оценка: +3
    Здравствуйте, Serginio1, Вы писали:
    S>>Непонятна семантика — тут нет опечаток? Если нету, то что имеется в виду под aTable и e — это типа "переменные"?
    S>>Чего хочется получить?
    S> Видно под extended имеется ввиду подчиненная таблица как в ObjectQuery
    Как раз это — сахар чистой воды.
    Замена

    select * from Person p 
      where p.City.Name like 'Ново%'

    на
    select p.* from Person p 
    inner join City on p.City = City.Id
      where City.Name like 'Ново%'

    Во-первых, тривиальна, во-вторых, не очень много чего экономит. Ну, то есть в развесистых star-join запросах это было бы полезно, но реальный пауэр — это всё же возможность полноценной функциональной декомпозиции. Хотя бы без ФВП.
    Без этого 3/4 хранимых процедур в реальных SQL базах — это ужасный boilerplate, который существует исключительно из-за невозможности повторного использования. Все вот эти "where ((startDate >= @minDate or @minDate is null) and (startDate <= @maxDate or @maxDate is null)) or ((endDate >= @minDate or @minDate is null) and (endDate <= @maxDate or @maxDate is null)) и прочий тихий ужос. Это на уровне кортежей. На уровне реляций всё ещё хуже — нет никакой возможности написать универсальную функцию, всё всегда только по месту.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[5]: Языки общего назначения не имеют смысла?
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 12.04.12 12:23
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    O> Так есть он, этот способ. Причем мало от языка зависящий.

    Расскажите.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[9]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 12.04.12 12:25
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    G>>У меня как раз был курс построения языков и мы там dsl рассматривали. Именно оттуда я выяснил что это сложная тема.

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

    Не нужно передергивать.
    "Сложность рукопашного кода всё равно больше" — для каких задач ?
    Всегда ли нужно писать полноценное решение ?

    На примере CSV-парсера. В разных проектах, в которые пришлось сунуть нос, видел уже наверное под сотню парсеров, от простых вроде string.split до всяких регулярных выражений и тд. Работают все по разному, с разной степенью надежности, производительности и тд.
    1 Покажи на примере этой простой задачи преимущества DSL.
    2 Всегда ли нужно писать полноценный парсер вроде CSV ?
    3 Объясни, кем заменить тех, кто не в состоянии написать чтото большее string.split ?

    DSL, хочешь ты или нет, это очень сложная тема. Очевиднл, рукапашный код будет еще сложнее, но сложности задачи это не отменяет. Если люди способны работать на продакшн и могут писать вроде string.split, то нужно предложить хорошую замену задирая планку требований до небес.
    The animals went in two by two, hurrah, hurrah...
    Re[10]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 12.04.12 12:28
    Оценка:
    Здравствуйте, Tanker, Вы писали:

    T>3 Объясни, кем заменить тех, кто не в состоянии написать чтото большее string.split ?


    Я бы рассказал, что надо сделать с теми, кто выдумывает форматы, требующие чего-то большего чем String.Split. CSV это злобно и бесчеловечно.

    T>DSL, хочешь ты или нет, это очень сложная тема.


    Не-а. Простая. Проще некуда.
    Re[13]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 12.04.12 12:33
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

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


    G>>Чтобы написать в 10 раз меньше надо сначала написать DSL, что сложнее чем написать код. Ты пока что обратного не смог показать.

    WH>Смех на палочке.
    WH>Напиши этот код руками:
    ... мусор убрал
    WH>Любому непредвзятому человеку ясно, какой вариант выбрать.

    Это передергивание. Пока ты дошел до этого, ты сотни раз писал вские парсеры, грамматики и тд и тд и тд. То есть, ты уже написал под сотню другую вариантов и твой коротенький код есть результат всех этих попыток.
    Осталось дело за малым — распространить твой опыт на индустрию. Всего то посадить по WolfHound на каждый проект
    The animals went in two by two, hurrah, hurrah...
    Re[14]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 12.04.12 12:36
    Оценка:
    Здравствуйте, Tanker, Вы писали:

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


    Достаточно один раз написать, чтобы понять. Не велика проблема. Это как "hello, world".

    Да и не в парсерах дело, они весьма редко нужны. DSL это не обязательно новый синтаксис.
    Re[26]: Языки общего назначения не имеют смысла!
    От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
    Дата: 12.04.12 12:37
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    Поверь мне пушущему на 1С этих соединений в запросе может быть великое множество, так что доступ через точку резко сокращает и главное улучшает читаемость кода.
    А так полностью согласен.
    и солнце б утром не вставало, когда бы не было меня
    Re[5]: Языки общего назначения не имеют смысла!
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 12.04.12 12:51
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

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


    G>>В бизнесе чуть ли не все задачи типовые, но вот dsl для них не придумали.

    S>Простите, вы не BPEL, случайно, ищете?

    BPEL — очень высокий уровень. Проблемы как раз уровнем ниже начинаются.
    Re[24]: Языки общего назначения не имеют смысла!
    От: Andrei N.Sobchuck Украина www.smalltalk.ru
    Дата: 12.04.12 13:08
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    ANS>>Имя таблицы захардкожено.

    S>Нет, никуда ничего не захардкожено. SearchPerson всё равно, какую таблицу ей дадут. В идеале всё должно быть "переменной" — и 'FirstName, LastName', и 'SearchPerson', и 'Employees', и 'John'. Но хотя бы так.

    Это я не правильно сказал. И пример мой — дурацкий. Забудь
    Я думал о рефлексии. Тогда всё действительно сводится к тому, что не хватает relation, как первоклассной сущности.
    С другой стороны особенность SQL такова, что без хост-языка он смысла не имеет. А подзапросы мне по прежнему кажутся достаточными для декомпозиции.
    Я ненавижу Hibernate
    Автор: Andrei N.Sobchuck
    Дата: 08.01.08
    !
    Re[25]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 12.04.12 13:21
    Оценка:
    Здравствуйте, Andrei N.Sobchuck, Вы писали:

    ANS>Я думал о рефлексии. Тогда всё действительно сводится к тому, что не хватает relation, как первоклассной сущности.

    relation как первоклассная сущность в SQL есть. Нет функций как первоклассной сущности.
    ANS>С другой стороны особенность SQL такова, что без хост-языка он смысла не имеет. А подзапросы мне по прежнему кажутся достаточными для декомпозиции.
    Откуда такие иллюзии? Я показал примеры декомпозиции, которые невозможны на SQL. Вам что-то непонятно? Спрашивайте.
    Подзапросы не спасут вас от монолитности запроса — это всего лишь те же шесть страниц, записанные в другом порядке.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[4]: Языки общего назначения не имеют смысла?
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 12.04.12 14:12
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    VD>>На то она и предметная область, чтобы решать только ее задачу. Если ДСЛ позволяет (пусть криво или медленно) воспроизвести себя, то это ЯОН (язык общего назначения). А его уровень не имеет никакого отношения к ДСЛ-ности.

    WH>Плохой критерий.
    WH>Ибо так умеют все полные по Тьюрингу языки.

    Не все. Для этого еще доступ к внешним ресурсам нужен.

    WH>Соответственно если вдруг ДСЛ окажется полным по Тьюрингу, то он сразу перестает быть ДСЛ?


    В общем — да. Как только язык становится универсальным, то он перестает быть ДСЛ-ем. Он становится специализированным (или не очень) ЯОН.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[4]: Языки общего назначения не имеют смысла?
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 12.04.12 14:31
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>Влад, я с этим не согласен. Ну ты же сам тут же делаешь оговорку. Чем DSL для разработки компиляторов хуже, чем DSL для описания фильтров для фотошопа?


    Ничем. Но ДСЛ для фильров не должен позволять написать ДСЛ для фильтров, а только фильтры.

    S>Если отвлечься от специфики, то окажется, что у любого языка есть какой-то домен.

    S>Бытовое понятие "языка общего назначения" обычно просто означает повышенную "ширину" домена, по сравнению с каким-то другим доменом.

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

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

    Кроме того тогда встает вопрс о том, что вместо ДСЛ можно использовать термин "язык". Ведь если мы дофилософствовались до того, что любой язык являетс ДС, то нафиг тогда нужна эта приставка?
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[5]: Языки общего назначения не имеют смысла?
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 12.04.12 14:54
    Оценка: 1 (1) +1
    Здравствуйте, VladD2, Вы писали:

    VD>Ничем. Но ДСЛ для фильров не должен позволять написать ДСЛ для фильтров, а только фильтры.

    Ну, а язык для компиляторов не обязан позволять написать фильтр. Или, по крайней мере, написать его удобно (понятно, что любой тьюринг-полный язык сразу даст написать и фильтр, и компилятор с DSL).

    VD>Это бессмысленная философия. Должно быть различие между двумя совершенно разными вещами.

    Развернём утверждение: если чёткого различия нет, то две вещи не являются совершенно разными. Не так ли?

    VD>* языком на котором можно написать все, что угодно, но тем или иным образом используемым для решения некой задачи;

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

    VD>Уж слишком разные требования и свойства у этих вещей.

    Не вижу особенных различий в требованиях. Вот, скажем, два языка — Паскаль и C++. Оба — GPPL ("можно написать все, что угодно"). Но в Паскале есть встроенная механика по работе с файлами фиксированной структуры (FILE OF TYPE), а С++ — механика перегрузки операторов. Почему? Надо полагать, у них отличаются домены.

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

    Влад, с какого момента можно называть человека толстым? Где граница между "полным", "полноватым", и "склонным к полноте"?
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[26]: Языки общего назначения не имеют смысла!
    От: Andrei N.Sobchuck Украина www.smalltalk.ru
    Дата: 12.04.12 15:00
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    ANS>>Я думал о рефлексии. Тогда всё действительно сводится к тому, что не хватает relation, как первоклассной сущности.

    S>relation как первоклассная сущность в SQL есть. Нет функций как первоклассной сущности.

    Не совсем понял. Ты пишешь, что так нельзя:

    Вот чего нельзя сделать в SQL:

    public IQueryable<T> SearchPerson<T>(IQueryable<T> source, string searchText) 
      where T: IPerson
    {
       from p in source 
         where p.FirstName.Contains(searchText) || p.LastName.Contains(searchText)
    ...

    Т.е. `source` как параметр передать нельзя. И тут же ты говоришь, что relation это первоклассная сущность. Какой тогда критерий первоклассности чего-либо, если не (не)возможность передать это нечто аргументом в функцию?

    S>Подзапросы не спасут вас от монолитности запроса — это всего лишь те же шесть страниц, записанные в другом порядке.

    Пожалуй, это проблемы хост-языка, а не самого SQL. В Java это решаемо. А если нерешаемо в T-SQL, то это проблемы именно T-SQL.
    Я ненавижу Hibernate
    Автор: Andrei N.Sobchuck
    Дата: 08.01.08
    !
    Re[6]: Языки общего назначения не имеют смысла?
    От: oldjackal Россия  
    Дата: 12.04.12 15:03
    Оценка: +1
    Здравствуйте, Sinclair, Вы писали:

    S>Ну, а язык для компиляторов не обязан позволять написать фильтр. Или, по крайней мере, написать его удобно (понятно, что любой тьюринг-полный язык сразу даст написать и фильтр, и компилятор с DSL).


    Самое смешное, что как раз язык для написания компиляторов и не должен быть Тьюринг-полным. Для него это крайне нежелательное свойство. Смотрите на Coq (и на CompCert за примером применения).
    Re[10]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 12.04.12 15:07
    Оценка:
    Здравствуйте, Tanker, Вы писали:

    WH>>1)В институте плохому учат. У них там все действительно сложнее, чем надо получается.

    WH>>2)Сложность рукопашного кода всё равно больше. Чем сложность компилятора.
    T>Не нужно передергивать.
    В каком месте?

    T>"Сложность рукопашного кода всё равно больше" — для каких задач ?

    Для всех чей домен не является подмножеством используемого языка.
    Те для чуть менее чем всех.

    T>Всегда ли нужно писать полноценное решение ?

    А какое еще?

    T>На примере CSV-парсера. В разных проектах, в которые пришлось сунуть нос, видел уже наверное под сотню парсеров, от простых вроде string.split до всяких регулярных выражений и тд. Работают все по разному, с разной степенью надежности, производительности и тд.

    CSV? string.split'ом? Оригинально.

    T>1 Покажи на примере этой простой задачи преимущества DSL.

    Так это зависит от того что ты делаешь.
    Скажи, зачем ты парсишь CSV?

    T>2 Всегда ли нужно писать полноценный парсер вроде CSV ?

    А как иначе? Если нам нужно разобрать CSV то нам нужно писать его парсер.

    T>3 Объясни, кем заменить тех, кто не в состоянии написать чтото большее string.split ?

    Этих по-хорошему нужно гнать из профессии.
    Но если приспичило можно их посадить писать код на ДСЛ, который не дает делать плохие вещи.

    T>DSL, хочешь ты или нет, это очень сложная тема.

    Только для тех, кто ничего кроме книги дракона не видел.

    T>Очевиднл, рукапашный код будет еще сложнее, но сложности задачи это не отменяет. Если люди способны работать на продакшн и могут писать вроде string.split, то нужно предложить хорошую замену задирая планку требований до небес.

    Ничего не понял.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[8]: Языки общего назначения не имеют смысла!
    От: PSV100  
    Дата: 12.04.12 15:18
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

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


    PSV>>Создаётся чистый HTML (пусть верстальщиком, дизайнером), без шаблонов, без CSS-элементов, без никакого кода, где есть некоторые правила, например, условные имена для div. Программист в коде читает этот файл, он трансформируется в структуры и пр. этого языка, дальше манипулируй с документом как хочешь в рамках программного кода.

    WH>Я бы не сказал что это хороший подход.
    WH>ИМХО тут слишком много не нужной работы.
    Ну, главное, чтобы работа была, а когда надо, уменьшить её сможем .

    Я тут посмотрел то, что, скорее всего, ты имел в виду. Здесь, кажись Влад, давал ссылку на пример из knockoutjs, приведу код оттуда.
    Это View:
    <h2>Planets</h2>
    <p>
        <label>
            <input type='checkbox' data-bind='checked: displayAdvancedOptions' />
            Display advanced options
        </label>
    </p>
     
    <p data-bind='fadeVisible: displayAdvancedOptions'>
        Show:
        <label><input type='radio' name="type" value='all' data-bind='checked: typeToShow' />All</label>
        <label><input type='radio' name="type" value='rock' data-bind='checked: typeToShow' />Rocky planets</label>
        <label><input type='radio' name="type" value='gasgiant' data-bind='checked: typeToShow' />Gas giants</label>
    </p>
     
    <div data-bind='template: { foreach: planetsToShow,
                                beforeRemove: hidePlanetElement,
                                afterAdd: showPlanetElement }'>
        <div data-bind='attr: { "class": "planet " + type }, text: name'> </div>
    </div>
     
    <p data-bind='fadeVisible: displayAdvancedOptions'>
        <button data-bind='click: addPlanet.bind($data, "rock")'>Add rocky planet</button>
        <button data-bind='click: addPlanet.bind($data, "gasgiant")'>Add gas giant</button>
    </p>

    И код для View model:
    var PlanetsModel = function() {
        this.planets = ko.observableArray([
            { name: "Mercury", type: "rock"},
            { name: "Venus", type: "rock"},
            { name: "Earth", type: "rock"},
            { name: "Mars", type: "rock"},
            { name: "Jupiter", type: "gasgiant"},
            { name: "Saturn", type: "gasgiant"},
            { name: "Uranus", type: "gasgiant"},
            { name: "Neptune", type: "gasgiant"},
            { name: "Pluto", type: "rock"}
        ]);
     
        this.typeToShow = ko.observable("all");
        this.displayAdvancedOptions = ko.observable(false);
     
        this.addPlanet = function(type) {
            this.planets.push({
                name: "New planet",
                type: type
            });
        };
     
        this.planetsToShow = ko.computed(function() {
            // Represents a filtered list of planets
            // i.e., only those matching the "typeToShow" condition
            var desiredType = this.typeToShow();
            if (desiredType == "all") return this.planets();
            return ko.utils.arrayFilter(this.planets(), function(planet) {
                return planet.type == desiredType;
            });
        }, this);
     
        // Animation callbacks for the planets list
        this.showPlanetElement = function(elem) { if (elem.nodeType === 1) $(elem).hide().slideDown() }
        this.hidePlanetElement = function(elem) { if (elem.nodeType === 1) $(elem).slideUp(function() { $(elem).remove(); }) }
    };
     
    // Here's a custom Knockout binding that makes elements shown/hidden via jQuery's fadeIn()/fadeOut() methods
    // Could be stored in a separate utility library
    ko.bindingHandlers.fadeVisible = {
        init: function(element, valueAccessor) {
            // Initially set the element to be instantly visible/hidden depending on the value
            var value = valueAccessor();
            $(element).toggle(ko.utils.unwrapObservable(value)); // Use "unwrapObservable" so we can handle values that may or may not be observable
        },
        update: function(element, valueAccessor) {
            // Whenever the value subsequently changes, slowly fade the element in or out
            var value = valueAccessor();
            ko.utils.unwrapObservable(value) ? $(element).fadeIn() : $(element).fadeOut();
        }
    };
     
    ko.applyBindings(new PlanetsModel());

    И здесь ты давал ссылки на прототип DSL для Немерля, как я понимаю, по мотивам этого knockoutjs (здесь
    Автор: WolfHound
    Дата: 15.02.11
    и здесь
    Автор: WolfHound
    Дата: 14.02.11
    ).
    Да, конечно, DSL неплох, сразу позволяет в HTML декларативно задать много чего, с меньшей возней и реально с меньшей работой. Но этот DSL хорош именно для программистов. Я понимаю, что в реальной жизни, имхо, больше случаев, когда программист сам себе дизайнер. В предыдущем своём посту я больше акцентировал внимание на тот случай, когда в проект притаскиваются специалисты по юзабилити. Какому-то верстальщику, или дизайнеру (на всякий случай, чтобы здесь никого не обидеть, назвав стилиста парикмахером), имхо, уже непросто будет набрать подобный View. Во-первых, дизайнерам нужно разобраться с новым языком, пусть и несложным, похожим на HTML, но со своими нюансами. Во-вторых, им нужно или изучить новый инструментарий для этого языка, если имеется, или адаптировать свои годами подточенные IDE/редакторы для вёрстки HTML. Имхо, это всё несложно решаемо. Главная беда в том, что дизайнерам, имхо, обычно пофиг, как устроена программа и как она будет создавать документы. Им не только в лом набирать всякий биндинг, но и опасно это делать: программисты долго будут материться от того, что эти спецы набиндили.

    Вот примерно то, о чём я говорил в рамках всяких фреймворках для Кложуры:
    <html>
    <head>
      <title></title>
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
    </head>
    
    <body>
    <div>
      <div id="msg1">Old value: <span id="old" /></div>
      <div id="msg2" />
      <form method="post" action="/some_action" >
        <input type="text" name="value" ></input><input type="submit" name="ok" ></input>
      </form>
    </div>

    Это заготовка для HTML, чистая разметка без ничего лишнего. Вот по таким мотивам можно обрабатывать HTML:
    (html/deftemplate page-index "web_clojure_demo/index.html" [ctxt]
      [:title] (html/content "Awesome application")
      [:#old] (html/content (:old ctxt))
      [:#msg2] (html/set-attr "style" "display: none"))
    
    (html/deftemplate page-summary "web_clojure_demo/index.html" [ctxt]
      [:title] (html/content "Awesome application")
      [:#old] (html/content (:old ctxt))
      [:#msg2] (html/content (str "Summary is " (:sum ctxt))))

    Здесь создаются две функции, которые принимают параметр ctxt, загружают html-шаблон и модифицируют содержимое, изменяют стили.
    Вот так эти функции можно применять:
    (defn parse-input [a]
      (Integer/parseInt a))
    
    (defn index []
      (let [old (redis/get db "value")]
        (page-index {:old old})))
    
    (defn summary [value]
      (let [old (redis/get db "value")]
        (redis/set db "value" value)
        (page-summary { :sum (+ (parse-input value) (parse-input old))
                        :old old})))


    HTML, CSS можно лепить с нуля в таком стиле:
    (defpartial todo-item [{:keys [id title due]}]
        [:li {:id id} ;; maps define HTML attributes
            [:h3 title]
            [:span.due due]]) ;; add a class
    
    (defpartial todos-list [items]
        [:ul#todoItems ;; set the id attribute
            (map todo-item items)])
    
    (todos-list [{:id "todo1"
                  :title "Get Milk"
                  :due "today"}])
    ;; =>
    ;; <ul id="todoItems">
    ;; <li id="todo1">
    ;; <h3>Get Milk</h3>
    ;; <span class="due">today</span>
    ;; </li>
    ;; </ul>

    Короче говоря, в самом лиспе можно вертеть/крутить HTML и CSS как угодно.

    Но это не главное, что хотел сказать. Вот вырезка из ссылки по поводу прототипа DSL для Немерля:
    view HelloView(model : HelloModel)
    {
        <p>First name: <input value <-> model.firstName; /></p>
        <p>Last name: <input value <-> model.lastName; /></p>
        <h2>Hello, <span text <- model.fullName; />!</h2>
    }
    
    model HelloModel
    {
        firstName : string = "Planet";
        lastName : string = "Earth";
        fullName : string <- $"$firstName $lastName";
    }

    Здесь, как простой пример, понятен даже дизайнеру, в принципе, ему можно объяснить декларации для отношений.

    А здесь:
    view BetterListView(model : BetterListModel)
    {
        <def itemToAdd = ""; />
        <form submit -> model.addItem(itemToAdd); >
                Add item: <input type = text; value <-> itemToAdd; valueUpdate = afterkeydown; />
                <button type = submit; enable <- !itemToAdd.IsEmpty; >Add</button>
        </form>
         
        <p>Your values:</p>
        <select multiple = multiple; height = 5; options <- model.items;  selectedOptions <-> selectedItems; />
         
        <div>
            <def selectedItems = []; />
            <button click -> model.removeItems(selectedItems); enable <- !selectedItems.IsEmpty; >Remove</button>
            <button click -> model.items.sort(); enable <- items.Length > 1; >Sort</button>
        </div>
    }
    
    model BetterListModel
    {
        items : list[string] = ["Fries", "Eggs Benedict", "Ham", "Cheese"];
        addItem(item : stirng) : void
        {
            items.Add(item);
        }
        remodeItems(itemsToRemove : list[ListItem[stirng]]) : void
        {
            items.RemoveAll(itemsToRemove);
        }
    }

    уже явно можно говорить только о программистах, даже только в рамках View.

    А здесь:
    view TemplatingView(model : PeopleModel)
    {
        <div content <- PeopleView(model); />
        <label><input type = checkbox; checked <-> showRenderTimes; /> Show render times</label>
    }
    
    view PeopleView(model : PeopleModel)
    {
        <h2>People</h2>
        <ul>
            <li foreach (person in model.people)>
                <div>
                    $(person.name) has <span text <- $"$(children().length)">&nbsp;</span> children:
                    <a click -> person.addChild(); >Add child</a>
                    <span class = "renderTime"; visible <- model.showRenderTimes; >
                        (person rendered at <span text = $"$(Date().getSeconds())"; />)
                    </span>
                </div>
                <div content <- ChildrenView(mode, person.children); />
            </li>
        </ul>
    }
    
    view ChildrenView(model : PeopleModel, children : list[string])
    {
        <ul>
            <li foreach (name in children)>
                $name
                <span class = "renderTime"; visible <- model.showRenderTimes; >
                    (child rendered at <span text = $"$(Date().getSeconds())"; />)
                </span>
            </li>
        </ul>
    }
    
    
    model PersonModel
    {
        name : string;
        children : list[string];
        addChild() : void
        {
            children.Add("New child");
        }
    }
    
    model PeopleModel
    {
        people : list[PersonModel] = [
            PersonModel("Annabelle", ["Arnie", "Anders", "Apple"]),
            PersonModel("Bertie", ["Boutros-Boutros", "Brianna", "Barbie", "Bee-bop"]),
            PersonModel("Charles", ["Cayenne", "Cleopatra"])
        ];
        showRenderTimes : bool = false;
    }

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

    Для Кложуры есть какой-то проект, где эмулируют этот knockoutjs. Там всё разделили: шаблоны отдельны, обработка, поведение тоже. Правда нет там деклараций для реактивности, и неясно будут ли (там всё в зачаточном состоянии). Но в Немерле ведь всё можно, пусть это будет как-то так:
    // оформим шаблон так для примера, теоретически он может быть во внешнем HTML-файле и как-то получен оттуда: 
    
    template HelloTempl
    {
    <html>
    <body>
        <p>First name: <input value type="text" name="firstName" /></p>
        <p>Last name: <input value type="text" name="lastName" /></p>
        <h2>Hello, <span id="fullName" />!</h2>
    }
    
    view HelloView(template: HelloTempl, model: HelloModel)
    {
        template.firstName <-> model.firstName;
        template.lastName <-> model.lastName;
        template.fullName <- model.fullName;
        
        //могут быть и другие настройки:
        template.anyElement.style = display: none;
    }
    
    model HelloModel
    {
        firstName : string = "Planet";
        lastName : string = "Earth";
        fullName : string <- $"$firstName $lastName";
    }

    Короче говоря, когда всё разделено, обычно, как-то проще жить, более гибче. Здесь HTML будет иметь натуральный вид, или можно использовать любой DSL для HTML (типа HAML), чтобы упростить, как минимум, теперь уже необходимость в явном указании атрибутов вида type="..." name="..." id = "..." и т.д. Кому-то проще набирать через Zen Coding и т.д. При этом, я думаю, что можно сохранить основные задуманные фишки: вычисления во время компиляции, какие нужно, контроль типов, ну и реактивность.

    Иными словами, если бы я занимался соответствующим проектом, то задумался бы, стоит ли делать только такие шаблоны по мотивам knockoutjs, во всяком случае, только ими ограничиться. Это сугубо моё личное имхо.
    Re: Языки общего назначения не имеют смысла!
    От: 11molniev  
    Дата: 12.04.12 15:35
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

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


    VE>>А как бы стоило сделать на твой взгляд?

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

    WH>Вот буквально только что презенташка попалась.

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

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


    Ну и что?
    Практическая ценность с этого какая? Честно говоря было бы уместней не подобные сравнения, в этот самый "ДСЛ" с перечнем его преимуществ как платформу для разработки и документацией. Если все действительно так радужно — то будет как C, C++ & co. Найдет свое место, а пока это нишевый продукт. Что как бы намекает, на общее назначение и смысл)) (во избежание споров — это шутка, а не противопоставление)
    Re[18]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 12.04.12 15:40
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

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


    G>Это мощность парсера. А еще семантика этих цепочек есть.


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

    Тебя же не смущает, что лексер вообще по регулярной грамматике бегает? Это только часть разбора.


    V>>Отсебятина из-за непонимания. кол-во писанины зависит исключительно от соотношения встроенных в язык/библиотеки ср-в и потребностей в них для конкретной задачи. В DSL это соотношение гораздо лучше для конкретного класса задач.

    G>Так это и есть та мощность языка, которую имеет смысл тут рассматривать.

    Это выразительность.
    Re[8]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 12.04.12 15:40
    Оценка:
    Здравствуйте, Tanker, Вы писали:

    WH>>В том, что бизнес задачами занимаются люди, которые дальше языков общего назначения ничего не видят.

    T>Других просто нет.
    Есть. И остальных переучивать надо.

    T>Враньё. Курс вроде компиляторов есть почти во всех серьехзных ИТ-вузах. Из своих наблюдений

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

    T>1. большинство программистов плохо знает математику

    И что?

    T>2. компиляторы хорошо идут только у тех кто хорошо знает математику

    Для того чтобы писать компиляторы матан знать не нужно. Вернее хватит весьма поверхностных знаний.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[26]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 12.04.12 15:40
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>А, ну так состав операций никак не изменился.

    Да я бы не сказал.

    S>Вообще, все нужные операции уже давно описаны Коддом.

    S>Проблема SQL — только в том, что в нём нет понятия "функция" в широком смысле. И тем более нет понятия "функция высшего порядка".
    На самом деле все гораздо хуже.

    A relation is a data structure which consists of a heading and an unordered set of tuples which share the same type.

    Те отношение не имеет порядка.
    В отношении не может быть дублей.
    На практике нам нужно нарушать оба условия.
    Таким образом, язык работы с БД не может быть построен на отношениях.
    Что на практике и происходит. Например, order by или top для отношений просто не имеют смысла.

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

    А раз у нас все на списках то можно использовать все наработки функциональных языков.
    Также можно использовать Liquid Types для того чтобы задавать спискам дополнительные ограничения. Например, что список содержит только уникальные элементы. Причем можно указать какие поля дают уникальность. Тогда при проекции, которая включает все эти поля, мы не потеряем информацию о том, что элементы в списке уникальны.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[27]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 12.04.12 15:44
    Оценка:
    Здравствуйте, Andrei N.Sobchuck, Вы писали:

    ANS>Т.е. `source` как параметр передать нельзя. И тут же ты говоришь, что relation это первоклассная сущность. Какой тогда критерий первоклассности чего-либо, если не (не)возможность передать это нечто аргументом в функцию?

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

    S>>Подзапросы не спасут вас от монолитности запроса — это всего лишь те же шесть страниц, записанные в другом порядке.

    ANS> Пожалуй, это проблемы хост-языка, а не самого SQL.
    Пожалуй, вы не понимаете, что такое язык. То, о чём я говорю — это проблемы именно SQL. SQL не предусматривает никакого "хост-языка", а способ, которым вы предлагате "решать это в Java" — ужасен. Ровно потому, что Java отвратительно приспособлена для работы с реляционными данными. Там есть функции, зато нет реляций как первоклассных сущностей. Примеры, которые я вам привел на linq, в Java будут выглядеть отвратительно.
    Ровно потому, что linq — это SQL с функциями. У него свои (достаточно унылые) ограничения, но в целом он гораздо ближе подошёл к решению реляционного вопроса, чем любая связка из GPPL и SQL.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[18]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 12.04.12 15:48
    Оценка:
    Здравствуйте, alex_public, Вы писали:

    V>>Тебя же не смущает, что в аббревиатуре UML последняя буква означает Language?


    _>Хгм, тут речь шла именно о формате данных, в котором редактор сохраняет данные на диск. Т.е. то что сам редактор является своеобразным графическим DSL я с самого начала не сомневался (хотя слово language тут конечно несколько сомнительно, но это мелочи).


    Чего сомнительного? ИМХО, это программистская привычка. Изначальный смысл слова "язык" — это вообще медиа. Ну, звук то бишь.
    До сих пор вроде есть языки, не имеющие текстового представления.


    _>Весь вопрос был в том, задаётся ли этот самый язык неким эфемерным способом через набор контролов, которыми манипулируют.


    У графических языков и спецификации графические.


    _>Или же мы можем просто формально считать обычным текстовым dsl'ом тот самый формат, в котором нарисованный интерфейс сохраняется на диск?


    У всяких CAD-ов обычно много поддерживаемых форматов для файла импорта/экспорта, но семантика графических элементов — постоянна. По крайней мере в рамках одного графического стандарта, если мы о схеме принципиальной, например, т.к. есть традиционо стандарты соц-лагеря, есть европейские и есть американские.


    _>Вот тут у меня и Sinclair мнения и разошлись. Но я не думаю что эту мелочь имеет смысл особо долго обсуждать — это скорее просто вопрос терминологии, что считать dsl, а что нет.


    Согласно определения — тот язык, который заточен на проблему. Если он позволяет решать и другие проблемы — ну это может быть побочным эффектом. Значит целевая проблема очень широка, т.е. для ее решения надо было много ср-в вводить, задевая крылом пересекающиеся области.
    Re[27]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 12.04.12 16:21
    Оценка: +1
    Здравствуйте, WolfHound, Вы писали:

    WH>На практике нам нужно нарушать оба условия.

    WH>Таким образом, язык работы с БД не может быть построен на отношениях.
    WH>Что на практике и происходит. Например, order by или top для отношений просто не имеют смысла.
    А, это-то фигня. Это тривиальное расширение понятия relation, и я про него в курсе. Просто в рамках этого топика не хотел переусложнять на ровном месте.

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

    Не, не списки. Список задаёт ad-hoc порядок, а нам интересен ключ упорядочивания и ещё кое-какие метаданные.

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

    WH>Также с ними будут работать все наработки в области реляционных БД просто по тому, что по факту они и работают со списками кортежей, а не с отношениями.
    Совершенно верно.

    WH>А раз у нас все на списках то можно использовать все наработки функциональных языков.

    WH>Также можно использовать Liquid Types для того чтобы задавать спискам дополнительные ограничения. Например, что список содержит только уникальные элементы. Причем можно указать какие поля дают уникальность. Тогда при проекции, которая включает все эти поля, мы не потеряем информацию о том, что элементы в списке уникальны.
    И при отборе тоже не потеряем, т.к. подсписок уникального списка — уникальный список.

    Осталось приделать к этому приемлемый синтаксис, и золотой ключик у нас в кармане.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[8]: Языки общего назначения не имеют смысла!
    От: PSV100  
    Дата: 12.04.12 16:53
    Оценка:
    Здравствуйте, alex_public, Вы писали:

    _>Не знал что Дельфи такая модная в этом смысле. ) Мы то её никогда не использовали по своми причинам и видимо никогда не будем. Но возможно что часть идей оттуда хорошо бы стащить. )))

    Естественно, ведь её популярность не на пустом месте была (кроме политических причин: распространённость Паскаля в учебных заведениях и развитость пиратства). И сейчас её уже столько лет все хоронят и хоронят, а она всё живёт себе и живёт (хотя, далеко не все хоронят).

    PSV>>Здесь рядом в своём сообщении WolfHound говорит о реактивном программировании на основе model-view. Вполне здравая идея, проверенная у нас. Удобно, когда подправил скрипт и сразу видишь результат неотходя от кассы, часто не нужны отладчики или debug-сообщения.


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

    Ну, не знаю, чтобы прям универсальный, всех удовлетворил, да чтобы и под С++ (как я понимаю, он прежде всего интересен). Можно в Qt глянуть, что там в последних версиях наворотили с их фактически JavaScript-програмлянием и CSS, может там есть какая-то реактивность, я не в курсе. А так, если кругом оглянуться, то можно найти немало всякой реактивности. Те же action-ы в Delphi, у них есть свойства Caption, Hint, ShortCut и пр., когда их изменяешь, то связанные элементы тоже себя обновляют. При этом одну и ту же action можно привязать нескольким элементам, например, пункту меню и кнопке на тулбаре, все себя сами корректируют. Также, например, action можно привязать к набору данных и указать, чтобы она следила за его состоянием, и когда, скажем, он пустой, то нужно себя запрещать, т.е. установить Enabled = false. В результате, например, если на экране пустая таблица, то кнопка "удалить" автоматом не работает (становится запрещенной). Всё настраивается в дизайнере или программируется.

    Или вот попался пример на WPF (я в нём не разбираюсь). Здесь TextBox будет виден только тогда, когда включён CheckBox (насколько приятно в таком XML ковыряться, я не в курсе, лично мне не очень):
    <Window x:Class="ParaPlan.Windows.Window1"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="Window1" Height="300" Width="300"
        xmlns:converters="clr-namespace:ParaPlan.Converters">
        <StackPanel Orientation="Vertical">
            <StackPanel.Resources>
                <converters:BooleanToHiddenVisibility x:Key="boolToVis"/>
            </StackPanel.Resources>
            <CheckBox Content="Check to show text box below me" Name="checkViewTextBox"/>
            <TextBox Text="only seen when above checkbox is checked"
                     Visibility="{Binding Path=IsChecked, ElementName=checkViewTextBox, Converter={StaticResource boolToVis}}"/>
        </StackPanel>
    </Window>


    Вот примерчик на JavaFX, когда он ещё скриптом был (вроде и сейчас есть, но сторонним проектом):
    package com.dieajax.sample.TrafficLight;
     
    import javafx.scene.Scene;
    import javafx.scene.text.Text;
    import javafx.stage.Stage;
    import javafx.scene.shape.Circle;
    import javafx.scene.paint.Color;
    import javafx.ext.swing.SwingComboBox;
    import javafx.ext.swing.SwingComboBoxItem;
    import javafx.scene.layout.VBox;
     
    def trafficColors : Color[] = [Color.RED, Color.YELLOW, Color.GREEN];
    def trafficColorNames : String[] = ["Red", "Yellow", "Green"];
    def trafficColorActions : String[] = ["Stop", "Slow", "Go"];
     
    class Model {
        var action: String;
        var selectedColorIndex: Integer on replace oldValue {
            action = trafficColorActions[selectedColorIndex];
        }
    }
     
    var trafficLightComboBox = SwingComboBox {
        translateX: 113
        width: 75
        selectedIndex: 2
        items: for (colorName in trafficColorNames)
            SwingComboBoxItem {
                text: colorName
            }        
        }
     
    var model = Model {
        selectedColorIndex: bind trafficLightComboBox.selectedIndex;
    };
     
    var trafficLight = Circle {
                centerX: 150
                centerY: 20
                radius: 20
                fill: bind trafficColors[model.selectedColorIndex]
            }
     
    var trafficLightText = Text {
                    x: 135
                    y: 10
                    content: bind model.action
                }
     
    Stage {
        title: "Die, Ajax! - Traffic Light Sample"
        width: 300
        height: 250
        scene: Scene {
            content: [
                    VBox {
                        spacing: 20
                        content: [trafficLight, trafficLightText, trafficLightComboBox]
                    }
            ]
        }
    }

    Здесь и модель можно увидеть, и биндинг (искать слово bind) и триггер на изменение переменной (выражение "on replace" — это лямбда, где доступно старое значение переменной).

    А я также под реактивной разработкой подразумеваю и реальную скорострельность в создании чего-то. Та же упомянутая Кложура позволяет, благодаря языку и платформе, реализовать некое динамическое приложение. Лисперы часто предпочитают эмакс, который для лисп-кода даёт больше удобств, чем любая IDE для С++-кода. Открыл буфер в эмаксе со скриптом из проекта, реализовал новую функцию, рядом в соседнем буфере набросал тестик, тут же его выполнил, проверил функцию, всё ОК, дал команду и где-то рядом запущенный процесс приложения тут же подхватил твои изменения и ты сразу видишь результат. Всё нормально, возвращается в эмакс в буфер с программой и начинаешь ваять следующую функцию. Можешь без тестирования и т.п. сразу любоваться своим творением. Всякий REPL тут же тебе в помощь и т.д.

    PSV>>Имхо, отличный подход, который можно взять на вооружение не только для веба.


    _>Ну вообще то например древние rc файлы тоже действовали по такому принципу. Т.е. там были только id, к которым потом обращался код. Правда не было разделения на структуру (html) и стили (css), но это уже мелочи. И я бы не сказал что из этого вышел очень удачный инструмент. Хотя для своего времени...


    Я в соседнем сообщении
    Автор: PSV100
    Дата: 12.04.12
    чуть подробнее написал, что я имел в виду.
    Re[11]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 12.04.12 16:57
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>>>1)В институте плохому учат. У них там все действительно сложнее, чем надо получается.

    WH>>>2)Сложность рукопашного кода всё равно больше. Чем сложность компилятора.
    T>>Не нужно передергивать.
    WH>В каком месте?

    В процитированом.

    T>>"Сложность рукопашного кода всё равно больше" — для каких задач ?

    WH>Для всех чей домен не является подмножеством используемого языка.
    WH>Те для чуть менее чем всех.

    Ну тогда навскидку"
    Как быть с теми, чей домен не сильно определен ?
    Как быть с теми, которые плохо формализованы ?
    Как быть с теми которые затрагивают сразу несколько доменов ?

    T>>Всегда ли нужно писать полноценное решение ?

    WH>А какое еще?

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

    T>>На примере CSV-парсера. В разных проектах, в которые пришлось сунуть нос, видел уже наверное под сотню парсеров, от простых вроде string.split до всяких регулярных выражений и тд. Работают все по разному, с разной степенью надежности, производительности и тд.

    WH>CSV? string.split'ом? Оригинально.

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

    T>>1 Покажи на примере этой простой задачи преимущества DSL.

    WH>Так это зависит от того что ты делаешь.
    WH>Скажи, зачем ты парсишь CSV?

    Импортирую данные которые кастомеры по отрасли хранят в CSV.

    T>>2 Всегда ли нужно писать полноценный парсер вроде CSV ?

    WH>А как иначе? Если нам нужно разобрать CSV то нам нужно писать его парсер.

    Я видел проекты где решения вроде string.split работали десятками лет. Для чего там полноценный парсер ? Я вот не смог объяснить, потому там и по сей день string.split.

    T>>3 Объясни, кем заменить тех, кто не в состоянии написать чтото большее string.split ?

    WH>Этих по-хорошему нужно гнать из профессии.

    Ни один бизнес не пойдет на такое решение.

    WH>Но если приспичило можно их посадить писать код на ДСЛ, который не дает делать плохие вещи.


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

    T>>DSL, хочешь ты или нет, это очень сложная тема.

    WH>Только для тех, кто ничего кроме книги дракона не видел.

    А большинство про неё даже не знают.
    The animals went in two by two, hurrah, hurrah...
    Re[9]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 12.04.12 17:00
    Оценка: :)
    Здравствуйте, WolfHound, Вы писали:

    WH>>>В том, что бизнес задачами занимаются люди, которые дальше языков общего назначения ничего не видят.

    T>>Других просто нет.
    WH>Есть. И остальных переучивать надо.

    Я боюсь что это утопия.

    T>>Враньё. Курс вроде компиляторов есть почти во всех серьехзных ИТ-вузах. Из своих наблюдений

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

    Это и показывает, что материал сложный. Когда материал простой, все студенты его на раз умеют.

    T>>2. компиляторы хорошо идут только у тех кто хорошо знает математику

    WH>Для того чтобы писать компиляторы матан знать не нужно. Вернее хватит весьма поверхностных знаний.

    Я и не говорил про матан, но по моему компиляторы это всего лишь часть математики.
    The animals went in two by two, hurrah, hurrah...
    Re[15]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 12.04.12 17:03
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

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


    O> Достаточно один раз написать, чтобы понять. Не велика проблема. Это как "hello, world".


    Я чет сомневаюсь что ты в любой задаче сможешь выдать качественное решение для общего случая решив её только единожды
    Пример — почему ты не предложил html+css примерно 40 лет назад ?
    The animals went in two by two, hurrah, hurrah...
    Re: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 12.04.12 17:08
    Оценка: +1 :)
    Здравствуйте, WolfHound, Вы писали:

    VE>>А как бы стоило сделать на твой взгляд?

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



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

    В кратце, люди создают инструментарий для себя
    1 орудийный == синтаксис
    2 понятийный == семантика

    Людие которые в разумные сроки могут п.2 + п.1 настолько мало, что их можно пересчитать по пальцам.
    The animals went in two by two, hurrah, hurrah...
    Re[28]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 12.04.12 17:09
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>А, это-то фигня. Это тривиальное расширение понятия relation, и я про него в курсе. Просто в рамках этого топика не хотел переусложнять на ровном месте.

    Тривиальность это вопрос десятый.
    Но нужно про это помнить.

    S>Не, не списки. Список задаёт ad-hoc порядок, а нам интересен ключ упорядочивания и ещё кое-какие метаданные.

    Одно другому не мешает.
    А ключ сортировки можно на это навесить при помощи тех же жидких типов.

    S>И при отборе тоже не потеряем, т.к. подсписок уникального списка — уникальный список.

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

    S>Осталось приделать к этому приемлемый синтаксис, и золотой ключик у нас в кармане.

    Не только еще и нормальную систему типов было бы неплохо прикрутить.
    Как минимум хочется алгебраических типов и вместо null использовать Option.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[10]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 12.04.12 17:11
    Оценка:
    Здравствуйте, Tanker, Вы писали:

    T>Это и показывает, что материал сложный. Когда материал простой, все студенты его на раз умеют.

    Нет. Это показывает, что студентов учат не правильному материалу.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[12]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 12.04.12 17:21
    Оценка: :)
    Здравствуйте, Tanker, Вы писали:

    WH>>Для всех чей домен не является подмножеством используемого языка.

    WH>>Те для чуть менее чем всех.
    T>Как быть с теми, чей домен не сильно определен ?
    Определить. Твой КО.

    T>Как быть с теми, которые плохо формализованы ?

    Формализовать. Можно итерациями. Это работает не хуже чем с библиотеками.

    T>Как быть с теми которые затрагивают сразу несколько доменов ?

    Чего? У задачи один домен.
    Большие задачи всегда можно разбить на маленькие, для которых легко определить домен.

    T>Импортирую данные которые кастомеры по отрасли хранят в CSV.

    Ничего не сказал.
    Куда ты их ипортируешь?
    Зачем ты их импортируешь?
    Не проще ли сказать базе данных, чтобы она их сама импортировала? Они умеют.

    T>Я видел проекты где решения вроде string.split работали десятками лет. Для чего там полноценный парсер ? Я вот не смог объяснить, потому там и по сей день string.split.

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

    T> Ни один бизнес не пойдет на такое решение.

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

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

    Написать. Это просто.

    T>А большинство про неё даже не знают.

    Нужно учиться. Или ты думаешь, куда ты попал?
    Программист это инженер, а не дворник. Он просто обязан быть хорошо подготовлен.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[16]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 12.04.12 17:34
    Оценка:
    Здравствуйте, Tanker, Вы писали:

    O>> Достаточно один раз написать, чтобы понять. Не велика проблема. Это как "hello, world".


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


    Прелесть подхода с употреблением DSL в том, что плевать на общие случаи, и решать надо всегда лишь примитивные частные задачи. Общее решение, при необходимости, само получится. Потом.

    T>Пример — почему ты не предложил html+css примерно 40 лет назад ?


    40 лет назад от этого html-а никакой пользы не было бы, а css отображать было не на чем.

    А вот когда html таки появился, я сразу говорил что это чушь, и что все делают заведомо неправильно. Недоумевал, почему вылезло это SGML-отродье и почему забыли про DPS и другие умные технологии. Да что там — latex тот же уже на всю катушку был популярен (и Тим Барнс-Ли его прекрасно знал, как и про DPS). Но все равно родилась фигня, а до хотя бы отдаленно приличного состояния вся эта шелуха не дошла и по сей день.
    Re[12]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 12.04.12 17:40
    Оценка: +1
    Здравствуйте, Tanker, Вы писали:

    T>Ну тогда навскидку"

    T>Как быть с теми, чей домен не сильно определен ?
    T>Как быть с теми, которые плохо формализованы ?
    T>Как быть с теми которые затрагивают сразу несколько доменов ?

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

    T>Наиболее дешовое, которое подходит для текущего случая. Бюджеты вобщем не резиновые.


    А проще и дешевле чем с DSL уже и некуда.

    WH>>Скажи, зачем ты парсишь CSV?


    T>Импортирую данные которые кастомеры по отрасли хранят в CSV.


    Куда?

    T>Я видел проекты где решения вроде string.split работали десятками лет. Для чего там полноценный парсер ?


    А что такое "полноценный парсер"? Такой, который escape всякие поймет, да кавычки корректно прочитает? Ну так он действительно необходим, тупое решение будет работать до первого же не-тупого CSV от "кастомеров по отрасли" (уж не знаю, кто это такие, но звучит страшно).

    T> Я вот не смог объяснить, потому там и по сей день string.split.


    Достаточно показать валидный CSV который этот split сломает. Чего там объяснять-то?

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


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

    T>>>DSL, хочешь ты или нет, это очень сложная тема.

    WH>>Только для тех, кто ничего кроме книги дракона не видел.

    T>А большинство про неё даже не знают.


    У них огромное преимущество — они не испорчены и не напуганы.
    Re[10]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 12.04.12 17:42
    Оценка:
    Здравствуйте, Tanker, Вы писали:

    WH>>Ибо все, что люди из него выносят это то, что компиляторы это что-то сложное.

    WH>>При этом реальных навыков создания компиляторов они не получают. По тому и говорю, что не учат.

    T>Это и показывает, что материал сложный. Когда материал простой, все студенты его на раз умеют.


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

    T>Я и не говорил про матан, но по моему компиляторы это всего лишь часть математики.


    Так любую хоть немного формализуемую (пусть даже только в бредовых фантазиях формализуемую) отралсь можно обозвать "частью математики".
    Re[2]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 12.04.12 17:43
    Оценка:
    Здравствуйте, Tanker, Вы писали:

    T>В кратце, люди создают инструментарий для себя

    T>1 орудийный == синтаксис
    T>2 понятийный == семантика

    T>Людие которые в разумные сроки могут п.2 + п.1 настолько мало, что их можно пересчитать по пальцам.


    Вот как раз это утверждение совершенно не соответствует действительности. Это может любой школьник. Не напрягаясь. Если вооружится правильным подходом и если не испортит себе мозги драконьими книгами и матаном.
    Re[20]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 12.04.12 18:28
    Оценка:
    Здравствуйте, Andrei N.Sobchuck, Вы писали:


    ANS>Тот же Word+VB умеет работать с COM. Чем это отличается от С с библиотеками?


    VB умеет импортировать ф-ии из DLL. Потому что он не скрипт, а полноценный язык программирования. Но VBScript не умеет. А с COM работает только через ф-ию CreateObject, которую ему предоставляет хост.


    ANS>А то получается, что С без библиотек это DSL, а с — нет.


    На С и на VB можно писать эти библиотеки. И подключать любые имеющиеся. Вот такое маленькое отличие. Хотя... никто не мешает хосту дать возможность подключать библиотеки. Я похожим образом поступал несколько раз во время хостинга JS для прикладных нужд.
    Re[16]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 12.04.12 18:33
    Оценка:
    Здравствуйте, Andrei N.Sobchuck, Вы писали:

    ANS>Я к тому, что наличие "встроенного" класса "Документы" ничем таким не отличается от класса "Документы" в Java/C#, чтобы язык со встроенным классом стал DSL.


    Он только синтаксисом не отличается. Но реально отличается всем. Возьми для сравнения скриптовый объект JS — они все одинаково устроены. А в 1C встроенные объекты имеют уникальное устройство каждый, но для тебя эта уникальность скрыта за однообразным синтаксисом. Разве не в этом задача DSL — скрывать подробности относительно реализации предметной области?


    V>>Тебя синтаксис языка в заблуждение ввел, похоже.

    ANS>DSL нужен человеку -> вся суть DSL в синтаксисе (а если не вся, то 80% точно, т.е. таки вся).

    Ну таки да. Разве что этот синтаксис у некоторых вызывает устойчивые ассоциации с ранее виденным.
    Re[13]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 12.04.12 18:35
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>Но это как раз неинтересно. Интересно, когда вам нужно передать данные из одного контрола или формы в другой. Вот коллега Wolfhound предлагает делать это через биндинги и ViewModel, а от событий (как я понял) отказаться вовсе.

    Совсем не получится.
    Ибо есть кнопки по нажатию на которые обычно нужно что-то сделать.
    Но в остальном вполне можно и без обработчиков жить.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[19]: Языки общего назначения не имеют смысла!
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 12.04.12 19:03
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    V>>>Отсебятина из-за непонимания. кол-во писанины зависит исключительно от соотношения встроенных в язык/библиотеки ср-в и потребностей в них для конкретной задачи. В DSL это соотношение гораздо лучше для конкретного класса задач.

    G>>Так это и есть та мощность языка, которую имеет смысл тут рассматривать.

    V>Это выразительность.


    Ок, напиши вместо мощности выразительность. Чтонить изменится? Мы тут не корректность терминов обсуждаем.
    Re[10]: Просто мысль...
    От: WolfHound  
    Дата: 12.04.12 19:29
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    O> Ну так я смогу определить такую функцию и в том же модуле ей воспользоваться? А смогу из макроса воспользоваться другими функциями из этого модуля?

    Да. Да.
    В том числе рекурсивно.

    WH>>Именно. Причем типизация будет полностью декларативна. Я уже и матаном на эту тему обчитался.

    O> Вот этого я и боюсь. Может получиться неприемлемо сложно.
    С этим я как раз борюсь.
    Для этого матаном и обчитался.
    Ибо хочу вместо того чтобы заставить человека писать вывод типов (это сложно шо писец) написать декларативный код проверки типов.
    И по нему уже сгенерировать вывод типов.
    Уверен использовать это будет очень просто.

    O> Иногда типы могут зависеть от типизации вложенных макр, которых нет (и про которые мы ничего не знаем) до тех пор, пока AST не развернули. Когда я пытался прикрутить типизированную макросистему к ML я по этим граблям походил. В Nemerle система типов несколько более человечная, так что не берусь утверждать, что трудности непреодолимы.

    В Н2 идеология другая.
    А системы типов вообще нет. Ибо это не язык, а движок для создания языков.
    Ибо, например мой генератор парсеров имеют свою систему типов не похожую на другие языки.

    Основная идея состоит в том, что каждая конструкция имеет, не только правила разбора, но и правила типизации.
    Таким образом, мы можем полностью типизировать программу до переписывания в язык более низкого уровня.
    Скажем в режиме ИДЕ, переписывание производится, вообще не будет.
    Ибо все ошибки компиляции и так будут известны.

    Скажем для if будет что-то типа такого (очень предварительный вариант):
    abstract rule Expr
    {
        Type : LangType;
    }
    
    rule IfExpr is Expr
    syntax "if" "(" cond : Expr ")" expr1 : Expr "else" expr2 : Expr;
    {
      assert(cond.Type == #bool, "Condition type must be bool.");
      assert(Type <= expr1.Type && Type <= expr2.Type, "Branch types must be convertible to same type.");
    }


    O> Обоснуете? Чем плоха возможность пользоваться определениями сразу, не отходя от кассы?

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

    O> Ну, по этому вопросу лучше не дискутировать, у меня прямо противоположное мнение —

    По которому из трех пунктов?

    Тормозит, жрет память и главное ошибки не ловит.


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

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

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

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

    Н2 не будет навязывать систему типов языку который на нем разрабатывается.
    Это моя принципиальная позиция.
    Это будет обеспечено тем, что иерархия языков будет весьма ветвистой и глубокой.
    Те не будет какого-то одного языка, под который все обязаны подстроиться.

    O> Пусть он другой, но если он ограничивает возможности реализации иерархических макросов, то он должен как минимум предоставлять что-то взамен. Что-то не менее ценное.

    Я это понимаю. И изначально создаю систему с прицелом на иерархию языков.
    Разница с макрами в том, что макры всё же завязаны на конкретный язык. И упираются в его ограничения.
    У меня этого не будет.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[11]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 12.04.12 20:13
    Оценка: 60 (1) +1
    Здравствуйте, oldjackal, Вы писали:

    O> Вам нравятся грамматики со сложными правилами приоритетов? А я вот такой код читать не могу совершенно, если там есть что-то сложнее школьной арифметики. И писать такой код не могу, я всегда скобочки расставляю явным образом. Не хочу и не могу помнить, больше у '%' приоритет чем у '+' или меньше.

    Это дело вкуса.
    Большинство людей это не напрягает.

    WH>>У меня обе без мемоизации работают. Ключевые слова Pratt parser.

    WH>>У меня алгоритм основа на нем.
    O> Как-то информации по нему мало, кроме самой оригинальной статьи.
    Есть такое.
    http://javascript.crockford.com/tdop/tdop.html
    Бред про то, что оно заточено под динамически типизированные языки пропускай мимо ушей.

    O> Совсем нет? Так не бывает. Но вы меня заинтересовали, попробую узнать про Pratt-а побольше. Есть какие-то ссылки по теме, которые гугл и википедия не дадут?

    У меня нельзя делать непрямую левую рекурсию.
    Те это правильно:
    pow is expr = expr : 31 '^'s expr : 30;
    Тк левая рекурсия идет в правило, которое расширяется.

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

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

    O> Естественно, воспользоваться я этим смогу только если алгоритм позволяет писать парсеры руками, на C или шарпе, без всяких генераторов.

    С этим как раз все просто.
    Пратт простой как пробка.

    WH>>Да я не спорю. Но существующие языки тоже нужно разбирать.

    O> К задаче реализации DSL это особого отношения не имеет, к счастью.
    Но у меня это требование есть.
    Ибо одна из задачь парсить C# и Java.
    Чтобы дать людям возможность взять готовый проект и начать добавлять туда макры.

    WH>>Мне хватает скорости, чтобы все распарсить.

    O> Даже если там сто тысяч строк кода?
    Nemerle.Peg пару метров в секунду на грамматике C# дает.

    WH>>Я это понимаю. И собираюсь сделать язык описания ошибочных ситуаций.

    O> А это не ошибочная ситуация. Это предупреждение.
    Тогда видимо я что-то не понял.
    Я думал ты про восстановление после ошибок говоришь.

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

    O> Очень интересно. Я пока что не представляю себе, как это можно сделать декларативно.
    Пока в процессе. Так что конкретного ответа пока не дам.

    O> Мне Packrat интересен как раз тем, что его можно и руками делать, без DSLей, без генераторов.

    Так там как раз генератор.

    O> Семантика то как раз прозрачна, поскольку не далеко ушла от привычной семантики низлежащего языка.

    Вот ту не могу согласиться.
    Ибо ДСЛ для того и создают чтобы уйти от семантики языка более низкого уровня.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[25]: Языки общего назначения не имеют смысла!
    От: Vain Россия google.ru
    Дата: 12.04.12 20:41
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

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

    S>>>А если вам нужно посчитать какие-то агрегаты по результату join восьми таблиц, и при этом ещё иметь гарантии ACID, то вручную вы это делать замаетесь.
    V>>Ну что вы мне сказки рассказываете? Специалист по SQL это такой же специалист по C++ или java, а это самостоятельные языки.
    S>Я не понял вашу фразу.
    Меня терзают смуутные сомнения (c)
    Какую именно?
    [In theory there is no difference between theory and practice. In
    practice there is.]
    [Даю очевидные ответы на риторические вопросы]
    Re[8]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 12.04.12 22:48
    Оценка: 31 (1)
    Здравствуйте, vdimas, Вы писали:

    V>ИМХО, SELECT оператор SQL спроектирован превосходно, т.к. обладает реляционной полнотой и при этом отличной читабельностью.


    С читабельностью, увы, не очень хорошо, особенно в его оригинальной версии. И совсем плохо с декомпозицией (я знаю про СТЕ и пользовательские функции, но этого очень мало). Впрочем, качество дизайна SQL относительно терпимо.

    V> И да, SQL-ем после некоторого навыка может пользоваться даже не программист. И его разрабатывали не с потолка, это был результат обобщения многолетнего опыта разработки и эксплуатации первой промышленной БД.


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

    V>ИМХО, это хорошо, что последние годы в кремнии встряли, т.е. не ожидается такого роста быстродействия...


    Да не встрял никто в кремнии. Просто у Интела исчезла в high end процессорах конкуренция и он начал искусственно тормозить прогресс.

    V>Для некоторых нужд я бы променял. Только не по физической структуре, а по некоторому АПИ итерирования по данным. Из-за того, что сложные вычисления на SQL не айс, т.к. интерпретатор.


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

    V> А преобразовать реляционные исчисления в реляционные уравнения — не бог весть какая наука.


    Я тебе больше скажу — оказывается, можно преобразовать реляции SQL в навигации NoSql и обратно.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[13]: Языки общего назначения не имеют смысла!
    От: alex_public  
    Дата: 13.04.12 03:26
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>Поздравляю, вы почти изобрели .dfm. Один-в-один. С точностью до способа группировки — индентация вместо явного object ... end.

    А dfm тоже компилировали в C++ или что-то подобное? Тогда это был не плохой dsl наверное. Возможно стоит какие-то идеи взять с него.

    S>Вы же только что критиковали "языки размётки", в которых "всего лишь привязываются обработчики, написанные на системном языке". И тут же делаете то же самое. Принципиальный момент, которого тут не хватает — согласование сигнатур. Грубо говоря, хорошо, когда у вас евенты без параметров, и методы без параметров.

    Ну во-первых тут как раз видно два вида вызовов — из системного языка и непосредственно из gui объекта. Т.е. уже не просто язык размётки. Потом в любом случае необходимы составные операторы типа:
    onclick
        [calculate]
        this.Update


    Далее, я думаю что что бы полностью замкнуть весь интерфейс на себе только вызовов будет недостаточно — нужны ещё какие-то операторы для логики. Не знаю насколько универсальные. Но допустим возможность писать код типа такого:
    onrclick
        if Tree.selected
            ContextMenu.Show

    должна там быть.

    и т.д...

    S>Но это как раз неинтересно. Интересно, когда вам нужно передать данные из одного контрола или формы в другой. Вот коллега Wolfhound предлагает делать это через биндинги и ViewModel, а от событий (как я понял) отказаться вовсе.


    Такой вариант может быть ещё интереснее, но я пока так до конца и не представил его себе вне html+javascript области. Вот может кто-нибудь написать мне пример для решения буквально той же простейшей задачи (что я приводил выше с парой окон) на подобном dsl? Т.е. я понимаю что всю мощь mvvm на нём не продемонстрируешь, но ведь наш язык должен хорошо решать и тривиальные задачи...
    Re[26]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 13.04.12 03:27
    Оценка:
    Здравствуйте, Vain, Вы писали:

    V>Какую именно?

    Специалист по SQL это такой же специалист по C++ или java, а это самостоятельные языки

    Расшифруйте.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[14]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 13.04.12 03:32
    Оценка:
    Здравствуйте, alex_public, Вы писали:
    _>А dfm тоже компилировали в C++ или что-то подобное? Тогда это был не плохой dsl наверное. Возможно стоит какие-то идеи взять с него.
    DFM — это язык разметки, принятый в VCL. Его не надо было "компилировать в C++", потому что классы VCL умели его десериализовывать напрямую.

    _>Ну во-первых тут как раз видно два вида вызовов — из системного языка и непосредственно из gui объекта.

    Нет, не видно тут никаких разных видов вызовов. Вы вызываете метод либо формы, либо одного из контролов на форме.
    С точки зрения VCL, например, они совершенно одинаковы. Главное, чтобы была доступна метаинформация об этих методах — для выполнения связывания.

    Т.е. уже не просто язык размётки. Потом в любом случае необходимы составные операторы типа:
    _>
    onclick
    _>    [calculate]
    _>    this.Update

    _>Далее, я думаю что что бы полностью замкнуть весь интерфейс на себе только вызовов будет недостаточно — нужны ещё какие-то операторы для логики. Не знаю насколько универсальные. Но допустим возможность писать код типа такого:
    _>
    onrclick
    _>    if Tree.selected
    _>        ContextMenu.Show

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

    _>Такой вариант может быть ещё интереснее, но я пока так до конца и не представил его себе вне html+javascript области. Вот может кто-нибудь написать мне пример для решения буквально той же простейшей задачи (что я приводил выше с парой окон) на подобном dsl?

    Ну, пусть WolfHound прокомментирует.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[21]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 13.04.12 03:46
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    V>На С и на VB можно писать эти библиотеки.

    Не-не-не-не-не, Дэвид Блейн. Это получается бесконечная рекурсия. Вот, допустим, в чистом C у нас нет возможности работать с портами 8086. Подключив библиотеку, я могу добавить туда эту возможность через inp() и outp().
    Но каким образом я напишу эту библиотеку на С? Если бы я мог обращаться к портам на С, мне не потребовалась бы библиотека.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[19]: Языки общего назначения не имеют смысла!
    От: alex_public  
    Дата: 13.04.12 03:51
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    V>Чего сомнительного? ИМХО, это программистская привычка. Изначальный смысл слова "язык" — это вообще медиа. Ну, звук то бишь.

    V>До сих пор вроде есть языки, не имеющие текстового представления.

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

    V>У графических языков и спецификации графические.


    Ну так тогда это совпадает с моей точкой зрения и спорить надо с Sinclair. )))
    Re[9]: Языки общего назначения не имеют смысла!
    От: alex_public  
    Дата: 13.04.12 04:13
    Оценка:
    Здравствуйте, PSV100, Вы писали:

    PSV>Естественно, ведь её популярность не на пустом месте была (кроме политических причин: распространённость Паскаля в учебных заведениях и развитость пиратства). И сейчас её уже столько лет все хоронят и хоронят, а она всё живёт себе и живёт (хотя, далеко не все хоронят).


    Краем уха слышал, что там ещё некий Lazarus набирает силу. )

    PSV>Или вот попался пример на WPF (я в нём не разбираюсь). Здесь TextBox будет виден только тогда, когда включён CheckBox (насколько приятно в таком XML ковыряться, я не в курсе, лично мне не очень):

    PSV>
    PSV><Window x:Class="ParaPlan.Windows.Window1"
    PSV>    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    PSV>    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    PSV>    Title="Window1" Height="300" Width="300"
    PSV>    xmlns:converters="clr-namespace:ParaPlan.Converters">
    PSV>    <StackPanel Orientation="Vertical">
    PSV>        <StackPanel.Resources>
    PSV>            <converters:BooleanToHiddenVisibility x:Key="boolToVis"/>
    PSV>        </StackPanel.Resources>
    PSV>        <CheckBox Content="Check to show text box below me" Name="checkViewTextBox"/>
    PSV>        <TextBox Text="only seen when above checkbox is checked"
    PSV>                 Visibility="{Binding Path=IsChecked, ElementName=checkViewTextBox, Converter={StaticResource boolToVis}}"/>
    PSV>    </StackPanel>
    PSV></Window>
    PSV>


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

    PSV>Я в соседнем сообщении
    Автор: PSV100
    Дата: 12.04.12
    чуть подробнее написал, что я имел в виду.


    Да, я посмотрел — это как раз ближе к тому, что мне интересно для нативных предложений, но что я не стал бы применять в вебе (это я про первый пример оттуда). В современной веб разработке обычно стараются уйти от каких либо намёков на код внутри html. А тут некие привязки и т.п. В то же время для приложения с нативным интерфесом это возможно было бы удобно, причём возможно даже можно было совместить в единое целое view и view-model.

    А разница на мой взгляд в том, что под дизайном в случае сайта и в случае приложения с нативным интерфейсом частенько подразумеваюся достаточно различающиеся вещи.
    Re[15]: Языки общего назначения не имеют смысла!
    От: alex_public  
    Дата: 13.04.12 05:28
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>DFM — это язык разметки, принятый в VCL. Его не надо было "компилировать в C++", потому что классы VCL умели его десериализовывать напрямую.


    Там был какой-то практический смысл тащить в рантайм лишнюю сущность или это просто "так реализовали"?

    S>Нет, не видно тут никаких разных видов вызовов. Вы вызываете метод либо формы, либо одного из контролов на форме.

    S>С точки зрения VCL, например, они совершенно одинаковы. Главное, чтобы была доступна метаинформация об этих методах — для выполнения связывания.

    Как раз есть. Изнутри dsl мы чётко видим два вида вызовов: родные вызовы контролов и некий внешний вызов куда-то там. Да, при той реализации компиляции языка, что я предложил, они потом оказывались членами одного C++ класса. Но это уже вне языка (dsl) и только одна реализация, простейшая, которую я бы мог сам с ходу закодировать. А можно же представить себе много других вариантов. Например dsl компилируется непосредственно в последовательности вызовов win api (или же gtk api или же android api, в зависимости от целевой платформы), а наша функция calculate вообще написана на ассемблере и подключается через библиотеку. И это всё будет работать и в одной реализации и в другой, для одного и того же dsl кода.

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


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

    Пока писал это, пришёл в голову альтернативный вариант. Я вроде уже писал что не исключаю вариант такого dsl реализованый как встроенный в системный язык. Т.е. условно говоря вот у нас сейчас есть визуальный редактор умеющий генерировать C++ (допустим для примера) код. При этом он не задаёт никаких отношений логики между элементами, максимум отношения взаимного расположения. Если мы добавим возможность вставлять в редакторе код обработчиков на неком простеньком языке (а не имя функции как сейчас), то получим возможность удобно задавать и логику интерфейса. Причём редактор в принципе может сильно подсказывать при редактирование обработчика, т.к. он видит все существующие сущности и т.п. Да, так вот, а этот самый простенький язык в принципе можно реализовать на макросах или шаблонах C++. Соответственно получаем готовую систему минимальными усилиями и даже без создания дополнительных парсеров/компиляторов. Эх, было бы сейчас свободное время, может быть даже попробовал бы сам (код того визуального редактора в открытом доступе, так что...) такой вариант набросать.
    Re[11]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 13.04.12 07:42
    Оценка: -2 :))
    Здравствуйте, WolfHound, Вы писали:

    T>>Это и показывает, что материал сложный. Когда материал простой, все студенты его на раз умеют.

    WH>Нет. Это показывает, что студентов учат не правильному материалу.

    Если так, то это значит, что тема компиляторов сложна даже для преподавателей.
    The animals went in two by two, hurrah, hurrah...
    Re[17]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 13.04.12 07:53
    Оценка: -2
    Здравствуйте, oldjackal, Вы писали:

    O> Прелесть подхода с употреблением DSL в том, что плевать на общие случаи, и решать надо всегда лишь примитивные частные задачи. Общее решение, при необходимости, само получится. Потом.


    А для чего дсл для примитивных частных задач ? их тыщи. ДСЛ нужен там где можно закрыть общий случай.

    T>>Пример — почему ты не предложил html+css примерно 40 лет назад ?


    O> А вот когда html таки появился, я сразу говорил что это чушь, и что все делают заведомо неправильно. Недоумевал, почему вылезло это SGML-отродье и почему забыли про DPS и другие умные технологии. Да что там — latex тот же уже на всю катушку был популярен (и Тим Барнс-Ли его прекрасно знал, как и про DPS). Но все равно родилась фигня, а до хотя бы отдаленно приличного состояния вся эта шелуха не дошла и по сей день.


    Вот-вот. А сейчас для UI считай ничего лучше html+css вобщем то и нет. А говоришь одного раза достаточно.
    The animals went in two by two, hurrah, hurrah...
    Re[13]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 13.04.12 07:59
    Оценка:
    Здравствуйте, oldjackal, Вы писали:


    T>>Как быть с теми, чей домен не сильно определен ?

    T>>Как быть с теми, которые плохо формализованы ?
    T>>Как быть с теми которые затрагивают сразу несколько доменов ?

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


    Предполагается что понятия и отношения привезет волшебник в голубом вертолете ?

    T>>Импортирую данные которые кастомеры по отрасли хранят в CSV.


    O> Куда?


    В модель данных.

    O> А что такое "полноценный парсер"? Такой, который escape всякие поймет, да кавычки корректно прочитает? Ну так он действительно необходим, тупое решение будет работать до первого же не-тупого CSV от "кастомеров по отрасли" (уж не знаю, кто это такие, но звучит страшно).


    Вопрос был — "зачем" ? Не можешь ответить ?

    T>> Я вот не смог объяснить, потому там и по сей день string.split.

    O> Достаточно показать валидный CSV который этот split сломает. Чего там объяснять-то?

    Недостаточно.

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

    O> Те, кто не способен dsl написать, не справятся и с тупым решением задачи, требующей экспертизы в нескольких областях.

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

    T>>А большинство про неё даже не знают.


    O> У них огромное преимущество — они не испорчены и не напуганы.


    Они просто ничего не хотят знать, при том что уже гарантировано получают очень неплохую ЗП.
    The animals went in two by two, hurrah, hurrah...
    Re[11]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 13.04.12 08:01
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    WH>>>Ибо все, что люди из него выносят это то, что компиляторы это что-то сложное.

    WH>>>При этом реальных навыков создания компиляторов они не получают. По тому и говорю, что не учат.

    T>>Это и показывает, что материал сложный. Когда материал простой, все студенты его на раз умеют.


    O> Неверно. При паршивом преподавании любой материал сложным покажется. А в данном случае вообще нужный материал и не дают, а только грузят абсолютно несущественной ерундой, 100% из которой на практике не пригодится совершенно. То, что пригодится, как раз и не дают.


    Не хочешь ли ты сказать, что преподаватели сами не понимают этот материал ?
    Откуда тогда возьмется та самая простота ?
    И как объяснить тот факт, что преподаватели одни и те же, а одни предметы усваиваются хорошо, а другие — плохо ?

    T>>Я и не говорил про матан, но по моему компиляторы это всего лишь часть математики.


    O> Так любую хоть немного формализуемую (пусть даже только в бредовых фантазиях формализуемую) отралсь можно обозвать "частью математики".


    Так в том то и дело
    The animals went in two by two, hurrah, hurrah...
    Re[13]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 13.04.12 08:20
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    T>>Как быть с теми, чей домен не сильно определен ?

    WH>Определить. Твой КО.

    А бизнесу сказать: "Ребята, заносите миллионы долларов через пять-десять лет, пока мы всё формализуем и напишем классный DSL"

    T>>Как быть с теми, которые плохо формализованы ?

    WH>Формализовать. Можно итерациями. Это работает не хуже чем с библиотеками.

    T>>Как быть с теми которые затрагивают сразу несколько доменов ?

    WH>Чего? У задачи один домен.

    Это у тебя так.

    WH>Большие задачи всегда можно разбить на маленькие, для которых легко определить домен.


    Где взять DSL на все случаи жизни ? Кто будет семантику реализовывать ?

    T>>Импортирую данные которые кастомеры по отрасли хранят в CSV.

    WH>Ничего не сказал.
    WH>Куда ты их ипортируешь?

    Из CSV файлов.

    WH>Зачем ты их импортируешь?


    Кастомер так хочет. Там его данные. Он хочет с ними работать в нашем приложении.

    WH>Не проще ли сказать базе данных, чтобы она их сама импортировала? Они умеют.


    Спасибо, ты открыл Америку. Осталось самое малое — вписать эту фичу в конкретные сценарии. Тут окажется, что прежде чем совать файл базе данных, уже нужно залезть в этот файл что бы посмотреть, что там такое. По этой причине мы например отказались от БД в качестве основного парсера CSV


    T>>Я видел проекты где решения вроде string.split работали десятками лет. Для чего там полноценный парсер ? Я вот не смог объяснить, потому там и по сей день string.split.

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

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

    T>> Ни один бизнес не пойдет на такое решение.

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

    Ты наверное думаешь, что раз программист двое круче, то и профит у бизнеса будет вдвое больше ? Стоимость разработки <10% от стоимости всех затрат. И часто нужно не просто уметь программировать, но и понимать всю специфику бизнеса. Как правило, второе всегда важнее первого.

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

    WH>Написать. Это просто.

    А волшебник в голубом вертолете формализует каждую из областей и реализует семантику ?

    T>>А большинство про неё даже не знают.

    WH>Нужно учиться. Или ты думаешь, куда ты попал?

    Кому ? Для чего ? Вот приходит вчерашний студент на работу, получает сходу ЗП которые выше раз в пять чем средняя по стране.
    Откуда у него будет мотив учиться ?

    WH>Программист это инженер, а не дворник. Он просто обязан быть хорошо подготовлен.


    Люди обычно учатся, что бы чего то добиться, а не просто так, от любви к процессу.
    Чего нужно добиваться инженеру ? Квартиру, машину, детей ?
    На это хватит той ЗП которую получает молодой специалит, т.е. вчерашний студент, а если он еще пару леваков прихватит, то еще и самолет прикупит.
    The animals went in two by two, hurrah, hurrah...
    Re[3]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 13.04.12 08:22
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    T>>В кратце, люди создают инструментарий для себя

    T>>1 орудийный == синтаксис
    T>>2 понятийный == семантика

    T>>Людие которые в разумные сроки могут п.2 + п.1 настолько мало, что их можно пересчитать по пальцам.


    O> Вот как раз это утверждение совершенно не соответствует действительности. Это может любой школьник. Не напрягаясь.


    И что же толпы школьников никак не могут выдать внятный DSL для описания вечной проблемы — UI ?
    The animals went in two by two, hurrah, hurrah...
    Re[12]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 13.04.12 08:28
    Оценка:
    Здравствуйте, Tanker, Вы писали:

    WH>>Нет. Это показывает, что студентов учат не правильному материалу.

    T>Если так, то это значит, что тема компиляторов сложна даже для преподавателей.
    Раньше преподавали, что земля плоская и на трех китах стоит.
    Не по тому, что гелиоцентрическая система это что-то сложное, а по тому, что просто не знали как на самом деле. Только и всего.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[14]: Языки общего назначения не имеют смысла!
    От: koodeer  
    Дата: 13.04.12 08:32
    Оценка: :)
    Здравствуйте, Tanker, Вы писали:

    T> И часто нужно не просто уметь программировать, но и понимать всю специфику бизнеса. Как правило, второе всегда важнее первого.


    Специфика бизнеса — это и есть domain-specific
    Вывод: DSL рулят!
    Re[12]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 13.04.12 08:36
    Оценка: +1 -2
    Здравствуйте, Tanker, Вы писали:

    T>>>Это и показывает, что материал сложный. Когда материал простой, все студенты его на раз умеют.

    WH>>Нет. Это показывает, что студентов учат не правильному материалу.

    T>Если так, то это значит, что тема компиляторов сложна даже для преподавателей.


    Ну вот зачем говорить глупости с таким упрямством?

    Вам же говорят, что академичекое представление об этом примере нелепое и переусложненное. Это болезнь всех "теоретиков". И к реальной практике все это не имеет ровным счетом никакого отношения.
    Re[18]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 13.04.12 08:39
    Оценка:
    Здравствуйте, Tanker, Вы писали:

    O>> Прелесть подхода с употреблением DSL в том, что плевать на общие случаи, и решать надо всегда лишь примитивные частные задачи. Общее решение, при необходимости, само получится. Потом.


    T>А для чего дсл для примитивных частных задач ? их тыщи. ДСЛ нужен там где можно закрыть общий случай.


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

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

    O>> А вот когда html таки появился, я сразу говорил что это чушь, и что все делают заведомо неправильно. Недоумевал, почему вылезло это SGML-отродье и почему забыли про DPS и другие умные технологии. Да что там — latex тот же уже на всю катушку был популярен (и Тим Барнс-Ли его прекрасно знал, как и про DPS). Но все равно родилась фигня, а до хотя бы отдаленно приличного состояния вся эта шелуха не дошла и по сей день.


    T>Вот-вот. А сейчас для UI считай ничего лучше html+css вобщем то и нет. А говоришь одного раза достаточно.


    А не надо сравнивать столь сложную тему (UI) с такой примитивной и убогой как разработка и реализация языков.
    Re[14]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 13.04.12 08:43
    Оценка: +1
    Здравствуйте, Tanker, Вы писали:

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


    T>Предполагается что понятия и отношения привезет волшебник в голубом вертолете ?


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

    T>>>Импортирую данные которые кастомеры по отрасли хранят в CSV.


    O>> Куда?


    T>В модель данных.


    Какую модель? В каком виде представленную?

    O>> А что такое "полноценный парсер"? Такой, который escape всякие поймет, да кавычки корректно прочитает? Ну так он действительно необходим, тупое решение будет работать до первого же не-тупого CSV от "кастомеров по отрасли" (уж не знаю, кто это такие, но звучит страшно).


    T>Вопрос был — "зачем" ? Не можешь ответить ?


    Затем, что иначе это не будет поддежкой CSV. Потому как валидный CSV поломает этот "парсер" запросто.

    T>>> Я вот не смог объяснить, потому там и по сей день string.split.

    O>> Достаточно показать валидный CSV который этот split сломает. Чего там объяснять-то?

    T>Недостаточно.


    Ну, в таком случае надо всех уволить. С волчьим билетом. Потому что дебилы опасны для общества.

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

    O>> Те, кто не способен dsl написать, не справятся и с тупым решением задачи, требующей экспертизы в нескольких областях.

    T>Неужели наличие экспертизы в нескольких областях автоматически гарантирует умение дсл и компиляторов ?


    Да.

    O>> У них огромное преимущество — они не испорчены и не напуганы.


    T>Они просто ничего не хотят знать, при том что уже гарантировано получают очень неплохую ЗП.


    Им приходится учиться. Все время. Так не бывает, как вы описываете. Каждый год какие-то новые мумбы-юмбы появляются, с которыми вся индустрия плясать начинает истерично. Agile там всякие, TDD, паттерны-шматтерны и прочая чепуха. И ничего, учатся, напрягаются. Тогда как могли бы научиться гораздо более простой и понятной системе и про все последующие мумбы-юмбы забыть навсегда.
    Re[19]: Языки общего назначения не имеют смысла!
    От: netch80 Украина http://netch80.dreamwidth.org/
    Дата: 13.04.12 08:44
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    O>>> Прелесть подхода с употреблением DSL в том, что плевать на общие случаи, и решать надо всегда лишь примитивные частные задачи. Общее решение, при необходимости, само получится. Потом.

    T>>А для чего дсл для примитивных частных задач ? их тыщи. ДСЛ нужен там где можно закрыть общий случай.
    O> Неверно. DSL нужны там, где решение с DSL будет проще, понятее не поддерживаемее. Никаких таких "общих случаев" не надо, это совершенно нерелевантная тема.

    Вы не противоречите друг другу. Но Tanker говорит о том, что разработка DSL полезна не для однократного случая, а для систематического решения задач какого-то специализированного типа.

    O> Еще бы сказали, что языки высокого уровня нужны там, где можно закрыть общий случай, а "примитивные частные задачи" можно и на ассемблере нафигачить.


    Если они действительно примитивные — да, это имеет смысл.

    T>>Вот-вот. А сейчас для UI считай ничего лучше html+css вобщем то и нет. А говоришь одного раза достаточно.


    O> А не надо сравнивать столь сложную тему (UI) с такой примитивной и убогой как разработка и реализация языков.


    Наоборот, это разработка и реализация языков — сложная тема на всех уровнях.
    А UI в своей базе примитивен до ужаса. Сложность там в основном в оптимизации юзкейсов.
    The God is real, unless declared integer.
    Re[12]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 13.04.12 08:46
    Оценка:
    Здравствуйте, Tanker, Вы писали:

    O>> Неверно. При паршивом преподавании любой материал сложным покажется. А в данном случае вообще нужный материал и не дают, а только грузят абсолютно несущественной ерундой, 100% из которой на практике не пригодится совершенно. То, что пригодится, как раз и не дают.


    T>Не хочешь ли ты сказать, что преподаватели сами не понимают этот материал ?


    Да, именно так.

    T>Откуда тогда возьмется та самая простота ?


    Из жизни, из практики. А преподаватели — это недоумки-теоретики, в основном. Много вы видели в ВУЗах преподавателей с реальным опытом в индустрии? Они не только компиляторов не понимают, они вообще-то ничего не понимают.

    T>И как объяснить тот факт, что преподаватели одни и те же, а одни предметы усваиваются хорошо, а другие — плохо ?


    Что-то я сомневаюсь в том, что что-то там "хорошо" усваивается с помощью преподавателей. Просто по одним предметам студенты догадываются заниматься самостоятельно, решать практические задачи, а по другим боятся (благодаря недоумкам-преподавателям, конечно же). Посмотрите на выпускников ВУЗов — они ни черта вообще не умеют, если у них не было реальной практики.

    T>>>Я и не говорил про матан, но по моему компиляторы это всего лишь часть математики.


    O>> Так любую хоть немного формализуемую (пусть даже только в бредовых фантазиях формализуемую) отралсь можно обозвать "частью математики".


    T>Так в том то и дело
    Re[14]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 13.04.12 08:49
    Оценка:
    Здравствуйте, Tanker, Вы писали:

    T>>>Как быть с теми, чей домен не сильно определен ?

    WH>>Определить. Твой КО.
    T>А бизнесу сказать: "Ребята, заносите миллионы долларов через пять-десять лет, пока мы всё формализуем и напишем классный DSL"
    А ты что совсем программу не проектируешь?
    Бедный бизнес.

    T>>>Как быть с теми которые затрагивают сразу несколько доменов ?

    WH>>Чего? У задачи один домен.
    T>Это у тебя так.
    Это всегда так.

    T>Где взять DSL на все случаи жизни ? Кто будет семантику реализовывать ?

    Часто это проще чем писать библиотеки.

    T>>>Импортирую данные которые кастомеры по отрасли хранят в CSV.

    WH>>Ничего не сказал.
    WH>>Куда ты их ипортируешь?
    T>Из CSV файлов.
    Ты вообще читаешь?

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

    В каком месте?
    Ты защищаешь подход с багами в коде. Типа и так все работает.

    T>Ты наверное думаешь, что раз программист двое круче, то и профит у бизнеса будет вдвое больше ? Стоимость разработки <10% от стоимости всех затрат. И часто нужно не просто уметь программировать, но и понимать всю специфику бизнеса. Как правило, второе всегда важнее первого.

    И чем же таким занимается разработчик, что пишет код только 10% своего времени?
    Я сколько работаю программистом, у меня на всякие совещания уходит процентов 10 времени.
    А остальное исследования (это неучи вообще не могут), проектирование (и это тоже) и кодирование (да и это обычно себе дороже).
    У тебя в конторе явно что-то не так.

    T>А волшебник в голубом вертолете формализует каждую из областей и реализует семантику ?

    А что ты сам не в состоянии?

    T>Кому ? Для чего ? Вот приходит вчерашний студент на работу, получает сходу ЗП которые выше раз в пять чем средняя по стране.

    T>Откуда у него будет мотив учиться ?
    Тех, кто не учиться нужно, отправлять в дворники, а не программистом брать.
    Ибо писать они всё равно не смогут.
    Проверено.

    T>Люди обычно учатся, что бы чего то добиться, а не просто так, от любви к процессу.

    Хорошие инженеры учатся всегда. Они просто не могут, не учится. Иначе моментом тупеют и теряют квалификацию.

    T>Чего нужно добиваться инженеру ? Квартиру, машину, детей ?

    T>На это хватит той ЗП которую получает молодой специалит, т.е. вчерашний студент, а если он еще пару леваков прихватит, то еще и самолет прикупит.
    Это я так понимаю, ты про себя говоришь?
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[4]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 13.04.12 08:49
    Оценка: -1
    Здравствуйте, Tanker, Вы писали:

    O>> Вот как раз это утверждение совершенно не соответствует действительности. Это может любой школьник. Не напрягаясь.


    T>И что же толпы школьников никак не могут выдать внятный DSL для описания вечной проблемы — UI ?


    Программирование UI никогда проблемой не было. Проблема в его дизайне. А тут DSL не помогут.

    Кроме того, UI это просто неинтересно. Вот никто и не берется за эту чушь.
    Re[13]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 13.04.12 08:51
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>>>Нет. Это показывает, что студентов учат не правильному материалу.

    T>>Если так, то это значит, что тема компиляторов сложна даже для преподавателей.
    WH> Раньше преподавали, что земля плоская и на трех китах стоит.
    WH>Не по тому, что гелиоцентрическая система это что-то сложное, а по тому, что просто не знали как на самом деле. Только и всего.

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

    Поэтому, когда ты говоришь что преподают плохо, это значит, что в голове у преподавателей все еще земля на трёх китах. А это значит, что даже преподаватели еще не доросли до внятного понимания компиляторов.
    The animals went in two by two, hurrah, hurrah...
    Re[13]: Языки общего назначения не имеют смысла!
    От: netch80 Украина http://netch80.dreamwidth.org/
    Дата: 13.04.12 08:51
    Оценка: :)
    Здравствуйте, oldjackal, Вы писали:

    T>>Откуда тогда возьмется та самая простота ?

    O> Из жизни, из практики. А преподаватели — это недоумки-теоретики, в основном. Много вы видели в ВУЗах преподавателей с реальным опытом в индустрии? Они не только компиляторов не понимают, они вообще-то ничего не понимают.

    Даже если это так для exUSSR и Европы, то уже в США ситуация заметно другая — там традиция использовать для преподавания практиков никогда не прерывалась.
    Но и там знают, что разработка языков — дело сложное и неблагодарное: выживает 1 из 1000, в лучшем случае.
    Значит, местные традиции ни при чём и незачем гнать на них.
    The God is real, unless declared integer.
    Re[16]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 13.04.12 08:53
    Оценка:
    Здравствуйте, alex_public, Вы писали:

    _>Там был какой-то практический смысл тащить в рантайм лишнюю сущность или это просто "так реализовали"?

    "Так реализовали". Реально, компилировать процесс инициализации объектов не имеет практического смысла. Зачем? Интерпретатор проще.

    _>Как раз есть. Изнутри dsl мы чётко видим два вида вызовов: родные вызовы контролов и некий внешний вызов куда-то там.

    Как вы их отличаете?

    _>Но это уже вне языка (dsl) и только одна реализация, простейшая, которую я бы мог сам с ходу закодировать. А можно же представить себе много других вариантов. Например dsl компилируется непосредственно в последовательности вызовов win api (или же gtk api или же android api, в зависимости от целевой платформы), а наша функция calculate вообще написана на ассемблере и подключается через библиотеку. И это всё будет работать и в одной реализации и в другой, для одного и того же dsl кода.

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

    _>Преимущество естественно в простоте и удобстве.

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

    _>А вообще изначально задача ставилась не про язык для обработчиков, а про отделение "языка интерфейса" (который вбирал бы в себя всё, включая дизайн, логику интерфейса и т.д.) и "языка движка" с удобной связью между ними. Сейчас же в основном присутствуют (не в вебе) варианты разделяющие "язык размётки интерфейса" и "всё остальное".

    Я вам намекаю на то, что вы изобретаете ровно то же самое.

    _>И как я уже писал, в таком случае, мне даже сам язык размётки как таковой не нужен — полностью хватает визуального генератора, генерирующего системный код.

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

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

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

    _>Пока писал это, пришёл в голову альтернативный вариант. Я вроде уже писал что не исключаю вариант такого dsl реализованый как встроенный в системный язык. Т.е. условно говоря вот у нас сейчас есть визуальный редактор умеющий генерировать C++ (допустим для примера) код.

    Чисто для справки: именно такой визуальный редактор вы делать задолбаетесь. По очевидным причинам.
    А то, что вы имеете в виду — это 3 (три) разных штуки:
    1. DSL описания разметки (который вам "не нужен")
    2. Визуальный редактор для этого DSL (кстати, большинству разработчиков не нужен как раз он)
    3. Компилятор/конвертер, который по описанию разметки генерирует код инициализации на хост-языке.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[15]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 13.04.12 08:55
    Оценка:
    Здравствуйте, koodeer, Вы писали:

    T>> И часто нужно не просто уметь программировать, но и понимать всю специфику бизнеса. Как правило, второе всегда важнее первого.


    K>Специфика бизнеса — это и есть domain-specific

    K>Вывод: DSL рулят!

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

    Т.е. не бвает универсальных специалистов которые одинаково хорошо строят ДСЛ, решают задачи бизнеса и реализуют программы на своём ДСЛ. Как то так складывается, что архитектор SQL сам не пишет запросы. А те, кто пишут запросы, и те, кто строит дсл, задачи бизнеса понимают плохо, потому им нужен человек из бизнеса, который ставит и учавствует в формализации области.
    The animals went in two by two, hurrah, hurrah...
    Re[13]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 13.04.12 08:57
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    T>>Если так, то это значит, что тема компиляторов сложна даже для преподавателей.


    O> Ну вот зачем говорить глупости с таким упрямством?


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


    Практика всегда идет впереди теории. Если у теоретиков представление устаревшее, то это потому, что практики еще не накопили нужное количество опыта и не формализовали этот опыт.
    The animals went in two by two, hurrah, hurrah...
    Re[12]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 13.04.12 08:57
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>Есть такое.

    WH>http://javascript.crockford.com/tdop/tdop.html
    WH>Бред про то, что оно заточено под динамически типизированные языки пропускай мимо ушей.

    Спасибо, попробую поиграть с разными реализациями.

    O>> Совсем нет? Так не бывает. Но вы меня заинтересовали, попробую узнать про Pratt-а побольше. Есть какие-то ссылки по теме, которые гугл и википедия не дадут?

    WH>У меня нельзя делать непрямую левую рекурсию.

    У... Это плохо.

    WH>Но на практике я даже представить не могу, кому может понадобиться непрямая левая рекурсия в данном алгоритме.


    Встречается иногда.

    WH>>>Да я не спорю. Но существующие языки тоже нужно разбирать.

    O>> К задаче реализации DSL это особого отношения не имеет, к счастью.
    WH>Но у меня это требование есть.
    WH>Ибо одна из задачь парсить C# и Java.
    WH>Чтобы дать людям возможность взять готовый проект и начать добавлять туда макры.

    Логично. О расширении того же шарпа я как-то не подумал. Встраивать DSL в привычный шарп, а не в страшный Nemerle — это должно быть весьма удобно и эффективно.

    WH>>>Мне хватает скорости, чтобы все распарсить.

    O>> Даже если там сто тысяч строк кода?
    WH>Nemerle.Peg пару метров в секунду на грамматике C# дает.

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

    WH>>>Я это понимаю. И собираюсь сделать язык описания ошибочных ситуаций.

    O>> А это не ошибочная ситуация. Это предупреждение.
    WH>Тогда видимо я что-то не понял.
    WH>Я думал ты про восстановление после ошибок говоришь.

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

    O>> Мне Packrat интересен как раз тем, что его можно и руками делать, без DSLей, без генераторов.

    WH>Так там как раз генератор.

    Вот и интересно посмотреть, что он генерит.

    O>> Семантика то как раз прозрачна, поскольку не далеко ушла от привычной семантики низлежащего языка.

    WH>Вот ту не могу согласиться.
    WH>Ибо ДСЛ для того и создают чтобы уйти от семантики языка более низкого уровня.

    Как правило — да. Но в случае с парсерами это не всегда возможно (см. выше про clang). Тонкости поведения при ошибках декларативно определять пока никто не научился, так что наилучшим решением представляется как раз тоненькая прослойка над низким уровнем — определяем декларативно все, что можно, а где нельзя, там прозрачно скатываемся на низкий уровень. Это не leaky abstraction, это честно, потому как абстракция парсера от низкого уровня сама не далеко ушла.
    Re[19]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 13.04.12 08:59
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    T>>А для чего дсл для примитивных частных задач ? их тыщи. ДСЛ нужен там где можно закрыть общий случай.


    O> Неверно. DSL нужны там, где решение с DSL будет проще, понятее не поддерживаемее. Никаких таких "общих случаев" не надо, это совершенно нерелевантная тема.


    "понятее не поддерживаемее" — могу тлько догадываться что это могло означать.

    O> Еще бы сказали, что языки высокого уровня нужны там, где можно закрыть общий случай, а "примитивные частные задачи" можно и на ассемблере нафигачить.


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

    T>>Вот-вот. А сейчас для UI считай ничего лучше html+css вобщем то и нет. А говоришь одного раза достаточно.


    O> А не надо сравнивать столь сложную тему (UI) с такой примитивной и убогой как разработка и реализация языков.


    Как ты померил сложность разработки и реализации языков ? Наверняка "у меня получилось и следовательно это просто" ?
    The animals went in two by two, hurrah, hurrah...
    Re[14]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 13.04.12 09:01
    Оценка:
    Здравствуйте, Tanker, Вы писали:

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

    Но это не значит что тема сложна.
    Просто они пошли по неверному пути.
    Что я и пытаюсь тебе втолковать.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[14]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 13.04.12 09:07
    Оценка:
    Здравствуйте, netch80, Вы писали:

    N>Но и там знают, что разработка языков — дело сложное и неблагодарное: выживает 1 из 1000, в лучшем случае.

    А откуда, по-твоему, драконщина пошла?
    Плюс ты специально, что ли путаешь ДСЛ и ЯОН?
    ДСЛ они все выживают в том проекте, для которых их делают. А на большее они обычно и не претендуют.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[15]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 13.04.12 09:07
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    T>>Предполагается что понятия и отношения привезет волшебник в голубом вертолете ?


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


    Бизнес(энтерпрайз) он весь в формуле из детской сказки: "иди туда не знаю куда и принеси то не знаю что."

    T>>В модель данных.


    O> Какую модель? В каком виде представленную?


    В

    T>>Вопрос был — "зачем" ? Не можешь ответить ?


    O> Затем, что иначе это не будет поддежкой CSV. Потому как валидный CSV поломает этот "парсер" запросто.


    правильно. Поддержка CSV ради поддержки CSV не нужна. Задача решена — парсер не нужен. А решена ли задача или нет, проверяет и определяет человек из бизнеса.

    T>>Недостаточно.

    O> Ну, в таком случае надо всех уволить. С волчьим билетом. Потому что дебилы опасны для общества.

    Эти дебилы платят тебе и мне(платили) зарплату

    T>>Неужели наличие экспертизы в нескольких областях автоматически гарантирует умение дсл и компиляторов ?

    O> Да.

    Неужели ДСЛ это как перк, который качать не надо, но который появляется сам собой случайным образом ?
    Странно, но явидел много специалистов которые прокачаны в разных областях и при этом вообще не знали программирования и это не мешало им работать в софтверных проектах. Пример — сопромат-баллистика-гидроаэродинамика.
    The animals went in two by two, hurrah, hurrah...
    Re[13]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 13.04.12 09:10
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    T>>Не хочешь ли ты сказать, что преподаватели сами не понимают этот материал ?

    O> Да, именно так.

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

    T>>Откуда тогда возьмется та самая простота ?


    O> Из жизни, из практики. А преподаватели — это недоумки-теоретики, в основном. Много вы видели в ВУЗах преподавателей с реальным опытом в индустрии? Они не только компиляторов не понимают, они вообще-то ничего не понимают.


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

    T>>И как объяснить тот факт, что преподаватели одни и те же, а одни предметы усваиваются хорошо, а другие — плохо ?


    O> Что-то я сомневаюсь в том, что что-то там "хорошо" усваивается с помощью преподавателей. Просто по одним предметам студенты догадываются заниматься самостоятельно, решать практические задачи, а по другим боятся (благодаря недоумкам-преподавателям, конечно же). Посмотрите на выпускников ВУЗов — они ни черта вообще не умеют, если у них не было реальной практики.


    Да, теория ничего не может там, где практики не накопили достаточно опыта.
    The animals went in two by two, hurrah, hurrah...
    Re[11]: Просто мысль...
    От: oldjackal Россия  
    Дата: 13.04.12 09:13
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    O>> Ну так я смогу определить такую функцию и в том же модуле ей воспользоваться? А смогу из макроса воспользоваться другими функциями из этого модуля?

    WH>Да. Да.
    WH>В том числе рекурсивно.

    Это хорошо. А как это реализовано? Модуль создается динамически?

    WH>Ибо хочу вместо того чтобы заставить человека писать вывод типов (это сложно шо писец) написать декларативный код проверки типов.

    WH>И по нему уже сгенерировать вывод типов.
    WH>Уверен использовать это будет очень просто.

    А не ограничит ли эта декларативность возможные системы типов еще сильнее?

    Кстати, тот же несчастный Хиндли-Миллнер это всего лишь подмножество Пролога. Если, например, декларативное описание типизации делать в виде правил генерации утверждений Пролога из термов AST, то получится бесплатно и сам Хиндли-Миллнер, и что угодно еще, сколь угодно сложное (Пролог-то Тьюринг-полный). Не рассматривали такой вариант? Это и просто, и матана не надо (весь матан уже придуман и приложен разработчиками Пролога), и гибкость бесконечная получается.

    O>> Иногда типы могут зависеть от типизации вложенных макр, которых нет (и про которые мы ничего не знаем) до тех пор, пока AST не развернули. Когда я пытался прикрутить типизированную макросистему к ML я по этим граблям походил. В Nemerle система типов несколько более человечная, так что не берусь утверждать, что трудности непреодолимы.

    WH>В Н2 идеология другая.
    WH>А системы типов вообще нет. Ибо это не язык, а движок для создания языков.
    WH>Ибо, например мой генератор парсеров имеют свою систему типов не похожую на другие языки.

    Это хорошо. Я боялся, что будет что-то страшное в стиле MetaOCaml или Template Haskell. Хорошо если не так.

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


    Что-то похожее на JetBrains MPS?

    WH>
    rule IfExpr is Expr
    WH>syntax "if" "(" cond : Expr ")" expr1 : Expr "else" expr2 : Expr;
    WH>{
    WH>  assert(cond.Type == #bool, "Condition type must be bool.");
    WH>  assert(Type <= expr1.Type && Type <= expr2.Type, "Branch types must be convertible to same type.");
    WH>}
    WH>


    А, ну это не так уж и декларативно. Может и сработать.

    O>> Обоснуете? Чем плоха возможность пользоваться определениями сразу, не отходя от кассы?

    WH>Я понимаю, о чем ты, но у меня просто принципиально иной подход к построению системы.
    WH>То, что ты хочешь, в нем просто не имеет смысла.

    То есть? Раскрывать макрос в другой макрос имеет смысл всегда.

    O>> Ну, по этому вопросу лучше не дискутировать, у меня прямо противоположное мнение —

    WH>По которому из трех пунктов?
    WH>

    WH>Тормозит, жрет память и главное ошибки не ловит.


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

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

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

    А это уже неоправданное ограничение.

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


    А зря, зря. Строить статические типизации поверх динамической проще, чем наоборот.

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

    WH>Н2 не будет навязывать систему типов языку который на нем разрабатывается.

    А как же требование возможности статической проверки? Хотя, если эта базовая, минимальная система типов будет на уровне не выше чем в LLVM, то и не страшно.

    WH>Это моя принципиальная позиция.

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

    Вот еще такой вопрос — какая позиция насчет goto? Иметь возможность раскрывать макросы в код, использующий goto — это очень, очень удобно. Конечному пользователю его лучше в руки не давать, но вот иметь к нему доступ для компиляторов DSL очень важно. В N1 отсутствие goto меня отпугнуло.

    O>> Пусть он другой, но если он ограничивает возможности реализации иерархических макросов, то он должен как минимум предоставлять что-то взамен. Что-то не менее ценное.

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

    Не понял. Как раз при возможности использования иерархии языков макры ни на что не завязаны, их можно писать на любом из DSLей, сколь угодно высокого уровня. А вот если на каждый уровень надо по отдельной DLL создавать, как сейчас в N1 — тогда да, тогда это невозможно. В Лиспе же таких ограничений нет в принципе.

    WH>У меня этого не будет.


    Было бы очень интересно посмотреть на существующие наработки.
    Re[14]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 13.04.12 09:19
    Оценка: +1
    Здравствуйте, Tanker, Вы писали:

    T>>>Не хочешь ли ты сказать, что преподаватели сами не понимают этот материал ?

    O>> Да, именно так.

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


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

    T>>>Откуда тогда возьмется та самая простота ?


    O>> Из жизни, из практики. А преподаватели — это недоумки-теоретики, в основном. Много вы видели в ВУЗах преподавателей с реальным опытом в индустрии? Они не только компиляторов не понимают, они вообще-то ничего не понимают.


    T>Это потому, что теория идет позади практики.


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

    T> Как только практики накопили опыт, формализоваля, подтягиваются теоретики и делают сложное простым, т.к. занимаются распространением опыта. Слабость теоретиков означает что до простоты еще как до небес.


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

    O>> Что-то я сомневаюсь в том, что что-то там "хорошо" усваивается с помощью преподавателей. Просто по одним предметам студенты догадываются заниматься самостоятельно, решать практические задачи, а по другим боятся (благодаря недоумкам-преподавателям, конечно же). Посмотрите на выпускников ВУЗов — они ни черта вообще не умеют, если у них не было реальной практики.


    T>Да, теория ничего не может там, где практики не накопили достаточно опыта.


    Я говорю про даже самые примитивные вещи. Студенты, выпускники CS-специальностей, не умеют программировать. Вообще. На fizz-buzz ломаются. Даже если круглые отличники. Умеют программировать только те, кто подрабатывал налево или программировал что-то реальное just for fun. А они как правило, наоборот, вовсе не отличники, на учебу у них времени маловато остается.
    Re[15]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 13.04.12 09:21
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>>>Определить. Твой КО.

    T>>А бизнесу сказать: "Ребята, заносите миллионы долларов через пять-десять лет, пока мы всё формализуем и напишем классный DSL"
    WH> А ты что совсем программу не проектируешь?
    WH>Бедный бизнес.

    Ты похоже вещаешь про те задачки, которые хорошо формализованы еще десятки лет назад.

    T>>>>Как быть с теми которые затрагивают сразу несколько доменов ?

    WH>>>Чего? У задачи один домен.
    T>>Это у тебя так.
    WH>Это всегда так.

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

    T>>Где взять DSL на все случаи жизни ? Кто будет семантику реализовывать ?

    WH>Часто это проще чем писать библиотеки.

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

    T>>>>Импортирую данные которые кастомеры по отрасли хранят в CSV.

    WH>>>Ничего не сказал.
    WH>>>Куда ты их ипортируешь?
    T>>Из CSV файлов.
    WH>Ты вообще читаешь?

    Импортирую в domain model.

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

    WH>В каком месте?

    Ты похоже сам перестал читать.

    WH>Ты защищаешь подход с багами в коде. Типа и так все работает.


    Я демонстрирую тебе подход бизнеса.

    T>>Ты наверное думаешь, что раз программист двое круче, то и профит у бизнеса будет вдвое больше ? Стоимость разработки <10% от стоимости всех затрат. И часто нужно не просто уметь программировать, но и понимать всю специфику бизнеса. Как правило, второе всегда важнее первого.

    WH>И чем же таким занимается разработчик, что пишет код только 10% своего времени?

    Не надо передёргивать. 10% это процент расходов на всех разработчиков. Т.е. сумма ЗП разрабов за период поделить на бюджет и помножить на 100.

    WH>У тебя в конторе явно что-то не так.


    Ты явно не понимаешь, как функционирует бизнес.

    T>>А волшебник в голубом вертолете формализует каждую из областей и реализует семантику ?

    WH>А что ты сам не в состоянии?

    Сами формализуем как умеем. А ты похоже вещаешь про те задачки, которые хорошо формализованы еще десятки лет назад.

    T>>Кому ? Для чего ? Вот приходит вчерашний студент на работу, получает сходу ЗП которые выше раз в пять чем средняя по стране.

    T>>Откуда у него будет мотив учиться ?
    WH>Тех, кто не учиться нужно, отправлять в дворники, а не программистом брать.

    Я только за. Предложи хорошее решение.

    WH>Ибо писать они всё равно не смогут.

    WH>Проверено.

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

    T>>Люди обычно учатся, что бы чего то добиться, а не просто так, от любви к процессу.

    WH>Хорошие инженеры учатся всегда. Они просто не могут, не учится. Иначе моментом тупеют и теряют квалификацию.

    Квалификация ради квалификации ? Я боюсь что это утопия.

    T>>Чего нужно добиваться инженеру ? Квартиру, машину, детей ?

    T>>На это хватит той ЗП которую получает молодой специалит, т.е. вчерашний студент, а если он еще пару леваков прихватит, то еще и самолет прикупит.
    WH>Это я так понимаю, ты про себя говоришь?

    Это типичная картина которую я наблюдаю в разных странах, разных городах как сам так и со слов людей в самых разных уровнях иерархии.
    The animals went in two by two, hurrah, hurrah...
    Re[16]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 13.04.12 09:23
    Оценка:
    Здравствуйте, Tanker, Вы писали:


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


    T>Бизнес(энтерпрайз) он весь в формуле из детской сказки: "иди туда не знаю куда и принеси то не знаю что."


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

    O>> Затем, что иначе это не будет поддежкой CSV. Потому как валидный CSV поломает этот "парсер" запросто.


    T>правильно. Поддержка CSV ради поддержки CSV не нужна. Задача решена — парсер не нужен. А решена ли задача или нет, проверяет и определяет человек из бизнеса.


    И что, у них ни разу не попался CSV, убивающий недоделанный парсер? Так не бывает. Банальный экспорт из Excel (ненависть! ненависть!) генерит CSV, использующие все возможности формата.

    T>>>Недостаточно.

    O>> Ну, в таком случае надо всех уволить. С волчьим билетом. Потому что дебилы опасны для общества.

    T>Эти дебилы платят тебе и мне(платили) зарплату


    Программисты? Зарплату? Так не бывает. Они ее получают и тратят, а не платят.

    T>>>Неужели наличие экспертизы в нескольких областях автоматически гарантирует умение дсл и компиляторов ?

    O>> Да.

    T>Неужели ДСЛ это как перк, который качать не надо, но который появляется сам собой случайным образом ?


    Это умение уровня "hello, world". Прочитать, один раз сделать и потом всю жизнь пользоваться.

    T>Странно, но явидел много специалистов которые прокачаны в разных областях и при этом вообще не знали программирования и это не мешало им работать в софтверных проектах. Пример — сопромат-баллистика-гидроаэродинамика.


    Как раз те, кто не сильно испорчен "классическим" программированием учатся создавать DSLи намного быстрее чем упоротые "программисты".
    Re[5]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 13.04.12 09:24
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    O> Программирование UI никогда проблемой не было. Проблема в его дизайне. А тут DSL не помогут.


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

    O> Кроме того, UI это просто неинтересно. Вот никто и не берется за эту чушь.


    Это кому как. Кто умеет только мышом кликать в дизайнер, тому UI не будет интересен.
    The animals went in two by two, hurrah, hurrah...
    Re[14]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 13.04.12 09:26
    Оценка:
    Здравствуйте, Tanker, Вы писали:

    T>Практика всегда идет впереди теории. Если у теоретиков представление устаревшее, то это потому, что практики еще не накопили нужное количество опыта и не формализовали этот опыт.

    Правильные методики были разработаны в середине 70х.
    Но драконисты их затоптали. Инквизиторы хреновы.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[13]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 13.04.12 09:26
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    O> Спасибо, попробую поиграть с разными реализациями.

    Можешь начать с моей.
    С ней проще всего играться.

    WH>>У меня нельзя делать непрямую левую рекурсию.

    O> У... Это плохо.
    Это не нужно.
    На практике левая рекурсия встречается только в операторах.
    А там она прямая. В смысле рекурсивно вызывается расширяемое правило.
    И именно на такой сценарий все и заточено.
    Посмотри на ту грамматику, что я тебе показал.

    WH>>Но на практике я даже представить не могу, кому может понадобиться непрямая левая рекурсия в данном алгоритме.

    O> Встречается иногда.
    Пример?
    Я знаю только про операторы в классическом подходе.
    Но данный подход именно на этот случай и заточен.

    O> Это и пакрат сделает.

    Что-то сомневаюсь.

    O>Этого мало, для отзывчивости редактора надо быстрее.

    Хватает. Если парсить в фоне, то это просто не заметно.

    O> Восстановление это еще более интересная тема. Но я привел в пример warning, таких в Clang очень много. Он тем и хорош, что на всякие синтаксические неоднозначности указывать умеет. И возможно это только благодаря страшному, кривому, рукописному парсеру. Очень быстрому, кстати.

    Написать правила, которые проходятся по АСТ и дают предупреждения на скользкие места не сложно.
    Более того их можно скомпилировать в одну сильно оптимизированную структуру и тогда это будет работать очень быстро.
    Скорей всего ручные реализации за таким не угоняться. Я бы точно ручками не смог.

    WH>>Так там как раз генератор.

    O> Вот и интересно посмотреть, что он генерит.
    Очень много говнокода.
    Я столько ни прочитать, ни тем более написать не смогу.

    O> Как правило — да. Но в случае с парсерами это не всегда возможно (см. выше про clang). Тонкости поведения при ошибках декларативно определять пока никто не научился, так что наилучшим решением представляется как раз тоненькая прослойка над низким уровнем — определяем декларативно все, что можно, а где нельзя, там прозрачно скатываемся на низкий уровень. Это не leaky abstraction, это честно, потому как абстракция парсера от низкого уровня сама не далеко ушла.

    Так это все из-за дрконщины. С их подходами действительно ничего такого не сделать.
    А если изначально проектировать язык разбора, то можно засунуть в него и язык разбора ошибочного кода.
    До реализации у меня это пока не дошло, но мысли уже есть.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[15]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 13.04.12 09:28
    Оценка: -1 :)
    Здравствуйте, WolfHound, Вы писали:

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

    WH>Но это не значит что тема сложна.

    Конечно не значит, но это основной симптом.

    WH>Просто они пошли по неверному пути.

    WH>Что я и пытаюсь тебе втолковать.

    Не они пошли, а их туда завели практики. Пока практики не смогут накопить опыт, от теоретиков пользы не будет. Во все времена практика шла впереди теории.
    Хочешь качетсвенно готовить студентов — теоретики должны выдать весь понятийный аппарат. А для этого практики должны накопить должное количетсво опыта да еще и формализовать его.
    The animals went in two by two, hurrah, hurrah...
    Re[20]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 13.04.12 09:31
    Оценка:
    Здравствуйте, Tanker, Вы писали:

    O>> Неверно. DSL нужны там, где решение с DSL будет проще, понятее не поддерживаемее. Никаких таких "общих случаев" не надо, это совершенно нерелевантная тема.


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


    Это опечатка. s/не/и/g

    O>> Еще бы сказали, что языки высокого уровня нужны там, где можно закрыть общий случай, а "примитивные частные задачи" можно и на ассемблере нафигачить.


    T>Я так и говорю — частные задачи можно и нужно решать на ассемблере. Пример — задачи низкоуровневой оптимизации.


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

    O>> А не надо сравнивать столь сложную тему (UI) с такой примитивной и убогой как разработка и реализация языков.


    T>Как ты померил сложность разработки и реализации языков ? Наверняка "у меня получилось и следовательно это просто" ?


    Сложность это понятие объективное. Не верите мне — спросите у Колмогорова.

    Банально количество сущностей и связей между ними в компиляторах и в UI несопоставимо. Количество необходимых знаний несопоставимо (тут и психология, и эргономика, и черт те че еще).

    А для компиляторов надо всего лишь понимать, что такое правила переписывания. Причем всю эту мутную теорию про TRS учить не надо, она нерелевантна. И ведь все этим со школы владеют, алгебру-то все учили, а тут как раз то же самое, переписывание выражений по тупым правилам. И все! Ничего кроме этого во всей этой теме нет. Никаких там "формальных грамматик", которыми на 80% все учебники по компиляторам забиты, никакой такой ерунды просто даром не надо, в реальной практике этому нет места. А есть только выражения и правила их преобразования, то есть то, что понятно любому школьнику.
    Re[15]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 13.04.12 09:32
    Оценка: -1
    Здравствуйте, WolfHound, Вы писали:

    T>>Практика всегда идет впереди теории. Если у теоретиков представление устаревшее, то это потому, что практики еще не накопили нужное количество опыта и не формализовали этот опыт.

    WH>Правильные методики были разработаны в середине 70х.

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

    WH>Но драконисты их затоптали. Инквизиторы хреновы.


    Что лишь подтверждает гниль всей академической системы в целом.
    Re[17]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 13.04.12 09:35
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    T>>Бизнес(энтерпрайз) он весь в формуле из детской сказки: "иди туда не знаю куда и принеси то не знаю что."


    O> Не надо преувеличивать. Любая частная задача всегда имеет формулировку. Не строгую, конечно же, ну так строгие формулировки и не нужны. DSL и появляются из нестрогих формулировок.


    Я даже преуменьшил Теоретически, любая задача имеет формулировку. На практике эту формулировку надо еще и родить. ДСЛ появляется там опыт уже накоплен, формализован.

    T>>правильно. Поддержка CSV ради поддержки CSV не нужна. Задача решена — парсер не нужен. А решена ли задача или нет, проверяет и определяет человек из бизнеса.


    O> И что, у них ни разу не попался CSV, убивающий недоделанный парсер? Так не бывает. Банальный экспорт из Excel (ненависть! ненависть!) генерит CSV, использующие все возможности формата.


    Откуда негатив к Экселю ? Покажи пример. Например импортируем из экселя колонки чисел в csv формате. Покажи, как правильный файл повалит string split.

    T>>Эти дебилы платят тебе и мне(платили) зарплату


    O> Программисты? Зарплату? Так не бывает. Они ее получают и тратят, а не платят.


    Эти люди не программисты, они из бизнеса.


    T>>Неужели ДСЛ это как перк, который качать не надо, но который появляется сам собой случайным образом ?


    O> Это умение уровня "hello, world". Прочитать, один раз сделать и потом всю жизнь пользоваться.


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

    T>>Странно, но явидел много специалистов которые прокачаны в разных областях и при этом вообще не знали программирования и это не мешало им работать в софтверных проектах. Пример — сопромат-баллистика-гидроаэродинамика.


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


    Формализовать область могут и делают это много быстрее программистов. ДСЛ+компиляторы — это епархия программистов.
    The animals went in two by two, hurrah, hurrah...
    Re[6]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 13.04.12 09:36
    Оценка:
    Здравствуйте, Tanker, Вы писали:

    T>Вот эта проблема, в дизайне, которя плохо поддается формализации, вынуждает делать UI максимально гибким. Вот здесь как бы и должны помочь DSL. Но чет слабо помогают.


    Не представляю, как DSL может помочь. Программирование UI тривиально и так, да и DSL-ей и так полно под самые разные UI-задачи. Тот же Tcl/Tk или WPF (Xaml), или, пардон, HTML. Главная же проблема это собственно UI придумать, а ее и на бумажке с карандашом решать можно, или в каком либо Balsamiq Mockups. Когда эта задача решена, программирование становится тривиальным, и в сравнении с дизайном занимает исчезающе малое время, независимо от используемой технологии.

    O>> Кроме того, UI это просто неинтересно. Вот никто и не берется за эту чушь.


    T>Это кому как. Кто умеет только мышом кликать в дизайнер, тому UI не будет интересен.


    Это неинтересно программистам. Это интересно дизайнерам.
    Re[15]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 13.04.12 09:37
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

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


    O> Меня более всего удивляет то, что вас этот простой факт удивляет. Преподаватели много в чем ни в зуб ногой. Я бы сказал, почти во всем ни в зуб ногой.


    Повезло тебе.

    T>>Это потому, что теория идет позади практики.


    O> Это только в теории так. А на практике же, и в особенности в случае с компиляторами, теория идет где-то своими, параллельными путями, с практикой вообще не пересекающимися. То есть, между той теорией, которой учат на этом предмете, и реальной практикой, нет вообще абсолютно ничего общего. Ни единой точки соприкосновения.


    Это значит практика еще не накопила нужное количетсво опыта.

    T>> Как только практики накопили опыт, формализоваля, подтягиваются теоретики и делают сложное простым, т.к. занимаются распространением опыта. Слабость теоретиков означает что до простоты еще как до небес.


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


    Извиния, я далёк от таких обобщений.

    T>>Да, теория ничего не может там, где практики не накопили достаточно опыта.


    O> Я говорю про даже самые примитивные вещи. Студенты, выпускники CS-специальностей, не умеют программировать. Вообще. На fizz-buzz ломаются. Даже если круглые отличники. Умеют программировать только те, кто подрабатывал налево или программировал что-то реальное just for fun. А они как правило, наоборот, вовсе не отличники, на учебу у них времени маловато остается.


    Мне честно интересно где ты видел таких студентов ?
    The animals went in two by two, hurrah, hurrah...
    Re[15]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 13.04.12 09:38
    Оценка: :)
    Здравствуйте, WolfHound, Вы писали:

    T>>Практика всегда идет впереди теории. Если у теоретиков представление устаревшее, то это потому, что практики еще не накопили нужное количество опыта и не формализовали этот опыт.

    WH>Правильные методики были разработаны в середине 70х.
    WH>Но драконисты их затоптали. Инквизиторы хреновы.

    Затоптали — значит идейка была так себе.
    The animals went in two by two, hurrah, hurrah...
    Re[21]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 13.04.12 09:42
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    O>>> Неверно. DSL нужны там, где решение с DSL будет проще, понятее не поддерживаемее. Никаких таких "общих случаев" не надо, это совершенно нерелевантная тема.

    T>>"понятее не поддерживаемее" — могу тлько догадываться что это могло означать.
    O> Это опечатка. s/не/и/g

    Ну и в качестве примера берем скул и орм

    O> Не, эквивалентное по глупости утверждение было бы "все частные задачи надо решать на ассемблере". Кстати, низкоуровневую оптимизацию на ассемблере давно уже никто не делает, в этом нет смысла.


    Это ты сильно заблуждаешься. Шейдеры, аппаратные задачи, даже в менеджед приходится спускаться на il.

    T>>Как ты померил сложность разработки и реализации языков ? Наверняка "у меня получилось и следовательно это просто" ?

    O> Сложность это понятие объективное. Не верите мне — спросите у Колмогорова.

    То есть, два одинаковых бегуна пробегут две разные дистанции за одно и то же время ? Мне кажется Колмгоров такого не говорил.
    The animals went in two by two, hurrah, hurrah...
    Re[14]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 13.04.12 09:44
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    O>> Спасибо, попробую поиграть с разными реализациями.

    WH>Можешь начать с моей.
    WH>С ней проще всего играться.

    Уже смотрю.

    WH>>>У меня нельзя делать непрямую левую рекурсию.

    O>> У... Это плохо.
    WH>Это не нужно.
    WH>На практике левая рекурсия встречается только в операторах.

    В операторах как раз не так важно. Самая паршивая форма левой рекурсии — это в выражениях С-подобных языков:
    x.y[z]->(*f)(); // (и так далее)


    Другой мерзопакостный леворекурсивный пример — грамматика типов в C (и тем более в C++).

    WH>А там она прямая. В смысле рекурсивно вызывается расширяемое правило.

    WH>И именно на такой сценарий все и заточено.

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

    WH>Посмотри на ту грамматику, что я тебе показал.


    Это-то как раз простейший вариант.

    O>> Это и пакрат сделает.

    WH>Что-то сомневаюсь.

    Проверенно.

    O>>Этого мало, для отзывчивости редактора надо быстрее.

    WH>Хватает. Если парсить в фоне, то это просто не заметно.

    Тогда с задержкой раскрашивать будет. Неудобно.

    O>> Восстановление это еще более интересная тема. Но я привел в пример warning, таких в Clang очень много. Он тем и хорош, что на всякие синтаксические неоднозначности указывать умеет. И возможно это только благодаря страшному, кривому, рукописному парсеру. Очень быстрому, кстати.

    WH>Написать правила, которые проходятся по АСТ и дают предупреждения на скользкие места не сложно.

    Какой такой АСТ? Там АСТ еще нет, недопарсили его.

    WH>Более того их можно скомпилировать в одну сильно оптимизированную структуру и тогда это будет работать очень быстро.

    WH>Скорей всего ручные реализации за таким не угоняться. Я бы точно ручками не смог.

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

    Кстати, мемоизация пакрата как раз в востановлении после ошибок помогает неплохо, но даже ее недостаточно.

    WH>>>Так там как раз генератор.

    O>> Вот и интересно посмотреть, что он генерит.
    WH>Очень много говнокода.
    WH>Я столько ни прочитать, ни тем более написать не смогу.

    Но можно ведь генерить и не-говнокод, а что-то читабельное и коротенькое. Тот же packrat и на комбинаторах делается неплохо.

    WH>Так это все из-за дрконщины. С их подходами действительно ничего такого не сделать.

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

    Вот мысли как раз и интересуют. Я ничего придумать не смог. Ни в плане DSL, ни тем более в плане реализации. Когда есть императивный, тупой код, приправленный тупейшим PEG-генератором, то все понятно, можно любые проверки воткнуть куда угодно в процесс разбора. А вот как их декларативно описать, в самом общем виде?
    Re[7]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 13.04.12 09:45
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

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


    T>>Вот эта проблема, в дизайне, которя плохо поддается формализации, вынуждает делать UI максимально гибким. Вот здесь как бы и должны помочь DSL. Но чет слабо помогают.


    O> Не представляю, как DSL может помочь. Программирование UI тривиально и так, да и DSL-ей и так полно под самые разные UI-задачи. Тот же Tcl/Tk или WPF (Xaml), или, пардон, HTML. Главная же проблема это собственно UI придумать, а ее и на бумажке с карандашом решать можно, или в каком либо Balsamiq Mockups. Когда эта задача решена, программирование становится тривиальным, и в сравнении с дизайном занимает исчезающе малое время, независимо от используемой технологии.


    Люди занимающиеся мобайлом и десктопом с тобой не согласятся. UI только начинается с кнопочек и дале требует хорошей инфрастурктуры над тем же WPF и тд.
    The animals went in two by two, hurrah, hurrah...
    Re[16]: Языки общего назначения не имеют смысла!
    От: koodeer  
    Дата: 13.04.12 09:45
    Оценка: :)
    Здравствуйте, Tanker, Вы писали:

    T>Конечно. Разве я это оспариваю ?

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

    T>Т.е. не бвает универсальных специалистов которые одинаково хорошо строят ДСЛ, решают задачи бизнеса и реализуют программы на своём ДСЛ. Как то так складывается, что архитектор SQL сам не пишет запросы. А те, кто пишут запросы, и те, кто строит дсл, задачи бизнеса понимают плохо, потому им нужен человек из бизнеса, который ставит и учавствует в формализации области.


    Я это представляю так:
    Исходная предпосылка — человек уже хороший программист.
    Знания специфики бизнеса пока нет. Поэтому пишем лапшу. Постепенно выделяем части кода в библиотеки.
    Со временем приходит понимание специфики. Хороший программист сразу же сможет выделить DSL. Точка.
    Re[16]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 13.04.12 09:46
    Оценка:
    Здравствуйте, Tanker, Вы писали:
    T>Не они пошли, а их туда завели практики. Пока практики не смогут накопить опыт, от теоретиков пользы не будет.

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

    T>Хочешь качетсвенно готовить студентов — теоретики должны выдать весь понятийный аппарат. А для этого практики должны накопить должное количетсво опыта да еще и формализовать его.


    Там всего понятийного аппарата на две строки текста, не больше. Теоретики просто фигней страдают.
    Re[17]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 13.04.12 09:48
    Оценка:
    Здравствуйте, koodeer, Вы писали:

    K>Я это представляю так:

    K>Исходная предпосылка — человек уже хороший программист.
    K>Знания специфики бизнеса пока нет. Поэтому пишем лапшу. Постепенно выделяем части кода в библиотеки.
    K>Со временем приходит понимание специфики. Хороший программист сразу же сможет выделить DSL. Точка.

    Сразу же это когда ? Когда понимания еще нет или когда понимание уже есть ? Специфику бизнеса люди годами осваивают и даже десятками лет.
    The animals went in two by two, hurrah, hurrah...
    Re[8]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 13.04.12 09:50
    Оценка:
    Здравствуйте, Tanker, Вы писали:

    O>> Не представляю, как DSL может помочь. Программирование UI тривиально и так, да и DSL-ей и так полно под самые разные UI-задачи. Тот же Tcl/Tk или WPF (Xaml), или, пардон, HTML. Главная же проблема это собственно UI придумать, а ее и на бумажке с карандашом решать можно, или в каком либо Balsamiq Mockups. Когда эта задача решена, программирование становится тривиальным, и в сравнении с дизайном занимает исчезающе малое время, независимо от используемой технологии.


    T>Люди занимающиеся мобайлом и десктопом с тобой не согласятся. UI только начинается с кнопочек и дале требует хорошей инфрастурктуры над тем же WPF и тд.


    Я видел, как эти люди работают. Программирование занимает самую незначительную часть времени. Гораздо больше они спорят до хрипоты над карандашными рисунками и тестируют интерфейс на пользователях, используя бумажные аппликации. Так что их инструмент — бумажка, карандаш, ножницы и клей. Какие такие DSL им могли бы помочь?
    Re[16]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 13.04.12 09:51
    Оценка: +2 :)
    Здравствуйте, Tanker, Вы писали:

    WH>>Правильные методики были разработаны в середине 70х.

    WH>>Но драконисты их затоптали. Инквизиторы хреновы.

    T>Затоптали — значит идейка была так себе.


    Нет, это теоретики так себе. Практики то как пользовались правильными подходами, так и пользуются. А теоретики в это время всякую чушь в учебниках пишут и студентов этой чушью пугают.
    Re[17]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 13.04.12 09:51
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    T>>Не они пошли, а их туда завели практики. Пока практики не смогут накопить опыт, от теоретиков пользы не будет.


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


    Развивать идею "все теоретики дураки" мне неинтересно дасже с учетом того что себя я причисляю к практикам-прагматикам.

    T>>Хочешь качетсвенно готовить студентов — теоретики должны выдать весь понятийный аппарат. А для этого практики должны накопить должное количетсво опыта да еще и формализовать его.


    O> Там всего понятийного аппарата на две строки текста, не больше. Теоретики просто фигней страдают.


    Выдай эти два строки текста. Надеюсь их длина как в хорошей программе ограничена сотней символов ?
    The animals went in two by two, hurrah, hurrah...
    Re[9]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 13.04.12 09:52
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    T>>Люди занимающиеся мобайлом и десктопом с тобой не согласятся. UI только начинается с кнопочек и дале требует хорошей инфрастурктуры над тем же WPF и тд.


    O> Я видел, как эти люди работают. Программирование занимает самую незначительную часть времени. Гораздо больше они спорят до хрипоты над карандашными рисунками и тестируют интерфейс на пользователях, используя бумажные аппликации. Так что их инструмент — бумажка, карандаш, ножницы и клей. Какие такие DSL им могли бы помочь?


    Фильтр это UI или не UI ?
    The animals went in two by two, hurrah, hurrah...
    Re[16]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 13.04.12 09:58
    Оценка:
    Здравствуйте, Tanker, Вы писали:

    O>> Меня более всего удивляет то, что вас этот простой факт удивляет. Преподаватели много в чем ни в зуб ногой. Я бы сказал, почти во всем ни в зуб ногой.


    T>Повезло тебе.


    В чем это мне повезло? В том, что пригодного к немедленному употреблению студента днем с огнем не найдешь? Не назвал бы это везением.

    O>> Это только в теории так. А на практике же, и в особенности в случае с компиляторами, теория идет где-то своими, параллельными путями, с практикой вообще не пересекающимися. То есть, между той теорией, которой учат на этом предмете, и реальной практикой, нет вообще абсолютно ничего общего. Ни единой точки соприкосновения.


    T>Это значит практика еще не накопила нужное количетсво опыта.


    Поразительная упертость. Включите мозг! Практика лет 60 существует. Компиляторы всех мастей пишут, не напрягаясь. Наплевав на рассуждения теоретиков. Никаких сложностей и неясных моментов в практике нет уже очень давно. А теоретики как рассуждали про "формальные грамматики", как спорили про разницу между LALR(1) и SLR, так и спорят, тогда как абсолютно все практики всегда пишут ad hoc рекурсивные парсеры и знать не желают про баталии дебилов-теоретиков.

    Советую прежде чем продолжать этот нелепый спор, где вы заведомо и на все 100% лажаетесь, посмотрите на существующие промышленные компиляторы. Попробуйте найти там хотя бы малюсенький след того, о чем рассуждают дебилы-теоретики. Найдите там хотя бы одну страницу драконьей книги, на которую теоретики молятся. Не найдете! Ни в gcc, ни clang/llvm, ни в HotSpot, ни в CPython, нигде!

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

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


    T>Извиния, я далёк от таких обобщений.


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

    O>> Я говорю про даже самые примитивные вещи. Студенты, выпускники CS-специальностей, не умеют программировать. Вообще. На fizz-buzz ломаются. Даже если круглые отличники. Умеют программировать только те, кто подрабатывал налево или программировал что-то реальное just for fun. А они как правило, наоборот, вовсе не отличники, на учебу у них времени маловато остается.


    T>Мне честно интересно где ты видел таких студентов ?


    Мне было бы очень интересно узнать, где можно взять других?
    Re[22]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 13.04.12 10:01
    Оценка:
    Здравствуйте, Tanker, Вы писали:

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

    O>> Это опечатка. s/не/и/g

    T>Ну и в качестве примера берем скул и орм


    А не надо их брать. Я же сказал, это абсолютно иная тема, ничего общего с обсуждаемой не имеющая.

    O>> Не, эквивалентное по глупости утверждение было бы "все частные задачи надо решать на ассемблере". Кстати, низкоуровневую оптимизацию на ассемблере давно уже никто не делает, в этом нет смысла.


    T>Это ты сильно заблуждаешься. Шейдеры, аппаратные задачи, даже в менеджед приходится спускаться на il.


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

    T>>>Как ты померил сложность разработки и реализации языков ? Наверняка "у меня получилось и следовательно это просто" ?

    O>> Сложность это понятие объективное. Не верите мне — спросите у Колмогорова.

    T>То есть, два одинаковых бегуна пробегут две разные дистанции за одно и то же время ? Мне кажется Колмгоров такого не говорил.


    Что-то вы совсем зарапортовались. Что за нелепая аналогия? Я говорю о том, что сложность областей несопоставимая. Компиляторы — это тупо и примитивно, и изучается за несколько часов полностью. UI — гигантских размеров дисциплина, на поверхностное знакомство с которой могут уйти годы.
    Re[12]: Просто мысль...
    От: WolfHound  
    Дата: 13.04.12 10:01
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    O> Это хорошо. А как это реализовано? Модуль создается динамически?

    Зачем? Функции они и есть функции.
    Ничем от обычных функций не отличаются.

    O> А не ограничит ли эта декларативность возможные системы типов еще сильнее?

    Не должна.

    O> Кстати, тот же несчастный Хиндли-Миллнер это всего лишь подмножество Пролога. Если, например, декларативное описание типизации делать в виде правил генерации утверждений Пролога из термов AST, то получится бесплатно и сам Хиндли-Миллнер, и что угодно еще, сколь угодно сложное (Пролог-то Тьюринг-полный). Не рассматривали такой вариант? Это и просто, и матана не надо (весь матан уже придуман и приложен разработчиками Пролога), и гибкость бесконечная получается.

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

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

    O> Что-то похожее на JetBrains MPS?
    Да. Только намного технологичнее.
    И разве MPS умеет типы выводить? Что-то не заметил. Там вроде все руками типизировать нужно.

    WH>>
    rule IfExpr is Expr
    WH>>syntax "if" "(" cond : Expr ")" expr1 : Expr "else" expr2 : Expr;
    WH>>{
    WH>>  assert(cond.Type == #bool, "Condition type must be bool.");
    WH>>  assert(Type <= expr1.Type && Type <= expr2.Type, "Branch types must be convertible to same type.");
    WH>>}
    WH>>

    O> А, ну это не так уж и декларативно. Может и сработать.
    Не декларативно? Фигасе.
    Куда же декларативнее то?

    O> Вообще-то по каждому. Тормозить динамическая типизация совершенно не обязана (внутри она может быть совершенно статической).

    Ну да всякие V8 пытаются это делать. Но только что-то не получается.
    И в процессе память жрут тоннами.

    O>Памяти на RTTI мне не жалко совершенно (во время компиляции, чтоб рефлексию в макросах кормить, в рантайме его и не надо).

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

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

    Ну так я и планирую ввести предметно ориентированные системы типов.

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

    O> А зря, зря. Строить статические типизации поверх динамической проще, чем наоборот.
    Чего?

    WH>>Н2 не будет навязывать систему типов языку который на нем разрабатывается.

    O> А как же требование возможности статической проверки?
    А одно другому не мешает.

    O>Хотя, если эта базовая, минимальная система типов будет на уровне не выше чем в LLVM, то и не страшно.

    А это вообще лишнее. Например, мои генераторы парсеров типизируют грамматику совершенно не оглядываясь на то в какой язык это будет скомпилировано.
    А типы базового языка используются исключительно как черный ящик.
    Вот таким вариантом задаются типы в парсере.
    Выделенное это ссылки на типы немерла.
    С тем же успехом там могут быть ссылки на типы чего угодно.
      [Record]
      public variant RuleType : Nemerle.Compiler.Located
      {
        | List   { ty : RuleType; }
        | Option { ty : RuleType; }
        | Tuple  { types : list[RuleType]; }
        | PType  { ty : PExpr; }
        | NType  { ty : FixedType; }
        | Chars
        | Void

    Одну из них по-хорошему нужно убрать. Руки не доходят.

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

    O> Вот еще такой вопрос — какая позиция насчет goto? Иметь возможность раскрывать макросы в код, использующий goto — это очень, очень удобно. Конечному пользователю его лучше в руки не давать, но вот иметь к нему доступ для компиляторов DSL очень важно.

    Языки с goto безусловно будут.

    O>В N1 отсутствие goto меня отпугнуло.

    Скажу по секрету макры им могут пользоваться.
    https://github.com/rampelstinskin/ParserGenerator/blob/3666b1b364d3cbf942587a385aba13a07fa22661/Nemerle.Parser.Macro/Compiler/RuleCompiler/CompileFSM.n

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

    O>А вот если на каждый уровень надо по отдельной DLL создавать, как сейчас в N1 — тогда да, тогда это невозможно. В Лиспе же таких ограничений нет в принципе.

    Это не проблема.

    O> Было бы очень интересно посмотреть на существующие наработки.

    Сейчас есть только недописанный парсер. Остальное пока в теории.
    Но я работаю над этим.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[15]: Языки общего назначения не имеют смысла!
    От: netch80 Украина http://netch80.dreamwidth.org/
    Дата: 13.04.12 10:02
    Оценка: :)
    Здравствуйте, WolfHound, Вы писали:

    N>>Но и там знают, что разработка языков — дело сложное и неблагодарное: выживает 1 из 1000, в лучшем случае.

    WH>А откуда, по-твоему, драконщина пошла?

    А при чём тут её происхождение?

    WH>Плюс ты специально, что ли путаешь ДСЛ и ЯОН?

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

    Я не путаю, я не спешу различать, пока не нужно. Да, DSL на одну программу может быть кривым, но и у неё может быть миллион пользователей и долгая история развития, и тогда начинают править ошибки.
    The God is real, unless declared integer.
    Re[18]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 13.04.12 10:06
    Оценка:
    Здравствуйте, Tanker, Вы писали:

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


    T>Развивать идею "все теоретики дураки" мне неинтересно дасже с учетом того что себя я причисляю к практикам-прагматикам.


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

    T>>>Хочешь качетсвенно готовить студентов — теоретики должны выдать весь понятийный аппарат. А для этого практики должны накопить должное количетсво опыта да еще и формализовать его.


    O>> Там всего понятийного аппарата на две строки текста, не больше. Теоретики просто фигней страдают.


    T>Выдай эти два строки текста. Надеюсь их длина как в хорошей программе ограничена сотней символов ?


    Уже выдал, чуть раньше, про TRS и алгебру. Ничего кроме этого во всей этой области нет. Денотационные и операционные семантики? Чушь, сводится к TRS. Грамматики? Вообще нерелевантно. Оптимизации? На высоких уровнях сводится к правилам и стратегиям переписывания деревьев, на самых суровых низких уровнях (про которые большинству писателей компиляторов и знать-то не надо) немного сложнее, сводится к правилам и стратегиям переписывания DAG-ов.

    Так что, сложно простому смертному понять, что такое выражение, что такое дерево, и что такое правила переписывания? Да нет, элементарно. Уж всяко проще, чем зубрить сотни "паттернов", которые сейчас у любого промышленного программиста от зубов отскакивают.
    Re[10]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 13.04.12 10:07
    Оценка:
    Здравствуйте, Tanker, Вы писали:

    O>> Я видел, как эти люди работают. Программирование занимает самую незначительную часть времени. Гораздо больше они спорят до хрипоты над карандашными рисунками и тестируют интерфейс на пользователях, используя бумажные аппликации. Так что их инструмент — бумажка, карандаш, ножницы и клей. Какие такие DSL им могли бы помочь?


    T>Фильтр это UI или не UI ?


    Чего? Какой такой фильтр?
    Re[16]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 13.04.12 10:15
    Оценка:
    Здравствуйте, Tanker, Вы писали:

    T>Ты похоже вещаешь про те задачки, которые хорошо формализованы еще десятки лет назад.

    Я про любые.

    T>Сложность семантики не зависит ни от дсл ни от библиотеки, она определеятся доменом. Есть специалист по домену — значит будет N-готовых решений и легкость проектирования. Нет такого — надо тратить время сначала на формализацию, а уже потом, если хватит времени — на ДСЛ.

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

    WH>>Ты защищаешь подход с багами в коде. Типа и так все работает.

    T>Я демонстрирую тебе подход бизнеса.
    К чему? Собственному разорению?

    T>Не надо передёргивать. 10% это процент расходов на всех разработчиков. Т.е. сумма ЗП разрабов за период поделить на бюджет и помножить на 100.

    И на что же тратятся остальные 90%. Похоже у вас там воруют. Либо просто управленцы дураки.
    Это конечно если мы про контору, которая чисто разработкой живет, говорим.

    T>Сами формализуем как умеем. А ты похоже вещаешь про те задачки, которые хорошо формализованы еще десятки лет назад.

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

    WH>>Тех, кто не учиться нужно, отправлять в дворники, а не программистом брать.

    T>Я только за. Предложи хорошее решение.
    Не брать. В чем проблема то?

    WH>>Хорошие инженеры учатся всегда. Они просто не могут, не учится. Иначе моментом тупеют и теряют квалификацию.

    T>Квалификация ради квалификации ? Я боюсь что это утопия.
    Это реальность. Иначе программист за пару лет стане непрофпригодным.

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

    Ну, так и не надо таких брать.
    Нужно взять в 10 раз меньше нормальных. И показать им как ДСЛи делать.
    И они в 100 раз быстрее все сделают.

    Сколько я видел тех, о ком ты говоришь весь их код, после увольнения переписывался. Его даже без ДСЛ становилось в разы меньше и все баги пропадали.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[16]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 13.04.12 10:15
    Оценка: +1
    Здравствуйте, oldjackal, Вы писали:

    O> Гораздо раньше. Еще и компьютеров никаких не было, а все что надо уже знали и умели. Алгебру-то давно придумали.

    Я про Пратт и ПЕГ.
    Руками парсеры писать, мягко говоря, неудобно.

    O> Что лишь подтверждает гниль всей академической системы в целом.

    Она не вся гнилая. Есть там и полезные темы. Просто нужно перекопать кучу навоза, чтобы найти что-то полезное.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[11]: Языки общего назначения не имеют смысла!
    От: netch80 Украина http://netch80.dreamwidth.org/
    Дата: 13.04.12 10:16
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    T>>3 Объясни, кем заменить тех, кто не в состоянии написать чтото большее string.split ?

    O> Я бы рассказал, что надо сделать с теми, кто выдумывает форматы, требующие чего-то большего чем String.Split. CSV это злобно и бесчеловечно.

    "Яка розумная тому альтернатива?"
    Для передачи в поле произвольного значения мы имеем или стаффинг, или эскейпинг.
    Стаффинг требует разбора грамматики, пусть даже минимальной. Эскейпинг таким не страдает, но усложняет визуальное чтение и ручное редактирование.
    Что лучше — иметь в поле "\"15%+20%\"" или %2215%25%2B20%25%22 ? (для примера был взят HTML form escaping)

    T>>DSL, хочешь ты или нет, это очень сложная тема.

    O> Не-а. Простая. Проще некуда.

    Её сложность ровно такая же, как с любым другим языком. Но средняя цена ошибки сильно меньше.
    The God is real, unless declared integer.
    Re[13]: Просто мысль...
    От: oldjackal Россия  
    Дата: 13.04.12 10:18
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    O>> Это хорошо. А как это реализовано? Модуль создается динамически?

    WH>Зачем? Функции они и есть функции.
    WH>Ничем от обычных функций не отличаются.

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

    WH>Ибо у меня есть требование инкрементального обновления для работы в режиме ИДЕ.

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

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

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

    O>> Что-то похожее на JetBrains MPS?
    WH>Да. Только намного технологичнее.
    WH>И разве MPS умеет типы выводить? Что-то не заметил. Там вроде все руками типизировать нужно.

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

    O>> А, ну это не так уж и декларативно. Может и сработать.

    WH>Не декларативно? Фигасе.
    WH>Куда же декларативнее то?

    Я правильно понимаю, что в { ... } может быть произвольный императивный код?

    O>> Вообще-то по каждому. Тормозить динамическая типизация совершенно не обязана (внутри она может быть совершенно статической).

    WH>Ну да всякие V8 пытаются это делать. Но только что-то не получается.
    WH>И в процессе память жрут тоннами.

    Это можно делать статически. Даже такой простой компилятор, как SBCL, это в принципе делать умеет.

    O>>Памяти на RTTI мне не жалко совершенно (во время компиляции, чтоб рефлексию в макросах кормить, в рантайме его и не надо).

    WH>А мне жалко. Если проект большой, то это вызывает проблемы.

    При раздельной-то компиляции? Вряд ли.

    Да и не стоит забывать, что в .NET от RTTI все равно не избавишься, так почему бы им не пользоваться тогда?

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

    WH>Была бы динамическая типизация... ой... даже подумать страшно.

    Не представляю, чем динамика может помешать.

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

    WH>Ну так я и планирую ввести предметно ориентированные системы типов.

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

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

    O>> А зря, зря. Строить статические типизации поверх динамической проще, чем наоборот.
    WH>Чего?

    А есть возражения?

    WH>>>Н2 не будет навязывать систему типов языку который на нем разрабатывается.

    O>> А как же требование возможности статической проверки?
    WH>А одно другому не мешает.

    Не понимаю. Как?

    O>>Хотя, если эта базовая, минимальная система типов будет на уровне не выше чем в LLVM, то и не страшно.

    WH>А это вообще лишнее. Например, мои генераторы парсеров типизируют грамматику совершенно не оглядываясь на то в какой язык это будет скомпилировано.

    А язык потом по рукам не надает, если что-то окажется не типизируемым по его мнению?

    WH>Используя такой подход можно полностью избавиться от необходимости раскрывать макросы для проверки кода.

    WH>Причем сообщения об ошибках будут в терминах предметной области, а не того языка в который раскрывается код.

    Буду думать. Пока не понимаю.

    O>> Вот еще такой вопрос — какая позиция насчет goto? Иметь возможность раскрывать макросы в код, использующий goto — это очень, очень удобно. Конечному пользователю его лучше в руки не давать, но вот иметь к нему доступ для компиляторов DSL очень важно.

    WH>Языки с goto безусловно будут.

    Это хорошо.

    O>>В N1 отсутствие goto меня отпугнуло.

    WH>Скажу по секрету макры им могут пользоваться.

    О как!

    WH>Но по-хорошему goto не нужен.


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

    WH>Он отлично заменяется взаимно рекурсивными функциями с хвостовой рекурсией.


    Ну да, конечно же, SSA эквивалентен CPS. Только вот в SSA все намного короче и проще получается.

    WH>Нужно только чтобы она гарантированно оптимизировалась. Н1 так не умеет. Поэтому пришлось гото использовать.


    И зачем? С goto оптимизировать не надо, оно уже и так оптимально.

    O>>А вот если на каждый уровень надо по отдельной DLL создавать, как сейчас в N1 — тогда да, тогда это невозможно. В Лиспе же таких ограничений нет в принципе.

    WH>Это не проблема.

    Как это решается?

    O>> Было бы очень интересно посмотреть на существующие наработки.

    WH>Сейчас есть только недописанный парсер. Остальное пока в теории.
    WH>Но я работаю над этим.

    Ок, подожду.
    Re[12]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 13.04.12 10:21
    Оценка:
    Здравствуйте, netch80, Вы писали:

    N>"Яка розумная тому альтернатива?"

    N>Для передачи в поле произвольного значения мы имеем или стаффинг, или эскейпинг.
    N>Стаффинг требует разбора грамматики, пусть даже минимальной. Эскейпинг таким не страдает, но усложняет визуальное чтение и ручное редактирование.

    Но за возможность разбора awk-ом такое можно и простить.

    N>Что лучше — иметь в поле "\"15%+20%\"" или %2215%25%2B20%25%22 ? (для примера был взят HTML form escaping)


    Эскейпить надо ровно один единственный символ — разделитель колонок. Остальное можно оставить как есть.

    T>>>DSL, хочешь ты или нет, это очень сложная тема.

    O>> Не-а. Простая. Проще некуда.

    N>Её сложность ровно такая же, как с любым другим языком. Но средняя цена ошибки сильно меньше.


    Разговор был про сложность разработки DSL. А они уж всяко проще языков "общего назначения".
    Re[17]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 13.04.12 10:23
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    O>> Гораздо раньше. Еще и компьютеров никаких не было, а все что надо уже знали и умели. Алгебру-то давно придумали.

    WH>Я про Пратт и ПЕГ.
    WH>Руками парсеры писать, мягко говоря, неудобно.

    А, ну да, оба из 70х. В любом случае, парсеры это далеко не главное. Драконовщина нанесла непоправимый вред в первую очередь как раз зацикленностью на парсерах.

    O>> Что лишь подтверждает гниль всей академической системы в целом.

    WH>Она не вся гнилая. Есть там и полезные темы. Просто нужно перекопать кучу навоза, чтобы найти что-то полезное.

    Естественно, term rewriting, семантики и тому подобное это в целом полезно. Хоть и тут без ненужного переусложнения не обошлись.
    Re[17]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 13.04.12 10:30
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    O> Советую прежде чем продолжать этот нелепый спор, где вы заведомо и на все 100% лажаетесь, посмотрите на существующие промышленные компиляторы. Попробуйте найти там хотя бы малюсенький след того, о чем рассуждают дебилы-теоретики. Найдите там хотя бы одну страницу драконьей книги, на которую теоретики молятся. Не найдете! Ни в gcc, ни clang/llvm, ни в HotSpot, ни в CPython, нигде!

    Несколько страниц можно найти.
    Те, на которых написано про регулярные грамматики.
    Эта часть драконщины оказалась полезной.
    Страниц 10 из 1000. Остальное навоз.
    Они даже в моих генераторах используются.
    Ибо конечные автоматы для распознавания токенов рулят.

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

    Я тоже немного теоретик. И занимаюсь как раз анализом, обобщением и формализацией реального опыта.
    И это нужный процесс. Ибо долбеж парсеов руками на С это мазохизм. Плавали, знаем.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[27]: Языки общего назначения не имеют смысла!
    От: Vain Россия google.ru
    Дата: 13.04.12 10:33
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    V>>Какую именно?

    S>

    S>Специалист по SQL это такой же специалист по C++ или java, а это самостоятельные языки

    S>Расшифруйте.
    Ну SQL и базы данных по сложности, к примеру, не уступают C++ и компиляторам.
    [In theory there is no difference between theory and practice. In
    practice there is.]
    [Даю очевидные ответы на риторические вопросы]
    Re[18]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 13.04.12 10:34
    Оценка: +1
    Здравствуйте, Tanker, Вы писали:
    T>Откуда негатив к Экселю ? Покажи пример. Например импортируем из экселя колонки чисел в csv формате. Покажи, как правильный файл повалит string split.
    Держите:
    A,B
    "0,77","1,22"
    "12,44","5,23"

    Удачи со string.split.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[13]: Языки общего назначения не имеют смысла!
    От: netch80 Украина http://netch80.dreamwidth.org/
    Дата: 13.04.12 10:38
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    N>>"Яка розумная тому альтернатива?"

    N>>Для передачи в поле произвольного значения мы имеем или стаффинг, или эскейпинг.
    N>>Стаффинг требует разбора грамматики, пусть даже минимальной. Эскейпинг таким не страдает, но усложняет визуальное чтение и ручное редактирование.
    O> Но за возможность разбора awk-ом такое можно и простить.

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

    N>>Что лучше — иметь в поле "\"15%+20%\"" или %2215%25%2B20%25%22 ? (для примера был взят HTML form escaping)

    O> Эскейпить надо ровно один единственный символ — разделитель колонок. Остальное можно оставить как есть.

    Увы, тут сложнее. Если для эскейпинга использовать, например, формат %XX, то как минимум ещё требуется эскейпинг самого '%' — именно так происходит в HTTP'шных правилах. Далее, строки же тоже чем-то разделяются? Значит, может и должен быть эскейпинг CR и LF, если они есть в значении.
    Вы правы в том, что я перестарался в данном примере — кавычки и плюс можно было не переделывать. Но даже без них вариант "15%25+20%25" уже выглядит усложнённым для ручной обработки.

    Собственно говоря, все грамматики и возникают от желания усидеть одной попой на двух совершенно разных сиденьях — соблюсти и однозначность для машины, и удобство обработки человеком. Отсюда чрезмерная привязанность к грамматикам у ряда стандартизирующих организаций (таких, как IETF), при том, что они не в состоянии обеспечить отсутствие принципиальных ошибок в определениях (RFC822 и RFC3261, видимо, так и останутся рекордсменами по нелепости).

    Ещё в 95-м D.J.Bernstein написал такое:

    I have discovered that there are two types of command interfaces in the world of computing: good interfaces and user interfaces.

    The essence of user interfaces is parsing: converting an unstructured sequence of commands, in a format usually determined more by psychology than by solid engineering, into structured data.

    When another programmer wants to talk to a user interface, he has to quote: convert his structured data into an unstructured sequence of commands that the parser will, he hopes, convert back into the original structured data.

    This situation is a recipe for disaster. The parser often has bugs: it fails to handle some inputs according to the documented interface. The quoter often has bugs: it produces outputs that do not have the right meaning. Only on rare joyous occasions does it happen that the parser and the quoter both misinterpret the interface in the same way.


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

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

    T>>>>DSL, хочешь ты или нет, это очень сложная тема.

    O>>> Не-а. Простая. Проще некуда.
    N>>Её сложность ровно такая же, как с любым другим языком. Но средняя цена ошибки сильно меньше.
    O> Разговор был про сложность разработки DSL. А они уж всяко проще языков "общего назначения".

    Эмпирически — да. Но это результат меньших усилий по их созданию.
    С другой стороны, Perl тоже начинался как DSL, и уже тогда был локальным рекордсменом по "нелинейности" грамматики.
    The God is real, unless declared integer.
    Re[28]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 13.04.12 10:44
    Оценка:
    Здравствуйте, Vain, Вы писали:
    S>>Расшифруйте.
    V>Ну SQL и базы данных по сложности, к примеру, не уступают C++ и компиляторам.
    Не очень понятно, как вы сделали такое сравнение. Но ладно, допустим, что это так.
    Этот ваш аргумент — он какое утверждение доказывает или опровергает?

    Складывается ощущение, что вы мне пытаетесь доказать, что можно заменить запрос на SQL процедурой на C++, причём последняя будет иметь сопоставимую с запросом сложность. Но этого не может быть, так как это, очевидно, неверно.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[17]: Языки общего назначения не имеют смысла!
    От: alex_public  
    Дата: 13.04.12 10:44
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    _>>Как раз есть. Изнутри dsl мы чётко видим два вида вызовов: родные вызовы контролов и некий внешний вызов куда-то там.

    S>Как вы их отличаете?

    Там в примере вызов calculate был в [] скобках. Я думал будет видно что этот вызов отличается от всех остальных. И т.к. дальше было сказано что calculate реализуется в системном коде, то идея должна была быть очевидной. Может зря не пояснил эту свою метафору...

    S>Не понимаю, зачем вы лезете в такие подробности. Определитесь сначала с тем, какие возможности вы хотите в вашем DSL. Потом можно решать, во что его компилировать, и компилировать ли вообще.


    Мы хотим систему полностью инкапсулирующую в себе всю работу с интерфейсом. Т.е. что бы ничего подобного OnCheckbox12132(){editboх94584.enable();} в системном коде не было. А общение интерфейсной части программы с системным кодом было только "по делу", но при этом естественно интегрировано. Это всё. Все остальные примеры в этой темке — это мысли на счёт реализации подобного. Возможно не самые удачные. Но и на рынке реально рабочих примеров подобного особо не видно (web мы пока не обсуждаем). Какие-то намёки есть в Delphi/Builder/Lazarus, какие-то элементы видны в xaml. Но полноценного удобного решения нет. И кстати по идее оно вполне может не зависеть как от целевой платформы, так и от системного языка. Но это уже в идеале.

    S>Я вам уже писал — язык разметки вы всё равно используете. Делать вид, что он вам "не нужен" — это жеманство.


    Это вы снова про тот формат, в котором редактор хранит данные? Ну хорошо, пускай использую — это хорошее, нейтральное слово))) Главное что никогда не редактирую его руками и мне в общем то безразлично какой он там.

    S>Это плохая идея. Объясняю почему: вы, фактически, предлагаете пользователю выбор между написанием одного и того же обработчика на вашем DSL, и написанием того же самого на полноценном host-языке. Велики шансы, что он начнёт с первого, но рано или поздно будет вынужден перейти ко второму. Вообще, это не тот выбор, перед которым стоит ставить разработчика. Желательно, чтобы работал один способ, и он же по совместительству бы был самым очевидным.


    Если скажем 95% обычной интерфейсной логики будет нормально укладываться в синтаксис нашего простенького языка, то разве в целом система не упростит создание интерфейсов?

    _>>Пока писал это, пришёл в голову альтернативный вариант. Я вроде уже писал что не исключаю вариант такого dsl реализованый как встроенный в системный язык. Т.е. условно говоря вот у нас сейчас есть визуальный редактор умеющий генерировать C++ (допустим для примера) код.

    S>Чисто для справки: именно такой визуальный редактор вы делать задолбаетесь. По очевидным причинам.
    Эм, мне не очевидные. Тем более что при наличие уже готового редактора размётки, там останется только чуть подправить что бы он генерировал не только объявления функций обработчиков (как сейчас уже работает), но и их тела и добавить в интерфейс редактора область ввода с подсветкой (scintilla какая-нибудь).

    S>А то, что вы имеете в виду — это 3 (три) разных штуки:


    Ну хорошо, пусть три. Обзовём это не просто одиноким dsl, а целой платформой для разработки. ))) Это что-то меняет?

    S>1. DSL описания разметки (который вам "не нужен")

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

    S>2. Визуальный редактор для этого DSL (кстати, большинству разработчиков не нужен как раз он)

    Интересное мнение. ) Оказывается автоматизация в написание тупого шаблонного кода большинству не нужна... И зачем только в IDE всякие снипнеты напридумывали? ) А про удобство режима WYSIWYG — это наверное всё сказки. )))

    S>3. Компилятор/конвертер, который по описанию разметки генерирует код инициализации на хост-языке.

    Не только код инициализации, но теперь уже и код интерфейсной логики.)
    Re[18]: Языки общего назначения не имеют смысла!
    От: koodeer  
    Дата: 13.04.12 10:46
    Оценка: +1
    Здравствуйте, Tanker, Вы писали:

    T>Сразу же это когда ? Когда понимания еще нет или когда понимание уже есть ?


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

    T>Специфику бизнеса люди годами осваивают и даже десятками лет.


    Скорее так: годами и десятками лет пытаются выразить специфику неудобными конструкциями языков общего назначения. Колются, плачут, но продолжают мучиться.
    Re[29]: Языки общего назначения не имеют смысла!
    От: Vain Россия google.ru
    Дата: 13.04.12 10:54
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>>>Расшифруйте.

    V>>Ну SQL и базы данных по сложности, к примеру, не уступают C++ и компиляторам.
    S>Не очень понятно, как вы сделали такое сравнение. Но ладно, допустим, что это так.
    S>Этот ваш аргумент — он какое утверждение доказывает или опровергает?
    S>Складывается ощущение, что вы мне пытаетесь доказать, что можно заменить запрос на SQL процедурой на C++, причём последняя будет иметь сопоставимую с запросом сложность. Но этого не может быть, так как это, очевидно, неверно.
    Не так, в sql много чего кроме самих запросов. На самом деле сами запросы это вершина айсберга. Можно взять любой учебник по SQL и поисследовать на тему что ещё входит в "знания по SQL".
    [In theory there is no difference between theory and practice. In
    practice there is.]
    [Даю очевидные ответы на риторические вопросы]
    Re[22]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 13.04.12 10:55
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>Не-не-не-не-не, Дэвид Блейн. Это получается бесконечная рекурсия. Вот, допустим, в чистом C у нас нет возможности работать с портами 8086. Подключив библиотеку, я могу добавить туда эту возможность через inp() и outp().

    S>Но каким образом я напишу эту библиотеку на С? Если бы я мог обращаться к портам на С, мне не потребовалась бы библиотека.

    Через встроенный ассемблер, вестимо.

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

    Но на JS или LUA прекрасно сделаешь.
    Re[14]: Просто мысль...
    От: WolfHound  
    Дата: 13.04.12 10:59
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

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

    Ты просто пытаешься понять, основываясь на модели лиспа.
    Но у меня другая модель.
    Не менее мощная просто другая.
    Почитай код моих генераторов парсеров.
    Там в одной сборке описаны функции, которые занимаются переписыванием кусков АСТ.
    И они вызывают друг друга, в том числе рекурсивно.
    Этот подход позволяет сделать все, что ты хочешь. Но немного другим методом.

    WH>>Ибо у меня есть требование инкрементального обновления для работы в режиме ИДЕ.

    O> Такое требование может как раз существенно ограничить возможный диапазон систем типов.
    Не думаю.

    O> Я правильно понимаю, что в { ... } может быть произвольный императивный код?

    Нет. Зачем?
    assert'ов и еще кое-чего достаточно. На их основе будет построен алгоритм вывода типов.
    А в случае если вывод не удался, будет выдано соответствующее сообщение.

    O> Это можно делать статически. Даже такой простой компилятор, как SBCL, это в принципе делать умеет.

    В прицепе оно это умеет делать только для той части кода, для которой можно вывести типы. Так что внутри этого самого SBCL живет выводильщик типов. Работающий с вполне конкретной системой типов.
    А там где не может он сваливается в динамику.
    Подход V8 круче. Он может больше вывести. Но всё равно до нормальной статики не дотягивает.

    O> Да и не стоит забывать, что в .NET от RTTI все равно не избавишься, так почему бы им не пользоваться тогда?

    Если его не трогать, то оно почти ничего не просит.
    А если тронуть получишь просадку производительности в десятки раз.

    WH>>Ну так я и планирую ввести предметно ориентированные системы типов.

    O> Для чего нужна самая базовая система типов, которая никаких ограничений не накладывает вообще.
    Зачем?

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

    O>>> А зря, зря. Строить статические типизации поверх динамической проще, чем наоборот.
    WH>>Чего?
    O> А есть возражения?
    Есть. Мне не известны компиляторы динамически типизированных языков, которые всегда могут вывести типы. Они все рано или поздно сваливаются в динамическую типизацию.

    WH>>А это вообще лишнее. Например, мои генераторы парсеров типизируют грамматику совершенно не оглядываясь на то в какой язык это будет скомпилировано.

    O> А язык потом по рукам не надает, если что-то окажется не типизируемым по его мнению?
    Он может дать по рукам только когда код будет переписан в язык более низкого уровня.
    Но эти ошибки я считаю ошибками разработчика макроса.
    Те internal macro error.
    И при обнаружении такой ошибки нужно чинить макрос. А не код, который его использует.

    O> Ну да, конечно же, SSA эквивалентен CPS. Только вот в SSA все намного короче и проще получается.

    Да я не про CPS, а про обычные хвостовые вызовы.

    O> И зачем? С goto оптимизировать не надо, оно уже и так оптимально.

    В него переписывать сложнее.
    Особенно если иногда нужны не хвостовые вызовы и передача параметров.
    Можно конечно поизвращаться с организацией стека и глобальных для автомата переменных, но зачем, если это сделает компилятор языка более низкого уровня?
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[15]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 13.04.12 11:09
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    O> В операторах как раз не так важно. Самая паршивая форма левой рекурсии — это в выражениях С-подобных языков:

    O>
    x.y[z]->(*f)(); // (и так далее)
    O>

    Никаких проблем.

    O> Другой мерзопакостный леворекурсивный пример — грамматика типов в C (и тем более в C++).

    Опять-таки никаких проблем.
    Просто описываешь правило для разборки типа и вперед.

    O> И вот как раз для таких выражений она не всегда прямая. Хотя и можно свести к прямой, ценой некоторой потери читабельности.

    Пример можно?

    O> Тогда с задержкой раскрашивать будет. Неудобно.

    Ты задержку порядка сотни миллисекунд не заметишь.

    O> Какой такой АСТ? Там АСТ еще нет, недопарсили его.

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

    O> Кстати, мемоизация пакрата как раз в востановлении после ошибок помогает неплохо, но даже ее недостаточно.

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

    O> Но можно ведь генерить и не-говнокод, а что-то читабельное и коротенькое. Тот же packrat и на комбинаторах делается неплохо.

    Но тормозит.

    O> Вот мысли как раз и интересуют. Я ничего придумать не смог. Ни в плане DSL, ни тем более в плане реализации. Когда есть императивный, тупой код, приправленный тупейшим PEG-генератором, то все понятно, можно любые проверки воткнуть куда угодно в процесс разбора. А вот как их декларативно описать, в самом общем виде?

    Просто семантика деклараций должна быть разбирающей, а не как в БНФ порождающей.
    Тогда мы просто вводим специальное правило, которое парсит ошибочный код и все.
    И получаем всю гибкость без лишнего кода.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[22]: Языки общего назначения не имеют смысла!
    От: Don Reba Канада https://stackoverflow.com/users/49329/don-reba
    Дата: 13.04.12 11:17
    Оценка:
    Здравствуйте, Tanker, Вы писали:

    O> Не, эквивалентное по глупости утверждение было бы "все частные задачи надо решать на ассемблере". Кстати, низкоуровневую оптимизацию на ассемблере давно уже никто не делает, в этом нет смысла.


    T>Это ты сильно заблуждаешься. Шейдеры, аппаратные задачи, даже в менеджед приходится спускаться на il.


    DirectX запрещает писать шейдеры на ассемблере, начиная с десятой версии — только HLSL.
    Ce n'est que pour vous dire ce que je vous dis.
    Re[17]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 13.04.12 11:26
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    T>>Повезло тебе.


    O> В чем это мне повезло? В том, что пригодного к немедленному употреблению студента днем с огнем не найдешь? Не назвал бы это везением.




    T>>Это значит практика еще не накопила нужное количетсво опыта.


    O> Поразительная упертость. Включите мозг! Практика лет 60 существует. Компиляторы всех мастей пишут, не напрягаясь. Наплевав на рассуждения теоретиков. Никаких сложностей и неясных моментов в практике нет уже очень давно. А теоретики как рассуждали про "формальные грамматики", как спорили про разницу между LALR(1) и SLR, так и спорят, тогда как абсолютно все практики всегда пишут ad hoc рекурсивные парсеры и знать не желают про баталии дебилов-теоретиков.


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

    O> Советую прежде чем продолжать этот нелепый спор, где вы заведомо и на все 100% лажаетесь, посмотрите на существующие промышленные компиляторы. Попробуйте найти там хотя бы малюсенький след того, о чем рассуждают дебилы-теоретики. Найдите там хотя бы одну страницу драконьей книги, на которую теоретики молятся. Не найдете! Ни в gcc, ни clang/llvm, ни в HotSpot, ни в CPython, нигде!


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

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


    Связь есть но не там где ты хочешь видеть.

    T>>Извиния, я далёк от таких обобщений.


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


    У каждого практика в голове свой набор понятий и связей. Что бы эти понятия стали общими, нужны теоретики.

    T>>Мне честно интересно где ты видел таких студентов ?


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


    На рынке труда, где и все. Может ты погнался за ДСЛ и теперь твоему направлению понизили приоритет, урезали бюджеты и вообще перевели в суппорт ?
    The animals went in two by two, hurrah, hurrah...
    Re[23]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 13.04.12 11:28
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    T>>Ну и в качестве примера берем скул и орм


    O> А не надо их брать. Я же сказал, это абсолютно иная тема, ничего общего с обсуждаемой не имеющая.


    А где граница, что можно брать, а что нельзя ?

    T>>Это ты сильно заблуждаешься. Шейдеры, аппаратные задачи, даже в менеджед приходится спускаться на il.


    O> За последние лет двадцать я ни разу не сталкивался с необходимостью писать что либо на ассемблере. При том, что моя работа как раз тесно связана с HPC.


    HPC не часто требует низкоуровневые оптимизации. А вот отрисовка простого контрола очень даже часто.

    T>>То есть, два одинаковых бегуна пробегут две разные дистанции за одно и то же время ? Мне кажется Колмгоров такого не говорил.


    O> Что-то вы совсем зарапортовались. Что за нелепая аналогия? Я говорю о том, что сложность областей несопоставимая. Компиляторы — это тупо и примитивно, и изучается за несколько часов полностью. UI — гигантских размеров дисциплина, на поверхностное знакомство с которой могут уйти годы.


    А я говорю про то, что у каждого практика в голове свои уникальные понятия и связи. Соответсвено что одному просто, то другому будет сложно. А Колмгоров говорил совсем про другое.
    The animals went in two by two, hurrah, hurrah...
    Re[11]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 13.04.12 11:29
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    T>>Фильтр это UI или не UI ?

    O> Чего? Какой такой фильтр?

    Простой фильтр. Дизайнер положил на форму галочки — кликаешь, появляются одни объекты. Еще кликаешь — появляются или исчезают другие. И тд.
    The animals went in two by two, hurrah, hurrah...
    Re[19]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 13.04.12 11:31
    Оценка: :)
    Здравствуйте, oldjackal, Вы писали:

    O> Про "все" я не говорил. Я привожу конкретный факт, в компиляторостроении полностью отсуствует связь между теорией и практикой. Факт объективный и тривиально доказуемый.


    Боюсь тебя огорчить, но доказательств подобного в этом треде я не видел.

    T>>Выдай эти два строки текста. Надеюсь их длина как в хорошей программе ограничена сотней символов ?


    O> Уже выдал, чуть раньше, про TRS и алгебру. Ничего кроме этого во всей этой области нет. Денотационные и операционные семантики? Чушь, сводится к TRS. Грамматики? Вообще нерелевантно. Оптимизации? На высоких уровнях сводится к правилам и стратегиям переписывания деревьев, на самых суровых низких уровнях (про которые большинству писателей компиляторов и знать-то не надо) немного сложнее, сводится к правилам и стратегиям переписывания DAG-ов.


    Ну можно значит расслабиться, вся евклидова геометрия сводится к трём аксиомам и формальной логике. намёк понятен ?
    The animals went in two by two, hurrah, hurrah...
    Re[16]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 13.04.12 11:51
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>Он прямым текстом заявляет, что программистам ДСЛ не нужны. Они типа и так умные.


    В некоторой мере DSL можно сделать на библиотеках и переопределении операций. Даже по твоей исходной ссылке непонятно, зачем там была DSL? Замени :- на какой-нить << и будет тебе щастье прямо из твоего языка программирования, будь то C# или C++. Там же просто декларация правил для решателя, и этой декларации не нужно мильон новых операторов для выражения всех поддерживаемых отношений.

    Или взять популярный случай размерности величин. Не думаю, что для вменяемого программиста запись 42kg будет сильно отличаться от записи 42*unit.kg или unit.kg(42), тем более, что константы в коде встречаются относительно редко.

    Есть, конечно, момент кодогенерации, как в BLT (что есть тоже DSL на атрибутах), но этот момент прекрасно обыгрывается через post-build step.


    WH>А пишет он бред.

    WH>

    WH>Про DSL, в основе которых матан, мы просто не знаем, по вполне понятной причине — они нехрен никому не нужны.

    WH>В основе SQL матан. Реляционная алгебра называется.

    С какой радости малюсенький сугубо прикладной раздел теории мн-в стал разделом части фундаментальной математики?
    Приплыли..


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


    Принципы разложения по базисам или трюки с возможностью поиска решений в операторной области многие не понимают даже после 5-ти лет учебы. И простым это станет только если программист нарисует пользователю большую кнопку "сделать мне п-дато". Но DSL или реляционная алгебра здесь не при чем. На ее изучение отводится максимум 3-5 лекций и столько же практических занятий. ИМХО, копейки.


    WH>Его для того и придумывают. Чтобы сложные вещи можно было записывать относительно простым способом.


    Ну... сложные вещи даже на SQL просто не запишешь. Особенно когда речь пойдет о необходимости cross или outer join и понимании работы nullable-типов в этих случаях, если необходимо по таким выборкам производить ограничения. ИМХО, только простые вычисления будут выглядеть просто. Но это потому что происходящее на низлежащем уровне тоже довольно просто. И в теории аналогично не сложно. Т.е. я не вижу, где сложность теоретическая вдруг будет замаскирована простотой SQL. Единственный трюк, маскирующий сложность, это автоматическое преобразование условий существования (все операторы которого сводимы к одному из них) в продукцию, но ведь это детали реализации... человеку как раз удобней оперировать понятиями существования элемента в заданном им множестве и "тупая" наивная реализация может точно так же итерироваться по подмногжеству, как задано человеком, т.е. низлежащее преобразование условий существования в продукцию (т.е. переход от реляционного исчисления в реляционную алгебру) идет лишь эффективности ради.


    WH>>> YACC, ANTLR и тп тоже один сплошной матан.


    Опять промазал. Это прикладная наука формальных языков и их грамматик. Это не матан. Хотя задевает крылом области раздела традиционной математики при введении понятия мощности языков с помощью теоремы Кантора о мощности мн-в, но это так же не входит в матан.


    WH>Все что можно сделать, это указать на бред.


    Это от невладения информацией у читателя.
    Re[22]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 13.04.12 12:00
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>Откуда, вы думаете, берутся шестистраничные запросы на SQL? Да ровно оттуда же: нет никаких возможностей по декомпозиции. Приходится всё писать в теле запроса.


    Кто мешает написать своё расширение SQL, которое это может? Вы же все-равно запускаете запросы не из некой "стандартной консоли", а из своего приложения, так? Грамматика SQL проста до безобразия и в сети лежит множество готовых парсеров, которые расширить на свои потребности можно с пол-пинка.
    Re[17]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 13.04.12 12:09
    Оценка: :)
    Здравствуйте, WolfHound, Вы писали:

    T>>Сложность семантики не зависит ни от дсл ни от библиотеки, она определеятся доменом. Есть специалист по домену — значит будет N-готовых решений и легкость проектирования. Нет такого — надо тратить время сначала на формализацию, а уже потом, если хватит времени — на ДСЛ.

    WH>А если не хватит, то потратить в 100 раз больше времени чтобы долбить код на языке низкого уровня.

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

    T>>Я демонстрирую тебе подход бизнеса.

    WH>К чему? Собственному разорению?

    Внутренности винды видел ? Похоже, что нет.

    T>>Не надо передёргивать. 10% это процент расходов на всех разработчиков. Т.е. сумма ЗП разрабов за период поделить на бюджет и помножить на 100.

    WH>И на что же тратятся остальные 90%. Похоже у вас там воруют. Либо просто управленцы дураки.
    WH>Это конечно если мы про контору, которая чисто разработкой живет, говорим.

    90% это управление и маркетинг. Ты вообще в курсе, что маркетинг увеличивает выхлоп каждого девелопера в десятки а то и сотни раз ?

    T>>Сами формализуем как умеем. А ты похоже вещаешь про те задачки, которые хорошо формализованы еще десятки лет назад.

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

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

    WH>>>Тех, кто не учиться нужно, отправлять в дворники, а не программистом брать.

    T>>Я только за. Предложи хорошее решение.
    WH>Не брать. В чем проблема то?

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

    WH>>>Хорошие инженеры учатся всегда. Они просто не могут, не учится. Иначе моментом тупеют и теряют квалификацию.

    T>>Квалификация ради квалификации ? Я боюсь что это утопия.
    WH>Это реальность. Иначе программист за пару лет стане непрофпригодным.

    Есть спрос на конкретные задачи а не на задачи вообще.

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

    WH>Ну, так и не надо таких брать.

    ты хочешь переделать чуть более чем весь мир

    WH>Нужно взять в 10 раз меньше нормальных. И показать им как ДСЛи делать.

    WH>И они в 100 раз быстрее все сделают.

    Приходи с такими цифрами к CEO какого нибудь софтверного гиганта. Если у тебя все получится, в ближайшие 10 лет увидим адский прорыв. Правильно ?

    WH>Сколько я видел тех, о ком ты говоришь весь их код, после увольнения переписывался. Его даже без ДСЛ становилось в разы меньше и все баги пропадали.


    Не всегда есть возможность нанять тех, кого хочется. Квалифицированых специалистов на порядки меньше чем проектов. Да и квалифицированые часто ничего кроме вселенских проблем не хотят решать
    The animals went in two by two, hurrah, hurrah...
    Re[17]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 13.04.12 12:13
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    V>Или взять популярный случай размерности величин. Не думаю, что для вменяемого программиста запись 42kg будет сильно отличаться от записи 42*unit.kg или unit.kg(42), тем более, что константы в коде встречаются относительно редко.

    И никто такой код писать не будет. Ибо мусора много.

    V>Есть, конечно, момент кодогенерации, как в BLT (что есть тоже DSL на атрибутах), но этот момент прекрасно обыгрывается через post-build step.

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

    V>С какой радости малюсенький сугубо прикладной раздел теории мн-в стал разделом части фундаментальной математики?

    А что это?
    Математика она и есть математика.

    V>Приплыли..

    Это точно.

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

    Ох. Реляционная алгебра тут вообще не причем.
    Я просто показал гапертону практически полезный ДСЛ в основе которого матан.
    Тем самым опровергнув его утверждение.

    V>Ну... сложные вещи даже на SQL просто не запишешь. Особенно когда речь пойдет о необходимости cross или outer join и понимании работы nullable-типов в этих случаях, если необходимо по таким выборкам производить ограничения.

    Напиши это при помощи fopen, fread и fwrite. С ACID в полный рост.
    Удачи.

    V>Опять промазал. Это прикладная наука формальных языков и их грамматик. Это не матан. Хотя задевает крылом области раздела традиционной математики при введении понятия мощности языков с помощью теоремы Кантора о мощности мн-в, но это так же не входит в матан.

    Ты бредешь. Теореммы есть? Есть. Доказательства есть? Есть.
    Матан. По определению.

    WH>>Все что можно сделать, это указать на бред.

    V>Это от невладения информацией у читателя.
    Во-во. Не читай про то, что не понимаешь. И тем более не комментируй.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[20]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 13.04.12 12:14
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    G>>>Так это и есть та мощность языка, которую имеет смысл тут рассматривать.

    V>>Это выразительность.
    G>Ок, напиши вместо мощности выразительность. Чтонить изменится? Мы тут не корректность терминов обсуждаем.

    Не термины?

    G>Тогда давай формализуем понятие мощности.
    Давно уже. Мощность некоторого языка — это мощность мн-ва допустимых цепочек.


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

    ОК. Чтобы закрыть тему, пару полезных ссылок, где фактически "на пальцах" о мощности мн-в:
    http://www.lif.univ-mrs.fr/~ashen/part1.pdf
    http://ru.m.wikipedia.org/wiki/Мощность_множества
    http://www.ega-math.narod.ru/Singh/Cantor.htm

    Насколько велико бесконечное множество? Кантор доказал существование иерархии бесконечностей, каждая из которых «больше» предшествующей. Его теория множеств — один из краеугольных камней математики.

    Re[30]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 13.04.12 12:17
    Оценка:
    Здравствуйте, Vain, Вы писали:

    V>Не так, в sql много чего кроме самих запросов. На самом деле сами запросы это вершина айсберга. Можно взять любой учебник по SQL и поисследовать на тему что ещё входит в "знания по SQL".

    Только в этой теме говорится о том что аналогичный запрос на С++ будет на порядки сложнее.
    Так что совершенно не ясно к чему ты это сказал.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[19]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 13.04.12 12:20
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    T>>Откуда негатив к Экселю ? Покажи пример. Например импортируем из экселя колонки чисел в csv формате. Покажи, как правильный файл повалит string split.

    S>Держите:
    S>
    S>A,B
    S>"0,77","1,22"
    S>"12,44","5,23"
    S>

    S>Удачи со string.split.

    Цепочка импорта чуток удлинняется, в качестве разделителя задаются tab. Формально это не csv, но главное это импорт, а на форматы забили. Бизнес не будет проверять CSV или нет, он будет проверять проходил ли сам импорт. Обычно дает набор файлов.
    The animals went in two by two, hurrah, hurrah...
    Re[19]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 13.04.12 12:23
    Оценка:
    Здравствуйте, koodeer, Вы писали:

    K>Как только возникнет понимание. Хотя бы небольшое понимание. При традиционном подходе в этом случае будет создана небольшая библиотека с набором функций. В нашем случае будет создан небольшой DSL.

    K>По мере дальнейшего освоения специфики будет развиваться либо библиотека, либо DSL.

    Здесь Wolfhound сказал что второй вариант будет на три порядке дешевле, т.е. разрабов в 10 раз меньше и в 100 раз времени меньше.
    Понятно, что цифры с потолка, но хотелось бы четкие основания и более менее адекватные оценки, а не так, что взяли десять дураков, дали джаву, взяли десять толковых и посадили за ДСЛ.

    T>>Специфику бизнеса люди годами осваивают и даже десятками лет.

    K>Скорее так: годами и десятками лет пытаются выразить специфику неудобными конструкциями языков общего назначения. Колются, плачут, но продолжают мучиться.

    Это наверное твой случай.
    The animals went in two by two, hurrah, hurrah...
    Re[23]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 13.04.12 12:23
    Оценка:
    Здравствуйте, vdimas, Вы писали:
    V>Кто мешает написать своё расширение SQL, которое это может? Вы же все-равно запускаете запросы не из некой "стандартной консоли", а из своего приложения, так? Грамматика SQL проста до безобразия и в сети лежит множество готовых парсеров, которые расширить на свои потребности можно с пол-пинка.
    Да в общем-то никто. Просто спроектировать это так, чтобы оно работало, не вполне тривиально. Скажем, view и SP хранятся внутри базы. А спроектированные на "внешнем языке" функции этого ESQL должны жить где-то ещё, т.к. в базе им места нету.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[18]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 13.04.12 12:28
    Оценка: :)
    Здравствуйте, WolfHound, Вы писали:

    WH>Напиши это при помощи fopen, fread и fwrite. С ACID в полный рост.


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


    WH>Ты бредешь. Теореммы есть? Есть. Доказательства есть? Есть.

    WH>Матан. По определению.

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

    WH>Во-во. Не читай про то, что не понимаешь. И тем более не комментируй.


    Re[15]: Просто мысль...
    От: oldjackal Россия  
    Дата: 13.04.12 12:32
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

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

    WH>Ты просто пытаешься понять, основываясь на модели лиспа.

    Лисп не при чем. Я пытаюсь понять, основываясь на идее построения иерархии DSL.

    WH>Но у меня другая модель.

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

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

    Причем, абсолютно ничего такого в Nemerle нет, что помешало бы сделать это правильно — например, добавить аттрибут функциям, определяющий, пойдут они в "runtime" модуль или только в "macro module". И последний делать динамическим (это легко средствами Reflection.Emit делается). Получится вся статическая прелесть Nemerle, со всей его раздельной компиляцией, и при этом некий аналог image из Лиспов и Смоллтолков. Ничем за это платить не надо, никаких дополнительных накладных расходов, а вот возможностей это даст невообразимое количество.

    Не стоит так вот запросто отмахиваться от опыта Лиспа только за то, что там скобочки и он динамический. У него всем остальным еще учиться и учиться.

    O>> Я правильно понимаю, что в { ... } может быть произвольный императивный код?

    WH>Нет. Зачем?

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

    WH>assert'ов и еще кое-чего достаточно. На их основе будет построен алгоритм вывода типов.

    WH>А в случае если вывод не удался, будет выдано соответствующее сообщение.

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

    WH>Подход V8 круче. Он может больше вывести. Но всё равно до нормальной статики не дотягивает.


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

    O>> Да и не стоит забывать, что в .NET от RTTI все равно не избавишься, так почему бы им не пользоваться тогда?

    WH>Если его не трогать, то оно почти ничего не просит.
    WH>А если тронуть получишь просадку производительности в десятки раз.

    Каким образом? Компилятору от RTTI много не надо. Узнать типы, сравнить типы на приводимость, и т.д.

    WH>>>Ну так я и планирую ввести предметно ориентированные системы типов.

    O>> Для чего нужна самая базовая система типов, которая никаких ограничений не накладывает вообще.
    WH>Зачем?

    Чтобы на нее можно было наложить любую возможную систему типов.

    O>> А есть возражения?

    WH>Есть. Мне не известны компиляторы динамически типизированных языков, которые всегда могут вывести типы. Они все рано или поздно сваливаются в динамическую типизацию.

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

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

    WH>Но эти ошибки я считаю ошибками разработчика макроса.

    А он может дать по рукам за корректный, но нетипизируемый код. И именно этого и хотелось бы избежать.

    WH>Те internal macro error.

    WH>И при обнаружении такой ошибки нужно чинить макрос. А не код, который его использует.

    В том и фокус, что несовпадение типов далеко не всегда является ошибкой.

    O>> Ну да, конечно же, SSA эквивалентен CPS. Только вот в SSA все намного короче и проще получается.

    WH>Да я не про CPS, а про обычные хвостовые вызовы.

    Я про общий случай. В общем случае любую лапшу из goto элементарно привести к cps (через ssa).

    O>> И зачем? С goto оптимизировать не надо, оно уже и так оптимально.

    WH>В него переписывать сложнее.

    Да ну? Что вообще может быть проще чем метки и переходы?

    WH>Особенно если иногда нужны не хвостовые вызовы и передача параметров.


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

    WH>Можно конечно поизвращаться с организацией стека и глобальных для автомата переменных, но зачем, если это сделает компилятор языка более низкого уровня?


    А если у нас и так уже достаточно низкоуровневая семантика? Зачем уровень поднимать?
    Re[20]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 13.04.12 12:36
    Оценка:
    Здравствуйте, Tanker, Вы писали:

    O>> Про "все" я не говорил. Я привожу конкретный факт, в компиляторостроении полностью отсуствует связь между теорией и практикой. Факт объективный и тривиально доказуемый.


    T>Боюсь тебя огорчить, но доказательств подобного в этом треде я не видел.


    А если начать применять интеллект? Не пробовали?

    T>>>Выдай эти два строки текста. Надеюсь их длина как в хорошей программе ограничена сотней символов ?


    O>> Уже выдал, чуть раньше, про TRS и алгебру. Ничего кроме этого во всей этой области нет. Денотационные и операционные семантики? Чушь, сводится к TRS. Грамматики? Вообще нерелевантно. Оптимизации? На высоких уровнях сводится к правилам и стратегиям переписывания деревьев, на самых суровых низких уровнях (про которые большинству писателей компиляторов и знать-то не надо) немного сложнее, сводится к правилам и стратегиям переписывания DAG-ов.


    T>Ну можно значит расслабиться, вся евклидова геометрия сводится к трём аксиомам и формальной логике. намёк понятен ?


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

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

    Прекращайте уже спорить о "сложности" темы, про которую вы не знаете ровным счетом ничего. Ознакомьтесь с ней сначала, это легко и просто, а потом уже рассуждайте.
    Re[12]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 13.04.12 12:37
    Оценка:
    Здравствуйте, Tanker, Вы писали:

    T>Простой фильтр. Дизайнер положил на форму галочки — кликаешь, появляются одни объекты. Еще кликаешь — появляются или исчезают другие. И тд.


    Я опять ни слова не понял.
    Re[24]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 13.04.12 12:40
    Оценка:
    Здравствуйте, Tanker, Вы писали:

    O>> А не надо их брать. Я же сказал, это абсолютно иная тема, ничего общего с обсуждаемой не имеющая.


    T>А где граница, что можно брать, а что нельзя ?


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

    O>> За последние лет двадцать я ни разу не сталкивался с необходимостью писать что либо на ассемблере. При том, что моя работа как раз тесно связана с HPC.


    T>HPC не часто требует низкоуровневые оптимизации.


    Ну-ну. В HPC часто требуется real time отклик и очень высокий throughput. Оптимизации там страшные. Но вот на ассемблере кодировать никто все равно не станет. Потому что в этом нет смысла, на ЯВУ можно добиться лучшей производительности чем с ассемблером.

    T> А вот отрисовка простого контрола очень даже часто.


    Даже не смешно.

    O>> Что-то вы совсем зарапортовались. Что за нелепая аналогия? Я говорю о том, что сложность областей несопоставимая. Компиляторы — это тупо и примитивно, и изучается за несколько часов полностью. UI — гигантских размеров дисциплина, на поверхностное знакомство с которой могут уйти годы.


    T>А я говорю про то, что у каждого практика в голове свои уникальные понятия и связи.


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

    T> Соответсвено что одному просто, то другому будет сложно. А Колмгоров говорил совсем про другое.


    Вы хотя бы отдаленное представление имеете о Колмогоровской сложности?
    Re[21]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 13.04.12 12:41
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    T>>Боюсь тебя огорчить, но доказательств подобного в этом треде я не видел.


    O> А если начать применять интеллект? Не пробовали?


    Начни.

    T>>Ну можно значит расслабиться, вся евклидова геометрия сводится к трём аксиомам и формальной логике. намёк понятен ?


    O> До крайности идиотская аналогия. В геометрии полно всяких там теорем и прочей мути, без которой практические задачи решать невозможно.


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

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


    Напиши книгу, я куплю, почитаю.

    O> Прекращайте уже спорить о "сложности" темы, про которую вы не знаете ровным счетом ничего. Ознакомьтесь с ней сначала, это легко и просто, а потом уже рассуждайте.


    Так где же ознакомиться, если весь материал, что есть, по твоим словам негодны
    The animals went in two by two, hurrah, hurrah...
    Re[13]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 13.04.12 12:41
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    T>>Простой фильтр. Дизайнер положил на форму галочки — кликаешь, появляются одни объекты. Еще кликаешь — появляются или исчезают другие. И тд.


    O> Я опять ни слова не понял.


    Тогда это не ко мне.
    The animals went in two by two, hurrah, hurrah...
    Re[23]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 13.04.12 12:43
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    V>Через встроенный ассемблер, вестимо.

    Если у вас есть встроенный ассемблер, то аргумент про библиотеки не нужен. Если нету — то аргумент неприменим.

    V>Но вообще, если программа, порождаемая языком, работает сверху ОС, то языку необходимо только умение подключать библиотеки и больше ничего, чтобы превратиться в язык общего назначения.

    Мне не нравится этот критерий. Потому что он слишком сильно противоречит бытовому понятию DSL. Скажем, Clipper, который, в отличие от VBA, явно заточен на конкретный домен, получается GPPL, т.к. в нём можно подключать библиотеки.

    V>Поэтому строгий DSL никак не сделаешь на основе языков, которые умеют это изкаробки.

    Вот это опять непонятно. Что именно называется "это"? Наличие встроенных в языке средств импорта библиотек?
    Да ну! Вот, скажем, в языке C нет никаких возможностей импорта библиотек. Там всё, что есть — это текст одной программы.
    Библиотеки в него потом запихивает линкер, который отдельный от языка.
    Давайте теперь я напишу версию лого, в синтаксис (и семантику) которого я добавлю IMPORT MODULE XXX. Он что, от этого внезапно станет GPPL? Возможность имитировать логовский модуль при помощи сторонних средств (а именно это и делается в тот момент, когда мы стряпаем библиотеку для С-программ на языках типа ассемблера) мне не кажется ключевой для осмысления этого.
    V>Но на JS или LUA прекрасно сделаешь.
    Объясните мне ещё раз, чем С в этом смысле хуже JS.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[25]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 13.04.12 12:44
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    T>>HPC не часто требует низкоуровневые оптимизации.


    O> Ну-ну. В HPC часто требуется real time отклик и очень высокий throughput. Оптимизации там страшные. Но вот на ассемблере кодировать никто все равно не станет. Потому что в этом нет смысла, на ЯВУ можно добиться лучшей производительности чем с ассемблером.


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

    T>> А вот отрисовка простого контрола очень даже часто.


    O> Даже не смешно.


    T>>А я говорю про то, что у каждого практика в голове свои уникальные понятия и связи.

    O> Чушь. Они настолько примитивные, что никакого расхождения быть не может.

    И поэтому ты через сообщение записывашь в дураки чуть не всех подряд ?

    T>> Соответсвено что одному просто, то другому будет сложно. А Колмгоров говорил совсем про другое.


    O> Вы хотя бы отдаленное представление имеете о Колмогоровской сложности?


    Конечно, только я довожу до тебя простую мысль, которая никакого отношения к его сложности не имеет.
    The animals went in two by two, hurrah, hurrah...
    Re[18]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 13.04.12 12:47
    Оценка:
    Здравствуйте, Tanker, Вы писали:

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


    Сформулированная задача — это уже формализованная задача. По определению. А если задачу даже сформулировать не осилили, то уж и закодировать решение в лоб никто не сможет.

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


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

    T>>>Не надо передёргивать. 10% это процент расходов на всех разработчиков. Т.е. сумма ЗП разрабов за период поделить на бюджет и помножить на 100.

    WH>>И на что же тратятся остальные 90%. Похоже у вас там воруют. Либо просто управленцы дураки.
    WH>>Это конечно если мы про контору, которая чисто разработкой живет, говорим.

    T>90% это управление и маркетинг. Ты вообще в курсе, что маркетинг увеличивает выхлоп каждого девелопера в десятки а то и сотни раз ?


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

    T>Жалко, людей вроде тебя не нашлось в UI лет 40 назад, а то уже был бы один грамотный дсл для всех случаев в UI.


    Так никто и не объяснил, на кой нужен "один" DSL "для всех случаев". Да еще и в UI. Это в корне противоречит самой идее DSL.

    WH>>>>Тех, кто не учиться нужно, отправлять в дворники, а не программистом брать.

    T>>>Я только за. Предложи хорошее решение.
    WH>>Не брать. В чем проблема то?

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


    Вы преувеличиваете. Большинство программистов достаточно умны. Раз уж они ООП осилили, то уж намного более простую методологию с DSL осилят без проблем.

    T>Приходи с такими цифрами к CEO какого нибудь софтверного гиганта. Если у тебя все получится, в ближайшие 10 лет увидим адский прорыв. Правильно ?


    Что-то я не видел, чтобы гиганты набирали идиотов. Там как раз все сурово. Идиоты в основном кучкуются в больших аутсорсинговых конторах в некоторых всем известных странах.
    Re[30]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 13.04.12 12:47
    Оценка:
    Здравствуйте, Vain, Вы писали:

    S>>Складывается ощущение, что вы мне пытаетесь доказать, что можно заменить запрос на SQL процедурой на C++, причём последняя будет иметь сопоставимую с запросом сложность. Но этого не может быть, так как это, очевидно, неверно.

    V>Не так, в sql много чего кроме самих запросов. На самом деле сами запросы это вершина айсберга. Можно взять любой учебник по SQL и поисследовать на тему что ещё входит в "знания по SQL".
    Ещё раз спрошу: какой тезис вы пытаетесь доказать или оспорить? Вам что, кто-то тут написал, что SQL — проще, чем С++?
    Нет.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[20]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 13.04.12 12:52
    Оценка:
    Здравствуйте, Tanker, Вы писали:

    T> Цепочка импорта чуток удлинняется, в качестве разделителя задаются tab. Формально это не csv, но главное это импорт, а на форматы забили. Бизнес не будет проверять CSV или нет, он будет проверять проходил ли сам импорт. Обычно дает набор файлов.

    Ну, то есть парсер СSV на string.split нагнулся, теперь вы перешли на tab-delimited values.
    Я рад, что мы хотя бы прояснили вопросы о фатальных недостатках парсеров, построенных на string.split. Второй вариант, который вам известен, я так понял — регексы, да?
    Так вот: они — тоже не работают. Работают парсеры, честно построенные на стейт-машине. У них всё в порядке с быстродействием и надёжностью. Плохо у них только с объёмом ручного кода. DSL для построения парсеров позволил бы значительно сократить время разработки и избежать приседаний с внезапным переходом с CSV на TDV после запуска системы в эксплуатацию в РФ, где десятичной точкой неожиданно является запятая.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[18]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 13.04.12 12:55
    Оценка:
    Здравствуйте, Tanker, Вы писали:

    O>> Поразительная упертость. Включите мозг! Практика лет 60 существует. Компиляторы всех мастей пишут, не напрягаясь. Наплевав на рассуждения теоретиков. Никаких сложностей и неясных моментов в практике нет уже очень давно. А теоретики как рассуждали про "формальные грамматики", как спорили про разницу между LALR(1) и SLR, так и спорят, тогда как абсолютно все практики всегда пишут ad hoc рекурсивные парсеры и знать не желают про баталии дебилов-теоретиков.


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


    Опять глупости говорите. Несусветные глупости. Ну явно не имеете понятия о Колмогорове и его сложности.

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

    O>> Советую прежде чем продолжать этот нелепый спор, где вы заведомо и на все 100% лажаетесь, посмотрите на существующие промышленные компиляторы. Попробуйте найти там хотя бы малюсенький след того, о чем рассуждают дебилы-теоретики. Найдите там хотя бы одну страницу драконьей книги, на которую теоретики молятся. Не найдете! Ни в gcc, ни clang/llvm, ни в HotSpot, ни в CPython, нигде!


    T>Зато знания уложеные в гцц невозможно распространять.


    Можно. Элементарно. Один из разработчиков gcc несколько лет назад объяснил мне про ssa на пальцах. За пять минут. Хватило. А это, пожалуй, самое сложное что там есть. Остальное из чтения исходников понимается легко и непринужденно.

    T> А книгу драконо — можно, хотя и сложно.


    Может и "можно", но не нужно. Ее по хорошему следовало бы признать экстремистской и запретить.

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


    T>Связь есть но не там где ты хочешь видеть.


    Конкретика где? Такая-то страница дракона, применена в таких-то и таких-то исходных файлах gcc. Без этого все, что вы говорите — пустой треп.

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


    T>У каждого практика в голове свой набор понятий и связей. Что бы эти понятия стали общими, нужны теоретики.


    Нужно живое общение между практиками. Общие понятия рождаются сами, без помощи высоколобых теоретиков.

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


    T>На рынке труда, где и все.


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

    Все, кого я видел из МГУ, МФТИ, СПбГУ и прочих "крутых" ВУЗов не умели ничего, если только не учились вне ВУЗа.
    Re[19]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 13.04.12 12:56
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    O> Расстреливать таких манагеров, которые привлекают к "управлению и маркетингу" инженеров. Каждый сверчок должен знать свой шесток. Программисты должны программировать, 100% рабочего времени.

    Не, он не про это. Он про то, что кроме инженеров, у компаний есть и другие источники затрат. Скажем, чтобы твой продукт купили, нужно оплачивать расходы на маркетинг. Руководству компании эффективность труда одного подразделения, пусть даже и самого важного, важна пропорционально доле ФОТ этого подразделения в бюджете компании.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[16]: Языки общего назначения не имеют смысла!
    От: fmiracle  
    Дата: 13.04.12 12:57
    Оценка:
    Здравствуйте, Tanker, Вы писали:

    O>> Затем, что иначе это не будет поддежкой CSV. Потому как валидный CSV поломает этот "парсер" запросто.

    T>правильно. Поддержка CSV ради поддержки CSV не нужна. Задача решена — парсер не нужен. А решена ли задача или нет, проверяет и определяет человек из бизнеса.

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

    Другое дело, что во множестве систем для передачи данных может использоваться другой формат, условно назовем его CSVlite, который описывается как "Текстовые поля, разделенные запятой. Значения полей не могут содержать запятой или перевода строки". На него отлично ложатся матрицы целых чисел, например. Этот формат часто путают с CSV, но это ошибка, это другой формат, подмножество CSV. И разбирать его действительно гораздо проще.
    Re[19]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 13.04.12 12:58
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    O> Про "все" я не говорил. Я привожу конкретный факт, в компиляторостроении полностью отсуствует связь между теорией и практикой. Факт объективный и тривиально доказуемый.


    Скажите мне Киса, как художник художнику, вот Аппель — он по делу пишет, или только теоретик? Я имею в виду http://www.cs.princeton.edu/~appel/modern/

    Мне правда интересно, т.к. в компиляторостроении я некомпетентен. Ищу жизненные ориентиры. Дракона прочитать так и не сподобился; после вашей рецензии, возможно, уже и не сподоблюсь.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[16]: Просто мысль...
    От: WolfHound  
    Дата: 13.04.12 12:59
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    O> И вот в этом подходе никакой иерархии я не вижу. Хотелось бы, чтобы можно было каждый следующий крошечный DSL писать в терминах предыдущего. Делать по dll на каждый из них просто глупо и неудобно.

    Ну, так я и написал генератор парсера в терминах немерле.
    Немерле превратил все это в MSIL.
    JIT преваритл MSIL в машинный код.

    И все они живут в разных ДЛЛ.

    Добавить новые уровни не проблема.

    O>Ничем за это платить не надо,

    Тормозами.

    O>никаких дополнительных накладных расходов, а вот возможностей это даст невообразимое количество.

    Не даст.

    O> Не стоит так вот запросто отмахиваться от опыта Лиспа только за то, что там скобочки и он динамический. У него всем остальным еще учиться и учиться.

    Ох. Я его прекрасно понимаю.
    Просто мой подход умеет все тоже самое.

    O> На всякий случай. Потому как assert это только малая часть того, что можно (и нужно) делать с типами. Надо не только проверять корректность входных типов (они могут быть и неизвестными, быть привязанными к неотрезолвленной еще переменной), а уметь выводить новые уравнения для вывода типов, как минимум.

    Так эти уравнения будут выведены и assert'ов.
    В этом вся идея.

    O>И делать это только декларативно может оказаться неоправданно сложным.

    Например?

    O> Еще одно проблемное место — такие сообщения очень непросто сделать понятными и разумными.

    Это как?
    Что в тех сообщениях, что я показал не понятно?

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

    Это как раз не проблема.
    И опыт немерла это прекрасно демонстрирует.
    Сообщения макросов вполне понятные если ими озаботиться.

    O> Каким образом? Компилятору от RTTI много не надо. Узнать типы, сравнить типы на приводимость, и т.д.

    А зачем тут RTTI? Особенно если типы у нас не .НЕТные, а предметно ориентированные?
    Как RTTI поможет при сравнении этого?
      [Record]
      public variant RuleType : Nemerle.Compiler.Located
      {
        | List   { ty : RuleType; }
        | Option { ty : RuleType; }
        | Tuple  { types : list[RuleType]; }
        | PType  { ty : PExpr; }
        | NType  { ty : FixedType; }
        | Chars
        | Void

    Да и сам по себе .НЕТный RTTI та еще кака.
    А если учесть то что я планирую полностью отвязать систему от .НЕТ то это вообще неприемлемо.

    O> Чтобы на нее можно было наложить любую возможную систему типов.

    А зачем на нее накладывать?
    Если можно просто задать нужную систему типов?
    Как я сделал в генераторах парсеров?

    O> А для таких редких случаев можно опциональную статическую типизацию применять. Главное, чтобы она не была насильственной.

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

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

    WH>>Но эти ошибки я считаю ошибками разработчика макроса.
    O> А он может дать по рукам за корректный, но нетипизируемый код. И именно этого и хотелось бы избежать.
    Кто-то что-то явно не понимает.

    O> В том и фокус, что несовпадение типов далеко не всегда является ошибкой.

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

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

    O> Да ну? Что вообще может быть проще чем метки и переходы?

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

    WH>>Особенно если иногда нужны не хвостовые вызовы и передача параметров.

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

    O> А если у нас и так уже достаточно низкоуровневая семантика? Зачем уровень поднимать?

    Какая? По-хорошему goto должны появляться не раньше превращения "базового немерле" в "MSIL". Кавычки тут по тому, что я просто показываю уровень языков.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[16]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 13.04.12 13:01
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    O>> Другой мерзопакостный леворекурсивный пример — грамматика типов в C (и тем более в C++).

    WH>Опять-таки никаких проблем.
    WH>Просто описываешь правило для разборки типа и вперед.

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

    O>> Тогда с задержкой раскрашивать будет. Неудобно.

    WH>Ты задержку порядка сотни миллисекунд не заметишь.

    Есть простая в установке сборка Nemerle расширений для visual studio, на которой я мог бы это посмотреть? Когда я в последний раз пробовал собрать это дело, у меня не получилось (уже не помню, по какой причине).

    O>> Какой такой АСТ? Там АСТ еще нет, недопарсили его.

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

    А, для таких warning-ов все еще веселее. В AST нужной информации уже нет. a||b && c||d распарсится в точно такое же AST, что и (a||b) && (c||d).

    O>> Кстати, мемоизация пакрата как раз в востановлении после ошибок помогает неплохо, но даже ее недостаточно.

    WH>В общем случае нужны правила для разбора ошибочного кода.

    Естественно. Не ясно только, как их в виде правил изобразить-то, без императивного тупого кода.

    O>> Но можно ведь генерить и не-говнокод, а что-то читабельное и коротенькое. Тот же packrat и на комбинаторах делается неплохо.

    WH>Но тормозит.

    Может быть. Мне в большинстве случаев скорость разбора интересна в последнюю очередь.

    O>> Вот мысли как раз и интересуют. Я ничего придумать не смог. Ни в плане DSL, ни тем более в плане реализации. Когда есть императивный, тупой код, приправленный тупейшим PEG-генератором, то все понятно, можно любые проверки воткнуть куда угодно в процесс разбора. А вот как их декларативно описать, в самом общем виде?

    WH>Просто семантика деклараций должна быть разбирающей, а не как в БНФ порождающей.
    WH>Тогда мы просто вводим специальное правило, которое парсит ошибочный код и все.
    WH>И получаем всю гибкость без лишнего кода.

    Мне нужно это увидеть, чтобы понять.
    Re[20]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 13.04.12 13:03
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>Не, он не про это. Он про то, что кроме инженеров, у компаний есть и другие источники затрат. Скажем, чтобы твой продукт купили, нужно оплачивать расходы на маркетинг. Руководству компании эффективность труда одного подразделения, пусть даже и самого важного, важна пропорционально доле ФОТ этого подразделения в бюджете компании.

    Это не правда.
    Если идиоты будут делать продукт в десять раз дольше конкурентов и с кучей багов, то нужен очень суровый маркетинг чтобы этот продукт впарить.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[22]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 13.04.12 13:08
    Оценка:
    Здравствуйте, Tanker, Вы писали:

    O>> До крайности идиотская аналогия. В геометрии полно всяких там теорем и прочей мути, без которой практические задачи решать невозможно.


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


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

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


    T>Напиши книгу, я куплю, почитаю.


    Может мне еще и про "2+2=4" и про "Hello, World!" написать? Сопоставимые по сложности темы.

    O>> Прекращайте уже спорить о "сложности" темы, про которую вы не знаете ровным счетом ничего. Ознакомьтесь с ней сначала, это легко и просто, а потом уже рассуждайте.


    T>Так где же ознакомиться, если весь материал, что есть, по твоим словам негодны


    Что, кроме драконьей книги ничего нет? Вранье. Полно отличного материала. Одно из лучших, что я видел:

    http://www.iro.umontreal.ca/~boucherd/mslug/meetings/20041020/90-min-scc/90-min-scc.pdf

    так же неплохо: http://llvm.org/docs/tutorial/

    А так же одна из глав SICP. Он вообще весь малость затянутый, там все мелочи разжевывают многократно, но относительно компиляции они палку не слишком сильно перегибают.
    Re[26]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 13.04.12 13:12
    Оценка: +2
    Здравствуйте, Tanker, Вы писали:

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


    Вы опять с умным видом рассуждаете о теме, в которой ни бум-бум. Лучше про "фильтры" и контроллы рассуждайте, это явно ваш конек.
    Какая такая "диспетчеризация"? Часто вообще никакой ОС нет, все на голом железе живет. И нужно уместить довольно сложные вычисления в заданное количество миллисекунд, любыми путями. Казалось бы, как раз для ассемблера задача — ан нет, на C быстрее получается. Нельзя человеку соревноваться с современными компиляторами, компиляторы умнее.

    T>>>А я говорю про то, что у каждого практика в голове свои уникальные понятия и связи.

    O>> Чушь. Они настолько примитивные, что никакого расхождения быть не может.

    T>И поэтому ты через сообщение записывашь в дураки чуть не всех подряд ?


    Не всех. Только дураков. А их очень мало. Это вы тут распинаетесь, что мол все программисты тупые и ничего сложнее string.split никогда не осилят, а у меня есть все основания вам не верить, мне дураки редко попадаются.

    O>> Вы хотя бы отдаленное представление имеете о Колмогоровской сложности?


    T>Конечно, только я довожу до тебя простую мысль, которая никакого отношения к его сложности не имеет.


    Мне абсолютно не интересны ваши нерелевантные простые мысли. Мы обсуждали сравнение сложности двух предметных областей.
    Re[21]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 13.04.12 13:13
    Оценка:
    Здравствуйте, WolfHound, Вы писали:
    WH>Это не правда.
    WH>Если идиоты будут делать продукт в десять раз дольше конкурентов и с кучей багов, то нужен очень суровый маркетинг чтобы этот продукт впарить.
    Ты не переживай. Каждый род войск думает, что он главный.
    Реальная картина — именно такая, как я сказал. Затраты на разработчиков составляют совсем не такую большую долю в бюджетах компаний, как думают разработчики. Более того, если эта доля велика, то вы недополучаете прибыль, т.к. вложения в sales force окупятся гораздо быстрее вложений в инженерный департамент.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[21]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 13.04.12 13:14
    Оценка: -2
    Здравствуйте, Sinclair, Вы писали:

    S>Так вот: они — тоже не работают. Работают парсеры, честно построенные на стейт-машине. У них всё в порядке с быстродействием и надёжностью. Плохо у них только с объёмом ручного кода. DSL для построения парсеров позволил бы значительно сократить время разработки и избежать приседаний с внезапным переходом с CSV на TDV после запуска системы в эксплуатацию в РФ, где десятичной точкой неожиданно является запятая.


    Это не совсем так. Точнее, совсем не так. Самые быстрые парсеры получаются ручной оптимизацией рекурсивного ad hoc кода. Посмотрите на clang, на gcc. А вот "построенные на стейт-машине" — это как раз та самая драконовщина, которую надо всячески искоренять.
    Re[20]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 13.04.12 13:16
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>Скажите мне Киса, как художник художнику, вот Аппель — он по делу пишет, или только теоретик? Я имею в виду http://www.cs.princeton.edu/~appel/modern/

    Я его не читал. Но судя по первым страницам та же драконщина.
    Только менее фундаментальная.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[20]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 13.04.12 13:18
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    O>> Про "все" я не говорил. Я привожу конкретный факт, в компиляторостроении полностью отсуствует связь между теорией и практикой. Факт объективный и тривиально доказуемый.


    S>Скажите мне Киса, как художник художнику, вот Аппель — он по делу пишет, или только теоретик? Я имею в виду http://www.cs.princeton.edu/~appel/modern/


    S>Мне правда интересно, т.к. в компиляторостроении я некомпетентен. Ищу жизненные ориентиры. Дракона прочитать так и не сподобился; после вашей рецензии, возможно, уже и не сподоблюсь.


    Аппель на порядки лучше и практичнее драконьей книги. Тоже конечно же хватает лишнего, но большая часть по делу, особенно если про парсинг не читать. Правда, там слишком низкий уровень описывается, для DSL это все просто не нужно (instruction scheduling всякий, алгоритмы раскраски регистров и т.д.). Если хотите писать компилятор Си, то книга годная. Если простые DSL, то где-то треть от книги пригодится.
    Re[22]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 13.04.12 13:20
    Оценка:
    Здравствуйте, oldjackal, Вы писали:
    O> Это не совсем так. Точнее, совсем не так. Самые быстрые парсеры получаются ручной оптимизацией рекурсивного ad hoc кода. Посмотрите на clang, на gcc. А вот "построенные на стейт-машине" — это как раз та самая драконовщина, которую надо всячески искоренять.
    В общем случае — возможно. Но для разбора CSV быстрее стейт-машины вы в принципе ничего не получите. Уж очень формат простой: там нет никакой рекурсии, состояний всего четыре.
    Может, я чего-то не понимаю? Покажите, какой парсер CSV вы имеете в виду.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[22]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 13.04.12 13:24
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>Ты не переживай. Каждый род войск думает, что он главный.

    S>Реальная картина — именно такая, как я сказал. Затраты на разработчиков составляют совсем не такую большую долю в бюджетах компаний, как думают разработчики. Более того, если эта доля велика, то вы недополучаете прибыль, т.к. вложения в sales force окупятся гораздо быстрее вложений в инженерный департамент.
    Я не про то.
    Если программеры выкатили продукт на несколько лет позже конкурентов с кучей багов и тормозов то этому продукту никакие маркетойды не помогут.
    Точно также случится, если рынок уже типа занят, но приходит конкурент, который выкатывает фичи в 10 раз быстрее. При этом его продукт не тормозит и не глюкает. А если он еще и импортом данных из монстрика конкурентов озиботится.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[17]: Просто мысль...
    От: oldjackal Россия  
    Дата: 13.04.12 13:30
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    O>> И вот в этом подходе никакой иерархии я не вижу. Хотелось бы, чтобы можно было каждый следующий крошечный DSL писать в терминах предыдущего. Делать по dll на каждый из них просто глупо и неудобно.

    WH>Ну, так я и написал генератор парсера в терминах немерле.
    WH>Немерле превратил все это в MSIL.
    WH>JIT преваритл MSIL в машинный код.

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

    WH>И все они живут в разных ДЛЛ.


    WH>Добавить новые уровни не проблема.


    И по dll на уровень? У меня сотни уровней бывают.

    O>>Ничем за это платить не надо,

    WH>Тормозами.

    Откуда тормоза?!?

    O>>никаких дополнительных накладных расходов, а вот возможностей это даст невообразимое количество.

    WH>Не даст.

    Все таки вы до сих пор не понимаете.

    O>> Не стоит так вот запросто отмахиваться от опыта Лиспа только за то, что там скобочки и он динамический. У него всем остальным еще учиться и учиться.

    WH>Ох. Я его прекрасно понимаю.
    WH>Просто мой подход умеет все тоже самое.

    Да нет же, не умеет! Я не смогу раскрыть макру в код, определяющий другую макру, которая в следующей же строке и будет использована. Тем более я не смогу раскрыть макру в код, определяющий другую макру и код, эту другую макру использующий. А все это совершенно необходимо для реализации DSL в виде последовательности малых преобразований.

    O>> На всякий случай. Потому как assert это только малая часть того, что можно (и нужно) делать с типами. Надо не только проверять корректность входных типов (они могут быть и неизвестными, быть привязанными к неотрезолвленной еще переменной), а уметь выводить новые уравнения для вывода типов, как минимум.

    WH>Так эти уравнения будут выведены и assert'ов.
    WH>В этом вся идея.

    Это уже очень существенное ограничение.


    O>> Еще одно проблемное место — такие сообщения очень непросто сделать понятными и разумными.

    WH>Это как?
    WH>Что в тех сообщениях, что я показал не понятно?

    Это простейший случай. В жизни все сложнее.

    O>> Каким образом? Компилятору от RTTI много не надо. Узнать типы, сравнить типы на приводимость, и т.д.

    WH>А зачем тут RTTI? Особенно если типы у нас не .НЕТные, а предметно ориентированные?

    Например, чтобы при раскрытии макры знать, какие методы есть у объектов этого типа.

    WH>А если учесть то что я планирую полностью отвязать систему от .НЕТ то это вообще неприемлемо.


    Тогда да, тогда другого выбора нет.

    O>> Чтобы на нее можно было наложить любую возможную систему типов.

    WH>А зачем на нее накладывать?
    WH>Если можно просто задать нужную систему типов?
    WH>Как я сделал в генераторах парсеров?

    Ну как зачем? Если мы преобразуем DSL в язык более низкого уровня, то его система типов должна так же преобразовываться в систему типов целевого языка.

    O>> А для таких редких случаев можно опциональную статическую типизацию применять. Главное, чтобы она не была насильственной.

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

    В том и дело, что не справляются.

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

    WH>>>Но эти ошибки я считаю ошибками разработчика макроса.
    O>> А он может дать по рукам за корректный, но нетипизируемый код. И именно этого и хотелось бы избежать.
    WH>Кто-то что-то явно не понимает.

    Я уже приводил банальный пример — комбинатор фиксированной точки.

    O>> В том и фокус, что несовпадение типов далеко не всегда является ошибкой.

    WH>А для меня всегда.

    То есть, Y-комбинатора не существует?

    WH>Я всю работу строю так чтобы если я что-то не так сделаю чтобы это поймали типы.

    WH>На 100% не получается но даже то что есть экономит кучу нервов.

    Свою работу можно так и строить (хоть это и уныло). Но вот пытаться семантику всех-всех возможных DSL засунуть в это прокрустово ложе это уже опасно.

    WH>За такие плюшки я готов простить негибкость статической типизации в клинических случаях.


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

    WH>А при наличии предметно-ориентированной системы типов это вообще не проблема.

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

    Ценность интеллисенса для меня крайне сомнительна. Он нужен только в нагрузку к гигантским, идиотским ООП-фреймворкам.

    O>> Да ну? Что вообще может быть проще чем метки и переходы?

    WH>Добавляем стек и передачу данных в состояние и все становится не таким простым.

    А если мы их добавим, то это уже совсем другой уровень, не тот, на котором goto нужны..

    O>> А если у нас и так уже достаточно низкоуровневая семантика? Зачем уровень поднимать?

    WH>Какая? По-хорошему goto должны появляться не раньше превращения "базового немерле" в "MSIL".

    С чего вдруг? Мне проще всего скомпилировать FSM в кучу меток и goto. Если я из него буду switch делать, то это уже усложнение. Семантика goto идеально подходит к семантике перехода между состояниями в FSM. При этом уровень языка в обработчиках состояний может быть сколь угодно высоким.
    Re[12]: Языки общего назначения не имеют смысла!
    От: fmiracle  
    Дата: 13.04.12 13:34
    Оценка: +2
    Здравствуйте, Tanker, Вы писали:

    T>>>Это и показывает, что материал сложный. Когда материал простой, все студенты его на раз умеют.

    WH>>Нет. Это показывает, что студентов учат не правильному материалу.
    T>Если так, то это значит, что тема компиляторов сложна даже для преподавателей.

    Я помню в школе у нас учительница преподавала химию и было все просто и понятно. Потом она переехала, вместо нее пришел новы преподавать, и сразу резко стало сложно и непонятно. Хотя сложность предмета при этом явно не изменилась.
    Re[19]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 13.04.12 13:34
    Оценка:
    Здравствуйте, vdimas, Вы писали:

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


    WH>>Напиши это при помощи fopen, fread и fwrite. С ACID в полный рост.


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

    Покажите код, который будет пользоваться этими операциями.
    Скажем, аналог
    select Manager.Name, OrderTotals.Amount 
    from Manager 
    inner join City on City.ID = Manager.CityID
    inner join 
      (select ManagerID, sum(Orders.Amount) from Orders where Orders.OrderDate between '20100101' and '20101231' group by ManagerID) 
        OrderTotals on OrderTotals.ManagerID = Manager.ID
    where City.Name like 'Н%'
    order by 2 desc


    V>Матан — это не теоремы, это исследование ф-ий и их систем.

    Он про другой матан.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[23]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 13.04.12 13:38
    Оценка: +1
    Здравствуйте, WolfHound, Вы писали:
    WH>Если программеры выкатили продукт на несколько лет позже конкурентов с кучей багов и тормозов то этому продукту никакие маркетойды не помогут.
    К сожалению, и это тоже не так.

    WH>Точно также случится, если рынок уже типа занят, но приходит конкурент, который выкатывает фичи в 10 раз быстрее. При этом его продукт не тормозит и не глюкает. А если он еще и импортом данных из монстрика конкурентов озиботится.

    То ему всё равно потребуются бешеные затраты на маркетинг, т.к. волшебного самораспространения информации не бывает.
    Вообще, есть много стратегий поведения на рынке. И совершенствование продукта — вовсе не единственная из них.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[23]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 13.04.12 13:40
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>Если программеры выкатили продукт на несколько лет позже конкурентов с кучей багов и тормозов то этому продукту никакие маркетойды не помогут.


    Не всегда. Если вспомнить win95 и os/2, например.
    Re[23]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 13.04.12 13:41
    Оценка:
    Здравствуйте, Sinclair, Вы писали:
    S>В общем случае — возможно. Но для разбора CSV быстрее стейт-машины вы в принципе ничего не получите. Уж очень формат простой: там нет никакой рекурсии, состояний всего четыре.

    А, ну да, для CSV даже ad hoc будет реализацией той же самой стейт-машины.
    Re[19]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 13.04.12 13:43
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    O> Сформулированная задача — это уже формализованная задача. По определению. А если задачу даже сформулировать не осилили, то уж и закодировать решение в лоб никто не сможет.


    Я сколько ни работаю, все время все приходится формулировать и формализовывать самому

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

    O> И именно такой подход к быстрому прототипированию и работает быстрее и надежнее всех прочих. Вы не знали?

    Покажи пример.

    T>>90% это управление и маркетинг. Ты вообще в курсе, что маркетинг увеличивает выхлоп каждого девелопера в десятки а то и сотни раз ?


    O> Расстреливать таких манагеров, которые привлекают к "управлению и маркетингу" инженеров. Каждый сверчок должен знать свой шесток. Программисты должны программировать, 100% рабочего времени.


    Еще раз — на проект затрачена определенная сумма, которая кроме зп всех вовлеченных (разрабы, тестеры, маркетинг, менеджмент и тд) включает в себя и аренду, и железо и командировки и все возможные налоги и вызов девок для празднования майлстонов.
    ЗП(гросс) всех разрабов вместе с тестерами это 10% от всей суммы.

    Вроде умные люди, а азы экономики понять не могут С т.з. бизнеса нужно или урезать затраты наибольшей части, 90% или же делать так, что бы общий расклад приносил денег больше. Второй вариант это норма для софтверной индустрии.

    T>>Жалко, людей вроде тебя не нашлось в UI лет 40 назад, а то уже был бы один грамотный дсл для всех случаев в UI.


    O> Так никто и не объяснил, на кой нужен "один" DSL "для всех случаев". Да еще и в UI. Это в корне противоречит самой идее DSL.


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

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

    O> Вы преувеличиваете. Большинство программистов достаточно умны. Раз уж они ООП осилили, то уж намного более простую методологию с DSL осилят без проблем.

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

    T>>Приходи с такими цифрами к CEO какого нибудь софтверного гиганта. Если у тебя все получится, в ближайшие 10 лет увидим адский прорыв. Правильно ?

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

    Не далее чем пару сообщений назад ты назвал людей из конторы-гиганта идиотами. Сейчас ты пошел дальше — назвал тех, кто предлагает всерьез внедрить ДСЛ, идиотами.
    Я уже боюсь оставаться на форуме после таких заявлений
    The animals went in two by two, hurrah, hurrah...
    Re[17]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 13.04.12 13:48
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    WH>>Опять-таки никаких проблем.

    WH>>Просто описываешь правило для разборки типа и вперед.
    O> Может я чего-то и недопонимаю.
    Получается что-то типа такого. Грамматика не полная и с приоритетами мог накосячить. На плюсах давно не писал.
        [Ast()] TypeExpr : Ast;
    
        NameLiteral = ['a'..'z']+;
        Name is TypeExpr  = NameLiteral s;
    
        ConstPrefix  is TypeExpr = "const"s TypeExpr : 10;
        ConstPostfix is TypeExpr = TypeExpr : 10 "const"s;
        Pointer      is TypeExpr = TypeExpr : 20 "*"s;
        Referance    is TypeExpr = TypeExpr : 20 "&"s;
        TypeArgs     is TypeExpr = TypeExpr : 30 "<"s (TypeExpr : 30, ","s)+ ">"s;
        Member       is TypeExpr = TypeExpr : 40 "::"s TypeExpr : 40;


    O>Попробую без левой рекурсии описать.

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

    O> Есть простая в установке сборка Nemerle расширений для visual studio, на которой я мог бы это посмотреть? Когда я в последний раз пробовал собрать это дело, у меня не получилось (уже не помню, по какой причине).

    Немерле тут вообще не причем.
    В нем мои генераторы не используются, если не считать парсера C#.

    Но сам немерле можно взять тут:
    https://github.com/rsdn/nemerle/downloads
    Ночные сборки вполне стабильны.

    Хотя лично я живу на исходниках. Ибо иногда компилятор правлю.

    O> А, для таких warning-ов все еще веселее. В AST нужной информации уже нет. a||b && c||d распарсится в точно такое же AST, что и (a||b) && (c||d).

    Нет. Я сохраняю все. Так что скобки в AST останутся.

    O> Естественно. Не ясно только, как их в виде правил изобразить-то, без императивного тупого кода.

    А в чем проблема? Пример можно?
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[21]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 13.04.12 13:54
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    T>> Цепочка импорта чуток удлинняется, в качестве разделителя задаются tab. Формально это не csv, но главное это импорт, а на форматы забили. Бизнес не будет проверять CSV или нет, он будет проверять проходил ли сам импорт. Обычно дает набор файлов.

    S>Ну, то есть парсер СSV на string.split нагнулся, теперь вы перешли на tab-delimited values.

    Не мы, но да.

    S>Я рад, что мы хотя бы прояснили вопросы о фатальных недостатках парсеров, построенных на string.split. Второй вариант, который вам известен, я так понял — регексы, да?


    Да где ж фатальный, если задача выполняется ? Код наверное 20 лет проработал

    S>Так вот: они — тоже не работают.


    Почему не работают ? По секрету, я не разбирался, где можно было, менял на свой собственный. Я вообще очень не люблю регулярные выражения для случаев больших чем всякие токены.
    The animals went in two by two, hurrah, hurrah...
    Re[20]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 13.04.12 13:55
    Оценка:
    Здравствуйте, Tanker, Вы писали:

    O>> Сформулированная задача — это уже формализованная задача. По определению. А если задачу даже сформулировать не осилили, то уж и закодировать решение в лоб никто не сможет.


    T>Я сколько ни работаю, все время все приходится формулировать и формализовывать самому


    Что, и задачи себе самому придумывать приходится? Сам пошутил, сам посмеялся?

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

    O>> И именно такой подход к быстрому прототипированию и работает быстрее и надежнее всех прочих. Вы не знали?

    T>Покажи пример.


    Ну вот, например: http://ahefner.livejournal.com/20528.html

    Или вот: http://homepage.mac.com/digego/study_in_keith.mov

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

    T>ЗП(гросс) всех разрабов вместе с тестерами это 10% от всей суммы.

    Да кого это колышет-то? Вы-то сначала про время чего-то там говорили.

    T>Вроде умные люди, а азы экономики понять не могут С т.з. бизнеса нужно или урезать затраты наибольшей части, 90% или же делать так, что бы общий расклад приносил денег больше. Второй вариант это норма для софтверной индустрии.


    Вот не надо мне про экономику заливать. Не интересно мне выслушивать про экономику от человека, не понимающего смысла "time to market".

    O>> Так никто и не объяснил, на кой нужен "один" DSL "для всех случаев". Да еще и в UI. Это в корне противоречит самой идее DSL.


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


    Как-то так. Для распознавания регулярной грамматики я буду использовать один DSL (регулярные выражения), для распознавания контекстно-свободной грамматики — совсем другой (например, PEG). Вся идея DSL в том, что надо решать конкретные частные задачи, а не искать ненужные в данный момент обобщения. Для обобщений есть языки "общего назначения". Те самые, которые не нужны вовсе.

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

    O>> Вы преувеличиваете. Большинство программистов достаточно умны. Раз уж они ООП осилили, то уж намного более простую методологию с DSL осилят без проблем.

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


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

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


    Я не спорю, что есть корреляция. Разница в том, что я устанавливаю планку намного ниже. Как по мне, если человек fizz-buzz смог закодить, то он уже адекватный программист. И компиляторы писать научится без проблем. Вы же утверждаете, что это только редкие высокооплачиваемые ковбои могут, что есть чушь и бред, и опровергается практикой.

    T>>>Приходи с такими цифрами к CEO какого нибудь софтверного гиганта. Если у тебя все получится, в ближайшие 10 лет увидим адский прорыв. Правильно ?

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

    T>Не далее чем пару сообщений назад ты назвал людей из конторы-гиганта идиотами.


    Это софтовая контора? Не верю. В софтовой конторе такого быть не может. Не представляю себе Microsoft или Google, где парсили бы CSV сплитом. А в не-софтовых, конечно же, любой дряни хватает.
    Re[19]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 13.04.12 14:00
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

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


    O> Опять глупости говорите. Несусветные глупости. Ну явно не имеете понятия о Колмогорове и его сложности.


    Колмгоровская сложность не имеет никакого отношения к тому что я говорю.

    O> Обобщенная теория всегда появляется тотчас же, как только набирается достаточный объем эмпирического знания. А поскольку нового эмпирического знания в обсуждаемой теме уже много лет нет, то можно уверенно говорить, что тема насытилась и ничего нового уже не будет. Мы знаем все.


    Это заблуждение.

    T>>Зато знания уложеные в гцц невозможно распространять.


    O> Можно. Элементарно. Один из разработчиков gcc несколько лет назад объяснил мне про ssa на пальцах. За пять минут. Хватило. А это, пожалуй, самое сложное что там есть. Остальное из чтения исходников понимается легко и непринужденно.


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

    T>>Связь есть но не там где ты хочешь видеть.


    O> Конкретика где? Такая-то страница дракона, применена в таких-то и таких-то исходных файлах gcc. Без этого все, что вы говорите — пустой треп.


    Как минимум регулярные грамматики используются и в гцц

    T>>У каждого практика в голове свой набор понятий и связей. Что бы эти понятия стали общими, нужны теоретики.


    O> Нужно живое общение между практиками. Общие понятия рождаются сами, без помощи высоколобых теоретиков.


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


    T>>На рынке труда, где и все.


    O> Назовите учебные заведения, откуда выходят ваши гении. И помните, мы говорим только о тех, кто только-только попал на рынок труда, у кого ни капли опыта нет.


    Все заведения по ИТ в странах бывшего СССР которые были созданы во времена этого СССР.

    O> Все, кого я видел из МГУ, МФТИ, СПбГУ и прочих "крутых" ВУЗов не умели ничего, если только не учились вне ВУЗа.


    Ни один вуз не отменяет самостоятельной работы. Ты хотел как то иначе ?
    The animals went in two by two, hurrah, hurrah...
    Re[17]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 13.04.12 14:03
    Оценка:
    Здравствуйте, fmiracle, Вы писали:

    F>Ты говоришь противоположные вещи.

    F>Если система должна разбирать формат CSV, то есть на вход может поступить любой CSV-файл, то string.split явно не достаточно, и пример подбирается легко. И спорить с этим бессмысленно.

    Так и думают теоретики. Практики понимают, что задача сводится к импорту данных кастомера и импортируют даже ничего не зная про CSV. Собтсвенно string.split это однозначно доказывает.

    F>Другое дело, что во множестве систем для передачи данных может использоваться другой формат, условно назовем его CSVlite, который описывается как "Текстовые поля, разделенные запятой. Значения полей не могут содержать запятой или перевода строки". На него отлично ложатся матрицы целых чисел, например. Этот формат часто путают с CSV, но это ошибка, это другой формат, подмножество CSV. И разбирать его действительно гораздо проще.


    См выше
    The animals went in two by two, hurrah, hurrah...
    Re[20]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 13.04.12 14:07
    Оценка: :)
    Здравствуйте, Tanker, Вы писали:

    O>> Опять глупости говорите. Несусветные глупости. Ну явно не имеете понятия о Колмогорове и его сложности.


    T>Колмгоровская сложность не имеет никакого отношения к тому что я говорю.


    Имеет. Непосредственное. Алгоритмическая теория информации, собственно, и описывает, как эмпирические знания превращаются в теорию. Вы и этого не понимаете? Жаль.

    O>> Обобщенная теория всегда появляется тотчас же, как только набирается достаточный объем эмпирического знания. А поскольку нового эмпирического знания в обсуждаемой теме уже много лет нет, то можно уверенно говорить, что тема насытилась и ничего нового уже не будет. Мы знаем все.


    T>Это заблуждение.


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

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


    Это дают студентам. Легко. И они понимают. Только вот драконовская школа к этом непричастна.

    O>> Конкретика где? Такая-то страница дракона, применена в таких-то и таких-то исходных файлах gcc. Без этого все, что вы говорите — пустой треп.


    T>Как минимум регулярные грамматики используются и в гцц


    Далеко не так явно. Там даже лексер рукописный. Никаких генераторов.

    O>> Нужно живое общение между практиками. Общие понятия рождаются сами, без помощи высоколобых теоретиков.


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


    В теоретика он не превратится. Его диссертация опубликована, все ею пользуются, кому надо — http://www.cri.ensmp.fr/classement/doc/A-381.pdf

    T>>>На рынке труда, где и все.


    O>> Назовите учебные заведения, откуда выходят ваши гении. И помните, мы говорим только о тех, кто только-только попал на рынок труда, у кого ни капли опыта нет.


    T>Все заведения по ИТ в странах бывшего СССР которые были созданы во времена этого СССР.


    Это какие же такие заведения "по ИТ" были созданы во времена СССР?!?

    O>> Все, кого я видел из МГУ, МФТИ, СПбГУ и прочих "крутых" ВУЗов не умели ничего, если только не учились вне ВУЗа.


    T>Ни один вуз не отменяет самостоятельной работы. Ты хотел как то иначе ?


    Я то как раз не хотел. Это вы тут втираете, что преподватели могут чему-то там научить. А я же утверждаю, что в программировании научить может только практика. Да и не только в программировании. Причем в программировании теория как правило только мешает, и как правило никакой связи с практикой не имеет.
    Re[23]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 13.04.12 14:16
    Оценка: :)
    Здравствуйте, oldjackal, Вы писали:

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


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


    А мне тож самое учитель геометрии доказывал — решение любой задачи делается в один шаг

    T>>Напиши книгу, я куплю, почитаю.


    O> Может мне еще и про "2+2=4" и про "Hello, World!" написать? Сопоставимые по сложности темы.


    Не хочешь, не пиши.

    O> Что, кроме драконьей книги ничего нет? Вранье. Полно отличного материала. Одно из лучших, что я видел:


    O>http://www.iro.umontreal.ca/~boucherd/mslug/meetings/20041020/90-min-scc/90-min-scc.pdf


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

    O>так же неплохо: http://llvm.org/docs/tutorial/


    В качетсве методички для лабораторных сгодится.

    O> А так же одна из глав SICP. Он вообще весь малость затянутый, там все мелочи разжевывают многократно, но относительно компиляции они палку не слишком сильно перегибают.


    Сам подумай — студенты, как ты плачешься, программировать неумеют, а ты им SICP хочешь вручить.
    The animals went in two by two, hurrah, hurrah...
    Re[27]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 13.04.12 14:21
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

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


    O> Вы опять с умным видом рассуждаете о теме, в которой ни бум-бум. Лучше про "фильтры" и контроллы рассуждайте, это явно ваш конек.

    O> Какая такая "диспетчеризация"?

    Самая обыкновенная.

    >Часто вообще никакой ОС нет, все на голом железе живет.


    А что, диспетчеры только в ОС бывают ?

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


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

    O> Не всех. Только дураков. А их очень мало. Это вы тут распинаетесь, что мол все программисты тупые и ничего сложнее string.split никогда не осилят, а у меня есть все основания вам не верить, мне дураки редко попадаются.


    Ты противоречишь своим же собственным словам Забыл что ли, как плакался про студентов и молодых специалистов ?

    T>>Конечно, только я довожу до тебя простую мысль, которая никакого отношения к его сложности не имеет.


    O> Мне абсолютно не интересны ваши нерелевантные простые мысли. Мы обсуждали сравнение сложности двух предметных областей.


    Судя по примеру транслятора схемы в си, ты соврешненно не понимаешь о чем речь.
    The animals went in two by two, hurrah, hurrah...
    Re[24]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 13.04.12 14:22
    Оценка:
    Здравствуйте, Tanker, Вы писали:

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


    T>А мне тож самое учитель геометрии доказывал — решение любой задачи делается в один шаг


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

    O>> Что, кроме драконьей книги ничего нет? Вранье. Полно отличного материала. Одно из лучших, что я видел:


    O>>http://www.iro.umontreal.ca/~boucherd/mslug/meetings/20041020/90-min-scc/90-min-scc.pdf


    T>Предполагается, что ЦА искаропки знает функциональщину ?


    Если и не знает, то разберется. Это ж не ООП какой, тут думать не надо.

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


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

    O>>так же неплохо: http://llvm.org/docs/tutorial/


    T>В качетсве методички для лабораторных сгодится.


    Ничего более сложного в жизни и не надо. Да и Kaleidoscope сложноват, сложнее чем 99% DSL.

    O>> А так же одна из глав SICP. Он вообще весь малость затянутый, там все мелочи разжевывают многократно, но относительно компиляции они палку не слишком сильно перегибают.


    T>Сам подумай — студенты, как ты плачешься, программировать неумеют, а ты им SICP хочешь вручить.


    SICP как раз и есть книга для тех, кто не умеет программировать и хочет научиться. Учебник для первокурсников.
    Re[13]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 13.04.12 14:24
    Оценка:
    Здравствуйте, fmiracle, Вы писали:

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


    А у меня было так — один и тот же преподаватель рассказывал про программирование и компиляторы и про ОС и много чего еще. Что странно, компиляторы в среднем давали худший выхлоп.
    The animals went in two by two, hurrah, hurrah...
    Re[18]: Языки общего назначения не имеют смысла!
    От: fmiracle  
    Дата: 13.04.12 14:25
    Оценка:
    Здравствуйте, Tanker, Вы писали:

    F>>Ты говоришь противоположные вещи.

    F>>Если система должна разбирать формат CSV, то есть на вход может поступить любой CSV-файл, то string.split явно не достаточно, и пример подбирается легко. И спорить с этим бессмысленно.
    T>Так и думают теоретики. Практики понимают, что задача сводится к импорту данных кастомера и импортируют даже ничего не зная про CSV. Собтсвенно string.split это однозначно доказывает.

    Ну да. Ничего не зная про некоторый формат Х, они делают импорт из другого формата, лишь частично совпадающего с указанным, и гордо называют это "импорт из Х".

    F>>Другое дело, что во множестве систем для передачи данных может использоваться другой формат, условно назовем его CSVlite, который описывается как "Текстовые поля, разделенные запятой. Значения полей не могут содержать запятой или перевода строки". На него отлично ложатся матрицы целых чисел, например. Этот формат часто путают с CSV, но это ошибка, это другой формат, подмножество CSV. И разбирать его действительно гораздо проще.


    T>См выше


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

    Мне, как бы, тоже не раз приходилось на практике импортировать из "файла с разделителями". Причем приходилось сталкиваться и со случаями, когда достаточно было string.split делать, и когда его было совершенно недостаточно. Вторые, кстати, чаще встречались. Когда в тексте идут всякие там адреса в произвольной форме или пользовательские комментарии — там в них может быть все что угодно, и запятые, и ; и табы, и все прочее.
    Re[21]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 13.04.12 14:34
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    T>>Колмгоровская сложность не имеет никакого отношения к тому что я говорю.


    O> Имеет. Непосредственное. Алгоритмическая теория информации, собственно, и описывает, как эмпирические знания превращаются в теорию. Вы и этого не понимаете? Жаль.


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

    O>>> Обобщенная теория всегда появляется тотчас же, как только набирается достаточный объем эмпирического знания. А поскольку нового эмпирического знания в обсуждаемой теме уже много лет нет, то можно уверенно говорить, что тема насытилась и ничего нового уже не будет. Мы знаем все.


    T>>Это заблуждение.


    O> Это факт. Железный. Опровергните, если можете — найдите чего-то, чего практики не знают, что появилось лишь недавно. И найдите хотя бы один след из того, что обобщено практиками (и далекими от драконьей доминирующей школы теоретиками) в "официальных" учебниках и курсах по компиляторам.


    На примере ньютоновской механии и релативистской — годится ? Напомнить разницу во времени ? На примере геометрии евклида и лобачевского ?

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


    O> Это дают студентам. Легко. И они понимают. Только вот драконовская школа к этом непричастна.


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

    T>>Как минимум регулярные грамматики используются и в гцц

    O> Далеко не так явно. Там даже лексер рукописный. Никаких генераторов.

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

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


    O> В теоретика он не превратится. Его диссертация опубликована, все ею пользуются, кому надо — http://www.cri.ensmp.fr/classement/doc/A-381.pdf


    Значит уже превратился. Уже появилась диссертация которая будет покруче книги дракона, а ты сообщал вроде про "пять минут" или хочешь пересмотреть показания ?

    T>>Все заведения по ИТ в странах бывшего СССР которые были созданы во времена этого СССР.


    O> Это какие же такие заведения "по ИТ" были созданы во времена СССР?!?


    Все заведения которые сейчас готовят специалистов по ИТ но при этом были созданы во времена СССР.

    O>>> Все, кого я видел из МГУ, МФТИ, СПбГУ и прочих "крутых" ВУЗов не умели ничего, если только не учились вне ВУЗа.


    T>>Ни один вуз не отменяет самостоятельной работы. Ты хотел как то иначе ?


    O> Я то как раз не хотел. Это вы тут втираете, что преподватели могут чему-то там научить.


    Буквально "учат" только учителя в начальной школе.

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


    Есть люди двух типов. Одни умеют пользоваться теорией, другие — нет.
    The animals went in two by two, hurrah, hurrah...
    Re[18]: Просто мысль...
    От: WolfHound  
    Дата: 13.04.12 14:34
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    O> Это слишком крупные уровни. Неинтересно. Иерархии языков не получится.

    Получается.

    WH>>И все они живут в разных ДЛЛ.

    WH>>Добавить новые уровни не проблема.
    O> И по dll на уровень? У меня сотни уровней бывают.
    Сотни? Откуда?
    Или ты то, что я делаю функцией делаешь макрой?
    Так тоже можно, но я о том и говорю что это другой подход.

    O>>>Ничем за это платить не надо,

    WH>>Тормозами.
    O> Откуда тормоза?!?
    Из постоянной динамической компиляции или интерпретации.

    O>Все таки вы до сих пор не понимаете.

    Я прекрасно понимаю то, как работает лисп.
    Просто я работаю иначе.

    O> Да нет же, не умеет! Я не смогу раскрыть макру в код, определяющий другую макру, которая в следующей же строке и будет использована. Тем более я не смогу раскрыть макру в код, определяющий другую макру и код, эту другую макру использующий. А все это совершенно необходимо для реализации DSL в виде последовательности малых преобразований.

    Макры генерирующие обращения к другим макрам это понятно. И в моей схеме это возможно.
    Но макры генерирующие новые макры?
    Не понимаю, зачем оно надо.

    WH>>Так эти уравнения будут выведены и assert'ов.

    WH>>В этом вся идея.
    O> Это уже очень существенное ограничение.
    Почему?

    O> Это простейший случай. В жизни все сложнее.

    Посмотрим что получится.

    O> Например, чтобы при раскрытии макры знать, какие методы есть у объектов этого типа.

    Это и по-другому сделать можно.

    O> Ну как зачем? Если мы преобразуем DSL в язык более низкого уровня, то его система типов должна так же преобразовываться в систему типов целевого языка.

    Преобразование может быть очень не прямым.

    O>>> В том и фокус, что несовпадение типов далеко не всегда является ошибкой.

    WH>>А для меня всегда.
    O> То есть, Y-комбинатора не существует?
    То есть существуют системы типов, в которых можно его типизировать.

    O> Свою работу можно так и строить (хоть это и уныло).

    Вот тут у нас принципиальное противоречие.
    Я иначе работать не могу.

    O>Но вот пытаться семантику всех-всех возможных DSL засунуть в это прокрустово ложе это уже опасно.

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

    O> А если мы их добавим, то это уже совсем другой уровень, не тот, на котором goto нужны..

    Вот я и говорю что они только на самых низких уровнях и нужны.

    O> С чего вдруг? Мне проще всего скомпилировать FSM в кучу меток и goto. Если я из него буду switch делать, то это уже усложнение.

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

    O>Семантика goto идеально подходит к семантике перехода между состояниями в FSM. При этом уровень языка в обработчиках состояний может быть сколь угодно высоким.

    Точно также FSM ложится и на взаимно-рекурсивные функции.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[14]: Языки общего назначения не имеют смысла!
    От: fmiracle  
    Дата: 13.04.12 14:39
    Оценка:
    Здравствуйте, Tanker, Вы писали:

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

    T>А у меня было так — один и тот же преподаватель рассказывал про программирование и компиляторы и про ОС и много чего еще. Что странно, компиляторы в среднем давали худший выхлоп.

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

    Вообще, у нас тоже компиляторы и грамматики преподавали как-то так себе. У меня после этого так полный сумбур и непонятность и осталась в голове Но непонятная подача материалами еще не значит, что его в принципе невозможно подавать проще.
    Re[20]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 13.04.12 14:42
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

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

    S>Покажите код, который будет пользоваться этими операциями.
    S>Скажем, аналог
    S>
    S>select Manager.Name, OrderTotals.Amount 
    S>from Manager 
    S>inner join City on City.ID = Manager.CityID
    S>inner join 
    S>  (select ManagerID, sum(Orders.Amount) from Orders where Orders.OrderDate between '20100101' and '20101231' group by ManagerID) 
    S>    OrderTotals on OrderTotals.ManagerID = Manager.ID
    S>where City.Name like 'Н%'
    S>order by 2 desc
    S>


    До получения кода надо получить набор операций в терминах РА. Я не так давно тебе уже показывал как это делается и как это выглядит. (если настаиваешь, поищу ссылку).
    После этого подставляешь имеющиеся алгоритмы, реализующие примитивы РА над нужными структурами, в которых хранятся данные сущностей Manager, City и прочих. Сами алгоритмы могут быть как энергичными, так и ленивыми на итераторах...

    Если же ты о перезаписи операций и прочей оптимизации — то это совсем отдельные операции, которые тоже, впрочем, достаточно формализованы.


    V>>Матан — это не теоремы, это исследование ф-ий и их систем.

    S>Он про другой матан.

    Это он тебе сам сказал?
    Таким макаром можно далеко пойти, называя матаном любую формальную модель... даже если это модель табурета.
    Re[19]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 13.04.12 14:44
    Оценка:
    Здравствуйте, fmiracle, Вы писали:

    T>>Так и думают теоретики. Практики понимают, что задача сводится к импорту данных кастомера и импортируют даже ничего не зная про CSV. Собтсвенно string.split это однозначно доказывает.


    F>Ну да. Ничего не зная про некоторый формат Х, они делают импорт из другого формата, лишь частично совпадающего с указанным, и гордо называют это "импорт из Х".


    Главное что задача решена и бизнес доволен.

    T>>См выше


    F>Во-во. Почитай внимательно, что я тебе написал. Я уж как мог разжевал. Да, на практике задача решена, и это прекрасно. Но чтобы не путать окружающих не надо говорить, что эта задача — импорт из CSV. Это импорт из совсем другого формата.


    Я все это понимаю. Если ты плохо читаешь, я на вский напишу еще раз, что этот же вопрос я сам же и пытался решать, т.е. вместо string.split ввести CSV-парсер.
    The animals went in two by two, hurrah, hurrah...
    Re[25]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 13.04.12 14:47
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    T>>А мне тож самое учитель геометрии доказывал — решение любой задачи делается в один шаг


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


    Конечно врал, точно так же как и ты. Говорил про две строчки текста и "пять минут", а на поверку выдал три источника ЦА которых как минимум должна знать функциональщину и понимать диссеры написаные языком почище чем в книге дракона.

    T>>Предполагается, что ЦА искаропки знает функциональщину ?


    O> Если и не знает, то разберется. Это ж не ООП какой, тут думать не надо.


    Это в ООП думать не надо

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


    O> Так и хорошо, что не умеют программировать. Мозги не испорченные. Осилят самостоятельно за кратчайшее время. Я еще не встречал таких, кто даже тупейшую Схему не осиливает. Это ж не шарп какой.


    тогда природа твоего вайна не ясна.

    T>>Сам подумай — студенты, как ты плачешься, программировать неумеют, а ты им SICP хочешь вручить.


    O> SICP как раз и есть книга для тех, кто не умеет программировать и хочет научиться. Учебник для первокурсников.


    От него отказались в МИТ как от устаревшего материала.
    The animals went in two by two, hurrah, hurrah...
    Re[15]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 13.04.12 14:48
    Оценка:
    Здравствуйте, fmiracle, Вы писали:

    F>Ну он же не биоробот, идеально заточенный под преподавание всего? Может быть, компиляторостроение ему была не интересная тема просто


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

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


    А я разве где то утверждаю, что в принципе невозможно проще ?
    The animals went in two by two, hurrah, hurrah...
    Re[21]: Языки общего назначения не имеют смысла!
    От: Курилка Россия http://kirya.narod.ru/
    Дата: 13.04.12 15:09
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

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


    T>> Цепочка импорта чуток удлинняется, в качестве разделителя задаются tab. Формально это не csv, но главное это импорт, а на форматы забили. Бизнес не будет проверять CSV или нет, он будет проверять проходил ли сам импорт. Обычно дает набор файлов.

    S>Ну, то есть парсер СSV на string.split нагнулся, теперь вы перешли на tab-delimited values.
    S>Я рад, что мы хотя бы прояснили вопросы о фатальных недостатках парсеров, построенных на string.split. Второй вариант, который вам известен, я так понял — регексы, да?
    S>Так вот: они — тоже не работают. Работают парсеры, честно построенные на стейт-машине. У них всё в порядке с быстродействием и надёжностью. Плохо у них только с объёмом ручного кода. DSL для построения парсеров позволил бы значительно сократить время разработки и избежать приседаний с внезапным переходом с CSV на TDV после запуска системы в эксплуатацию в РФ, где десятичной точкой неожиданно является запятая.

    К слову — запятая является разделителем целой и десятичной части в очень большом числе стран (к примеру, в Европе практически все кроме Британии с Ирландией её используют)
    Re[10]: Языки общего назначения не имеют смысла!
    От: PSV100  
    Дата: 13.04.12 15:13
    Оценка:
    Здравствуйте, alex_public, Вы писали:

    _>Краем уха слышал, что там ещё некий Lazarus набирает силу. )


    Ну вроде да, народ Lazarus-ом пользуется (на Delphi он похож, но не полностью совместим). И вообще, FreePascal хорошая штука. Он конечно по оптимизациям и всякой эффективности уступает C++, но если ничего сверхсерьёзного не нужно, скажем, какая-то утилита, особенно кроссплатформенная, то на нём на порядок проще и быстрее реализовать, чем на С++. Кстати, у него удобные и реально кроссплатформенные модули для работы с консолью, чем мучения в С++, с его всяким ncurses, особенно с портами на другие платформы.

    А лично я от программирования в GUI-дизайнере как-то уже отошёл в сторону. Всё-таки неудобно, когда ты не видишь в виде удобного (!) кода то, чего создаешь, что изменяешь (дельфовские DFM-файлы — они не для этого), есть неудобное разделение — что-то нужно делать в дизайнере (в которых ковыряться мало удовольствия), а что-то нужно в коде ваять. К тому же дизайнерство ограничивает тебя в функционале, потенциале, несмотря на то, что например, в Delphi вполне мощная техника наследования форм. Кроме того, направленность на GUI-дизайнер влияет на архитектуру визуальной библиотеки, в результате, хоть в своём программном коде можно делать абсолютно всё (дизайнерство никак не ограничивает в коде), но работать с GUI в коде неудобно, громоздко (если с нуля что-то создавать).
    Delphi повлиял на Net, там тоже любят дизайнеров. А вот в жабе как-то дизайнеры особо не востребованы. Там научились программировать, хотя джава как язык не фонтан для этого. Для расположения контролов используют выравниватели — layout manager.
    Вот очень популярное решение MigLayout (в инете куча статей про него). Сейчас его пытаются портировать на всякие разные платформы.
    Кстати, в нашем скриптовом язычке тоже по таким мотивам программируется GUI.

    PSV>>Или вот попался пример на WPF (я в нём не разбираюсь). Здесь TextBox будет виден только тогда, когда включён CheckBox (насколько приятно в таком XML ковыряться, я не в курсе, лично мне не очень):

    PSV>>
    PSV>><Window x:Class="ParaPlan.Windows.Window1"
    PSV>>    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    PSV>>    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    PSV>>    Title="Window1" Height="300" Width="300"
    PSV>>    xmlns:converters="clr-namespace:ParaPlan.Converters">
    PSV>>    <StackPanel Orientation="Vertical">
    PSV>>        <StackPanel.Resources>
    PSV>>            <converters:BooleanToHiddenVisibility x:Key="boolToVis"/>
    PSV>>        </StackPanel.Resources>
    PSV>>        <CheckBox Content="Check to show text box below me" Name="checkViewTextBox"/>
    PSV>>        <TextBox Text="only seen when above checkbox is checked"
    PSV>>                 Visibility="{Binding Path=IsChecked, ElementName=checkViewTextBox, Converter={StaticResource boolToVis}}"/>
    PSV>>    </StackPanel>
    PSV>></Window>
    PSV>>


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


    Не знаю на счёт Net-а, но для Delphi и Java я насмотрелся на кучу всяких декларативных велосипедных описаний для GUI, включая и на основе XML (таких, имхо, и больше всего). XML якобы промстандарт, есть универсальные инструменты, в том числе и IDE с ним работают (включая и спецсредства под конкретный язык, как этот XAML), также есть способствие к кодогенерации. В WPF с Сервелатом вроде можно и в коде работать, не только с XML, но я смотрю, что многие внутри XML и работают, ибо в C# ещё больше неудобств (хотя я не в курсе, вполне возможно, что часть функционала только в XML и возможна).

    Вот я давал пример с JavaFX. Сейчас, в принципе, сделали по уму: теперь это часть самой джавы, т.е. обычные жабьи классы со своим API, и есть из коробки вариант работы и через XML, можешь ваять отдельно разметку, стили и т.д. А хочешь, бери любой язык под JVM — кложуру, груви, питон и т.д. и вперёд. Хочешь делай свой DSL, какой тебе нужно. Можно взять тот скриптовый язык, на котором я приводил пример. Кстати, он как DSL вполне хорош, но лично мне не всё нравится в синтаксисе. Говорят, что он похож на флэш или Flex какой-то (я в них не шарю).

    _>Да, я посмотрел — это как раз ближе к тому, что мне интересно для нативных предложений, но что я не стал бы применять в вебе (это я про первый пример оттуда). В современной веб разработке обычно стараются уйти от каких либо намёков на код внутри html. А тут некие привязки и т.п. В то же время для приложения с нативным интерфесом это возможно было бы удобно, причём возможно даже можно было совместить в единое целое view и view-model.


    _>А разница на мой взгляд в том, что под дизайном в случае сайта и в случае приложения с нативным интерфейсом частенько подразумеваюся достаточно различающиеся вещи.


    Ну, прежде всего, нужно ориентироваться на конкретные задачи, конкретные потребности. А в таком, глобальном, масштабе я с тобой не соглашусь. Вот тот же HTMLLayout специально создавался с целью позволить разделить дизайнерчество от программирования, ну кроме того, чтобы дать возможность делать любой интерфейс и как-то упростить программирование. По своему опыту могу сказать, что лучше всегда стремиться к простому, гибкому, и если есть обоснованная (!) возможность что-то разделить, отвязать — лучше так и сделать. Я и в программном коде привык писать попроще, лучше накидать с десяток простых строк, чем замутить одну, в которой потом через несколько лет сам же не разберёшься. Сейчас я могу что-то не увидеть, не догнать, но потом может так вжарить петух, что будешь браться за голову и гадать, как имеющееся месиво кода переделать.
    Кстати, HTML и в десктоп-GUI весьма популярен. Вот ещё один известный "равнятель" для Java: TableLayout, разметка в HTML-стиле. А вот здесь товарищ попытался его совместить с выше приведенным MigLayout (мне не понравилось то, что есть переплетение разметки со стилями, т.е. с визуальным оформлением).

    А я, сам для себя, пришёл к такому выводу. Обязательно нужно:

  • декларативное описание GUI. В рамках вэба стандарт является HTML, он же повлиял и на десктоп. Его недостаток в том, что он труден для восприятия и для прямой работы с ним. Также он затрудняет задачи локализации (разные варианты языков), если убрать из него содержательный текст, останутся только одни тэги, причём в этом случае они неудобны, ведь HTML — это язык для разметки элементов внутри текстового документа (для чего он и предназначался), а теперь текста и нет, сплошные неудобные угловые скобки. Но он стандарт, поэтому востребован.

    Второй вариант, это DSL по мотивам JavaFX-скрипта, пример которого я приводил раньше. Он оперирует не текстом, а GUI-элементами: сценами и объектами внутри них. В принципе, тут даже и спецы-дизайнеры также смогут работать, ибо, как я понимаю, это уже тоже некий типовой промстандарт. Конкретно JavaFX-скрипт позволяет ещё и включать сразу в себя и программный код, внутри описаний, но этот вопрос решаем (в этом и плюс тоже, тут и дизайнерам может даже что-то пригодиться, но как-то это нужно ограничить, но не ликвидировать полностью).

    Имхо, сейчас эти два формата промышленно рулят. К ним (лучше всё-таки отдельно) нужно декларативное указание биндинга, реактивности, но уже удобное в рамках языка программирования (или внешний DSL, если язык программирования такой ...).
    Да, и нужны декларации для визуального оформления по мотивам CSS, отдельные от разметки. Это есть и в HTML, и в JavaFX (тут тоже не помешали бы какие-то небольшие вычисления, удобные для дизайнеров).

    А этот микрософтский XAML — в какой-то степени JavaFX-скрипт, но в XML-формате. Спецы по нему вроде только в рамках около WPF. Имхо, для ручной работы неприятен, несмотря на чудеса от IDE. Такой XML, как и в JavaFX, имхо, лучше применять в рамках кодогенерации, в т.ч. и при работе GUI-дизайнеров, для чего, в первую очередь, их и придумывают. Я же пытаюсь нащупать способ для простой жизни, без дизайнеров.

  • Нужно и удобное прямое алгоритмическое программирование GUI. Какое бы не было крутое декларативное описание, но всех потребностей оно никогда не покроет. Здесь какой-нибудь miglayout очень кстати (соответственно и декларативный DSL должен иметь как бы прямую связь с API языка программирования, т.е. в DSL задаются те же элементы, что и в этом miglayout).
    Неплохой помощник тот язык, который может удобно (!) оперировать и некоторыми элементами из DSL, по мотивам JavaScript при работе с XML/HTML-тэгами (а также, например, Scala, и в Nemerle что-то есть для работы с XML).
    И в идеале, неплохо, если язык/платформа позволяют делать нужные мета-вычесления при компиляции, если в этом есть необходимость. И очень хорошо, если есть возможность для true-реактивности — сразу видеть свои результаты не отходя от кассы.

    Это сугубо моё личное имхо.
  • Re[21]: Языки общего назначения не имеют смысла!
    От: Mamut Швеция http://dmitriid.com
    Дата: 13.04.12 15:14
    Оценка:
    S>DSL для построения парсеров позволил бы значительно сократить время разработки и избежать приседаний с внезапным переходом с CSV на TDV после запуска системы в эксплуатацию в РФ, где десятичной точкой неожиданно является запятая.

    А если есть биболиотеки тот же CSV уже читающий, то и DSL'ей не надо

    На прошлой работе надо было импортировать Excel (не CSV, а .xls). Питон + xlrd дают что-то такое:
    book = xlrd.open(path)
    
    for sheet in book:
        for row in sheet:
            for column in row:
              ...


    Чем не DSL?


    dmitriid.comGitHubLinkedIn
    Re[21]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 13.04.12 15:18
    Оценка: +1
    Здравствуйте, vdimas, Вы писали:

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

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

    V>Если же ты о перезаписи операций и прочей оптимизации — то это совсем отдельные операции, которые тоже, впрочем, достаточно формализованы.

    Хотелось бы, чтобы перезапись операций и прочая оптимизация были не хуже, чем в SQL.

    V>Это он тебе сам сказал?

    Я умею читать.
    V>Таким макаром можно далеко пойти, называя матаном любую формальную модель... даже если это модель табурета.
    Прочитайте по ссылке. В интернетах матаном называют любую формальную модель. Вы же не думали, что ваш оппонент реально имеет в виду исчисление бесконечно малых как основу реляционной модели, нет?
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[22]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 13.04.12 15:56
    Оценка:
    Здравствуйте, Mamut, Вы писали:

    M>А если есть биболиотеки тот же CSV уже читающий, то и DSL'ей не надо

    M>На прошлой работе надо было импортировать Excel (не CSV, а .xls). Питон + xlrd дают что-то такое:
    M>Чем не DSL?
    Всё зависит от того, что нужно делать дальше. Возможно, захочется обращаться к колонкам типизированно; возможно, захочется обращаться по именам, а не номерам; возможно, захочется понимать написанные там формулы Excel.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[23]: Языки общего назначения не имеют смысла!
    От: Mamut Швеция http://dmitriid.com
    Дата: 13.04.12 16:34
    Оценка:
    M>>А если есть биболиотеки тот же CSV уже читающий, то и DSL'ей не надо
    M>>На прошлой работе надо было импортировать Excel (не CSV, а .xls). Питон + xlrd дают что-то такое:
    M>>Чем не DSL?
    S>Всё зависит от того, что нужно делать дальше. Возможно, захочется обращаться к колонкам типизированно; возможно, захочется обращаться по именам, а не номерам; возможно, захочется понимать написанные там формулы Excel.

    Ну, для этого (почти) все можно уложить в библиотеку (и есть в xlrd)


    dmitriid.comGitHubLinkedIn
    Re[21]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 13.04.12 17:10
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    O>>> Сформулированная задача — это уже формализованная задача. По определению. А если задачу даже сформулировать не осилили, то уж и закодировать решение в лоб никто не сможет.


    T>>Я сколько ни работаю, все время все приходится формулировать и формализовывать самому


    O> Что, и задачи себе самому придумывать приходится? Сам пошутил, сам посмеялся?


    "иди туда не знаю куда и принеси то не знаю что" @

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

    O>>> И именно такой подход к быстрому прототипированию и работает быстрее и надежнее всех прочих. Вы не знали?

    T>>Покажи пример.


    O> Ну вот, например: http://ahefner.livejournal.com/20528.html

    O> Или вот: http://homepage.mac.com/digego/study_in_keith.mov

    Где там "десяток другой дсл для частных задач и организовывать взаимодействие этих дсл" ?

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

    T>>ЗП(гросс) всех разрабов вместе с тестерами это 10% от всей суммы.

    O> Да кого это колышет-то? Вы-то сначала про время чего-то там говорили.


    Это волнует мендеджмент который в бизнесе

    T>>Вроде умные люди, а азы экономики понять не могут С т.з. бизнеса нужно или урезать затраты наибольшей части, 90% или же делать так, что бы общий расклад приносил денег больше. Второй вариант это норма для софтверной индустрии.


    O> Вот не надо мне про экономику заливать. Не интересно мне выслушивать про экономику от человека, не понимающего смысла "time to market".


    Вот благодаря этому time to market и появляются решение string.split вместо CSV-парсера. Пока один пилит dsl и покрывает тестами, другой без тестов и вливает string.split в продакшн и получает профит.
    В долгосрочной перспективе нужен дсл. В краткосрочной, например что бы тупо вырвать тендер, в ход идут любые средства, что бы продемонстрировать первый результат. Кто показал первый результат, тот и получает основные деньги.

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


    O> Как-то так. Для распознавания регулярной грамматики я буду использовать один DSL (регулярные выражения), для распознавания контекстно-свободной грамматики — совсем другой (например, PEG). Вся идея DSL в том, что надо решать конкретные частные задачи, а не искать ненужные в данный момент обобщения.


    Правильно. Почему ты решил что UI это разные случаи не совсем ясно.

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


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


    "в геометрии достаточно трёх аксиом"

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

    O> Я не спорю, что есть корреляция. Разница в том, что я устанавливаю планку намного ниже. Как по мне, если человек fizz-buzz смог закодить, то он уже адекватный программист. И компиляторы писать научится без проблем. Вы же утверждаете, что это только редкие высокооплачиваемые ковбои могут, что есть чушь и бред, и опровергается практикой.

    То есть, готов брать людей на работу по одному только тесту fizz-buzz ?

    T>>Не далее чем пару сообщений назад ты назвал людей из конторы-гиганта идиотами.

    O> Это софтовая контора? Не верю. В софтовой конторе такого быть не может. Не представляю себе Microsoft или Google, где парсили бы CSV сплитом. А в не-софтовых, конечно же, любой дряни хватает.

    Софтовее некуда. А в Микрософте и не такое случается Я чет смотрю, чем больше гигант, более гигантские глупости случаются и это как то слабо коррелирует с доходностью бизнеса.
    The animals went in two by two, hurrah, hurrah...
    Re[23]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 13.04.12 17:13
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    M>>Чем не DSL?

    S>Всё зависит от того, что нужно делать дальше. Возможно, захочется обращаться к колонкам типизированно; возможно, захочется обращаться по именам, а не номерам; возможно, захочется понимать написанные там формулы Excel.

    Тут самое интересное начинается. Есть ДСЛ для организации всяких импортов ?
    The animals went in two by two, hurrah, hurrah...
    Re[22]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 13.04.12 17:31
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

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

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

    Ну, во-первых запрос мне кажется некорректным, т.к. не выведет менеджеров, у которых не было продаж вообще.

    Во-вторых, есть минимум 2 популярных библиотечных подхода:
    1. это непосредственная реализация некоей функциональности (например, это иерархия объектов и весь функционал контролов WPF).
    2. "движок" поверх этой функциональности, который на входе берет некое декларативное описание и по нему комбинирует имеющийся фнкционал (это интерпретаторы XAML форм, стилей, шаблонов отображения, шаблонов данных и т.д.)

    Для первого уровня как-то так:
    АПИ библиотеки (const и & везде опускаю для краткости):

    template<typename Enitity, typename Predicate, typename Transform>
    Iterator<typename Transform::ResultType> select(Iterator<Entity> i, Predicate p);
    
    template<typename Enitity, typename Transform>
    Iterator<typename Transform::ResultType> transform(Iterator<Entity> i, Tranform t);
    
    template<typename Enitity, typename GroupBy>
    Iterator< pair<typename GroupBy::KeyType, Iterator<Entity> > > group(Iterator<Entity> i, GroupBy groupBy);
    
    template<typename Value>
    struct BetweenPredicate { 
      Value v1, v2; 
      bool operator()(const Value & v) { return  v>=v1 && v<=v2; } 
    };
    
    template<typename Entity, typename Value>
    struct MemberBetweenPredicate { 
      Value Entity::* member;
      BetweenPredicate<Value> between;
      bool operator(Entity e) { return between(e.*member); } 
    };


    Прикладной вызов либы как-то так:
    struct OrderTotal { ManagerID managerId; double amount; }
    
    auto annual = select(from(orders), between(cdate("20100101", &Order::orderDate, cdate("20101231")))
    auto byManager = group(annualOrders, groupBy(&Order::managerId));
    auto orderTotals = transform(byManager, transformWrap<OrderTotal>((_1.managerId=_2.first, _1.amount=sum(_2.second, &Order::amount)) ));


    Дальше лень расписывать, пока было расписано подвыражение:
    select ManagerID, sum(Orders.Amount) from Orders where Orders.OrderDate between '20100101' and '20101231' group by ManagerID;

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

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


    V>>Если же ты о перезаписи операций и прочей оптимизации — то это совсем отдельные операции, которые тоже, впрочем, достаточно формализованы.

    S>Хотелось бы, чтобы перезапись операций и прочая оптимизация были не хуже, чем в SQL.

    Это нужен подход №2, когда выражение дается в виде декларации и доступно затем для аналитических вычислений. Тогда точно так же как показано выше в синтаксисе, но пусть select, from, transform и т.д. являюся не вызовами на обработку коллекций, а конструкторами узлов графа операций (аналог AST). Добавится лишь еще одна команда, нечто типа:
    auto resultingCollection = execute(result);


    Аналогичное я делал для описания грамматики прямо в С++ и затем генерации/минимизации по описанию лексера и LR(1)-парсера. Оба табличные, ес-но.


    V>>Таким макаром можно далеко пойти, называя матаном любую формальную модель... даже если это модель табурета.

    S>Прочитайте по ссылке. В интернетах матаном называют любую формальную модель.

    Даже на этом сайте "профессионалов"? Не замечал.

    В любом случае, прикладные модели, которыми будет оперировать прикладной специалист (не программист) тоже могут быть формальными. Опять получается бессмыслица в аппелировании к такому толкованию "матана".
    Re[7]: Языки общего назначения не имеют смысла!
    От: Pavel Dvorkin Россия  
    Дата: 13.04.12 17:37
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    G>>Не уходи от ответа.

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

    А можешь ответить на такой вопрос. На каком языке надо писать бинаризацию изображения? Дано greyscaled (8bpp) изображение, сделать черно-белое.

    Условия :

    Картинка размером от 3000*5000 до 5000*6000 пикселей, размер файла 15-30 Мб.
    Время на обработку — 200-300 мсек на современном процессоре. Не уложишься — считай, что задача не решена.

    Я ее писал на С. Наверное, неправильно делал. Расскажи, на чем надо было бы писать.
    With best regards
    Pavel Dvorkin
    Re[24]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 13.04.12 18:16
    Оценка: +1
    Здравствуйте, Sinclair, Вы писали:


    V>>Но вообще, если программа, порождаемая языком, работает сверху ОС, то языку необходимо только умение подключать библиотеки и больше ничего, чтобы превратиться в язык общего назначения.

    S>Мне не нравится этот критерий. Потому что он слишком сильно противоречит бытовому понятию DSL.

    А я не про DSL, а про то, что при наличии такой возможности многие DSL вполне могут служить языками общего назначения. Даже случайно.

    S>Скажем, Clipper, который, в отличие от VBA, явно заточен на конкретный домен, получается GPPL, т.к. в нём можно подключать библиотеки.


    Дык, я и видел на Клиппере "просто программы" в своё время.
    Потому что в нем была библиотека GUI для DOS и у него был компилятор.


    V>>Поэтому строгий DSL никак не сделаешь на основе языков, которые умеют это изкаробки.

    S>Вот это опять непонятно. Что именно называется "это"? Наличие встроенных в языке средств импорта библиотек?

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


    S>Да ну! Вот, скажем, в языке C нет никаких возможностей импорта библиотек. Там всё, что есть — это текст одной программы.

    S>Библиотеки в него потом запихивает линкер, который отдельный от языка.

    С тобой не согласен синтаксис объявления функций без определения в С и ключевое слово extern для переменных. В общем, никогда в плюсах линкер не был отдельно, это часть языка. Хотя бы потому, что без знания ABI конкретного компилятора линковка невозможна. Поэтому нужен не просто линкер, а конкретный линкер для конкретного компилятора.


    S>Давайте теперь я напишу версию лого, в синтаксис (и семантику) которого я добавлю IMPORT MODULE XXX. Он что, от этого внезапно станет GPPL?


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


    V>>Но на JS или LUA прекрасно сделаешь.

    S>Объясните мне ещё раз, чем С в этом смысле хуже JS.

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

    Т.е. я считаю, что по одному только синтаксису нельзя отличить DSL от не-DSL. Например, в C такая запись означает операцию копирования по-значению:
    SomeType someVar = getValue();

    А для какого-нить скриптового, со встроенным типом SomeType — вовсе не факт. Потому что помимо синтаксиса важна еще семантика происходящего. И эта семантика таки входит в спецификацию языка.
    Re[20]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 13.04.12 20:42
    Оценка:
    Здравствуйте, netch80, Вы писали:

    O>> Неверно. DSL нужны там, где решение с DSL будет проще, понятее не поддерживаемее. Никаких таких "общих случаев" не надо, это совершенно нерелевантная тема.


    N>Вы не противоречите друг другу. Но Tanker говорит о том, что разработка DSL полезна не для однократного случая, а для систематического решения задач какого-то специализированного типа.


    Вот, такие простые слова но мне в голову не пришли ДСЛ это долгосрочная перспектива и многократное решение схожих задач.

    N>Наоборот, это разработка и реализация языков — сложная тема на всех уровнях.

    N>А UI в своей базе примитивен до ужаса. Сложность там в основном в оптимизации юзкейсов.

    +2
    The animals went in two by two, hurrah, hurrah...
    Re[6]: Языки общего назначения не имеют смысла?
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 13.04.12 21:29
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    VD>>Ничем. Но ДСЛ для фильров не должен позволять написать ДСЛ для фильтров, а только фильтры.

    S>Ну, а язык для компиляторов не обязан позволять написать фильтр.

    Не. Не так... "язык для компиляторов обязан НЕ позволять написать фильтр"

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

    S> Или, по крайней мере, написать его удобно (понятно, что любой тьюринг-полный язык сразу даст написать и фильтр, и компилятор с DSL).


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

    VD>>Это бессмысленная философия. Должно быть различие между двумя совершенно разными вещами.

    S>Развернём утверждение: если чёткого различия нет, то две вещи не являются совершенно разными. Не так ли?

    Если, то нет. Но четкая разница есть.

    Почитал книгу Фаулера Предметно-ориентированные языки программирования.

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

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

    Многие могут не согласиться со мной и, используя буквальное определение DSL, будут утверждать, что такие языки, как R, должны рассматриваться как предметноориентированные. Поэтому я сделал сильный акцент на ограниченности выразительных возможностей как на важном отличии между DSL и языками общего назначения. Ограниченность выразительных возможностей придает DSL иные характеристики как в плане их использования, так и в плане реализации. Это приводит к отличию представлений о DSL по сравнению с языками общего назначения.

    Давайте рассмотрим XSLT. Предфметной областью XSLT является преобразование XML-документов, но у него имеются все возможности, которых можно было бы ожидать от обычного языка программирования. Я думаю, что в этом случае способ применения языка важнее, чем сам язык. Если XSLT используется для преобразования XML, то это DSL. Однако если он используется для решения задачи о восьми ферзях, то это язык общего назначения. Конкретное применение языка может разместить его по обе стороны границы.


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

    S>Мне кажется, ты сравниваешь полноту по тьюрингу с проблемно-ориенированностью.


    Я не сравниваю. Я считаю, что полнота по Тьюрингу — это признак ЯОН, но при некоторых оговорках. Скажем хотя SQL с CTE теоретически и стал полон по Тьюрингу, но написать на нем парсер будет крайне сложно. А вот на ВБА или 1Эс вполне.

    S>На мой взгляд, они не являются взаимоисключающими.


    Взаимоисключаемы ДСЛ-и и ЯОН-ы. Понятно, что полнота по тьюрингу не четкий критерий, но наличие процедур, циклов, условных операторов и прочего барахла, как бы говорит нам, что это 100% ЯОН. И не фига тут философствовать.

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

    ЯОН со встроенным ДСЛ-ем не превращается в ДСЛ. ЯОН прикрученный к Ворду или броузеру не становится ДСЛ.

    И все это потому, что ДСЛ — это не о том, что язык для чего-то заточен, а о том, что язык предназначен только для чего-то.

    Еще одним показателем ЯОН-а является то можно ли на нем (без использования других языков) написать целую систему. Если можно — это почти наверняка не ДСЛ. Вот на 1Эс можно. А на SQL — нет.

    Если для написания системы использует ДСЛ, то система уже обязана быть написана более чем на одном языке. Если это не так, то вас обманули.

    VD>>Уж слишком разные требования и свойства у этих вещей.

    S>Не вижу особенных различий в требованиях.

    Это то и печально.

    S> Вот, скажем, два языка — Паскаль и C++. Оба — GPPL ("можно написать все, что угодно"). Но в Паскале есть встроенная механика по работе с файлами фиксированной структуры (FILE OF TYPE), а С++ — механика перегрузки операторов. Почему? Надо полагать, у них отличаются домены.


    Это не имеет отношение к делу. Ты как и многие не верно (прямолинейно) толкуешь термин ДСЛ. Кстати, у Фаулера об этом хорошо сказано:

    В этом определении есть четыре ключевых элемента.
    * Язык программирования...
    * Природа языка...
    * Ограниченные выразительные возможности...
    * Ориентированность на предметную область...
    Обратите внимание на то, что ориентированность на предметную область оказалась последней в списке и является лишь следствием ограниченных выразительных возможностей. Многие используют буквальное определение DSL как язык для конкретной предметной области.

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


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

    S>Влад, с какого момента можно называть человека толстым? Где граница между "полным", "полноватым", и "склонным к полноте"?

    Меня не интересует этот вопрос. Да и реально толстого мы все определим без проблем. А вот реальные ЯОН вроде ВБА и 1Эс вы, почему-то, определяете как ДСЛ. Хот, казалось бы, взгляни на них и все поймешь.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[11]: Языки общего назначения не имеют смысла!
    От: alex_public  
    Дата: 13.04.12 22:20
    Оценка:
    Здравствуйте, PSV100, Вы писали:

    PSV>А лично я от программирования в GUI-дизайнере как-то уже отошёл в сторону. Всё-таки неудобно, когда ты не видишь в виде удобного (!) кода то, чего создаешь, что изменяешь (дельфовские DFM-файлы — они не для этого), есть неудобное разделение — что-то нужно делать в дизайнере (в которых ковыряться мало удовольствия), а что-то нужно в коде ваять. К тому же дизайнерство ограничивает тебя в функционале, потенциале, несмотря на то, что например, в Delphi вполне мощная техника наследования форм. Кроме того, направленность на GUI-дизайнер влияет на архитектуру визуальной библиотеки, в результате, хоть в своём программном коде можно делать абсолютно всё (дизайнерство никак не ограничивает в коде), но работать с GUI в коде неудобно, громоздко (если с нуля что-то создавать).


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

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

    PSV>Delphi повлиял на Net, там тоже любят дизайнеров. А вот в жабе как-то дизайнеры особо не востребованы. Там научились программировать, хотя джава как язык не фонтан для этого. Для расположения контролов используют выравниватели — layout manager.


    Да, да, у нас тоже только на них всё. Никаких абсолютных координат (хотя возможность и для этого есть) и т.п. Иначе сделать автоматический перевод интерфейса очень напряжно. ) А так он работает из коробки. )))

    PSV>Ну, прежде всего, нужно ориентироваться на конкретные задачи, конкретные потребности. А в таком, глобальном, масштабе я с тобой не соглашусь. Вот тот же HTMLLayout специально создавался с целью позволить разделить дизайнерчество от программирования, ну кроме того, чтобы дать возможность делать любой интерфейс и как-то упростить программирование.


    HTMLayout — специфическое решение, которое приносит web-технологии в нативные приложения. Поэтому не очень укладывается в то разделение, про которое я писал. И таких решений много довольно. Тот же XULRunner. У меня пока смешанное отношения к ним и неясное видение их будущего...

    PSV>
  • декларативное описание GUI. В рамках вэба стандарт является HTML, он же повлиял и на десктоп. Его недостаток в том, что он труден для восприятия и для прямой работы с ним. Также он затрудняет задачи локализации (разные варианты языков), если убрать из него содержательный текст, останутся только одни тэги, причём в этом случае они неудобны, ведь HTML — это язык для разметки элементов внутри текстового документа (для чего он и предназначался), а теперь текста и нет, сплошные неудобные угловые скобки. Но он стандарт, поэтому востребован.
    HTML в чистом виде использует только подмножество нормального набора нативных контролов. В вебе это обычно расширяется вручную. Но мы же хотим использовать html как язык размётки...

    PSV>Второй вариант, это DSL по мотивам JavaFX-скрипта, пример которого я приводил раньше. Он оперирует не текстом, а GUI-элементами: сценами и объектами внутри них. В принципе, тут даже и спецы-дизайнеры также смогут работать, ибо, как я понимаю, это уже тоже некий типовой промстандарт. Конкретно JavaFX-скрипт позволяет ещё и включать сразу в себя и программный код, внутри описаний, но этот вопрос решаем (в этом и плюс тоже, тут и дизайнерам может даже что-то пригодиться, но как-то это нужно ограничить, но не ликвидировать полностью).


    Да, интересное решение.

    PSV>А этот микрософтский XAML — в какой-то степени JavaFX-скрипт, но в XML-формате. Спецы по нему вроде только в рамках около WPF. Имхо, для ручной работы неприятен, несмотря на чудеса от IDE. Такой XML, как и в JavaFX, имхо, лучше применять в рамках кодогенерации, в т.ч. и при работе GUI-дизайнеров, для чего, в первую очередь, их и придумывают. Я же пытаюсь нащупать способ для простой жизни, без дизайнеров.


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

    PSV>
  • Нужно и удобное прямое алгоритмическое программирование GUI. Какое бы не было крутое декларативное описание, но всех потребностей оно никогда не покроет. Здесь какой-нибудь miglayout очень кстати (соответственно и декларативный DSL должен иметь как бы прямую связь с API языка программирования, т.е. в DSL задаются те же элементы, что и в этом miglayout).

    Точно. Вот его и ищем, но пока не видно ничего. Точнее есть нормальные решения в рамках системного языка, но хотелось бы всё же вынести это их него.
  • Re[31]: Языки общего назначения не имеют смысла!
    От: Vain Россия google.ru
    Дата: 13.04.12 22:29
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>>>Складывается ощущение, что вы мне пытаетесь доказать, что можно заменить запрос на SQL процедурой на C++, причём последняя будет иметь сопоставимую с запросом сложность. Но этого не может быть, так как это, очевидно, неверно.

    V>>Не так, в sql много чего кроме самих запросов. На самом деле сами запросы это вершина айсберга. Можно взять любой учебник по SQL и поисследовать на тему что ещё входит в "знания по SQL".
    S>Ещё раз спрошу: какой тезис вы пытаетесь доказать или оспорить? Вам что, кто-то тут написал, что SQL — проще, чем С++?
    А это что?

    SQL является удобным и несложным средством описания сложных операций с данными.

    По вашему получается что с++ по сложности вообще для первоклашек, раз так.
    [In theory there is no difference between theory and practice. In
    practice there is.]
    [Даю очевидные ответы на риторические вопросы]
    Re[31]: Языки общего назначения не имеют смысла!
    От: Vain Россия google.ru
    Дата: 13.04.12 22:33
    Оценка: :)
    Здравствуйте, WolfHound, Вы писали:

    V>>Не так, в sql много чего кроме самих запросов. На самом деле сами запросы это вершина айсберга. Можно взять любой учебник по SQL и поисследовать на тему что ещё входит в "знания по SQL".

    WH>Только в этой теме говорится о том что аналогичный запрос на С++ будет на порядки сложнее.
    Это вообще-то зависит от базы данных.
    WH>Так что совершенно не ясно к чему ты это сказал.
    Вот и мне не ясно почему вы приводите SQL как классический пример DSL, когда он вообще сам по себе и не доказывает что DSL может заменить языки общего уровня.
    [In theory there is no difference between theory and practice. In
    practice there is.]
    [Даю очевидные ответы на риторические вопросы]
    Re[14]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 14.04.12 00:05
    Оценка:
    Здравствуйте, Tanker, Вы писали:

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


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

    Вот в Америке сложилась традиционная школа основанная на BNF и LR-автоматных парсерах, и хрен ты им что объяснишь.

    Берем книгу дракона, глядим... Ба да там ни TDOP Пратта, ни PEG Форда нет. Ну, с PEG еще можно понять. Ему не так много лет (хотя базе уже лет 40, не меньше). Но TDOP — это 1974 год.

    А где доценты материал для курсов берут? Да из кнжек, что купили на Озоне, и из того пиара, что валит из-за всех дыр.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[20]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 14.04.12 00:14
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>Скажите мне Киса, как художник художнику, вот Аппель — он по делу пишет, или только теоретик? Я имею в виду http://www.cs.princeton.edu/~appel/modern/


    Где берут сабж?
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[19]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 14.04.12 04:01
    Оценка: +1 :)
    Здравствуйте, koodeer, Вы писали:

    K>Скорее так: годами и десятками лет пытаются выразить специфику неудобными конструкциями языков общего назначения. Колются, плачут, но продолжают мучиться.


    Ну давай проведем эксперимент. Вот типовой серверный бизнес-код на универсальном языке — C#. Давай ты продемонстрируешь, как все будет круто на DSL?
    // откатить отработку документов в ХО
    UncarryDocuments(objectsIds);
    var cardsDeleteSet = new HashSet<IInventoryCardBase>();
    var documents = Manager.Get(objectsIds);
    foreach (IInternalDisplacementDocument doc in documents)
        foreach (IInventoryInternalDisplacementOperation obj in doc.GetObjects())
        {
            IInventory inv = obj.GetInventory();
            // Найти все связанные операции по видам учета
            IInventoryOperation[] operations = inv.GetInventoryOperations(
                null, InventoryOperationKindEnum.InternalDisplacement, (IDocument)doc, null, null, null);
            foreach (IInventoryOperation operation in operations)
            {
                IInventoryOperation relatedOperation = operation;
                // не должно быть более поздних операций
                if (inv.GetInventoryOperations(relatedOperation.AccountingKind, null, null, null, null, null)
                        .Any(op => op.Order > relatedOperation.Order))
                    throw new BusinessException("После внутреннего перемещения не должно быть операций.");
                if (!Equals(relatedOperation.InventoryCardBefore, relatedOperation.InventoryCardAfter)
                        && !(relatedOperation.InventoryCardAfter is IAccrualAccountingInventoryCard))
                    cardsDeleteSet.Add(relatedOperation.InventoryCardAfter);
                // удалить операции
                DeleteInventoryOperation(relatedOperation);
            }
            IInventory invAfter = inv.ChangesHistory;
            if (invAfter != null)
            {
                IInventoryCardObject invCardObj = invAfter.GetInventoryCardObject();
                if (invCardObj != null)
                {
                    var card = ((IPersistedObject)invCardObj).Master as IInventoryCardBase;
                    if (card is IAccrualAccountingInventoryCard)
                        Manager.DeleteObject((IPersistedObject)invCardObj);
                    else if (!cardsDeleteSet.Contains(card))
                        invCardObj.Inventory = inv;
                }
                inv.ChangesHistory = null;
                ChangeInventoryActualStateInDocuments(invAfter, inv);
                ILinkManager linkManager = LinkManager;
                foreach (IObjectLink link in linkManager.GetAllInLinks(((IIdentifiableObject)invAfter).Id))
                {
                    var linkDoc = link.Source as IDocument;
                    if (linkDoc != null)
                        throw new BusinessException(InventoryIncludedErrorTemp, linkDoc.DisplayName);
                }
                Manager.DeleteObject((IPersistedObject)invAfter);
            }
            else
                ChangeInventoryActualStateInDocuments(inv, inv);
            // изменить ИО
            inv.MateriallyResponsiblePerson = doc.GetDelivererMateriallyResponsiblePerson();
            inv.StructuralSubdivision = doc.GetDelivererSubdivision();
        }
    // удалить созданные при отработке инвентарные карточки
    if (cardsDeleteSet.Count > 0)
        Manager.DeleteObjects(cardsDeleteSet);
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[21]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 14.04.12 04:26
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Где берут сабж?

    Я года четыре назад его находил выложенным где-то.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[32]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 14.04.12 04:32
    Оценка: +1
    Здравствуйте, Vain, Вы писали:

    V>А это что?

    V>

    V> SQL является удобным и несложным средством описания сложных операций с данными.

    V>По вашему получается что с++ по сложности вообще для первоклашек, раз так.
    Ваша ошибка — в попытке оценивать сложность в отрыве от задачи. Для описания операций с данными SQL значительно проще, чем любой GPPL, будь то си, паскаль, или жава.
    И чем сложнее эти операции, тем сильнее рулит SQL.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[7]: Языки общего назначения не имеют смысла?
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 14.04.12 04:40
    Оценка:
    Здравствуйте, VladD2, Вы писали:


    VD>Взаимоисключаемы ДСЛ-и и ЯОН-ы. Понятно, что полнота по тьюрингу не четкий критерий, но наличие процедур, циклов, условных операторов и прочего барахла, как бы говорит нам, что это 100% ЯОН. И не фига тут философствовать.


    VD>Говоря о чем-то нужно пнимать о чем идет речь. При очень вольной трактовке понятния ДСЛ его просто нельзя использовать, так как одним и тем же термином описываются принципиально разные вещи.

    И ты в поддержку этой точки зрения цитируешь Фаулера, для которого XSTL одновременно является и GPPL и DSL — в зависимости от задачи.

    VD>И все это потому, что ДСЛ — это не о том, что язык для чего-то заточен, а о том, что язык предназначен только для чего-то.

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

    VD>Еще одним показателем ЯОН-а является то можно ли на нем (без использования других языков) написать целую систему.

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

    VD>Это не имеет отношение к делу. Ты как и многие не верно (прямолинейно) толкуешь термин ДСЛ. Кстати, у Фаулера об этом хорошо сказано:

    Прости, но Фаулер для меня не авторитет. Для тебя, кстати, тоже — см. противоречие выше.

    VD>Меня не интересует этот вопрос. Да и реально толстого мы все определим без проблем.

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

    А вот реальные ЯОН вроде ВБА и 1Эс вы, почему-то, определяете как ДСЛ. Хот, казалось бы, взгляни на них и все поймешь.
    ВБА — не DSL. В нём нет никакой доменной специфики. Про 1С ничего не скажу, в связи с некомпетентностью в нём.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[8]: Языки общего назначения не имеют смысла?
    От: Cyberax Марс  
    Дата: 14.04.12 05:00
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>А вот реальные ЯОН вроде ВБА и 1Эс вы, почему-то, определяете как ДСЛ. Хот, казалось бы, взгляни на них и все поймешь.

    S>ВБА — не DSL. В нём нет никакой доменной специфики. Про 1С ничего не скажу, в связи с некомпетентностью в нём.
    VB6 — чистый DSL для создания простых UI (язык необязательно должен быть чисто текстовым). VB.NET — это уже другой синтаксис для С#.

    1С — это целый комплекс, там язык не так важен, на самом деле.
    Sapienti sat!
    Re[7]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 14.04.12 05:11
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    _>>А вот если бы у нас в gui dsl можно было бы задавать хотя бы минимальные действия... Весь значительная часть обработчиков замкнута самая же на себя. Т.е. зачем обращаться в мощный основной язык ради того что бы в обработчики команды меню вызвать команду "показать диалог такой-то". И таких вызовов очень много! Значительная часть обработчиков состоит из вызова одной строки — вызова функции другого gui контрола. Это всё можно было замкнуть внутри себя, сделав вызовы наружу (в системный язык) только уже для реальной функциональности. Вот на такой dsl я бы точно перешёл. Но таких gui фреймворков я не знаю вообще.

    S>Это интересная идея.

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

    На DSL тут не императивщину писать надо, а связывать элементы управления и команды. Но вроде в дизайнере это и так несложно делается визуально.
    Re[7]: Языки общего назначения не имеют смысла?
    От: netch80 Украина http://netch80.dreamwidth.org/
    Дата: 14.04.12 06:15
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD> Таким образом, несмотря на его ориентированность на предметную область, я бы не назвал его предметно-ориентированным языком.


    5 баллов. "Несмотря на то, что эта ткань белого цвета, я бы не назвал её белой". Это везде так у Фаулера?

    VD>Другими словами — поддерживает мою точку зрения .


    Хорошо, я теперь буду знать, что "я бы не назвал белое белым" является адекватным выражением твоей точки зрения. Учтём это в спорах об уездном городе языке N и других горячих темах

    А если более конструктивно, вы оба впали в проблему недостатка терминов, но почему-то отказываетесь признать это явно. Хороший учёный тут хотя бы пронумеровал варианты, если недостаточно данных или фантазии для собственных названий. Например, белый-1 — это тот белый, который ты признаёшь белым, а белый-2 — тот, что не признаёшь. Далее попытался бы сформулировать критерии различия, пусть даже кривые и нечёткие. Проблема уже поставлена, а дальше можно надеяться, что кто-то ещё сможет сформулировать различие.

    Мне кажется, что тут таки надо различать предметную *ориентированность*, *специализированность*, *специфичность* и *ограниченность*. То, что Фаулер пытался сказать, должно быть скорее сказано так: "R обладает предметной *ориентированностью* на задачи статистики, и частично *специализирован* на неё, но не *специфичен* и не *ограничен*".

    Прикидка определения каждого из этих понятий:
    * ориентированность — имеет специализированные средства для названной цели, но не общую адаптацию
    * специализированность — адаптирован в целом (в общих принципах) под названную цель
    * специфичность — реализация запросов за пределами названной цели заметно усложнена
    * ограниченность — не имеет средств, выходящих за пределы, нужны для реализации названной цели

    они представляют собой последовательное усиление в сторону DSL, в том же порядке.

    VD>Взаимоисключаемы ДСЛ-и и ЯОН-ы. Понятно, что полнота по тьюрингу не четкий критерий, но наличие процедур, циклов, условных операторов и прочего барахла, как бы говорит нам, что это 100% ЯОН. И не фига тут философствовать.


    См. выше — должен быть не один критерий, а четыре.

    VD>Это не имеет отношение к делу. Ты как и многие не верно (прямолинейно) толкуешь термин ДСЛ. Кстати, у Фаулера об этом хорошо сказано:


    VD>В этом определении есть четыре ключевых элемента.

    VD>* Язык программирования...
    VD>* Природа языка...
    VD>* Ограниченные выразительные возможности...
    VD>* Ориентированность на предметную область...
    VD>Обратите внимание на то, что ориентированность на предметную область оказалась последней в списке и является лишь следствием ограниченных выразительных возможностей. Многие используют буквальное определение DSL как язык для конкретной предметной области.

    Во-во. Проблему он почувствовал, но выразить не супел.

    VD>Меня не интересует этот вопрос. Да и реально толстого мы все определим без проблем. А вот реальные ЯОН вроде ВБА и 1Эс вы, почему-то, определяете как ДСЛ. Хот, казалось бы, взгляни на них и все поймешь.


    Так крайние случаи очевидны, если бы всё состояло из них, и дискуссии не было бы.
    The God is real, unless declared integer.
    Re[12]: Языки общего назначения не имеют смысла!
    От: v2kochetov Россия  
    Дата: 14.04.12 06:51
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    G>>Впрочем, 1С-сники специально сделали ее настолько простой, что на ней может писать бухгалтер.


    VD>Это полнейший гон. Ни одни бухгалтер (если он по совместительству не программист) не сможет написать на 1Эс нихрена.


    "Это полнейший гон" — надо понимать заголовок твоего последующего суждения?

    За свой небольшой опыт работы 1Сником — 1 год всего-лишь, я лично работал с тремя клиентами, которые сами писали себе код — с двумя бухгалтерами и одним мелким предпринимателем.
    Да это был не ахти какой сложный код, они не автоматизировали полный цикл производства или что-то в этом духе, но делали себе отчеты, добавляли субконто к проводкам и тому подобные мелочи.
    Программирование не настолько сложная штука, чтобы ей могли заниматься только программисты с профильным образованием.
    ... << RSDN@Home (RF) 1.2.0 alpha 5 rev. 21>>
    Re[13]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 14.04.12 07:41
    Оценка: +1 -2
    Здравствуйте, v2kochetov, Вы писали:

    V>За свой небольшой опыт работы 1Сником — 1 год всего-лишь, я лично работал с тремя клиентами, которые сами писали себе код — с двумя бухгалтерами и одним мелким предпринимателем.

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

    Не надо откровенно врать. То что кто-то там в визуальном редактре сделал себе отчет (скорее всего под присмотром программиста) еще не значит, что этот человек может писать на языке встроенном в 1Эс. А именно он здесь обсуждается.

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

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

    Идея "заставить писать код экспертов предметной области" поднималась уже не раз. Всякий раз они проваливалась. Хрестоматийный пример — SQL.

    Но SQL хотя бы ДСЛ. А 1Эс-ный язык — это полноценный императивный язык. Для его освоения надо стать программистом.

    Для того чтобы эксперт мог читать или даже править код — это код нужно выражать на крайне ограниченном, декларативно и простом ДСЛ-е. И то только отдельные эксперты смогут его понимать.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[18]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 14.04.12 07:54
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    O> А, ну да, оба из 70х. В любом случае, парсеры это далеко не главное. Драконовщина нанесла непоправимый вред в первую очередь как раз зацикленностью на парсерах.


    На самом деле там парсерам посвящено не более 20% места.

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

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

    WH>>Она не вся гнилая. Есть там и полезные темы. Просто нужно перекопать кучу навоза, чтобы найти что-то полезное.


    O> Естественно, term rewriting, семантики и тому подобное это в целом полезно.


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

    O>Хоть и тут без ненужного переусложнения не обошлись.


    +1

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

    Из-за этого же сложно найти что-то ценное, так как чтобы понять есть ли в работе что-то ценное, или нет, нужно продраться сквозь наукообразный булшит до сути идеи, которая обычно легко выражается на пальцах в трех абзацах.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[8]: Языки общего назначения не имеют смысла?
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 14.04.12 08:29
    Оценка:
    Здравствуйте, netch80, Вы писали:

    N>Хорошо, я теперь буду знать, что "я бы не назвал белое белым" является адекватным выражением твоей точки зрения. Учтём это в спорах об уездном городе языке N и других горячих темах


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

    Точно так же одно то, что язык используется для решения узкого круга задач, еще недостаточно для того чтобы называть его ДСЛ-ем. Он так же должен обладать ограниченными выразительными возможностями. Языки обладающие неограниченными выразительными возможностями не могут называться ДСЛ-ями. По сему 1Эс и ВБА не ДСЛ-и.

    Серджинио тут где-то привел определение подходящее для 1Эс-ного язяка. Что-то типа предметно-ориентированный язык высокого уровня. Что можно перевести на детерминированный язык как заточенный под предмет ЯОН.

    N>А если более конструктивно, вы оба впали в проблему недостатка терминов, но почему-то отказываетесь признать это явно.


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

    Причем дело доходит до обсурда.

    Один под ДСЛ-нем начинает понимать все языки программирования которые кто-то прикрутил к какому то приложению (в том числе и жабаскрпит в броузерах).

    Другой называет ДСЛ-ем наличие модели в приложении.

    Третий видит ДСЛ в любом АПИ.

    Короче полнейшая каша. С такой терминологической какофонией применять этот термин нельзя в принципе. Иначе любой разговор превратится в полную бессмыслицу.

    N> Хороший учёный тут хотя бы пронумеровал варианты, если недостаточно данных или фантазии для собственных названий. Например, белый-1 — это тот белый, который ты признаёшь белым, а белый-2 — тот, что не признаёшь. Далее попытался бы сформулировать критерии различия, пусть даже кривые и нечёткие. Проблема уже поставлена, а дальше можно надеяться, что кто-то ещё сможет сформулировать различие.


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

    N>Мне кажется, что тут таки надо различать предметную *ориентированность*, *специализированность*, *специфичность* и *ограниченность*. То, что Фаулер пытался сказать, должно быть скорее сказано так: "R обладает предметной *ориентированностью* на задачи статистики, и частично *специализирован* на неё, но не *специфичен* и не *ограничен*".


    Фаулер не рассматривает отвлеченных тем. Он рассматривает то, что он сам считает (и называет) ДСЛ-ями.
    По сему он привел ряд критериев которые позволяют назвать язык ДСЛ-ем (по его мнению). Я сними согласен.
    Но к сожалению, они неформальны. Вот они:

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

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

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


    Его мысль в том, что наличие одного из условий еще не делает язык ДСЛ-ем. Нужно сочетание факторов.
    И я с этим категорически согласен.

    N>Прикидка определения каждого из этих понятий:

    N>* ориентированность — имеет специализированные средства для названной цели, но не общую адаптацию
    N>* специализированность — адаптирован в целом (в общих принципах) под названную цель
    N>* специфичность — реализация запросов за пределами названной цели заметно усложнена
    N>* ограниченность — не имеет средств, выходящих за пределы, нужны для реализации названной цели

    Опять какая-то каша. Ориентированность, специализированность и специфичность — это все из одной оперы.

    VD>>Взаимоисключаемы ДСЛ-и и ЯОН-ы. Понятно, что полнота по тьюрингу не четкий критерий, но наличие процедур, циклов, условных операторов и прочего барахла, как бы говорит нам, что это 100% ЯОН. И не фига тут философствовать.


    N>См. выше — должен быть не один критерий, а четыре.


    Твои критерии вообще никуда не годятся. Критерии фаулера — годятся.

    Язык с неограниченной выразительностью ДСЛ-ем быть не может, согласно этим критериям.

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

    Зато язык не полный по тьюрингу и ориентированный на конкретную задачу — это уже точно ДСЛ.

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

    N>Во-во. Проблему он почувствовал, но выразить не супел.


    Он то сумел. Просто кто-то кобенится и не хочет понять сказанного.

    Я бы предпочел четкую терминалогию, и четкое разделение понятий. Язык 1Эс нужно отличать как от универсальных ЯОН-ов, так и от ДСЛ-ей. Это самостоятельный класс языков.

    VD>>Меня не интересует этот вопрос. Да и реально толстого мы все определим без проблем. А вот реальные ЯОН вроде ВБА и 1Эс вы, почему-то, определяете как ДСЛ. Хот, казалось бы, взгляни на них и все поймешь.


    N>Так крайние случаи очевидны, если бы всё состояло из них, и дискуссии не было бы.


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

    Такие "знания" и такая терминология не дает возможность продуктивно обсуждать данную область.

    Так что нужно сделать одно из двух:
    1. Ограничить определение термина ДСЛ выделив независимые понятия в отдельные понятия и дав им названия (введя термины).
    2. Придумать новые термины для подтипов ДСЛ-ей, если уж не удается прийти к консенсусу в п.1.

    Вот регекспы и ВБА по-твоему ДСЛ-и?

    Если, да, то нужно придумать новые термины для различения этих подвидов ДСЛ-ей.

    Если нет, то для ВБА нужно придумать отдельный термин, а ДСЛ-ем называть только регекспы.

    Для ВБА термин есть — скриповый язык встроенный в хост-приложение. А как нажвать класс ДСЛ-ей в который входят регексы, SQL и т.п.?
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[8]: Языки общего назначения не имеют смысла?
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 14.04.12 09:24
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>И ты в поддержку этой точки зрения цитируешь Фаулера, для которого XSTL одновременно является и GPPL и DSL — в зависимости от задачи.


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

    Фаулер тоже философствует. Критерии действительно не четки. И XSTL — это забавный пример. В принципе XSTL отлично подходит под определение ДСЛ-я, но в погоне за гибкостью в XSTL были включены фичи которые позволяют использовать (и довольно эффективно) его не по назначению. Если XSTL начинает использоваться не для преобразования текста — это он сразу же превращается в ЯОН. Главное здесь, то что использование XSTL для рассчетов — это внеполовое извращение.

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

    VD>>И все это потому, что ДСЛ — это не о том, что язык для чего-то заточен, а о том, что язык предназначен только для чего-то.

    S>Ок, так тоже можно. Но даже если мы будем судить о DSL-ности по тому, чего именно нельзя на этом языке, всё равно у нас будет континуум таких языков.

    Нам нужно четко разделить ВБА, 1 Эс, SQL и регексы. SQL и регексы — это четкие представители того что я (и, как оказалось, Фаулер) называю ДСЛ-ем. ВБА — для меня вообще скрипт не имеющий к ДСЛ-ю никакого отношения. 1Эс — спорный вопрос, но я бы отнес его к специализированным ЯОН или даже к ЯОН с со встроенными ДСЛ-ями (хотя основную мощь в 1Эс определяет среда и встроенная модель).

    Такое разделение нам необходимо для плодотворного обсуждения вопросов связанных с разработкой ДСЛ-ей.

    На мой взгляд ДСЛ должен обладать одной моделью. Если язык штатно позволяет манипулировать несколькими моделями, то это уже ЯОН (или очень кривой ДСЛ).

    Скажем моделью SQL является запрос к СУБД, ХСЛТ описывает модель трансформации ХМЛ, а моделью регексов — паттерн поиска подстроки в тексте. SQL, ХСЛТ и регексы всего лишь удобный синтаксис по заполнению соответствющих моделей. 1Эс же — это универсальный язык который позволяет в том числе манипулировать рядом моделей которые предоставляет среда 1Эс.

    И это огромное различие. Под истенные ДСЛ можно подвести четкую иделогию:
    1. Проектируем модель описывающую решаемую задачу.
    2. Проектируем язык позволяющий максимально декларативно и понятно заполнить модель.
    3. Делам компилятор или интерпретатор модели.

    Все! Мы получили способ решения сложных проблем в любой области.

    Для создания жерешений вроде 1Эс данная иделогия не применима, так как в 1Эс много моделей и связующего их кода. 1Эс можно представить как ряд ДСЛ-ей, часть из которых визуальные (формоклепство и описание отчетов).

    VD>>Еще одним показателем ЯОН-а является то можно ли на нем (без использования других языков) написать целую систему.

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

    Ты опять извращаешь реальность. Библиотеки ни разу не отдельная сущность для ЯОН. У любого языка можно отнять библиотеки и он станет ограниченным в возможностях. Но это ни разу не меняет реальность.

    Это ты выдумал сам, что ЯОН без библиотек чудесным образом превращается в ДСЛ. Но это не так! ЯОН позволяет описать модели прямо внутри себя и решить любые задачи без использования библиотек. Библиотеки только позволяют общаться с внешним миром.


    VD>>Это не имеет отношение к делу. Ты как и многие не верно (прямолинейно) толкуешь термин ДСЛ. Кстати, у Фаулера об этом хорошо сказано:

    S>Прости, но Фаулер для меня не авторитет. Для тебя, кстати, тоже — см. противоречие выше.

    У меня вообще нет авторитетов. Но мужик провел реальную работу по классификации я согласен с его выводами. Ну, и сам факт, что мое мнение не уникально уже косвенно подтверждает его правоту.

    VD>>Меня не интересует этот вопрос. Да и реально толстого мы все определим без проблем.

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

    Опять софистика. По фигу в какой компании находится человек страдающий ожирением третьей степени. Весящие складки жира на боках, 3-ий подбородок — это трудно не заметить.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[13]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 14.04.12 09:27
    Оценка:
    Здравствуйте, fmiracle, Вы писали:

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


    В целом согласен, но хочу заметить, что в школьной программе как раз частенько бывает так, что вначале дается легкая информации, а позже уже более сложная и формальная.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[25]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 14.04.12 10:13
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    V>А я не про DSL, а про то, что при наличии такой возможности многие DSL вполне могут служить языками общего назначения. Даже случайно.

    Вы так говорите, как будто это плохо.

    V>С тобой не согласен синтаксис объявления функций без определения в С и ключевое слово extern для переменных.

    И тем не менее, никакого способа сообщить в языке "мне нужна эта библиотека" нету. Всю нездоровую мощь программе даёт рантайм,

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

    Простите, это чушь. Линкер всего лишь разрешает символьные имена. Никакой информации об ABI в нём нету. Ну, то есть современные линкеры стали шибко умными и поддерживают LTCG, но языку C не нужна LTCG. Она не является частью спецификации. И линкер не является частью языка C.

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

    Вы правильно помните. Итак, стал ли Лого GPPL после добавления возможности импорта библиотек на том же Лого?

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

    Я как раз ничего не путаю. В JS я тоже могу подключать любые "нейтивные" библиотеки. Если хост будет столь добр, что разрешит CreateObject(), то я могу делать всё, что угодно. В С роль хоста играет линкер.

    V>А для какого-нить скриптового, со встроенным типом SomeType — вовсе не факт. Потому что помимо синтаксиса важна еще семантика происходящего. И эта семантика таки входит в спецификацию языка.


    Ок, тогда давайте вернёмся к вопросу определений. Как мы убедились, возможность подключать библиотеки сама по себе никак не влияет на DSLность языка.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[23]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 14.04.12 10:23
    Оценка:
    Здравствуйте, vdimas, Вы писали:


    V>Ну, во-первых запрос мне кажется некорректным, т.к. не выведет менеджеров, у которых не было продаж вообще.

    Это зависит от формулировки задачи. Предположим, что он корректен.

    V>Во-вторых, есть минимум 2 популярных библиотечных подхода:

    V>1. это непосредственная реализация некоей функциональности (например, это иерархия объектов и весь функционал контролов WPF).
    V>2. "движок" поверх этой функциональности, который на входе берет некое декларативное описание и по нему комбинирует имеющийся фнкционал (это интерпретаторы XAML форм, стилей, шаблонов отображения, шаблонов данных и т.д.)

    V>Прикладной вызов либы как-то так:

    V>
    V>struct OrderTotal { ManagerID managerId; double amount; }
    
    V>auto annual = select(from(orders), between(cdate("20100101", &Order::orderDate, cdate("20101231")))
    V>auto byManager = group(annualOrders, groupBy(&Order::managerId));
    V>auto orderTotals = transform(byManager, transformWrap<OrderTotal>((_1.managerId=_2.first, _1.amount=sum(_2.second, &Order::amount)) ));
    V>


    V>Дальше лень расписывать, пока было расписано подвыражение:

    V>select ManagerID, sum(Orders.Amount) from Orders where Orders.OrderDate between '20100101' and '20101231' group by ManagerID;
    Отлично. Пока что SQL рвёт библиотеку 1 к 3м по компактности и читаемости.
    И это у вас ещё нет никаких попыток разрешить переписывания и оптимизации запроса внутри библиотеки — ваши предикаты это всего лишь функторы, а не Expression Trees.

    V>Можно спросить, что ты хотел узнать?

    Да я-то ничего нового не узнал. Я хотел вам показать разницу между DSL и библиотекой, нарисованной на GPPL. Надеюсь, показал.
    V>На Клиппере пожестче было в свое время — никто не жаловался. И рвали по быстродействию любые базы, бо скомпилированный код многократно быстрее интерпретируемого работает.

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


    V>>>Если же ты о перезаписи операций и прочей оптимизации — то это совсем отдельные операции, которые тоже, впрочем, достаточно формализованы.

    S>>Хотелось бы, чтобы перезапись операций и прочая оптимизация были не хуже, чем в SQL.

    V>Это нужен подход №2, когда выражение дается в виде декларации и доступно затем для аналитических вычислений. Тогда точно так же как показано выше в синтаксисе, но пусть select, from, transform и т.д. являюся не вызовами на обработку коллекций, а конструкторами узлов графа операций (аналог AST). Добавится лишь еще одна команда, нечто типа:

    V>
    V>auto resultingCollection = execute(result);
    V>

    Что-то меня гложут тяжкие сомнения про то, что это так легко сделать, как вы пишете. Скажем, Версанту потребовалось всё-таки приделать свой парсер C++, чтобы обойти ограничения языка. Для AST недостаточно скормить в between указатель на член класса — надо каким-то образом дать возможность среде определить, что это за член класса такой, и поднять всю нужную метадату.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[24]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 14.04.12 10:24
    Оценка:
    Здравствуйте, Tanker, Вы писали:

    T>Тут самое интересное начинается. Есть ДСЛ для организации всяких импортов ?

    Мне неизвестны.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[14]: Языки общего назначения не имеют смысла!
    От: v2kochetov Россия  
    Дата: 14.04.12 11:03
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Не надо откровенно врать. То что кто-то там в визуальном редактре сделал себе отчет (скорее всего под присмотром программиста) еще не значит, что этот человек может писать на языке встроенном в 1Эс. А именно он здесь обсуждается.

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

    VD>Я знаю много околокомпьютерных людей близких к программированию, но не программистов и не раз видел как они пытались влезть в программирование Ворда, Ёкселя или Эксеса. Их хватало на примитивные правки сгенерированного кода. Попытка выразить логику на (вроде бы языке для не проффесионалов) неизменно выливалась в то, что они звали меня или еще кого-то.

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

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


    VD>Идея "заставить писать код экспертов предметной области" поднималась уже не раз. Всякий раз они проваливалась. Хрестоматийный пример — SQL.

    И еще много раз провалится, в том числе и с DSLями.

    VD>Но SQL хотя бы ДСЛ. А 1Эс-ный язык — это полноценный императивный язык. Для его освоения надо стать программистом.

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

    VD>Для того чтобы эксперт мог читать или даже править код — это код нужно выражать на крайне ограниченном, декларативно и простом ДСЛ-е. И то только отдельные эксперты смогут его понимать.

    Существуют люди, которые пишут код и отлично разбираются в предметной области, но таких крайне мало и стоят они дорого.
    ... << RSDN@Home (RF) 1.2.0 alpha 5 rev. 21>>
    Re[8]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 14.04.12 11:08
    Оценка:
    Здравствуйте, Pavel Dvorkin, Вы писали:

    PD>Картинка размером от 3000*5000 до 5000*6000 пикселей, размер файла 15-30 Мб.

    PD>Время на обработку — 200-300 мсек на современном процессоре. Не уложишься — считай, что задача не решена.

    PD>Я ее писал на С. Наверное, неправильно делал. Расскажи, на чем надо было бы писать.

    Думаю, надо писать на ассемблере. Потому как "модели" тут у предметной области нет никакой. Выполнять побайтное сравнение с константой — это ровно одна операция. Задача не в том, как эту операцию представить в более читаемом виде, а как поаккуратнее запихать данные в SSE.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[20]: Языки общего назначения не имеют смысла!
    От: koodeer  
    Дата: 14.04.12 11:28
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    AVK>Ну давай проведем эксперимент. Вот типовой серверный бизнес-код на универсальном языке — C#. Давай ты продемонстрируешь, как все будет круто на DSL?


    Лично я — не могу показать.
    1. Я не явлюясь специалистом в данной предметной области.
    2.1. Я не являюсь специалистом в создании DSL.
    2.2. У меня нет удобных средств написания DSL. Поэтому я с такой надеждой смотрю на N2, и желаю проекту успеха.
    Пока что я пишу примерно такой же код.

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

    В иделе, в моём понимании, процесс должен происходить примерно так: работают совместно два специалиста (две группы специалистов), один спец в программировании, другой спец в бизнесе. Бизнесмен перечисляет основные сущности своей области деятельности, программер тут же задаёт их в своём DSL. Всё, в дальнейшем они общаются уже на одном языке! Называют и используют одинаковые предметные сущности! Ни тому, ни другому уже не нужно держать в голове что-то из чужой для себя области.
    Re[15]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 14.04.12 11:50
    Оценка:
    Здравствуйте, v2kochetov, Вы писали:

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


    И какой объем кода написали твои не программисты?

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

    Я освоил программирование сам по книжкам и самостоятельным попыткам написать что-то. Вот только в процессе этого я и стал программистом.

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


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

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

    VD>>Идея "заставить писать код экспертов предметной области" поднималась уже не раз. Всякий раз они проваливалась. Хрестоматийный пример — SQL.

    V>И еще много раз провалится, в том числе и с DSLями.

    Вот именно!

    VD>>Но SQL хотя бы ДСЛ. А 1Эс-ный язык — это полноценный императивный язык. Для его освоения надо стать программистом.

    V>Тут всплывает другой вопрос — что значит "стать программистом"?

    Научиться мыслить алгоритмически. Понять (осознать) логическое устройство компьютера. Что такое память. Как ее менять. Что такое команды компьютеру. Что такое поток управления и как с его помощью управлять командами и памятью. Короче освоение архитектуры Фон Неймана.

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


    Да нельзя, нельзя! За пару месяцев можно освоить только технику. А стать программистом означает — уметь сформулировать алгоритм, уметь логически мыслить, уметь понять и устранить ошибку.

    Просто есть люди с врожденными талантами и те кто имеет некоторую подготовку. Вот они и составляют этот 1% освоивших (и то кое как) программирование.

    V>Я не готов спорить по поводу DSLности 1С, по нескольким причинам — я не знаю четкого и емкого определения DSL, а как показывает этот топик, оно необходимо, иначе спор похож на рассуждения дальтоников об оттенках красного, да и сам я 1с считаю императивным языком.


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

    VD>>Для того чтобы эксперт мог читать или даже править код — это код нужно выражать на крайне ограниченном, декларативно и простом ДСЛ-е. И то только отдельные эксперты смогут его понимать.

    V>Существуют люди, которые пишут код и отлично разбираются в предметной области, но таких крайне мало и стоят они дорого.

    Вот именно. Это потому, что человек фактически является и программистом, и еще кем-то. Т.е. совмещает два не простых знания.

    Что касается терминов, то я как раз об это и говорю. Никакая терминология мешает не только популяризации ДСЛ-подхода, но и банальному рассуждению о нем.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[17]: Языки общего назначения не имеют смысла!
    От: koodeer  
    Дата: 14.04.12 12:04
    Оценка: :)
    Здравствуйте, vdimas, Вы писали:

    V>Или взять популярный случай размерности величин. Не думаю, что для вменяемого программиста запись 42kg будет сильно отличаться от записи 42*unit.kg или unit.kg(42), тем более, что константы в коде встречаются относительно редко.


    Дело не просто в записи. На DSL можно реализовать не только запись размерности величин, но и проверку на этапе компиляции, разрешена ли операция над этими величинами.

    Поясню. Например, в обычном коде имеются две переменные типа double — масса и температура. Простой язык программирования никак не запретит допустим сложить две эти переменные: с точки зрения компилятор типы double можно складывать. Но с точки зрения физики массу и температуру складывать нет смысла: какая величина должна получиться?
    Именно эту ситуацию способен разрулить DSL.

    Конечно, нечто подобное можно реализовать в ООП: создать классы Масса и Температура, переопределить операции сложения для них. Но очевиден оверхед: для простых типов данных будет использоваться класс, что и быстродействие снизит, и память жрать будет. В случае обработки миллионов значений это критично.
    А в DSL и масса и температура по-прежнему останутся после компиляции простым типом. Никакого оверхеда в рантайме!
    Re[14]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 14.04.12 12:22
    Оценка:
    Здравствуйте, Tanker, Вы писали:

    T>А у меня было так — один и тот же преподаватель рассказывал про программирование и компиляторы и про ОС и много чего еще. Что странно, компиляторы в среднем давали худший выхлоп.


    А у меня было так. Изучал тему самостоятельно. Сначала пытался делать это на основании курсов из институтов и приславутой книги дракона (ибо единственный брэнд). Результат был плачевным.

    Потом начал изучать все на практике и читать малоизвестные научные работы. Результат в корне изменился.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[33]: Языки общего назначения не имеют смысла!
    От: Vain Россия google.ru
    Дата: 14.04.12 12:23
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    V>>А это что?

    V>>

    V>> SQL является удобным и несложным средством описания сложных операций с данными.

    V>>По вашему получается что с++ по сложности вообще для первоклашек, раз так.
    S>Ваша ошибка — в попытке оценивать сложность в отрыве от задачи. Для описания операций с данными SQL значительно проще, чем любой GPPL, будь то си, паскаль, или жава.
    S>И чем сложнее эти операции, тем сильнее рулит SQL.
    Ну так в этом и дело, вы пытаетесь рассматривать только запросы в отрыве от всего остального куда входят сами базы данных, управление правами, пользователями, связи и отношения в таблицах, триггеры, процедуры и т.д. Сами запросы это вершина айсберга.
    [In theory there is no difference between theory and practice. In
    practice there is.]
    [Даю очевидные ответы на риторические вопросы]
    Re[34]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 14.04.12 12:56
    Оценка: +1
    Здравствуйте, Vain, Вы писали:

    S>>И чем сложнее эти операции, тем сильнее рулит SQL.

    V>Ну так в этом и дело, вы пытаетесь рассматривать только запросы в отрыве от всего остального куда входят сами базы данных, управление правами, пользователями, связи и отношения в таблицах, триггеры, процедуры и т.д. Сами запросы это вершина айсберга.
    Нет. Запросы — это всё-таки ядро. Управление правами и пользователями — это администрирование серверов баз данных.
    Но вы по-прежнему не понимаете одну главную вещь: скрипты SQL гораздо проще для управления БД, чем любые библиотеки на С++. Совершенно неважно то, что сами базы данных — это большая и сложная область. Мы сейчас не сравниваем объём предметных областей. Мы сравниваем удобство и простоту различных языков для работы в этих областях.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[21]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 14.04.12 15:48
    Оценка: +3
    Здравствуйте, koodeer, Вы писали:

    K>Лично я — не могу показать.


    Воот.

    K>1. Я не явлюясь специалистом в данной предметной области.

    K>2.1. Я не являюсь специалистом в создании DSL.

    А таких людей вообще — просто считанное количество. That's the problem.

    K>2.2. У меня нет удобных средств написания DSL.


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

    K> Поэтому я с такой надеждой смотрю на N2, и желаю проекту успеха.


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

    K>Пока что я пишу примерно такой же код.


    Ну так покажи — какой код ты хотел бы писать.

    K>Просто, мне кажется очевидным: вся сложность в переложении специфики бизнеса на программые конструкции заключается именно в том, что конструкции кода так и остаются кодом.


    Идея DSL это не отменяет.

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


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

    P.S. Пример я привел, чтобы продемонстрировать две важные вещи:
    1) Для сочинения DSL требуется специфичная и очень высокая квалификация. Подчеркиваю, для сочинения, а не для реализации.
    2) Современные ЯОН совсем не так уж и ужасны при умелом использовании.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[8]: Языки общего назначения не имеют смысла!
    От: alex_public  
    Дата: 14.04.12 16:20
    Оценка:
    Здравствуйте, vdimas, Вы писали:

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


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

    V>На DSL тут не императивщину писать надо, а связывать элементы управления и команды. Но вроде в дизайнере это и так несложно делается визуально.


    Смотря что подразумевать под командами. Если функции из системного кода, то да — так и работают сейчас большинство редакторов. Но как показывает практика, большое количество этих команд сводятся к 1-2 вызовам функций других элементов интерфейса и всё. Соответственно подобная привязка прямо в визуальном редакторе (или же в текстовом gui dsl — кому что больше нравится), без создания обработчиков в системном коде (руками — как оно там внутри реализуется не важно) существенно повысила бы эффективность разработки. И кстати в таком случае например дизайнер мог бы тестировать логику работы интерфейса в режиме WYSIWYG, а не ждать пока программисты её реализуют.
    Re[18]: Языки общего назначения не имеют смысла!
    От: alex_public  
    Дата: 14.04.12 16:27
    Оценка:
    Здравствуйте, koodeer, Вы писали:

    <оффтопик>
    K>Но с точки зрения физики массу и температуру складывать нет смысла: какая величина должна получиться?
    В одной известной физической системе единиц как раз можно и даже возможно будет некий смысл. )))
    </оффтопик>

    А вообще я согласен. Именно в этом смысл DSL — ограничение возможностей.

    K>Именно эту ситуацию способен разрулить DSL.


    Только на самом деле действительно качественных dsl не так уж много. Мне с ходу sql, regexp, xslt, make в голову приходят — то, с чем часто имеем дело. Но это же капля в море. И инструментов для их проектирования в промышленных масштабах не видно.
    Re[16]: Языки общего назначения не имеют смысла!
    От: v2kochetov Россия  
    Дата: 14.04.12 16:36
    Оценка:
    Да наши позиции действительно схожи, но твой тон прямо провоцировал написать опровержение.

    Мне вот вообще интересно, те люди которые придумывают очередную фиговину на которой смогут писать кухарки и матросы, они вообще с пользователями когда-нибудь общались? Или хотя бы с коллегами — хреновыми программистами? На что они после такого общения вообще рассчитывают?
    ... << RSDN@Home (RF) 1.2.0 alpha 5 rev. 21>>
    Re[22]: Языки общего назначения не имеют смысла!
    От: koodeer  
    Дата: 14.04.12 17:13
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    K>>1. Я не явлюясь специалистом в данной предметной области.

    K>>2.1. Я не являюсь специалистом в создании DSL.

    AVK>А таких людей вообще — просто считанное количество. That's the problem.


    Таких людей — очень много! Каждый бизнесмен — специалист в своей области. (Пояснения дальше.)


    K>>Пока что я пишу примерно такой же код.


    AVK>Ну так покажи — какой код ты хотел бы писать.


    AVK>Я не прошу тебя написать парсер и анализатор DSL, я прошу показать, как DSL будет выглядеть.


    Это не я должен показывать. Это должны показывать бизнесмены. Оно уже есть: предметная область. Берём стандарт, ГОСТ, спецификацию этой области, и механически переносим в наш DSL.


    K>>2.2. У меня нет удобных средств написания DSL.


    AVK>Причем тут средства?


    Всё-таки от средств зависит многое.
    Я понимаю, что слишком многого хочу. Но в мечтах вижу создание DSL именно так: манипулирует предметная область текстами — наше средство создания DSL должно легко позволять это; бизнес манипулирует чертежами — DSL должен уметь делать это, а фреймворк по созданию DSL должен легко поддерживать это; и т. п.


    AVK>1) Для сочинения DSL требуется специфичная и очень высокая квалификация. Подчеркиваю, для сочинения, а не для реализации.


    Как я уже сказал, сочинять ничего не нужно: оно уже всё есть. Сочинено самими спецами в данной области.

    AVK>2) Современные ЯОН совсем не так уж и ужасны при умелом использовании.


    С этим конечно же не спорю.
    Re[23]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 14.04.12 17:31
    Оценка: 1 (1)
    Здравствуйте, koodeer, Вы писали:

    K>Таких людей — очень много! Каждый бизнесмен — специалист в своей области. (Пояснения дальше.)


    Это даже не смешно. При чем тут бизнесмен? Речь о специалисте по созданию DSL.


    AVK>>Я не прошу тебя написать парсер и анализатор DSL, я прошу показать, как DSL будет выглядеть.

    K>Это не я должен показывать. Это должны показывать бизнесмены.

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

    K> Оно уже есть: предметная область. Берём стандарт, ГОСТ, спецификацию этой области, и механически переносим в наш DSL.


    Продемонстрируй.

    K>>>2.2. У меня нет удобных средств написания DSL.

    AVK>>Причем тут средства?

    K>Всё-таки от средств зависит многое.


    Да пофик. Я тебя спрашиваю про то, как будет выглядеть DSL.

    AVK>>1) Для сочинения DSL требуется специфичная и очень высокая квалификация. Подчеркиваю, для сочинения, а не для реализации.

    K>Как я уже сказал, сочинять ничего не нужно: оно уже всё есть.

    Ну вот покажи мне это есть для приведенного примера. И область то — одна из самых в этом плане востребованных. Т.е. если в ней не будет, то можно считать, что готовых DSL почти нигде нет.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[17]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 14.04.12 17:59
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    O>Не строгую, конечно же, ну так строгие формулировки и не нужны. DSL и появляются из нестрогих формулировок.


    Смелое утверждение. Попробуешь обосновать?
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[24]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 14.04.12 17:59
    Оценка: :)
    Здравствуйте, Tanker, Вы писали:

    T>Тут самое интересное начинается. Есть ДСЛ для организации всяких импортов ?


    По странному стечению обстоятельств мне в ближайшее время предстоит спроектировать такой DSL.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[8]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 14.04.12 17:59
    Оценка:
    Здравствуйте, Pavel Dvorkin, Вы писали:

    PD>Картинка размером от 3000*5000 до 5000*6000 пикселей, размер файла 15-30 Мб.

    PD>Время на обработку — 200-300 мсек на современном процессоре. Не уложишься — считай, что задача не решена.

    Может я чего не понял в твоей задаче, но лобовое решение без всяких SSE и CUDA, типа такого:
    for (var y = 0; y < _height; y++)
    {
        var line = data[y];
        for (var x = 0; x < _width; x++)
            line[x] = line[x] < 128 ? (byte) 0 : (byte) 1;
    }


    На моем процессоре (мейнстрим годовалой давности) для картинки 6000х5000 дает 260мс.

    А чуть-чуть более умный:
    Parallel.For(
        0,
        _height,
        y =>
        {
            var line = data[y];
            for (var x = 0; x < _width; x++)
                line[x] = line[x] < 128 ? (byte) 0 : (byte) 1;
        });

    65 мс.
    Получается, уложился почти с 5-тикратным запасом.
    Только DSL на таких примитивных задачах, разумеется, мало что даст.
    А вот если SSE и CUDA понадобится, то там уже DSL заработает в полный рост.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[9]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 14.04.12 18:09
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    T>>2. компиляторы хорошо идут только у тех кто хорошо знает математику

    WH>Для того чтобы писать компиляторы матан знать не нужно.

    Матан не нужно. А вот CS (ну или ПМ в отечественной терминологии) было бы мягко говоря, неплохо.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[13]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 14.04.12 18:09
    Оценка: 1 (1) +1
    Здравствуйте, oldjackal, Вы писали:

    O> Из жизни, из практики. А преподаватели — это недоумки-теоретики, в основном. Много вы видели в ВУЗах преподавателей с реальным опытом в индустрии?


    Я себя в КубГУ в прошлом году видел. ABBYY вот на физтехе тоже силами своих спецов лекции читает.

    O> Они не только компиляторов не понимают, они вообще-то ничего не понимают.


    А ты какой ВУЗ по какой специальности закончил, если не секрет?

    O>Посмотрите на выпускников ВУЗов — они ни черта вообще не умеют


    Выпускники, они разные бывают. Несколько человек на поток обычно вполне вменяемые. А остальные просто для корочки 5-6 лет отсидели, что то по ним мерять неинтересно.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[18]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 14.04.12 18:31
    Оценка: +1
    Здравствуйте, koodeer, Вы писали:

    K>Поясню. Например, в обычном коде имеются две переменные типа double — масса и температура. Простой язык программирования никак не запретит допустим сложить две эти переменные: с точки зрения компилятор типы double можно складывать. Но с точки зрения физики массу и температуру складывать нет смысла: какая величина должна получиться?

    На шаблонах С++ эту задачу можно решить довольно просто.
    Показать, как или сам хочешь подумать?

    K>Конечно, нечто подобное можно реализовать в ООП: создать классы Масса и Температура, переопределить операции сложения для них. Но очевиден оверхед: для простых типов данных будет использоваться класс, что и быстродействие снизит, и память жрать будет. В случае обработки миллионов значений это критично.

    В случае с С++ это не проблема. Если в класс засунуть один double то там ничего кроме него не будет.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[20]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 14.04.12 18:46
    Оценка: +1
    Здравствуйте, AndrewVK, Вы писали:

    AVK>Ну давай проведем эксперимент. Вот типовой серверный бизнес-код на универсальном языке — C#. Давай ты продемонстрируешь, как все будет круто на DSL?

    Это не серьезно.
    Для того чтобы создать ДСЛ нужно садиться и анализировать предметную область.
    Ибо создание ДСЛ == создание архитектуры.
    Это один процесс.
    Создание архитектуры даже сложнее, ибо кроме создания ДСЛ происходит еще и натягивание этого ДСЛ на ЯОН таким образом, чтобы код не превращался в говно. В случае с ДСЛ это не проблема. Ибо код на ЯОН генерируется.

    Так что любой адекватный архитектор может спокойно создавать ДСЛи.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[23]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 14.04.12 18:59
    Оценка:
    Здравствуйте, VladD2, Вы писали:

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


    О как долго я пытался тебе это лет несколько назад объяснить. Извини, не удержался.

    VD> А скорее всего не ДСЛ.


    VD>Польза ДСЛ в декларативности описания. Меньше кода, меньше ошибок, больше метаинформации.


    И в идентичности его терминологии терминологии домена. Т.е. сущности в предметной области в соответствующем DSL часто являются first class citizen, в отличие от ЯОН.
    Для примера (не для тебя лично, для тех кто топик читает), тот же язык запросов Паруса. Есть там такая штука — enum. По сути, в БД, это просто гуид из предопределенного набора значений. Если я хочу поработать с ним из голого SQL, то мне придется писать что то такое:
    WHERE tbl.Attr = '67579290-3712-4b03-9C1F-06BA6FD97A2F'

    или, если дописать udf, такое:
    WHERE tbl.Attr = ENUM_VALUE('MyEnum', 'Value1')

    И никакого контроля, кроме check constraint в рантайме.
    В тоже время в DSL можно написать просто:
    WHERE tbl.Attr = MyEnum.Value1

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

    VD>Если библиотека решает задачу на достойном уровне, то ДСЛ — оверкил.


    +1
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[24]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 14.04.12 18:59
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>У тебя получается, что полные по Тьюрингу языки все ЯОН. Но по некоторым мутным причинам ты некоторые полные по Тьюрингу языки записываешь в ДСЛ.


    Ограничения DSL заключаются не в ограничении Тьюринг-полноты, а в ограничении внешних возможностей. Например конструировании собственных типов определенного вида, использовании внешних библиотек и т.п.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[22]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 14.04.12 18:59
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    O> Решение любой задачи вообще всегда сводится к созданию языка. Всегда. Достаточно заметить этот факт, и дальше все становится просто.


    O> Посмотрите на историю развития науки. Каждая новая теория это язык. Каждая хоть немного новая и сложная задача решается через введение нового языка. Вся математика это не более чем коллекция разнообразных языков, созданных в разное время для решения возникающих в науке задач.


    Влад верно сказал — практическая полезность всей этой философии тождественно равна 0. Под языком в DSL понимают вполне конкретный инструментарий, и не надо тут доказательствами по аналогии заниматься.

    O>если узко мыслить в терминах существующих языков то можно не заметиь, что родился новый язык.


    А зачем мыслить "широко"? Практический выхлоп из такого мышления какой?
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[21]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 14.04.12 19:02
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    AVK>>Ну давай проведем эксперимент. Вот типовой серверный бизнес-код на универсальном языке — C#. Давай ты продемонстрируешь, как все будет круто на DSL?

    WH>Это не серьезно.

    Как раз это — серьезно, коль уж вы претендуете на практическую ценность концепции. А общие слова не стоят ничего. Show me your code, как IT любит говорить.

    WH>Для того чтобы создать ДСЛ нужно садиться и анализировать предметную область.

    WH>Ибо создание ДСЛ == создание архитектуры.
    WH>Это один процесс.
    WH>Создание архитектуры даже сложнее, ибо кроме создания ДСЛ происходит еще и натягивание этого ДСЛ на ЯОН таким образом, чтобы код не превращался в говно.

    Ты мне хочешь расказать, что такое создание архитектуры и создание DSL? Спасибо, не надо. Show me your code.

    WH>Так что любой адекватный архитектор может спокойно создавать ДСЛи.


    Попробуй доказать.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[22]: Замечание от КО
    От: Курилка Россия http://kirya.narod.ru/
    Дата: 14.04.12 19:08
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

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


    AVK>>>Ну давай проведем эксперимент. Вот типовой серверный бизнес-код на универсальном языке — C#. Давай ты продемонстрируешь, как все будет круто на DSL?

    WH>>Это не серьезно.

    AVK>Как раз это — серьезно, коль уж вы претендуете на практическую ценность концепции. А общие слова не стоят ничего. Show me your code, как IT любит говорить.


    Оффтопично, но по-моему это перецитированные слова Линуса — https://lkml.org/lkml/2000/8/25/132
    Re[17]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 14.04.12 19:43
    Оценка:
    Здравствуйте, netch80, Вы писали:

    N>Я поставил ему плюс именно за грамотные и интересные комментарии о DSL для пользователей — я раньше как-то не задумывался о том, почему большинство успешных из них так похоже на Basic.


    SQL похож на бейсик? Всевозможные внутренние list comprehension или query comprehension? UML? HTML? XAML? Может XSLT?
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[20]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 14.04.12 19:43
    Оценка: +2
    Здравствуйте, Sinclair, Вы писали:

    S>Во-вторых, всё же всё не настолько плохо, как вы говорите. В новом SQL


    Я бы сказал, в "новом". SQL'99, однако, 13 лет уже тому.

    S> есть with как способ введения "табличной переменной".


    Он уродский. Ввиду старых заскоков они затолкали все это в одно выражение с мутноватыми правилами видимости внутренних имен реляций, что на читабельности сказалось далеко не лучшим образом. Куда проще было ввести, наконец, многострочность на уровне стандарта и сделать как то так:
    PARAM @Org AS CHAR(3);
    
    DEFINE
      SELECT * FROM Users WHERE UserClass='A'
      AS Admins;
      
    DEFINE
      CASE
            WHEN @Org IS NOT NULL THEN
                SELECT * FROM Users WHERE Origin=@Org
            ELSE
                SELECT * FROM Admins;
        END
    AS OrgAdmins;
    
    SELECT * FROM OrgAdmins;


    А так CTE на практике просто на редкость извратный способ получить в запросе ограниченную рекурсию.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[23]: Замечание от КО
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 14.04.12 19:43
    Оценка:
    Здравствуйте, Курилка, Вы писали:

    К>Оффтопично, но по-моему это перецитированные слова Линуса


    Я в курсе.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[22]: Языки общего назначения не имеют смысла!
    От: Jack128  
    Дата: 14.04.12 19:59
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

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


    AVK>>>Ну давай проведем эксперимент. Вот типовой серверный бизнес-код на универсальном языке — C#. Давай ты продемонстрируешь, как все будет круто на DSL?

    WH>>Это не серьезно.

    AVK>Как раз это — серьезно, коль уж вы претендуете на практическую ценность концепции. А общие слова не стоят ничего. Show me your code, как IT любит говорить.


    Ну ты тогда ты без сомнения на примере _этого_ кода покажешь преимущества ООП над процедурным программированием, не так ли??
    Re[26]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 14.04.12 20:27
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    V>>А я не про DSL, а про то, что при наличии такой возможности многие DSL вполне могут служить языками общего назначения. Даже случайно.

    S>Вы так говорите, как будто это плохо.

    Если я доверяю кусок кода непрофессионалу-бухгалтеру, то плохо, ес-но, т.к. он может банально всё уронить.


    V>>С тобой не согласен синтаксис объявления функций без определения в С и ключевое слово extern для переменных.

    S>И тем не менее, никакого способа сообщить в языке "мне нужна эта библиотека" нету.

    Вообще-то есть. Как прямо, так и косвенно.


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

    S>Простите, это чушь. Линкер всего лишь разрешает символьные имена. Никакой информации об ABI в нём нету.

    ABI — это еще форматы объектных файлов и способов кодирования информации в них. Чтобы связать имена, надо знать как их искать.


    S>И линкер не является частью языка C.


    Сорри, за ликбез, но является обширной частью спецификации. В стандарте прямо упоминается внешнее и внутреннее связывание. Упоминается термин "единица компиляции".

    Вот примеры конструкций из стандарта, которые управляют линковкой:
    namespace /* anonimous */ {
     int someInternalSymbol = 42;  // можно включить по include, и у каждой единицы компиляции будет свой экземпляр
    }
    
    extern const int x = 42; // заметь, ключевое слово extern и инициализация одновременно, почему?
    
    static void foo() {}     // что значит static для свободной ф-ии?
    static int y = 42;       // что значит static для глобальной переменной?

    Про платформенно зависимые pragma даже говорить неохота. Но справедливости ради pragma упоминается именно в исходном коде программы, а не аргументах командной строки линкера.


    S>Вы правильно помните. Итак, стал ли Лого GPPL после добавления возможности импорта библиотек на том же Лого?


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

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

    S>Я как раз ничего не путаю. В JS я тоже могу подключать любые "нейтивные" библиотеки. Если хост будет столь добр, что разрешит CreateObject(), то я могу делать всё, что угодно.

    Ну так хост не дается кем-то сверху, это именно ты хостишь JS, и ты можешь дать только то, что считаешь нужным. Я потому и использую для JS для своих инструментов в кач-ве DSL, что в нем изкаробки нет ничего, кроме голого синтаксиса, т.е. весь нужный функционал подается извне. Именно поэтому он БЕЗОПАСЕН для браузеров. Вернее, ровно наоборот — он был разработан таким, чтобы быть безопасным, поэтому такие ограничения.


    S>В С роль хоста играет линкер.


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

    Насчет твоих inp/outp. Если интересовался, то в защищенном режиме x86 порты отображены на карту виртуальной памяти. Во многих embedded-архитектрах, например PIC — точно так же без всякого защищенного режима — порты ввода-вывода лежат по специальным адресам. Но это фигня, дело-то не в порта, так? А в выполнении произвольной инструкции процессора, правильно? С/С++ чуть ли не единственные языки, где можно записать данные в некоторую область памяти (в сегмент данных, например) и передать туда управление. Так работают всякие нейтивные вирусы, писанные на С. Именно поэтому на DSL никак не тянут, т.к. подобное бывает случайно происходит даже у профессиональных программистов. И опция защиты исполнения данных тоже не глобальная ни разу, какими-нить настройками совместимости отключается аж бегом.


    V>>А для какого-нить скриптового, со встроенным типом SomeType — вовсе не факт. Потому что помимо синтаксиса важна еще семантика происходящего. И эта семантика таки входит в спецификацию языка.

    S>Ок, тогда давайте вернёмся к вопросу определений. Как мы убедились, возможность подключать библиотеки сама по себе никак не влияет на DSLность языка.

    В каком месте мы в этом убедились? На примере С/С++ никак не убедились, т.к. совокупность всех возможностей языка позволяет ему ставить раком произвольную аппаратную платформу.

    В общем, своё видение DSL я уже описывал, могу повториться. В плане императивного DSL — для меня это любой язык, который "ничего не умеет сам", т.е. "замкнут сам в себе" в своих там арифметических выражениях, типах данных, пользовательских ф-ий и т.д. Я думал, что приведенные примеры JS и LUA должны уже были полностью пояснить точку зрения. Далее. Чтобы такой ограниченный язык сделать DSL, мы подаем в процессе хостинга некую внешнюю функциональность, которая позволяет решать задачи лишь из некоей узкой области. Зачем именно так? В этом случае вероятность "всё завалить" непрофессиональным программистом прикладной логики многократно меньше, чем если дать ему куда разбежаться. Даже если речь о самом себе, когда я хочу сосредоточиться на конкретной задаче, я сам себя считаю потенциальной "обезъяной с гранатой" и хочу себя ограничить, чтобы не забивать лишний раз голову. ИМХО, вполне нормальный подход.

    Да и взять сами термины: на мой взгляд specific area отличается от general area границами и более ничем. Поэтому для меня императивный DSL — это в первую очередь ограничение области приложения, а затем уже хелперы и прочие плюшки. Например, с точностью до тонкостей синтаксиса можно этот HTML-DOM обрабатывать из какого-нить C# или С++ при подключенной соответствующей библиотеке.

    Если же DSL декларативный, то есть ничего сам не делает by-design, а только описывает данные для интерпретатора этих данных, то тут ровно наоборот: степень его безопасности никак не изменится, даже если реализовать его в виде eDSL даже внутри исходников С++ программы. Поэтому подход декларатиного DSL я спокойно использую прямо в коде С++. В этом случае DSL — это лишь подход к решению задачи, через описание условий и применения некоего "решателя" для конкретной области. Соответствующее замечание на счет ссылки, приведенной в начале ветки, уже делал:

    ... по твоей исходной ссылке непонятно, зачем там была DSL? Замени :- на какой-нить << и будет тебе щастье прямо из твоего языка программирования, будь то C# или C++. Там же просто декларация правил для решателя,

    Re[23]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 14.04.12 20:43
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    V>Грамматика SQL проста до безобразия


    Я бы так не сказал. Там местами даже в LL(k) не укладывается, LL(*) нужен.

    V> и в сети лежит множество готовых парсеров, которые расширить на свои потребности можно с пол-пинка.


    Парсер это примерно 5% потребной работы, если не меньше.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[26]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 14.04.12 20:43
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>Во-первых, тривиальна


    Я бы так не сказал. Там много интересных моментов возникает.

    S>, во-вторых, не очень много чего экономит


    Очень много экономит, как показала практика.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[23]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 14.04.12 20:44
    Оценка:
    Здравствуйте, Jack128, Вы писали:

    J>Ну ты тогда ты без сомнения на примере _этого_ кода покажешь преимущества ООП над процедурным программированием, не так ли??


    Зачем?
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[22]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 14.04.12 20:48
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    AVK>Как раз это — серьезно, коль уж вы претендуете на практическую ценность концепции. А общие слова не стоят ничего. Show me your code, как IT любит говорить.

    Покажи, как создать архитектуру вот по этому коду. Тот, что под cat.
    Re[12]: Языки общего назначения не имеют смысла!
    Автор: WolfHound
    Дата: 09.04.12

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

    Повторю еще раз: Для того чтобы сделать ДСЛ нужно проанализировать задачу. Проанализировать задачу на основе нескольких десятков строк кода невозможно.
    И ты сам это знаешь.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[20]: Языки общего назначения не имеют смысла!
    От: mrTwister Россия  
    Дата: 14.04.12 20:58
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    С этим кодом и без DSL есть куда развиваться
    лэт ми спик фром май харт
    Re[22]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 14.04.12 21:13
    Оценка:
    Здравствуйте, Tanker, Вы писали:

    T>даже в менеджед приходится спускаться на il.


    IL приходится писать, потому что до 4 версии в фреймворке не было других способов динамической кодогенерации. В 3.5 появился ExpressionTree.Compile(), а в 4 ET дополнили стейтментами.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[21]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 14.04.12 21:17
    Оценка:
    Здравствуйте, mrTwister, Вы писали:

    T>С этим кодом и без DSL есть куда развиваться


    Топик не об этом. Но расскажи.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[23]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 14.04.12 21:17
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>Покажи, как создать архитектуру вот по этому коду. Тот, что под cat.


    Ты что то перепутал. Я как раз таки не утверждаю, что спроектировать DSL легко.

    WH>ДСЛ тоже не сможешь. Ибо там уже потерялось куча информации о том, что же там происходит.


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

    WH>Повторю еще раз: Для того чтобы сделать ДСЛ нужно проанализировать задачу.


    Я с этим и не спорил. Я просто продемонстрировал, цитирую:

    1) Для сочинения DSL требуется специфичная и очень высокая квалификация. Подчеркиваю, для сочинения, а не для реализации.
    2) Современные ЯОН совсем не так уж и ужасны при умелом использовании.

    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[24]: Языки общего назначения не имеют смысла!
    От: Jack128  
    Дата: 14.04.12 21:24
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

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


    J>>Ну ты тогда ты без сомнения на примере _этого_ кода покажешь преимущества ООП над процедурным программированием, не так ли??


    AVK>Зачем?

    ну как. Ты взял произвольный кусок кода и предложил на этом примере доказать преимущество одной парадигмы программирования(не уверен, что правильно выбрал термин, не силен в теории) над другой. Я предложил сделать тоже самое.
    Re[9]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 14.04.12 21:25
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    O>Вы очень неудачно пример выбрали. В любой CAS эта задача решается именно через правила переписывания, причем крайне простые: факторизация выражения ( раскрытие скобок) и подстановка коэффициентов в готовую формулу.


    Ты про ресолвинг имен и вывод типов не забыл? Даже такая простая вещь, как свертывание константных выражений "подстановками коэффициентов в простую формулу" никак не решается.
    Ты, случаем, семантический анализ с кодогенерацией не спутал?
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[25]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 14.04.12 21:27
    Оценка:
    Здравствуйте, Jack128, Вы писали:

    AVK>>Зачем?

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

    Тебе показалось. Я всего лишь предложил показать, как мог бы выглядеть DSL.

    J>Я предложил сделать тоже самое.


    В контексте топика твое предложение абсолютно бессмысленно.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[24]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 14.04.12 21:29
    Оценка: +1
    Здравствуйте, AndrewVK, Вы писали:

    WH>>Покажи, как создать архитектуру вот по этому коду. Тот, что под cat.

    AVK>Ты что то перепутал. Я как раз таки не утверждаю, что спроектировать DSL легко.
    Ты утверждаешь, что это сложнее чем делать архитектуру на обычных языках.
    Но это не так.
    Обрати внимание я тебе не ДСЛ предложил делать.

    WH>>ДСЛ тоже не сможешь. Ибо там уже потерялось куча информации о том, что же там происходит.

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

    WH>>Повторю еще раз: Для того чтобы сделать ДСЛ нужно проанализировать задачу.

    AVK>Я с этим и не спорил. Я просто продемонстрировал, цитирую:
    AVK>

    AVK>1) Для сочинения DSL требуется специфичная и очень высокая квалификация. Подчеркиваю, для сочинения, а не для реализации.
    AVK>2) Современные ЯОН совсем не так уж и ужасны при умелом использовании.

    Да ты что издеваешься что ли?
    Я тебе про то, что задачу нужно проанализировать ты мне про квалификацию.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[26]: Языки общего назначения не имеют смысла!
    От: Jack128  
    Дата: 14.04.12 21:33
    Оценка: +2
    Здравствуйте, AndrewVK, Вы писали:

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


    AVK>>>Зачем?

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

    AVK>Тебе показалось. Я всего лишь предложил показать, как мог бы выглядеть DSL.


    на примере кода в 50 строк?? смеёшься?? Это тоже самое что предложить спроектировать иерархию классов на этих 50ти строках.
    Re[6]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 14.04.12 21:47
    Оценка:
    Здравствуйте, alex_public, Вы писали:

    _>Ну так я про то и говорю, что кругом просто "размётка". И в этом случае я невижу никакого смысла для отдельного языка под это — проще сразу генерировать в редакторе готовый код на системном языке.


    Генерировать то может и проще, а вот десериализовать его потом ...

    _>А вот если бы у нас в gui dsl можно было бы задавать хотя бы минимальные действия...


    Есть и такое. Например, WPF/XAML. Отработка на самого себя и другие контролы, а так же несложная анимация задаются декларативно прямо внутри XAML.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[25]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 14.04.12 21:49
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>>>Покажи, как создать архитектуру вот по этому коду. Тот, что под cat.

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

    Из этого никак не следует, что архитектуру сделать просто.

    AVK>>Мне кажется, приведенный кусок значительно понятнее и очевиднее. Ну и я всегда готов ответить на дополнительные вопросы.

    WH>Это он тебе кажется понятным и очевидным. Ибо ты его написал.

    Не угадал. Я его не писал. Я его даже не видел до того как в форум воткнуть.

    WH>Я тебе про то, что задачу нужно проанализировать ты мне про квалификацию.


    А вроде бы не тебе отвечал. И нигде не утверждал, что задачу анализировать не нужно.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[26]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 14.04.12 22:00
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    AVK>А вроде бы не тебе отвечал. И нигде не утверждал, что задачу анализировать не нужно.

    Ох. Ты сам-то веришь, что задачу по этому куску можно проанализировать?
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[22]: Языки общего назначения не имеют смысла!
    От: mrTwister Россия  
    Дата: 14.04.12 22:13
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    AVK>Топик не об этом. Но расскажи.


    Типичный пример лапша-кода.

    лэт ми спик фром май харт
    Re[35]: Языки общего назначения не имеют смысла!
    От: Vain Россия google.ru
    Дата: 15.04.12 04:27
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>>>И чем сложнее эти операции, тем сильнее рулит SQL.

    V>>Ну так в этом и дело, вы пытаетесь рассматривать только запросы в отрыве от всего остального куда входят сами базы данных, управление правами, пользователями, связи и отношения в таблицах, триггеры, процедуры и т.д. Сами запросы это вершина айсберга.
    S>Нет. Запросы — это всё-таки ядро. Управление правами и пользователями — это администрирование серверов баз данных.
    S>Но вы по-прежнему не понимаете одну главную вещь: скрипты SQL гораздо проще для управления БД, чем любые библиотеки на С++.
    Как я сказал уже это от базы данных зависит. Как вы к примеру собираетесь через SQL управлять реестром винды? Или файловой системой? А это ведь тоже база данных.
    S>Совершенно неважно то, что сами базы данных — это большая и сложная область. Мы сейчас не сравниваем объём предметных областей. Мы сравниваем удобство и простоту различных языков для работы в этих областях.
    Попу с пальцем сранивать бесполезно.
    [In theory there is no difference between theory and practice. In
    practice there is.]
    [Даю очевидные ответы на риторические вопросы]
    Re[27]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 15.04.12 04:29
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    V>Если я доверяю кусок кода непрофессионалу-бухгалтеру, то плохо, ес-но, т.к. он может банально всё уронить.

    Не может, если хост языка ему не позволяет.

    V>Сорри, за ликбез, но является обширной частью спецификации. В стандарте прямо упоминается внешнее и внутреннее связывание. Упоминается термин "единица компиляции".


    V>Про платформенно зависимые pragma даже говорить неохота. Но справедливости ради pragma упоминается именно в исходном коде программы, а не аргументах командной строки линкера.

    Это вы С с С++ путаете.

    S>>Вы правильно помните. Итак, стал ли Лого GPPL после добавления возможности импорта библиотек на том же Лого?

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

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

    S>>В С роль хоста играет линкер.

    V>Опять сорри за ликбез, но нет. CRT является частью языка и стандарта, позволяя писать практически что угодно без линкера.

    Я боюсь, что у вас ничего не получится без линкера.

    V>Насчет твоих inp/outp. Если интересовался, то в защищенном режиме x86 порты отображены на карту виртуальной памяти. Во многих embedded-архитектрах, например PIC — точно так же без всякого защищенного режима — порты ввода-вывода лежат по специальным адресам. Но это фигня, дело-то не в порта, так? А в выполнении произвольной инструкции процессора, правильно? С/С++ чуть ли не единственные языки, где можно записать данные в некоторую область памяти (в сегмент данных, например) и передать туда управление. Так работают всякие нейтивные вирусы, писанные на С.

    И это не имеет никакого отношения к импорту библиотек.

    V>В каком месте мы в этом убедились? На примере С/С++ никак не убедились, т.к. совокупность всех возможностей языка позволяет ему ставить раком произвольную аппаратную платформу.

    Мне нравится ваша способность начисто игнорировать весь ход обсуждения. Что мы имеем? Пример С показывает, что для постановки раком платформы библиотеки ему не нужны, да и нет в языке ничего специального про библиотеки. Пример "улучшенного Лого" показывает, что добавление библиотек никак не помогает поставить раком платформу. Но вас это не смущает.

    V>Да и взять сами термины: на мой взгляд specific area отличается от general area границами и более ничем. Поэтому для меня императивный DSL — это в первую очередь ограничение области приложения, а затем уже хелперы и прочие плюшки. Например, с точностью до тонкостей синтаксиса можно этот HTML-DOM обрабатывать из какого-нить C# или С++ при подключенной соответствующей библиотеке.

    Совершенно верно. Поэтому изо всех языков, работающих с DOM, DSL-ями являются только CSS и XSLT. JS, как и С и C++, это типичный GPPL.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[18]: Языки общего назначения не имеют смысла!
    От: netch80 Украина http://netch80.dreamwidth.org/
    Дата: 15.04.12 07:09
    Оценка:
    Здравствуйте, koodeer, Вы писали:

    K>Конечно, нечто подобное можно реализовать в ООП: создать классы Масса и Температура, переопределить операции сложения для них. Но очевиден оверхед: для простых типов данных будет использоваться класс, что и быстродействие снизит, и память жрать будет. В случае обработки миллионов значений это критично.


    Видимо, ты давно последний раз видел C++.
    Если размерность значения определена в его типе, то достаточно легко получить и контроль во время компиляции (причём оно может, например, разрешить присвоить скорости произведение ускорения на время и в то же время запретить присвоение ей массы), и в то же время единственным данным внутри класса будет значение величины — например, типа double — и после оптимизации всё это выродится в простейшие операции со скаляром с плавающей точкой.

    Попробуй сам (только на современных компиляторах, а не образца 95-го года) и удивись.

    K>А в DSL и масса и температура по-прежнему останутся после компиляции простым типом. Никакого оверхеда в рантайме!


    Для статически типизированного — да. Для динамически — нет.
    Зависит именно от типизации.
    Но можешь ли ты в DSL простым образом объявить новую размерность величины?
    Вот потребовалось тебе что-то вроде паскалей в кубе на квадратный ампер. Объявишь?
    The God is real, unless declared integer.
    Re[19]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 15.04.12 07:30
    Оценка:
    Здравствуйте, netch80, Вы писали:

    N>Для статически типизированного — да. Для динамически — нет.

    N>Зависит именно от типизации.
    N>Но можешь ли ты в DSL простым образом объявить новую размерность величины?
    N>Вот потребовалось тебе что-то вроде паскалей в кубе на квадратный ампер. Объявишь?
    Детский сад. Если уж С++ с этим справляется то ДСЛ с системой типов заточенной на это справится вообще не напрягаясь.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[20]: Языки общего назначения не имеют смысла!
    От: netch80 Украина http://netch80.dreamwidth.org/
    Дата: 15.04.12 08:53
    Оценка: :)
    Здравствуйте, WolfHound, Вы писали:

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


    N>>Для статически типизированного — да. Для динамически — нет.

    N>>Зависит именно от типизации.
    N>>Но можешь ли ты в DSL простым образом объявить новую размерность величины?
    N>>Вот потребовалось тебе что-то вроде паскалей в кубе на квадратный ампер. Объявишь?
    WH>Детский сад. Если уж С++ с этим справляется то ДСЛ с системой типов заточенной на это справится вообще не напрягаясь.

    Я не тебя спрашивал. Меня интересует именно подход koodeer'а с *его* организацией DSL'ей.
    The God is real, unless declared integer.
    Re[21]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 15.04.12 09:03
    Оценка: -1
    Здравствуйте, netch80, Вы писали:

    N>Я не тебя спрашивал. Меня интересует именно подход koodeer'а с *его* организацией DSL'ей.

    Как же быстро ты слил.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[7]: Языки общего назначения не имеют смысла!
    От: alex_public  
    Дата: 15.04.12 11:07
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    _>>Ну так я про то и говорю, что кругом просто "размётка". И в этом случае я невижу никакого смысла для отдельного языка под это — проще сразу генерировать в редакторе готовый код на системном языке.

    AVK>Генерировать то может и проще, а вот десериализовать его потом ...

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

    AVK>Есть и такое. Например, WPF/XAML. Отработка на самого себя и другие контролы, а так же несложная анимация задаются декларативно прямо внутри XAML.


    Ага, какие то элементы есть. Так же как и скажем в delphi и т.п. Но это всё только обрезки решения, захватывающие небольшую часть логики. Полноценного же решения, которор позволило бы полностью отделить интерфейс от "движка", на рынке не видно. А хотелось бы. И кстати кроме удобстваразработки такой подход мог бы принести как бонус реальную кроссплатформенность. на уровне своего интерфейса под каждую платформу (особенно актуально для софта работающего и на десктопе и на мобильных устройства).
    Re[9]: Языки общего назначения не имеют смысла!
    От: Pavel Dvorkin Россия  
    Дата: 15.04.12 11:38
    Оценка: 6 (1)
    Здравствуйте, AndrewVK, Вы писали:

    AVK>Здравствуйте, Pavel Dvorkin, Вы писали:


    PD>>Картинка размером от 3000*5000 до 5000*6000 пикселей, размер файла 15-30 Мб.

    PD>>Время на обработку — 200-300 мсек на современном процессоре. Не уложишься — считай, что задача не решена.

    AVK>Может я чего не понял в твоей задаче, но лобовое решение без всяких SSE и CUDA, типа такого:

    AVK>
    AVK>for (var y = 0; y < _height; y++)
    AVK>{
    AVK>    var line = data[y];
    AVK>    for (var x = 0; x < _width; x++)
    AVK>        line[x] = line[x] < 128 ? (byte) 0 : (byte) 1;
    AVK>}
    AVK>


    .

    http://www.djvu-soft.narod.ru/bookscanlib/024.htm
    With best regards
    Pavel Dvorkin
    Re[27]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 15.04.12 12:20
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    AVK>>А вроде бы не тебе отвечал. И нигде не утверждал, что задачу анализировать не нужно.

    WH>Ох. Ты сам-то веришь, что задачу по этому куску можно проанализировать?

    Я не прошу анализа задачи или создания архитектуры. Я прошу показать, как гипотетически можно было бы упростить такой кусок. Любые фантазии допустимы.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[23]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 15.04.12 12:20
    Оценка: :)
    Здравствуйте, mrTwister, Вы писали:

    T>*]код очень трудно читаем. что он делает и зачем он нужен понять трудно.


    Я легко прочел? И не очень понятно, что там так трудно читаемо.

    T>*]кучи даункастов


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

    T>*]кучи null'ей, которые в разных случаях имеют неявный смысл


    Непонятно. Современные БД в принципе увязаны с null.

    T>а во второй оставили низкоуровневый лапшу-код


    Почему низкоуровневый?

    T>*]напрашивается вынос из метода 3-х 4-х подпрограмм


    Зачем выносить то, что встречается ровно один раз из метода меньше экрана размером?

    T>*]Использование бессмысленных идентификаторов


    Каких именно?

    T>*]Есть подозрение на использование синглтонов: Manager, LinkManager


    Нет, это не синглтоны.

    T>*]Можно было бы обойтись без модификаций локальной переменной (cardsDeleteSet)


    Зачем?
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[8]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 15.04.12 12:42
    Оценка:
    Здравствуйте, alex_public, Вы писали:

    _>>>Ну так я про то и говорю, что кругом просто "размётка". И в этом случае я невижу никакого смысла для отдельного языка под это — проще сразу генерировать в редакторе готовый код на системном языке.

    AVK>>Генерировать то может и проще, а вот десериализовать его потом ...

    _>В том редакторе, что мы сейчас используем, данные хранятся в неком внутреннем файле проекта, со всеми настройками и т.п.


    Тогда это и есть тот самый отдельный язык.

    _>Ага, какие то элементы есть. Так же как и скажем в delphi и т.п.


    В Дельфи даже близко не. В Дельфи самый примитивизм допустим, просто подписка. А в WPF можно довольно объемную логику в XAML упихать.

    _> Но это всё только обрезки решения, захватывающие небольшую часть логики.


    Ты сперва попробуй.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[28]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 15.04.12 12:44
    Оценка: +2 -1
    Здравствуйте, AndrewVK, Вы писали:

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

    Для того чтобы его упростить нужно понять что там происходит.
    А по этому куску понять это нельзя.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[29]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 15.04.12 13:04
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>А по этому куску понять это нельзя.


    Ну, я понял.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[30]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 15.04.12 13:07
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    WH>>А по этому куску понять это нельзя.

    AVK>Ну, я понял.
    А сколько еще кода в этом проекте ты прочитал/написал/спроектировал?
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[31]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 15.04.12 13:10
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    AVK>>Ну, я понял.

    WH>А сколько еще кода в этом проекте ты прочитал/написал/спроектировал?

    В этом? 0. Я вообще прикладным кодом не занимаюсь.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[32]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 15.04.12 13:59
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    AVK>В этом? 0. Я вообще прикладным кодом не занимаюсь.

    Те ты написал и спроектировал весь системный код?
    Я правильно понял?
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[9]: Языки общего назначения не имеют смысла!
    От: Pavel Dvorkin Россия  
    Дата: 15.04.12 14:43
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>Думаю, надо писать на ассемблере. Потому как "модели" тут у предметной области нет никакой. Выполнять побайтное сравнение с константой — это ровно одна операция. Задача не в том, как эту операцию представить в более читаемом виде, а как поаккуратнее запихать данные в SSE.


    SSE тут, конечно, присутствует, (а еще присутствует распараллеливание) но вот насчет модели предметной области — не мешало бы определить, что она (в этом контексте) такое и почему ее в этой задаче нет.

    Алгоритм там намного сложнее сравнения с константой. Тот, что ты имеешь в виду (полагаю, это то же, что озвучил AndrewVK) — никуда не годится. Черный будет пиксел или белый в target — определяется не только им, но еще и квадратным окном вокруг него. Так что размерность задачи (если не продумывать эту самую модель предметной области) — N*M*K^2, где K — размер окна.
    With best regards
    Pavel Dvorkin
    Re[9]: Языки общего назначения не имеют смысла!
    От: alex_public  
    Дата: 15.04.12 14:55
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    _>> Но это всё только обрезки решения, захватывающие небольшую часть логики.

    AVK>Ты сперва попробуй.

    Ну и как мне сделать на xaml что бы по нажатию пунка меню About открывалось окно About (тоже заданное на xaml рядом)? Или что бы какой-то пункт контекстного меню был активен только если в дереве (допустим это у нас основной контрол в окне) выделен элемент?
    Re[36]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 15.04.12 16:00
    Оценка: +1
    Здравствуйте, Vain, Вы писали:
    V>Как я сказал уже это от базы данных зависит. Как вы к примеру собираетесь через SQL управлять реестром винды? Или файловой системой? А это ведь тоже база данных.
    Хорошо, раз вам неочевидно, я разжую ещё подробнее: через SQL проще управлять реляционными базами данных.
    S>>Совершенно неважно то, что сами базы данных — это большая и сложная область. Мы сейчас не сравниваем объём предметных областей. Мы сравниваем удобство и простоту различных языков для работы в этих областях.
    V>Попу с пальцем сранивать бесполезно.
    Ну, если вы хотите на таком уровне сравнивать, то я не понимаю смысла вообще дальше общение продолжать.
    А если хотите по делу — смотрите рядом комментарии коллеги vdimas-а. Он наглядно продемонстрировал, в какой ужос превращается SQL при попытке заменить его на C++. К слову, на чистом C всё будет ещё на порядок хуже.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[33]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 15.04.12 16:51
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    AVK>>В этом? 0. Я вообще прикладным кодом не занимаюсь.

    WH>Те ты написал и спроектировал весь системный код?
    WH>Я правильно понял?

    В приведенном куске нет практически никакого системного кода, он весь аккуратно спрятан. А вызовы типа DeleteObjects очевидны и недвусмысленны.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[10]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 15.04.12 16:51
    Оценка:
    Здравствуйте, alex_public, Вы писали:

    _>Ну и как мне сделать на xaml что бы по нажатию пунка меню About открывалось окно About


    Подписаться на метод вызова About

    _> (тоже заданное на xaml рядом)?


    Что значит рядом? Это уже другое окно, и смысла в xaml увязывать межоконную логику немного. Ыпрочем, при желании можно примитивный компонентик написать, который это делает.

    _> Или что бы какой-то пункт контекстного меню был активен только если в дереве (допустим это у нас основной контрол в окне) выделен элемент?


    Это без проблем.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[34]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 15.04.12 17:25
    Оценка: +1 -1
    Здравствуйте, AndrewVK, Вы писали:

    AVK>В приведенном куске нет практически никакого системного кода, он весь аккуратно спрятан. А вызовы типа DeleteObjects очевидны и недвусмысленны.

    Те ты спроектировал всю систему. И знаешь, что там за всеми этими функциями происходит.
    Какой код и по каким моделям генерируется.
    У тебя есть вся информация.
    У нас нет.
    Поэтому тебе все понятно.
    Но никто тут ничего по этому куску кода не поймет.
    Ты бы и сам ничего не понял, если бы не был архитектором всего этого дела.
    Я тоже с первого взгляда пойму, что написано на ДСЛ который сам делал.
    Так что то, что ты понимаешь этот кусок кода, ничего не значит.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[35]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 15.04.12 17:59
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

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


    Нет, не знаю. Потому что почти все функции в примере — прикладные, а не системные. Системный код занимается организацией вычислений, и в приведенном отрезке его не видно. И к DSL он уж точно отношения не имеет.

    WH>Какой код и по каким моделям генерируется.

    WH>У тебя есть вся информация.
    Эта информация для понимания кода не нужна. Совсем.

    WH>Я тоже с первого взгляда пойму, что написано на ДСЛ который сам делал.


    Так не DSL же, а обычный C#, в том то все и дело.

    WH>Так что то, что ты понимаешь этот кусок кода, ничего не значит.


    Значит значит. Попробуй привести кусочек, который ты не можешь понять, и объясни что ты в нем не понимаешь.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[20]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 15.04.12 18:19
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    AVK>Ну давай проведем эксперимент. Вот типовой серверный бизнес-код на универсальном языке — C#. Давай ты продемонстрируешь, как все будет круто на DSL?


    AVK>...


    Этот код никто кроме авторов понять не может. У вас там явно есть какая-то внутренняя модель с которой вы взаимодействуете по средствами своего АПИ. Чтобы понять код нужно не только знать АПИ, но и понимать устройство модели.

    Лучше опиши используемую у вас модель и то что с ней делает этот фрагмент кода. Тогда можно будет что-то сказать.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[37]: Языки общего назначения не имеют смысла!
    От: Vain Россия google.ru
    Дата: 15.04.12 18:23
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

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

    V>>Как я сказал уже это от базы данных зависит. Как вы к примеру собираетесь через SQL управлять реестром винды? Или файловой системой? А это ведь тоже база данных.
    S>Хорошо, раз вам неочевидно, я разжую ещё подробнее: через SQL проще управлять реляционными базами данных.
    Я фигею моя деревня. Это вам я пытался объяснить битый час. У SQL своя ниша и он далеко не панацея при работе с базами данных.

    S>>>Совершенно неважно то, что сами базы данных — это большая и сложная область. Мы сейчас не сравниваем объём предметных областей. Мы сравниваем удобство и простоту различных языков для работы в этих областях.

    V>>Попу с пальцем сранивать бесполезно.
    S>Ну, если вы хотите на таком уровне сравнивать, то я не понимаю смысла вообще дальше общение продолжать.
    S>А если хотите по делу — смотрите рядом комментарии коллеги vdimas-а. Он наглядно продемонстрировал, в какой ужос превращается SQL при попытке заменить его на C++. К слову, на чистом C всё будет ещё на порядок хуже.
    Тоже самое может произойти и с С++ при попытке заменить его на SQL. Примеры я уже привел: реестр, файловая система и т.д.
    [In theory there is no difference between theory and practice. In
    practice there is.]
    [Даю очевидные ответы на риторические вопросы]
    Re[9]: Языки общего назначения не имеют смысла?
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 15.04.12 18:24
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Ты занимаешься демагогией.


    Я бы сказал, вы все тут молодцы демагогией в той или иной степени занимаетесь Потому что обсуждение терминов почти всегда оно и есть. Правда, стоит заметить, что, почему то, топики с участием netch80 явно чаще среднего по больнице на обсуждение терминов скатываются.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[22]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 15.04.12 18:33
    Оценка: :)
    Здравствуйте, AndrewVK, Вы писали:

    K>>2.1. Я не являюсь специалистом в создании DSL.


    AVK>А таких людей вообще — просто считанное количество. That's the problem.


    Это вопрос образования и материалов по теме.

    K>>2.2. У меня нет удобных средств написания DSL.


    AVK>Причем тут средства? Я не прошу тебя написать парсер и анализатор DSL, я прошу показать, как DSL будет выглядеть.


    Дык если у человека будет средство, то он сможет найти красивое решение методом проб и ошибок (как это делается без ДСЛ-ей).

    K>> Поэтому я с такой надеждой смотрю на N2, и желаю проекту успеха.


    AVK>Удивительное дело — только что ты написал, что проблема то далеко не только в средствах. И N2 тебе тут ничем не поможет. Понимаешь, на практике я вижу, что даже сам факт осознания того, что для парсинга нужно грамматику описать для подавляющего большинства программистов отсутствует. Они неспособны даже формально описать существующий язык. Что уж говорить о сочинении собственной грамматики с нуля.


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

    AVK>И N2 необходимость создания этой самой грамматики отнюдь не отменяет, он упрощает только последующие шаги.


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

    K>>Пока что я пишу примерно такой же код.


    AVK>Ну так покажи — какой код ты хотел бы писать.


    Это нельзя сделать по твоему фрагменту. Из него не ясна модель. А без этого разговаривать не о чем.

    K>>Просто, мне кажется очевидным: вся сложность в переложении специфики бизнеса на программые конструкции заключается именно в том, что конструкции кода так и остаются кодом.


    AVK>Идея DSL это не отменяет.


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

    AVK>Бизнесмен все равно не сможет сказать на языке DSL. Потому что DSL абсолютно формален, и именно формализация задачи составляет основную сложность общения с ним. DSL решает в другом месте проблему — перевод формальной спецификации в понятные компу инструкции. Бизнесмен там уже не участвует.


    Тоже не совсем так. ДСЛ могут быть простыми. Такие ДСЛ-и можно давать и конечным пользователям. Не всем, но все же.

    Простой пример. Многие пользователи спокойно правят конфигурационные файлы приложений. А ведь это и есть ДСЛ-и!

    AVK>P.S. Пример я привел, чтобы продемонстрировать две важные вещи:

    AVK>1) Для сочинения DSL требуется специфичная и очень высокая квалификация. Подчеркиваю, для сочинения, а не для реализации.

    Это миф. Квалификация нужна для придумывания модели которая может описать задачу. А натянуть на нее ДСЛ уже довольно просто.

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

    AVK>2) Современные ЯОН совсем не так уж и ужасны при умелом использовании.


    Совсем ужасны. Единственное, что — можно делать внутренние ДСЛ-и (средствами языка) которые немного уменьшают этот ужас. Но внешние всегда будут лучше.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[21]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 15.04.12 18:44
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Этот код никто кроме авторов понять не может.


    Ну я то понял. И я, правда, не вижу ничего непонятного. Обычная бизнес-логика. Дернуть из конфигурации 1С код — будет примерно то же самое.

    VD> У вас там явно есть какая-то внутренняя модель с которой вы взаимодействуете по средствами своего АПИ. Чтобы понять код нужно не только знать АПИ, но и понимать устройство модели.


    Каждая сущность описывается обыкновенным .NET интерфейсом. Это все, что нужно знать для понимания кода.

    VD>Лучше опиши используемую у вас модель


    Вопрос непонятен

    VD> и то что с ней делает этот фрагмент кода.


    Ну вот как там написано, так все и есть

    // откатить отработку документов в ХО
    UncarryDocuments(objectsIds);


    В комментарии все сказано

    var cardsDeleteSet = new HashSet<IInventoryCardBase>();


    Вопросы есть?

    var documents = Manager.Get(objectsIds);


    Получение объектов документов по их Id. Из названий методов и переменных понятно. Одно из трех обращений к инфраструктуре (оставшиеся — Manager.DeleteObjects и ((IPersistedObject)invCardObj).Master. Смысл первого очевиден, второе — получение мастера для отношения master-detail).

    foreach (IInternalDisplacementDocument doc in documents)
        foreach (IInventoryInternalDisplacementOperation obj in doc.GetObjects())


    Цикл по каким то внутренним объектам всех документов. GetObjects это какой то прикладной метод. Можно было бы написать проще:

    Manager
      .Get(objectsIds)
      .SelectMany(doc => doc.GetObjects);


    IInventory inv = obj.GetInventory();


    Вызов какого то прикладного кода, возвращающего экземпляр IInventory.

    // Найти все связанные операции по видам учета
            IInventoryOperation[] operations = inv.GetInventoryOperations(
                null, InventoryOperationKindEnum.InternalDisplacement, (IDocument)doc, null, null, null);


    Вызов прикладного кода. Суть отражена в комментарии.

    foreach (IInventoryOperation operation in operations)


    Цикл по найденному.

    // не должно быть более поздних операций
                if (inv.GetInventoryOperations(relatedOperation.AccountingKind, null, null, null, null, null)
                        .Any(op => op.Order > relatedOperation.Order))
                    throw new BusinessException("После внутреннего перемещения не должно быть операций.");


    Проверка бизнес-ограничения.

    if (!Equals(relatedOperation.InventoryCardBefore, relatedOperation.InventoryCardAfter)
                        && !(relatedOperation.InventoryCardAfter is IAccrualAccountingInventoryCard))
                    cardsDeleteSet.Add(relatedOperation.InventoryCardAfter);


    Опять проверка бизнес-условия и добавление в хеш, если совпало

                // удалить операции
                DeleteInventoryOperation(relatedOperation);


    Вызов прикладного кода. Суть понятна из коментария.
    И т.д. Тупой и абсолютно прозрачный код без какой либо хитрой платформенной специфики. Что тут непонятно я ХЗ.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[23]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 15.04.12 18:51
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    AVK>>А таких людей вообще — просто считанное количество. That's the problem.

    VD>Это вопрос образования и материалов по теме.

    Это еще и вопрос нужного склада ума.

    AVK>>Причем тут средства? Я не прошу тебя написать парсер и анализатор DSL, я прошу показать, как DSL будет выглядеть.

    VD>Дык если у человека будет средство, то он сможет найти красивое решение методом проб и ошибок (как это делается без ДСЛ-ей).

    Я не спрашиваю про готовый DSL. Пусть это будет не совсем корректное решение, мне интересно именно на идею посмотреть.

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


    А я с этим и не спорю.

    VD>Кроме того идея ДСЛ-я еще дает в руки возможность генерировать код


    Это можно и без DSL делать в определенной степени.

    VD>Тоже не совсем так. ДСЛ могут быть простыми. Такие ДСЛ-и можно давать и конечным пользователям. Не всем, но все же.


    Ну вот мне очень хотелось бы посмотреть на то, как мог бы выглядеть DSL для бизнес логики типичной ERP системы (1С, как мы поняли, не DSL). Не нравится мой пример — можно любой другой взять, даже гипотетический. Но что то ответа нет. А именно это интересно, инструментарий для реализации уже вторичен.

    VD>Простой пример. Многие пользователи спокойно правят конфигурационные файлы приложений. А ведь это и есть ДСЛ-и!


    Если ьы мне был интересен DSL для конфигураций, я бы так и написал.

    AVK>>P.S. Пример я привел, чтобы продемонстрировать две важные вещи:

    AVK>>1) Для сочинения DSL требуется специфичная и очень высокая квалификация. Подчеркиваю, для сочинения, а не для реализации.

    VD>Это миф


    Ну так приводи пример, раз миф. С бизнес-спецификой ты, вроде как, в какой то степени знаком.

    VD>Совсем ужасны.


    Так укажи на ужасы в приведенном коде. Именно их я и хочу обсудить.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[36]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 15.04.12 19:27
    Оценка: +1
    Здравствуйте, AndrewVK, Вы писали:

    AVK>Нет, не знаю. Потому что почти все функции в примере — прикладные, а не системные. Системный код занимается организацией вычислений, и в приведенном отрезке его не видно. И к DSL он уж точно отношения не имеет.

    Системный код это потроха ДСЛя.

    WH>>Какой код и по каким моделям генерируется.

    WH>>У тебя есть вся информация.
    AVK>Эта информация для понимания кода не нужна. Совсем.
    Она нужна для создания ДСЛ.

    WH>>Я тоже с первого взгляда пойму, что написано на ДСЛ который сам делал.

    AVK>Так не DSL же, а обычный C#, в том то все и дело.
    В чем дело?
    Ты спроектировал систему.
    Ты знаешь архитектуру.
    Ты знаешь, как все выполняется.
    У тебя куча информации, которую ты используешь и даже не осознаешь этого.
    У меня этой информации нет.
    Поэтому я не смогу ни архитектуру создать, ни ДСЛ.

    AVK>Значит значит. Попробуй привести кусочек, который ты не можешь понять, и объясни что ты в нем не понимаешь.

    Я постановку задачи не понимаю. Причем постановку задачи ни на этот кусок, а ну всю систему.
    Без постановки задачи ДСЛ, как и архитектуру не сделать.

    Да ты сам поставь себя на наше место.
    Тебе дали 50 строк кода и попросили создать архитектуру.
    Куда ты пошлешь с такой просьбой?
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[22]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 15.04.12 20:07
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    VD>>Лучше опиши используемую у вас модель


    AVK>Вопрос непонятен


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

    Как бы ООП придуман для того, чтобы моделировать реальность. Ваше приложение этим и занимается. Вот эти все IDocument, IInventoryOperatio, IInventoryCardBase — это интерфейс вашей модели.

    AVK>...

    AVK>И т.д. Тупой и абсолютно прозрачный код без какой либо хитрой платформенной специфики. Что тут непонятно я ХЗ.

    Да меня не интересует описание отдельных действий. Меня интересует устройство модели — что за документы, что за инвентори (это интвентаризация или инвентарь?), что за операции? Как все это друг с другом соотносится? Каковы инварианты модели?

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

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

    То что для любой модели можно придумать язык доказано наукой. Этим занимается целый раздел математики — Теория моделей.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[24]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 15.04.12 20:35
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    VD>>Это вопрос образования и материалов по теме.


    AVK>Это еще и вопрос нужного склада ума.


    Несомненно. Кухарка не может проектировать ПО. Но тот кто может проектировать ПО, может выделять (придумывать) ДСЛ-и.

    В сотый раз повторяю: главное в ДСЛ-е — модель.

    Мало людей может придумать модель для задачи?

    AVK>Я не спрашиваю про готовый DSL.


    А я не отвечаю про готовый DSL.

    AVK>Пусть это будет не совсем корректное решение, мне интересно именно на идею посмотреть.


    Идею чего?

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


    AVK>А я с этим и не спорю.


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

    VD>>Кроме того идея ДСЛ-я еще дает в руки возможность генерировать код


    AVK>Это можно и без DSL делать в определенной степени.


    Ну, да. На самом деле для генерации важен не DSL (язык), а модель. А модель как раз можно и без DSL-я описать и использовать. Вот только для генерации кода модель нужно иметь до рантайма. Иначе не почему будет этот самый код генерировать. А где ее взять? DSL отличный способ "загрузить" модель когда угодно (в том числе и при компиляции или развертывании). Вот и получается, что хотя сам DSL не является необходимым для генерации кода, но он все же способствует применению этой техники.

    VD>>Тоже не совсем так. ДСЛ могут быть простыми. Такие ДСЛ-и можно давать и конечным пользователям. Не всем, но все же.


    AVK>Ну вот мне очень хотелось бы посмотреть на то, как мог бы выглядеть DSL для бизнес логики типичной ERP системы (1С, как мы поняли, не DSL). Не нравится мой пример — можно любой другой взять, даже гипотетический. Но что то ответа нет. А именно это интересно, инструментарий для реализации уже вторичен.


    Ну, предположим можно придумать DSL который бы позволил бы описать некие правила контроля конкретного документа. Что-то вроде:
    Sum > 10000 => Operator mast be Supervisor 
    Client is PreferredPartner => UsePrice(3)

    Далее помещаем эти правила в файл и позволяем пользователям изменять его. Ну, и используем эти правила при сохранении документа.

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

    VD>>Простой пример. Многие пользователи спокойно правят конфигурационные файлы приложений. А ведь это и есть ДСЛ-и!


    AVK>Если ьы мне был интересен DSL для конфигураций, я бы так и написал.


    А нет никакой разница для чего ДСЛ. Проме того почти все ДСЛ используются для конфигурации. Скажем грамматика — это конфигурация для парсера. Описание КА — это конфигурация для машины состояний. Бизнес-правила — это конфигурация для движка проверки бизнес-правил.

    AVK>Ну так приводи пример, раз миф. С бизнес-спецификой ты, вроде как, в какой то степени знаком.


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

    VD>>Совсем ужасны.


    AVK>Так укажи на ужасы в приведенном коде. Именно их я и хочу обсудить.


    Ужасы заключается в том, что в коде моного деталей реализации не относящихся к делу. Куча приведений типов. Вызовов АПИ и т.п. Я чую, что большая часть из приведенного лишняя. Но не зная модели я не могу сказать как оно должно было бы быть.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[25]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 15.04.12 21:22
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>В сотый раз повторяю: главное в ДСЛ-е — модель.


    Да хоть в двухсотый. Обоснования будут?

    AVK>>Пусть это будет не совсем корректное решение, мне интересно именно на идею посмотреть.


    VD>Идею чего?


    DSL для такого домена

    VD>Ну, предположим можно придумать DSL который бы позволил бы описать некие правила контроля конкретного документа. Что-то вроде:

    VD>
    VD>Sum > 10000 => Operator mast be Supervisor 
    VD>Client is PreferredPartner => UsePrice(3)
    VD>

    VD>Далее помещаем эти правила в файл и позволяем пользователям изменять его. Ну, и используем эти правила при сохранении документа.

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

    AVK>>Если ьы мне был интересен DSL для конфигураций, я бы так и написал.


    VD>А нет никакой разница для чего ДСЛ.


    Кому нет никакой разницы? Лично мне разница есть.

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


    Это софистика

    VD>Выше я привел пример гипотетических бизнес-правил


    Совершенно непонятный. При этом куча подробностей про файлы и моменты сохранения.

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


    Я до сих пор не понимаю, о чем речь.

    AVK>>Так укажи на ужасы в приведенном коде. Именно их я и хочу обсудить.


    VD>Ужасы заключается в том, что в коде моного деталей реализации не относящихся к делу.


    Каких именно? Конкретно.

    VD> Куча приведений типов. Вызовов АПИ и т.п.


    Нет там никакой кучи.

    VD> Я чую, что большая часть из приведенного лишняя.


    Кроме твоего чутья — есть что нибудь, что можно обсуждать?
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[37]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 15.04.12 21:22
    Оценка: 53 (4) +1
    Здравствуйте, WolfHound, Вы писали:

    AVK>>Нет, не знаю. Потому что почти все функции в примере — прикладные, а не системные. Системный код занимается организацией вычислений, и в приведенном отрезке его не видно. И к DSL он уж точно отношения не имеет.

    WH>Системный код это потроха ДСЛя.

    Какого DSLя? Ты о чем вообще?

    AVK>>Эта информация для понимания кода не нужна. Совсем.

    WH>Она нужна для создания ДСЛ.

    Почему? Как изменится DSL, если что то в конкретном примере системного (там ровно три точки) изменится? Давай поконкретнее.

    WH>>>Я тоже с первого взгляда пойму, что написано на ДСЛ который сам делал.

    AVK>>Так не DSL же, а обычный C#, в том то все и дело.
    WH>В чем дело?

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

    WH>У тебя куча информации, которую ты используешь и даже не осознаешь этого.


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

    WH>Поэтому я не смогу ни архитектуру создать, ни ДСЛ.


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

    AVK>>Значит значит. Попробуй привести кусочек, который ты не можешь понять, и объясни что ты в нем не понимаешь.

    WH>Я постановку задачи не понимаю.

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

    WH> Причем постановку задачи ни на этот кусок, а ну всю систему.


    Какую такую всю систему? У тебя DSL обязательно зависит от реализации конкретной системы? А мне всегда казалось, что DSL должны быть более менее универсально применимы в рамках D этого самого DSL. Так как ценность отраслевых языков в том и заключается, что построены они в рамках отрасли и понятны для всех, кто к отрасли имеет непосредственное отношение. А тут оказывается, что не зная досконально архитектуру конкретной реализации, даже предположить о том, как мог бы выглядеть такой DSL, нельзя. Интересно девки пляшут.

    WH>Без постановки задачи ДСЛ, как и архитектуру не сделать.


    Т.е. для разработки DSL обязательно нужна архитектура конкретной системы, так? Т.е., к примеру, создать SQL нельзя, не зная архитектуру конкретно MSSQL?

    WH>Да ты сам поставь себя на наше место.


    Я, кажется, уже писал здесь, что регулярно это делаю. И никаких архитектур мне, обычно, знать не надо. Архитектуры наоборот, приспосабливаются под DSL, потому что DSL первичен.
    Вот, к примеру, вся реализация языка запросов, который я здесь приводил, находится в одной сборке, которая не ссылается ни на одну сборку платформы. Т.е. даже реализация DSL никак не учитывает какую либо специфику системы, не говоря уж о его (DSL) дизайне. И это, кстати, позволило легко применить его там, где его применять изначально не планировалось. А что было бы, если бы он оказался заточен на конкретную архитектуру?

    WH>Тебе дали 50 строк кода и попросили создать архитектуру.


    В 100500 раз — я не просил создавать архитектуру. То, что для демонстрации преимуществ DSL нужна полная архитектура всей системы, где он будет применяться — это твои личные теории. Моя практика эти теории не подтверждает.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[23]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 15.04.12 21:22
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    AVK>>Вопрос непонятен


    VD>Вот в этом все и дело. Если ты не понимаешь, что такое модель предметной области в приложении


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

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


    Да без проблем могу привести. Только непонятно, чем это тебе поможет.
    public interface IInternalDisplacementDocument : IDocument
    {
        /// <summary>
        /// Вернуть дату операции
        /// </summary>
        /// <param name="accountingKind">Вид учета</param>
        /// <returns>Дата</returns>
        Date GetOperationDate(IAccountingKind accountingKind);
    
        /// <summary>
        /// Вернуть коллекцию объектов
        /// </summary>
        /// <returns>Коллекция объектов</returns>
        IInventoryInternalDisplacementOperation[] GetObjects();
    
        /// <summary>
        /// Вернуть МОЛ получатель
        /// </summary>
        /// <returns>МОЛ</returns>
        IMateriallyResponsiblePerson GetReceiverMateriallyResponsiblePerson();
    
        /// <summary>
        /// Вернуть МОЛ сдатчик
        /// </summary>
        /// <returns>МОЛ</returns>
        IMateriallyResponsiblePerson GetDelivererMateriallyResponsiblePerson();
    
        /// <summary>
        /// Вернуть структурное подразделение получатель
        /// </summary>
        /// <returns>Структурное подразделение</returns>
        IStructuralSubdivision GetReceiverSubdivision();
    
        /// <summary>
        /// Вернуть структурное подразделение сдатчик
        /// </summary>
        /// <returns>Структурное подразделение</returns>
        IStructuralSubdivision GetDelivererSubdivision();
    }
    
    /// <summary>
    /// Операция по внутреннему перемещение инвентарного объекта
    /// </summary>
    public interface IInventoryInternalDisplacementOperation
    {
        /// <summary>
        /// Вернуть Инвентарный объект
        /// </summary>
        /// <returns>Инвентарный объект</returns>
        IInventory GetInventory();
    }
    
    /// <summary>
    /// Операции
    /// </summary>
    public interface IInventoryOperation
    {
        /// <summary>
        /// Балансовая стоимость
        /// </summary>
        InventorySum BookValue
        {get; set;}
    
        /// <summary>
        /// Вид операции
        /// </summary>
        InventoryOperationKind OperationKind
        {get; set;}
    
        /// <summary>
        /// Дата операции
        /// </summary>
        Parus.Business.Date Date
        {get; set;}
    
        /// <summary>
        /// Начисленная амортизация
        /// </summary>
        InventorySum AddedAmortisation
        {get; set;}
    
        /// <summary>
        /// Остаточная стоимость
        /// </summary>
        InventorySum ResidualValue
        {get; set;}
    
        /// <summary>
        /// Порядковый номер операции
        /// </summary>
        Parus.Business.Order Order
        {get; set;}
    
        /// <summary>
        /// Срок полезного использования
        /// </summary>
        UsefulLife UsefullLife
        {get; set;}
    
        /// <summary>
        /// Вид учета
        /// </summary>
        Parus.Business.Accounting.Core.IAccountingKind AccountingKind
        {get; set;}
    
        /// <summary>
        /// Документ
        /// </summary>
        Parus.Business.IDocument Document
        {get; set;}
    
        /// <summary>
        /// МОЛ до изменения
        /// </summary>
        Parus.Business.IMateriallyResponsiblePerson OriginalMateriallyResponsiblePerson
        {get; set;}
    
        /// <summary>
        /// Объект в документе, который соответствует операции над инвентарным объектом
        /// </summary>
        object DocumentObject
        {get; set;}
    
        /// <summary>
        /// Ссылка на актуальное состояние объекта после операции
        /// </summary>
        IInventory ActualObject
        {get; set;}
    
        /// <summary>
        /// Структурное подразделение до изменения
        /// </summary>
        Parus.Business.IStructuralSubdivision OriginalStructuralSubdivision
        {get; set;}
    
        /// <summary>
        /// Местоположение инвентарного объекта
        /// </summary>
        IInventoryLocation Location
        {get; set;}
    
        /// <summary>
        /// Начальное состояние инвентарного объекта
        /// </summary>
        IInventory InitialObject
        {get; set;}
    
        /// <summary>
        /// Операция-основание
        /// </summary>
        IInventoryOperation BaseOperation
        {get; set;}
    
        /// <summary>
        /// Карточка до операции
        /// </summary>
        IInventoryCardBase InventoryCardBefore
        {get; set;}
    
        /// <summary>
        /// Карточка после операции
        /// </summary>
        IInventoryCardBase InventoryCardAfter
        {get; set;}
    }
    
    /// <summary>
    /// Инвентарный объект
    /// </summary>
    public interface IInventory
    {
        /// <summary>
        /// Атрибуты инвентарного объекта по видам учета
        /// </summary>
        IInventoryAttributesDetailCollection Attributes
        {get;}
        
        /// <summary>
        /// Комплект
        /// </summary>
        IInventorySetDetailCollection Set
        {get;}
    
        /// <summary>
        /// Возвращает операции над ИО
        /// </summary>
        /// <param name="accountingKind">Вид учета. Если null, то не учитывается.</param> 
         /// <param name="operationKind">Вид операции над ИО. Если null, то не учитывается.</param> 
         /// <param name="document">Документ. Если null, то не учитывается.</param> 
         /// <param name="startPeriod">Начало периода. Если null, то не учитывается.</param> 
         /// <param name="endPeriod">Окончание периода. Если null, то не учитывается.</param> 
         /// <param name="baseOperation">Операция-основание. Если null, то не учитывается.</param> 
         Parus.Business.InventoryAccounting.IInventoryOperation[] GetInventoryOperations(Parus.Business.Accounting.Core.IAccountingKind accountingKind, Parus.Business.InventoryAccounting.InventoryOperationKind operationKind, Parus.Business.IDocument document, Parus.Business.Date startPeriod, Parus.Business.Date endPeriod, Parus.Business.InventoryAccounting.IInventoryOperation baseOperation);
         
        /// <summary>
        /// Возвращает дату принятия к учету
        /// </summary>
        Parus.Business.Date GetAdoptionToAccountingDate();
        
        /// <summary>
        /// Возвращает карточку, в которую включен ИО
        /// </summary>
        Parus.Business.InventoryAccounting.IInventoryCardBase GetInventoryCard();
        
        /// <summary>
        /// Скопировать поля ИО источника в текущий ИО
        /// </summary>
        /// <param name="source">Инвентарный объект - источник</param> 
         /// <param name="sourceAttr">Инвентарный объект - источник атрибутов</param> 
    
        void Copy(Parus.Business.InventoryAccounting.IInventory source, Parus.Business.InventoryAccounting.IInventory sourceAttr);
        /// <summary>
        /// Создать атрибуты по виду учета
        /// </summary>
        /// <param name="accountingKind">Вид учета. Не может быть null.</param> 
        Parus.Business.InventoryAccounting.IInventoryAttributes CreateAttributes(Parus.Business.Accounting.Core.IAccountingKind accountingKind);
        
        /// <summary>
        /// Установить новый автогенеренный инвентарный номер
        /// </summary>
        void SetNewNumber();
        
        /// <summary>
        /// Возвращает ИО в карточке (объект-спецификацию)
        /// </summary>
        Parus.Business.InventoryAccounting.IInventoryCardObject GetInventoryCardObject();
        
        /// <summary>
        /// Получить объект обеспечения уникальности для инвентарного объекта
        /// </summary>
        Parus.Business.InventoryAccounting.IInventoryUnique GetInventoryUnique();
        
        /// <summary>
        /// Получить фактический срок эксплуатации на дату
        /// </summary>
        /// <param name="date">Дата</param> 
         Parus.Business.Counter GetActualUsefulLife(Parus.Business.Date date);
         
        /// <summary>
        /// Проверка соответствия учетной политике
        /// </summary>
        /// <param name="date">Дата</param> 
         /// <param name="cardType">Тип карточки</param> 
         string CheckPolicy(Parus.Business.Date date, Parus.Business.ClassRefDomain cardType);
         
        /// <summary>
        /// Установить новый автогенеренный инвентарный номер
        /// </summary>
        void SetNewNumber2(string lastNumber);
    
        #region Physical Attributes
        /// <summary>
        /// Дата выпуска
        /// </summary>
        Parus.Business.Date ReleaseDate
        {get; set;}
    
        /// <summary>
        /// Дата государственной регистрации
        /// </summary>
        Parus.Business.Date StateRegistrationDate
        {get; set;}
    
        /// <summary>
        /// Дополнительный идентификатор инвентарного объекта без инвентарного номера
        /// </summary>
        Parus.Business.DomainGuid AdditionalId
        {get; set;}
    
        /// <summary>
        /// Заводской номер
        /// </summary>
        SerialNumber SerialNumber
        {get; set;}
    
        /// <summary>
        /// Изготовитель
        /// </summary>
        Vendor Vendor
        {get; set;}
    
        /// <summary>
        /// Инвентарный номер
        /// </summary>
        InventoryNumber InventoryNumber
        {get; set;}
    
        /// <summary>
        /// Количество
        /// </summary>
        InventoryQuantity Quantity
        {get; set;}
    
        /// <summary>
        /// Модель, марка
        /// </summary>
        InventoryBrand Brand
        {get; set;}
    
        /// <summary>
        /// Номер паспорта
        /// </summary>
        InventoryPassportNumber PassportNumber
        {get; set;}
    
        /// <summary>
        /// Ограничения распоряжением с активами
        /// </summary>
        AssetsManagementRestrictions ManagementLimitations
        {get; set;}
    
        /// <summary>
        /// Префикс
        /// </summary>
        InventoryNumberPrefix Prefix
        {get; set;}
    
        /// <summary>
        /// Примечание
        /// </summary>
        Parus.Business.Note Note
        {get; set;}
    
        /// <summary>
        /// Регистрационный номер
        /// </summary>
        RegistrationNumber RegistrationNumber
        {get; set;}
    
        /// <summary>
        /// Факт государственной регистрации
        /// </summary>
        StateRegistrationFact StateRegistration
        {get; set;}
    
        /// <summary>
        /// Этикетка (дата)
        /// </summary>
        Parus.Business.Date LabelDate
        {get; set;}
    
        /// <summary>
        /// Этикетка (штрих-код)
        /// </summary>
        BarCode LabelBarCode
        {get; set;}
    
        /// <summary>
        /// Амортизационная группа-подгруппа
        /// </summary>
        IDepreciationGroup DepreciationGroup
        {get; set;}
    
        /// <summary>
        /// Вид НФА
        /// </summary>
        IInventoryObjectGroup Group
        {get; set;}
    
        /// <summary>
        /// История изменений
        /// </summary>
        IInventory ChangesHistory
        {get; set;}
    
        /// <summary>
        /// Код ОКОФ
        /// </summary>
        IOkof Okof
        {get; set;}
    
        /// <summary>
        /// МОЛ
        /// </summary>
        Parus.Business.IMateriallyResponsiblePerson MateriallyResponsiblePerson
        {get; set;}
    
        /// <summary>
        /// Номенклатура
        /// </summary>
        INomenclator Nomenclature
        {get; set;}
    
        /// <summary>
        /// Организация
        /// </summary>
        Parus.Business.IServedOrganization Organization
        {get; set;}
    
        /// <summary>
        /// Структурное подразделение
        /// </summary>
        Parus.Business.IStructuralSubdivision StructuralSubdivision
        {get; set;}
    
        /// <summary>
        /// Регистрирующий орган
        /// </summary>
        Parus.Business.IJuridicalPerson RegistrationAgency
        {get; set;}
    
        /// <summary>
        /// Местоположение инвентарного объекта
        /// </summary>
        IInventoryLocation Location
        {get; set;}
    
        /// <summary>
        /// Начальное состояние инвентарного объекта
        /// </summary>
        IInventory InitialState
        {get; set;}
    
        /// <summary>
        /// Сквозная аналитика
        /// </summary>
        Parus.Business.IThroughAnalytics ThroughAnalytics
        {get; set;}
    
        /// <summary>
        /// Ссылка на каталог
        /// </summary>
        Parus.Net.Server.ISystemCatalog Catalog
        {get; set;}
    
        /// <summary>
        /// Имя ИО (из номенклатуры)
        /// </summary>
         Parus.Business.Name Name
        {get;}
    
        /// <summary>
        /// Дата принятия к учету по бух. виду учета
        /// </summary>
         Parus.Business.Date AdoptionToAccountingDate
        {get;}
    
        /// <summary>
        /// Строковое представление ИО
        /// </summary>
         Parus.Business.Text InventoryString
        {get;}
    
        /// <summary>
        /// Отображаемое имя
        /// </summary>
         Parus.Business.Text DisplayName
        {get;}
    }
    
    /// <summary>
    /// Объект ОС
    /// </summary>
    public interface IInventoryCardObject
    {
        /// <summary>
        /// Порядковый номер
        /// </summary>
        Parus.Business.Order Order
        {get; set;}
    
        /// <summary>
        /// Инвентарный объект
        /// </summary>
        IInventory Inventory
        {get; set;}
    }
    
    /// <summary>
    /// Сервис для работы со связями между объектами.
    /// </summary>
    public interface ILinkManager
    {
        /// <summary>
        /// Создать связь между объектами.
        /// </summary>
        /// <param name="source">Персистентный объект - источник связи.</param>
        /// <param name="target">Персистентный объект - приемник связи.</param>
        /// <param name="role">Роль связи.</param>
        /// <param name="data">Персистентный объект - данные связи.</param>
        void Link(IPersistedObject source, IPersistedObject target, Guid role, IPersistedObject data);
    
        /// <summary>
        /// Разорвать связь между объектами.
        /// </summary>
        /// <param name="source">Персистентный объект - источник связи.</param>
        /// <param name="target">Персистентный объект - приемник связи.</param>
        /// <param name="role">Роль связи.</param>
        void UnLink(IPersistedObject source, IPersistedObject target, Guid role);
    
        /// <summary>
        /// Получить все исходящие связи для данного объекта
        /// </summary>
        IObjectLink[] GetAllInLinks(IObjectIdentity obj);
    
        /// <summary>
        /// Получить все входящие связи для данного объекта
        /// </summary>
        IObjectLink[] GetAllOutLinks(IObjectIdentity obj);
    
        /// <summary>
        /// Существует ли связь с указанной ролью между объектами?
        /// </summary>
        /// <param name="source">Персистентный объект - источник связи.</param>
        /// <param name="target">Персистентный объект - приемник связи.</param>
        /// <param name="role">Роль связи.</param>
        /// <returns><c>true</c>, если связь имеется, иначе <c>false</c>.</returns>
        bool IsLinkExists(IPersistedObject source, IPersistedObject target, Guid role);
    
        /// <summary>
        /// Метод возвращает связь, если объекты связаны связью с указанной ролью, 
        /// либо <b>null</b>, если такой связи нет.
        /// </summary>
        /// <param name="source">Персистентный объект - источник связи.</param>
        /// <param name="target">Персистентный объект - приемник связи.</param>
        /// <param name="role">Роль связи.</param>
        IObjectLink GetLink(IPersistedObject source, IPersistedObject target, Guid role);
    
        /// <summary>
        /// Получить прикрепленные к связи данные.
        /// </summary>
        /// <param name="source">Персистентный объект - источник связи.</param>
        /// <param name="target">Персистентный объект - приемник связи.</param>
        /// <param name="role">Роль связи.</param>
        /// <returns>Персистентный объект с данными, если связь имеется, иначе <b>null</b>.</returns>
        IPersistedObject GetLinkData(IPersistedObject source, IPersistedObject target, Guid role);
    
        /// <summary>
        /// Проверяет есть ли связи <paramref name="role"/> от объекта <paramref name="source"/>.
        /// </summary>
        /// <param name="source">Источник</param>
        /// <param name="role">Роль</param>
        /// <returns><c>true</c>, если связь имеется, иначе <c>false</c>.</returns>
        bool SourceHasLinks(IPersistedObject source, Guid role);
    
        /// <summary>
        /// Проверяет есть ли связи <paramref name="role"/> к объекту <paramref name="target"/>.
        /// </summary>
        /// <param name="target">Цель связи</param>
        /// <param name="role">Роль</param>
        /// <returns><c>true</c>, если связь имеется, иначе <c>false</c>.</returns>
        bool TargetHasLinks(IPersistedObject target, Guid role);
    
        /// <summary>
        /// Возвращает список связей <paramref name="role"/> от объекта <paramref name="source"/>.
        /// </summary>
        /// <param name="source">Источник</param>
        /// <param name="role">Роль</param>
        /// <returns>Список связей, либо пустой список, если связей нет.</returns>
        IEnumerable<IObjectLink> GetLinksFromSource(IPersistedObject source, Guid role);
    
        /// <summary>
        /// Возвращает список связей <paramref name="role"/> к объекту <paramref name="target"/>.
        /// </summary>
        /// <param name="target">Цель связи</param>
        /// <param name="role">Роль</param>
        /// <returns>Список связей, либо пустой список, если связей нет.</returns>
        IEnumerable<IObjectLink> GetLinksToTarget(IPersistedObject target, Guid role);
    
        /// <summary>
        /// Возвращает список ролей связей, которые идут от объекта <paramref name="source"/>.
        /// </summary>
        /// <param name="source">Источник связи</param>
        /// <returns>Массив ролей/пустой массив</returns>
        IEnumerable<Guid> GetSourceRoles(IPersistedObject source);
    
        /// <summary>
        /// Возвращает список ролей связей, которые идут к объекту <paramref name="target"/>.
        /// </summary>
        /// <param name="target">Цель связи</param>
        /// <returns>Массив ролей/пустой массив</returns>
        IEnumerable<Guid> GetTargetRoles(IPersistedObject target);
    
        /// <summary>
        /// Получить source-объект по связи
        /// </summary>
        /// <param name="target">Цель связи</param>
        /// <param name="role">Роль</param>
        /// <returns>Объект</returns>
        IEnumerable<IPersistedObject> GetSources(IPersistedObject target, Guid role);
    
        /// <summary>
        /// Получить target-объект по связи
        /// </summary>
        /// <param name="source">Источник связи</param>
        /// <param name="role">Роль</param>
        /// <returns>Объект</returns>
        IEnumerable<IPersistedObject> GetTargets(IPersistedObject source, Guid role);
    }


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

    VD>То что для любой модели можно придумать язык доказано наукой.


    Только вопрос не в этом.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[30]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 15.04.12 21:35
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    WH>>А по этому куску понять это нельзя.


    AVK>Ну, я понял.


    А я — нет.

    А классы и интерфейсы ты проектировал? Или знаком с ними?
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[31]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 15.04.12 21:41
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>А классы и интерфейсы ты проектировал? Или знаком с ними?


    На оба вопроса — нет. Просто выдернул первый попавшийся кусок, который показался мне максимально простым для понимания.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[22]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 15.04.12 21:52
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    VD>>Этот код никто кроме авторов понять не может.


    AVK>Ну я то понял.


    А ты найди на этом форуме еще одного человека который бы понял этот код, но не работал бы в Парусе.

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

    Ты бы описал бы, что делает этот код. А то я в этой лапше имею слишком много вопросов, чтобы понять ее.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[26]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 15.04.12 22:52
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    VD>>В сотый раз повторяю: главное в ДСЛ-е — модель.


    AVK>Да хоть в двухсотый. Обоснования будут?


    Язык — это синтаксис. Интерпретация языка (синтаксиса) есть семантика. Семантика в программах обычно выражается в виде модели.

    Например, модель парсера Н2 описана вот здесь. Она состоит из ряда подмоделей. Например, модель правила грамматики описана здесь.

    Язык описывающий парсер всего лишь наполняет модель конкретным содержимым (описанием языка).

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

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

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

    AVK>>>Пусть это будет не совсем корректное решение, мне интересно именно на идею посмотреть.


    VD>>Идею чего?


    AVK>DSL для такого домена


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

    AVK>Ты опять скатываешься на реализацию? Как эти правила опишут логику наподобие той, что приведена в моем примере?


    Ты просил пример "возможно выдуманный". Я тебе дал выдуманный пример. К логике приведенной в твоем примере мой пример не имеет никакого отношения. Понять логику твоего примера я не в силах. А ты явно не намерен ее объяснять. Вместо описания модели ты мне тут выкатил какие-то странные описания отдельных действий. Причем даже эти описания мало чего объясняют.

    AVK>Кому нет никакой разницы? Лично мне разница есть.


    Лично ты просто не понимаешь природу ДСЛ-ей. Что забавно ты сам их делал, но природу так и не понял.

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


    AVK>Это софистика


    Это правда. ДСЛ не что иное как средство конфигурирования модели. А это и есть конфиги, по большому счету.

    VD>>Выше я привел пример гипотетических бизнес-правил


    AVK>Совершенно непонятный. При этом куча подробностей про файлы и моменты сохранения.


    А давай спросим всех тех кто не понял твоего кода, понятен ли им мой ДСЛ? Уверен, что мой ДСЛ поймут куда больше людей чем твой "понятный" тебе код.

    Даже если код не ясен, мне не составит труда объяснить семантику. А вот объяснить семантику привденной тобой лапши будет невозможно без описания всех используемых типов (модели).

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


    AVK>Я до сих пор не понимаю, о чем речь.


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

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

    VD>>Ужасы заключается в том, что в коде моного деталей реализации не относящихся к делу.


    AVK>Каких именно? Конкретно.


    Например, вот эти строки:
    UncarryDocuments(objectsIds);
    var cardsDeleteSet = new HashSet<IInventoryCardBase>();
    var documents = Manager.Get(objectsIds);

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

    VD>> Куча приведений типов. Вызовов АПИ и т.п.


    AVK>Нет там никакой кучи.


    Там ужасная лапша. И только ты, привыкший к ней, не можешь (не хочешь) этого заметить. А ведь тебе уже человека 4 сказали это.

    VD>> Я чую, что большая часть из приведенного лишняя.


    AVK>Кроме твоего чутья — есть что нибудь, что можно обсуждать?


    Конечно! Опиши модель на базе которой построена эта лапша и я обязательно постараюсь написать код достаточный для решения проблемы.

    Но, ты меня уж извини. Отвечать еще на одно сообщения в стиле "да там все ОК... да там все очевидно..." я не буду. Если тебе интересен ответ, то потрудись описать все объекты участвующие в коде, все связи между ними, и опиши почему все именно так.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[24]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 15.04.12 22:58
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

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


    Это уже лучше. Только это все еще очень поверхностное описание интерефейса модели. А нужна конкретика. Опиши зачем нужны эти сущности. Каковы между ними связи...

    Ну, и в двух словах опиши что же делала та замечательная простыня кода. Ведь она явно делала что-то не сложное. Да? Там что-то откуда-то удалялось. Вот и объясни: что, откуда, зачем и по каким правилам.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[27]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 15.04.12 23:36
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    AVK>>DSL для такого домена


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


    Возьми другой кусок.

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


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

    VD>Ты просил пример "возможно выдуманный". Я тебе дал выдуманный пример.


    Где он?

    AVK>>Кому нет никакой разницы? Лично мне разница есть.


    VD>Лично ты просто не понимаешь природу ДСЛ-ей.


    О, началось. Собственно, все разговоры с тобой так и заканчиваются.

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

    AVK>>Я до сих пор не понимаю, о чем речь.

    VD>О ОО-модели твоего приложения


    Она задается пользователем и не может учитываться в DSL.

    AVK>>Каких именно? Конкретно.


    VD>Например, вот эти строки:

    VD>
    VD>UncarryDocuments(objectsIds);
    VD>var cardsDeleteSet = new HashSet<IInventoryCardBase>();
    VD>var documents = Manager.Get(objectsIds);
    VD>

    VD>не имеют никакого отношения к решаемой задачи. Это чисты болерплэйт.

    Первая строка — нет. Это бизнес-операция.

    VD> Вызван он тем, что описание ведется не на подходщем для этого языке, а на универсальном зыке с использованием АПИ.


    Как это могло бы выглядеть на подходящем языке?

    VD> Ну, и такого кода в этом примере большая часть.


    Но привести ты смог только один момент?

    VD>>> Куча приведений типов. Вызовов АПИ и т.п.


    AVK>>Нет там никакой кучи.


    VD>Там ужасная лапша.


    Это все опять ни о чем.

    VD> И только ты, привыкший к ней, не можешь (не хочешь) этого заметить.


    Я к ней не привыкший.

    VD> А ведь тебе уже человека 4 сказали это.


    А чего не 8?

    AVK>>Кроме твоего чутья — есть что нибудь, что можно обсуждать?


    VD>Конечно!


    Где оно?

    VD> Опиши модель на базе которой построена эта лапша и я обязательно постараюсь написать код достаточный для решения проблемы.


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


    VD>Но, ты меня уж извини. Отвечать еще на одно сообщения в стиле "да там все ОК... да там все очевидно..." я не буду. Если тебе интересен ответ, то потрудись описать все объекты участвующие в коде, все связи между ними, и опиши почему все именно так.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[25]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 15.04.12 23:36
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Это уже лучше.


    Напоминаю — речь о DSL. Который не может быть завязан на конкретную приведенную модель. Потому что это как при проектировании SQL учитывать конкретные таблицы конкретного решения.

    VD> Только это все еще очень поверхностное описание интерефейса модели. А нужна конкретика.


    Это все, что есть в системе.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[23]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 15.04.12 23:36
    Оценка: :)
    Здравствуйте, VladD2, Вы писали:

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


    Вобщем, все понятно. Результата 0. Что и ожидалось. Одни разговоры ни о чем.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[38]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 16.04.12 02:33
    Оценка:
    Здравствуйте, Vain, Вы писали:

    S>>Хорошо, раз вам неочевидно, я разжую ещё подробнее: через SQL проще управлять реляционными базами данных.

    V>Я фигею моя деревня. Это вам я пытался объяснить битый час. У SQL своя ниша и он далеко не панацея при работе с базами данных.
    Ну, значит так объясняли.

    S>>А если хотите по делу — смотрите рядом комментарии коллеги vdimas-а. Он наглядно продемонстрировал, в какой ужос превращается SQL при попытке заменить его на C++. К слову, на чистом C всё будет ещё на порядок хуже.

    V>Тоже самое может произойти и с С++ при попытке заменить его на SQL. Примеры я уже привел: реестр, файловая система и т.д.
    А чего ж не привести сразу решение линейных уравнений или 3d-rendering?
    Потому-то SQL и DSL, что он хорошо подходит для своего домена.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[39]: Языки общего назначения не имеют смысла!
    От: Vain Россия google.ru
    Дата: 16.04.12 03:55
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>>>А если хотите по делу — смотрите рядом комментарии коллеги vdimas-а. Он наглядно продемонстрировал, в какой ужос превращается SQL при попытке заменить его на C++. К слову, на чистом C всё будет ещё на порядок хуже.

    V>>Тоже самое может произойти и с С++ при попытке заменить его на SQL. Примеры я уже привел: реестр, файловая система и т.д.
    S>А чего ж не привести сразу решение линейных уравнений или 3d-rendering?
    Напомню:

    WH>>>Ну, давай изучи АПИ для прямых обращений к физической структуре БД.
    V>>А в чём проблема? MFC, ADO, DAO?
    S>Боюсь, ни один из них тебе не даст возможности напрямую читать/писать странички БД и расставлять локи разных уровней. А именно это и есть прямое обращение "к физической структуре БД".
    V>>А вы объясните зачем?
    S>Как зачем? Чтобы выполнять задачи управления данными в БД.

    Как видим реестр и файловые системы дают такие возможности и прекрасно управляют данными без SQL или DSL.

    S>Потому-то SQL и DSL, что он хорошо подходит для своего домена.

    Про это я и говорил.
    [In theory there is no difference between theory and practice. In
    practice there is.]
    [Даю очевидные ответы на риторические вопросы]
    Re[40]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 16.04.12 07:54
    Оценка:
    Здравствуйте, Vain, Вы писали:
    V>Напомню:
    V>

    WH>>>>Ну, давай изучи АПИ для прямых обращений к физической структуре БД.
    V>>>А в чём проблема? MFC, ADO, DAO?
    S>>Боюсь, ни один из них тебе не даст возможности напрямую читать/писать странички БД и расставлять локи разных уровней. А именно это и есть прямое обращение "к физической структуре БД".
    V>>>А вы объясните зачем?
    S>>Как зачем? Чтобы выполнять задачи управления данными в БД.

    V>Как видим реестр и файловые системы дают такие возможности и прекрасно управляют данными без SQL или DSL.
    Ничего подобного мы не видим. Вам предложили "изучить АПИ для прямых обращений к физической структуре БД".
    Если вам хочется порассуждать о том, что ФС — это та же БД (которая в этом топике подразумевалась реляционной, и судя по предложенным акронимам, вам это было тоже понятно с самого начала), то это не сюда.
    А если хотите по делу, то ни реестр ни файловые системы никаких "прекрасных" возможностей по управлению реляционными базами данных не дают, и не дадут.

    S>>Потому-то SQL и DSL, что он хорошо подходит для своего домена.

    V>Про это я и говорил.
    Нет, про это у вас нет ни одного топика. Есть только про то, что DAO/ADO/MFC — это API для "обращения к физической структуре БД", и про то, что в SQL есть ещё и управление пользователями, что не менее сложно, чем C++.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[28]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 16.04.12 11:00
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    AVK>Это не имеет значения с точки зрения проектирования DSL. Потому что все, что ты перечислил, на момент создания DSL неизвестно. Все эти документы тоже определяются пользователем.

    Тебе не об этом говорят.
    Тебя просят рассказать о модели, на которой основаны все эти сущности.

    То, что ты сделал это всё равно что показать конкретный SQL запрос человеку, который про реляционную алгебру даже не слышал. Он ничего не поймет, пока ты ему про реляционную алгебру не расскажешь.

    Вот тебя и просят рассказать про твой аналог РА, на котором основана эта бизнес логика.
    И что характерно ты его сам создал.
    Но рассказывать о нем не хочешь.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[41]: Языки общего назначения не имеют смысла!
    От: Vain Россия google.ru
    Дата: 16.04.12 11:25
    Оценка: -1 :)
    Здравствуйте, Sinclair, Вы писали:

    V>>Как видим реестр и файловые системы дают такие возможности и прекрасно управляют данными без SQL или DSL.

    S>Ничего подобного мы не видим. Вам предложили "изучить АПИ для прямых обращений к физической структуре БД".
    S>Если вам хочется порассуждать о том, что ФС — это та же БД (которая в этом топике [b]подразумевалась реляционной[b], и судя по предложенным акронимам, вам это было тоже понятно с самого начала), то это не сюда.
    Ничего такого здесь не подразумевалось. Речь шла про SQL как про DSL который можно сунуть везде и это прокатит.

    S>А если хотите по делу, то ни реестр ни файловые системы никаких "прекрасных" возможностей по управлению реляционными базами данных не дают, и не дадут.

    Я и говорил что базы сильно разные бывают, чтобы DSL ко всем им подошёл.

    S>>>Потому-то SQL и DSL, что он хорошо подходит для своего домена.

    V>>Про это я и говорил.
    S>Нет, про это у вас нет ни одного топика.
    Я не только вам отвечал.
    [In theory there is no difference between theory and practice. In
    practice there is.]
    [Даю очевидные ответы на риторические вопросы]
    Re[29]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 16.04.12 11:38
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>Тебя просят рассказать о модели, на которой основаны все эти сущности.


    Без проблем.
    /// <summary>
    /// Интерфейс метаэлемента.
    /// </summary>
    public interface IMetaElement
    {
        /// <summary>
        /// Имя.
        /// </summary>
        string Name {get; set;}
    
        /// <summary>
        /// Описание.
        /// </summary>
        string Description {get; set;}
    
        /// <summary>
        /// Идентификатор.
        /// </summary>
        Guid Id {get;}
    
        /// <summary>
        /// Элемент хранения, в котором находится указанный элемент.
        /// </summary>
        IStorageElement StorageElement {get;}
    }
    
    /// <summary>
    /// Элемент хранения.
    /// </summary>
    public interface IStorageElement : IMetaElement
    {
        /// <summary>
        /// Версия.
        /// </summary>
        Version Version {get; set;}
    
        /// <summary>
        /// Ресольвер внешних ссылок.
        /// </summary>
        IMetaResolver Resolver {get;}
    }
    
    /// <summary>
    /// Домены
    /// </summary>
    public interface IDomain : IStorageElement
    {    
        /// <summary>
        /// Тип данных
        /// </summary>
        DataType DataType {get; set;}
        
        /// <summary>
        /// Формат данных
        /// </summary>
        string Format {get; set;}
        
        /// <summary>
        /// Значение по умолчанию
        /// </summary>
        string DefaultValue {get; set;}
        
        /// <summary>
        /// Значения перечисления
        /// </summary>
        IDomainEnumValueCollection DomainEnumValues {get;}
    }
    
    /// <summary>
    /// Классы
    /// </summary>
    public interface IClass : IStorageElement
    {
        /// <summary>
        /// Базовый класс
        /// </summary>
        IClass BaseClass {get; set;}
    
        /// <summary>
        /// Свойство IsAbstract. (!A)
        /// </summary>
        bool IsAbstract {get; set;}
    
        /// <summary>
        /// Свойство IsPersistent. (!A)
        /// </summary>
        bool IsPersistent {get; set;}
    
        /// <summary>
        /// Время жизни серверного объекта
        /// </summary>
        LifeTimeType LifeTime {get; set;}
    
        /// <summary>
        /// Ссылка на каталог
        /// </summary>
        IClassRefAttribute CatalogLink {get; set;}
    
        /// <summary>
        /// Связь иерархии
        /// </summary>
        IClassRefAttribute HierarchyLink {get; set;}
    
        /// <summary>
        /// Спецификация класса
        /// </summary>
        IDetailCollection Details {get;}
        
        /// <summary>
        /// Методы
        /// </summary>
        IClassMethodCollection ClassMethods {get;}
        
        /// <summary>
        /// Атрибуты
        /// </summary>
        IClassPhysicalAttributeCollection ClassPhysicalAttributes {get;}
        
        /// <summary>
        /// Атрибуты
        /// </summary>
        IClassRefAttributeCollection ClassRefAttributes {get;}
        
        /// <summary>
        /// Вычисляемые атрибуты
        /// </summary>
        IClassCalcAttributeCollection ClassCalcAttributes {get;}
        
        /// <summary>
        /// Ограничения класса
        /// </summary>
        IClassConstraintCollection ClassConstraints {get;}
        
        /// <summary>
        /// Индекс класса
        /// </summary>
        IClassIndexCollection ClassIndexes {get;}
    }


    Вложенные типы и коллекции нужны?

    WH>Но рассказывать о нем не хочешь.


    Тебе показалось.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[20]: Языки общего назначения не имеют смысла!
    От: Andrei N.Sobchuck Украина www.smalltalk.ru
    Дата: 16.04.12 13:13
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    AVK>Ну давай проведем эксперимент. Вот типовой серверный бизнес-код на универсальном языке — C#. Давай ты продемонстрируешь, как все будет круто на DSL?


    Очевидно нужен SQL-inspired язык запросов. Просто прикрутить его к навигационному API не получится.
    Я ненавижу Hibernate
    Автор: Andrei N.Sobchuck
    Дата: 08.01.08
    !
    Re[21]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 16.04.12 13:35
    Оценка:
    Здравствуйте, Andrei N.Sobchuck, Вы писали:

    ANS>Очевидно нужен SQL-inspired язык запросов.


    Такой язык уже есть. Но он для такого кода не особенно то и применим.

    ANS> Просто прикрутить его к навигационному API не получится.


    API можно и поменять. Только непонятно, как на SQL-подобном языке упростить приведенную логику.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[17]: Языки общего назначения не имеют смысла!
    От: Andrei N.Sobchuck Украина www.smalltalk.ru
    Дата: 16.04.12 13:36
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    ANS>>Я к тому, что наличие "встроенного" класса "Документы" ничем таким не отличается от класса "Документы" в Java/C#, чтобы язык со встроенным классом стал DSL.


    V>Он только синтаксисом не отличается. Но реально отличается всем. Возьми для сравнения скриптовый объект JS — они все одинаково устроены. А в 1C встроенные объекты имеют уникальное устройство каждый, но для тебя эта уникальность скрыта за однообразным синтаксисом. Разве не в этом задача DSL — скрывать подробности относительно реализации предметной области?


    Не согласен. Во-первых, не все JS-объекты одинаково устроены. JS массивы и DOM массивы они, вроде как, разные. В Smalltalk, тоже есть объекты предоставляемые VM — типа числа, методы и пр. Т.е. наличие слоя абстракции — это не критерий DSL-ности языка.
    Я ненавижу Hibernate
    Автор: Andrei N.Sobchuck
    Дата: 08.01.08
    !
    Re[25]: Языки общего назначения не имеют смысла!
    От: Andrei N.Sobchuck Украина www.smalltalk.ru
    Дата: 16.04.12 13:41
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:


    WH>>У тебя получается, что полные по Тьюрингу языки все ЯОН. Но по некоторым мутным причинам ты некоторые полные по Тьюрингу языки записываешь в ДСЛ.


    AVK>Ограничения DSL заключаются не в ограничении Тьюринг-полноты, а в ограничении внешних возможностей. Например конструировании собственных типов определенного вида, использовании внешних библиотек и т.п.


    Скриптовые языки, ориентированные на внедрение должны иметь такие ограничивающие механизмы. Напр. Safe Tcl. С другой стороны используя Tcl, как движок можно сбацать DSL. Но это будет DSL и с Safe Tcl и без.
    Я ненавижу Hibernate
    Автор: Andrei N.Sobchuck
    Дата: 08.01.08
    !
    Re[22]: Языки общего назначения не имеют смысла!
    От: Andrei N.Sobchuck Украина www.smalltalk.ru
    Дата: 16.04.12 14:00
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    ANS>>Очевидно нужен SQL-inspired язык запросов.


    AVK>Такой язык уже есть. Но он для такого кода не особенно то и применим.


    Значит плохой язык

    ANS>> Просто прикрутить его к навигационному API не получится.

    AVK>API можно и поменять. Только непонятно, как на SQL-подобном языке упростить приведенную логику.

    В твоём примере, в один проход втиснуто много операций /бизнес-логики/. Оно понятно зачем — в навигационном API получить доступ к элементам очень дорого.
    Теперь, бьём эту функцию на элементарные операции — получится десяток запросов. Эти запросы без комментариев будут однозначно понятнее этой лапши с комментариями.
    Я ненавижу Hibernate
    Автор: Andrei N.Sobchuck
    Дата: 08.01.08
    !
    Re[8]: Языки общего назначения не имеют смысла!
    От: Andrei N.Sobchuck Украина www.smalltalk.ru
    Дата: 16.04.12 14:40
    Оценка:
    Здравствуйте, Pavel Dvorkin, Вы писали:

    PD>А можешь ответить на такой вопрос. На каком языке надо писать бинаризацию изображения? Дано greyscaled (8bpp) изображение, сделать черно-белое.


    BitBlt это язык? JitBlt, Adobe Pixel Blender.
    Я ненавижу Hibernate
    Автор: Andrei N.Sobchuck
    Дата: 08.01.08
    !
    Re[23]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 16.04.12 15:03
    Оценка:
    Здравствуйте, Andrei N.Sobchuck, Вы писали:

    AVK>>Такой язык уже есть. Но он для такого кода не особенно то и применим.


    ANS>Значит плохой язык


    Возможно.

    ANS>>> Просто прикрутить его к навигационному API не получится.

    AVK>>API можно и поменять. Только непонятно, как на SQL-подобном языке упростить приведенную логику.

    ANS>В твоём примере, в один проход втиснуто много операций /бизнес-логики/.


    Непонятно. А чем будет полезно много проходов?

    ANS>Теперь, бьём эту функцию на элементарные операции — получится десяток запросов. Эти запросы без комментариев будут однозначно понятнее этой лапши с комментариями.


    Пример привести можешь?
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[11]: Языки общего назначения не имеют смысла!
    От: alex_public  
    Дата: 16.04.12 15:59
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    _>>Ну и как мне сделать на xaml что бы по нажатию пунка меню About открывалось окно About

    AVK>Подписаться на метод вызова About

    Ну это не интересно — это как раз везде так сейчас.

    AVK>Что значит рядом? Это уже другое окно, и смысла в xaml увязывать межоконную логику немного. Ыпрочем, при желании можно примитивный компонентик написать, который это делает.


    Я считаю интерфейс единой сущностью, которая должна быть задана цельно. Т.е. технически то оно может быть и разнесено на несколько файлов для удобства, но тогда между ними должны быть нормальные вызовы. Как в обычных языка программирования.

    _>> Или что бы какой-то пункт контекстного меню был активен только если в дереве (допустим это у нас основной контрол в окне) выделен элемент?

    AVK>Это без проблем.

    Отлично! Т.е. видно что по тому пути, о котором я говорил, идут. Но к сожалению ещё очень далеко до полноценной реализации.
    Re[30]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 16.04.12 16:16
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    WH>>Тебя просят рассказать о модели, на которой основаны все эти сущности.

    AVK>Без проблем.
    Честно говря опять мало что понятно.

    Правильно ли я понял что у тебя там получается ООБД?
    У каждого объекта есть свой GUID используемый в качестве первичного ключа.
    Версия. Как я понял сколько раз меняли объект. Хранятся ли предыдущие версии объекта?
    У объектов как я понимаю могут быть коллекции вложенных объектов. А еще они умеют ссылаться на другие объекты.
    Что это?
        /// <summary>
        /// Ссылка на каталог
        /// </summary>
        IClassRefAttribute CatalogLink {get; set;}
    
        /// <summary>
        /// Связь иерархии
        /// </summary>
        IClassRefAttribute HierarchyLink {get; set;}

    В чем разница:
        /// Атрибуты
        /// </summary>
        IClassPhysicalAttributeCollection ClassPhysicalAttributes {get;}
        
        /// <summary>
        /// Атрибуты
        /// </summary>
        IClassRefAttributeCollection ClassRefAttributes {get;}

    bool IsPersistent а что объекты бывают не persistent? Зачем?

    Ну и главный вопрос: Почему ООБД? ИМХО в БД должны быть только данные, а не методы итп.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[9]: Языки общего назначения не имеют смысла!
    От: Pavel Dvorkin Россия  
    Дата: 16.04.12 16:17
    Оценка:
    Здравствуйте, Andrei N.Sobchuck, Вы писали:

    ANS>Здравствуйте, Pavel Dvorkin, Вы писали:


    PD>>А можешь ответить на такой вопрос. На каком языке надо писать бинаризацию изображения? Дано greyscaled (8bpp) изображение, сделать черно-белое.


    ANS>BitBlt это язык? JitBlt,


    Язык.

    Even on x86 systems, Jitblt was not able to achieve adequate performance for
    several reasons. Because COLA does not provide any compiler optimizations (e.g., constant
    folding, CSE), optimization had to be done within Jitblt itself. Unfortunately, there
    were several optimizations that could not be completed due to time restraints


    Ничего удивительного. Jit есть Jit, даже если он JitBlt

    А вот как из этого положения выходят

    COLA includes a C API for creating and communicating with a COLA compiler
    from external languages. This is available in the form of a static library that embeds the
    entire COLA system (libjolt). The library exposes a single C function for creating a
    COLA compiler object.

    Adobe Pixel Blender.

    Pixel Bender uses procedural syntax similar to languages such as C, Java, and ActionScript.

    В общем, некая вариация на тему C/Java с измененем синтаксиса и неописанными характеристиками быстродействия и способом реализации.
    With best regards
    Pavel Dvorkin
    Re[31]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 16.04.12 16:21
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>Правильно ли я понял что у тебя там получается ООБД?


    ООБД слишком неопределенный термин.

    WH>У каждого объекта есть свой GUID используемый в качестве первичного ключа.


    Это неважно, что у него в качестве первичного ключа. Главное что он есть.

    WH>Версия. Как я понял сколько раз меняли объект. Хранятся ли предыдущие версии объекта?


    Нет.

    WH>У объектов как я понимаю могут быть коллекции вложенных объектов. А еще они умеют ссылаться на другие объекты.


    Да

    WH>Что это?

    WH>
    WH>    /// <summary>
    WH>    /// Ссылка на каталог
    WH>    /// </summary>
    WH>    IClassRefAttribute CatalogLink {get; set;}
    
    WH>    /// <summary>
    WH>    /// Связь иерархии
    WH>    /// </summary>
    WH>    IClassRefAttribute HierarchyLink {get; set;}
    WH>


    Неважно. В примере это не используется.

    WH>В чем разница:

    WH>
    WH>    /// Атрибуты
    WH>    /// </summary>
    WH>    IClassPhysicalAttributeCollection ClassPhysicalAttributes {get;}
        
    WH>    /// <summary>
    WH>    /// Атрибуты
    WH>    /// </summary>
    WH>    IClassRefAttributeCollection ClassRefAttributes {get;}
    WH>


    Первые атрибуты описываются доменами и хранят непосредственно значение. ВТорые — ссылки на другие экземпляры объектов.

    WH>bool IsPersistent а что объекты бывают не persistent? Зачем?


    Неважно. В примере нет неперсистентных объектов.

    WH>Ну и главный вопрос: Почему ООБД? ИМХО в БД должны быть только данные, а не методы итп.


    А в БД никаких методов и нет.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[32]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 16.04.12 16:34
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    WH>>Правильно ли я понял что у тебя там получается ООБД?

    AVK>ООБД слишком неопределенный термин.
    Ты оперируешь персистентными объектами.
    А не реляционными таблицами.

    WH>>У каждого объекта есть свой GUID используемый в качестве первичного ключа.

    AVK>Это неважно, что у него в качестве первичного ключа. Главное что он есть.
    Важно.

    WH>>Версия. Как я понял сколько раз меняли объект. Хранятся ли предыдущие версии объекта?

    AVK>Нет.
    Что нет?
    Первое? Второе? Или оба?

    AVK>Неважно. В примере это не используется.

    Важно. Как проектировать ДСЛ если не ясно что в системе твориться?

    AVK>Первые атрибуты описываются доменами и хранят непосредственно значение. ВТорые — ссылки на другие экземпляры объектов.

    Не понимаю. Зачем их разделять?

    WH>>bool IsPersistent а что объекты бывают не persistent? Зачем?

    AVK>Неважно. В примере нет неперсистентных объектов.
    Ох.

    WH>>Ну и главный вопрос: Почему ООБД? ИМХО в БД должны быть только данные, а не методы итп.

    AVK>А в БД никаких методов и нет.
    Ессно нет. Она же у тебя реляционная. Или как?

    Честно говоря, я не понял, зачем была выбрана модель персистентных объектов?
    Чем она такая хорошая?

    Еще вопрос: Нужна ли распределенная работа?
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[33]: Языки общего назначения не имеют смысла!
    От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
    Дата: 16.04.12 16:40
    Оценка: :)
    Здравствуйте, WolfHound, Вы писали:

    WH>Честно говоря, я не понял, зачем была выбрана модель персистентных объектов?

    WH>Чем она такая хорошая?

    Например на ней легко делать рекурсивные запросы любой глубины и сложности. На реляционной надо сначала приседать с запросом, потом приседать с перформансом запроса.
    Re[34]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 16.04.12 16:54
    Оценка:
    Здравствуйте, Ikemefula, Вы писали:

    I>Например на ней легко делать рекурсивные запросы любой глубины и сложности.

    I>На реляционной надо сначала приседать с запросом,
    Это зависит от языка.

    I>потом приседать с перформансом запроса.

    А в объектной модели, которая маппится на реляционную БД все будет просто летать?
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[12]: Языки общего назначения не имеют смысла!
    От: PSV100  
    Дата: 16.04.12 17:01
    Оценка:
    Здравствуйте, alex_public, Вы писали:

    PSV>Нужно и удобное прямое алгоритмическое программирование GUI. Какое бы не было крутое декларативное описание, но всех потребностей оно никогда не покроет. Здесь какой-нибудь miglayout очень кстати (соответственно и декларативный DSL должен иметь как бы прямую связь с API языка программирования, т.е. в DSL задаются те же элементы, что и в этом miglayout).


    _>Точно. Вот его и ищем, но пока не видно ничего. Точнее есть нормальные решения в рамках системного языка, но хотелось бы всё же вынести это их него.


    IUP (вики) — фреймворк для Lua (можно работать и из С) для GUI, кроссплатформенный, использует нативные контролы платформы. Есть и свой DSL (простые текстовые файлы) для задания GUI, но это, прежде всего, Lua (есть и соответствующее API из коробки), где можно вытворять чего хочешь: любой свой DSL, можно взять MetaLua, MoonScript и т.д.
    Слабо заметен на фоне Qt, Wx, FoxToolkit, FLTK и пр., но, имхо, им неплохая альтернатива для ряда задач. Лично сам не юзал, но в своё время глаз на него положил.
    Re[28]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 16.04.12 17:28
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    V>>Если я доверяю кусок кода непрофессионалу-бухгалтеру, то плохо, ес-но, т.к. он может банально всё уронить.

    S>Не может, если хост языка ему не позволяет.

    Ну ты же спросил насчет случая, когда язык приобретает св-ва языка общего назначения через подключение произвольных либ, так? В это случае может, ес-но, через неправильное использование этих самых библиотек, которые не обязательно безопасны, если мы договорились, что они произвольные.

    V>>Опять сорри за ликбез, но нет. CRT является частью языка и стандарта, позволяя писать практически что угодно без линкера.

    S>Я боюсь, что у вас ничего не получится без линкера.

    На gcc, icc и многих других компиляторах получится. Причем, зависимости от CRT указывать не надо, в отличие от зависимостей от других либ, бо стандартные ф-ии обязаны работать "изкаробки". Я уже обращал внимание на то, что если другие либы надо указывать в параметрах компилятора или линкера для включения, то относительно CRT опции чуть другие по характеру — это опции отключения CRT или выбора типа CRT.


    V>>Насчет твоих inp/outp. Если интересовался, то в защищенном режиме x86 порты отображены на карту виртуальной памяти. Во многих embedded-архитектрах, например PIC — точно так же без всякого защищенного режима — порты ввода-вывода лежат по специальным адресам. Но это фигня, дело-то не в порта, так? А в выполнении произвольной инструкции процессора, правильно? С/С++ чуть ли не единственные языки, где можно записать данные в некоторую область памяти (в сегмент данных, например) и передать туда управление. Так работают всякие нейтивные вирусы, писанные на С.

    S>И это не имеет никакого отношения к импорту библиотек.

    Это имеет отношение к твоему утверждению, что С/С++ так же подойдет на роль DSL. Не подойдет, т.к. нет каких-либо ср-в ограничить исходный код.

    V>>В каком месте мы в этом убедились? На примере С/С++ никак не убедились, т.к. совокупность всех возможностей языка позволяет ему ставить раком произвольную аппаратную платформу.

    S>Мне нравится ваша способность начисто игнорировать весь ход обсуждения. Что мы имеем? Пример С показывает, что для постановки раком платформы библиотеки ему не нужны, да и нет в языке ничего специального про библиотеки.

    Я не игнорирую, я вижу что ты успел забыть на какие твои вопросы я даю ответы. Ты сделал кое-какие утверждения относительно С? Я не согласился и объяснил — почему. Потому что изкаробки слишком много возможностей, даже без внешних библиотек — из-за CRT и адресной арифметики ф-ий.


    S>Пример "улучшенного Лого" показывает, что добавление библиотек никак не помогает поставить раком платформу. Но вас это не смущает.


    Мы недообсуждали Лого, чтобы делать такие выводы. Я еще не увидел твоего примера целиком. Покажи предположительный синтаксис вызова произвольных внешних ф-ий для "расширенного Лого", а затем я тебе дам небольшой список экспорта, например, NT.DLL, с помощью которого можно уронить любую, самую защищенную программную среду.


    V>>Да и взять сами термины: на мой взгляд specific area отличается от general area границами и более ничем. Поэтому для меня императивный DSL — это в первую очередь ограничение области приложения, а затем уже хелперы и прочие плюшки. Например, с точностью до тонкостей синтаксиса можно этот HTML-DOM обрабатывать из какого-нить C# или С++ при подключенной соответствующей библиотеке.

    S>Совершенно верно. Поэтому изо всех языков, работающих с DOM, DSL-ями являются только CSS и XSLT. JS, как и С и C++, это типичный GPPL.

    Опять по кругу... Если бы C/C++ не обладали CRT/CppRT, идущими как часть стандарта, и не имели адресной арифметики ф-ий, позволяющей передать управление куда угодно, я бы согласился. А так — нет.
    Re[14]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 16.04.12 17:33
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    O>>Посмотрите на выпускников ВУЗов — они ни черта вообще не умеют


    AVK>Выпускники, они разные бывают. Несколько человек на поток обычно вполне вменяемые. А остальные просто для корочки 5-6 лет отсидели, что то по ним мерять неинтересно.


    Это да, но знакомые преподы говорят, что % вменяемых выпускников IT резко уменьшился за последние 10 лет. Сейчас их порядка по 1-2 на группу выходит из нашего ВУЗа, в 90-е выходило от четверти до трети и даже девушки что-то умели, что сейчас большая редкость.
    Re[33]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 16.04.12 17:58
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    AVK>>ООБД слишком неопределенный термин.

    WH>Ты оперируешь персистентными объектами.

    Не я, но в приведенном куске кода — да.

    WH>>>У каждого объекта есть свой GUID используемый в качестве первичного ключа.

    AVK>>Это неважно, что у него в качестве первичного ключа. Главное что он есть.
    WH>Важно.

    Почему?

    WH>>>Версия. Как я понял сколько раз меняли объект. Хранятся ли предыдущие версии объекта?

    AVK>>Нет.
    WH>Что нет?

    Не хранятся.

    AVK>>Неважно. В примере это не используется.

    WH>Важно. Как проектировать ДСЛ если не ясно что в системе твориться?

    Как проектировать SQL, если неясно как работают функции lo_ххх в Postgres?

    AVK>>Первые атрибуты описываются доменами и хранят непосредственно значение. ВТорые — ссылки на другие экземпляры объектов.

    WH>Не понимаю. Зачем их разделять?

    Набор данных, описывающих их, разный.

    WH>>>bool IsPersistent а что объекты бывают не persistent? Зачем?

    AVK>>Неважно. В примере нет неперсистентных объектов.
    WH>Ох.

    Можешь считать, что их вообще не существует, если тебе так комфортно. Ты же понимаешь, что мне не нужно конкретное готовое решение? Мне нужна демонстрация преимуществ подхода в целом.

    WH>>>Ну и главный вопрос: Почему ООБД? ИМХО в БД должны быть только данные, а не методы итп.

    AVK>>А в БД никаких методов и нет.
    WH>Ессно нет. Она же у тебя реляционная. Или как?

    Реляционная.

    WH>Честно говоря, я не понял, зачем была выбрана модель персистентных объектов?


    Это другая тема. Обработки, не связанные с агрегацией, редактирование конкретных экземпляров — все это удобнее и, главное, проще выражать в ОО форме. Там, где удобнее реляционная модель — можно писать реляционные запросы. Но запросы уже и так DSL. А вот для такого обрабатывающего кода — все далеко не так очевидно.

    WH>Еще вопрос: Нужна ли распределенная работа?


    В каком смысле распределенная? Распределенные сервера не нужны, а система в целом — конечно распределенная. Времена однопользовательских ERP давным давно прошли.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[15]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 16.04.12 18:00
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    V>Это да, но знакомые преподы говорят, что % вменяемых выпускников IT резко уменьшился за последние 10 лет.


    Это, в основном, потому что профессия стала престижнее.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[24]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 16.04.12 18:05
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    V>>Грамматика SQL проста до безобразия

    AVK>Я бы так не сказал. Там местами даже в LL(k) не укладывается, LL(*) нужен.

    Зато прекрасно справляется параллельный LR(1), т.к. всегда может отличить конец одного выражения от начала другого без этих разделителей (все копии автомата "схлопываются" в этом месте к 1-й). Или его минимизированный вариант — LALR. И вообще, любые параллельные парсеры для этого дела подойдут, например Эрли.

    Под простотой грамматики я имел ввиду малое кол-во правил для описания обсуждаемого оператора SELECT, т.е. можно закодить LR(1) врукопашную по системе правил — это будет вполне обозримый объем работ на несколько вечеров. (Для перфекционистов, выбирающих LALR, лучше использовать готовый генератор, ес-но, чтобы не налепить ручных ошибок).


    V>> и в сети лежит множество готовых парсеров, которые расширить на свои потребности можно с пол-пинка.

    AVK>Парсер это примерно 5% потребной работы, если не меньше.

    Именно что. Но ведь самый популярный контраргумент против разработки самописных DSL — якобы сложность разработки парсера.

    На самом деле, остальные 95% — они тоже не с 0-ля будут писаны в реальной разработке. К тому моменту, когда созрели до DSL, обычно уже есть много из готовой инфраструктуры и понимания происходящего, которое теперь надо "просто чуть по-другому оформить".
    Re[25]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 16.04.12 18:34
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    V>Зато прекрасно справляется параллельный LR(1)


    Не справляется. Там есть места, парсить которые можно только с откатами, за фиксированное число лексем определить нужное правило нельзя. К примеру, IN предикат бывает двух типов — когда в скобках список выражений и когда подзапрос. Т.е. может быть такое:
    WHERE x IN (SELECT * FROM ys)
    ...
    WHERE x IN (SELECT COUNT(*) FROM ys, SELECT COUNT(*) FROM zs)

    Это две разных синтаксических конструкции, одна "IN" "(" <value_list> ")", другая "IN" <subquery>, но отличить их парсер, могущий заглядывать на фиксированное количество лексем, в точке перед скобкой не может в принципе. Нужно заглядывать вперед по правилу с subquery, и только если не получилось его отматчить, идти по ветке value_list. Т.е. нужны откаты.
    И таких вещей несколько штук даже в sql'92 есть.

    V>И вообще, любые параллельные парсеры для этого дела подойдут, например Эрли.


    Ты под параллельными понимаешь парсеры с откатами (параллельным разбором правил) что ли? Тогда LL(k) или LR(k) такие парсеры называть некорректно.

    V>Под простотой грамматики я имел ввиду малое кол-во правил для описания обсуждаемого оператора SELECT


    В SQL'92, емнип, больше 6 сотен только для селекта. У меня, когда я выкинул все гавно типа указания кодировок и устаревших форм различных операторов, все равно больше сотни получилось.
    Но, на самом деле, парсер это фигня, мизерная часть от общего объема транслятора. Один ресолвер типов по трудоемкости в разы больше.

    V>, т.е. можно закодить LR(1) врукопашную по системе правил — это будет вполне обозримый объем работ на несколько вечеров.


    С учетом построения нормального AST и промышленного качества кода, я бы сказал пару недель. У опытного человека. Ну и LR в такой ситуации не лучший выбор — диагностика ошибок, понимаешь ли.

    V>Именно что. Но ведь самый популярный контраргумент против разработки самописных DSL — якобы сложность разработки парсера.


    Не знаю у кого он популярный. Наверное у тех, кто периодически озвучивает тут очередную гениальную идею по хранению исходников в виде отпарcенного AST.

    V>На самом деле, остальные 95% — они тоже не с 0-ля будут писаны в реальной разработке. К тому моменту, когда созрели до DSL, обычно уже есть много из готовой инфраструктуры и понимания происходящего, которое теперь надо "просто чуть по-другому оформить".


    Ну, у меня такой проект до первого рабочего прототипа занял примерно 6 человекомесяцев. Потом еще пару пришлось потратить на переделку мест, где я сам же и схалтурил. Ну и еще месяца 4 в сумме ушло на докручивание нового функционала, в основном не мной.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[24]: Языки общего назначения не имеют смысла!
    От: koodeer  
    Дата: 16.04.12 18:41
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    AVK>Это даже не смешно. При чем тут бизнесмен? Речь о специалисте по созданию DSL.


    Да при том! Представим, что компьютеров нет. Совсем нет, не изобрели ещё! Ведь бизнесмены и без них смогут общаться между собой, именно на языке своего бизнеса, своими терминами. Так и было до компьютеризации. А потом пришли мы, программисты, и стали требовать, чтобы свою специфику бизнесмены выразили нам в терминах языков программирования. Мы не понимаем их, они нас.


    K>>Это не я должен показывать. Это должны показывать бизнесмены.


    AVK>Забудь, это фантастика. Заказчики не способны даже логически непротиворечиво изложить требования.


    Странно, большинство моих заказчиков вполне адекватно излагают требования. Но на своём языке. Да, эти требования не перекладываются напрямую на программный код. Но это уже не проблемы их логики. Это проблемы отсутствия софта по созданию DSL.



    Повторюсь, что хочу слишком многого. Я это понимаю.
    Ещё понятнее донести свои мысли не могу. На сём предлагаю прекратить обсуждение.
    Re[25]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 16.04.12 18:46
    Оценка:
    Здравствуйте, koodeer, Вы писали:

    K>Да при том! Представим, что компьютеров нет. Совсем нет, не изобрели ещё! Ведь бизнесмены и без них смогут общаться между собой, именно на языке своего бизнеса, своими терминами.


    Только такой язык невозможно будет реализовать. Умение формализовать естественно произошедшие вещи — важное и сложное умение. Собственно, все эти ООП, ФП, DSL — это все как раз про это.

    AVK>>Забудь, это фантастика. Заказчики не способны даже логически непротиворечиво изложить требования.

    K>Странно, большинство моих заказчиков вполне адекватно излагают требования.

    Значит тебе повезло. Или специфика области, в которой ты работаешь. Мне так не повезло, у меня даже прикладники (программисты!) иногда не способны непротиворечиво объяснить, что им нужно.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[19]: Языки общего назначения не имеют смысла!
    От: koodeer  
    Дата: 16.04.12 18:47
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>На шаблонах С++ эту задачу можно решить довольно просто.

    WH>Показать, как или сам хочешь подумать?

    Я представляю в общих чертах, как это делается. Более того, есть готовые примеры:
    http://www.rsdn.ru/forum/src/1824757.flat.aspx
    Автор: CrystaX
    Дата: 06.04.06
    — C++.
    http://www.rsdn.ru/forum/src/1823225.flat.aspx
    Автор: Oyster
    Дата: 05.04.06
    — Nemerle.
    В своё время я очень заинтересовался этими двумя примерами.

    Кстати, хотелось бы, чтобы нечто подобное было включено в стандартную библиотеку Немерла.


    WH>В случае с С++ это не проблема. Если в класс засунуть один double то там ничего кроме него не будет.


    Ну, хотелось бы не просто одно значение в классе. Нужно чтобы, например, при делении напряжения на сопротивление получалась сила тока.
    Re: Языки общего назначения не имеют смысла!
    От: org_256  
    Дата: 16.04.12 18:49
    Оценка:
    я тысячный :-P походу
    Re[19]: Языки общего назначения не имеют смысла!
    От: koodeer  
    Дата: 16.04.12 18:53
    Оценка:
    Здравствуйте, netch80, Вы писали:

    N>Видимо, ты давно последний раз видел C++.


    Да, давно. Последние годы сижу на дотнете.


    N>Если размерность значения определена в его типе, то достаточно легко получить и контроль во время компиляции (причём оно может, например, разрешить присвоить скорости произведение ускорения на время и в то же время запретить присвоение ей массы), и в то же время единственным данным внутри класса будет значение величины — например, типа double — и после оптимизации всё это выродится в простейшие операции со скаляром с плавающей точкой.


    N>Попробуй сам (только на современных компиляторах, а не образца 95-го года) и удивись.


    А это будет сильно проще этого примера: http://www.rsdn.ru/forum/src/1824757.flat.aspx
    Автор: CrystaX
    Дата: 06.04.06
    ? Или именно реализация на шаблонах имеется в виду?


    N>Для статически типизированного — да. Для динамически — нет.

    N>Зависит именно от типизации.

    Не, не, — динамическая типизация идёт лесом. Только статика, только проверки в компайл-тайме по максимуму.
    Re[24]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 16.04.12 19:02
    Оценка: :)
    Здравствуйте, Sinclair, Вы писали:


    V>>Дальше лень расписывать, пока было расписано подвыражение:

    V>>select ManagerID, sum(Orders.Amount) from Orders where Orders.OrderDate between '20100101' and '20101231' group by ManagerID;
    S>Отлично. Пока что SQL рвёт библиотеку 1 к 3м по компактности и читаемости.

    Это пока нам не надо повторно использовать код. А то в итоге может оказаться наоборот 30 к 1 в итоге.


    S>И это у вас ещё нет никаких попыток разрешить переписывания и оптимизации запроса внутри библиотеки — ваши предикаты это всего лишь функторы, а не Expression Trees.


    V>>Можно спросить, что ты хотел узнать?

    S>Да я-то ничего нового не узнал. Я хотел вам показать разницу между DSL и библиотекой, нарисованной на GPPL. Надеюсь, показал.
    V>>На Клиппере пожестче было в свое время — никто не жаловался. И рвали по быстродействию любые базы, бо скомпилированный код многократно быстрее интерпретируемого работает.
    S>
    S>Вообще-то на клиппере как раз было помягче, т.к. всё таки это DSL, специально заточенный на обработку данных — пусть и чрезмерно императивный.

    Таки я хорошо помню, что ручками делал гораздо больше, чем могу себе позволить обобщить на шаблонах С++ сегодня. И никакой оптимизации тоже не было, ес-но, было тупое сканирование файлов данных или файлов-индексов и обработка согласно самописных алгоритмов. Так же помню, что копипасты было много.


    V>>>>Если же ты о перезаписи операций и прочей оптимизации — то это совсем отдельные операции, которые тоже, впрочем, достаточно формализованы.

    S>>>Хотелось бы, чтобы перезапись операций и прочая оптимизация были не хуже, чем в SQL.

    V>>Это нужен подход №2, когда выражение дается в виде декларации и доступно затем для аналитических вычислений. Тогда точно так же как показано выше в синтаксисе, но пусть select, from, transform и т.д. являюся не вызовами на обработку коллекций, а конструкторами узлов графа операций (аналог AST). Добавится лишь еще одна команда, нечто типа:

    V>>
    V>>auto resultingCollection = execute(result);
    V>>

    S>Что-то меня гложут тяжкие сомнения про то, что это так легко сделать, как вы пишете.

    Почему? Смотрел на boost::lambda? Они почти весь синтаксис С++ умудрились сделать как генератор работающего AST. Отличный пример того, как это надо делать и стартовая точка для своих наработок.

    Ес-но, для каждого выражения — свой узел. Вот здесь в двойных скобках приводил в примере именно генерацию AST, которое исполняется "потом":
    ( (_1.managerId=_2.first, _1.amount=sum(_2.second, &Order::amount)) )


    _1, _2 — это глобальные placeholders из boost::lambda. В двойный скобках потому, что используется operator,() (оператор "запятая"), для перечисления последовательности действий в лямбде. Но синтаксис вызова ф-ии "проглотит" эти запятые в качестве разделителей нескольких аргументов, в то время как аргумент только у нас только один — это лямбда, вызываемая для построчных трансформаций.


    S>Скажем, Версанту потребовалось всё-таки приделать свой парсер C++, чтобы обойти ограничения языка. Для AST недостаточно скормить в between указатель на член класса — надо каким-то образом дать возможность среде определить, что это за член класса такой, и поднять всю нужную метадату.


    Как раз для приведенной мною ф-ии between ничего не нужно в отличие от генерации трансформаторов для проекций, продукций и пересечений, т.к. это просто перегрузка ее сигнатуры для случая на указателя на мембер, которая должна конструировать MemberBetweenPredicate (кстате, приведенный исключительно с целью показать, во что превратится вызов between).

    Если бы я писал не торопясь, то увидел бы, что некая ф-ия приведения 'cdate' не нужна, достаточно, чтобы тип переменной-мембера имел нужный конструктор от одного аргумента, который можно вызвать как explicit.

    Вот полный код для перегрузки сигнатуры between для указателя на мембер:
    template<typename Entity, typename Value, typename Arg1, typename Agr2>
    struct MemberBetweenPredicate<Entity, Value> between(Arg1 agr1, Value Entity::*member, Arg2 arg2) {
      MemberBetweenPredicate<Entity, Value> tmp = { member, { Value(arg1), Value(arg2) } };
      return tmp;
    }


    Теперь, при наличии у некоего типа, используемого для представления даты, конструктора от С-строки, можно писать еще короче:
    between("20100101", &Order::orderDate, "20101231")
    Re[26]: Языки общего назначения не имеют смысла!
    От: koodeer  
    Дата: 16.04.12 19:09
    Оценка:
    Здравствуйте, AndrewVK

    Я сейчас почитал в соседней теме "DSL — мысли", что пишет Влад:

    3. DSL есть всегда, так как любая модель предметной области в программе — это DSL. DSL, уважаемые, это в первую очередь ЯЗЫК. Модель ни разу не язык. С моделью можно работать через API. А DSL как раз и предназначен для того, чтобы корявое и не имеющее четких границ API заменить на четкий язык позволяющий заполнить эту модель конкретными данными. Простой пример — реализация КА (конечного автомата) — это модель. А язык позволяющий описывать состояния и переходы КА — это DSL.


    Я понял часть своих заблуждений. Я действительно путаю модель и язык.
    Собственно, для того я и вступил в обсуждение, чтобы разъяснить для себя самого неясные вопросы. Постепенно туман рассеивается.
    Благодарю за потраченное время.
    Re[20]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 16.04.12 19:13
    Оценка:
    Здравствуйте, koodeer, Вы писали:

    K>Ну, хотелось бы не просто одно значение в классе. Нужно чтобы, например, при делении напряжения на сопротивление получалась сила тока.

    Так по твоей ссылке код на С++ это и делает.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[26]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 16.04.12 19:54
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    V>>Зато прекрасно справляется параллельный LR(1)


    AVK>Не справляется. Там есть места, парсить которые можно только с откатами, за фиксированное число лексем определить нужное правило нельзя. К примеру, IN предикат бывает двух типов — когда в скобках список выражений и когда подзапрос. Т.е. может быть такое:

    AVK>
    AVK>WHERE x IN (SELECT * FROM ys)
    AVK>...
    AVK>WHERE x IN (SELECT COUNT(*) FROM ys, SELECT COUNT(*) FROM zs)
    AVK>

    AVK>Это две разных синтаксических конструкции, одна "IN" "(" <value_list> ")", другая "IN" <subquery>, но отличить их парсер, могущий заглядывать на фиксированное количество лексем, в точке перед скобкой не может в принципе. Нужно заглядывать вперед по правилу с subquery, и только если не получилось его отматчить, идти по ветке value_list. Т.е. нужны откаты.
    AVK>И таких вещей несколько штук даже в sql'92 есть.

    Я знаю, но дело в том, что к концу выражения "останется" только один вариант, т.к. грамматика SQL однозначна. Поэтому я упомянул параллельный LR(1). В нем в месте конфликта происходит размножение текущего состояния вычислителя (полученные копии, кстати, эффективно делят стек предыдущих вычислений), затем "ошибочные ветки" умрут сами собой к концу выражения или еще раньше.

    Я все время забываю, что у этой разновидности LR(k) есть собственное название GLR, т.к. сам переизобрел такой способ парсинга "неоднозначных где-то в середине выражений" на основе LR(1) в последней трети 90-х, когда еще не было у нас нормального интернета. Кстате, тогда же и убедился, что для техники параллельного разбора достаточно k=1 для любой однозначной грамматики, т.е. реализация GLR-алгоритма на основе LR(k) автомата даже в наколенном варианте выходит весьма примитивна из-за k=1 и располагает к экспериментам. К тому же работает шустро на однозначных участках входных цепочек, где разбор не уступает скорости работы какому-нить лексическому анализатору по регулярной грамматике.



    V>>И вообще, любые параллельные парсеры для этого дела подойдут, например Эрли.

    AVK>Ты под параллельными понимаешь парсеры с откатами (параллельным разбором правил) что ли? Тогда LL(k) или LR(k) такие парсеры называть некорректно.

    Таки LR(k) — это разбор вширь, а не вглубь, как LL(k). Поэтому LR-парсеры и просятся на параллельность.
    Эрли я упомянул как известный параллельный парсер, который 100% справится с задачей, хоть он и нисходящий. Конечно, он не LL(k). Просто есть несколько его готовых реализаций, включая на этом сайте (и мой чуть допиленный вариант, форкнутый с этого сайта ), и был подробный разбор принципов его работы. Т.е. это лишь пример того, что ничего страшного в плане парсинга не ожидает.


    V>>Под простотой грамматики я имел ввиду малое кол-во правил для описания обсуждаемого оператора SELECT


    AVK>В SQL'92, емнип, больше 6 сотен только для селекта. У меня, когда я выкинул все гавно типа указания кодировок и устаревших форм различных операторов, все равно больше сотни получилось.


    Понятно... я навскидку больше пары десятков не вспомню...

    Опять же, мы же обсуждали свой собственный DSL, лишь похожий на SQL, а разработка поддерживаемого этим DSL синтаксиса могла бы быть, скажем так, очень пошаговой. Ведь на каждую синтаксическую конструкцию необходимо иметь работающую трансформацию.


    AVK>Но, на самом деле, парсер это фигня, мизерная часть от общего объема транслятора. Один ресолвер типов по трудоемкости в разы больше.


    У меня однажды с полпинка заработала аналогичная задача, после перекидывания ее на Пролог. Т.е. захостил движок пролога в программе, скормил ему правила вывода + структуру фактических выражениq с неизвестными и он разресолвил мне все неизвестные. Причем, очень удобно, если больше одного решения по каждому неизвестному — то неоднозначность. Если нет решений — то нет. Круто. С тех пор я настойчиво рекомендую во всех этих обсуждениях использовать для вывода типов любой движок для программирования в ограничениях, т.е. взять готовую часть логического вывода, чтобы не писать ее самому. Ты ведь всё-равно ручками писал точно такой же перебор, только захардкоженный, т.е. даже не столь гибкий и легкий в экспериментах. Ну... если только не догадался декларативно выделить правила и заставить работать "решатель" поверх них, тогда беру свои слова назад насчет "захардкоженный", но не беру насчет "ручками".

    Когда копнул эту тему чуть позже — увидел довольно много готовых движков и даже новых языков на эту тему.


    V>>, т.е. можно закодить LR(1) врукопашную по системе правил — это будет вполне обозримый объем работ на несколько вечеров.


    AVK>С учетом построения нормального AST и промышленного качества кода, я бы сказал пару недель. У опытного человека. Ну и LR в такой ситуации не лучший выбор — диагностика ошибок, понимаешь ли.


    Я уже многократно видел мнение, что диагностика ошибок у LR слабовата... Не всегда это так. Это так у "глубоких" выражений, где парсер дает ошибку не в том месте, где человек допустил ошибку. Но каждый оператор SQL — максимум двухуровневый (операторы существования), и сами выражения редко более чем в 2-3 уровня склыдваются, если только не в join, что не есть в глубину. ИМХО вполне пойдет. У LR(k) будет точно такая же диагностика как у табличного LL(k), т.к. в точке возникновения ошибки будут доступны возможные успешные терминалы + ветки продолжения удачного разбора, точно так же, как доступен список успешных направляющих терминалов + соотв. веток разбора для LL(k).


    V>>Именно что. Но ведь самый популярный контраргумент против разработки самописных DSL — якобы сложность разработки парсера.


    AVK>Не знаю у кого он популярный. Наверное у тех, кто периодически озвучивает тут очередную гениальную идею по хранению исходников в виде отпарcенного AST.


    V>>На самом деле, остальные 95% — они тоже не с 0-ля будут писаны в реальной разработке. К тому моменту, когда созрели до DSL, обычно уже есть много из готовой инфраструктуры и понимания происходящего, которое теперь надо "просто чуть по-другому оформить".


    AVK>Ну, у меня такой проект до первого рабочего прототипа занял примерно 6 человекомесяцев. Потом еще пару пришлось потратить на переделку мест, где я сам же и схалтурил. Ну и еще месяца 4 в сумме ушло на докручивание нового функционала, в основном не мной.


    Надеюсь, повторное использование разработанной технологии в разных проектах были? Ну или сам проект кастомизируемый под разных заказчиков (что фактически одно и то же)?
    Понятно, что вложения должны давать отдачу. Например, от объема целевой задачи могла зависеть полнота поддержки исходного SQL. Мы в до-LINQ времена на перегрузках операторов C# делали генератор SQL для своей ORM на основе тогда еще RFD под 3 SQL-диалекта и развивали этот движок весьма пошагово, по мере поступления новых требований от всё новых и новых проектов, где он многократно использовался.
    Re[24]: Языки общего назначения не имеют смысла!
    От: mrTwister Россия  
    Дата: 16.04.12 21:10
    Оценка: 58 (1)
    Здравствуйте, AndrewVK, Вы писали:

    AVK>Здравствуйте, mrTwister, Вы писали:


    T>>*]код очень трудно читаем. что он делает и зачем он нужен понять трудно.


    AVK>Я легко прочел? И не очень понятно, что там так трудно читаемо.


    Я совершенно не могу понять, что делает этот кусок кода:

    IInventoryCardObject invCardObj = invAfter.GetInventoryCardObject();
    if (invCardObj != null)
    {
        var card = ((IPersistedObject)invCardObj).Master as IInventoryCardBase;
        if (card is IAccrualAccountingInventoryCard)
            Manager.DeleteObject((IPersistedObject)invCardObj);
        else if (!cardsDeleteSet.Contains(card))
            invCardObj.Inventory = inv;
    }
    inv.ChangesHistory = null;
    ChangeInventoryActualStateInDocuments(invAfter, inv);
    Manager.DeleteObject((IPersistedObject)invAfter);


    Это просто взрыв мозга

    Также множество вложенных конструкций, код "расфокусирован", то есть делает много разных вещей. Например, выполняет какие-то сложные модификации и одновременно занимается нетривиальными проверками бизнес-логики. Такой код лучше разделять.

    T>>*]кучи даункастов


    AVK>Не куча, а несколько. И это особенность платформы. Можешь просто проигнорировать.


    Я насчитал 11 явных и неявных даункастов. Это очень много, код считай нетипизирован. Про особенность платформы — все мы знаем, что любую проблему в CS можно решить введением еще одного уровня абстракции. Причем совсем не обязательно этому уровню абстрацкии быть DSLем.

    T>>*]кучи null'ей, которые в разных случаях имеют неявный смысл


    AVK>Непонятно. Современные БД в принципе увязаны с null.


    Совсем не обязательно тащить в прикладной код бизнес-логики потроха и особенности работы с БД.

    T>>а во второй оставили низкоуровневый лапшу-код


    AVK>Почему низкоуровневый?


    Потому что API вашей платформы выглядит весьма гибким и низкоуровневым, о чем свидетельствует, например, обилие даункастов.

    T>>*]напрашивается вынос из метода 3-х 4-х подпрограмм


    AVK>Зачем выносить то, что встречается ровно один раз из метода меньше экрана размером?


    Затем, чтобы читатель мог бы быстро понять в общем, что делает код и опускаться до деталей только тогда, когда они его действительно интересуют.

    T>>*]Использование бессмысленных идентификаторов


    AVK>Каких именно?


    obj

    T>>*]Можно было бы обойтись без модификаций локальной переменной (cardsDeleteSet)


    AVK>Зачем?


    Чтобы код было легче читать. Сейчас чтобы понять, что происходит приходится искать все места использования переменной в весьма "жирном" коде, искать, где переменная модифицируется, а где затем читается.


    Вообще, я бы отрефакторил код, чтобы он в конце-концов выглядел как-то так:

    var documentsAndInventories = (
        from document in Manager.Get(objectsIds)
        from inventory in document.GetObjects().Cast<IInventory>
        select new {document, inventory} ).ToArray();
        
    var inventories = (from item in documentsAndInventories select new {item.inventory}).ToArray();
    var inventoriesAndTheirOperations = (from inventory in inventories select new {inventory, GetInventiryOperations(inventory)}).ToArray();
    
    ValidateForLateOperations(inventoriesAndTheirOperations);
    ValidateForInvalidLinks(inventories);
    
    var cardsThatWillBeDeleted = DeleteInventoryOperations(inventoriesAndTheirOperations);
    ClearInventoryHistory(inventories, cardsThatWillBeDeleted);
    ModifyInventoryResponsiblePersonAndStructuralSubdivision(documentsAndInventories);
    DeleteCards(cardsThatWillBeDeleted);
    лэт ми спик фром май харт
    Re[25]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 16.04.12 21:54
    Оценка:
    Здравствуйте, mrTwister, Вы писали:

    T>Я совершенно не могу понять, что делает этот кусок кода:


    T>
    T>IInventoryCardObject invCardObj = invAfter.GetInventoryCardObject();
    T>if (invCardObj != null)
    T>{
    T>    var card = ((IPersistedObject)invCardObj).Master as IInventoryCardBase;
    T>    if (card is IAccrualAccountingInventoryCard)
    T>        Manager.DeleteObject((IPersistedObject)invCardObj);
    T>    else if (!cardsDeleteSet.Contains(card))
    T>        invCardObj.Inventory = inv;
    T>}
    T>inv.ChangesHistory = null;
    T>ChangeInventoryActualStateInDocuments(invAfter, inv);
    T>Manager.DeleteObject((IPersistedObject)invAfter);
    T>


    T>Это просто взрыв мозга


    Не вижу никакого взрыва. Этот код просто лапочка по сравнению с тем, что местами попадается, скажем, в решарпере Типа нескольких вложенных циклов по графу, на который наложены и неявно учитываются контролируемые только в рантайме ограничения, внутри которых несколько goto, причем в разные точки. Вот это да, взрыв моска. А тут линейная логика.
    Ну давай посмотрим:
    IInventoryCardObject invCardObj = invAfter.GetInventoryCardObject();

    Получаем объект инвентаризации из истории операции инвентаризации
    if (invCardObj != null)

    Если объект есть
    var card = ((IPersistedObject)invCardObj).Master as IInventoryCardBase;

    Берем карточку, по которой он инвентаризован
    if (card is IAccrualAccountingInventoryCard)
        Manager.DeleteObject((IPersistedObject)invCardObj);

    Здесь мои скудные знания бухгалтерии меня подводят, но суть понятна — удаляем объект инвентаризации, если он к определенному виду принадлежит. Прикладники тут, кстати, накосячили — приведение лишнее.
    else if (!cardsDeleteSet.Contains(card))
            invCardObj.Inventory = inv;

    Иначе проверяем наличие в хешике, который мы чуть раньше заполняли, и если совпало, то в детейле инвентарной карточки заменяем ссылку на справочник инвентаризуемых объектов.
    inv.ChangesHistory = null;

    Обнуляем историю инвентаризации
    ChangeInventoryActualStateInDocuments(invAfter, inv);

    Название метода вполне говорящее.
    Manager.DeleteObject((IPersistedObject)invAfter);

    Удаляем инвентаризационную операцию
    Это, собственно, типичная бизнес-логика. Далеко не самая запутанная, уж поверь. И ее то как раз нужно сохранить, это входящее требование. А вот как ее более красиво записать — вопрос.

    AVK>>Не куча, а несколько. И это особенность платформы. Можешь просто проигнорировать.


    T>Я насчитал 11 явных и неявных даункастов.


    Где? В DeleteObject даункаст лишний. Даункаст при обращении к Master — технологическая особенность, связанная с распределенностью системы и едиными интерфесами и в клиентском и в серверном коде. Согласен, проблема, но ее не так то легко вылечить. А as/is — это просто проверка дискриминанта, который выражен в виде реализации тех или иных интерфейсов.

    AVK>>Непонятно. Современные БД в принципе увязаны с null.

    T>Совсем не обязательно тащить в прикладной код бизнес-логики потроха и особенности работы с БД.

    Согласен. Но альтернатив как то недофига. Можно, наверное, maybe monad использовать, да. Но тут скорее не dsl нужен, а нормальный допил C#. Штука то предельно универсальная.

    T>>>а во второй оставили низкоуровневый лапшу-код

    AVK>>Почему низкоуровневый?

    T>Потому что API вашей платформы выглядит весьма гибким и низкоуровневым, о чем свидетельствует, например, обилие даункастов.


    Это не API платформы, это сознательно сделанные на прикладном уровне решения. API платформы это Get и DeleteObjects.

    T>>>*]Использование бессмысленных идентификаторов


    AVK>>Каких именно?


    T>obj


    InventaryObject это потому что оно так и называется — объект инвентаризации, а не потому что это какая то неведомая фигня типа System.Object. Так что вполне осмысленный.


    T>>>*]Можно было бы обойтись без модификаций локальной переменной (cardsDeleteSet)


    AVK>>Зачем?


    T>Чтобы код было легче читать. Сейчас чтобы понять, что происходит приходится искать все места использования переменной в весьма "жирном" коде, искать, где переменная модифицируется, а где затем читается.


    Переменная модифицируется ровно один раз, при объявлении. Потом меняется содержимое самого хеша, а не переменной. И использование вполне стандартное — запоминаем в цикле обхода, потом запомненное используем для проверки. Такого кода, скажем, внутри System.Enumerable до попы, хотя, вроде как, весьма приличные спецы писали.

    T>Вообще, я бы отрефакторил код, чтобы он в конце-концов выглядел как-то так:


    T>[c#]

    T>var documentsAndInventories = (
    T> from document in Manager.Get(objectsIds)
    T> from inventory in document.GetObjects().Cast<IInventory>
    T> select new {document, inventory} ).ToArray();

    Можно. Но линк для прикладников, все же, тяжеловат. Со временем, впрочем, должны научится, сейчас довольно вменяемых товарищей набрали. Было намного хуже, уж поверь.

    T>var inventories = (from item in documentsAndInventories select new {item.inventory}).ToArray();

    ...

    Спасибо за потраченное время.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[27]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 16.04.12 22:14
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    V>Я знаю, но дело в том, что к концу выражения "останется" только один вариант, т.к. грамматика SQL однозначна.


    Не, ну это понятно. Неоднозначные грамматики с эвристиками (типа тернарного оператора в шарпе или угловых скобок в плюсах, ты это имел ввиду?) это уже точно кандидаты на рукопашное разруливание проблем.

    V> Поэтому я упомянул параллельный LR(1). В нем в месте конфликта происходит размножение текущего состояния вычислителя (полученные копии, кстати, эффективно делят стек предыдущих вычислений), затем "ошибочные ветки" умрут сами собой к концу выражения или еще раньше.


    Да в LL(*), по сути, то же самое. Только вместо внешнего явного состояния стек и исключения. Суть тут одна — парсер с откатами нужен. А это уже, как мне кажется, нельзя назвать простой до безобразия грамматикой.

    V>Я все время забываю, что у этой разновидности LR(k) есть собственное название GLR


    GLR это скорее LR(*). k — количество лексем, на которые парсер заглядывает вперед для принятия решения. В случае откатов, сам понимаешь, к неопределено заранее. Поэтому *.

    AVK>>Ты под параллельными понимаешь парсеры с откатами (параллельным разбором правил) что ли? Тогда LL(k) или LR(k) такие парсеры называть некорректно.


    V>Таки LR(k) — это разбор вширь, а не вглубь, как LL(k).


    Да пофик.

    AVK>>В SQL'92, емнип, больше 6 сотен только для селекта. У меня, когда я выкинул все гавно типа указания кодировок и устаревших форм различных операторов, все равно больше сотни получилось.

    V>Понятно... я навскидку больше пары десятков не вспомню...

    Ну, sql'92 свободно доступен и правила в нем пронумерованы. Можешь сам проверить.

    V>Опять же, мы же обсуждали свой собственный DSL, лишь похожий на SQL


    Ну так большую часть полезных конструкций SQL там реализовать нужно обязательно. Текущее состояние не на ровно месте сформировалось.

    V>, а разработка поддерживаемого этим DSL синтаксиса могла бы быть, скажем так, очень пошаговой.


    Мне показалось в свое время проще сперва получить sql 1 в 1 по стандарту, а потом допилить нужное. Это, помимо прочего, позволило съэкономить на документации, так как достаточно дать ссылку на стандарт и описать только отличия.

    V> Ведь на каждую синтаксическую конструкцию необходимо иметь работающую трансформацию.


    Там много чего надо иметь. Трансформация тоже не самое сложное, хотя и похитрее парсера.

    V>У меня однажды с полпинка заработала аналогичная задача, после перекидывания ее на Пролог. Т.е. захостил движок пролога в программе, скормил ему правила вывода + структуру фактических выражениq с неизвестными и он разресолвил мне все неизвестные.


    ИМХО перебор. Алгоритм вывода типов для типизированного аналога сиквела тривиален — там ведь неоднозначностей никаких нет, в отличие от того же шарпа. А вот ресолвер местами довольно хитер — правила то для сиквела в стандарте отсутствуют, он, типа, динамический. Так что часть из головы надо додумывать, часть смотреть как в реальных sql серверах сделано.
    Но ресолвинг это еще не все. Отдельная песня — проверка агрегатов/неагрегатов при использовании group by. Абсолютно безошибочный алгоритм мне так и не удалось придумать в итоге — там на вложенных запросах очень хитрые ситуации могут получится.

    V>и сами выражения редко более чем в 2-3 уровня склыдваются


    Поверь, совсем нередко.

    V>Надеюсь, повторное использование разработанной технологии в разных проектах были?


    В разных местах проекта. У нас всего один основной проект.

    V> Ну или сам проект кастомизируемый под разных заказчиков (что фактически одно и то же)?


    Хуже, это платформа типа 1С, только намного гибче и сложнее.

    V>Понятно, что вложения должны давать отдачу.


    Там других вариантов не было. Поддержка нескольких разных СУБД — обязательное требование.

    V>развивали этот движок весьма пошагово, по мере поступления новых требований от всё новых и новых проектов, где он многократно использовался.


    Знаешь, я тоже думал схалтурить и не реализовал сперва, скажем, часть стандартных строковых функций или having. Сейчас покрытие вменяемой части SQL'92 — 100%. И висит еще куча фич, которых в sql'92 нет, но есть в реальных серверах, типа выражений в group by.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[28]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 17.04.12 03:30
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    AVK>Хуже, это платформа типа 1С, только намного гибче и сложнее.


    А, ну если про П., то для такого уровня продукта ес-но, требование покрытия функционала максимальные.
    Его сейчас на чем делают, если не секрет? Когда-то, помнится, на Паскале пилили модули (местами успел поучаствовать до 94-го.)
    Re[9]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 17.04.12 04:35
    Оценка: +1
    Здравствуйте, WolfHound, Вы писали:

    V>>Мифы распространяют люди без профильного образования и не потрудившиеся в самостоятельном изучении. Их меньшинство, т.е. это тоже не совсем так.

    WH>Меньшинство? Фигасе. Да их тут армия.

    Знаю многих спецов, не написавших сюда ни строчки.


    WH>Вот только когда запрос становится чуть сложнее, чем на пару строк начинается беда.

    WH>Ибо в SQL нет средств декомпозиции кода.

    И не нужен. Большинство актуальных запросов формируются ТОЛЬКО динамически.... Дык, где тогда должна быть декомпозиция: в SQL или в его генераторе?


    WH>>>Причем недостаток знаний фундаментальная проблема. Ибо часто пока не сделаешь хоть что-то, не поймёшь что действительно нужно.

    V>>Знания тут не при чем. Это такой популярный алгоритм независимо от кол-ва знаний. Действительно, тенденция сравнивать, проверять, расчитывать и т.д. за последние лет 15 куда-то ушла. Не модно. Потому что "мощщи компов все проглотят" и прочая ересь, идущая с сегмента заказухи... которой постепенно заражалась вся индустрия.
    WH>Я не об этом. Многие задачи даже нельзя сформулировать пока ты их решать не начнёшь.

    Очень немногие, подходящие под исследовательские задачи. Может тебя просто больше всего в эту область тянет? Она редка, вообще-то. Большинство задач IT давно сформулированы, но даже с этой формулировкой не хотят знакомиться.


    V>>Для некоторых нужд я бы променял. Только не по физической структуре, а по некоторому АПИ итерирования по данным. Из-за того, что сложные вычисления на SQL не айс, т.к. интерпретатор. А преобразовать реляционные исчисления в реляционные уравнения — не бог весть какая наука. Но это 5% сценариев от силы, т.е. в общем случае таки да, SQL рулит.

    WH>А если тебе дать компилируемый, статически типизированный SQL имеющий средства декомпозиции запросов?
    WH>Это ведь не так сложно.

    Что значит "компиллируемый" в среде, где я могу транзакционно менять структуру базы и прогонять запросы сразу же по новой структуре? В какой момент должна произойти компиляция? Не, я прекрасно понимаю о чем речь, но сценарий использования классической СУБД совсем не тот, что новомодный сценарий хранилища объектов, который "замораживает" структуру данных. База любого мало-мальски большого предприятия постоянно развивается. А уж кол-во накопленных read-only запросов вообще может не поддаваться счету. И всё это развитие происходит "наживую". Плох тот админ, которому требуется монопольный доступ к базе для её модификации.


    WH>>>Есть два десятка цветовых пространств и нужно сгенерировать код по трансформации из каждого в каждое.

    V>>Там точно DSL нужен, а не таблицы составляющих и коэффициентов?
    WH>Таблицами тут не поможешь. Ибо есть куча цветовых пространств преобразования, между которыми очень не линейны. Да хотябы RGB и sRGB. sRGB хорош для восприятия человеком. Но при попытке, например, отмасштабировать в картинку в этом цветовом пространстве появляется куча артефактов. Поэтому нужно переводить в RGB, масштабировать и переводить обратно. Если в картинке есть альфа-канал то там нужно еще кое что сделать. Иначе опять артефакты лезут.

    Что значит "масштабировать"? Любой ресэмплинг неважно в какую сторону предполагает один из алгоритмов фильтрации. А фильтрация ес-но должна быть сугубо покомпонентной. Кодировки с одинаковыми компонентами отличаются от цветоразностных тем, что оперируют одной и той же частотой сглаживания и цветовой глубиной. Альфа-канал — это тоже независимая компонента, по которой над делать независимую фильтрацию.

    WH>Ну и не нужно забывать, что их у меня было 22 (точно не помню) писать 484 преобразования руками, мягко говоря, не хотелось. Так что я задал только несколько преобразований и по определенным правилам сгенерировал все остальные.


    Есно, достаточно одной лишь зависимости, чтобы транзитивно вывести остальные — это св-во линейности преобразований. Но этого мало, ведь при преобразовании м/у кодировками меняется цветовое разрешение.


    WH>Посмотрел что получилось. И добавил еще несколько преобразований, чтобы углы срезать. И так несколько итераций.


    А какие алгоритмы фильтрации использовал? Как боролся с шумом округления? Боролся ли с интерференцией при передискретизации (ресэмплинге?). Вносил ли аддитивный шум при преобразовании к кодировке с меньшим цветовым разрешением? А как ты вообще оценивал изменения эффективной цветовой разрешающей способности при преобразовании м/у стандартами с разными цветовой кодировкой, т.е. как узнать, большая ли получается итоговая цветовая разрешающая способность или нет? А если результат привести в координаты YUV? А если вносил аддитивный шум, как оценивал необходимую амплитуду и спектр этого шума? Использовал ли информацию об исходном DPI изображения?

    В общем, хоть убей не понимаю, где здесь взяться DSL...
    Математические вычисления почти на любом современном ЯП выглядят похоже и вряд ли их лучше представишь в каком-нить DSL.

    WH>А потом еще цветовые пространства появились.

    WH>Без ДСЛ я бы это не осилил.
    WH>Причем ДСЛ был очень циничен. Сами цветовые пространства описывались отдельным язычком. Но вот преобразования прямо в коде на С++.
    WH>После чего я пробегался по исходнику и собирал список базовых преобразований.

    Ну хорошо, а можно посмотреть отрывок этого DSL? Я так думаю, что DSL тебе был нужен для экспериментов и эвристики?


    V>>Ну таки даже по результатам презентации по ссылке хотелось бы увидеть что-нить на входе и что-нить на выходе.

    WH>На входе программа. На выходе проезды по памяти, race condition'ы и тп. И все на основе статического анализа. Причем почти без ложных срабатываний.

    Это понятно, любопытно было увидеть реальные куски кода и найденные в них ошибки. Таки семантика разных языков очень разная.
    Re[29]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 17.04.12 05:05
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    V>Его сейчас на чем делают, если не секрет?


    На C#, как несложно догадаться.

    V> Когда-то, помнится, на Паскале пилили модули (местами успел поучаствовать до 94-го.)


    Это совсем другой продукт. У Паруса их много было и есть.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[9]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 17.04.12 05:06
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:


    V>>ИМХО, SELECT оператор SQL спроектирован превосходно, т.к. обладает реляционной полнотой и при этом отличной читабельностью.


    AVK>С читабельностью, увы, не очень хорошо, особенно в его оригинальной версии.


    А есть примеры языков запросов с лучшей читабельностью?

    Сколько я не смотрел альтернативы в своё время, ничего лучше так и не увидел. Есть неплохой язык реляционного исчисления, популярный во всякой учебной литературе вокруг СУБД, но он (1) так и не формализован до конца, хотя используется чуть ли не как стандарт, (2) это язык все-таки для профессионалов — на нем будет трудно общаться с прикладными специалистами.


    AVK>К сожалению, при его разработке много чего принесли в жертву похожести SQL запросов на естественный язык.


    Это и была цель. И как показала практика — цель правильная. Альтернатив много, но в мейнстриме не прижились.


    AVK>Толку с того вышло немного, а вот дизайн подзасрался основательно. Надо было делать что то вроде того, что сделали в шарпе в query comprehension. Но поезд давно ушел, увы.


    Почему? Альтернативы-то есть... Но вот лучшей я пока не видел.


    V>>ИМХО, это хорошо, что последние годы в кремнии встряли, т.е. не ожидается такого роста быстродействия...


    AVK>Да не встрял никто в кремнии. Просто у Интела исчезла в high end процессорах конкуренция и он начал искусственно тормозить прогресс.


    Чтобы нагнали и нагнули?
    Обсуждали уже пару лет назад. В кремний фактически уперлись. Всего в 3 раза осталось уменьшить процесс, чтобы упереться в его теоретическую границу достоверности, бо мало подвижных зарядов на единицу объема. Ну и пороговое напряжение порядка 0,8В так и не смогли на кремнии побороть, т.е. нет возможности уменьшать рабочее напряжение, а значит проблема с теплоотводом.

    Я так думаю, что это "заговор".
    О новых технологиях более 5-ти лет назад рапортовали все ведущие игроки, но старательно выпускают процессоры на старых технологиях до сих пор...


    V>>Для некоторых нужд я бы променял. Только не по физической структуре, а по некоторому АПИ итерирования по данным. Из-за того, что сложные вычисления на SQL не айс, т.к. интерпретатор.


    AVK>Итерирование по данным, видишь ли, проблематично не из-за SQL, а из-за проблемы обеспечения ACID для таких курсоров.


    Даже если взять снапшот нужных данных (или их промежуточных итогов) во временные таблицы, по потом по ним нетривиальные вычисления идут относительно долго. Относительно классической скомпиллированной числодробилки.
    Re[10]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 17.04.12 05:13
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    AVK>>С читабельностью, увы, не очень хорошо, особенно в его оригинальной версии.


    V>А есть примеры языков запросов с лучшей читабельностью?


    Реальных, очевиджно, нет. Совместимость с sql сейчас важнее.

    V>Сколько я не смотрел альтернативы в своё время, ничего лучше так и не увидел.


    Да убрать из него откровенные косяки, типа select впереди from, и будет уже существенно лучше.

    V>Это и была цель. И как показала практика — цель правильная.


    Практика показала, что всем пофиг на похожесть. Особенно у нас, где английский никогда не был широко распространен.

    V>Почему?


    Потому что стандарт.

    AVK>>Да не встрял никто в кремнии. Просто у Интела исчезла в high end процессорах конкуренция и он начал искусственно тормозить прогресс.


    V>Чтобы нагнали и нагнули?


    В таких вещах быстро не нагоняют.

    V>Обсуждали уже пару лет назад. В кремний фактически уперлись. Всего в 3 раза осталось уменьшить процесс, чтобы упереться в его теоретическую границу достоверности


    Ну вот как уменьшат, иогда и поговорим. А пока интел уменьшает техпроцесс с завидной регулярностью.

    AVK>>Итерирование по данным, видишь ли, проблематично не из-за SQL, а из-за проблемы обеспечения ACID для таких курсоров.


    V>Даже если взять снапшот нужных данных


    Снапшот это невероятно дорого.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[18]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 17.04.12 05:26
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    O> А, ну да, оба из 70х. В любом случае, парсеры это далеко не главное. Драконовщина нанесла непоправимый вред в первую очередь как раз зацикленностью на парсерах.


    Разве? Это была далеко не первая и далеко не последняя работа на эту тему. Просто одна из, заслуженно ставшая популярной.
    Re[25]: Языки общего назначения не имеют смысла!
    От: FR  
    Дата: 17.04.12 05:26
    Оценка: 105 (2) :))
    Здравствуйте, vdimas, Вы писали:


    V>Почему? Смотрел на boost::lambda? Они почти весь синтаксис С++ умудрились сделать как генератор работающего AST. Отличный пример того, как это надо делать и стартовая точка для своих наработок.


    V>Ес-но, для каждого выражения — свой узел. Вот здесь в двойных скобках приводил в примере именно генерацию AST, которое исполняется "потом":


    Не так давно зарелизился Boost.Phoenix 3.0 там практически полностью
    ленивый (привет хаскелю ) встроенный в C++ DSL, и AST там гораздо богаче чем в boost::lambda, есть все конструкции языка практически,
    в примере ниже они с _ в конце (if_, switch_ и т. п.)

    std::for_each(v.begin(), v.end(),
        if_(arg1 > 5)
        [
            std::cout << arg1 << ", "
        ]
    );
    
    //...
    
    std::for_each(c.begin(), c.end(),
        switch_(arg1)
        [
            case_<1>(std::cout << val("one") << '\n'),
            case_<2>(std::cout << val("two") << '\n'),
            default_(std::cout << val("other value") << '\n')
        ]
    );
    
    //...
    
    std::for_each(c.begin(), c.end(),
        (
            while_(arg1--)
            [
                cout << arg1 << ", "
            ],
            cout << val("\n")
        )
    );
    Re[19]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 17.04.12 05:52
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Проблема в драконе в том, что не смотря на ширату охвата и системность изложения, книга сугубо не практическая. В ней многие вещи описаны так заумно, что толку от чтения нет. А многие вещи просо упущены из виду.


    Ширина охвата так себе. Книга хороша именно своей практичностью. Показывает как от теории переходить к практике. А так-то полно других работ из этой же области, с разной глубиной по разным темам (порой многократно глубже).


    VD>Парсерам же вообще уделяется слишком много внимания в литературе посвященной компиляторам и языкам. Мне кажется это следствием того, что человечество до сих пор не нашло приемлемого решения этой проблемы. А проблема эта возникает самой первой при разработке языка.


    И не найдет.
    Чем "естественнее" язык, тем он неоднозначнее и сложнее для автоматического разбора. ИМХО, с ростом мощности компьютера стоит ожидать роста сложности обрабатываемых грамматик.


    VD>Наука она идет путем перебора всех возможных вариантов (за счет того, что каждый аспирант ищет тему для дисера, которая не пересекается с другими дисерами).


    Просто сейчас появились возможности для экспериментов, т.к. память больше не ресурс (С). Отсюда все эти эксперименты мемоизацией или распараллеливанием, немыслимые еще 10 лет назад.

    Заметь, приличная часть дракона посвящена вопросам преобразования грамматик, чтобы впихнуть исходную грамматику в некие рамки, которые будут означать банальную реализуемость на технике тех лет.
    Re[30]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 17.04.12 06:12
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    AVK>Это совсем другой продукт. У Паруса их много было и есть.


    Т.е. не 8-ка? Хорошо, а 8-ка на чем, если не секрет?

    ============
    Просто пример Паруса был антипример в теме о "доступности" DSL, бо как раз показывает необходимый размах проекта, чтобы DSL был оправдан.
    Re[10]: Языки общего назначения не имеют смысла!
    От: Andrei N.Sobchuck Украина www.smalltalk.ru
    Дата: 17.04.12 06:13
    Оценка:
    Здравствуйте, Pavel Dvorkin, Вы писали:

    PD>Язык.


    Ок. Я просто требование по быстродействию не зря пропустил. Любую технологию можно загнобить сказав "а-а-а. оно не может доработать за х наносекунд",
    Я думаю ты спорить не будешь, что написать какой-то "эффект" на Adobe Pixel Blender будет проще, чем его же на C. А в конечном итоге оно даже работать может быстрее, просто потому, что во много кода можно напартачить.

    Но в общем спорить никто не будет, что если действительно встанет вопрос оптимизации, то в конечном итоге можно дойти и до низкоуровневого программирования.
    Я ненавижу Hibernate
    Автор: Andrei N.Sobchuck
    Дата: 08.01.08
    !
    Re[25]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 17.04.12 06:14
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    V>Это пока нам не надо повторно использовать код. А то в итоге может оказаться наоборот 30 к 1 в итоге.



    V>Таки я хорошо помню, что ручками делал гораздо больше, чем могу себе позволить обобщить на шаблонах С++ сегодня. И никакой оптимизации тоже не было, ес-но, было тупое сканирование файлов данных или файлов-индексов и обработка согласно самописных алгоритмов. Так же помню, что копипасты было много.

    Ну так и в C++ никакой оптимизации запросов не было. Да, копипасты было полно, но у интерпретатора есть свои преимущества — насколько я помню, на клиппере были доступны всякие забавные трюки, связанные с различным поведением функций вызываемых в различных контекстах. Бест практисов я тогда не знал, и глобальными переменными пользовался в полный рост.

    V>Почему? Смотрел на boost::lambda? Они почти весь синтаксис С++ умудрились сделать как генератор работающего AST. Отличный пример того, как это надо делать и стартовая точка для своих наработок.

    Нет, не смотрел. И с трудом представляю себе, как это работает.

    V>Ес-но, для каждого выражения — свой узел. Вот здесь в двойных скобках приводил в примере именно генерацию AST, которое исполняется "потом":

    V>
    V>( (_1.managerId=_2.first, _1.amount=sum(_2.second, &Order::amount)) ) 
    V>

    Ну, вот уже пошёл птичий язык. Все эти подчерки и неименованные туплы читаются намного-намного хуже старого доброго SQL.

    V>Как раз для приведенной мною ф-ии between ничего не нужно в отличие от генерации трансформаторов для проекций, продукций и пересечений, т.к. это просто перегрузка ее сигнатуры для случая на указателя на мембер, которая должна конструировать MemberBetweenPredicate (кстате, приведенный исключительно с целью показать, во что превратится вызов between).

    Во-первых, придётся иметь 8 перегрузок этого предиката. Ведь никогда не знаешь заранее, на каком месте будет стоять мембер.

    V>Теперь, при наличии у некоего типа, используемого для представления даты, конструктора от С-строки, можно писать еще короче:

    V>
    V>between("20100101", &Order::orderDate, "20101231")
    V>

    Во-вторых, а дальше-то что? Вот мы имеем этот предикат. Как нам использовать его для выбора индекса для сканирования?
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[29]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 17.04.12 06:26
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    V>На gcc, icc и многих других компиляторах получится. Причем, зависимости от CRT указывать не надо, в отличие от зависимостей от других либ, бо стандартные ф-ии обязаны работать "изкаробки". Я уже обращал внимание на то, что если другие либы надо указывать в параметрах компилятора или линкера для включения, то относительно CRT опции чуть другие по характеру — это опции отключения CRT или выбора типа CRT.

    Компилятор не имеет права самовольно включать CRT в .obj — он не в курсе, сколько ещё будет единиц компиляции.

    V>Это имеет отношение к твоему утверждению, что С/С++ так же подойдет на роль DSL. Не подойдет, т.к. нет каких-либо ср-в ограничить исходный код.

    Я не делал такого утверждения. Я делал утверждение про то, что отсутствие импорта библиотек не помогает для DSLности, как и его наличие не помогает выйти за пределы DSLности.

    V>Я не игнорирую, я вижу что ты успел забыть на какие твои вопросы я даю ответы. Ты сделал кое-какие утверждения относительно С? Я не согласился и объяснил — почему. Потому что изкаробки слишком много возможностей, даже без внешних библиотек — из-за CRT и адресной арифметики ф-ий.

    Сосредоточьтесь. Я вам напомню — мы обсуждаем, годится ли "возможность использовать библиотеки" в качестве критерия DSL. Пока что выходит, что никак не годится.

    V>Мы недообсуждали Лого, чтобы делать такие выводы. Я еще не увидел твоего примера целиком. Покажи предположительный синтаксис вызова произвольных внешних ф-ий для "расширенного Лого", а затем я тебе дам небольшой список экспорта, например, NT.DLL, с помощью которого можно уронить любую, самую защищенную программную среду.

    Непонятно, что вы называете "произвольными внешними функциями". Мы имеем стандартный логовский синтаксис вызова функций/процедур:
    FORWARD 100
    LEFT 90

    Плюс мы имеем стандартный синтаксис объявления функций и процедур:
    TO CHAIR  REPEAT 4 [FD 100 RT 90]  FD 200  END

    Плюс мы имеем команду IMPORT, которая втягивает лого-библиотеку, делая видимыми все функции и процедуры, определённые в них.
    Никакого синтаксиса для загрузки NT.DLL нет.

    S>>Совершенно верно. Поэтому изо всех языков, работающих с DOM, DSL-ями являются только CSS и XSLT. JS, как и С и C++, это типичный GPPL.


    V>Опять по кругу... Если бы C/C++ не обладали CRT/CppRT, идущими как часть стандарта, и не имели адресной арифметики ф-ий, позволяющей передать управление куда угодно, я бы согласился. А так — нет.

    То есть вы не считаете C++ языком общего назначения? Очень странно.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[42]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 17.04.12 06:28
    Оценка:
    Здравствуйте, Vain, Вы писали:

    V>Ничего такого здесь не подразумевалось. Речь шла про SQL как про DSL который можно сунуть везде и это прокатит.

    Впервые об этом слышу. Кто вам сказал такую глупость? DSL, по определению, нельзя "сунуть везде".
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[31]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 17.04.12 06:47
    Оценка: 6 (1)
    Здравствуйте, vdimas, Вы писали:

    AVK>>Это совсем другой продукт. У Паруса их много было и есть.


    V>Т.е. не 8-ка?


    Нет, 10-ка ака Торнадо.

    V> Хорошо, а 8-ка на чем, если не секрет?


    Дельфи + Оракл.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[10]: Языки общего назначения не имеют смысла!
    От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
    Дата: 17.04.12 07:02
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    V>Здравствуйте, AndrewVK, Вы писали:



    V>>>ИМХО, SELECT оператор SQL спроектирован превосходно, т.к. обладает реляционной полнотой и при этом отличной читабельностью.


    AVK>>С читабельностью, увы, не очень хорошо, особенно в его оригинальной версии.


    V>А есть примеры языков запросов с лучшей читабельностью?

    Linq?
    и солнце б утром не вставало, когда бы не было меня
    Re[26]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 17.04.12 07:07
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    V>>Почему? Смотрел на boost::lambda? Они почти весь синтаксис С++ умудрились сделать как генератор работающего AST. Отличный пример того, как это надо делать и стартовая точка для своих наработок.

    S>Нет, не смотрел. И с трудом представляю себе, как это работает.

    Работает несложно. В С++ принято считать "исполняемым" любой тип с определенным в нем operator() (оператор вызова ф-ии). В общем, это обычный метод со специальным именем, типа как Invoke у делегатов дотнета.
    Простой пример вот:
    template<typename Value>
    struct BetweenPredicate { 
      Value v1, v2; 
      bool operator()(const Value & v) { return  v>=v1 && v<=v2; } 
    };

    Это один из подобных самописных узлов исполняемого AST. Надо проинициализировать "замкнутые" значения v1, v2, а затем рассматривать этот объект как функтор с арностью 1.

    Представь на C# value-типы с методом Invoke:
    struct PlusOp<T> {
      public T arg1, arg2;
      T Invoke() { return arg1 + arg2; }  
    }


    Жаль, что в дотнете так нельзя, но в С++ можно. В дотнете нужно выкручиваться через какой-нить OperatorProxy<T>.Default.Plus(arg1, arg2);

    S>Ну, вот уже пошёл птичий язык. Все эти подчерки и неименованные туплы читаются намного-намного хуже старого доброго SQL.


    Дык, в старом добром SQL даже номеров переменных в тупле нет, он сугубо позиционный. В широких запросах пальчиком по экрану надо водить и номер аргумента считать, чтобы не промазать.
    Хотя, спорить не буду, с непривычки нечитабельно.


    V>>Как раз для приведенной мною ф-ии between ничего не нужно в отличие от генерации трансформаторов для проекций, продукций и пересечений, т.к. это просто перегрузка ее сигнатуры для случая на указателя на мембер, которая должна конструировать MemberBetweenPredicate (кстате, приведенный исключительно с целью показать, во что превратится вызов between).

    S>Во-первых, придётся иметь 8 перегрузок этого предиката. Ведь никогда не знаешь заранее, на каком месте будет стоять мембер.

    Для библиотеки не жалко. Только я бы, по праву автора библиотеки, ограничил бы вдвое, чтобы в середине всегда был мембер.


    S>Во-вторых, а дальше-то что? Вот мы имеем этот предикат. Как нам использовать его для выбора индекса для сканирования?


    Зависит от отображения типов на хранилище. Если используем какой-нить boost::multiindex, то на нем как раз индексы можно описать через мемберы хранимых элементов (т.е. ключ не дублируется, в отличие от std::map<> или System::Dictionary<>).

    В общем, ничего нового под луной: чем меньше захардкожено в отображениии типов и соотв. хранилища под его экземпляры, тем больше потребуется метаинформации. Обычно метаинформацию о типах С++ организуют как инстансы неких описательных структур, в которых хранятся опять же указатели на мемберы типа.
    Re[35]: Языки общего назначения не имеют смысла!
    От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
    Дата: 17.04.12 07:40
    Оценка: :)
    Здравствуйте, WolfHound, Вы писали:

    I>>Например на ней легко делать рекурсивные запросы любой глубины и сложности.

    I>>На реляционной надо сначала приседать с запросом,
    WH>Это зависит от языка.

    И много языков умеет сервер рсубд ?

    I>>потом приседать с перформансом запроса.

    WH>А в объектной модели, которая маппится на реляционную БД все будет просто летать?

    когда, куда и как сохранится модель персистентных объектов это дело десятое. Главное что в ней многие вещи делать проще и перформанс искаропки.
    Re[36]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 17.04.12 07:58
    Оценка:
    Здравствуйте, Ikemefula, Вы писали:

    I>И много языков умеет сервер рсубд ?

    Зачем сервер?

    I>когда, куда и как сохранится модель персистентных объектов это дело десятое. Главное что в ней многие вещи делать проще и перформанс искаропки.

    То-то народ плачет глядя на то как тяжёлые ОРМ тормозят.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[10]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 17.04.12 08:18
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    V>>>Мифы распространяют люди без профильного образования и не потрудившиеся в самостоятельном изучении. Их меньшинство, т.е. это тоже не совсем так.

    WH>>Меньшинство? Фигасе. Да их тут армия.
    V>Знаю многих спецов, не написавших сюда ни строчки.
    А сколько таких кого ты не знаешь?
    Короче ты нерепрезентативен. Твой маааленький круг общения тоже.

    WH>>Ибо в SQL нет средств декомпозиции кода.

    V>И не нужен. Большинство актуальных запросов формируются ТОЛЬКО динамически.... Дык, где тогда должна быть декомпозиция: в SQL или в его генераторе?
    Осталось понять, почему они формируются динамически.

    V>Что значит "компиллируемый" в среде, где я могу транзакционно менять структуру базы и прогонять запросы сразу же по новой структуре? В какой момент должна произойти компиляция? Не, я прекрасно понимаю о чем речь, но сценарий использования классической СУБД совсем не тот, что новомодный сценарий хранилища объектов, который "замораживает" структуру данных. База любого мало-мальски большого предприятия постоянно развивается. А уж кол-во накопленных read-only запросов вообще может не поддаваться счету. И всё это развитие происходит "наживую".

    И это вызывает массу проблем.
    Все запросы должны быть проверены на соответствие новой структуре БД.
    Иначе получишь вылеты в рантайме. Динамическая типизация во всей красе.

    V>Плох тот админ, которому требуется монопольный доступ к базе для её модификации.

    Плох тот админ, который руками в продакшен базу лезет.
    Обновления в продакшен должны выкатываться только после тестирования.

    V>Что значит "масштабировать"? Любой ресэмплинг неважно в какую сторону предполагает один из алгоритмов фильтрации. А фильтрация ес-но должна быть сугубо покомпонентной. Кодировки с одинаковыми компонентами отличаются от цветоразностных тем, что оперируют одной и той же частотой сглаживания и цветовой глубиной. Альфа-канал — это тоже независимая компонента, по которой над делать независимую фильтрацию.

    Теоретик.
    Вот что получается, если альфу игнорировать.

    А так если нет.


    V>Есно, достаточно одной лишь зависимости, чтобы транзитивно вывести остальные — это св-во линейности преобразований. Но этого мало, ведь при преобразовании м/у кодировками меняется цветовое разрешение.

    Смешно. Ибо многие преобразования нелинейные.

    V>Ну хорошо, а можно посмотреть отрывок этого DSL?

    Нельзя. У меня на руках исходников нет. Они все в конторе остались.

    V>Я так думаю, что DSL тебе был нужен для экспериментов и эвристики?

    Нет. Для продакшена.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[27]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 17.04.12 08:21
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    V>Работает несложно. В С++ принято считать "исполняемым" любой тип с определенным в нем operator() (оператор вызова ф-ии). В общем, это обычный метод со специальным именем, типа как Invoke у делегатов дотнета.

    V>Простой пример вот:
    V>
    V>template<typename Value>
    V>struct BetweenPredicate { 
    V>  Value v1, v2; 
    V>  bool operator()(const Value & v) { return  v>=v1 && v<=v2; } 
    V>};
    V>

    V>Это один из подобных самописных узлов исполняемого AST. Надо проинициализировать "замкнутые" значения v1, v2, а затем рассматривать этот объект как функтор с арностью 1.
    Это мне как раз понятно. Непонятно, как будет работать оптимизация. На всякий случай напомню вам, что задачи "вызывать" этот функтор у нас не стоит. Вместо него должна быть выполнена операция index seek по подходящему индексу.
    В C# всё как раз гораздо лучше — есть понятие Expression Tree, которое заполняется при построении лямбды, и я могу его потом интроспектировать.

    V>Для библиотеки не жалко. Только я бы, по праву автора библиотеки, ограничил бы вдвое, чтобы в середине всегда был мембер.



    V>Зависит от отображения типов на хранилище. Если используем какой-нить boost::multiindex, то на нем как раз индексы можно описать через мемберы хранимых элементов (т.е. ключ не дублируется, в отличие от std::map<> или System::Dictionary<>).

    Ладно, поверю вам на слово. Хотя есть много подводных камней — т.к. всё, что у нас есть, это указатель на мембер (грубо говоря, какие-то там два поинтера), который нельзя персистить, ведь он может меняться от запуска к запуску. Придётся придумывать специальную процедуру инициализации, которая сможет связать физически хранимый индекс с его ключами, выраженными в виде набора указателей на мемберов.

    V>В общем, ничего нового под луной: чем меньше захардкожено в отображениии типов и соотв. хранилища под его экземпляры, тем больше потребуется метаинформации. Обычно метаинформацию о типах С++ организуют как инстансы неких описательных структур, в которых хранятся опять же указатели на мемберы типа.

    Ну, понятно. То есть DDL у нас опять же получается довольно-таки ужасным.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[20]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 17.04.12 08:23
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    V>Заметь, приличная часть дракона посвящена вопросам преобразования грамматик, чтобы впихнуть исходную грамматику в некие рамки, которые будут означать банальную реализуемость на технике тех лет.

    Брееед! TDOP прост как пробка и ресурсы не ест.
    Они просто не знали. Или не хотели замечать то, что не сводится к куче матана.
    Более того если бы они показали людям TDOP их с их автоматными парсерами просто послали бы куда подальше.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[37]: Языки общего назначения не имеют смысла!
    От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
    Дата: 17.04.12 09:57
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    I>>И много языков умеет сервер рсубд ?

    WH>Зачем сервер?

    mysql, так сгодится ? Много ли он языков умеет ?

    I>>когда, куда и как сохранится модель персистентных объектов это дело десятое. Главное что в ней многие вещи делать проще и перформанс искаропки.

    WH> То-то народ плачет глядя на то как тяжёлые ОРМ тормозят.

    Плачет, еще как. Реляционная модель в принципе не предполагает перформанс в тех запросах, которые я указал.
    Re[43]: Языки общего назначения не имеют смысла!
    От: Vain Россия google.ru
    Дата: 17.04.12 10:19
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    V>>Ничего такого здесь не подразумевалось. Речь шла про SQL как про DSL который можно сунуть везде и это прокатит.

    S>Впервые об этом слышу. Кто вам сказал такую глупость? DSL, по определению, нельзя "сунуть везде".
    на название топика посмотрите.
    [In theory there is no difference between theory and practice. In
    practice there is.]
    [Даю очевидные ответы на риторические вопросы]
    Re[11]: Языки общего назначения не имеют смысла!
    От: Pavel Dvorkin Россия  
    Дата: 17.04.12 10:19
    Оценка:
    Здравствуйте, Andrei N.Sobchuck, Вы писали:

    ANS>Здравствуйте, Pavel Dvorkin, Вы писали:


    PD>>Язык.


    ANS>Ок. Я просто требование по быстродействию не зря пропустил. Любую технологию можно загнобить сказав "а-а-а. оно не может доработать за х наносекунд",

    ANS>Я думаю ты спорить не будешь, что написать какой-то "эффект" на Adobe Pixel Blender будет проще, чем его же на C.

    Не буду. Проще можно, но будет хуже (по скорости).

    >А в конечном итоге оно даже работать может быстрее, просто потому, что во много кода можно напартачить.


    Если партачить, то все будет хуже. Надо не партачить, а тогда быстрее не будет. Чудес не бывает. Там нужно выполнить определенный набор команд сколько-то миллионов раз, и чем меньше будет посторонних команд, тем быстрее будет.

    ANS>Но в общем спорить никто не будет, что если действительно встанет вопрос оптимизации, то в конечном итоге можно дойти и до низкоуровневого программирования.


    Нет, С мне вполне хватило, на асме не писал.
    With best regards
    Pavel Dvorkin
    Re[38]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 17.04.12 10:24
    Оценка:
    Здравствуйте, Ikemefula, Вы писали:

    I>>>И много языков умеет сервер рсубд ?

    WH>>Зачем сервер?
    I>mysql, так сгодится ? Много ли он языков умеет ?
    Ох. Мы и сами язык сделать можем. После чего транслировать его в SQL.
    Тоже мне бином Ньютона.

    I>Плачет, еще как. Реляционная модель в принципе не предполагает перформанс в тех запросах, которые я указал.

    Ничего ты не указал.
    А учитывая, что у AVK все лежит в РБД никакого перформанса не будет.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[20]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 17.04.12 11:52
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    V>Ширина охвата так себе. Книга хороша именно своей практичностью. Показывает как от теории переходить к практике. А так-то полно других работ из этой же области, с разной глубиной по разным темам (порой многократно глубже).


    Ни хрена там практического нет.


    VD>>Парсерам же вообще уделяется слишком много внимания в литературе посвященной компиляторам и языкам. Мне кажется это следствием того, что человечество до сих пор не нашло приемлемого решения этой проблемы. А проблема эта возникает самой первой при разработке языка.


    V>И не найдет.


    Ну, да. Если игнорировать наличие нашей реализации, то можно любые выводы сделать.

    V>Чем "естественнее" язык, тем он неоднозначнее и сложнее для автоматического разбора. ИМХО, с ростом мощности компьютера стоит ожидать роста сложности обрабатываемых грамматик.


    Что значит "естественнее"? У понятия естественный язык есть четко значение. Русский, Английский и т.п., вот естественные языки. Вот только они не имеют отношения к копьютерным языкам. Там свои проблемы.

    Для парсинга же компьютерных языков есть https://github.com/rampelstinskin/ParserGenerator. Ну, и АНТЛР тоже сгодится, если не нужна расширяемость.

    VD>>Наука она идет путем перебора всех возможных вариантов (за счет того, что каждый аспирант ищет тему для дисера, которая не пересекается с другими дисерами).


    V>Просто сейчас появились возможности для экспериментов, т.к. память больше не ресурс (С). Отсюда все эти эксперименты мемоизацией или распараллеливанием, немыслимые еще 10 лет назад.


    Тебе конечно виднее, но вот алгоритм который в итоге получился у Вольфхаунда использует константный объем памяти и обеспечивает при этом весьма высокую производительность.

    V>Заметь, приличная часть дракона посвящена вопросам преобразования грамматик, чтобы впихнуть исходную грамматику в некие рамки, которые будут означать банальную реализуемость на технике тех лет.


    Эти вопросы никого больше не интересуют. Я наткнулся даже на такую мысль — в нашей системе почти стирается грань между деревом разбора (Parse Tree) и AST, так как у нас просто нет тех проблем, что присуттвуют в BNF (порождающих грамматиках). За счет богатого синтаксиса/семантики и отсутствия неоднозначностей наше дерево разбора получается практически эквивалентным AST. Разве что скобки мы не уничтожаем. Но они вряд ли сильно помешают преобразованиям. А вот проблем пустых переходов у нас нет, так как нет нужды делать пустые правила обеспечивающие устранение неоднозначностей в грамматиках. Да и самой проблемы переписывать грамматику так, чтобы что-то там обходить у нас нет. Операторы описываются приоритетами, есть циклы и необязательные подправила, и вообще нет пустых подправил.

    В общем, в наша реализация полностью устраняет проблему написания парсеров.

    Остается приделать такую же высокоуровневвую систему типизации, систему трансформации и получится великолепный мета-язык для описания любых языков программирования (как ЯОН, так и ДСЛ).

    Так что остается только одна проблема. Как заставить неверующих Фом хотя бы взглянуть на то, что у нас получается. Я уже не говорю об использовании.

    В этом перевернутом с ног на голову мире без бабла и пиара трудно пропихнуть новую идею.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[39]: Языки общего назначения не имеют смысла!
    От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
    Дата: 17.04.12 12:30
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    I>>mysql, так сгодится ? Много ли он языков умеет ?

    WH>Ох. Мы и сами язык сделать можем. После чего транслировать его в SQL.
    WH>Тоже мне бином Ньютона.

    Значит всё таки SQL ? Ну тогда покажи мне SQL который будет выполнять какой нибудть итерационный алгоритм на графах заодно покажи кусочек DSL который будет генерить это дело.

    I>>Плачет, еще как. Реляционная модель в принципе не предполагает перформанс в тех запросах, которые я указал.

    WH>Ничего ты не указал.
    WH>А учитывая, что у AVK все лежит в РБД никакого перформанса не будет.

    Значит ему нужна простая работа с объектным деревом, а не только перформанс. Меня же интересует в основном перформанс. Что бы было понятно — объектна модель искаропки позволяет выполнить запрос за время меньшее чем самый банальный селект со всеми индексами, кешами и прочей ерундой.
    Re[28]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 17.04.12 12:33
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>Это мне как раз понятно. Непонятно, как будет работать оптимизация. На всякий случай напомню вам, что задачи "вызывать" этот функтор у нас не стоит. Вместо него должна быть выполнена операция index seek по подходящему индексу.

    S>В C# всё как раз гораздо лучше — есть понятие Expression Tree, которое заполняется при построении лямбды, и я могу его потом интроспектировать.

    А каков механизм "интроспекции"? Как обходить будешь на дотнете? Ну т.е. строить самый первый план запросов? В общем, для плюсов доступна т.н. техника "статического визитора", которая не совсем является классическим вихитором, но устойчиво так называют из-за статического ad-hoc полиморфизма:
    template<Builder builder, typename Entity, typename Value>
    void visit(Builder * builder, MemberBetweenPredicate<Entity, Value> betweenExp) {
      builder->onMemberBetweenExp(betweenExp);
      visit(builder, betweenExp.member);
    }
    
    template<Builder builder, typename Entity1, typename Value1, typename Entity2, typename Value2>
    void visit(Builder * builder, boost::lambda::expression::equal<Entity1, Value1, Entity2, Value2> equalOp) {
      builder->onEqualOp(equalOp);
      visit(builder, equalOp.left); 
      visit(builder, equalOp.right);
    }
    ...


    Тип equal я привел условно, неохота листать исходники boost:lambda для точного имени аналогичного типа, просто показал принцип. Но это мы уже глубоко в детали подались.

    V>>Для библиотеки не жалко. Только я бы, по праву автора библиотеки, ограничил бы вдвое, чтобы в середине всегда был мембер.

    S>

    V>>Зависит от отображения типов на хранилище. Если используем какой-нить boost::multiindex, то на нем как раз индексы можно описать через мемберы хранимых элементов (т.е. ключ не дублируется, в отличие от std::map<> или System::Dictionary<>).

    S>Ладно, поверю вам на слово. Хотя есть много подводных камней — т.к. всё, что у нас есть, это указатель на мембер (грубо говоря, какие-то там два поинтера), который нельзя персистить, ведь он может меняться от запуска к запуску.

    Не факт что в задаче персистить от запуска к запуску надо... Я же говорю — уже пошло слишком много деталей на одного меня. Если любопытно, загляни в доку к boost::serialization. Выглядит это так (из примера):
    class gps_position
    {
        friend class boost::serialization::access;
        friend std::ostream & operator<<(std::ostream &os, const gps_position &gp);
    
        int degrees;
        int minutes;
        float seconds;
    
        template<class Archive>
        void serialize(Archive & ar, const unsigned int /* file_version */){
            ar  & BOOST_SERIALIZATION_NVP(degrees)
                & BOOST_SERIALIZATION_NVP(minutes)
                & BOOST_SERIALIZATION_NVP(seconds);
        }
    
    public:
        // every serializable class needs a constructor
        gps_position(){};
        gps_position(int _d, int _m, float _s) : 
            degrees(_d), minutes(_m), seconds(_s)
        {}
    };


    Метод void serialize<>() вызывается для любого типа-архива как во время сериализации, так и для десериализации.
    Вот пример исопльзования этого типа с XML-сериализацией: http://www.boost.org/doc/libs/1_43_0/libs/serialization/example/demo_xml.cpp
    Вот результат: http://www.boost.org/doc/libs/1_39_0/libs/serialization/example/demo_save.xml

    Отрывок из результата в XML:
    <longitude>
      <degrees>134</degrees>
      <minutes>22</minutes>
      <seconds>78.300003</seconds>
    </longitude>



    S>Придётся придумывать специальную процедуру инициализации, которая сможет связать физически хранимый индекс с его ключами, выраженными в виде набора указателей на мемберов.


    В любом случае для персиста потребуется арнтайм-метаинформация не только о типах прикладного языка, но и о структуре хранилища и об их взаимном ORM.В каком виде идет эта информация — не принципиально. ORM для C++ можно делать в технике, похожей на технику сериализации (это фактически одно и то же).


    V>>В общем, ничего нового под луной: чем меньше захардкожено в отображениии типов и соотв. хранилища под его экземпляры, тем больше потребуется метаинформации. Обычно метаинформацию о типах С++ организуют как инстансы неких описательных структур, в которых хранятся опять же указатели на мемберы типа.

    S>Ну, понятно. То есть DDL у нас опять же получается довольно-таки ужасным.

    Не очень. Компиляторы давно научились "склеивать" идентичный код, порожденный шаблонами для разных типов. Первые компиляторы С++ действительно порождали ОЧЕНЬ МНОГО бинарного кода, уникального для каждого инстанса шаблонной ф-ии или метода.
    Re[21]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 17.04.12 13:01
    Оценка: :)
    Здравствуйте, WolfHound, Вы писали:

    V>>Заметь, приличная часть дракона посвящена вопросам преобразования грамматик, чтобы впихнуть исходную грамматику в некие рамки, которые будут означать банальную реализуемость на технике тех лет.

    WH>Брееед! TDOP прост как пробка и ресурсы не ест.

    Это LALR или LL(1) ресурсы не ест.


    WH>Они просто не знали. Или не хотели замечать то, что не сводится к куче матана.

    WH>Более того если бы они показали людям TDOP их с их автоматными парсерами просто послали бы куда подальше.

    Дык, Пратт его показал в каком-то махровом 70-м году и никто ни кого не послал. Ведь Дракон — лишь одна из мн-ва работ на эту тему, но почему-то стала более популярной... Не насильно же...
    А теоретических работ по детерминированному парсингу недетерминированных грамматик хватало, от Ахо в т.ч. И там же 100 раз говорилось, что у всех этих "приоритетных" грамматик, в отличие от однозначных, трудно вывести св-ва грамматики. И практически невозможно доказать сохранение эквивалентности грамматики во время преобразований (например факторизации), бо упираемся в проблему останова и т.д.

    Ну и самое главное, существующие ЯП позволяют решать синтаксические неоднозначности на семантическом уровне, что НАДЕЖНЕЕ, чем это:

    Так правило "кто длиннее тот и прав" разрешает чуть менее чем все конфликты.

    Re[21]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 17.04.12 13:13
    Оценка: :)
    Здравствуйте, VladD2, Вы писали:


    VD>Так что остается только одна проблема. Как заставить неверующих Фом хотя бы взглянуть на то, что у нас получается. Я уже не говорю об использовании.

    VD>В этом перевернутом с ног на голову мире без бабла и пиара трудно пропихнуть новую идею.

    Влад, ты хоть представляешь, сколько уже было работ на тему детерминированного разбора недетерминированных грамматик? TDOP уже порядка 30-ти лет.

    Я уже рядом ответил — всё упирается в св-ва получаемой грамматики. Для приоритетных грамматик вывести их св-ва практически невозможно. Поэтому как практический прием — вполне сойдет, а теоретическое док-во придется еще подождать.

    Опять же, надо смотреть чуть шире на происходящее. Алгоритмы типа LL(k), GLR или LALR и так прекрасно подходят зачастую, при том что, никто ничем не рискует (давно уже всё изведано) и скорость парсинга неплохая. Станет некий программный архитектор выбирать "темную лошадку" в кач-ве технологии, если есть извеcтные и доказанно-работающие решения? Ну разве что от зашкаливания авантюризма... Тем более, что в том же в компиляторе С++ парсинг занимает единицы % от всего времени компиляции...
    Re[11]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 17.04.12 13:35
    Оценка: :)
    Здравствуйте, WolfHound, Вы писали:


    WH>>>Ибо в SQL нет средств декомпозиции кода.

    V>>И не нужен. Большинство актуальных запросов формируются ТОЛЬКО динамически.... Дык, где тогда должна быть декомпозиция: в SQL или в его генераторе?
    WH>Осталось понять, почему они формируются динамически.

    Требования изменяются динамически.
    Но это не важно. Мне интересно, какая проблема рассматривать SQL как язык промежуточного протокола к базе? Тем более, что это так и есть.


    WH>Все запросы должны быть проверены на соответствие новой структуре БД.

    WH>Иначе получишь вылеты в рантайме. Динамическая типизация во всей красе.

    Для read-only запросов не страшно.

    V>>Плох тот админ, которому требуется монопольный доступ к базе для её модификации.

    WH>Плох тот админ, который руками в продакшен базу лезет.
    WH>Обновления в продакшен должны выкатываться только после тестирования.

    Они и выкатываются после тестирования. Но это никак не отменяет возможной динамики происходящего.
    Я вообще не вижу проблем с декомпозицией построителя запросов. Тем более, что как раз писали генератор SQL и во многих проектах юзали. Очень удобно декомпозировать запросы на прикладном уровне, со стороны O, а не со стороны R в действе, под названием ORM.


    V>>Что значит "масштабировать"? Любой ресэмплинг неважно в какую сторону предполагает один из алгоритмов фильтрации. А фильтрация ес-но должна быть сугубо покомпонентной. Кодировки с одинаковыми компонентами отличаются от цветоразностных тем, что оперируют одной и той же частотой сглаживания и цветовой глубиной. Альфа-канал — это тоже независимая компонента, по которой над делать независимую фильтрацию.

    WH>Теоретик.
    WH>Вот что получается, если альфу игнорировать.
    WH>
    WH>А так если нет.
    WH>

    Ничего не понял... Что значит "игнорировать альфу"? Можно поинтересоваться, какой алгоритм фильтрации при ресэмплинге ты сейчас критикуешь, а какой тебе показался лучше? А то, глядя на пример, я уже начинаю подозревать, что ты пытаешься сравнивать "тупой" ресэмплинг на целочисленных операциях с ресэмплнгом, использующим хоть какую-то фильтрацию.

    V>>Есно, достаточно одной лишь зависимости, чтобы транзитивно вывести остальные — это св-во линейности преобразований. Но этого мало, ведь при преобразовании м/у кодировками меняется цветовое разрешение.

    WH>Смешно. Ибо многие преобразования нелинейные.

    Ну, в обработке сигналов нелинейными считаются преобразования, которые не позволяют делать взаимно-обратные преобразования. Например, взятие модуля числа — нелинейное преобразование. А коррекция гаммы в этом плане однозначна в обе стороны.


    V>>Ну хорошо, а можно посмотреть отрывок этого DSL?

    WH>Нельзя. У меня на руках исходников нет. Они все в конторе остались.

    Мог бы по памяти привести пару отрывков или условный код? Бо пример твой уж очень специфический. Я хоть и за DSL, но пытаюсь понять, при чем он тут для этой задачи.
    Re[24]: Языки общего назначения не имеют смысла!
    От: Andrei N.Sobchuck Украина www.smalltalk.ru
    Дата: 17.04.12 14:40
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:


    ANS>>В твоём примере, в один проход втиснуто много операций /бизнес-логики/.

    AVK>Непонятно. А чем будет полезно много проходов?

    Так я как бы про это написал. Если ты разобъёш эту функцию на несколько кусков, чтобы каждая представляла элементарную-бизнес операцию, то у тебя просядет производительность. В результате, из-за навигационного API у тебя возникает вопрос, что лучше получить читаемый код или производительный.

    ANS>>Теперь, бьём эту функцию на элементарные операции — получится десяток запросов. Эти запросы без комментариев будут однозначно понятнее этой лапши с комментариями.


    AVK>Пример привести можешь?


    var cardsDeleteSet = 
      SELECT io 
      FROM InventoryOperation io 
        INNER JOIN Inventory i 
        INNER JOIN InventoryInternalDisplacementOperation iido 
        INNER JOIN InternalDisplacementDocument d
      WHERE
        d.id IN (:objectsIds)
        AND io.kind == InventoryOperationKindEnum.InternalDisplacement
        AND io.InventoryCardBefore != io.InventoryCardAfter
        AND io.InventoryCardAfter.type != 'AccrualAccountingInventoryCard';
    
    DELETE FROM ...

    "inner join" это артефакт, в DSL можно делать проще используя точечную нотацию.

    Явно лучше 10 запросов, пусть даже с пересекающимися "WHERE" чем несколько вложенных циклов, которые и удаляют и обновляют и что-то в Set накапливают.

    ЗЫ. А как такое авто-тестировать?

    ЗЗЫ. почему не начался спор, что лучше Rich или Anemic?
    Я ненавижу Hibernate
    Автор: Andrei N.Sobchuck
    Дата: 08.01.08
    !
    Re[22]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 17.04.12 15:10
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    WH>>Брееед! TDOP прост как пробка и ресурсы не ест.

    V>Это LALR или LL(1) ресурсы не ест.
    Ты хоть знаешь как TDOP работает
    Вот основной цикл. Чему тут тормозить?
    var expression = function (rbp) {
        var left;
        var t = token;
        advance();
        left = t.nud();
        while (rbp < token.lbp) {
            t = token;
            advance();
            left = t.led(left);
        }
        return left;
    }

    TDOP линеен.

    V>Дык, Пратт его показал в каком-то махровом 70-м году и никто ни кого не послал. Ведь Дракон — лишь одна из мн-ва работ на эту тему, но почему-то стала более популярной... Не насильно же...

    Насильно. Ибо в институтах только это направление и дают.

    V>А теоретических работ по детерминированному парсингу недетерминированных грамматик хватало, от Ахо в т.ч.

    Работ по созданию распознавателей на основе языка для генерации.
    БНФ описывает ГЕНРАЦИЮ, а не распознавание.
    Тебе не скажется что сама постанвка задачи бредовая?

    V>И там же 100 раз говорилось, что у всех этих "приоритетных" грамматик, в отличие от однозначных,

    Это БНФ то одназначная?
    Вот ПЕГ однозначный. TDOP тоже.
    А БНФ неоднозначная. Да еще и не для этой задачи придумана.

    V>трудно вывести св-ва грамматики.

    Да нахрен эти свойства не упали.
    Они нужны теоретикам, ибо без этого работа не будет считать научной.
    А практикам они не нужны.
    Практикам нужен работающий алгоритм.

    V>И практически невозможно доказать сохранение эквивалентности грамматики во время преобразований (например факторизации), бо упираемся в проблему останова и т.д.

    Чего?
    Нахрена TDOP'у факторизация?

    V>Ну и самое главное, существующие ЯП позволяют решать синтаксические неоднозначности на семантическом уровне, что НАДЕЖНЕЕ, чем это:

    V>

    V>Так правило "кто длиннее тот и прав" разрешает чуть менее чем все конфликты.

    Тройной фейспалм.
    Ты даже не понимаешь, что эту же эвристику используют классические парсеры.
    Что? Не знал?
    А чем ты думаешь лексер занимается?
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[28]: Языки общего назначения не имеют смысла!
    От: Andrei N.Sobchuck Украина www.smalltalk.ru
    Дата: 17.04.12 15:16
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>Здравствуйте, Andrei N.Sobchuck, Вы писали:


    ANS>>Т.е. `source` как параметр передать нельзя. И тут же ты говоришь, что relation это первоклассная сущность. Какой тогда критерий первоклассности чего-либо, если не (не)возможность передать это нечто аргументом в функцию?

    S>Наличие встроенной поддержки в языке. Критерий передаваемости чего-либо в функцию бессмысленен в отсутствие функций, вы не находите?
    S>Вот у нас есть relation. Вот у нас есть правила композиции relation, из которых получаются другие relation. Первоклассность этой сущности — в том, что мы внутри запроса можем в любом месте, где нужен relation, подставить любой (подходящий) relation.
    S>Вы называете это "подзапросами".

    А, туплю. Тебя смущает, что нет мета-протокола?


    S>>>Подзапросы не спасут вас от монолитности запроса — это всего лишь те же шесть страниц, записанные в другом порядке.


    мне не совсем понятно, как это использовать. Я беру из пула конекшен, фигашу туда сорок кусков запросов и пятьдесят функций для комбинации этих кусков, потом один запрос который из дёргает эти функции и так при каждом запросе?
    Я пока только уверился, что прав в том, что базовый функционал есть весь, что нужно
    Автор: Andrei N.Sobchuck
    Дата: 12.04.12
    . И есть другие люди, которые думают так же
    Автор: vdimas
    Дата: 17.04.12
    .


    ANS>> Пожалуй, это проблемы хост-языка, а не самого SQL.

    S>Пожалуй, вы не понимаете, что такое язык. То, о чём я говорю — это проблемы именно SQL. SQL не предусматривает никакого "хост-языка", а способ, которым вы предлагате "решать это в Java" — ужасен.

    Не предусматривает, но практика такова, что есть если не Java, то PL/SQL. Ты конечно, можешь сказать, что процедурные языки имеют все уважающие себя СУБД, но их сделали не для декомпозиции запросов.
    Я ненавижу Hibernate
    Автор: Andrei N.Sobchuck
    Дата: 08.01.08
    !
    Re[29]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 17.04.12 18:08
    Оценка:
    Здравствуйте, Andrei N.Sobchuck, Вы писали:

    ANS>А, туплю. Тебя смущает, что нет мета-протокола?

    Я не понимаю, что такое мета-протокол.

    ANS>мне не совсем понятно, как это использовать. Я беру из пула конекшен, фигашу туда сорок кусков запросов и пятьдесят функций для комбинации этих кусков, потом один запрос который из дёргает эти функции и так при каждом запросе?

    Нет, зачем? Вы же не создаёте при каждом запросе все view и stored procedures.
    Вы берёте, фигачите один раз при развёртывании базы в неё нужные вам функции, которые могут вызывать другие функции, а наружу выставляете только простой и понятный набор таблиц/view/функций/хранимых процедур.

    ANS>Не предусматривает, но практика такова, что есть если не Java, то PL/SQL. Ты конечно, можешь сказать, что процедурные языки имеют все уважающие себя СУБД, но их сделали не для декомпозиции запросов.

    Процедурные языки, построенные на основе SQL, убоги чуть более чем все. По той же самой причине — есть средства декомпозиции только для императивной функциональности, которая вообще чужда SQL. Лучшее, что могут предложить передовые СУБД — это table-valued функции.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[44]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 17.04.12 18:11
    Оценка:
    Здравствуйте, Vain, Вы писали:

    V>Здравствуйте, Sinclair, Вы писали:


    V>>>Ничего такого здесь не подразумевалось. Речь шла про SQL как про DSL который можно сунуть везде и это прокатит.

    S>>Впервые об этом слышу. Кто вам сказал такую глупость? DSL, по определению, нельзя "сунуть везде".
    V> на название топика посмотрите.
    Посмотрел. Дальше что? Подсказка: "языки общего назначения" и "DSL" — это не синонимы, а антонимы.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[25]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 17.04.12 18:34
    Оценка:
    Здравствуйте, Andrei N.Sobchuck, Вы писали:

    AVK>>Пример привести можешь?


    ANS>[sql]

    ANS>var cardsDeleteSet =
    ANS> SELECT io
    ANS> FROM InventoryOperation io
    ANS> INNER JOIN Inventory i
    ANS> INNER JOIN InventoryInternalDisplacementOperation iido
    ANS> INNER JOIN InternalDisplacementDocument d
    ANS> WHERE
    ANS> d.id IN (:objectsIds)
    ANS> AND io.kind == InventoryOperationKindEnum.InternalDisplacement
    ANS> AND io.InventoryCardBefore != io.InventoryCardAfter
    ANS> AND io.InventoryCardAfter.type != 'AccrualAccountingInventoryCard';

    Этот кусок на C# короче. И там вполне можно через query comprehension переписать.

    ANS>DELETE FROM ...


    Ага, а самого то интересного и нет. Как циклы в декларативную форму переделать — догадаться несложно. А вот как последующий алгоритм — вопрос.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[29]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 17.04.12 18:37
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    V>А каков механизм "интроспекции"? Как обходить будешь на дотнете? Ну т.е. строить самый первый план запросов?

    Обычным образом — это же данные. Плюс Reflection, т.е. про всех упомянутых мемберов я знаю чуть более чем всё.
    Вот подробный рассказ про то, как это делается под капотом:
    http://blogs.msdn.com/b/mattwar/archive/2008/11/18/linq-links.aspx

    V>В общем, для плюсов доступна т.н. техника "статического визитора", которая не совсем является классическим вихитором, но устойчиво так называют из-за статического ad-hoc полиморфизма:

    V>
    V>template<Builder builder, typename Entity, typename Value>
    V>void visit(Builder * builder, MemberBetweenPredicate<Entity, Value> betweenExp) {
    V>  builder->onMemberBetweenExp(betweenExp);
    V>  visit(builder, betweenExp.member);
    V>}
    
    V>template<Builder builder, typename Entity1, typename Value1, typename Entity2, typename Value2>
    V>void visit(Builder * builder, boost::lambda::expression::equal<Entity1, Value1, Entity2, Value2> equalOp) {
    V>  builder->onEqualOp(equalOp);
    V>  visit(builder, equalOp.left); 
    V>  visit(builder, equalOp.right);
    V>}
    V>...
    
    V>

    Прикольно. То есть все Expression Trees процессятся статически, во время компиляции?
    Как-то мне это кажется подозрительным. В какой-то момент всё равно произойдёт потеря информации о конкретном типе, т.е. рано или поздно всё свернётся в некий Predicate*.

    V>Не факт что в задаче персистить от запуска к запуску надо... Я же говорю — уже пошло слишком много деталей на одного меня.

    Как правило, неперсистить неинтересно. За один запуск не получается получить так много данных, чтобы запросы по ним имело смысл делать в декларативном виде. (Тут я могу ошибаться, т.к. вроде бы на дотнете народ рапортовал об эффективности индексов в памяти супротив банального сканирования на объёмах от 16 элементов и выше)

    Если любопытно, загляни в доку к boost::serialization. Выглядит это так (из примера):
    V>
    V>class gps_position
    V>{
    V>    friend class boost::serialization::access;
    V>    friend std::ostream & operator<<(std::ostream &os, const gps_position &gp);
    
    V>    int degrees;
    V>    int minutes;
    V>    float seconds;
    
    V>    template<class Archive>
    V>    void serialize(Archive & ar, const unsigned int /* file_version */){
    V>        ar  & BOOST_SERIALIZATION_NVP(degrees)
    V>            & BOOST_SERIALIZATION_NVP(minutes)
    V>            & BOOST_SERIALIZATION_NVP(seconds);
    V>    }
    
    V>public:
    V>    // every serializable class needs a constructor
    V>    gps_position(){};
    V>    gps_position(int _d, int _m, float _s) : 
    V>        degrees(_d), minutes(_m), seconds(_s)
    V>    {}
    V>};
    V>


    V>Метод void serialize<>() вызывается для любого типа-архива как во время сериализации, так и для десериализации.

    V>Вот пример исопльзования этого типа с XML-сериализацией: http://www.boost.org/doc/libs/1_43_0/libs/serialization/example/demo_xml.cpp
    V>Вот результат: http://www.boost.org/doc/libs/1_39_0/libs/serialization/example/demo_save.xml

    V>Отрывок из результата в XML:

    V>
    V><longitude>
    V>  <degrees>134</degrees>
    V>  <minutes>22</minutes>
    V>  <seconds>78.300003</seconds>
    V></longitude>
    V>



    S>>Придётся придумывать специальную процедуру инициализации, которая сможет связать физически хранимый индекс с его ключами, выраженными в виде набора указателей на мемберов.


    V>В любом случае для персиста потребуется арнтайм-метаинформация не только о типах прикладного языка, но и о структуре хранилища и об их взаимном ORM.В каком виде идет эта информация — не принципиально. ORM для C++ можно делать в технике, похожей на технику сериализации (это фактически одно и то же).

    Да, при соблюдении определённых правил гигиены всё это может и сработать.

    V>Не очень. Компиляторы давно научились "склеивать" идентичный код, порожденный шаблонами для разных типов. Первые компиляторы С++ действительно порождали ОЧЕНЬ МНОГО бинарного кода, уникального для каждого инстанса шаблонной ф-ии или метода.

    Да меня количество бинарного кода не очень колышет. SQL Server под свои внутренние структуры отжирает всё равно на порядки больше. Беспокоит в основном количество того кода, который придётся колбасить прикладному программисту. DML у нас изобилует лишними скобками и подчерками (и это мы ещё намеренно завинтили гайки насчёт произвольных выражений, т.к. у нас в качестве аргументов between() могут быть либо мемберы, либо константы).
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[40]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 17.04.12 18:37
    Оценка: +1
    Здравствуйте, Ikemefula, Вы писали:

    I>Что бы было понятно — объектна модель искаропки позволяет выполнить запрос за время меньшее чем самый банальный селект со всеми индексами, кешами и прочей ерундой.


    Зависит от запроса. Где то быстрее и удобнее реляционная модель, где то навигационный доступ. И помимо сырого перформанса есть еще и масштабируемость, так что даже для одного запроса преимущества того или другого способа могут варьироваться в зависимости от абсолютной нагрузки.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[10]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 17.04.12 18:57
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    V>И не нужен. Большинство актуальных запросов формируются ТОЛЬКО динамически....


    В моей практике большинство запросов все же можно статически скомпилировать. Сейчас они динамические благодаря тому, что все API доступа динамические (кроме LINQ). Другое дело, что совсем без динамических запросов тоже плохо, поэтому LINQ частенько тоже проблемен.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[28]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 17.04.12 18:59
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    AVK>Не, ну это понятно. Неоднозначные грамматики с эвристиками (типа тернарного оператора в шарпе или угловых скобок в плюсах, ты это имел ввиду?) это уже точно кандидаты на рукопашное разруливание проблем.

    Или TDOP'у. Он такие вещи ест, вообще не напрягаясь.
    Вот, например тренарный оператор
    cond is expr = expr : 300 '?'s expr ':'s expr;
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[29]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 17.04.12 19:02
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>Или TDOP'у. Он такие вещи ест, вообще не напрягаясь.


    Какие такие? Бывают вещи, которые не описываются вообще грамматикой. Вместо этого есть текстовое описание, как поступать в той или иной конфликтной ситуации.

    WH>Вот, например тренарный оператор

    WH>cond is expr = expr : 300 '?'s expr ':'s expr;

    Я точно не помню, но там проблемы не с самим оператором. а с его комбинацией с оператором ??.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[23]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 17.04.12 19:33
    Оценка: 1 (1)
    Здравствуйте, WolfHound, Вы писали:

    WH>>>Брееед! TDOP прост как пробка и ресурсы не ест.

    V>>Это LALR или LL(1) ресурсы не ест.
    WH>Ты хоть знаешь как TDOP работает

    Сорри, я ваше новое увлечение TDOP подробно еще не смотрел, хватило ПЕГ когда-то. Но и без этого известно, что любая грамматика без неоднозначностей относительно выбранного способа разбора будет линейна, то бишь ее можно парсить за O(n), в чем был прикол отрывка? Как решаются неоднозначности, которые возникают из-за контекстно-зависимой сути исходной грамматики? Как TDOP разберет угловые скобки в С++ до ответа семантического анализатора — это типы или переменные в области видимости? Т.е. это шаблоны или последовательность операций больше/меньше? Неоднозначности грамматик приходится протаскивать в грамматику парсера, где вместо целевых выражений описывать такие промежуточные, требующие решения "потом". И эта техника общая, независимо от техники реализации парсера, бо все эти техники все-равно оперируют лишь в подклассах контекстно-свободных грамматик... Т.е. положа руку на сердце — подробности немного фиолетово.


    V>>Дык, Пратт его показал в каком-то махровом 70-м году и никто ни кого не послал. Ведь Дракон — лишь одна из мн-ва работ на эту тему, но почему-то стала более популярной... Не насильно же...

    WH>Насильно. Ибо в институтах только это направление и дают.

    Этот учебник мы не учили, учили другие. Но да, подача материала примерно такая же. Просто для решений "в лоб" особо и учить нечего. Если ты учился на 2201 или 2202, то должен помнить, что алгоритму нисходящего разбора с потенциально бесконечным магазином было уделено менее половины одной лекции, бо там понимать нечего даже идиоту. А ведь на уровне этой "тупизны" работают такие "современные" алгоритмы, как Эрли и его модификации только лишь за счет того фокуса, что глубина любой потенциальной рекурсии не может быть глубже длины входной цепочки при параллельном пошаговом разборе. Ну просто космические технологии, да?

    Чему действительно много учили на практиках — это строить автоматы для LL(k)/LR(k) и преобразовывать грамматики из одной в другую. Т.е. если разобраться — учили сугубо практическим вещам... ХЗ почему Влад считает рядом, что это далеко от практики. Это и есть современная практика, на которой написаны многие тонны парсеров.


    V>>А теоретических работ по детерминированному парсингу недетерминированных грамматик хватало, от Ахо в т.ч.

    WH>Работ по созданию распознавателей на основе языка для генерации.

    Еще раз, Ахо серьезно занимался проблемами парсинга неоднозначных грамматик. Собсно, только они проблематику и составляют. Я не изучал его работы особо, но можно попытаться поискать. Возможно, вы пропустили что-то интересное, ХЗ.


    WH>БНФ описывает ГЕНРАЦИЮ, а не распознавание.

    WH>Тебе не скажется что сама постанвка задачи бредовая?

    Договорились, поздравляю. Форма БНФ без побочных эффектов, поэтому поддается аналитическим преобразованиям без нарушения св-в исходной грамматики. Почему так? Потому что является всего-навсего разновидностью записи уравнений редукций для случая контекстно-свободных грамматик, т.е. имеет отображение 1-в-1 на систему редукций после преобразования их к контекстно-свободному виду. А уравнениям редукций вообще до фени, что ими описывается: разбор, генерация, зависимые типы, задача для Пролога или азбука Морзе.

    Похоже, вас сбил с толку обычай описывать сначала нетерминалы верхнего уровня в БНФ... но в системе без побочных эффектов, повторю, это абсолютно фиолетово — меняй местами правила как хочешь.

    Сравнить теперь с ПЕГ, который не поддается аналитическим преобразованиям, имеет побочные эффекты, является условием задачи для классического динамического программирования, т.е. заведомо не для всех преобразований грамматики возможно доказать их корректность из-за той самой проблемы останова. Т.е. если ограничить ПЕГ только таким подмножеством правил, в которых преобразования доказуемо корректны — то я был еще не против... Иначе это заведомое UB, которое непонятно где может вылезти и у тебя не будет даже найти ответ в гугле при всем твоем желании, бо матаппарата для побочных эффектов не существует. Еще раз повторюсь, что TDOP подрбно не смотрел, но 5 лет назад вы с не меньшим жаром рассказывали про ПЕГ, чем спровоцировали бесполезную потерю времени на знакомство с этим разделом у многих, я уверен.



    V>>И там же 100 раз говорилось, что у всех этих "приоритетных" грамматик, в отличие от однозначных,

    WH>Это БНФ то одназначная?

    Стоп, грамматика самой БНФ? Или описанная с помощью нее?
    Однозначность — это св-ва формальной грамматики относительно выбранного способа разбора, независимо от способа ее записи. Предлагаю помедитировать над этой фразой, вместо попыток подмены понятий. А то у тебя выходит, что если на заборе мелком похабное слово нарисовали, то виноват мелок.


    WH>Вот ПЕГ однозначный. TDOP тоже.


    ПЕГ детерминированный, бо это просто алгоритм. Алгоритм задает грамматику, угу. Отношение м/у алгоритмом разбора и грамматикой 1:1, поэтому грамматика, заданная ПЕГом, не может быть неоднозначной, если разбирать ее этим же алгритмом... Это же сколько каши должно быть в голове, чтобы всерьез утверждать про однозначность ПЕГа и неоднозначность БНФ. Про ПЕГ-грамматику можно лишь сказать, что она контекстно-свободная, больше ничего. Поэтому если тебе удалось записать в ПЕГ некоторую неоднозначную в координатах контекстно-свободного разбора грамматику (например грамматику С++), то ты записал ее с ошибкой.


    WH>А БНФ неоднозначная. Да еще и не для этой задачи придумана.


    Выделенное больше не пиши никогда. Ну просто чтобы не было столь стыдно, за грамотных, казалось бы, коллег. БНФ получила популярность как "человеческая" запись редукций для случая контекстно-свободных грамматик. Можно сравнить с диаграммами Вирта, в терминах которых, например, описывает свои спецификации IBM. Это все одно и то же.


    V>>трудно вывести св-ва грамматики.

    WH>Да нахрен эти свойства не упали.
    WH>Они нужны теоретикам, ибо без этого работа не будет считать научной.
    WH>А практикам они не нужны.
    WH>Практикам нужен работающий алгоритм.

    Правильно, и когда алгоритм не работает, я могу отбросить хотя бы на часок лень ума и поискать решение через вникание в суть происходящего, благо теории хоть попой кушай. А в случае ПЕГа у нас есть только эксперименты, эвристика и сплошное TDD, которое не факт, что будет достаточно полным, если у меня всего одни мои руки. Не ты ли в соседних форумах поливаешь динамические языки? Но при этом предлагал ПЕГ на динамическом программировании вместо статически-спроектированного парсера, доказанно работающего по исходной грамматике? Разрыв шаблона-с...


    V>>И практически невозможно доказать сохранение эквивалентности грамматики во время преобразований (например факторизации), бо упираемся в проблему останова и т.д.

    WH>Чего?
    WH>Нахрена TDOP'у факторизация?

    Угу, а ПЕГу нахрена? (его имел в виду)


    V>>Ну и самое главное, существующие ЯП позволяют решать синтаксические неоднозначности на семантическом уровне, что НАДЕЖНЕЕ, чем это:

    V>>

    V>>Так правило "кто длиннее тот и прав" разрешает чуть менее чем все конфликты.

    WH>Тройной фейспалм.
    WH>Ты даже не понимаешь, что эту же эвристику используют классические парсеры.
    WH>Что? Не знал?

    Нет никакой эвристики и не было никогда. Потому что та грамматика, в которой это действительно так, не является неоднозначной.


    WH>А чем ты думаешь лексер занимается?


    Думаю, что ты уже третий раз на моей памяти наступаешь на одну и ту же граблю. Не каждый лексер использует жадный алгоритм, и я тебе минимум дважды уже это говорил в разные годы. Это не эвристика никакая, а спецификация "лексемы" в сугубо некоторых языках. Для сравнения в классическом Бейсике или Фортране это вовсе не так, потому что спецификации на лексемы и их отношении с ключевыми словами чуть другие, чем в жабе, С++ или C#. Поэтому Фортран не имеет выделенного лексера, но все-равно парсится не хуже Паскаля.

    Короче, про "эвристику в классических парсерах" ты врешь или сам не в курсе, поэтому изобретаешь тут. Неоднозначность возникает только из-за несоответствия техники разбора имеющимся правилам, больше не из-за чего. Например, если у нас выражение можно распарсить LR(k) распознавателем, где K может достигать длины цепочки, то используя LR(1) у нас будут возможные неоднозначности в процессе разбора. Если все варианты неоднозначностей "протянуть" до конца то, если грамматика однозначна в координатах всех контекстно-свободных грамматик и входная цепочка принадлежит грамматике, то обязательно останется только один вариант. Я только что доказал тебе теорему о том, что такая разновидность параллельного LR(1) разбора разбирает все существующие контекстно-свободные грамматики без ограничений. Или это скорее аксиома определения удачного разбора — ХЗ. Называется GLR. О св-вах GLR разбора написано достаточно... Так зачем платить больше?
    Re[30]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 17.04.12 19:41
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    AVK>Какие такие? Бывают вещи, которые не описываются вообще грамматикой. Вместо этого есть текстовое описание, как поступать в той или иной конфликтной ситуации.

    Это смотря какой грамматикой.

    WH>>Вот, например тренарный оператор

    WH>>cond is expr = expr : 300 '?'s expr ':'s expr;
    AVK>Я точно не помню, но там проблемы не с самим оператором. а с его комбинацией с оператором ??.
    Какие именно?
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[31]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 17.04.12 19:42
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    AVK>>Я точно не помню, но там проблемы не с самим оператором. а с его комбинацией с оператором ??.

    WH>Какие именно?

    Не помню, а искать лень. В стандарте шарпа описано.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[11]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 17.04.12 19:49
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    AVK>В моей практике большинство запросов все же можно статически скомпилировать.


    Наверно, с точностью до параметров если провайдер и диалект позволяют параметры требуемых типов данных.


    AVK>Другое дело, что совсем без динамических запросов тоже плохо, поэтому LINQ частенько тоже проблемен.


    В моей практике ведения даже не самого большого предприятия когда-то до десятка новых уникальных запросов в месяц непрерывно накапливалось... Т.е. как ни крути, а динамика нужна by-design.
    Re[17]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 17.04.12 19:59
    Оценка: -2
    Здравствуйте, oldjackal, Вы писали:

    O> Нет, это теоретики так себе. Практики то как пользовались правильными подходами, так и пользуются. А теоретики в это время всякую чушь в учебниках пишут и студентов этой чушью пугают.


    Фурсенко аплодирует стоя...
    Re[12]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 17.04.12 20:00
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    AVK>>В моей практике большинство запросов все же можно статически скомпилировать.


    V>Наверно, с точностью до параметров


    У меня язык строго типизирован и типы параметров обязательны к декларированию. Я ж говорю — это проблема SQL, а не предметной области.

    AVK>>Другое дело, что совсем без динамических запросов тоже плохо, поэтому LINQ частенько тоже проблемен.


    V>В моей практике ведения даже не самого большого предприятия когда-то до десятка новых уникальных запросов в месяц непрерывно накапливалось...


    Значит такая задача. У нас написание запросов пользователем не предполагается вообще.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[30]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 17.04.12 20:11
    Оценка:
    Здравствуйте, Sinclair, Вы писали:


    V>>Я не игнорирую, я вижу что ты успел забыть на какие твои вопросы я даю ответы. Ты сделал кое-какие утверждения относительно С? Я не согласился и объяснил — почему. Потому что изкаробки слишком много возможностей, даже без внешних библиотек — из-за CRT и адресной арифметики ф-ий.

    S>Сосредоточьтесь. Я вам напомню — мы обсуждаем, годится ли "возможность использовать библиотеки" в качестве критерия DSL. Пока что выходит, что никак не годится.

    Я-то уже давно. Я говорил про произвольные библиотеки, это ключевое. Если же можно подлючать только ограниченные библиотеки, с тем же уровнем ограничений, что и сам DSL, то ес-но никаких изменений границ этого specific не происходит. сами библиотеки с

    V>>Мы недообсуждали Лого, чтобы делать такие выводы. Я еще не увидел твоего примера целиком. Покажи предположительный синтаксис вызова произвольных внешних ф-ий для "расширенного Лого", а затем я тебе дам небольшой список экспорта, например, NT.DLL, с помощью которого можно уронить любую, самую защищенную программную среду.

    S>Непонятно, что вы называете "произвольными внешними функциями". Мы имеем стандартный логовский синтаксис вызова функций/процедур:
    S>
    S>FORWARD 100
    S>LEFT 90
    S>

    S>Плюс мы имеем стандартный синтаксис объявления функций и процедур:
    S>
    S>TO CHAIR  REPEAT 4 [FD 100 RT 90]  FD 200  END
    S>

    S>Плюс мы имеем команду IMPORT, которая втягивает лого-библиотеку, делая видимыми все функции и процедуры, определённые в них.
    S>Никакого синтаксиса для загрузки NT.DLL нет.

    Вот, ЧТД. Тогда речь не идет о произвольных библиотеках.

    S>То есть вы не считаете C++ языком общего назначения? Очень странно.


    Я не считаю таковым JS и не согласен приравнивать его к C++. JS ничем не лучше Logo в своей ограниченности, идущей изкаробки. Поэтому на JS можно делать свои DSL, которые заведомо будут specific.
    Re[24]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 17.04.12 20:12
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    V>Сорри, я ваше новое увлечение TDOP подробно еще не смотрел, хватило ПЕГ когда-то.

    Это не увлечение. Это один из множества разобранных по косточкам алгоритмов.

    V>Но и без этого известно, что любая грамматика без неоднозначностей относительно выбранного способа разбора будет линейна, то бишь ее можно парсить за O(n), в чем был прикол отрывка? Как решаются неоднозначности, которые возникают из-за контекстно-зависимой сути исходной грамматики? Как TDOP разберет угловые скобки в С++ до ответа семантического анализатора — это типы или переменные в области видимости?

    Это для драконщины проблема.
    А для ДСЛей заточенных на практическое использование нет.
    Интегрировать парсер с таблицей символов дело тривиальное.

    V>Т.е. это шаблоны или последовательность операций больше/меньше? Неоднозначности грамматик приходится протаскивать в грамматику парсера, где вместо целевых выражений описывать такие промежуточные, требующие решения "потом". И эта техника общая, независимо от техники реализации парсера, бо все эти техники все-равно оперируют лишь в подклассах контекстно-свободных грамматик... Т.е. положа руку на сердце — подробности немного фиолетово.

    Очередной фейспалм.
    Например мой парсер (даже без интеграции с таблицей символов) захватывает некоторое подмножество контекстно зависимых грамматик.

    Ты так веришь в драконщину что ничего другого просто не хочешь видеть.

    V>Этот учебник мы не учили, учили другие. Но да, подача материала примерно такая же.

    Так я не про конкретную книгу, а про направление.
    Просто книга дракона это бренд.
    Поэтому все направление и называю драконщиной.

    V>А ведь на уровне этой "тупизны" работают такие "современные" алгоритмы, как Эрли

    Это просто песец, какой тормоз.
    Его просто нельзя использовать для практической работы.

    V>Чему действительно много учили на практиках — это строить автоматы для LL(k)/LR(k) и преобразовывать грамматики из одной в другую. Т.е. если разобраться — учили сугубо практическим вещам... ХЗ почему Влад считает рядом, что это далеко от практики. Это и есть современная практика, на которой написаны многие тонны парсеров.

    Это плохая практика.
    И я тебе по секрету скажу парсеры действительно больших проектов написаны руками. Без всего этого матана.
    Вы там со своей драконщиной совсем от реальности оторвались.

    V>Сравнить теперь с ПЕГ, который не поддается аналитическим преобразованиям, имеет побочные эффекты, является условием задачи для классического динамического программирования, т.е. заведомо не для всех преобразований грамматики возможно доказать их корректность из-за той самой проблемы останова. Т.е. если ограничить ПЕГ только таким подмножеством правил, в которых преобразования доказуемо корректны — то я был еще не против... Иначе это заведомое UB, которое непонятно где может вылезти и у тебя не будет даже найти ответ в гугле при всем твоем желании, бо матаппарата для побочных эффектов не существует. Еще раз повторюсь, что TDOP подрбно не смотрел, но 5 лет назад вы с не меньшим жаром рассказывали про ПЕГ, чем спровоцировали бесполезную потерю времени на знакомство с этим разделом у многих, я уверен.

    Просто песец. Нахрена мне грамматику трансформировать, если она без трансформаций работает?
    Просто работает.

    V>Однозначность — это св-ва формальной грамматики относительно выбранного способа разбора, независимо от способа ее записи. Предлагаю помедитировать над этой фразой, вместо попыток подмены понятий. А то у тебя выходит, что если на заборе мелком похабное слово нарисовали, то виноват мелок.

    Да ты хоть какой алгоритм разбора возьми, БНФ в общем случае неоднозначна.
    Те одну строку можно сгенерировать разными способами.

    V>Это же сколько каши должно быть в голове, чтобы всерьез утверждать про однозначность ПЕГа и неоднозначность БНФ.

    Эта грамматика неоднозначна всегда.
    A = a
    B = a
    C = A | B

    Ничиная с нетерминала C эта грамматика порождает только одну строку "a".
    Но может сделать это двумя способами.
    C -> A -> a
    C -> B -> a
    И никакой алгоритм разбора тут не поможет
    Так что каша в голове у тебя.

    V>Про ПЕГ-грамматику можно лишь сказать, что она контекстно-свободная, больше ничего.

    ПЕГ может разбирать некоторые КЗ правила.

    V> Поэтому если тебе удалось записать в ПЕГ некоторую неоднозначную в координатах контекстно-свободного разбора грамматику (например грамматику С++), то ты записал ее с ошибкой.

    Для начала тебе всё же нужно изучить, что же такое ПЕГ.
    Ибо ты этого не понимаешь.

    V>>>И практически невозможно доказать сохранение эквивалентности грамматики во время преобразований (например факторизации), бо упираемся в проблему останова и т.д.

    WH>>Чего?
    WH>>Нахрена TDOP'у факторизация?
    V>Угу, а ПЕГу нахрена? (его имел в виду)
    ПЕГу тоже не нужна. Небольшим допиливанием напильником его можно научить разбирать левую рекурсию.

    А TDOP вообще искаропки её поддерживает. А еще приоритеты с ассоциативность.

    Я с тебя фигею. В парсерах ничего не понимаешь. Почему альфаканал в картинках не такой как остальные не знаешь. А учить лезешь.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[32]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 17.04.12 20:27
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    AVK>Не помню, а искать лень. В стандарте шарпа описано.

    Скачал. Не вижу.
    Влад говорил что ? : в сочетании с самим собой весьма проблемный. Мой алгоритм распарсил не поперхнувшись.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[30]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 17.04.12 20:41
    Оценка:
    Здравствуйте, Sinclair, Вы писали:


    S>Прикольно. То есть все Expression Trees процессятся статически, во время компиляции?


    Именно. А код построения дерева каждого выражения в итоге линейный, без циклов и обхода. Так работает boost::lambda. Характерно, что и само AST зачастую не строится.

    Т.е. как таковой интерпретации на этом месте нет — одна статика. Любую динамику в C++, типа рефлекшена дотнета, надо проектировать и реализовывать явно, а это затратно- описывать акцессоры на все мемб.


    S>Как-то мне это кажется подозрительным. В какой-то момент всё равно произойдёт потеря информации о конкретном типе, т.е. рано или поздно всё свернётся в некий Predicate*.


    Ну... когда-то в компиляторах С++ (не в стандарте!) было ограничение на 256 вложенных шаблонов. Недавно я экспериментировал в MSVC от 2010-й — нет таких ограничений. Сколько памяти хватит, столь глубоким может быть такое статическое AST.


    V>>Не факт что в задаче персистить от запуска к запуску надо... Я же говорю — уже пошло слишком много деталей на одного меня.

    S>Как правило, неперсистить неинтересно. За один запуск не получается получить так много данных, чтобы запросы по ним имело смысл делать в декларативном виде.

    В финансовой области — запросто. Как раз в памяти хранится БД на эффективном мультииндексе. Ну разве что никакой динамической оптимизации запросов — это я фантазировал как бы оно могло быть и какие технологии из уже имеющихся могли бы сэкономить трудоемкость. В реальности статически подобрана структура/граф/индексы под конкретный характер данных конкретной биржи. Важный момент еще в том, что кол-во и характер операций не является заведомо неизвестным (это зачем нужен динамический оптимизатор запросов). Т.е. все структуры данных тюнятся под заведомо-известные алгоритмы их обработки, коих очень счетное кол-во.


    S>Тут я могу ошибаться, т.к. вроде бы на дотнете народ рапортовал об эффективности индексов в памяти супротив банального сканирования на объёмах от 16 элементов и выше.


    Похоже на результаты моих эксперименты на плюсах, только от вдвое/четверо большего числа элементов. Сканирование в нейтиве дешевле, видать.
    Но только если ключ целочисленный, т.е. если лишнее сравнение дешевле косвенной навигации. У меня стандартный двоичный поиск на самописном "плоском" map на 32 элемента немного слил поиску по целочисленному ключу перебором для серий случайных данных. Там же если не сортировать, то операции вставки/удаления совсем дешевые выходят.


    S>Да меня количество бинарного кода не очень колышет. SQL Server под свои внутренние структуры отжирает всё равно на порядки больше. Беспокоит в основном количество того кода, который придётся колбасить прикладному программисту. DML у нас изобилует лишними скобками и подчерками (и это мы ещё намеренно завинтили гайки насчёт произвольных выражений, т.к. у нас в качестве аргументов between() могут быть либо мемберы, либо константы).


    Ну... В реальности так делают только джидаи. Я не джидай, поэтому boost::lambda не пользую в коммерческих проектах. Обычно оформляю полезный код в виде привычных свободных ф-ий или ф-ий мемберов, а не лямбд, а потом просто делаю карринг через boost::bind. Такая техника на сегодня наиболее популярна. Во-первых декомпозиция, повторное использование + тестирование, начиная с совсем мелких кирпичиков-ф-ий. Во вторых, в обычную ф-ию можно брекпоинт поставить, в случае чего. Ну и карринг тоже неплохое подспорье, экономящее массу рукописного кода. Дальнейший переход на чистые лямбды экономит уже только на синтаксисе объявления ф-ий, что уже не столь принципиально.
    Re[13]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 17.04.12 21:04
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:


    AVK>У меня язык строго типизирован и типы параметров обязательны к декларированию. Я ж говорю — это проблема SQL, а не предметной области.


    Ага, тогда я не правильно понял "компиляцию запроса", я думал, что это есть процедура получения готового SQL.

    Интересно, а как запрос "ембедится" в исходник? Свой препроцессор C#? Или рядом в другом файле лежит?


    AVK>>>Другое дело, что совсем без динамических запросов тоже плохо, поэтому LINQ частенько тоже проблемен.


    V>>В моей практике ведения даже не самого большого предприятия когда-то до десятка новых уникальных запросов в месяц непрерывно накапливалось...


    AVK>Значит такая задача. У нас написание запросов пользователем не предполагается вообще.


    Ну это да, и это наверно уже обсуждается второй десяток лет... Когда-то кости Парусу в курилках перемыли некисло... Таки не удержусь. У нас ходило мнение в бытность 1С 6-ки, что она, невзирая на свою убогость и тормоза, стала популярной именно из-за того, что в ней сделали более-менее человеческую кастомизацию клиентом. Хотя реальную кастомизацию все-равно не сами клиенты делают, а всякие "партнеры", но шаговая доступность для этого и вообще сам сценарий: пришел представитель "партнера" к клиенту и прямо на месте что-то подкрутил — такой сценарий очень даже юзер-френдли.
    Re[45]: Языки общего назначения не имеют смысла!
    От: Vain Россия google.ru
    Дата: 17.04.12 21:16
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    V>>>>Ничего такого здесь не подразумевалось. Речь шла про SQL как про DSL который можно сунуть везде и это прокатит.

    S>>>Впервые об этом слышу. Кто вам сказал такую глупость? DSL, по определению, нельзя "сунуть везде".
    V>> на название топика посмотрите.
    S>Посмотрел. Дальше что? Подсказка: "языки общего назначения" и "DSL" — это не синонимы, а антонимы.
    Ну т.е. что ЯОН имеют смысл при работе с бд вы согласны?
    [In theory there is no difference between theory and practice. In
    practice there is.]
    [Даю очевидные ответы на риторические вопросы]
    Re[25]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 17.04.12 23:02
    Оценка: -1 :)
    Здравствуйте, WolfHound, Вы писали:

    V>>Но и без этого известно, что любая грамматика без неоднозначностей относительно выбранного способа разбора будет линейна, то бишь ее можно парсить за O(n), в чем был прикол отрывка? Как решаются неоднозначности, которые возникают из-за контекстно-зависимой сути исходной грамматики? Как TDOP разберет угловые скобки в С++ до ответа семантического анализатора — это типы или переменные в области видимости?

    WH>Это для драконщины проблема.
    WH>А для ДСЛей заточенных на практическое использование нет.
    WH>Интегрировать парсер с таблицей символов дело тривиальное.

    Не только с таблицей, но и правилами поиска символов в ней, согласно стандарта.
    Ты всерьез хочешь сделать заявку на обобщенную реализацию контекстно-зависимых грамматик, или мне только так показалось?


    V>>Т.е. это шаблоны или последовательность операций больше/меньше? Неоднозначности грамматик приходится протаскивать в грамматику парсера, где вместо целевых выражений описывать такие промежуточные, требующие решения "потом". И эта техника общая, независимо от техники реализации парсера, бо все эти техники все-равно оперируют лишь в подклассах контекстно-свободных грамматик... Т.е. положа руку на сердце — подробности немного фиолетово.


    WH>Очередной фейспалм.

    WH>Например мой парсер (даже без интеграции с таблицей символов) захватывает некоторое подмножество контекстно зависимых грамматик.

    Какое "некоторое"?

    WH>Ты так веришь в драконщину что ничего другого просто не хочешь видеть.


    Ровно вдвое меньше кол-во букв ушло бы на то, чтобы показать, решается ли это так же как я показал — через промежуточные нетерминалы в парсере или явный вызов внешнего обработчика в случае конфликта (что есть скукотищща), или как-то по-другому (что чуть любопытней).


    V>>А ведь на уровне этой "тупизны" работают такие "современные" алгоритмы, как Эрли

    WH>Это просто песец, какой тормоз.
    WH>Его просто нельзя использовать для практической работы.

    Но глотает вообще всё, поэтому для исследовательских целей таки можно. К тому же, есть улучшенные модификации алгоритма.



    V>>Чему действительно много учили на практиках — это строить автоматы для LL(k)/LR(k) и преобразовывать грамматики из одной в другую. Т.е. если разобраться — учили сугубо практическим вещам... ХЗ почему Влад считает рядом, что это далеко от практики. Это и есть современная практика, на которой написаны многие тонны парсеров.

    WH>Это плохая практика.
    WH>И я тебе по секрету скажу парсеры действительно больших проектов написаны руками. Без всего этого матана.

    Вообще-то пилил парсеры достаточно больших проектов. И скажу, что преобразование и упрощение грамматики происходит в полный рост уже для такой несложной грамматики, как CORBA IDL.


    WH>Вы там со своей драконщиной совсем от реальности оторвались.


    Ручная писанина не означает отсутствия бумажной стадии. Если LARL(1) или LL(k) кодить ручками, то без бумажной стадии вообще никак. Никакие руки не помогут. А это одни из самых популярных техник. И да, зайди на любой проект по генерации грамматик и посмотри, как часто их используют. Боюсь, твои сведения о ручной писанине парсеров неточны.



    WH>Просто песец. Нахрена мне грамматику трансформировать, если она без трансформаций работает?

    WH>Просто работает.

    Ну мало ли — развиваем постепенно. Сейчас работает, а добавили потом правил — и уже работает не так, как надо. Для известных подклассов грамматик есть известные приемы избавления от рекурсий или неоднозначностей, есть т.н. операции "приведения грамматик" — по очищению их от мусора. Это как рефакторинг в процессе развития, т.е. дело нормальное. Но, если для классики после всех преобразований я спокоен за свою грамматику как слон, т.к. мне гарантировано сохранение исходной семантики, то для случае ПЕГ — ес-но нет.



    V>>Однозначность — это св-ва формальной грамматики относительно выбранного способа разбора, независимо от способа ее записи. Предлагаю помедитировать над этой фразой, вместо попыток подмены понятий. А то у тебя выходит, что если на заборе мелком похабное слово нарисовали, то виноват мелок.

    WH>Да ты хоть какой алгоритм разбора возьми, БНФ в общем случае неоднозначна.
    WH>Те одну строку можно сгенерировать разными способами.

    Так и думал, но не стал озвучивать в прошлый раз. В общем, не так... Плохо дракона учил.
    Это так, только если контекстно-свободная грамматика является неоднозначной. Т.е. если она не является на самом деле контекстно-свободной и мы располагаем лишь подмножеством контекстно-свободных правил из полной системы правил грамматики.

    Я мог бы предположить чего похлеще, что ты имел ввиду подстроку, которая НЕ разбирается к начальному символу грамматики, хотя разбирается сразу к нескольким вариантам других нетерминалов, не имеющих правила S->N... но это совсем уже в профнепригодности подозревать... Хотя, твой пример ниже доставляет.


    V>>Это же сколько каши должно быть в голове, чтобы всерьез утверждать про однозначность ПЕГа и неоднозначность БНФ.

    WH>Эта грамматика неоднозначна всегда.
    WH>
    WH>A = a
    WH>B = a
    WH>C = A | B
    WH>

    WH>Ничиная с нетерминала C эта грамматика порождает только одну строку "a".
    WH>Но может сделать это двумя способами.
    WH>C -> A -> a
    WH>C -> B -> a
    WH>И никакой алгоритм разбора тут не поможет
    WH>Так что каша в голове у тебя.

    Нехило подставился, спасибо.

    Если ты описал эту грамматику в КС-форме, то я её сразу отношу к регулярным (у которых нет рекурсии в правилах или все рекурсии одного вида), т.е. ты описал исходный недетерминированный автомат регулярной грамматики. Согласно твоего же определения A и B неразличимы. Т.е. в этой регулярной грамматике даже конфликтов нет и она эквивалентна после минимизации такой: S->a.

    Если же A и B различимы, то ты забыл описать эту различимость. Наверно она осталась в тех КЗ-правилах, которые ты забыл привести? Дык, приведи. Итого, в техние КС-разбора дополненная грамматика будет неоднозначной, но будет однозначной в технике КЗ-разбора.

    Полегчало?


    V>>Про ПЕГ-грамматику можно лишь сказать, что она контекстно-свободная, больше ничего.

    WH>ПЕГ может разбирать некоторые КЗ правила.

    Без правого контекста в левой части правил? К сожалению, этого недостаточно, т.к. сам "контекст" может быть перехвачен удачно-примененным правилом из подмножества контекстно-свободных, разобрав полный терминал, т.е. закончив цикл разбора. А КЗ-грамматике нужен заход на продолжение разбора с накопленными предыдущими терминалами в ЛЕВОЙ части правила. Т.е. нужен другой верхний алгоритм верхнего уровня, нежели нисходящий для КС-грамматик. Последнее ключевое. Опыты по разбору КЗ-грамматик говорят, что нисходящий их разбор бессмыслен, т.к. редукция правил желательна уже по готовым нетерминалам.



    V>> Поэтому если тебе удалось записать в ПЕГ некоторую неоднозначную в координатах контекстно-свободного разбора грамматику (например грамматику С++), то ты записал ее с ошибкой.

    WH>Для начала тебе всё же нужно изучить, что же такое ПЕГ.
    WH>Ибо ты этого не понимаешь.

    Т.е. ты таки изобрел способ парсинга КЗ-грамматик?


    V>>>>И практически невозможно доказать сохранение эквивалентности грамматики во время преобразований (например факторизации), бо упираемся в проблему останова и т.д.

    WH>>>Чего?
    WH>>>Нахрена TDOP'у факторизация?
    V>>Угу, а ПЕГу нахрена? (его имел в виду)
    WH>ПЕГу тоже не нужна. Небольшим допиливанием напильником его можно научить разбирать левую рекурсию.

    WH>А TDOP вообще искаропки её поддерживает. А еще приоритеты с ассоциативность.


    WH>Я с тебя фигею. В парсерах ничего не понимаешь.


    Ага, приведенные тобой примеры я действительно не понимаю так, как ты их понимаешь. У тебя собственная система координат и терминологии, разрывающая возможный способ обмена информацией с коллегами. По аналогии с твоими рассуждениями, графы недетерминированы, ведь на них можно выразить недетерминированный автомат. А ручка и бумага вообще зло — мало ли что с помощью них можно описать...

    Или вот твои перлы, каждый и которых комментировать устанет рука:

    Народ научился эффективно разбирать только регулярные и некоторое подмножество контекстно сободных языков.


    Короче, доварился в собственном соку до непонятно чего...


    WH>Почему альфаканал в картинках не такой как остальные не знаешь. А учить лезешь.


    Дык, вижу невладение базовыми вещами, сорри. Я не понимаю выражение "альфа канал не такой как остальные". А "остальные" какие? Что за тайна великая раскрыть выбранный способ передискретизации/ресэмплинга изображений? И почему полный игнор вопросов относительно округления цветовой глубины при переходе м/у цветовыми пространствами? А что насчет цветового масштабирования в TV-диапазон для YUV и обратно?

    Но это лучше в том же топике продолжить, чтобы не путаться. Мне действительно интересно, бо цветами и изображениями занимался прилично. Потом покажу пару способов в RGB и YUV, а ты попробуешь на них пояснить, где же там "альфа не такая как остальные". Особенно если альфа в телестудиях идет как ключевой канал для управления YUV и передискретизируется в точности так же, как монохромный Y by design. И особенно интересно место DSL в описании адаптивного гребенчатого цветного фильтра или обязательного derainbow filter при преобразовании RGB->YUV. Ты же вроде говорил о быстродействии?
    Re[26]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 17.04.12 23:12
    Оценка:
    Очепятка, тут везде имелись ввиду нетерминалы:

    V>Без правого контекста в левой части правил? К сожалению, этого недостаточно, т.к. сам "контекст" может быть перехвачен удачно-примененным правилом из подмножества контекстно-свободных, разобрав полный терминал, т.е. закончив цикл разбора...
    Re[26]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 17.04.12 23:28
    Оценка: :)
    Здравствуйте, vdimas, Вы писали:

    Песец. Полный. Даже комментировать тот феерический бред, что ты тут понаписал, не хочу.
    Всё равно без толку.

    Это так, только если контекстно-свободная грамматика является неоднозначной. Т.е. если она не является на самом деле контекстно-свободной и мы располагаем лишь подмножеством контекстно-свободных правил из полной системы правил грамматики.

    Аааааааааа!!!!!!!!!!!!!! Жжжжжжжжееееееесть.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[46]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 18.04.12 02:07
    Оценка:
    Здравствуйте, Vain, Вы писали:
    V>Ну т.е. что ЯОН имеют смысл при работе с бд вы согласны?
    С реляционными БД — нет. Пока что я не вижу никаких аргументов в пользу этого утверждения.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[31]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 18.04.12 02:13
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    V>Я-то уже давно. Я говорил про произвольные библиотеки, это ключевое. Если же можно подлючать только ограниченные библиотеки, с тем же уровнем ограничений, что и сам DSL, то ес-но никаких изменений границ этого specific не происходит.

    Ок. Хорошо. Ну, то есть для платформы Windows нам достаточно иметь аналоги LoadLibrary и GetProcAddress.

    S>>То есть вы не считаете C++ языком общего назначения? Очень странно.


    V>Я не считаю таковым JS и не согласен приравнивать его к C++. JS ничем не лучше Logo в своей ограниченности, идущей изкаробки. Поэтому на JS можно делать свои DSL, которые заведомо будут specific.

    И всё же в самом С++ нет никаких LoadLibrary и GetProcAddress. Если уж на то пошло, то единственный язык, который вашему критерию не-DSLности удовлетворяет — это C#, в котором можно напрямую размечать импорты.
    Всякие прагмы в С++ — это всего лишь хинты линкеру, которые компилятор встраивает в тело .obj — файла.
    Если хочется иметь DSL, основанный на C или C++, то можно все эти прагмы проигнорировать или выдать ошибки при линковке. Точно так же, как попытка сделать произвольный CreateObject в JS будет зарезана хостом при желании хозяина хоста.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[47]: Языки общего назначения не имеют смысла!
    От: Vain Россия google.ru
    Дата: 18.04.12 02:21
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    V>>Ну т.е. что ЯОН имеют смысл при работе с бд вы согласны?

    S>С реляционными БД — нет. Пока что я не вижу никаких аргументов в пользу этого утверждения.
    Ну так и речь исходно не про реляционные бд была, а про дсл. Sql лишь как "классический пример" упоминался и не являлся никаким доказательством что ЯОН не нужны при работе с бд, замечу, не указано какой.
    [In theory there is no difference between theory and practice. In
    practice there is.]
    [Даю очевидные ответы на риторические вопросы]
    Re[22]: Языки общего назначения не имеют смысла!
    От: Ziaw Россия  
    Дата: 18.04.12 05:46
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    K>>1. Я не явлюясь специалистом в данной предметной области.

    K>>2.1. Я не являюсь специалистом в создании DSL.

    AVK>А таких людей вообще — просто считанное количество. That's the problem.


    Это да, проблема. Но давай вспомним появление C++. ООП тогда толком не умел применять почти никто. И сейчас, можно сказать, мало кто умеет (я, например, с трудом). Однако это не помешало большинству его применять и получать от этого немалый профит. Ибо остальные средства декомпозиции задач тоже не блещут. В том смысле, что на отдельных задачах могут показать более простой и поддерживаемый код, а могут и не показать.

    Язык, который даст возможность быстренько написать DSL если вдруг в нем возникла нужда в любом случае будет лучше такого же языка, который этой возможности не имеет. Обилие появляющихся примеров fluent DSL (которые тоже мало кто умел писать раньше, да и мало кто умеет писать сейчас) говорит о том, что какой-то DSL в системе все равно появится, вопрос только в его качестве и сложности разработки и поддержки. Я лично написал несколько fluent DSL, но это реально похоже на хождение по граблям на ходулях. И вносить правки в такой DSL, с прошествием времени, геморрой еще тот.
    Re[14]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 18.04.12 11:20
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    AVK>>У меня язык строго типизирован и типы параметров обязательны к декларированию. Я ж говорю — это проблема SQL, а не предметной области.


    V>Ага, тогда я не правильно понял "компиляцию запроса", я думал, что это есть процедура получения готового SQL.


    Готовый sql у нас не может быть заранее получен хотя бы потому что на этапе компиляции неизвестен целевой сервер СУБД. Но WH говорил прежде всего про статический контроль типов, а вот его то как раз в большинстве случаев обеспечить можно.

    V>Интересно, а как запрос "ембедится" в исходник? Свой препроцессор C#? Или рядом в другом файле лежит?


    У нас — никак. У нас запросы не в C# исходниках в основном, а внутри другого DSL. А те запросы, которые внутри шарпа, те сейчас компилируются только в рантайме.

    V>Хотя реальную кастомизацию все-равно не сами клиенты делают, а всякие "партнеры"


    Ну вот поэтому в Торнадо кастомизация партнерам доступна в любом объеме, в отличие от 8-ки, кде куча логики была захардкожена в клиенте.

    V>, но шаговая доступность для этого и вообще сам сценарий: пришел представитель "партнера" к клиенту и прямо на месте что-то подкрутил — такой сценарий очень даже юзер-френдли.


    У нас клиенты обычно покрупнее, такие фокусы не очень усместны. Да и сложность и технологичность продуктов сейчас сильно больше, чем во времена 1С 6, так просто не влезешь.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[33]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 18.04.12 12:16
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>Мой алгоритм распарсил не поперхнувшись.


    Вопрос в том, распарсил ли он его согласно стандарту.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[34]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 18.04.12 12:24
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    AVK>Вопрос в том, распарсил ли он его согласно стандарту.

    Распарсил согласно стандарту.
    Так что там с ??
    Хочу проверить.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[35]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 18.04.12 12:33
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>Распарсил согласно стандарту.

    WH>Так что там с ??
    WH>Хочу проверить.

    Сорри, я не готов сейчас обсуждать эту тему детально.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[26]: Языки общего назначения не имеют смысла!
    От: Andrei N.Sobchuck Украина www.smalltalk.ru
    Дата: 18.04.12 13:19
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:


    ANS>>
    ANS>>    INNER JOIN Inventory i 
    ANS>> ...
    ANS>>  WHERE
    ANS>>


    AVK>Этот кусок на C# короче. И там вполне можно через query comprehension переписать.


    Во-первых, я написал, что "INNER JOIN" это артефакт и его можно заменить более понятной и простой конструкцией, а там где всякие "больше"/"меньше"/"равно" это у тебя будет и в C#.
    Во-вторых, у тебя же не конкурс "впихни как можно больше функционала в меньшее кол-во букв". В примере типичный "лапша-код", из-за того, что если не сделать всё за один проход по циклам, то оно будет тормозить так, что можно будет сказать, что оно не работает. Я так понимаю, что с этим ты и не споришь?
    Другое дело, что в отличии от топик стартера, мне не кажется, что DSL в виде языка запросов, в таком приложении это "на раз-два". Но то, что это тяжело — не значит, что навигациооное API лучше всегда.

    А какое там API для сторонних приложений?


    ANS>>DELETE FROM ...

    AVK>Ага, а самого то интересного и нет. Как циклы в декларативную форму переделать — догадаться несложно. А вот как последующий алгоритм — вопрос.

    Какой такой "последующий алгоритм"? Мне непонятна твоя позиция. Ты согласен, что это "лапша-код"; ты утверждаешь, что это нормальный код, для такого приложения (т.е. бывает и хуже) и лучше нельзя. На выходе получается, что лапша-код это нормально и сделать ничего нельзя. Просто фатализм и безысходность.
    Я ненавижу Hibernate
    Автор: Andrei N.Sobchuck
    Дата: 08.01.08
    !
    Re[30]: Языки общего назначения не имеют смысла!
    От: Andrei N.Sobchuck Украина www.smalltalk.ru
    Дата: 18.04.12 13:34
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    ANS>>А, туплю. Тебя смущает, что нет мета-протокола?

    S>Я не понимаю, что такое мета-протокол.

    Аналог meta object protocol (сори, мне слово object тут показалось неуместным). Тебе же нужно запросами манипулировать — там условия дорисовать, там переписать. Не в строках же всё хранить. Плюс система a-la RULE в PostgreSQL для перехвата и переписывания запросов во время выполнения.

    ANS>>мне не совсем понятно, как это использовать. Я беру из пула конекшен, фигашу туда сорок кусков запросов и пятьдесят функций для комбинации этих кусков, потом один запрос который из дёргает эти функции и так при каждом запросе?

    S>Нет, зачем? Вы же не создаёте при каждом запросе все view и stored procedures.
    S>Вы берёте, фигачите один раз при развёртывании базы в неё нужные вам функции, которые могут вызывать другие функции, а наружу выставляете только простой и понятный набор таблиц/view/функций/хранимых процедур.

    Меня терзают смутные сомнения. Вроде как, пол приложения в БД, а половина в сервере приложения это уже пройденный этап.
    Я ненавижу Hibernate
    Автор: Andrei N.Sobchuck
    Дата: 08.01.08
    !
    Re[26]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 18.04.12 13:52
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:


    AVK>Не вижу никакого взрыва. Этот код просто лапочка по сравнению с тем, что местами попадается, скажем, в решарпере Типа нескольких вложенных циклов по графу, на который наложены и неявно учитываются контролируемые только в рантайме ограничения, внутри которых несколько goto, причем в разные точки. Вот это да, взрыв моска. А тут линейная логика.

    AVK>Ну давай посмотрим:
    AVK>
    AVK>IInventoryCardObject invCardObj = invAfter.GetInventoryCardObject();
    AVK>

    AVK>Получаем объект инвентаризации из истории операции инвентаризации
    1. Почему у нас явно указан тип? Это важно? (здесь и далее все комментарии — с точки зрения бизнес-логики, а не с точки зрения C#
    AVK>
    AVK>if (invCardObj != null)
    AVK>

    AVK>Если объект есть
    2. У нас он часто отсутствует?
    3. Если он отсутствует, то выполняется какая-то сложная логика, или просто "а, ну тогда пропустим тридцать строк"?
    4. Я веду к тому, что может имеет смысл свернуть эти явные ветки кода во что-то типа "для всех карточек (которых либо 0 либо 1) выполни XXX", либо перейти от null к исключениям, которые можно удобно проигнорировать где-то внизу кода (типа OnMissingInvCard = Skip).
    AVK>
    AVK>var card = ((IPersistedObject)invCardObj).Master as IInventoryCardBase;
    AVK>

    AVK>Берем карточку, по которой он инвентаризован
    5. Вот эти два даункаста в разных стилях — они точно нужны? Почему нельзя просто invCardObj.Master?
    AVK>
    AVK>if (card is IAccrualAccountingInventoryCard)
    AVK>    Manager.DeleteObject((IPersistedObject)invCardObj);
    AVK>

    6. Опять даункаст. В целом, выглядит, как размазанная запись правила, которое в оригинале звучало как "убить все карточки, которые входят в бла-бла-бла". DSL, который бы позволял написать "убить все карточки, которые входят в бла-бла-бла", не отвлекаясь на порядок обхода итераторов, даункасты, и скобочки, был бы крайне уместен.
    AVK>
    AVK>else if (!cardsDeleteSet.Contains(card))
    AVK>        invCardObj.Inventory = inv;
    AVK>

    AVK>Иначе проверяем наличие в хешике, который мы чуть раньше заполняли, и если совпало, то в детейле инвентарной карточки заменяем ссылку на справочник инвентаризуемых объектов.
    7. Этот хешик — он какую бизнес-сущность отражает?
    AVK>
    AVK>inv.ChangesHistory = null;
    AVK>

    AVK>Обнуляем историю инвентаризации
    Хм. Не вполне очевидно.
    AVK>
    AVK>ChangeInventoryActualStateInDocuments(invAfter, inv);
    AVK>

    AVK>Название метода вполне говорящее.
    AVK>
    AVK>Manager.DeleteObject((IPersistedObject)invAfter);
    AVK>

    AVK>Удаляем инвентаризационную операцию
    AVK>Это, собственно, типичная бизнес-логика. Далеко не самая запутанная, уж поверь. И ее то как раз нужно сохранить, это входящее требование. А вот как ее более красиво записать — вопрос.
    Отож, про то и обсуждение.

    AVK>Где? В DeleteObject даункаст лишний. Даункаст при обращении к Master — технологическая особенность, связанная с распределенностью системы и едиными интерфесами и в клиентском и в серверном коде. Согласен, проблема, но ее не так то легко вылечить. А as/is — это просто проверка дискриминанта, который выражен в виде реализации тех или иных интерфейсов.

    С точки зрения C# — понятно. С точки зрения бизнес-логики — нет.

    AVK>Переменная модифицируется ровно один раз, при объявлении. Потом меняется содержимое самого хеша, а не переменной. И использование вполне стандартное — запоминаем в цикле обхода, потом запомненное используем для проверки. Такого кода, скажем, внутри System.Enumerable до попы, хотя, вроде как, весьма приличные спецы писали.

    Тут дело не в спецах, а в решаемой задаче.
    Не то, чтобы у меня было готовое решение для вашей бизнес-логики, просто невооружонным мозгом понять код на шарпе всё же тяжело. Относительнно много мусора и сущностей, которые как бы вне модели собственно бизнеса.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[31]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 18.04.12 14:24
    Оценка: +1
    Здравствуйте, Andrei N.Sobchuck, Вы писали:

    ANS>Аналог meta object protocol (сори, мне слово object тут показалось неуместным).

    Эту аббревиатуру я тоже не знаю.
    ANS> Тебе же нужно запросами манипулировать — там условия дорисовать, там переписать. Не в строках же всё хранить. Плюс система a-la RULE в PostgreSQL для перехвата и переписывания запросов во время выполнения.
    Мне не надо манипулировать запросами. Мне надо иметь средства борьбы со сложностью.

    ANS>Меня терзают смутные сомнения. Вроде как, пол приложения в БД, а половина в сервере приложения это уже пройденный этап.

    Границы обязанностей двигаются всё время. Вот от толстых клиентов уже почти везде уехали к тонким; так и на серверной стороне то же самое. Зачем подымать мегабайты в память веб-сервера, чтобы "быстро-быстро" их обработать? Пусть RDBMS сама этим занимается. Вы никогда не порвёте по производительности update inventory set amount = amount — @quantity where goodId = @goodID and amount > @quantity никакими ORM. И никаким джаваскриптом вы его тоже не порвёте — ну разве что ценой отказа от персистентности.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[27]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 18.04.12 14:29
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    AVK>>Получаем объект инвентаризации из истории операции инвентаризации

    S>1. Почему у нас явно указан тип? Это важно?

    Ты имеешь в виду почему не var? Нет, не важно.

    AVK>>
    AVK>>if (invCardObj != null)
    AVK>>

    AVK>>Если объект есть
    S>2. У нас он часто отсутствует?

    ХЗ

    S>3. Если он отсутствует, то выполняется какая-то сложная логика, или просто "а, ну тогда пропустим тридцать строк"?


    Это из исходника видно.

    S>4. Я веду к тому, что может имеет смысл свернуть эти явные ветки кода во что-то типа "для всех карточек (которых либо 0 либо 1) выполни XXX", либо перейти от null к исключениям, которые можно удобно проигнорировать где-то внизу кода (типа OnMissingInvCard = Skip).


    Возможно

    AVK>>Берем карточку, по которой он инвентаризован

    S>5. Вот эти два даункаста в разных стилях — они точно нужны?

    Увы, да.

    S> Почему нельзя просто invCardObj.Master?


    Потому что сейчас базовый интерфейс, он для серверного и клиентского кода разный, а вот бизнес-интерфейсы универсальны. Технологическая проблема, которую надо устранять. Скорее всего введением еще одного интерфейса, общего для сервера и для клиента. В любом случае DSL тут — из пушки по воробьям.

    AVK>>
    AVK>>if (card is IAccrualAccountingInventoryCard)
    AVK>>    Manager.DeleteObject((IPersistedObject)invCardObj);
    AVK>>

    S>6. Опять даункаст.

    Я уже писал — ненужный.

    S>DSL, который бы позволял написать "убить все карточки, которые входят в бла-бла-бла", не отвлекаясь на порядок обхода итераторов, даункасты, и скобочки, был бы крайне уместен.


    По идее, такое можно и в рамках библиотеки реализовать.

    AVK>>Иначе проверяем наличие в хешике, который мы чуть раньше заполняли, и если совпало, то в детейле инвентарной карточки заменяем ссылку на справочник инвентаризуемых объектов.

    S>7. Этот хешик — он какую бизнес-сущность отражает?

    Никакую. Промежуточное накопление результатов, чтобы два раза коллекцию не обходить.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[27]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 18.04.12 14:35
    Оценка:
    Здравствуйте, Andrei N.Sobchuck, Вы писали:

    ANS>Во-первых, я написал, что "INNER JOIN" это артефакт и его можно заменить более понятной и простой конструкцией


    Я так понимаю, что весь топик ты не читал? Потому что я, как бы, в курсе. Но на шарпе все равно будет как минимум не хуже.

    ANS>Во-вторых, у тебя же не конкурс "впихни как можно больше функционала в меньшее кол-во букв".


    Нет. Меня больше читабельность интересует. Но и с ней никаких преимуществ по сравнению с шарпом нет.

    ANS> В примере типичный "лапша-код", из-за того, что если не сделать всё за один проход по циклам, то оно будет тормозить так, что можно будет сказать, что оно не работает.


    Нет, тормозить оно особо не будет. Все коллекции на момент прохода уже в памяти и на фоне активной работы с БД накладные расходы на лишний проход в микроскоп не увидишь.

    ANS> Я так понимаю, что с этим ты и не споришь?


    Я не спорю, я пытаюсь выслушать мнения (отличные от "пример не годится").

    ANS>Другое дело, что в отличии от топик стартера, мне не кажется, что DSL в виде языка запросов, в таком приложении это "на раз-два".


    DSL в виде языка запросов там уже есть. Но вряд ли он в таком коде что то упростит.

    ANS>А какое там API для сторонних приложений?


    Каких таких сторонних?

    ANS>Какой такой "последующий алгоритм"? Мне непонятна твоя позиция. Ты согласен, что это "лапша-код"; ты утверждаешь, что это нормальный код, для такого приложения (т.е. бывает и хуже) и лучше нельзя. На выходе получается, что лапша-код это нормально и сделать ничего нельзя. Просто фатализм и безысходность.


    Какое то у тебя странное восприятие. Код тут приведен не в качестве примера плохого или хорошего, а в качестве примера исходной логики, которую нужно круто записать на DSL. И код специально взят обрабатывающий, а не просто выборки делающий.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[32]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 18.04.12 14:42
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    AVK>>>Я точно не помню, но там проблемы не с самим оператором. а с его комбинацией с оператором ??.

    WH>>Какие именно?

    AVK>Не помню, а искать лень. В стандарте шарпа описано.


    Нет там никаких неоднозначностей и быть не может. Это ведь два разных токена. Соответственно в стандарте тоже ничего по их поводу нет.

    Для слабых парсеров может возникгуть проблема в интерпретации оператора "?" (в унарном виде он является частью описания типа), для TDOP — это ни разу не проблема.

    Плюс у нас еще есть синтаксические предикаты. То что не решается синтаксисом, решается предикатами.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[35]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 18.04.12 14:43
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>Распарсил согласно стандарту.

    WH>Так что там с ??
    WH>Хочу проверить.

    Ничего там. Надо просто воспроизвести операторы шарпа и сделать тесты.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[32]: Языки общего назначения не имеют смысла!
    От: Andrei N.Sobchuck Украина www.smalltalk.ru
    Дата: 18.04.12 15:36
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>Мне не надо манипулировать запросами. Мне надо иметь средства борьбы со сложностью.


    Фраза не несущая конкретики. Может моё решение и плохое, но твоя фраза это пожелание мира во всём мире.

    ANS>>Меня терзают смутные сомнения. Вроде как, пол приложения в БД, а половина в сервере приложения это уже пройденный этап.

    S>Границы обязанностей двигаются всё время. Вот от толстых клиентов уже почти везде уехали к тонким; так и на серверной стороне то же самое. Зачем подымать мегабайты в память веб-сервера, чтобы "быстро-быстро" их обработать? Пусть RDBMS сама этим занимается. Вы никогда не порвёте по производительности update inventory set amount = amount — @quantity where goodId = @goodID and amount > @quantity никакими ORM. И никаким джаваскриптом вы его тоже не порвёте — ну разве что ценой отказа от персистентности.

    Не совсем понял какая связь с моим утверждением. Мне кажется естественным и понятным ситуация, когда запрос на апдейт уходит с сервера приложения. Ты же хочешь, чтобы запрос уходил на сервер, там он (пре)процесился и порождался конечный запрос. Мне ситуация когда пользовательская логика размазана между СУБД и приложением кажется ненормальной. Ты же, с одной стороны, говоришь, что происходит четкое разделение обязанностей (я с этим согласен), с другой предлагаешь запихивать в сервер какую-то логику.

    И, я так понял, что ты сразу сомневаешься, в моём предположении, что JS это наше будущее
    Автор: Andrei N.Sobchuck
    Дата: 18.04.12
    . Так вот, просто иногда достаточно что-бы операция просто работала за приемлемое время, а разница в производительности компенсируется удобством. Железо сейчас для текущих операций позволяет.

    ЗЫ. Я в вас запутался. AndrewVK привёл пример, когда всё-всё поднимается в память и быстро быстро обрабатывается лапша-кодом, и говорит, что лучше нельзя, а тебе ставит плюсик, когда ты говоришь, что это плохо плохо.
    Я ненавижу Hibernate
    Автор: Andrei N.Sobchuck
    Дата: 08.01.08
    !
    Re[28]: Языки общего назначения не имеют смысла!
    От: Andrei N.Sobchuck Украина www.smalltalk.ru
    Дата: 18.04.12 15:53
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    AVK>Я так понимаю, что весь топик ты не читал? Потому что я, как бы, в курсе. Но на шарпе все равно будет как минимум не хуже.


    Тогда тебе будет польза от обсуждения с Sinclair его идей по декомпозиции запросов. Должно получится лучше чем на C#.

    AVK>Нет. Меня больше читабельность интересует. Но и с ней никаких преимуществ по сравнению с шарпом нет.


    Ок. Но пока получается, что читабельноcть C# кода может и есть, а вот с бизнес-сутью — проблемы. Пример:
    var card = ((IPersistedObject)invCardObj).Master as IInventoryCardBase;
    if (card is IAccrualAccountingInventoryCard)
      Manager.DeleteObject((IPersistedObject)invCardObj);
    else if (!cardsDeleteSet.Contains(card))
      invCardObj.Inventory = inv;


    ANS>> В примере типичный "лапша-код", из-за того, что если не сделать всё за один проход по циклам, то оно будет тормозить так, что можно будет сказать, что оно не работает.

    AVK>Нет, тормозить оно особо не будет.
    AVK>Все коллекции на момент прохода уже в памяти

    Хм. Вот этот код мне как-бы намекает, что не всё в памяти:
    inv.GetInventoryOperations(relatedOperation.AccountingKind, null, null, null, null, null)
                        .Any(op => op.Order > relatedOperation.Order)

    Но тебе виднее, конечно. Если он не лезет в БД, то — ок.

    AVK>и на фоне активной работы с БД накладные


    Это если всё в ОЗУ влезет.

    AVK>расходы на лишний проход в микроскоп не увидишь.


    Тогда мне вообще не понятно на какой ляд вводить промежуточные переменные, размазывать и перемешивать между собой реализацию разных бизнес-правил.

    AVK>Я не спорю, я пытаюсь выслушать мнения (отличные от "пример не годится").


    Пример, как раз годится. Мне кажется, что "внешний DSL" можно легче породить когда есть "внутренний DSL". Но я не уверен, что легко соглашусь с тем, что API из примере это "внутренний DSL".
    И, вообще, позволю себе вернутся к мысли, которую пытался выразить завуалировано. Признание проблемы это первый шаг к исцелению. Ты утверждаешь, что лучше нельзя. Как тогда можно сделать лучше, если даже нет попытки найти решение?

    ANS>>А какое там API для сторонних приложений?

    AVK>Каких таких сторонних?

    которые в другом процессе/по сети работают и хотят в этой системе операции творить.
    Я ненавижу Hibernate
    Автор: Andrei N.Sobchuck
    Дата: 08.01.08
    !
    Re[29]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 18.04.12 15:56
    Оценка:
    Здравствуйте, Andrei N.Sobchuck, Вы писали:

    ANS>И, вообще, позволю себе вернутся к мысли, которую пытался выразить завуалировано. Признание проблемы это первый шаг к исцелению. Ты утверждаешь, что лучше нельзя.


    Я нигде подобного не утверждал.

    ANS>>>А какое там API для сторонних приложений?

    AVK>>Каких таких сторонних?

    ANS>которые в другом процессе/по сети работают и хотят в этой системе операции творить.


    Свой протокол поверх HTTP.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[33]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 18.04.12 16:05
    Оценка:
    Здравствуйте, Andrei N.Sobchuck, Вы писали:

    ANS>Фраза не несущая конкретики. Может моё решение и плохое, но твоя фраза это пожелание мира во всём мире.

    Я не вижу у вас никакого решения. Я вижу какие-то непонятные мне слова про метаобъектные протоколы.
    Моя "идея" решения — в том, чтобы поддерживать в языке средства декомпозиции.

    ANS>Не совсем понял какая связь с моим утверждением. Мне кажется естественным и понятным ситуация, когда запрос на апдейт уходит с сервера приложения. Ты же хочешь, чтобы запрос уходил на сервер, там он (пре)процесился и порождался конечный запрос.

    Мне кажется, что вы неверно понимаете суть реальной ситуации. Любой запрос сейчас уходит на сервер, препроцессится, и порождается конечный запрос. Я, возможно, сейчас порву какие-то шаблоны, но внутри сервера, помимо наблюдаемых с клиента таблиц, в вышеупомянутом запросе участвуют индексы, блокировки, логи для восстановления и репликации и прочий малоинтересный стафф. Мне не очень важно, сколько там происходит стадий в этом "препроцессинге" — важен конечный результат.
    К примеру, когда я делаю select * from something where date > ...., я могу обращаться к view, которое построено поверх других view, и так далее. Это ничему не противоречит и никого не пугает, т.к. стандартизовано.

    ANS>Мне ситуация когда пользовательская логика размазана между СУБД и приложением кажется ненормальной. Ты же, с одной стороны, говоришь, что происходит четкое разделение обязанностей (я с этим согласен), с другой предлагаешь запихивать в сервер какую-то логику.

    Конечно предлагаю. Потому что логику нужно держать близко к тому месту, где живут данные, с которыми она работает. Ибо таскать данные туда-сюда — дорого. Идея "давайте использовать RDBMS чисто как хранилище данных" — это misconception. Забивание гвоздей при помощи электрического шуруповёрта.
    Причём идея эта происходит в основном от отчаяния. Потому что нет способа "нормально" запихать эту логику в сервер.
    Ну и понятно, что догика логике рознь. Логика "если вот этот параметр не выбран, то вон те нужно скрыть" прекрасно обработается на клиенте. Логика "найди мне список самых подходящих мест на этот рейс" лучше пусть работает внутри сервера.

    ANS>И, я так понял, что ты сразу сомневаешься, в моём предположении, что JS это наше будущее
    Автор: Andrei N.Sobchuck
    Дата: 18.04.12
    . Так вот, просто иногда достаточно что-бы операция просто работала за приемлемое время, а разница в производительности компенсируется удобством. Железо сейчас для текущих операций позволяет.

    Да я ни в чём не сомневаюсь. Вот, у нас сейчас есть один маленький кусочек приложения, который хранит данные в RDBMS в виде key:json. Пользуясь безлимитностью varchar полей в SQLite. Ну так он и рассчитан на частые неконтролируемые обновления приложения, и логики в нём самом собственно минимум — это, фактически, кэш-прослойка между нами и 3rd-party cервисом.

    ANS>ЗЫ. Я в вас запутался. AndrewVK привёл пример, когда всё-всё поднимается в память и быстро быстро обрабатывается лапша-кодом, и говорит, что лучше нельзя, а тебе ставит плюсик, когда ты говоришь, что это плохо плохо.

    Вот такие мы разносторонние
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[30]: Языки общего назначения не имеют смысла!
    От: Andrei N.Sobchuck Украина www.smalltalk.ru
    Дата: 19.04.12 07:03
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    AVK>Свой протокол поверх HTTP.


    RPC или вот эти самые запросы на языке запросов?
    Я ненавижу Hibernate
    Автор: Andrei N.Sobchuck
    Дата: 08.01.08
    !
    Re[34]: Языки общего назначения не имеют смысла!
    От: Andrei N.Sobchuck Украина www.smalltalk.ru
    Дата: 19.04.12 07:23
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>Мне кажется, что вы неверно понимаете суть реальной ситуации. Любой запрос сейчас уходит на сервер, препроцессится, и порождается конечный запрос. Я, возможно, сейчас порву какие-то шаблоны, но внутри сервера, помимо наблюдаемых с клиента таблиц, в вышеупомянутом запросе участвуют индексы, блокировки, логи для восстановления и репликации и прочий малоинтересный стафф. Мне не очень важно, сколько там происходит стадий в этом "препроцессинге" — важен конечный результат.

    S>К примеру, когда я делаю select * from something where date > ...., я могу обращаться к view, которое построено поверх других view, и так далее. Это ничему не противоречит и никого не пугает, т.к. стандартизовано.

    Ну, типа, вау. Но ты действительно не замечаешь разницы между внутренними механизмами сервера и тонами логики которые ты должен залить в сервер и там поддерживать?

    ANS>>Мне ситуация когда пользовательская логика размазана между СУБД и приложением кажется ненормальной. Ты же, с одной стороны, говоришь, что происходит четкое разделение обязанностей (я с этим согласен), с другой предлагаешь запихивать в сервер какую-то логику.

    S>Конечно предлагаю. Потому что логику нужно держать близко к тому месту, где живут данные, с которыми она работает. Ибо таскать данные туда-сюда — дорого. Идея "давайте использовать RDBMS чисто как хранилище данных" — это misconception. Забивание гвоздей при помощи электрического шуруповёрта.

    Это попытки нагрузить сервер чем-то кроме выполнения запросов это misconception. От нищеты и попытки на спичках экономить. Но сейчас потихоньку складывается такая ситуация, что там где есть смысл заливать логику в RDBM, там нет смысла пользоваться RDBM, а проще взять какой-то noSql и книжку Крокфорда (единственное, что сейчас мешает это незрелость). А вот там где преимущества RDBM встают в полный рост, там нет смысла логику заливать.
    Я ненавижу Hibernate
    Автор: Andrei N.Sobchuck
    Дата: 08.01.08
    !
    Re[35]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 19.04.12 07:57
    Оценка: +1
    Здравствуйте, Andrei N.Sobchuck, Вы писали:

    ANS>Ну, типа, вау. Но ты действительно не замечаешь разницы между внутренними механизмами сервера и тонами логики которые ты должен залить в сервер и там поддерживать?

    View — это не внутренний механизм сервера. Это чистой воды логика, которую я должен залить в сервер и там поддерживать.
    Stored Procedure — то же самое.

    Я вообще не очень понимаю, чего вы стесняетесь. Имея, допустим, сервер на ASP.NET, вы что, не заливаете в сервер тонны логики?
    Чем IIS по-вашему лучше MS SQL? Точно такой же сервер, только программируется на другом языке.
    И вот язык программирования MS SQL удобен не всегда.

    ANS>Это попытки нагрузить сервер чем-то кроме выполнения запросов это misconception. От нищеты и попытки на спичках экономить. Но сейчас потихоньку складывается такая ситуация, что там где есть смысл заливать логику в RDBM, там нет смысла пользоваться RDBM, а проще взять какой-то noSql и книжку Крокфорда (единственное, что сейчас мешает это незрелость). А вот там где преимущества RDBM встают в полный рост, там нет смысла логику заливать.

    Непонятно, откуда вы это взяли. Я вам привожу пример запроса, который вы никаким noSQL не сделаете эффективнее. И никаким ORM вы его не сделаете эффективнее. SQL — это правильная, хорошая идея, не доведённая до конца.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[36]: Языки общего назначения не имеют смысла!
    От: Andrei N.Sobchuck Украина www.smalltalk.ru
    Дата: 19.04.12 08:10
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    ANS>>Ну, типа, вау. Но ты действительно не замечаешь разницы между внутренними механизмами сервера и тонами логики которые ты должен залить в сервер и там поддерживать?

    S>View — это не внутренний механизм сервера. Это чистой воды логика, которую я должен залить в сервер и там поддерживать.
    S>Stored Procedure — то же самое.

    Так я и считаю, что в норме SP — это не нормально. В крайних случаях для хаков — да, а так — нет. View еще туда сюда. И то если это само приложение создаёт, а не какой-то мифический DBA.

    S>Я вообще не очень понимаю, чего вы стесняетесь. Имея, допустим, сервер на ASP.NET, вы что, не заливаете в сервер тонны логики?

    S>Чем IIS по-вашему лучше MS SQL? Точно такой же сервер, только программируется на другом языке.

    Разница хотя бы в том, что http-сервер это сродни сокет серверу. Никто сейчас не выносит код, который аксептит сокеты в отдельный сервер.


    S> SQL — это правильная, хорошая идея, не доведённая до конца.


    Если она так и не доведена до конца, то откуда удивление, что люди ищут альтернативу?
    Я ненавижу Hibernate
    Автор: Andrei N.Sobchuck
    Дата: 08.01.08
    !
    Re[37]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 19.04.12 08:31
    Оценка:
    Здравствуйте, Andrei N.Sobchuck, Вы писали:

    ANS>Так я и считаю, что в норме SP — это не нормально. В крайних случаях для хаков — да, а так — нет. View еще туда сюда. И то если это само приложение создаёт, а не какой-то мифический DBA.

    Разница между этими понятиями достаточно условна. Есть жизненный цикл приложения, и он в общем случае одинаков.

    ANS>Разница хотя бы в том, что http-сервер это сродни сокет серверу. Никто сейчас не выносит код, который аксептит сокеты в отдельный сервер.

    Я вас не понимаю. Современный HTTP-сервер — это штука, которая быстро отдаёт файлы в сокет. Примерно так же, как SQL-сервер отдаёт select * from customers из таблицы.

    В него можно вставить прослойку между файлами и сокетом. Это будет пользовательская логика, которую (о, ужас!) надо заливать в сервер и поддерживать её там.

    S>> SQL — это правильная, хорошая идея, не доведённая до конца.

    ANS>Если она так и не доведена до конца, то откуда удивление, что люди ищут альтернативу?
    Я удивляюсь не самому поиску альтернативы, а тому, где люди её ищут. То есть вместо дорабатывания SQL будем отказываться от него вовсе.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[38]: Языки общего назначения не имеют смысла!
    От: Andrei N.Sobchuck Украина www.smalltalk.ru
    Дата: 19.04.12 08:45
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    ANS>>Разница хотя бы в том, что http-сервер это сродни сокет серверу. Никто сейчас не выносит код, который аксептит сокеты в отдельный сервер.

    S>Я вас не понимаю. Современный HTTP-сервер — это штука, которая быстро отдаёт файлы в сокет. Примерно так же, как SQL-сервер отдаёт select * from customers из таблицы.

    Из SQL сервера можно запросит что-то сложнее чем "select * from customers", а из чистого http сервера — нет.

    S>В него можно вставить прослойку между файлами и сокетом. Это будет пользовательская логика, которую (о, ужас!) надо заливать в сервер и поддерживать её там.


    Разница в том, что логика размазывается по двум местам. При этом хранение логихи в БД имеет в добавок некую специфику. Но главное — должно быть разделение обязаностей.

    S>>> SQL — это правильная, хорошая идея, не доведённая до конца.

    ANS>>Если она так и не доведена до конца, то откуда удивление, что люди ищут альтернативу?
    S>Я удивляюсь не самому поиску альтернативы, а тому, где люди её ищут. То есть вместо дорабатывания SQL будем отказываться от него вовсе.

    Зачем отказываться. Ему место в самом низу. Там где его никто не видит.
    Я ненавижу Hibernate
    Автор: Andrei N.Sobchuck
    Дата: 08.01.08
    !
    Re[39]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 19.04.12 10:26
    Оценка:
    Здравствуйте, Andrei N.Sobchuck, Вы писали:

    ANS>Из SQL сервера можно запросит что-то сложнее чем "select * from customers", а из чистого http сервера — нет.

    Зато из чистого HTTP сервера можно запросить if modified since, а из SQL — нет. Дальше что?

    ANS>Разница в том, что логика размазывается по двум местам. При этом хранение логихи в БД имеет в добавок некую специфику. Но главное — должно быть разделение обязаностей.

    Разделение обязанностей всегда есть.

    ANS>Зачем отказываться. Ему место в самом низу. Там где его никто не видит.

    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[31]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 19.04.12 21:20
    Оценка:
    Здравствуйте, Andrei N.Sobchuck, Вы писали:

    AVK>>Свой протокол поверх HTTP.


    ANS>RPC или вот эти самые запросы на языке запросов?


    RPC
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[20]: Языки общего назначения не имеют смысла!
    От: akochnev Россия  
    Дата: 20.04.12 11:59
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    На шарпе я не пишу. Все идеи взяты из GORM (Grails' object relational mapping).
    Рассмотрим строку:
    var documents = Manager.Get(objectsIds);

    Если я правильно понимаю, то есть сущность InternalDisplacementDocument, объекты которой хранятся в базе данных, есть класс Manager и метод Get, который написан руками и возвращает список объектов InternalDisplacementDocument для заданных ключей.
    Задача ORM хорошо подходит для использования DSL. Можно было бы написать:
    var documents = InternalDisplacementDocument.findAllById(objectsIds);

    И некоторым образом (например положить в определенный пакет) указать, что класс InternalDisplacementDocument является моделью, т.е. будет маппиться в БД.
    Обработчик DSL, не найдя написанного руками метода findAllById, сгенерирует его. Название поля Id, по которому нужно сделать запрос будет взято из названия метода. Префикс findAllBy используется для нахождения всех объектов, удовлетворяющих критерию, префикс findBy только для одного любого.

    Аналогично:
    // Найти все связанные операции по видам учета
    IInventoryOperation[] operations = inv.GetInventoryOperations(
        null, InventoryOperationKindEnum.InternalDisplacement, (IDocument)doc, null, null, null);

    Может быть заменено на:
    IInventoryOperation[] operations = InventoryOperation.findAllByKindAndDocument(InternalDisplacement, doc)


    if (inv.GetInventoryOperations(relatedOperation.AccountingKind, null, null, null, null, null)
                        .Any(op => op.Order > relatedOperation.Order))

    на
    if (InventoryOperation.findAllByAccountingKindAndOrderGreaterThan(relatedOperation.AccountingKind, relatedOperation.Order))

    Что делает автоматически генерируемый метод findAllByAccountingKindAndOrderGreaterThan я думаю пояснений не требует.
    таким образом, сокращается количество кода, написанного вручную.

    Или, например, код
    Manager.DeleteObject((IPersistedObject)invAfter);

    Зачеркнут код, который не имеет отношения к бизнес-логике. DSL позволит записать:
    invAfter.delete()

    Необходимый минимум. И пусть уже обработчик DSL решает, как раскрыть delete метод.

    Что касается остального кода, то, как уже правильно замечали, DSL это скорее описание архитектуры. Если получиться выделить отдельный свой логики, то для него можно будет разработать DSL. В данном примере скорее требуется декомпозиция

    AVK>Ну давай проведем эксперимент. Вот типовой серверный бизнес-код на универсальном языке — C#. Давай ты продемонстрируешь, как все будет круто на DSL?
    Re[21]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 20.04.12 13:02
    Оценка:
    Здравствуйте, akochnev, Вы писали:

    A>Задача ORM хорошо подходит для использования DSL. Можно было бы написать:

    A>
    A>var documents = InternalDisplacementDocument.findAllById(objectsIds);
    A>

    A>И некоторым образом (например положить в определенный пакет) указать, что класс InternalDisplacementDocument является моделью, т.е. будет маппиться в БД.

    Нет никакого класса InternalDisplacementDocument. Есть только интерфейс IInternalDisplacementDocument. И суть замены на статический метод (которому неясно как контекст передавать) мне непонятна.

    A>Обработчик DSL, не найдя написанного руками метода findAllById, сгенерирует его.


    А зачем его генерировать?

    A>Аналогично:

    A>
    A>// Найти все связанные операции по видам учета
    A>IInventoryOperation[] operations = inv.GetInventoryOperations(
    A>    null, InventoryOperationKindEnum.InternalDisplacement, (IDocument)doc, null, null, null);
    A>

    A>Может быть заменено на:
    A>
    A>IInventoryOperation[] operations = InventoryOperation.findAllByKindAndDocument(InternalDisplacement, doc)
    A>


    Не может. Внутри GetInventoryOperations бизнес-логика, а не тривиальный отбор по условию.


    A>Что делает автоматически генерируемый метод findAllByAccountingKindAndOrderGreaterThan я думаю пояснений не требует.

    A>таким образом, сокращается количество кода, написанного вручную.

    На 3 копейки.

    A>Или, например, код

    A>
    A>Manager.DeleteObject((IPersistedObject)invAfter);
    A>

    A>Зачеркнут код, который не имеет отношения к бизнес-логике. DSL позволит записать:
    A>
    A>invAfter.delete()
    A>


    Ты серьезно думаешь, что это что то заметно улучшит?

    A>Что касается остального кода, то, как уже правильно замечали, DSL это скорее описание архитектуры.


    Ну, то есть, на самое интересное ответа и нет.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[22]: Языки общего назначения не имеют смысла!
    От: akochnev Россия  
    Дата: 20.04.12 14:17
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    A>>Задача ORM хорошо подходит для использования DSL. Можно было бы написать:

    A>>
    A>>var documents = InternalDisplacementDocument.findAllById(objectsIds);
    A>>

    A>>И некоторым образом (например положить в определенный пакет) указать, что класс InternalDisplacementDocument является моделью, т.е. будет маппиться в БД.

    AVK>Нет никакого класса InternalDisplacementDocument. Есть только интерфейс IInternalDisplacementDocument. И суть замены на статический метод (которому неясно как контекст передавать) мне непонятна.


    Не угадал название мало деталей...
    В том то и дело, что это не статический метод — это DSL, который обозначает для модели InternalDisplacementDocument нужно выбрать все объекты для заданных objectsIds. Компилятор может развернуть этот DSL
    var documents = Manager.Get(objectsIds);

    если я правильно понимаю, то Manager не имеет отношения к бизнес логике, а является лишь механизмом реализации запроса. DSL призван скрыть особенности реализации. Если я пишу на уровне бизнес логики, то я ничего не знаю о сущности Manager. Мне просто нужно выбрать все документы по определенному набору id.

    A>>Обработчик DSL, не найдя написанного руками метода findAllById, сгенерирует его.


    AVK>А зачем его генерировать?

    Очевидно, чтобы не писать руками. Ведь метод Manager.Get(objectsIds) был написан вручную? Но решает то он типовую задачу. В приведенном по id также выбираются объекты IObjectLink из LinkManager. Предположу, что этот метод решает ту же задачу. Его также можно автоматически генерировать по DSL типа:
    ObjectLink.findAllById( ((IIdentifiableObject)invAfter).Id )


    A>>Аналогично:

    A>>
    A>>// Найти все связанные операции по видам учета
    A>>IInventoryOperation[] operations = inv.GetInventoryOperations(
    A>>    null, InventoryOperationKindEnum.InternalDisplacement, (IDocument)doc, null, null, null);
    A>>

    A>>Может быть заменено на:
    A>>
    A>>IInventoryOperation[] operations = InventoryOperation.findAllByKindAndDocument(InternalDisplacement, doc)
    A>>


    AVK>Не может. Внутри GetInventoryOperations бизнес-логика, а не тривиальный отбор по условию.

    Понял.

    A>>Что делает автоматически генерируемый метод findAllByAccountingKindAndOrderGreaterThan я думаю пояснений не требует.

    A>>таким образом, сокращается количество кода, написанного вручную.

    AVK>На 3 копейки.

    Ок. Наверное, это зависит от специфики приложения. В тех, приложениях, которые я видел, подобные простые запросы все же использовались довольно часто (как в составе более сложных, так и по отдельности). Возможность не отвлекаться на реализацию таких методов (а также сопутствующей архитектуры) позволяла сразу приступать к реализации требуемой функциональности, снижая общие затраты на разработку.

    A>>Или, например, код

    A>>
    A>>Manager.DeleteObject((IPersistedObject)invAfter);
    A>>

    A>>Зачеркнут код, который не имеет отношения к бизнес-логике. DSL позволит записать:
    A>>
    A>>invAfter.delete()
    A>>


    AVK>Ты серьезно думаешь, что это что то заметно улучшит?


    Не претендуя на абсолютную истину, думаю, что да, улучшит.
    DSL не является серебряной пулей. Сам по себе он не способен уменьшить сложность бизнес логики. Он призван отделить именно "бизнес-логику" от деталей реализации, не имеющих к ней отношение.
    Я думаю, что ты не будешь спорить, что в данном примере бизнес логика смешивается с деталями ее имплементации. И не будешь спорить, что вынесение запроса в слой доступа к данным в Manager.Get(objectsIds) лучше, чем реализация его по месту использования. Перемешивание SQl запросов и бизнес логики ведь считается плохой практикой. DSL это просто еще один шаг в разделении бизнес логики и остального кода.

    A>>Что касается остального кода, то, как уже правильно замечали, DSL это скорее описание архитектуры.


    AVK>Ну, то есть, на самое интересное ответа и нет.

    Я не считаю, что использование DSL именно этот кусок кода сделает значительно лучше/понятнее.
    Я всего лишь попытался привести примеры, в которых использование DSL упрощает интерфейс и избавляет от ручного написания некоторой части кода.
    Re[23]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 20.04.12 19:05
    Оценка: :)
    Здравствуйте, akochnev, Вы писали:

    A>В том то и дело, что это не статический метод — это DSL, который обозначает для модели InternalDisplacementDocument нужно выбрать все объекты для заданных objectsIds. Компилятор может развернуть этот DSL

    A>
    A>var documents = Manager.Get(objectsIds);
    A>


    Ну и смысл?

    A> DSL призван скрыть особенности реализации.


    Это какая то уж очень причудливая абстракция. Принципиально замена Manager на OLaLa ничего не меняет.

    A>>>Обработчик DSL, не найдя написанного руками метода findAllById, сгенерирует его.


    AVK>>А зачем его генерировать?

    A>Очевидно, чтобы не писать руками.

    Так его не надо писать руками Он уже написан.

    A> Ведь метод Manager.Get(objectsIds) был написан вручную?


    Ну да, один раз, причем в платформе.

    A> Но решает то он типовую задачу.


    Так зачем еще один метод решения типовой задачи?

    A> В приведенном по id также выбираются объекты IObjectLink из LinkManager. Предположу, что этот метод решает ту же задачу.


    Нет.

    A> Его также можно автоматически генерировать по DSL типа:


    Генерация метода, который внутри вызывает ровно один метод с той же сигнатурой — практический смысл сего действа мне по прежнему непонятен.

    AVK>>На 3 копейки.

    A>Ок. Наверное, это зависит от специфики приложения. В тех, приложениях, которые я видел, подобные простые запросы все же использовались довольно часто

    Понимаешь, нет в приведенном коде никаких таких запросов. Есть просто логика. Да, перебор можно как то упростить, но, в данном случае, все это прекрасно переписывается на linq без каких либо спецDSL. А вот тот код, который у меня наибольший интерес вызывает — вот его ты рассматривать не хочешь. И оно понятно почему — задачка то куда сложнее.

    AVK>>Ты серьезно думаешь, что это что то заметно улучшит?


    A>Не претендуя на абсолютную истину, думаю, что да, улучшит.


    Что именно?

    A>DSL не является серебряной пулей. Сам по себе он не способен уменьшить сложность бизнес логики. Он призван отделить именно "бизнес-логику" от деталей реализации, не имеющих к ней отношение.


    Думаю, многие с тобой тут не согласятся. Для отделения логики от реализации достаточно средств языка, DSL для этого — как из пушки по воробьям.

    A>Я думаю, что ты не будешь спорить, что в данном примере бизнес логика смешивается с деталями ее имплементации.


    Буду. Нет в ней никаких деталей импл..., убил бы реализации. Manager, который тебя так беспокоит — абстрактный интерфейс, фабрика бизнес-объектов. Никакого смысла от него избавляться нет. А LinkManager — вообще часть бизнес-логики, а не часть платформы.

    AVK>>Ну, то есть, на самое интересное ответа и нет.

    A>Я не считаю, что использование DSL именно этот кусок кода сделает значительно лучше/понятнее.

    Ну, собственно, этого достаточно.

    A>Я всего лишь попытался привести примеры, в которых использование DSL упрощает интерфейс и избавляет от ручного написания некоторой части кода.


    Удобные примеры я и сам могу привести сколько хочешь (и даже приводил здесь). Вопрос в примерах неудобных, потому что название топика позиционирует DSL как универсальный всемогутер.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[39]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 20.04.12 19:08
    Оценка:
    Здравствуйте, Andrei N.Sobchuck, Вы писали:

    ANS>Разница в том, что логика размазывается по двум местам.


    Это всего лишь вопрос деплоймента. И никто не мешает сделать деплоймент полностью автоматическим.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[9]: Языки общего назначения не имеют смысла?
    От: netch80 Украина http://netch80.dreamwidth.org/
    Дата: 22.04.12 05:53
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    N>>Хорошо, я теперь буду знать, что "я бы не назвал белое белым" является адекватным выражением твоей точки зрения. Учтём это в спорах об уездном городе языке N и других горячих темах

    VD>Ты занимаешься демагогией. Он же привел отличный пример. Монеты ни разу не компакт-диски, не смотря на то, что они несомненно компактные, и несомненно диски.

    Это отличный пример, если заранее поверить в правильность его выводов, но если нет, то он натягивается на что угодно и служит разве что обоснованием того, что надо вначале разобраться, что и как называть. А он не разобрался, или намеренно выделил только самый частный случай.

    VD>Причем дело доходит до обсурда.

    VD>Один под ДСЛ-нем начинает понимать все языки программирования которые кто-то прикрутил к какому то приложению (в том числе и жабаскрпит в броузерах).
    VD>Другой называет ДСЛ-ем наличие модели в приложении.
    VD>Третий видит ДСЛ в любом АПИ.

    А ты думаешь, зачем я предложил несколько уровней "вложенности" понятий? Ты в принципе не найдёшь общего подхода для всех, и каждая из этих точек зрения имеет свой смысл и своё основание.

    VD>Фаулер не рассматривает отвлеченных тем. Он рассматривает то, что он сам считает (и называет) ДСЛ-ями.

    VD>По сему он привел ряд критериев которые позволяют назвать язык ДСЛ-ем (по его мнению). Я сними согласен.
    VD>Но к сожалению, они неформальны. Вот они:
    VD>Предметно(ориентированный язык (сущ.) — это язык программирования с ограниченными выразительными возможностями, ориентированный на некую конкретную предметную область.

    У тебя в цитатах какие-то странные символы, выглядят квадратами или цепочками квадратов.

    Определение Фаулера, насколько я вижу, близко к самому жёсткому из моих вариантов ("ограничен").

    VD>• Природа языка. DSL является языком программирования и как таковой должен давать ощущение свободы выразительных возможностей, проистекающее не только из отдельных выражений, но и из способа их соединения.


    Нужно ли было давать это в критерии? Это совсем неформализуемый признак.

    VD>Обратите внимание на то, что ориентированность на предметную область оказалась последней в списке и является лишь следствием ограниченных выразительных возможностей.


    Верно, самый жёсткий — ограниченный — вариант или будет специализированным (тогда у него есть необходимые признаки для хоть какой-то успешности), или он дохнет. Но такое определение заведомо отрезает, например, язык 1C. С другой стороны, почему тогда это domain *specific*, а не domain *restricted* language?

    VD>Его мысль в том, что наличие одного из условий еще не делает язык ДСЛ-ем. Нужно сочетание факторов.

    VD>И я с этим категорически согласен.

    N>>Прикидка определения каждого из этих понятий:

    N>>* ориентированность — имеет специализированные средства для названной цели, но не общую адаптацию
    N>>* специализированность — адаптирован в целом (в общих принципах) под названную цель
    N>>* специфичность — реализация запросов за пределами названной цели заметно усложнена
    N>>* ограниченность — не имеет средств, выходящих за пределы, нужны для реализации названной цели
    VD>Опять какая-то каша. Ориентированность, специализированность и специфичность — это все из одной оперы.

    Нет. Это последовательно сжимающиеся условия, каждое следующее всё более ограничено по сравнению с предыдущим.

    VD>Твои критерии вообще никуда не годятся. Критерии фаулера — годятся.


    Критерий Фаулера — только мой случай ограниченности, с автоматически потянувшимися за ним остальными ограничениями. Мои позволяют назвать и остальные типичные случаи.
    Например, C — *специализирован* на системное программирование, а Fortran — на численные расчёты, хотя ни один из них не *ограничен* и относительно слабо *специфичен*. Если пользоваться критериями Фаулера, ты их в принципе не различишь — они все будут в пределах одного "это не DSL, а что за птица — хрен его знает, мы не умеем такое различать". Я же могу назвать в этих терминах, чем они отличаются, и указать конкретные признаки.

    VD>Язык с неограниченной выразительностью ДСЛ-ем быть не может, согласно этим критериям.

    VD>Таким образом полные по тьюрингу языки вполне могут быть ДСЛ-ями, если их тьюринг-полнота не дате писать что попало в любой области.

    С этим полностью согласен.

    VD>Зато язык не полный по тьюрингу и ориентированный на конкретную задачу — это уже точно ДСЛ.


    А вот тут уже нет. Во-первых, не понятно в твоём случае, что значит "ориентирован". Во-вторых, отсутствие тьюринг-полноты не означает отсутствие средств для совсем другой цели. Про DSL можно говорить только тогда, когда мы определяем этот домен и соответствие ему; но язык может соответствовать нескольким доменам. Например, HTML — это что? Hypertext markup language? Тогда зачем в нём картинки, скрипты, CSS?

    VD>И вообще, важно разделять ориентацию на предметную область, и ориентацию на задачу. ДСЛ ориентирован на одру конкретную задачу,


    Точно одну? См. выше про HTML.

    VD> а не на предметную область в широком понимании этого термина. Скажем императивный язык для бухгалтерии — это не ДСЛ. А вот язык запросов к документам — ДСЛ.


    Мне это не нравится в первую очередь из-за того, что у тебя термин DSL оторвался от породившего его языка. Слово specific обычно не означает пригодность и ограниченность только для данной цели; я специально глянул в словарь — сказано "related to one thing and not others", но это related, а не более жёсткое отношение. Это к тому, что внедрение такого понимания, по крайней мере в англоязычной среде, будет сопровождаться насилием над понятием.
    То, что ты имеешь в виду, должно быть DTL или DRL. Ибо targeted, restricted.

    N>>Во-во. Проблему он почувствовал, но выразить не супел.

    VD>Он то сумел. Просто кто-то кобенится и не хочет понять сказанного.

    Админ, исцелись сам.

    VD>Я бы предпочел четкую терминалогию, и четкое разделение понятий. Язык 1Эс нужно отличать как от универсальных ЯОН-ов, так и от ДСЛ-ей. Это самостоятельный класс языков.


    Верно. Это DTL. А определение Фаулера — это DRL.

    VD>В том то и дело, что у нас дисскурссия возникает даже по крайним случаям. Есть не мало упертых товарищей которые называют ДСЛ-ями ВБА.


    Я согласен. Это DSL, а конкретно — Domain Specialized Language.

    VD> А кое-то (весьма не глупый) вообще дофилософствовался до того, что подменил понятие "уровень языка" понятием "ДСЛ", а ДСЛ в его словах это любой язык относительно языка более низкого уровня.


    Читай внимательно — это неизбежный, но вторичный признак.

    VD>Такие "знания" и такая терминология не дает возможность продуктивно обсуждать данную область.


    Даёт. А вот если ограничиваться только одной жёсткой границей по Фаулеру — тогда обсуждения действительно не получится.

    VD>Так что нужно сделать одно из двух:

    VD>1. Ограничить определение термина ДСЛ выделив независимые понятия в отдельные понятия и дав им названия (введя термины).
    VD>2. Придумать новые термины для подтипов ДСЛ-ей, если уж не удается прийти к консенсусу в п.1.

    Это я и пытаюсь сделать.

    VD>Вот регекспы и ВБА по-твоему ДСЛ-и?


    Первое — domain restricted, второе — domain specialized.

    VD>Если, да, то нужно придумать новые термины для различения этих подвидов ДСЛ-ей.


    См. выше.

    VD>Если нет, то для ВБА нужно придумать отдельный термин, а ДСЛ-ем называть только регекспы.


    VD>Для ВБА термин есть — скриповый язык встроенный в хост-приложение. А как нажвать класс ДСЛ-ей в который входят регексы, SQL и т.п.?


    См. выше.
    The God is real, unless declared integer.
    Re[21]: Языки общего назначения не имеют смысла!
    От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
    Дата: 22.04.12 20:35
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Так что остается только одна проблема. Как заставить неверующих Фом хотя бы взглянуть на то, что у нас получается. Я уже не говорю об использовании.


    А у тебя всегда ктото другой виноват. Твой вопрос абсолютно неконструктивный, ибо фактически ты признаешь что эти неверующие фомы определяют ваш успех.
    Более конструктивно будет задаться вопросами
    Кто есть ваша ЦА ?
    Что ей нужно ?
    Еак донести до ЦА ваши разработки ?

    Вобщем играйте в свои дсл для роутинга урлов, пермишнов и тд и тд.
    Re[23]: Языки общего назначения не имеют смысла!
    От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
    Дата: 22.04.12 20:48
    Оценка: :)
    Здравствуйте, WolfHound, Вы писали:

    V>>Дык, Пратт его показал в каком-то махровом 70-м году и никто ни кого не послал. Ведь Дракон — лишь одна из мн-ва работ на эту тему, но почему-то стала более популярной... Не насильно же...

    WH>Насильно. Ибо в институтах только это направление и дают.

    Ты вообще хорошо понимаешь, что такое система образования, какие у нее задачи и какой критерий отбора материала для обучения ?
    Re[22]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 22.04.12 21:35
    Оценка:
    Здравствуйте, Ikemefula, Вы писали:

    I>Еак донести до ЦА ваши разработки ?


    Для Фомы — это бессмысленно. Вот до тебя я вроде информацию донес, но что толку то? У тебя же вера в том, что тебя обманывают. Ты же проверять не будешь. А что тебе на словах можно доказать?

    I>Вобщем играйте в свои дсл для роутинга урлов, пермишнов и тд и тд.


    Ага. И вам приятно лясы поточить.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[24]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 23.04.12 08:23
    Оценка:
    Здравствуйте, Ikemefula, Вы писали:

    WH>>Насильно. Ибо в институтах только это направление и дают.

    I>Ты вообще хорошо понимаешь, что такое система образования, какие у нее задачи и
    Ее задача подготовить адекватных специалистов.
    Но она с этим не справляется.
    Ибо когда молодой специалист приходит на производство ему говорят, забудь все чему тебя учили и начинают учить по новой.

    I>какой критерий отбора материала для обучения ?

    По желанию левой пятки ответственных за подбор материала.
    Но так как они давно оторвались от реальности, они не могут подобрать нормальный материал, даже если захотят.
    Но самое скверное, что им часто пофигу. Что-то читают. Получают деньги. И ладно.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[40]: Языки общего назначения не имеют смысла!
    От: Andrei N.Sobchuck Украина www.smalltalk.ru
    Дата: 24.04.12 11:27
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    ANS>>Разница в том, что логика размазывается по двум местам.

    AVK>Это всего лишь вопрос деплоймента. И никто не мешает сделать деплоймент полностью автоматическим.

    Вторая разница в том, что изменение процедур в БД изменяет состояние. И обычно это несколько более сложная операция чем копирование новых файлов.
    Я ненавижу Hibernate
    Автор: Andrei N.Sobchuck
    Дата: 08.01.08
    !
    Re[41]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 24.04.12 11:29
    Оценка:
    Здравствуйте, Andrei N.Sobchuck, Вы писали:

    ANS>Вторая разница в том, что изменение процедур в БД изменяет состояние.


    Какое состояние и чем это плохо?

    ANS> И обычно это несколько более сложная операция чем копирование новых файлов.


    Разница непринципиальна. В больших системах все равно процедура деплоймента нетривиальна — структуру БД ту же надо привести в соответствие. На этом фоне апдейт хранимок — просто ерунда.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[26]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 24.04.12 16:18
    Оценка: :)
    Здравствуйте, FR, Вы писали:

    FR>
    FR>std::for_each(v.begin(), v.end(),
    FR>    if_(arg1 > 5)
    FR>    [
    FR>        std::cout << arg1 << ", "
    FR>    ]
    FR>);
    FR>


    С++ с квадратными скобками... Я знал, что С++ сделан для глумления над С!
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[15]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 25.04.12 05:43
    Оценка: :)
    Здравствуйте, WolfHound, Вы писали:

    WH>Отличный ДСЛ для разбора деревьев.


    Угу, пока кол-во вариантов узлов микроскопическое. Ты уже приводил отличные примеры с упрощением выражений для своего парсера.
    Re[11]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 25.04.12 05:45
    Оценка: -1 :)
    Здравствуйте, WolfHound, Вы писали:

    WH>>>2)Сложность рукопашного кода всё равно больше. Чем сложность компилятора.

    T>>Не нужно передергивать.
    WH>В каком месте?

    Например в месте обзора сложности компилятора N.
    Re[12]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 25.04.12 05:47
    Оценка:
    Здравствуйте, Tanker, Вы писали:

    T>Я видел проекты где решения вроде string.split работали десятками лет. Для чего там полноценный парсер ? Я вот не смог объяснить, потому там и по сей день string.split.


    Если объемы данных невелики, то пойдет string.split, если же велики — то только оперативная обработка.
    Re[10]: Языки общего назначения не имеют смысла?
    От: netch80 Украина http://netch80.dreamwidth.org/
    Дата: 25.04.12 06:17
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    AVK>Я бы сказал, вы все тут молодцы демагогией в той или иной степени занимаетесь Потому что обсуждение терминов почти всегда оно и есть. Правда, стоит заметить, что, почему то, топики с участием netch80 явно чаще среднего по больнице на обсуждение терминов скатываются.


    А жаль. Это значит, что слишком много флеймов, где спорят, совершенно не согласовав, о чём вообще говорят.
    The God is real, unless declared integer.
    Re[15]: Языки общего назначения не имеют смысла!
    От: netch80 Украина http://netch80.dreamwidth.org/
    Дата: 25.04.12 06:23
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    N>>Добавлю только, что само понятие "языка" с чёткими требованиями к синтаксису может быть чрезмерным для тех, кто пишет на DSL. Поэтому вопроса развиваются графические представления — для тех случаев, где они достаточны, и в них соблюдение синтаксических норм достигается само собой.

    O> А вот на этом пути надо не перегибать палку. В некоторых промышленных CAD-ах так старались добиться "нечеткого" и "естественного" синтаксиса, что получились языки с тысячами ключевых слов и десятитомными документациями.

    А я и не предлагал двигаться в эту сторону. В случае графически представимого DSL, внутренний синтаксис есть почти целиком дело исполняющей среды, и она может от этого уйти. В случае же явно записываемого человеком, есть как минимум два примера, оба достаточно знамениты: COBOL и конфиги fetchmail. В обоих адаптация под близость к естественному языку привела, хоть и по-разному, к одному и тому же — и естественного языка не добились, и искусственный получился каким-то... мнэээ... странноватым и малоудобным.
    The God is real, unless declared integer.
    Re[11]: Языки общего назначения не имеют смысла?
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 25.04.12 07:30
    Оценка: +1
    Здравствуйте, netch80, Вы писали:

    N>А жаль. Это значит, что слишком много флеймов, где спорят, совершенно не согласовав, о чём вообще говорят.


    Моя практика показывает, что как только разговор заходит о трактовке терминов, ветку сразу можно бросать читать, потому что ничего интересного в ней уже не будет, один пустой срач.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 33 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[23]: Языки общего назначения не имеют смысла!
    От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
    Дата: 25.04.12 11:10
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Здравствуйте, Ikemefula, Вы писали:


    I>>Еак донести до ЦА ваши разработки ?


    VD>Для Фомы — это бессмысленно. Вот до тебя я вроде информацию донес, но что толку то? У тебя же вера в том, что тебя обманывают.


    И как ты решил что я это часть твоей ЦА? У меня не вера, а факты, как вы забили на обратную совместимость.

    >Ты же проверять не будешь. А что тебе на словах можно доказать?


    Что бы проверить на реальном проекте, мне нужно рассказать начальству как у вас все классно с обратной совместимостью, то есть пойти на прямой обман.
    Re[25]: Языки общего назначения не имеют смысла!
    От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
    Дата: 25.04.12 11:14
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>>>Насильно. Ибо в институтах только это направление и дают.

    I>>Ты вообще хорошо понимаешь, что такое система образования, какие у нее задачи и
    WH>Ее задача подготовить адекватных специалистов.

    Осталось раскрыть что же ты вкладываешь в понятие "адекватных". Наверняка сюда ты хочешь притянуть "компиляторы" и "генераторы парсеров"

    WH>Но она с этим не справляется.

    WH>Ибо когда молодой специалист приходит на производство ему говорят, забудь все чему тебя учили и начинают учить по новой.

    Это у вас так ? Сочувствую.

    I>>какой критерий отбора материала для обучения ?

    WH>По желанию левой пятки ответственных за подбор материала.

    Соболезную твоему опыту.

    Выйди на улицу и посмотри, какие проекты приходят в девелоперские конторы и в каких количествах. Отсюда станет ясно, что за запросы у отрасли и как их можно удовлетворить.
    Re[12]: Языки общего назначения не имеют смысла?
    От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
    Дата: 25.04.12 11:36
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    N>>А жаль. Это значит, что слишком много флеймов, где спорят, совершенно не согласовав, о чём вообще говорят.


    AVK>Моя практика показывает, что как только разговор заходит о трактовке терминов, ветку сразу можно бросать читать, потому что ничего интересного в ней уже не будет, один пустой срач.


    А тебе что, нравится наблюдать людей, которые спорят друг с другом хотя излагают ровно одно и то же только разными словами ?

    Не совсем понятно, откуда возьмутся общие термины для вещей, которые не расписаны детально в букварях. И неясно, как прийти к согласию, если люди пользуются разными источниками.
    Re[27]: Языки общего назначения не имеют смысла!
    От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
    Дата: 25.04.12 11:58
    Оценка: :)
    Здравствуйте, Sinclair, Вы писали:

    S>6. Опять даункаст. В целом, выглядит, как размазанная запись правила, которое в оригинале звучало как "убить все карточки, которые входят в бла-бла-бла". DSL, который бы позволял написать "убить все карточки, которые входят в бла-бла-бла", не отвлекаясь на порядок обхода итераторов, даункасты, и скобочки, был бы крайне уместен.


    Так самое интересное в этих "бла-бла-бла". Но как только появляется не только выборка, но и всякие оптимизации, что откуда правильно тянуть, а потом появляются модификации, и снова оптимизации, что где правильно модифицировать, то крайне сложно придумать ДСЛ. А просто рожать ДСЛ для убиения карточек толку мало
    Re[28]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 25.04.12 12:32
    Оценка: :)
    Здравствуйте, Ikemefula, Вы писали:

    I>Так самое интересное в этих "бла-бла-бла". Но как только появляется не только выборка, но и всякие оптимизации, что откуда правильно тянуть, а потом появляются модификации, и снова оптимизации, что где правильно модифицировать, то крайне сложно придумать ДСЛ. А просто рожать ДСЛ для убиения карточек толку мало

    Все оптимизации должна делать платформа. Все вот эти вот "я лучше компилятора знаю, сколько у меня регистров" или "мне виднее, какой предикат селективнее" — повод улучшить платформу.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[29]: Языки общего назначения не имеют смысла!
    От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
    Дата: 25.04.12 12:44
    Оценка: :)
    Здравствуйте, Sinclair, Вы писали:

    I>>Так самое интересное в этих "бла-бла-бла". Но как только появляется не только выборка, но и всякие оптимизации, что откуда правильно тянуть, а потом появляются модификации, и снова оптимизации, что где правильно модифицировать, то крайне сложно придумать ДСЛ. А просто рожать ДСЛ для убиения карточек толку мало

    S>Все оптимизации должна делать платформа. Все вот эти вот "я лучше компилятора знаю, сколько у меня регистров" или "мне виднее, какой предикат селективнее" — повод улучшить платформу.

    Ну значит надо ждать хорошую платформу, в которой иммутабельность, ленивость, кеширование и тд вообще не расходуют никаких ресурсов, а до тех пор придется писать старым дедовским способом.
    Re[26]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 25.04.12 13:24
    Оценка:
    Здравствуйте, Ikemefula, Вы писали:

    I>Осталось раскрыть что же ты вкладываешь в понятие "адекватных". Наверняка сюда ты хочешь притянуть "компиляторы" и "генераторы парсеров"

    Нет. Но в институтах этому учат. Причем учат не правильно.
    После этой учёбы у людей либо появляется устойчивое мнение, что компиляторы это сложно. Либо что еще хуже случается дракон головного мозга. И они начинают хотеть заниматься факторизацией грамматик. А то, что существуют грамматики (не БНФ) которые и без этого работают они понять не в состоянии.

    WH>>Ибо когда молодой специалист приходит на производство ему говорят, забудь все чему тебя учили и начинают учить по новой.

    I>Это у вас так ? Сочувствую.
    Это везде так. Причем в программировании особенно. Если студент не работал во время учебы, то он вообще писать не может.

    WH>>По желанию левой пятки ответственных за подбор материала.

    I>Соболезную твоему опыту.
    У тебя есть другая информация? Поделишься?

    I>Выйди на улицу и посмотри, какие проекты приходят в девелоперские конторы и в каких количествах. Отсюда станет ясно, что за запросы у отрасли и как их можно удовлетворить.

    Заодно объясни, почему учат Виртовским поделкам? Какие запросы отрасли удовлетворяют?
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[27]: Языки общего назначения не имеют смысла!
    От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
    Дата: 25.04.12 14:13
    Оценка: +1 :)
    Здравствуйте, WolfHound, Вы писали:

    I>>Осталось раскрыть что же ты вкладываешь в понятие "адекватных". Наверняка сюда ты хочешь притянуть "компиляторы" и "генераторы парсеров"

    WH>Нет. Но в институтах этому учат. Причем учат не правильно.
    WH>После этой учёбы у людей либо появляется устойчивое мнение, что компиляторы это сложно. Либо что еще хуже случается дракон головного мозга. И они начинают хотеть заниматься факторизацией грамматик. А то, что существуют грамматики (не БНФ) которые и без этого работают они понять не в состоянии.

    Ты о чем то о своём, наболевшем Ты похоже путаешь колмгоровскую сложность с когнитивной. Ты пойми простую вещь, с т.з. колмбгоровской сложности древние мировоззрения слижнее нынешних. С точки зрения когнитивной — всё наоборот.

    Если чтото просто тебе, то это иллюзия, т.к. ты потратил годы на прокачку. Самое страшное для тебя — ты эту простоту никому и никогда не сможешь передать одной формулой и воплями "здесь всё просто а кто не понял тот дурак". Что бы знания распространялись, ктото должнен будет потратить столько же времени как и ты.

    I>>Это у вас так ? Сочувствую.

    WH>Это везде так. Причем в программировании особенно. Если студент не работал во время учебы, то он вообще писать не может.

    Причина в том, что дать надлежащий уровень практики под силу только ведущим вузам планеты, вроде МИТ. Их штук 10 может и наберётся по всему миру. Этой горстки специалистов, что дают эти вузы, не хватит что бы закрыть потребность в индустрии хотя бы в лид-дев/архитекторах, не говоря о девелоперах.

    WH>>>По желанию левой пятки ответственных за подбор материала.

    I>>Соболезную твоему опыту.
    WH>У тебя есть другая информация? Поделишься?

    Делился раз пятьсот в этом форуме и в форуме образование. Уже подустал. Челы вроде тебя продолжают утверждать прямо противоположные вещи, например что де компилеры-грамматики это просто, и тут же людей, кто чего то не понял, обзывают разными словами или призывают гнать из индустрии.
    Такого не бывает. Непонимание и отторжение это основные симптомы сложного направления. Если ты не понимаешь такой простой вещи, тебя нужно отстранить от форума ибо как и VladD2 похоронишь хорошее дело.

    I>>Выйди на улицу и посмотри, какие проекты приходят в девелоперские конторы и в каких количествах. Отсюда станет ясно, что за запросы у отрасли и как их можно удовлетворить.

    WH>Заодно объясни, почему учат Виртовским поделкам? Какие запросы отрасли удовлетворяют?

    На виртовских поделках учат некоторым способам решения задачи и целой куче алгоритмов. Что касается проблем, то это очень непростой вопрос.
    Бизнес постоянно платит вагоны денег за обыденные задачи, которых валом, хоть пруд пруди, что приводит к притоку низкоквалифицированых работников. Люди тупо идут за деньгами.

    С одной стороны это проблема. С другой стороны это приводит к разделению труда. Например люди вроде тебя могут не заниматься ковырянием мелочевки в UI или в запросах, а могут сосредоточиться на более важных задачах. Соответсвенно для бизнеса это гарантированый способ минимизации рисков и удешевление разработки.

    В образовании это проявляется в том, что ИТ-спецов учат чуть не где попало и все равно специалистов не хватает. Внимание, повторяю, не хватает !!! И это при том, что в программисты идут чуть ли не все подряд.

    Отсюда ясно, что проблемы не у Виртовского направления. Люди, кому сложны виртовские вещи, сильно вряд ли освоят "грамматики (не БНФ)". Например я точно знаю, что подавляющее большинство выпускников во всех странах бывшего СССР не в состоянии работать не только с вещами вроде АСТ, но даже рекурсию осваивают с трудом.
    До смешного доходит — распарсить строковое представление целого числа считается чуть не за верх совершенства.

    Теперь про бизнес. Проекты приходят и успешно сдаются безо вских компиляторов-ДСЛ и многих других вещей. Внимание еще раз — проекты успешно сдаются. Успешность определяет сам бизнес. Соответственно и ВУЗы подстраиваются под этот поток заявок.

    Отдельный момент — ДСЛ. Сочинение ДСЛ это крайне сложная задача. Если человек может решить бизнес-задачу, то это совершенно не значит, что он может сочинить ДСЛ для решения целого класса подобных задач. Даже если может написать фреймворк, то опять же не значит, что и ДСЛ сможет накидать.

    И снова про разделение труда — как только оно более менее определится, снова уровень квалификации выпускников пойдет вверх. Это закон природы. Что бы он произошел, программухой должны заняться буквально необученые массы.

    Собственно не все так плохо как кажется, раньше были просто программисты, сейчас от этой массы уже откололись всякие веб-кодеры, безопасники, админы, тестировщики, которые вобщем то тоже программисты. Т.е. разработчик ПО != программист.
    Re[28]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 25.04.12 15:10
    Оценка:
    Здравствуйте, Ikemefula, Вы писали:

    I>Ты о чем то о своём, наболевшем Ты похоже путаешь колмгоровскую сложность с когнитивной. Ты пойми простую вещь, с т.з. колмбгоровской сложности древние мировоззрения слижнее нынешних. С точки зрения когнитивной — всё наоборот.

    В каком месте гелиоцентрическая система сложнее геоцентрической?
    Правильный ответ: Она во всех отношениях проще.
    А книга дракона это луноцентрическая система. Ни понять. Ни запомнить.

    I>Если чтото просто тебе, то это иллюзия, т.к. ты потратил годы на прокачку. Самое страшное для тебя — ты эту простоту никому и никогда не сможешь передать одной формулой и воплями "здесь всё просто а кто не понял тот дурак". Что бы знания распространялись, ктото должнен будет потратить столько же времени как и ты.

    Нет. Годы я потратил на то чтобы перекопать мегатонны навоза и понять, как правильно делать.
    А самое страшное для тебя это то, что я эту самую простоту передаю всем, кто хочешь слушать.
    А тебя, конечно, ничего не передать. Ты ведь веришь что это все очень сложно.

    I>Причина в том, что дать надлежащий уровень практики под силу только ведущим вузам планеты, вроде МИТ. Их штук 10 может и наберётся по всему миру.

    Да ладно. Нужно только программу правильную давать.

    I>Такого не бывает. Непонимание и отторжение это основные симптомы сложного направления. Если ты не понимаешь такой простой вещи, тебя нужно отстранить от форума ибо как и VladD2 похоронишь хорошее дело.

    Это не направление сложное.
    Его дают сложно.
    Разницу улавливаешь или как?
    Это всё равно что принять за центр вселенной луну.
    Прикинь какие траектории у небесных тел получатся...
    Вот именно так и преподают компиляторы.

    I>На виртовских поделках учат некоторым способам решения задачи и целой куче алгоритмов. Что касается проблем, то это очень непростой вопрос.

    А что мешает этому учить на более актуальных инструментах?
    Хотя бы на C#?

    I>В образовании это проявляется в том, что ИТ-спецов учат чуть не где попало и все равно специалистов не хватает. Внимание, повторяю, не хватает !!! И это при том, что в программисты идут чуть ли не все подряд.

    Их не хватает именно по тому, что они используют плохие методики и инструменты.
    При правильном подходе число разработчиков можно сократить в десятки раз.

    I>Например я точно знаю, что подавляющее большинство выпускников во всех странах бывшего СССР не в состоянии работать не только с вещами вроде АСТ, но даже рекурсию осваивают с трудом.

    Вот только они так и ходят кругами по собеседованиям пока им это не надоедает.
    А еще ноют по форумам, что на собеседовании гады заставляют написать 10 строчек кода. После того как они завалили задание уровня FizzBuzz.
    По-хорошему институт им не должен давать диплом вообще. Ибо работать они всё равно не смогут.

    I>Теперь про бизнес. Проекты приходят и успешно сдаются безо вских компиляторов-ДСЛ и многих других вещей. Внимание еще раз — проекты успешно сдаются. Успешность определяет сам бизнес. Соответственно и ВУЗы подстраиваются под этот поток заявок.

    Только стоимость этих проектов в десятки раз больше чем могла бы быть.
    Но так как бизнес убедили, что по-другому быть не может вот этот бедный бизнес и платит за не пойми что.

    I>Отдельный момент — ДСЛ. Сочинение ДСЛ это крайне сложная задача. Если человек может решить бизнес-задачу, то это совершенно не значит, что он может сочинить ДСЛ для решения целого класса подобных задач. Даже если может написать фреймворк, то опять же не значит, что и ДСЛ сможет накидать.

    Написать ДСЛ проще, чем написать фреймворк.
    Просто по тому, что при написании фреймворка нужно решить две задачи.
    1)Создать модель предметной области.
    2)Натянуть модель предметной области на модель целевого языка так чтобы код не превратился в говно и работал не со скоростью улитки.

    Причем вторая задача сложнее первой.

    В случае с ДСЛ нам нужно решить только первую.
    Вторую решать не надо. Ибо ДСЛ может генерировать любой говнокод. Ибо читать его всё равно никто не будет. Главное чтобы правильно и быстро работал.

    I>И снова про разделение труда — как только оно более менее определится, снова уровень квалификации выпускников пойдет вверх. Это закон природы. Что бы он произошел, программухой должны заняться буквально необученые массы.

    не пойдет. Ибо для того чтобы он пошёл в верх нужно менять преподов и программу.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[13]: Языки общего назначения не имеют смысла?
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 25.04.12 15:52
    Оценка:
    Здравствуйте, Ikemefula, Вы писали:

    I>А тебе что, нравится наблюдать людей, которые спорят друг с другом хотя излагают ровно одно и то же только разными словами ?


    Такое бывает редко. Обычно просто прячутся за терминологией, когда аргументы кончаются.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 43 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[14]: Языки общего назначения не имеют смысла?
    От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
    Дата: 25.04.12 16:02
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    I>>А тебе что, нравится наблюдать людей, которые спорят друг с другом хотя излагают ровно одно и то же только разными словами ?


    AVK>Такое бывает редко. Обычно просто прячутся за терминологией, когда аргументы кончаются.


    Странно, я такое вижу почти в каждом треде на этом форуме, а у тебя это редко
    Re[29]: Языки общего назначения не имеют смысла!
    От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
    Дата: 25.04.12 16:20
    Оценка: +1
    Здравствуйте, WolfHound, Вы писали:

    I>>Ты о чем то о своём, наболевшем Ты похоже путаешь колмгоровскую сложность с когнитивной. Ты пойми простую вещь, с т.з. колмбгоровской сложности древние мировоззрения слижнее нынешних. С точки зрения когнитивной — всё наоборот.

    WH>В каком месте гелиоцентрическая система сложнее геоцентрической?
    WH>Правильный ответ: Она во всех отношениях проще.

    С когнитивной тз она сложнее, например потому что юзер не в курсе про то что такое солнце. Для него солнце это шарик на синем небе. шарик и небо ему понятны. А все остальное он не может пощупать. Соответсвенно гелиоцентричекую ты такому юзеру в голову не вобьёшь до тех пор, пока он не потрогает все руками.

    Когнитивная сложность определяется наличием соответсвующих понятий в голове юзера. Понятия прокачиваются даже не годами, а вообще постоянно, сколько человек живет, столько прокачиваются понятия и взаимосвязи между ними.
    Нет понятий или они не прокачаны — все что на эти понятия опирается будет адски сложным и будет вызывать попа-боль.

    Иначе, как через ручной труд понятия не прокачиваются. Вообще. Нет секретной формулы, котора сообщит знания того же паттерн-матчинга, если у юзер не решал руками все задачи на которые ориентирован ПМ.

    I>>Если чтото просто тебе, то это иллюзия, т.к. ты потратил годы на прокачку. Самое страшное для тебя — ты эту простоту никому и никогда не сможешь передать одной формулой и воплями "здесь всё просто а кто не понял тот дурак". Что бы знания распространялись, ктото должнен будет потратить столько же времени как и ты.

    WH>Нет. Годы я потратил на то чтобы перекопать мегатонны навоза и понять, как правильно делать.

    Ну то есть ты напрочь отрицаешь ценность практики ?

    WH>А самое страшное для тебя это то, что я эту самую простоту передаю всем, кто хочешь слушать.


    Это иллюзия. Эти люди работают вместе с тобой над одной целью. Потому и происходит переход. В виде формулы — не выйдет.

    WH>А тебя, конечно, ничего не передать. Ты ведь веришь что это все очень сложно.


    Мне как бы понятно было по дракону и по вирту Лично я вижу в ДСЛ только инструмент для решения хорошо формализованых задач в конкретной области. У меня как то маловато таких

    I>>Причина в том, что дать надлежащий уровень практики под силу только ведущим вузам планеты, вроде МИТ. Их штук 10 может и наберётся по всему миру.

    WH>Да ладно. Нужно только программу правильную давать.

    Тебе не кажется, что ты вещаешь про мировой заговор ? Я говорю про факты — должный уровень практики дают от силы десяток вузов. А у тебя какое то уникальное объяснение

    WH>Это не направление сложное.

    WH>Его дают сложно.

    Если все мерить колмгоровской сложностью, то да, парадокс не разрешим

    WH>Разницу улавливаешь или как?


    Для кого просто, для тебя, для меня, для того, кто работает столько же сколько и ты, или для того, кто еле справляется с FizzBuzz ?

    WH>Это всё равно что принять за центр вселенной луну.

    WH>Прикинь какие траектории у небесных тел получатся...
    WH>Вот именно так и преподают компиляторы.

    Колмгоровская сложность не имеет никакого отношения к тому, насколько легко люди осваивают новое.

    I>>На виртовских поделках учат некоторым способам решения задачи и целой куче алгоритмов. Что касается проблем, то это очень непростой вопрос.

    WH>А что мешает этому учить на более актуальных инструментах?
    WH>Хотя бы на C#?

    C# уже лет 5-6 как не новость для студентов. Где то 2й или 3й курс от силы.

    I>>В образовании это проявляется в том, что ИТ-спецов учат чуть не где попало и все равно специалистов не хватает. Внимание, повторяю, не хватает !!! И это при том, что в программисты идут чуть ли не все подряд.

    WH>Их не хватает именно по тому, что они используют плохие методики и инструменты.

    Начинать надо с качества абитуриентов. Мне уже не смешно, когда в программисты идут даже те, кто не сложение дробей не мог осилить.
    У тебя что, есть волшебная палочка, которая сделает из такого абитуариента адского специалиста ?

    WH>При правильном подходе число разработчиков можно сократить в десятки раз.


    Никаких конкретных выкладок у тебя нет на эту тему ? Покажи ты такие выкладки, тебе в любой конторе-гиганте дадут не только стол и стул, но и целое подразделение да еще и девок пучок.

    I>>Например я точно знаю, что подавляющее большинство выпускников во всех странах бывшего СССР не в состоянии работать не только с вещами вроде АСТ, но даже рекурсию осваивают с трудом.

    WH>Вот только они так и ходят кругами по собеседованиям пока им это не надоедает.

    Не только ходят, но еще и работают, при чем ЗП у них в среднем раз в 5 выше средней по стране. Завалил FizzBuzz — не беда, есть конкурентная фирма которая берет всех подряд и дает ЗП всего на 100$ меньше(а иногда, когда срочно, еще и больше).

    WH>А еще ноют по форумам, что на собеседовании гады заставляют написать 10 строчек кода. После того как они завалили задание уровня FizzBuzz.

    WH>По-хорошему институт им не должен давать диплом вообще. Ибо работать они всё равно не смогут.

    Вот-вот. А этих людей подавляющее большинство и это я еще про китайцев и индусов не говорил.

    Теперь жду внятных объяснений, как такому контингенту влить в голову грамматики, любые, какие тебе только нравятся.

    I>>Теперь про бизнес. Проекты приходят и успешно сдаются безо вских компиляторов-ДСЛ и многих других вещей. Внимание еще раз — проекты успешно сдаются. Успешность определяет сам бизнес. Соответственно и ВУЗы подстраиваются под этот поток заявок.


    WH>Только стоимость этих проектов в десятки раз больше чем могла бы быть.


    Ликбез. Бюджет разработки хорошо если 10% от той суммы что приносит продукт. А если продукт это не софт, то разработка и вовсе меньше 1%.
    Скажи, кто в своём уме будет оптимизировать ничтожно малое ?

    WH>Но так как бизнес убедили, что по-другому быть не может вот этот бедный бизнес и платит за не пойми что.


    Это снова теория заговора. С т.з. бизнеса наилучшие работники это
    1. понимающие специфику бизнеса
    2. направленые на результат
    3. ответственные,дисциплинированые, предсказуемые

    Странно, но здесь нет "ДСЛ"

    I>>Отдельный момент — ДСЛ. Сочинение ДСЛ это крайне сложная задача. Если человек может решить бизнес-задачу, то это совершенно не значит, что он может сочинить ДСЛ для решения целого класса подобных задач. Даже если может написать фреймворк, то опять же не значит, что и ДСЛ сможет накидать.

    WH>Написать ДСЛ проще, чем написать фреймворк.
    WH>Просто по тому, что при написании фреймворка нужно решить две задачи.
    WH>1)Создать модель предметной области.
    WH>2)Натянуть модель предметной области на модель целевого языка так чтобы код не превратился в говно и работал не со скоростью улитки.

    WH>Причем вторая задача сложнее первой.


    Для написания фремворка не нужна глубокая формализация. Часто хватает тупой императивщины и низкоуровневых операций. Тупо набор функций, даже без внятных абстракций — фремфорк готов. Высунь нос из немерел — такими фремворками завалены чуть не все хостинги. Что бы выдать хотя бы качествуенноую детальную формализацию задачи, нужно набить руку в таких задачах.

    WH>В случае с ДСЛ нам нужно решить только первую.


    Прграммисты годами тренируются кодить. Соотвесвенно формализация проблемы закончится ровно с записью решения в виде кода. Самое главное преимущество — фремворк не надо выпиливать заранее. Можно наговнокодить а через два года как появится потребность, отрефакторить, покрыть тестами и сделать фремфорк.
    Кроме того, для ДСЛ нужно заранее думать про оптимизации и все нюансы использования. С фремворком это не нужно — делаешь оптимизацию там где надо. То есть не нужна такая глубокая формализация. Да и фремворк не обязан покрывать все подряд.
    Более того — начинать внедрять можно практически сразу, как только готов первый приемочный тест.

    time to market — вот это рушит все надежды языко-писателей Потому ДСЛ интересен только в долгосрочной перспективе, если ожидается решение целой пачки задач, ане одной единственной.

    I>>И снова про разделение труда — как только оно более менее определится, снова уровень квалификации выпускников пойдет вверх. Это закон природы. Что бы он произошел, программухой должны заняться буквально необученые массы.

    WH> не пойдет. Ибо для того чтобы он пошёл в верх нужно менять преподов и программу.

    А где ж ты их наберёшь ? Думаешь если абитуриенты не умеют дроби складывать, то став преподавателями, они автоматом получат божественный интеллект ?
    Re[27]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 25.04.12 17:07
    Оценка: :)
    Здравствуйте, WolfHound, Вы писали:

    WH>Песец. Полный. Даже комментировать тот феерический бред, что ты тут понаписал, не хочу.


    Если правильно пользоваться терминологией и определениями, а не твоей свободной интерпретацией (типа неодноначности БНФ), то никакого бреда нет. Скорее всего, тебе просто нечего ответить.


    WH>

    WH>Это так, только если контекстно-свободная грамматика является неоднозначной. Т.е. если она не является на самом деле контекстно-свободной и мы располагаем лишь подмножеством контекстно-свободных правил из полной системы правил грамматики.

    WH>Аааааааааа!!!!!!!!!!!!!! Жжжжжжжжееееееесть.

    Да, пример был жесть. Ты повторно показал непонимание взаимоотношение грамматики языка и грамматики правил, по которой работает парсер этого языка. Почти никогда это отношение не является 1:1, иначе не нужен был бы семантический анализ.

    Ты привел пример грамматики, в котором A и B заведомо неразличимы. Но, если требуется их различимость, значит была приведена неполная грамматика, или язык заведомо неоднозначный. Но последний вариант по дефолту отбрасывается, т.к. неоднозначные языки не имеют практической ценности, по крайней мере в кач-ве языков программирования. Ведь ты просто не сможешь их скомпилить ни в какой технике. Т.е. либо это была неполная грамматика языка, как в случае x * y, описанном здесь, либо таки A и B неразличимы, например, являются промежуточными нетерминалами (ты знаешь что это такое?) и могут быть без всяких последствий "склеены" в один в процессе приведения грамматики.

    ============
    Тут уже разбирали как-то, что народ путает целевой формальный язык и грамматику парсера для него. Языки программирования зачастую контекстно-зависимые, но парсер будет работать скорее всего по неполной грамматике языка — по ее контекстно-свободной части, оставляя решение неоднозначностей семантическому анализатору. Насколько я помню, ты участвовал в том обсуждении, поэтому я хотел лишь напомнить, что ты и так должен был знать. Прочти теперь выделенную фразу еще раз — должно было полегчать.
    Re[28]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 25.04.12 18:37
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    V>Если правильно пользоваться терминологией и определениями, а не твоей свободной интерпретацией (типа неодноначности БНФ), то никакого бреда нет. Скорее всего, тебе просто нечего ответить.

    У меня с терминологией все в порядке.
    А вот ты не понимаешь, что БНФ может задать неоднозначную грамматику.
    Но разбирающие грамматики (PEG, TDOP,...) проектируют так, чтобы задать неоднозначную грамматику было бы не возможно по построению.

    WH>>

    WH>>Это так, только если контекстно-свободная грамматика является неоднозначной. Т.е. если она не является на самом деле контекстно-свободной и мы располагаем лишь подмножеством контекстно-свободных правил из полной системы правил грамматики.

    WH>>Аааааааааа!!!!!!!!!!!!!! Жжжжжжжжееееееесть.
    V>Да, пример был жесть.
    Он просто показал, что БНФ может задать неоднозначную грамматику.
    Только и всего.
    А твой гон про то, что неоднозначная КС грамматика не является КС грамматикой, просто противоречит всем определениям.

    V>Ты повторно показал непонимание взаимоотношение грамматики языка и грамматики правил, по которой работает парсер этого языка. Почти никогда это отношение не является 1:1, иначе не нужен был бы семантический анализ.

    Я про это говорю, уже не помню, сколько лет подряд.
    И тут ты заявляешь, что я это не понимаю.
    А еще я понимаю что то что приходится делать с БНФ для того чтобы скормить его генератору парсеров маразм.
    А те генераторы, что жрут любую КС грамматику тормоза.

    V>Ты привел пример грамматики, в котором A и B заведомо неразличимы.

    Именно. Я привел простейшую неоднозначную грамматику.

    V>Но, если требуется их различимость, значит была приведена неполная грамматика, или язык заведомо неоднозначный. Но последний вариант по дефолту отбрасывается, т.к. неоднозначные языки не имеют практической ценности, по крайней мере в кач-ве языков программирования. Ведь ты просто не сможешь их скомпилить ни в какой технике. Т.е. либо это была неполная грамматика языка, как в случае x * y, описанном здесь, либо таки A и B неразличимы, например, являются промежуточными нетерминалами (ты знаешь что это такое?) и могут быть без всяких последствий "склеены" в один в процессе приведения грамматики.

    Разбирающим грамматикам весь этот бред не нужен.
    Они однозначны по построению. Ты просто не сможешь задать неоднозначную разбирающую грамматику.
    И работают как есть без всяких факторизаций.

    Вся вина разбирающих грамматик в том, что они просты как пробка. И там исследовать нечего. Они просто работают. И как следствие на них не защитить диссертацию. Поэтому их научное сообщество и игнорирует.
    То ли дело БНФ. Тут тебе и факторизации. И привидения. И построение разбирающих алгоритмов на основе порождающих правил. И куча тому подобного бреда.

    Но мне на диссеры плевать.
    Я создаю практичное решение.
    Которым легко пользоваться.
    Вот это грамматика разбирает текст и создает АСТ нужной формы.
    Код генерируется по принципу, что вижу, то пою. Без трансформаций. Ручных или машинных.
    Самое сложное, что тут происходит это превращение литералов в ДКА.
    [Ast()]                                            Rule                        : Ast;
    [Ast(LeftRule, RightRules)]                        SequenceRule                is Rule = Rule : 10 (Rule : 10)+;
    [Ast(Op, Rule)]                                    NotRule                     is Rule = "!"s Rule : 20;
    [Ast(Op, Rule)]                                    AndRule                     is Rule = "&"s Rule : 20;
    [Ast(Rule, Op)]                                    OptionalRule                is Rule = Rule : 30 "?"s;
    [Ast(Rule, Op)]                                    ZeroOrManyRule              is Rule = Rule : 30 "*"s;
    [Ast(Rule, Op)]                                    OneOrManyRule               is Rule = Rule : 30 "+"s;
    [Ast(Char)]                                        CharRule                    is Rule = CharLiteral;
    [Ast(String)]                                      StringRule                  is Rule = StringLiteral;
    [Ast(Open, Rule, Close)]                           RoundsRule                  is Rule = "("s Rule ")"s;
    [Ast(Name, BP)]                                    CallRule                    is Rule = QIdentifier (":"s Number)?;
    [Ast(Open, Rule, Semicolon, Separator, Close, Op)] ZeroOrManyWithSeparatorRule is Rule = "("s Rule ";"s Rule ")"s "*"s;
    [Ast(Open, Rule, Semicolon, Separator, Close, Op)] OneOrManyWithSeparatorRule  is Rule = "("s Rule ";"s Rule ")"s "+"s;
    [Ast(Name, Open, Rule, Close)]                     Scope                       is Rule = Identifier "{"s Rule "}"s;

    Она однозначна по построению.
    Она понимает левую рекурсию, приоритеты и ассоциативность из коробки.
    Она поддерживает n-арные операторы. ChoiceTokenRule и SequenceTokenRule.
    Она поддерживает изменение грамматики во время разбора. Например, встретили "using syntax Xml;". Получили поддержку ХМЛ внутри C#. Область видимости закончилась синтаксис ХМЛ отключился.

    Ну и нахрена после этого нужен БНФ со всеми заморочками?

    V>Тут уже разбирали как-то, что народ путает целевой формальный язык и грамматику парсера для него. Языки программирования зачастую контекстно-зависимые,

    Зачастую? Тебе придется очень постараться, чтобы найти КС язык программирования. (Они конечно есть. Я даже регулярные знаю.) Ибо если у нас есть требование объявить перед использованием то это сразу минимум КЗ.

    V> но парсер будет работать скорее всего по неполной грамматике языка — по ее контекстно-свободной части, оставляя решение неоднозначностей семантическому анализатору. Насколько я помню, ты участвовал в том обсуждении, поэтому я хотел лишь напомнить, что ты и так должен был знать. Прочти теперь выделенную фразу еще раз — должно было полегчать.

    Вот пойди и почитай, что я там говорил.
    Оно сильно разойдется с тем, что ты мне тут пытаешься пришить.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[30]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 25.04.12 19:24
    Оценка:
    Здравствуйте, Ikemefula, Вы писали:

    I>С когнитивной тз она сложнее, например потому что юзер не в курсе про то что такое солнце. Для него солнце это шарик на синем небе. шарик и небо ему понятны. А все остальное он не может пощупать. Соответсвенно гелиоцентричекую ты такому юзеру в голову не вобьёшь до тех пор, пока он не потрогает все руками.

    И как же мне это еще в детском саду объяснили то?

    WH>>Нет. Годы я потратил на то чтобы перекопать мегатонны навоза и понять, как правильно делать.

    I>Ну то есть ты напрочь отрицаешь ценность практики ?
    Нет. Я говорю, что создание компиляторов на много проще чем принято думать.

    WH>>А самое страшное для тебя это то, что я эту самую простоту передаю всем, кто хочешь слушать.

    I>Это иллюзия. Эти люди работают вместе с тобой над одной целью. Потому и происходит переход. В виде формулы — не выйдет.
    Какой еще формулы?
    Какие люди?
    Ты действительно думаешь, что все кто заходит в форму по немерле пишут компилятор немерла? Или тем более работают над Н2?
    Над Н2 сейчас работает ровно один человек. И еще один статьи пишет.

    WH>>А тебя, конечно, ничего не передать. Ты ведь веришь что это все очень сложно.

    I>Мне как бы понятно было по дракону и по вирту Лично я вижу в ДСЛ только инструмент для решения хорошо формализованых задач в конкретной области. У меня как то маловато таких
    Ох. Сколько еще раз повторить, что то, что написано в драконе не пригодно для практического применения?
    Их методы заставляют делать в десятки, раз больше чем нужно и при этом даю посредственный результат.
    Все что ты мог вынести из дракона это: Компиляторы это сложно.
    И именно это ты и вынес. И пытаешься мне это втирать. Но я знаю, что это не так.

    I>Тебе не кажется, что ты вещаешь про мировой заговор ? Я говорю про факты — должный уровень практики дают от силы десяток вузов. А у тебя какое то уникальное объяснение

    Нет. Я вещаю про мировую глупость.

    WH>>Это не направление сложное.

    WH>>Его дают сложно.
    I>Если все мерить колмгоровской сложностью, то да, парадокс не разрешим
    Ох. В драконе когнитивная сложность тоже зашкаливает. Попробуй, объясни человеку что такое конфликт сдвиг/свертка.
    Вперед.
    При этом разбирающие грамматики можно объяснить за пять минут на пальцах.

    WH>>Разницу улавливаешь или как?

    I>Для кого просто, для тебя, для меня, для того, кто работает столько же сколько и ты, или для того, кто еле справляется с FizzBuzz ?
    Те, кто не может осилить FizzBuzz программы писать не должены.
    Совсем.
    Даже если больше никого нет.
    Ибо они просто физически не в состоянии это делать.
    Способность к программированию она как музыкальный слух. Если она есть ее можно развить. Если ее нет, то хоть ты что делай. Человек программы писать не сможет.

    I>C# уже лет 5-6 как не новость для студентов. Где то 2й или 3й курс от силы.

    Ну, так и зачем нужны Виртовские поделки?
    Вон тот же Лаптев с ними носится.

    I>Начинать надо с качества абитуриентов. Мне уже не смешно, когда в программисты идут даже те, кто не сложение дробей не мог осилить.

    I>У тебя что, есть волшебная палочка, которая сделает из такого абитуариента адского специалиста ?
    Их нужно просто выкидывать из профессии. Прямо в институте.
    А тем, кто может писать нужно дать инструменты, которые повысят их производительность.

    WH>>При правильном подходе число разработчиков можно сократить в десятки раз.

    I>Никаких конкретных выкладок у тебя нет на эту тему ? Покажи ты такие выкладки, тебе в любой конторе-гиганте дадут не только стол и стул, но и целое подразделение да еще и девок пучок.
    У меня есть не просто выкладки, а работающий прототип.
    И все что мне нужно я сам возьму.

    I>Не только ходят, но еще и работают, при чем ЗП у них в среднем раз в 5 выше средней по стране. Завалил FizzBuzz — не беда, есть конкурентная фирма которая берет всех подряд и дает ЗП всего на 100$ меньше(а иногда, когда срочно, еще и больше).

    Ты что этим доказать то хочешь?
    То, что есть идиоты, которые берут на работу тех, кто писать не может?
    Не надо. Я и так знаю, что они есть.

    I>Вот-вот. А этих людей подавляющее большинство и это я еще про китайцев и индусов не говорил.

    То-то сначала туда все ломанулись, а потом поняли что себе дороже. Это я про тех, кто продукт делает, а не бабло пилит.

    I>Теперь жду внятных объяснений, как такому контингенту влить в голову грамматики, любые, какие тебе только нравятся.

    Никак. Их нужно разогнать.
    Совсем.
    Ибо им в голову вообще ничего "влить" нельзя. У них просто нет нужного раздела головного мозга.

    I>Ликбез. Бюджет разработки хорошо если 10% от той суммы что приносит продукт. А если продукт это не софт, то разработка и вовсе меньше 1%.

    I>Скажи, кто в своём уме будет оптимизировать ничтожно малое ?
    Ох. И почему же в машинных кодах то не пишут?
    А по тому, что в машинных кодах просто ничего не напишешь. Люди такое не осилят.
    Для этого и придумали ЯВУ.
    Но и у ЯВУ есть свой придел сложности после которого в проект приходит жирная полярная лисичка.
    Поднять предел сложности проекта можно только еще сильнее повысив уровень инструмента.

    WH>>Но так как бизнес убедили, что по-другому быть не может вот этот бедный бизнес и платит за не пойми что.

    I>Это снова теория заговора. С т.з. бизнеса наилучшие работники это
    I>1. понимающие специфику бизнеса
    I>2. направленые на результат
    I>3. ответственные,дисциплинированые, предсказуемые
    Не могущие написать FizzBuzz но упорно идущие к цели...

    I>Для написания фремворка не нужна глубокая формализация.

    Ты не поверишь. Для ДСЛ тоже.

    WH>>В случае с ДСЛ нам нужно решить только первую.

    I>Прграммисты годами тренируются кодить. Соотвесвенно формализация проблемы закончится ровно с записью решения в виде кода. Самое главное преимущество — фремворк не надо выпиливать заранее. Можно наговнокодить а через два года как появится потребность, отрефакторить, покрыть тестами и сделать фремфорк.
    Так с ДСЛ все тоже самое.
    Ты посмотри на историю того же
    https://github.com/rampelstinskin/ParserGenerator
    И его предка, из которого я его итерациями переделал.
    https://github.com/rsdn/nemerle/tree/4855110cb34aa16ea6c5f481ee479bfe6513b706/snippets/peg-parser

    I>Кроме того, для ДСЛ нужно заранее думать про оптимизации и все нюансы использования.

    Не нужно.
    Это все допиливается по ходу дела.
    Особенно оптимизации.
    Которые возможно вообще делать не придется. Если и так производительности хватает.

    I>С фремворком это не нужно — делаешь оптимизацию там где надо. То есть не нужна такая глубокая формализация. Да и фремворк не обязан покрывать все подряд.

    I>Более того — начинать внедрять можно практически сразу, как только готов первый приемочный тест.
    Типа с ДСЛ это не так.
    Я же говорю, ты испорчен драконом.
    Все то, что ты говоришь можно и ДСЛем. Причем намного проще и быстрее.

    I>time to market — вот это рушит все надежды языко-писателей Потому ДСЛ интересен только в долгосрочной перспективе, если ожидается решение целой пачки задач, ане одной единственной.

    При правильных инструментах и методиках тут ДСЛи на высоте.

    I>А где ж ты их наберёшь ? Думаешь если абитуриенты не умеют дроби складывать, то став преподавателями, они автоматом получат божественный интеллект ?

    Я уже сто раз повторил. Выгонять не первой же сессии. Или еще лучше на вступительных экзаменах.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[26]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 26.04.12 00:38
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    V>Если ты описал эту грамматику в КС-форме, то я её сразу отношу к регулярным (у которых нет рекурсии в правилах или все рекурсии одного вида), т.е. ты описал исходный недетерминированный автомат регулярной грамматики. Согласно твоего же определения A и B неразличимы. Т.е. в этой регулярной грамматике даже конфликтов нет и она эквивалентна после минимизации такой: S->a.


    Я правильно понял, что ты утверждаешь, что БНФ описывает парсер?

    Приведенный ниже пример является корректным описанием с точки зрения БНФ?
    E = E + E;
    E = E * E;
    E = '1';


    Если — да, то какой парсер он описывает? Если нет, то почему?
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[29]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 26.04.12 01:45
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    V>>Если правильно пользоваться терминологией и определениями, а не твоей свободной интерпретацией (типа неодноначности БНФ), то никакого бреда нет. Скорее всего, тебе просто нечего ответить.

    WH>У меня с терминологией все в порядке.
    WH>А вот ты не понимаешь, что БНФ может задать неоднозначную грамматику.

    Да пофиг, это просто редукции, считай что уравнения. Тебя же не смущает, что ты можешь задать обычное уравнение, не имеющее решение?
    БНФ задает ВЕСЬ класс контекстно свободных грамматик, который самый важный на сегодня. В любом случае нужна нотация, нейтральная к способу разбора.


    WH>Но разбирающие грамматики (PEG, TDOP,...) проектируют так, чтобы задать неоднозначную грамматику было бы не возможно по построению.


    Дык, никто не спорит. Все пока больше спрашивают. Очевидно же, что ПЕГ задает лишь некий подкласс грамматик и навскидку можно насочинять полно мест, где будет хромать (твой же пример с if/else). В общем, есть сомнения, бо реализовал порядка пяти разных "взрослых" парсеров в разное время и есть вопросы, ответы на которые никогда еще не видел. Ты ведь так и не ответил на вопрос про скобки С++.


    V>>Да, пример был жесть.

    WH>Он просто показал, что БНФ может задать неоднозначную грамматику.
    WH>Только и всего.
    WH>А твой гон про то, что неоднозначная КС грамматика не является КС грамматикой, просто противоречит всем определениям.

    Ёпс... Да это же классика:

    (... идет определение неоднозначной грамматики)
    Однако это не означает, что язык L(G) обязательно неоднозначный. Определенная нами неоднозначность — это свойство грамматики, а не языка, т.е. для некоторых неоднозначных грамматик существуют эквивалентные им однозначные грамматики. Если грамматика используется для определения языка программирования, то она должна быть однозначной.


    Т.е. мне вообще трудно подбирать слова для обсуждения того, что на мой взгляд обсуждения не требует. Ну не может язык содержать неоднозначности. Точка. КС-грамматика может, ес-но.

    Более того, мне однажды пришлось писать парсер, где мне НУЖНА была неоднозначность по-условию. Многие алгоритмы выдаются все варианты разбора, я юзал GLR, как самый "оперативный" относительно входной цепочки (т.к. работает без возвратов а цепочка иногда на мегабайты). Поэтому для меня неоднозначность ни разу не проблема, а наоборот — удобное ср-во для написания парсера для КС-части КЗ-грамматики, т.к. не надо искусственно ресолвить неоднозначности на этапе разработки через нетерминалы-заместители и потом их дополнительно раскручивать.

    И ты дважды проигнорировал напоминание про процедуру приведения грамматики, на этапе которой отсекаются мертвые ветки и можно найти неоднозначности. БНФ ведь хороша своей симметричностью. Т.е. можно производить мн-во операций над системой правил, оставляя всю систему валидной. И все операции это аболютно реверсивны и результат заведомо известен. Поэтому обработку правил в БНФ можно (и нужно) автоматизировать. А в случае автоматизации очень многое из обсуждаемого малость до фени, сорри.

    Вот ПЕГ ты особо не преобразуешь (кроме тривиальных прямых подстановок заведомо промежуточных нетерминалов).


    WH>А еще я понимаю что то что приходится делать с БНФ для того чтобы скормить его генератору парсеров маразм.

    WH>А те генераторы, что жрут любую КС грамматику тормоза.

    ПЕГ жрет не любую. GRL тормозит только там, в грамматике существенные неоднозначности (большое кол-во несклеиваемых промежуточных нетерминалов), т.е. вызванные природой грамматики, т.е. на этой грамматике любой парсер будет требовать либо время, либо память. Но когда уровень неоднозначности в пределах нормы, то он довольно шустро разбирает ВЕСЬ класс КС-грамматик. Напротив, TDOP, насколько я помню — это простой способ парсить арифметические выражения и плохо подходит под произвольный синтаксис. Т.е. DSL в рамках TDOP будет заведомо обладать ограничениями.


    WH>Они однозначны по построению. Ты просто не сможешь задать неоднозначную разбирающую грамматику.

    WH>И работают как есть без всяких факторизаций.

    Ты всерьез считаешь, что никто тебя до сих пор не услышал? На самом деле пара примеров реальных DSL для реальной работы, с полным исходным кодом всего того, что потребовалось написать "сверху" имеющегося фреймворка, рассказало бы о всех плюсах и минусах лучше любого оратора на форуме.


    WH>Вся вина разбирающих грамматик в том, что они просты как пробка. И там исследовать нечего. Они просто работают. И как следствие на них не защитить диссертацию. Поэтому их научное сообщество и игнорирует.


    Нет, их игнорируют потому, что они задают обратный процесс написания языка: сначала его программирование, а потом что получилось — то и спецификация!
    Но читабельность человеком и читабельность программой — это две большие разницы. Определенно разрыв шаблона еще в том, что при разработке языка предлагается отталкиваться не от потребительских его кач-в, а от легкости написания его парсера... Не боишься, что разработанная тобой DSL потеряет значительную долю смысла, заложенную в сам факт ее существования? Чтобы заставить потом остальных программистов юзать DSL вместо милого их сердцу ЯВУ, синтаксис DSL должен быть ух и ах. Иначе усилия пропадут даром. Тут уже правильно говорили, что сама разработка DSL — сложная задача. Парсер — это уже так... В крайнем случае берется один из автоматических построителей — и копать отсюда и до обеда, в пару вечеров уложиться с первым работающим макетом парсера вполне можно...


    WH>То ли дело БНФ. Тут тебе и факторизации. И привидения. И построение разбирающих алгоритмов на основе порождающих правил. И куча тому подобного бреда.


    Автоматизируется. Кстати, я тут одну DSL постепенно пилю для своего хобби... надо попробовать испытать на вашей схеме... Но там явное КЗ-нарисовывается, иначе синтаксис придется резко урезать, а не хочется. Я же не могу, при всем своем уважении к себе споткнуться об парсер, правда? Тут как бы об саму DSL не споткнуться, а парсер — дело десятое или даже сотое.


    WH>Самое сложное, что тут происходит это превращение литералов в ДКА.


    Это как раз не самое сложное. Это я еще в дипломной работе делал черти сколько лет назад...

    Самое сложное в таком преобразовании — это отделить промежуточные нетерминалы от нецелевых и не потерять целевые при построении ДКА. Если происходит потеря, то строить надо не одноуровневый восходящий разбор (автоматный лексер), а многоуровневый, например LR(1). Он на участках, описываемых автоматной грамматикой, работает в точности со скоростью ДКА-сканера. Я уже когда-то вам советовал... жаль, что упоминание восходящего разбора на этом участке превратило всё обсуждение в срач. (Из-за того, что сам-то ПЕГ нисходящий).


    WH>
    ...
    WH>


    Посмотрел. С явными приоритетами чуть проще запись. Но дык, приоритеты операций в БНФ элегантно расписываются через промежуточные нетерминалы... Кто мешает генерить одно из другого?

    WH>Она понимает левую рекурсию, приоритеты и ассоциативность из коробки.

    WH>Она поддерживает n-арные операторы. ChoiceTokenRule и SequenceTokenRule.
    WH>Она поддерживает изменение грамматики во время разбора. Например, встретили "using syntax Xml;". Получили поддержку ХМЛ внутри C#. Область видимости закончилась синтаксис ХМЛ отключился.

    Не увидел как для C++ отличить умножение от символа указателя '*'.


    WH>Зачастую? Тебе придется очень постараться, чтобы найти КС язык программирования. (Они конечно есть. Я даже регулярные знаю.) Ибо если у нас есть требование объявить перед использованием то это сразу минимум КЗ.


    Если семантика зависит от значения идентификатора — то всегда КЗ. А оно в удобных языках всегда зависит, бо над одними сущностями языка определены одни операции, над другими — другие, а кол-во символов-знаков ограниченно. Отсюда дублирование синтаксиса для разных семантик. Даже в моем разрабатываемом DSL такая же беда, но это выглядит совершенно ЕСТЕСТВЕННО. А интересует, как ты понял, именно как оно выглядит и ничего более.
    Re[27]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 26.04.12 01:56
    Оценка:
    Здравствуйте, VladD2, Вы писали:


    V>>Если ты описал эту грамматику в КС-форме, то я её сразу отношу к регулярным (у которых нет рекурсии в правилах или все рекурсии одного вида), т.е. ты описал исходный недетерминированный автомат регулярной грамматики. Согласно твоего же определения A и B неразличимы. Т.е. в этой регулярной грамматике даже конфликтов нет и она эквивалентна после минимизации такой: S->a.


    VD>Я правильно понял, что ты утверждаешь, что БНФ описывает парсер?


    БНФ описывает грамматику. Просто я распознал класс грамматики согласно ее определения.

    VD>Приведенный ниже пример является корректным описанием с точки зрения БНФ?

    VD>
    VD>E = E + E;
    VD>E = E * E;
    VD>E = '1';
    VD>


    Вполне, если речь о нотации.

    VD>Если — да, то какой парсер он описывает? Если нет, то почему?


    При чем тут парсер? Парсер выполняется по какой-то технике, а БНФ заведомо нейтральна к любой технике. Это просто нотация КС-грамматик и ничего более. И задачи у парсеров могут быть разные. Если стоит задача дать любую удачную ветку разбора, то построить такой парсер по твоей грамматике не проблема. Если стоит задача написать парсер ЯП, то сам язык должен быть заведомо однозначным.
    Re[31]: Языки общего назначения не имеют смысла!
    От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
    Дата: 26.04.12 07:16
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    I>>С когнитивной тз она сложнее, например потому что юзер не в курсе про то что такое солнце. Для него солнце это шарик на синем небе. шарик и небо ему понятны. А все остальное он не может пощупать. Соответсвенно гелиоцентричекую ты такому юзеру в голову не вобьёшь до тех пор, пока он не потрогает все руками.

    WH>И как же мне это еще в детском саду объяснили то?

    Не объяснили, а раccказали как сказку и с этим балластом ты ничего не мог сделать до тех пор, пока накопил нужные знания и опыт, т.е. примерно до тех пор, где учитель физики или астрономии внятно объясняет по наглядной модели, которую, ВНИМАНИЕ !, можно пощупать.

    WH>>>Нет. Годы я потратил на то чтобы перекопать мегатонны навоза и понять, как правильно делать.

    I>>Ну то есть ты напрочь отрицаешь ценность практики ?
    WH>Нет. Я говорю, что создание компиляторов на много проще чем принято думать.

    Твои рассуждения не интересны по той причине, что ты через пост обвиняешь всех в тупости.

    WH>>>А самое страшное для тебя это то, что я эту самую простоту передаю всем, кто хочешь слушать.

    I>>Это иллюзия. Эти люди работают вместе с тобой над одной целью. Потому и происходит переход. В виде формулы — не выйдет.
    WH>Какой еще формулы?

    Любой. Ты потратил скажем десять лет и выдал все понимание одной-двумя строчками текста на русском языке. Любой кто умеет читать по русски внезапно становится способным создавать ДСЛ.

    WH>Какие люди?

    WH>Ты действительно думаешь, что все кто заходит в форму по немерле пишут компилятор немерла? Или тем более работают над Н2?

    Туда много кто заходит, например и я Люди про которых я говорю интересуются именно этим направлением и работают возможно не над немерле, а над своими проектами, где все это применяют. Вот потому и возможно распространение опыта.

    I>>Мне как бы понятно было по дракону и по вирту Лично я вижу в ДСЛ только инструмент для решения хорошо формализованых задач в конкретной области. У меня как то маловато таких

    WH>Ох. Сколько еще раз повторить, что то, что написано в драконе не пригодно для практического применения?

    Ты мне напоминаешь студентов-двоечников, которые повторяют, что знать матан не обязательно, ибо надо всего то деньги считать уметь.

    WH>Их методы заставляют делать в десятки, раз больше чем нужно и при этом даю посредственный результат.


    Да ладно, хорош гнать то. Давай проверим. Напиши компилятор модула за 1 час с нуля. Студенты по вирту делают это где то за две недели.

    WH>Все что ты мог вынести из дракона это: Компиляторы это сложно.


    Я как минимум представляю какой минимальный набор знаний и умений необходим для того, что бы родить простецкий ДСЛ. И этот набор много больше того, который требуется для решения большинства бизнес-задач.

    WH>И именно это ты и вынес. И пытаешься мне это втирать. Но я знаю, что это не так.


    С твоей верой я не собираюсь спорить

    I>>Тебе не кажется, что ты вещаешь про мировой заговор ? Я говорю про факты — должный уровень практики дают от силы десяток вузов. А у тебя какое то уникальное объяснение

    WH>Нет. Я вещаю про мировую глупость.

    Это такое же конспироложенство, как и мировой заговор. Кушай сам.

    I>>Если все мерить колмгоровской сложностью, то да, парадокс не разрешим

    WH>Ох. В драконе когнитивная сложность тоже зашкаливает. Попробуй, объясни человеку что такое конфликт сдвиг/свертка.

    Очевидно, с нуля это в принципе невозможно.

    WH>При этом разбирающие грамматики можно объяснить за пять минут на пальцах.


    Кому объяснить, тебе, мне, или тому, кто FizzBuzz не может родить на собеседовании ?

    I>>Для кого просто, для тебя, для меня, для того, кто работает столько же сколько и ты, или для того, кто еле справляется с FizzBuzz ?

    WH>Те, кто не может осилить FizzBuzz программы писать не должены.
    WH>Совсем.
    WH>Даже если больше никого нет.
    WH>Ибо они просто физически не в состоянии это делать.

    Твое мнение идет вразрез с наблюдаемой действительностью.

    WH>Способность к программированию она как музыкальный слух. Если она есть ее можно развить. Если ее нет, то хоть ты что делай. Человек программы писать не

    сможет.

    Ты путаешь инструмент и уровень владения оным. Ну нужно быть композитором, что бы играть свою музыку в балагане. У меня нет музыкального слуха, но мелодии для своих детей я могу придумать. Да и песенку сочинить тоже могу. С бизнесом точно так же, ты сильно переоцениваешь запросы индустрии.

    I>>C# уже лет 5-6 как не новость для студентов. Где то 2й или 3й курс от силы.

    WH>Ну, так и зачем нужны Виртовские поделки?

    Я уже внятно ответил. найди тот ответ и спрашивай что в ём неясно.

    I>>Начинать надо с качества абитуриентов. Мне уже не смешно, когда в программисты идут даже те, кто не сложение дробей не мог осилить.

    I>>У тебя что, есть волшебная палочка, которая сделает из такого абитуариента адского специалиста ?
    WH>Их нужно просто выкидывать из профессии. Прямо в институте.

    Если их выкинуть, тебе придется делать за них всю чОрную работу.

    WH>А тем, кто может писать нужно дать инструменты, которые повысят их производительность.


    чОрную работу пока невозможно исключить, потому что нет инструментов для автоматизации всех и вся.

    I>>Никаких конкретных выкладок у тебя нет на эту тему ? Покажи ты такие выкладки, тебе в любой конторе-гиганте дадут не только стол и стул, но и целое подразделение да еще и девок пучок.

    WH>У меня есть не просто выкладки, а работающий прототип.
    WH>И все что мне нужно я сам возьму.

    Прототип это ровно ничего.
    Что бы получить выкладки вроде тех, про которые ты говоришь, нужно внедрить инструмент в реальный проект и выкатить несколько версий. потом считаешь издержки и говоришь — вот, всё классно.
    Если хочешь доказать, что твои инструменты уменьшают зависимость от ЧФ, снова ровно то же, только проект должен сменить несколько команд исполнитлей.
    Снова считаешь издержки и снова показываешь результат.
    Кроме того, в бизнесе тебя обязательно спросят про обратную совместимость. Смотри, не облажайся, как Немерле. Здесь тоже нужны выкладки

    WH>Ты что этим доказать то хочешь?

    WH>То, что есть идиоты, которые берут на работу тех, кто писать не может?
    WH>Не надо. Я и так знаю, что они есть.

    Ты знаешь, но не понимаешь почему они там есть.

    I>>Вот-вот. А этих людей подавляющее большинство и это я еще про китайцев и индусов не говорил.

    WH>То-то сначала туда все ломанулись, а потом поняли что себе дороже. Это я про тех, кто продукт делает, а не бабло пилит.

    Я то про продукты, а ты про что ? Продукты это рынок, а что у тебя, разовые заказики ?

    I>>Теперь жду внятных объяснений, как такому контингенту влить в голову грамматики, любые, какие тебе только нравятся.

    WH>Никак. Их нужно разогнать.
    WH>Совсем.
    WH>Ибо им в голову вообще ничего "влить" нельзя. У них просто нет нужного раздела головного мозга.

    А между тем они решают задачи бизнеса. Это факт. И пока это не изменится, никто их не выбросит.

    I>>Ликбез. Бюджет разработки хорошо если 10% от той суммы что приносит продукт. А если продукт это не софт, то разработка и вовсе меньше 1%.

    I>>Скажи, кто в своём уме будет оптимизировать ничтожно малое ?
    WH>Ох. И почему же в машинных кодах то не пишут?

    Потому что разработка в машинных кодах на несколько порядков сложнее. То есть затраты на разработку вырастут на порядки.

    WH>А по тому, что в машинных кодах просто ничего не напишешь. Люди такое не осилят.


    Правильно. Потому стоимость разработки вырастает на порядки. То есть, твой пример показывает, почему не надо браться за древние технологии.

    WH>Но и у ЯВУ есть свой придел сложности после которого в проект приходит жирная полярная лисичка.

    WH>Поднять предел сложности проекта можно только еще сильнее повысив уровень инструмента.

    Теоретически это так. Подавляющему большинству проектов до этого порога как до небес. Понижать стоимость можно и другими способами, а ты их отказываешься даже рассматривать. Например самый простой способ — купить недостающие компоненты. Еще способ — нанять специалиста, который закроет критичную проблему. Еще способ — вообще отказаться от самостоятельной разработки и купить готовый софт.
    С тз бизнеса нет разницы, главное что профит есть.

    I>>Это снова теория заговора. С т.з. бизнеса наилучшие работники это

    I>>1. понимающие специфику бизнеса
    I>>2. направленые на результат
    I>>3. ответственные,дисциплинированые, предсказуемые
    WH>Не могущие написать FizzBuzz но упорно идущие к цели...

    Это уже не важно. Есть результат — есть профит.

    I>>Для написания фремворка не нужна глубокая формализация.

    WH>Ты не поверишь. Для ДСЛ тоже.

    Не поверю. Для фремворка можно вообще для начала ничего не формализовывать а просто кидать любой код который удовляетворяет требованиям. То есть берем любую более менее подходящую вычислительную модель и кидаем код который закрывает требования.
    Фремворк появится позжде, после нескольких циклов рефакторинга, если это понадобится.

    WH>>>В случае с ДСЛ нам нужно решить только первую.

    I>>Прграммисты годами тренируются кодить. Соотвесвенно формализация проблемы закончится ровно с записью решения в виде кода. Самое главное преимущество — фремворк не надо выпиливать заранее. Можно наговнокодить а через два года как появится потребность, отрефакторить, покрыть тестами и сделать фремфорк.
    WH>Так с ДСЛ все тоже самое.

    Покажи пример, только не поделки на вольную тему, а решение бизнес-задачи.

    WH>И его предка, из которого я его итерациями переделал.

    WH>https://github.com/rsdn/nemerle/tree/4855110cb34aa16ea6c5f481ee479bfe6513b706/snippets/peg-parser

    А где тот бизнес который делал приёмку ?

    I>>Кроме того, для ДСЛ нужно заранее думать про оптимизации и все нюансы использования.

    WH>Не нужно.
    WH>Это все допиливается по ходу дела.

    Где тот бизнес который делал приёмку ?

    WH>Особенно оптимизации.

    WH>Которые возможно вообще делать не придется. Если и так производительности хватает.

    Да ёе в общем случае никогда не хватает.

    WH>Типа с ДСЛ это не так.

    WH>Я же говорю, ты испорчен драконом.
    WH>Все то, что ты говоришь можно и ДСЛем. Причем намного проще и быстрее.

    где тот бизнес который делал приёмку ?

    I>>А где ж ты их наберёшь ? Думаешь если абитуриенты не умеют дроби складывать, то став преподавателями, они автоматом получат божественный интеллект ?

    WH>Я уже сто раз повторил. Выгонять не первой же сессии. Или еще лучше на вступительных экзаменах.

    То есть, пока их никто не выгонит, твоя теория остаётся теорией ?
    Re[29]: Языки общего назначения не имеют смысла!
    От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
    Дата: 26.04.12 08:28
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>Код генерируется по принципу, что вижу, то пою. Без трансформаций. Ручных или машинных.

    WH>Самое сложное, что тут происходит это превращение литералов в ДКА.

    Попробуй изыскать минимальный набор знаний-умений которые необходимы ЦА для использования твоей пульки ну и проверить это дело. Узнаешь много нового.
    Re[30]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 26.04.12 09:44
    Оценка: -1
    Здравствуйте, vdimas, Вы писали:

    V>БНФ задает ВЕСЬ класс контекстно свободных грамматик, который самый важный на сегодня.

    То-то чуть менее чем все языки КЗ.
    А для некоторых типа С++ даже нельзя построить адекватное КС надмножество.

    V>В любом случае нужна нотация, нейтральная к способу разбора.

    Зачем?

    V>Дык, никто не спорит. Все пока больше спрашивают. Очевидно же, что ПЕГ задает лишь некий подкласс грамматик и навскидку можно насочинять полно мест, где будет хромать (твой же пример с if/else).

    Чего?

    V>В общем, есть сомнения, бо реализовал порядка пяти разных "взрослых" парсеров в разное время и есть вопросы, ответы на которые никогда еще не видел. Ты ведь так и не ответил на вопрос про скобки С++.

    Какие скобки? Ты про a < b > c; ?
    Так его никакой БНФный парсер не разберет.
    А вот разбирающие грамматики можно подкрутить так чтобы разбирали.

    V>>>Да, пример был жесть.

    WH>>Он просто показал, что БНФ может задать неоднозначную грамматику.
    WH>>Только и всего.
    WH>>А твой гон про то, что неоднозначная КС грамматика не является КС грамматикой, просто противоречит всем определениям.
    V>Ёпс... Да это же классика:
    Какая еще классика?
    Как то что написал относится к этому утверждению?

    Это так, только если контекстно-свободная грамматика является неоднозначной. Т.е. если она не является на самом деле контекстно-свободной и мы располагаем лишь подмножеством контекстно-свободных правил из полной системы правил грамматики.


    V>Т.е. мне вообще трудно подбирать слова для обсуждения того, что на мой взгляд обсуждения не требует. Ну не может язык содержать неоднозначности. Точка. КС-грамматика может, ес-но.

    И зачем использовать для описания однозначных языков инструменты, которые могут описывать неоднозначности?
    Это же не имеет смысла.

    V>Более того, мне однажды пришлось писать парсер, где мне НУЖНА была неоднозначность по-условию.

    Зачем?

    V>И ты дважды проигнорировал напоминание про процедуру приведения грамматики, на этапе которой отсекаются мертвые ветки и можно найти неоднозначности.

    Вот только разбирающим грамматикам это не нужно.
    Они как есть работают.

    V>Вот ПЕГ ты особо не преобразуешь (кроме тривиальных прямых подстановок заведомо промежуточных нетерминалов).

    Еще раз. Разбирающим грамматикам преобразования не нужны.
    Они создаются так, чтобы работать как есть.

    WH>>А те генераторы, что жрут любую КС грамматику тормоза.

    V>ПЕГ жрет не любую.
    ПЕГ чтоб ты знал, вообще в иерархию Хомского не вписывается.
    Ибо он с одной стороны жрет не все КС. С другой стороны жрет некоторые КЗ. Чистый ПЕГ. Без расширений.

    V>Напротив, TDOP, насколько я помню — это простой способ парсить арифметические выражения и плохо подходит под произвольный синтаксис. Т.е. DSL в рамках TDOP будет заведомо обладать ограничениями.

    Вот только я довел его до такого состояния, что он прекрасно разбирает любые языки программирования.

    WH>>Они однозначны по построению. Ты просто не сможешь задать неоднозначную разбирающую грамматику.

    WH>>И работают как есть без всяких факторизаций.
    V>Ты всерьез считаешь, что никто тебя до сих пор не услышал?
    Да. Ибо ты упорно продолжаешь твердить про всякие преобразования.

    V>Нет, их игнорируют потому, что они задают обратный процесс написания языка: сначала его программирование, а потом что получилось — то и спецификация!

    V>Но читабельность человеком и читабельность программой — это две большие разницы. Определенно разрыв шаблона еще в том, что при разработке языка предлагается отталкиваться не от потребительских его кач-в, а от легкости написания его парсера... Не боишься, что разработанная тобой DSL потеряет значительную долю смысла, заложенную в сам факт ее существования? Чтобы заставить потом остальных программистов юзать DSL вместо милого их сердцу ЯВУ, синтаксис DSL должен быть ух и ах. Иначе усилия пропадут даром. Тут уже правильно говорили, что сама разработка DSL — сложная задача. Парсер — это уже так... В крайнем случае берется один из автоматических построителей — и копать отсюда и до обеда, в пару вечеров уложиться с первым работающим макетом парсера вполне можно...
    Бреееед!
    Мой построитель парсеров намного проще, гибче и мощнее всех БНФных поделок.
    Им можно легко разобрать то на чем БНФные поделки сдуются. Ибо он уже умеет КЗ. А скоро я туда еще возможностей для КЗ добавлю. Так что он С++ будет на раз разбирать.
    Так что я могу задать такой синтаксис, какой захочу.
    И описать его сразу.
    Без преобразований.
    И получить равно такой АСТ какой нужно.

    WH>>То ли дело БНФ. Тут тебе и факторизации. И привидения. И построение разбирающих алгоритмов на основе порождающих правил. И куча тому подобного бреда.

    V>Автоматизируется.
    Что автоматизируется? И какой АСТ он после этого сгенерирует?

    V>Кстати, я тут одну DSL постепенно пилю для своего хобби... надо попробовать испытать на вашей схеме... Но там явное КЗ-нарисовывается, иначе синтаксис придется резко урезать, а не хочется. Я же не могу, при всем своем уважении к себе споткнуться об парсер, правда? Тут как бы об саму DSL не споткнуться, а парсер — дело десятое или даже сотое.

    Пример в студию.
    Да и как ты собрался разбирать КЗ БНФом? Он же строго КС.

    WH>>Самое сложное, что тут происходит это превращение литералов в ДКА.

    V>Это как раз не самое сложное. Это я еще в дипломной работе делал черти сколько лет назад...
    О чем я и говорю.
    Разбирающие грамматики просты как пробка.
    Диссеры на них не защитить.

    V>Самое сложное в таком преобразовании — это отделить промежуточные нетерминалы от нецелевых и не потерять целевые при построении ДКА.

    А нету у меня этого преобразования. Ибо не нужно.
    Я просто дал пользователю возможность самому задать целевые терминалы.
    И все.
    Это решило сразу массу проблем. Включая адекватные сообщения об ошибках.

    V>Посмотрел. С явными приоритетами чуть проще запись. Но дык, приоритеты операций в БНФ элегантно расписываются через промежуточные нетерминалы... Кто мешает генерить одно из другого?

    Элегантно?

    Я бьюсь в истерике.
    А если нужно заточить грамматику под определенный построитель парсеров то там такая элегантность начинается...
    А уж получить из этой элегантности адекватный АСТ и сообщения об ошибках...

    А если учесть, то, что у меня операторы прямо во время разбора текста добавляться могут...

    WH>>Она понимает левую рекурсию, приоритеты и ассоциативность из коробки.

    WH>>Она поддерживает n-арные операторы. ChoiceTokenRule и SequenceTokenRule.
    WH>>Она поддерживает изменение грамматики во время разбора. Например, встретили "using syntax Xml;". Получили поддержку ХМЛ внутри C#. Область видимости закончилась синтаксис ХМЛ отключился.
    V>Не увидел как для C++ отличить умножение от символа указателя '*'.
    Сразу после того как ты покажешь как с этим справится БНФная поделка. Хоть GLR. Хоть Ерли. Не важно. Без расширений, заглядывающих в таблицу символов. Ибо таблица символов сразу делает парсер КЗ.

    И не соскакивай с вопроса. Покажи мне БНФную поделку, которая во время парсинга умеет грамматику менять.
    Не до начала разбора, а именно во время разбора загрузить ДЛЛ и получить оттуда новые правила.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[30]: Языки общего назначения не имеют смысла!
    От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
    Дата: 26.04.12 10:29
    Оценка: :)
    Здравствуйте, vdimas, Вы писали:

    V>Ты всерьез считаешь, что никто тебя до сих пор не услышал? На самом деле пара примеров реальных DSL для реальной работы, с полным исходным кодом всего того, что потребовалось написать "сверху" имеющегося фреймворка, рассказало бы о всех плюсах и минусах лучше любого оратора на форуме.


    Лет через пять может и покажут, а до того будет ной и плак : "Их нужно просто выкидывать из профессии." @ Wolfhound.
    Re[32]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 26.04.12 10:34
    Оценка:
    Здравствуйте, Ikemefula, Вы писали:

    I>Твои рассуждения не интересны по той причине, что ты через пост обвиняешь всех в тупости.

    Не всех. А тех кто FizzBuzz осилить не может. Если ты себя причисляешь к ним то извини.

    I>Любой. Ты потратил скажем десять лет и выдал все понимание одной-двумя строчками текста на русском языке. Любой кто умеет читать по русски внезапно становится способным создавать ДСЛ.

    Конечно не в пару строк. Но в несколько страниц уместить можно.
    И конечно не любой, а тот, кто способен писать программы.

    I>Туда много кто заходит, например и я Люди про которых я говорю интересуются именно этим направлением и работают возможно не над немерле, а над своими проектами, где все это применяют. Вот потому и возможно распространение опыта.

    На моей памяти таких было пара человек.
    Остальные темой интересуются исключительно с прикладной точки зрения.
    Хотя конечно то, что они слушают, то, что им говорят и это дает им возможность понять, то что им говорят.
    Ты же веришь что создание ДСЛ это что-то сложное.
    И эта вера запрещает тебе слушать то, что тебе говорят.

    WH>>Ох. Сколько еще раз повторить, что то, что написано в драконе не пригодно для практического применения?

    I>Ты мне напоминаешь студентов-двоечников, которые повторяют, что знать матан не обязательно, ибо надо всего то деньги считать уметь.
    Ох. Жертва дракона.

    WH>>Их методы заставляют делать в десятки, раз больше чем нужно и при этом даю посредственный результат.

    I>Да ладно, хорош гнать то. Давай проверим. Напиши компилятор модула за 1 час с нуля. Студенты по вирту делают это где то за две недели.
    Когда доделаю инструменты, думаю, за день справлюсь.
    Причем будет и ИДЕ сравнимая с решарпером. И отладка. И оптимизации.

    Студенты же за две недели осиливают компилятор без оптимизаций и с хреновыми сообщениями об ошибках.
    Про ИДЕ и отладку можно даже не вспоминать.

    I>Я как минимум представляю какой минимальный набор знаний и умений необходим для того, что бы родить простецкий ДСЛ. И этот набор много больше того, который требуется для решения большинства бизнес-задач.

    Не представляешь. Ты опираешься на дракона. А там все сложнее, чем нужно.

    WH>>И именно это ты и вынес. И пытаешься мне это втирать. Но я знаю, что это не так.

    I>С твоей верой я не собираюсь спорить
    У меня знания. У тебя вера.

    I>>>Если все мерить колмгоровской сложностью, то да, парадокс не разрешим

    WH>>Ох. В драконе когнитивная сложность тоже зашкаливает. Попробуй, объясни человеку что такое конфликт сдвиг/свертка.
    I>Очевидно, с нуля это в принципе невозможно.
    А у меня всего этого нет. И как следствие объяснять не придется.

    WH>>При этом разбирающие грамматики можно объяснить за пять минут на пальцах.

    I>Кому объяснить, тебе, мне, или тому, кто FizzBuzz не может родить на собеседовании ?
    Тому, кто не может FizzBuzz вообще ничего объяснить нельзя.
    Никогда.
    Он даже на жабке писать не сможет.

    WH>>Ибо они просто физически не в состоянии это делать.

    I>Твое мнение идет вразрез с наблюдаемой действительностью.
    Чего? Каждый раз. В 100% случаев. Когда брали такого человека. После его увольнения переписывали весь его код. Кода становилось в десятки, раз меньше и он начинал работать намного быстрее и без ошибок.
    Вот это наблюдаемая реальность.

    WH>>Способность к программированию она как музыкальный слух. Если она есть ее можно развить. Если ее нет, то хоть ты что делай. Человек программы писать не

    I>сможет.
    Не подтверждается практикой.
    Они конечно могут написать кучу операторов. Только эта куча будет тормозить и глючить, а не работать.

    I>>>C# уже лет 5-6 как не новость для студентов. Где то 2й или 3й курс от силы.

    WH>>Ну, так и зачем нужны Виртовские поделки?
    I>Я уже внятно ответил. найди тот ответ и спрашивай что в ём неясно.
    Понятно. Не знаешь.

    WH>>Их нужно просто выкидывать из профессии. Прямо в институте.

    I>Если их выкинуть, тебе придется делать за них всю чОрную работу.
    Если их выкинуть и остальным дать нормальные инструменты, то черная работа исчезнет.

    WH>>А тем, кто может писать нужно дать инструменты, которые повысят их производительность.

    I>чОрную работу пока невозможно исключить, потому что нет инструментов для автоматизации всех и вся.
    Ее можно сгенерировать.
    Факт.

    I>Прототип это ровно ничего.

    I>Что бы получить выкладки вроде тех, про которые ты говоришь, нужно внедрить инструмент в реальный проект и выкатить несколько версий. потом считаешь издержки и говоришь — вот, всё классно.
    I>Если хочешь доказать, что твои инструменты уменьшают зависимость от ЧФ, снова ровно то же, только проект должен сменить несколько команд исполнитлей.
    I>Снова считаешь издержки и снова показываешь результат.
    Да-да-да. Я просто этих считателей с рыка выдавлю и все.

    I>Кроме того, в бизнесе тебя обязательно спросят про обратную совместимость. Смотри, не облажайся, как Немерле. Здесь тоже нужны выкладки

    Ты про что? Н2 это новый проект. К немерле отношения не имеет.
    А ломающие изменения есть даже у мелкософта.
    Пруфлинк.
    https://www.google.ru/?q=site:msdn.microsoft.com+breaking+changes#hl=ru&amp;newwindow=1&amp;output=search&amp;sclient=psy-ab&amp;q=site:msdn.microsoft.com+breaking+changes&amp;oq=&amp;aq=&amp;aqi=&amp;aql=&amp;gs_nf=&amp;gs_l=&amp;pbx=1&amp;bav=on.2,or.r_gc.r_pw.r_qf.,cf.osb&amp;fp=79961699fc8b503f&amp;biw=1110&amp;bih=629
    И это только документированные.

    WH>>Ты что этим доказать то хочешь?

    WH>>То, что есть идиоты, которые берут на работу тех, кто писать не может?
    WH>>Не надо. Я и так знаю, что они есть.
    I>Ты знаешь, но не понимаешь почему они там есть.
    В компаниях нацеленных на результат по глупости. И долго они там не задерживаются.
    А там где пилят бабло руководству на продукт пофиг. Им бы лишь бы подешевле "работников" нанять. Чтобы создать вид бурной деятельности.

    I>А между тем они решают задачи бизнеса. Это факт. И пока это не изменится, никто их не выбросит.

    Ни разу не видел чтобы такой человек что-то решил.

    I>Потому что разработка в машинных кодах на несколько порядков сложнее. То есть затраты на разработку вырастут на порядки.

    Так вот что я тебе скажу.
    На заре разработки, когда все было в машинных кодах.
    Соотношения были ровно теми же.
    Но от машинных кодов ушли.

    I>Правильно. Потому стоимость разработки вырастает на порядки. То есть, твой пример показывает, почему не надо браться за древние технологии.

    Так технологии, которые ты защищаешь и есть древние.
    Только ты этого еще не понял.

    I>Теоретически это так. Подавляющему большинству проектов до этого порога как до небес. Понижать стоимость можно и другими способами, а ты их отказываешься даже рассматривать.

    I>Например самый простой способ — купить недостающие компоненты.
    I>Еще способ — нанять специалиста, который закроет критичную проблему.
    I>Еще способ — вообще отказаться от самостоятельной разработки и купить готовый софт.
    I>С тз бизнеса нет разницы, главное что профит есть.
    Первый и третий это отказ от разработки. Но мы обсуждаем именно разработку.
    Что касается второго, так как он будет закрывать проблему? А если у проблемы придел сложности выше, чем способности человека, у которого только жабка в руках?

    WH>>Не могущие написать FizzBuzz но упорно идущие к цели...

    I>Это уже не важно. Есть результат — есть профит.
    Нет результата. Я ни разу не видел.
    Попил бабла не рассматриваем.

    I>Не поверю.

    И зря.

    I>Для фремворка можно вообще для начала ничего не формализовывать а просто кидать любой код который удовляетворяет требованиям. То есть берем любую более менее подходящую вычислительную модель и кидаем код который закрывает требования.

    I>Фремворк появится позжде, после нескольких циклов рефакторинга, если это понадобится.
    Так с ДСЛем тоже самое.
    Только проще.
    Ибо не нужно думать, как натянуть нашу вычислительную модель на язык.

    WH>>Так с ДСЛ все тоже самое.

    I>Покажи пример, только не поделки на вольную тему, а решение бизнес-задачи.
    Что значит бизнес-задачи?
    Они, вообще говоря, очень разные бывают.

    I>А где тот бизнес который делал приёмку ?

    У меня есть закрытые проекты, где бизнес делал приемку.
    Показать их я ессно не могу.
    И разработка там велась именно итерациями.
    Дальше что?
    Будешь утверждать, что я вру?

    WH>>Особенно оптимизации.

    WH>>Которые возможно вообще делать не придется. Если и так производительности хватает.
    I>Да ёе в общем случае никогда не хватает.
    В общем да. В конкретных обычно с большим запасом. Или все утыкается в ввод/вывод.

    WH>>Я уже сто раз повторил. Выгонять не первой же сессии. Или еще лучше на вступительных экзаменах.

    I>То есть, пока их никто не выгонит, твоя теория остаётся теорией ?
    Нет. Я просто с ними дел иметь не буду и все.
    Они не моя целевая аудитория.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[31]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 26.04.12 10:42
    Оценка:
    Здравствуйте, WolfHound, Вы писали:


    V>>БНФ задает ВЕСЬ класс контекстно свободных грамматик, который самый важный на сегодня.

    WH>То-то чуть менее чем все языки КЗ.
    WH>А для некоторых типа С++ даже нельзя построить адекватное КС надмножество.

    Как раз в С++ конфликты совсем детские и решаются еще до парсинга, на этапе лексера + таблицы символов. Без отдельного этапа пост-обработки после парсинга.


    V>>В любом случае нужна нотация, нейтральная к способу разбора.

    WH>Зачем?

    Хотя бы, чтобы иметь возможность переность грамматику без изменений от парсера к парсеру и сравнивать результаты.


    V>>Дык, никто не спорит. Все пока больше спрашивают. Очевидно же, что ПЕГ задает лишь некий подкласс грамматик и навскидку можно насочинять полно мест, где будет хромать (твой же пример с if/else).

    WH>Чего?

    Какой else к какому if относится.


    WH>Какие скобки? Ты про a < b > c; ?

    WH>Так его никакой БНФный парсер не разберет.
    WH>А вот разбирающие грамматики можно подкрутить так чтобы разбирали.

    Ну так я уже который раз спрашиваю... Именно, на уровне грамматики — никак. А на уровне конструкции парсера и спецификации языка всё решается более чем элементарно. Для С++ существенно то, что задается строгий порядок: сначала объявление типа и лишь потом его использование (в отличие от C#). Даже внутри классов: сначала надо объявить типы, потом их использовать, в отличие от мемберов (!!!). Это позволяет со 100% точностью отличить типы от не типов во время парсинга и правильно распознать угловые скобки, или другие символы, типа *, &, ^. Т.е. вот лексер во время разбора тебе выдает нетерминал "Идентификатор", а ты его ищешь в таблице типов и подменяешь нетерминалами "ИдентификаторТип" или "ИдентификаторЗначение". Т.е. вставляешь м/у лексером и парсером эдакий "КЗ-фильтр", но на уровне подмножества КС-грамматики языка, по которой работает парсер, ты уже имеешь совершенно бесконфликтную схему (по крайней мере относительно этих значков). Примитивщина же.

    Вот я и спрашивал, а у вас как? Если через нотификацию конфликта или через "оперативную" обработку специально-введенных нетерминалов-заместителей, то это скукотища, т.к. это известно еще со времен твоего ругаемого дракона и многократно хуже того элегантного трюка, который позволяют формальные правила языка С++.


    WH>Какая еще классика?

    WH>Как то что написал относится к этому утверждению?
    WH>

    WH>Это так, только если контекстно-свободная грамматика является неоднозначной. Т.е. если она не является на самом деле контекстно-свободной и мы располагаем лишь подмножеством контекстно-свободных правил из полной системы правил грамматики.


    Блин, столько возни вокруг банальности... Я написал это, т.к. вижу во всей ветке, что не различается в спорах, где полная грамматика языка, а где грамматика некоего парсера. Ключевое всегда то, что практически-полезный язык, который мы собираемся парсить, не может быть неоднозначным. Грамматику этого языка я называю "полной". Поэтому, чтобы спор не превратился в бессмысленный, надо всегда помнить, что целевой язык может быть однозначным или никаким. Но, в БНФ по-определению можно записать только КС-правила из этой полной грамматики. Об этом я и пытался напомнить без подробностей в многа букф.

    К тому же, без указания, какие нетерминалы являются целевыми, а какие промежуточные, невозможно было утверждать про неоднозначность в твоем примере. Считай, что я с так лихо обошелся с твоим примером, чтобы тоже напомнить кое-что из БНФ... потому как вы слишком буквально воспринимаете правила редукции. Не обязано каждое правило в БНФ соответствовать 1:1 конечному АСТ, это тоже принципиально и тоже часто упускается, создавая трудности на ровном месте. Ты же наверняка многократно приводил недетерминированный автомат лексера к детерминировану, так? И тебя же не смущало, что в исходной записи в БНФ (если перейти от регулярных выражений к БНФ) он был бы точно такой же неоднозначной грамматикой в общем случае? Просто промежуточные нетерминалы, которые ты должен был бы ввести в систему уравнений БНФ для возможности записи исходной грамматики, склеиваются затем в один, если существует преобразование НКА->ДКА, или выдается конфликт состояний, если для пребразования в ДКА надо склеить различимые нетерминалы. Именно это я и показал на твоем примере.

    ============
    На остальное потом.
    Re[28]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 26.04.12 10:55
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    VD>>Я правильно понял, что ты утверждаешь, что БНФ описывает парсер?


    V>БНФ описывает грамматику. Просто я распознал класс грамматики согласно ее определения.


    А грамматика это что? Что она описывает? Варианты ответа:
    1. Описывает правила порождения (генерации) строк языка.
    2. Правила разбора строк принадлежащих к языку.

    VD>>Приведенный ниже пример является корректным описанием с точки зрения БНФ?

    VD>>
    VD>>E = E + E;
    VD>>E = E * E;
    VD>>E = '1';
    VD>>


    V>Вполне


    ОК, раз описывает, то является ли данная грамматика однозначной?

    V>, если речь о нотации.


    Можно подробнее об "если"? О чем еще может идти речь?

    VD>>Если — да, то какой парсер он описывает? Если нет, то почему?


    V>При чем тут парсер?


    ОК, заменим слово "парсер" на более нейтральное "разбор строки принадлежащей языку". Так грамматика в формате BNF описывает то как можно разобрать строку принадлежащую языку? Иными словами, можно ли, в общем случае, имея BNF-грамматику построить по ней парсер (без дополнительной информации)?

    V>Парсер выполняется по какой-то технике,


    +1

    V>а БНФ заведомо нейтральна к любой технике.


    -1

    И ты это поймешь сам как только правильно ответишь на заданные мной выше вопросы.

    V> Это просто нотация КС-грамматик и ничего более.


    Нет не просто... ОК, я дам тебе подсказку. А то ты там еще долго будешь кругами ходить.

    Грамматики бывают порождающие и разбирающие.

    Теперь, внимание, вопрос! Какого типа грамматики описывает BNF?

    В ответе на этот вопрос кроется ответ на все остальные вопросы, а стало быть понимание того что так долго пытается донести до тебя Вольфхаунд.

    V> И задачи у парсеров могут быть разные. Если стоит задача дать любую удачную ветку разбора, то построить такой парсер по твоей грамматике не проблема.


    У парсера есть только одна задача — разобрать строку принадлежащую языку и выдать дерево разбора (в том или ином виде) описывающее распознанные конструкции.

    V>Если стоит задача написать парсер ЯП, то сам язык должен быть заведомо однозначным.


    Все ЯП заведомо однозначны. Иначе на них нельзя было бы писать программы. Так что должно быть однозначным, чтобы можно было разобрать код на ЯП?
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[33]: Языки общего назначения не имеют смысла!
    От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
    Дата: 26.04.12 11:22
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    I>>Твои рассуждения не интересны по той причине, что ты через пост обвиняешь всех в тупости.

    WH>Не всех. А тех кто FizzBuzz осилить не может. Если ты себя причисляешь к ним то извини.

    Какой минимальный уровень квалификации необходим для того, что бы сочинить и реализовать ДСЛ ?

    I>>Любой. Ты потратил скажем десять лет и выдал все понимание одной-двумя строчками текста на русском языке. Любой кто умеет читать по русски внезапно становится способным создавать ДСЛ.

    WH>Конечно не в пару строк. Но в несколько страниц уместить можно.
    WH>И конечно не любой, а тот, кто способен писать программы.

    Точнее — какой уровень квалификации нужен для этого ?

    Я утверждаю следующее — любой, кто не может осилить свой свобственный фреймворк с помощью которого можно решать задачи в декларативном виде не способен рожать ни ДСЛ, ни работать с грамматиками, компиляторами.

    Т.е. ориентировочный уровень для работы с ДСЛ это примерно лет 5 опыта в индустрии _после_ универа.

    WH>Остальные темой интересуются исключительно с прикладной точки зрения.


    Это совершенно не важно. Главное что они работу делают.

    WH>Хотя конечно то, что они слушают, то, что им говорят и это дает им возможность понять, то что им говорят.


    Главное в том, что они работают в конкретном направлении.

    WH>Ты же веришь что создание ДСЛ это что-то сложное.

    WH>И эта вера запрещает тебе слушать то, что тебе говорят.

    Порожняк мне не нужен. Мне нужны обоснование "простоты" о которой вы все говорите.

    I>>Да ладно, хорош гнать то. Давай проверим. Напиши компилятор модула за 1 час с нуля. Студенты по вирту делают это где то за две недели.

    WH>Когда доделаю инструменты, думаю, за день справлюсь.

    За день- не интересно. Нужно за час. Студенты 3го курса. Производительность у них почти что нулевая, да и работают по "сложному Вирту и драконщине".

    WH>Студенты же за две недели осиливают компилятор без оптимизаций и с хреновыми сообщениями об ошибках.

    WH>Про ИДЕ и отладку можно даже не вспоминать.

    Консольный компилер, без изысков.

    I>>Я как минимум представляю какой минимальный набор знаний и умений необходим для того, что бы родить простецкий ДСЛ. И этот набор много больше того, который требуется для решения большинства бизнес-задач.

    WH>Не представляешь. Ты опираешься на дракона. А там все сложнее, чем нужно.

    Покажи, как ты вычислил минимальный уровень подготовки

    WH>>>Ох. В драконе когнитивная сложность тоже зашкаливает. Попробуй, объясни человеку что такое конфликт сдвиг/свертка.

    I>>Очевидно, с нуля это в принципе невозможно.
    WH>А у меня всего этого нет. И как следствие объяснять не придется.

    У тебя тоже чтото есть. все понятия прокачиваются, а не копируются из головы в голову. Это что, так сложно понять ?

    I>>Кому объяснить, тебе, мне, или тому, кто FizzBuzz не может родить на собеседовании ?

    WH>Тому, кто не может FizzBuzz вообще ничего объяснить нельзя.

    А кому можно ? Где минимальный уровень ? Где взять специалистов с этим минимальным уровнем ?
    Я, кстати, задаю этот вопрос всем немерлистам уже года три кряду и ответа до сих пор нет.

    WH>Он даже на жабке писать не сможет.


    Может.

    WH>Чего? Каждый раз. В 100% случаев. Когда брали такого человека. После его увольнения переписывали весь его код. Кода становилось в десятки, раз меньше и он начинал работать намного быстрее и без ошибок.

    WH>Вот это наблюдаемая реальность.

    А откуда уверенность, что вся индустрия работает с такими задачами как у вас ?

    WH>>>Способность к программированию она как музыкальный слух. Если она есть ее можно развить. Если ее нет, то хоть ты что делай. Человек программы писать не

    I>>сможет.
    WH>Не подтверждается практикой.
    WH>Они конечно могут написать кучу операторов. Только эта куча будет тормозить и глючить, а не работать.

    На каких задачах ? На ваших, на моих или на тех что в большинстве контор софтверных ?

    I>>Если их выкинуть, тебе придется делать за них всю чОрную работу.

    WH>Если их выкинуть и остальным дать нормальные инструменты, то черная работа исчезнет.

    На примере AVK ты почему то застрял Там что, код сложный ? Всех умений — ооп на уровне 3-5 лет опыта + специфика бизнеса. Всё.

    I>>чОрную работу пока невозможно исключить, потому что нет инструментов для автоматизации всех и вся.

    WH>Ее можно сгенерировать.
    WH>Факт.

    Тогда у тебя должен быть ДСЛ для примера AVK.

    I>>Если хочешь доказать, что твои инструменты уменьшают зависимость от ЧФ, снова ровно то же, только проект должен сменить несколько команд исполнитлей.

    I>>Снова считаешь издержки и снова показываешь результат.
    WH>Да-да-да. Я просто этих считателей с рыка выдавлю и все.

    Нет, ты будешь ныть и плакать "Их нужно просто выкидывать из профессии" еще лет пять или десять, а может и больше.

    I>>Кроме того, в бизнесе тебя обязательно спросят про обратную совместимость. Смотри, не облажайся, как Немерле. Здесь тоже нужны выкладки

    WH>Ты про что? Н2 это новый проект. К немерле отношения не имеет.

    Про первую версию Немерле.

    WH>А ломающие изменения есть даже у мелкософта.

    WH>Пруфлинк.
    WH>https://www.google.ru/?q=site:msdn.microsoft.com+breaking+changes#hl=ru&amp;newwindow=1&amp;output=search&amp;sclient=psy-ab&amp;q=site:msdn.microsoft.com+breaking+changes&amp;oq=&amp;aq=&amp;aqi=&amp;aql=&amp;gs_nf=&amp;gs_l=&amp;pbx=1&amp;bav=on.2,or.r_gc.r_pw.r_qf.,cf.osb&amp;fp=79961699fc8b503f&amp;biw=1110&amp;bih=629
    WH>И это только документированные.

    Забудь С++, это уже не мейнстрим. В мейнстриме у МС только один прокол это похороны J#.

    I>>Ты знаешь, но не понимаешь почему они там есть.

    WH>В компаниях нацеленных на результат по глупости. И долго они там не задерживаются.

    Работают годами и прокачиваются в специфике бизнеса что самое важное.

    WH>А там где пилят бабло руководству на продукт пофиг. Им бы лишь бы подешевле "работников" нанять. Чтобы создать вид бурной деятельности.


    Покажи свой продукт.

    I>>А между тем они решают задачи бизнеса. Это факт. И пока это не изменится, никто их не выбросит.

    WH>Ни разу не видел чтобы такой человек что-то решил.

    Вот я тебе это же и говорю — ты рассужаешь о том, чего не видел.

    WH>Так вот что я тебе скажу.

    WH>На заре разработки, когда все было в машинных кодах.
    WH>Соотношения были ровно теми же.

    Были. Задачи изменились. История лиспа тебя ничему не научила ?

    WH>Но от машинных кодов ушли.


    Ушли сначала в ассемблеры, потом в Си и причие фортраны . Лисп тот же не прижился — ОПАНЬКИ ЗАГОВОР !!!!!!!!!!!!

    I>>Правильно. Потому стоимость разработки вырастает на порядки. То есть, твой пример показывает, почему не надо браться за древние технологии.

    WH>Так технологии, которые ты защищаешь и есть древние.

    Я жду когда они будут опробованы на ком то другом, а не на мне. Я не люблю на себе испытывать поделки, которые после первой беты забивают на обратную совместимость.

    I>>С тз бизнеса нет разницы, главное что профит есть.

    WH>Первый и третий это отказ от разработки. Но мы обсуждаем именно разработку.

    Это тебе удобно сводить все к разработке. Именно бизнес определяет где будет разработка, а где нет.

    WH>Что касается второго, так как он будет закрывать проблему? А если у проблемы придел сложности выше, чем способности человека, у которого только жабка в руках?


    Ты похоже хочешь сказать простую вещи, что человек будет неспособен решить проблему в той области, в которой он является экспертом ?

    WH>>>Не могущие написать FizzBuzz но упорно идущие к цели...

    I>>Это уже не важно. Есть результат — есть профит.
    WH>Нет результата. Я ни разу не видел.

    Так это твои проблемы.

    WH>Попил бабла не рассматриваем.


    Первый раз слышу, что продукты являются попилом.

    WH>Только проще.

    WH>Ибо не нужно думать, как натянуть нашу вычислительную модель на язык.

    Ты что, весь код с нуля пишешь ?

    I>>Покажи пример, только не поделки на вольную тему, а решение бизнес-задачи.

    WH>Что значит бизнес-задачи?
    WH>Они, вообще говоря, очень разные бывают.

    Так в том то и дело. AVK дал хороший пример. Я могу еще пару таких подкинуть, это ж не сложно.

    I>>А где тот бизнес который делал приёмку ?

    WH>У меня есть закрытые проекты, где бизнес делал приемку.

    То есть не продукты ? До свидания.

    WH>Показать их я ессно не могу.

    WH>И разработка там велась именно итерациями.
    WH>Дальше что?
    WH>Будешь утверждать, что я вру?

    Неинтересно. Покажи продукт.

    I>>Да ёе в общем случае никогда не хватает.

    WH>В общем да. В конкретных обычно с большим запасом. Или все утыкается в ввод/вывод.

    А еще в ресурсы.

    I>>То есть, пока их никто не выгонит, твоя теория остаётся теорией ?

    WH>Нет. Я просто с ними дел иметь не буду и все.
    WH>Они не моя целевая аудитория.

    Ну и хорошо. Тогда в мейнстриме тебе делать вообще нечего да и в проектах где целая пачка технологий тоже.
    Re[32]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 26.04.12 11:38
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    V>Как раз в С++ конфликты совсем детские и решаются еще до парсинга, на этапе лексера + таблицы символов. Без отдельного этапа пост-обработки после парсинга.

    Только это уже КЗ.
    Просто по определению.

    V>Хотя бы, чтобы иметь возможность переность грамматику без изменений от парсера к парсеру и сравнивать результаты.

    1)Зачем?
    2)Попробуй, перенеси грамматику из АНТЛР в yacc.

    V>>>Дык, никто не спорит. Все пока больше спрашивают. Очевидно же, что ПЕГ задает лишь некий подкласс грамматик и навскидку можно насочинять полно мест, где будет хромать (твой же пример с if/else).

    WH>>Чего?
    V>Какой else к какому if относится.
    И где проблема?
    else всегда относится к ближайшему if . Другие правила невозможно даже сформулировать так чтобы их можно было однозначно разобрать.

    WH>>Какие скобки? Ты про a < b > c; ?

    WH>>Так его никакой БНФный парсер не разберет.
    WH>>А вот разбирающие грамматики можно подкрутить так чтобы разбирали.
    V>Ну так я уже который раз спрашиваю...
    Что спрашиваешь?

    V>Именно, на уровне грамматики — никак.

    На уровне БНФ никак. Но на БНФ свет клином не сошёлся.

    V>Блин, столько возни вокруг банальности... Я написал это, т.к. вижу во всей ветке, что не различается в спорах, где полная грамматика языка, а где грамматика некоего парсера. Ключевое всегда то, что практически-полезный язык, который мы собираемся парсить, не может быть неоднозначным. Грамматику этого языка я называю "полной". Поэтому, чтобы спор не превратился в бессмысленный, надо всегда помнить, что целевой язык может быть однозначным или никаким. Но, в БНФ по-определению можно записать только КС-правила из этой полной грамматики. Об этом я и пытался напомнить без подробностей в многа букф.

    Только ты сказал как обычно какойто бред из серии что некоторые КС грамматики восве не КС.

    V>К тому же, без указания, какие нетерминалы являются целевыми, а какие промежуточные, невозможно было утверждать про неоднозначность в твоем примере.

    Что характерно моей грамматике промежуточные нетерминалы не нужны.

    V>Считай, что я с так лихо обошелся с твоим примером, чтобы тоже напомнить кое-что из БНФ... потому как вы слишком буквально воспринимаете правила редукции. Не обязано каждое правило в БНФ соответствовать 1:1 конечному АСТ, это тоже принципиально и тоже часто упускается, создавая трудности на ровном месте.

    Ага. Трудности на ровном месте.
    И все ради чего?
    Ради БНФ?

    V>Ты же наверняка многократно приводил недетерминированный автомат лексера к детерминировану, так? И тебя же не смущало, что в исходной записи в БНФ (если перейти от регулярных выражений к БНФ) он был бы точно такой же неоднозначной грамматикой в общем случае? Просто промежуточные нетерминалы, которые ты должен был бы ввести в систему уравнений БНФ для возможности записи исходной грамматики, склеиваются затем в один, если существует преобразование НКА->ДКА, или выдается конфликт состояний, если для пребразования в ДКА надо склеить различимые нетерминалы. Именно это я и показал на твоем примере.

    Меня это не смущает по тому, что мне не нужно ничего различать.
    Токены атомарны.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[34]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 26.04.12 12:07
    Оценка: -1
    Здравствуйте, Ikemefula, Вы писали:

    WH>>Не всех. А тех кто FizzBuzz осилить не может. Если ты себя причисляешь к ним то извини.

    I>Какой минимальный уровень квалификации необходим для того, что бы сочинить и реализовать ДСЛ ?
    Если человек в состоянии написать библиотеку этого достаточно.
    Остальному можно научить за пару дней максимум.

    I>Я утверждаю следующее — любой, кто не может осилить свой свобственный фреймворк с помощью которого можно решать задачи в декларативном виде не способен рожать ни ДСЛ, ни работать с грамматиками, компиляторами.

    А я утверждаю, что ДСЛи намного проще.
    Ибо не нужно натягивать модель ДСЛ на модель языка.

    WH>>Остальные темой интересуются исключительно с прикладной точки зрения.

    I>Это совершенно не важно. Главное что они работу делают.
    Контекст беседы вспомни.

    WH>>Хотя конечно то, что они слушают, то, что им говорят и это дает им возможность понять, то что им говорят.

    I>Главное в том, что они работают в конкретном направлении.
    В каком? Они не создают инструменты для создания ДСЛ.
    Они создают ДСЛ.

    I>Порожняк мне не нужен. Мне нужны обоснование "простоты" о которой вы все говорите.

    Я тебе уже несколько раз сказал.
    Но ты не слушаешь.

    I>>>Да ладно, хорош гнать то. Давай проверим. Напиши компилятор модула за 1 час с нуля. Студенты по вирту делают это где то за две недели.

    WH>>Когда доделаю инструменты, думаю, за день справлюсь.
    I>За день- не интересно. Нужно за час. Студенты 3го курса. Производительность у них почти что нулевая, да и работают по "сложному Вирту и драконщине".
    Какая классная резьба по цитате.
    Так держать. Может быть, даже сможешь убедить себя.

    WH>>Студенты же за две недели осиливают компилятор без оптимизаций и с хреновыми сообщениями об ошибках.

    WH>>Про ИДЕ и отладку можно даже не вспоминать.
    I>Консольный компилер, без изысков.
    А я что написал?

    WH>>Тому, кто не может FizzBuzz вообще ничего объяснить нельзя.

    I>А кому можно ? Где минимальный уровень ? Где взять специалистов с этим минимальным уровнем ?
    FizzBuzz это минимальный уровень после, которого можно пытаться человека учить.

    I> Я, кстати, задаю этот вопрос всем немерлистам уже года три кряду и ответа до сих пор нет.

    Ты его постоянно игнорируешь.
    На немерле может писать любой кто осилил C#.

    WH>>Он даже на жабке писать не сможет.

    I>Может.
    Не может. Проверено.

    I>А откуда уверенность, что вся индустрия работает с такими задачами как у вас ?

    У меня уверенность в том что абсолютно любая бизнеслогика минимум на порядок сложнее чем FizzBuzz.

    I>На каких задачах ? На ваших, на моих или на тех что в большинстве контор софтверных ?

    На любых.

    I>На примере AVK ты почему то застрял Там что, код сложный ? Всех умений — ооп на уровне 3-5 лет опыта + специфика бизнеса. Всё.

    AVK ничего не сказал.
    Все попытки прояснить ситуацию закончились отбрёхами в стиле: Это не важно. То не нужно.
    Нельзя проектировать, не зная задачи.
    AVK и сам не сможет по тому куску восстановить архитектуру.
    Он все понимает только по тому, что все спроектировал.

    I>Тогда у тебя должен быть ДСЛ для примера AVK.

    После того как AVK удосужится нормально ответить на вопросы.

    I>>>Кроме того, в бизнесе тебя обязательно спросят про обратную совместимость. Смотри, не облажайся, как Немерле. Здесь тоже нужны выкладки

    WH>>Ты про что? Н2 это новый проект. К немерле отношения не имеет.
    I>Про первую версию Немерле.
    А что с ней?

    I>Забудь С++, это уже не мейнстрим. В мейнстриме у МС только один прокол это похороны J#.

    Причем тут С++?
    Там 10 тысяч ссылок.
    Но можно и вот так.
    https://www.google.ru/?q=site:msdn.microsoft.com+breaking+changes#hl=ru&amp;newwindow=1&amp;sclient=psy-ab&amp;q=site:msdn.microsoft.com+breaking+changes+C%23&amp;oq=site:msdn.microsoft.com+breaking+changes+C%23&amp;aq=f&amp;aqi=&amp;aql=&amp;gs_nf=1&amp;gs_l=serp.3...2208.3757.1.4060.4.4.0.0.0.1.214.700.0j3j1.4.0.kkY47QoiF0M&amp;pbx=1&amp;bav=on.2,or.r_gc.r_pw.r_qf.,cf.osb&amp;fp=79961699fc8b503f&amp;biw=1110&amp;bih=629
    Ты полистай выдачу.

    I>>>А между тем они решают задачи бизнеса. Это факт. И пока это не изменится, никто их не выбросит.

    WH>>Ни разу не видел чтобы такой человек что-то решил.
    I>Вот я тебе это же и говорю — ты рассужаешь о том, чего не видел.
    Я видел таких людей.
    Даже пытался с ними работать.

    I>Были. Задачи изменились. История лиспа тебя ничему не научила ?

    А чему она должна научить?
    Лисп, динамически типизированный язык без синтаксиса.
    Это само по себе огромные проблемы.

    I>Я жду когда они будут опробованы на ком то другом, а не на мне. Я не люблю на себе испытывать поделки, которые после первой беты забивают на обратную совместимость.

    Не пользуйся C#.

    I>Это тебе удобно сводить все к разработке. Именно бизнес определяет где будет разработка, а где нет.

    Но мы-то говорим про разработку.

    I>Ты похоже хочешь сказать простую вещи, что человек будет неспособен решить проблему в той области, в которой он является экспертом ?

    Я спрашиваю как он ее собирается решать?
    Ибо таки люди обычно приносят с собой кучу инструментов.
    Включая компиляторы своих язычков.

    WH>>Ибо не нужно думать, как натянуть нашу вычислительную модель на язык.

    I>Ты что, весь код с нуля пишешь ?
    Откуда такой вывод?

    I>Так в том то и дело. AVK дал хороший пример. Я могу еще пару таких подкинуть, это ж не сложно.

    Попробуй, подкинь.
    Только как AVK в молчанку с умным видом не играй.

    I>>>А где тот бизнес который делал приёмку ?

    WH>>У меня есть закрытые проекты, где бизнес делал приемку.
    I>То есть не продукты ? До свидания.
    Что значит не продукты?
    Еще, какие продукты. Они работают. И приносят деньги.
    А то, что это не вписывается в твою картину мира это твои проблемы.

    I>Ну и хорошо. Тогда в мейнстриме тебе делать вообще нечего да и в проектах где целая пачка технологий тоже.

    Откуда такой вывод?

    И еще более интересно, откуда вера в то, что человек не способный написать FizzBuzz может написать на порядок более сложную бизнеслогику?
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[35]: Языки общего назначения не имеют смысла!
    От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
    Дата: 26.04.12 14:23
    Оценка: -1 :)
    Здравствуйте, WolfHound, Вы писали:

    WH>>>Не всех. А тех кто FizzBuzz осилить не может. Если ты себя причисляешь к ним то извини.

    I>>Какой минимальный уровень квалификации необходим для того, что бы сочинить и реализовать ДСЛ ?
    WH>Если человек в состоянии написать библиотеку этого достаточно.
    WH>Остальному можно научить за пару дней максимум.

    Какую библиотеку? Библиотеки они разные. Даже на одну задачу можно найти под сотню самых разных библиотек.

    I>>Я утверждаю следующее — любой, кто не может осилить свой свобственный фреймворк с помощью которого можно решать задачи в декларативном виде не способен рожать ни ДСЛ, ни работать с грамматиками, компиляторами.

    WH>А я утверждаю, что ДСЛи намного проще.
    WH>Ибо не нужно натягивать модель ДСЛ на модель языка.

    WH>>>Остальные темой интересуются исключительно с прикладной точки зрения.

    I>>Это совершенно не важно. Главное что они работу делают.
    WH>Контекст беседы вспомни.

    Вспомнил. Я говорил о том, что знания можно передать только тому, кто занят примерно тем же что и ты. Представь, совершенно не обязательно писать компилятор немерле, что бы заниматься компиляторами и дсл.

    WH>>>Хотя конечно то, что они слушают, то, что им говорят и это дает им возможность понять, то что им говорят.

    I>>Главное в том, что они работают в конкретном направлении.
    WH>В каком? Они не создают инструменты для создания ДСЛ.
    WH>Они создают ДСЛ.

    Это абсолютно неважно.

    I>>Порожняк мне не нужен. Мне нужны обоснование "простоты" о которой вы все говорите.

    WH>Я тебе уже несколько раз сказал.
    WH>Но ты не слушаешь.

    Все что ты выдал, это какая то абстрактная "библиотека". Любой набор функций под конкретную задачу написаный с любым количеством ошибок в т.ч. ошибок проектирования и тд будет библиотекой.

    WH>>>Студенты же за две недели осиливают компилятор без оптимизаций и с хреновыми сообщениями об ошибках.

    WH>>>Про ИДЕ и отладку можно даже не вспоминать.
    I>>Консольный компилер, без изысков.
    WH>А я что написал?

    Я предлагаю тебе взять да оценить. Не надо придуриваться, сравнивать нужно сравнимое, а не табурет с бегемотом.

    I>>А кому можно ? Где минимальный уровень ? Где взять специалистов с этим минимальным уровнем ?

    WH>FizzBuzz это минимальный уровень после, которого можно пытаться человека учить.

    Спасибо, капитан. А что за абстрактная библиотека из фразы выше ?

    I>> Я, кстати, задаю этот вопрос всем немерлистам уже года три кряду и ответа до сих пор нет.

    WH>Ты его постоянно игнорируешь.
    WH>На немерле может писать любой кто осилил C#.

    На чистом немерле без ваших императивных костылей сильно вряд ли. А если взять макросы, то совершенно очевидно, что не любой. Тебе просто удобно игнорировать сообщения тех, кто попробовал и забил.

    I>>Может.

    WH>Не может. Проверено.

    Они даже библиотеки пишут

    I>>А откуда уверенность, что вся индустрия работает с такими задачами как у вас ?

    WH>У меня уверенность в том что абсолютно любая бизнеслогика минимум на порядок сложнее чем FizzBuzz.

    Правильно. Только сложность там специфике бизнеса и совершенно необязательно код должен быть таким же сложным.

    I>>На каких задачах ? На ваших, на моих или на тех что в большинстве контор софтверных ?

    WH>На любых.

    Чушь.

    I>>На примере AVK ты почему то застрял Там что, код сложный ? Всех умений — ооп на уровне 3-5 лет опыта + специфика бизнеса. Всё.

    WH>AVK ничего не сказал.

    Он дал все необходимые пояснения.

    WH>Все попытки прояснить ситуацию закончились отбрёхами в стиле: Это не важно. То не нужно.


    Да ладно, типа я не видел, ага.

    I>>Тогда у тебя должен быть ДСЛ для примера AVK.

    WH>После того как AVK удосужится нормально ответить на вопросы.

    Если ты не занимался инвентаризацией тебе все будет бесполезно.

    I>>Про первую версию Немерле.

    WH>А что с ней?

    Все хорошо, отдохни.

    WH>https://www.google.ru/?q=site:msdn.microsoft.com+breaking+changes#hl=ru&amp;newwindow=1&amp;sclient=psy-ab&amp;q=site:msdn.microsoft.com+breaking+changes+C%23&amp;oq=site:msdn.microsoft.com+breaking+changes+C%23&amp;aq=f&amp;aqi=&amp;aql=&amp;gs_nf=1&amp;gs_l=serp.3...2208.3757.1.4060.4.4.0.0.0.1.214.700.0j3j1.4.0.kkY47QoiF0M&amp;pbx=1&amp;bav=on.2,or.r_gc.r_pw.r_qf.,cf.osb&amp;fp=79961699fc8b503f&amp;biw=1110&amp;bih=629

    WH>Ты полистай выдачу.

    Это пурга. У нас ветка продуктов в сумме потянет мегов 150 кода который писался на 1.0 и перекочевал в 3.5, сейчас будет переводиться на 4.0. Там заюзаны практически все фичи языка. Не было ни одной проблемы.

    WH>>>Ни разу не видел чтобы такой человек что-то решил.

    I>>Вот я тебе это же и говорю — ты рассужаешь о том, чего не видел.
    WH>Я видел таких людей.
    WH>Даже пытался с ними работать.

    Мне кажется у тебя хронические проблемы в общении с людьми которые хоть в чем то знают меньше тебя

    I>>Были. Задачи изменились. История лиспа тебя ничему не научила ?

    WH>А чему она должна научить?
    WH>Лисп, динамически типизированный язык без синтаксиса.
    WH>Это само по себе огромные проблемы.

    Хорошая отмазка

    I>>Я жду когда они будут опробованы на ком то другом, а не на мне. Я не люблю на себе испытывать поделки, которые после первой беты забивают на обратную совместимость.

    WH>Не пользуйся C#.

    С C# все хорошо. А вот с немерле — не очень. Я забил когда в очередной версии перестал компилиться старый код и выбросил эту поделку на помойку.

    I>>Это тебе удобно сводить все к разработке. Именно бизнес определяет где будет разработка, а где нет.

    WH>Но мы-то говорим про разработку.

    О чем я и говорю — разработка отдельно от бизнеса никому не интересна. Кони в вакууме не нужны.

    I>>Ты похоже хочешь сказать простую вещи, что человек будет неспособен решить проблему в той области, в которой он является экспертом ?

    WH>Я спрашиваю как он ее собирается решать?
    WH>Ибо таки люди обычно приносят с собой кучу инструментов.
    WH>Включая компиляторы своих язычков.

    Необязательно компилятор. У него обязатеьлно будут наработки в любой форме. Мб даже готовый фремворк.

    WH>>>Ибо не нужно думать, как натянуть нашу вычислительную модель на язык.

    I>>Ты что, весь код с нуля пишешь ?
    WH>Откуда такой вывод?

    Да ты все акцентируешь внимание на этом натягивании. Я вот не могу этого понять, как ни кручу, а решение задачи занимает много больше времени чем запись решения. Может ты не теми задачами занимаешься ?

    I>>Так в том то и дело. AVK дал хороший пример. Я могу еще пару таких подкинуть, это ж не сложно.

    WH>Попробуй, подкинь.
    WH>Только как AVK в молчанку с умным видом не играй.

    Вот смотри. У юзеров есть тонны своих файлов в экселе которые он хочет засунуть в нашу прогу.
    Нужен дсл что бы натягивать одну структуру на другую. Каждый файлик содержит штук 10-15 закладок и там данные разных типов.
    Файлики он редактирует руками, что накладывает кучу ограничений. При импорте кое какие объекты нужно удалять, кое какие — создавать, в некоторых случаях обновление вообще нельзя выполнять. Например так — строчка в xls-файле это создание около десятка сущностей при выполнении ряда условий или же поиск-модификация этого десятка сущностей при выполнении ряда условий. Естественно, может быть все вместе — и создание и поиск и удаление и модификация и тд.
    Нужно логировать все ошибки в структуре, все проблемы и тд и тд.
    Вские констреинты накладываются на файлик, на создаваемый объект, на строчку, на операцию импорта, на закладку.
    Никаких глобальных уникальных идентификаторов нет, т.к. файлик редактируется юзером. Уникальность объекта по имени в пределах объека на уровень выше(на два, на три) и тд.
    нужно проверять, кучу вской всячины. например можно ли нулем перезатирать старое значение или нет и тд и тд.

    Нужен дсл для того, что бы написать сценарии импора покрыть все закладки в файле.


    I>>То есть не продукты ? До свидания.

    WH>Что значит не продукты?
    WH>Еще, какие продукты. Они работают. И приносят деньги.

    Если продукты, то почему не можешь дать ссылку ?

    I>>Ну и хорошо. Тогда в мейнстриме тебе делать вообще нечего да и в проектах где целая пачка технологий тоже.

    WH>Откуда такой вывод?

    В мейнстриме БЛ вроде той что показал AVK это норма. А пачка технологий означает использование готовых инструментов, а не создание собственных.

    WH>И еще более интересно, откуда вера в то, что человек не способный написать FizzBuzz может написать на порядок более сложную бизнеслогику?


    У тебя все или черное, или белое. Если человек может решить бизнес-задачу, то ему достаточно минимальных навыков в программировании что бы записать решение в лоб. Возможно он сделает в десять раз дольше чем я. Это ничего не значит. Мне переключиться на его задачу и решить её самому всё равно много дороже.

    Ты похоже меряешь способности к решению задач исключительно в понятиях программирования.
    Re[36]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 26.04.12 16:13
    Оценка:
    Здравствуйте, Ikemefula, Вы писали:

    WH>>>>Студенты же за две недели осиливают компилятор без оптимизаций и с хреновыми сообщениями об ошибках.

    WH>>>>Про ИДЕ и отладку можно даже не вспоминать.
    I>>>Консольный компилер, без изысков.
    WH>>А я что написал?
    I>Я предлагаю тебе взять да оценить. Не надо придуриваться, сравнивать нужно сравнимое, а не табурет с бегемотом.
    Что оценить?
    Ты, похоже, просто что-то пишешь даже не утруждая себя чтением.

    I>На чистом немерле без ваших императивных костылей сильно вряд ли. А если взять макросы, то совершенно очевидно, что не любой. Тебе просто удобно игнорировать сообщения тех, кто попробовал и забил.

    А мне совершенно очевидно обратное.

    WH>>У меня уверенность в том что абсолютно любая бизнеслогика минимум на порядок сложнее чем FizzBuzz.

    I>Правильно. Только сложность там специфике бизнеса и совершенно необязательно код должен быть таким же сложным.
    Каким сложным? Ты хоть знаешь что такое FizzBuzz?
    Вот условие:

    Напишите программу, которая выводит на экран числа от 1 до 100. При этом вместо чисел, кратных трем, программа должна выводить слово «Fizz», а вместо чисел, кратных пяти — слово «Buzz». Если число кратно и 3, и 5, то программа должна выводить слово «FizzBuzz»

    Если человек не может FizzBuzz то он вообще писать не может.
    Никак.

    I>>>На примере AVK ты почему то застрял Там что, код сложный ? Всех умений — ооп на уровне 3-5 лет опыта + специфика бизнеса. Всё.

    WH>>AVK ничего не сказал.
    I>Он дал все необходимые пояснения.
    Не дал. На чуть менее чем все вопросы он ответил "не важно".

    WH>>Все попытки прояснить ситуацию закончились отбрёхами в стиле: Это не важно. То не нужно.

    I>Да ладно, типа я не видел, ага.
    Похоже, что не видел.

    I>>>Про первую версию Немерле.

    WH>>А что с ней?
    I>Все хорошо, отдохни.
    Давай конкретно.

    WH>>https://www.google.ru/?q=site:msdn.microsoft.com+breaking+changes#hl=ru&amp;newwindow=1&amp;sclient=psy-ab&amp;q=site:msdn.microsoft.com+breaking+changes+C%23&amp;oq=site:msdn.microsoft.com+breaking+changes+C%23&amp;aq=f&amp;aqi=&amp;aql=&amp;gs_nf=1&amp;gs_l=serp.3...2208.3757.1.4060.4.4.0.0.0.1.214.700.0j3j1.4.0.kkY47QoiF0M&amp;pbx=1&amp;bav=on.2,or.r_gc.r_pw.r_qf.,cf.osb&amp;fp=79961699fc8b503f&amp;biw=1110&amp;bih=629

    WH>>Ты полистай выдачу.

    I>Это пурга.

    Это не пурга. Это факты.
    Причем признанные самим мелкософтом.
    Ты посмотри, по какому домену поиск происходит.
    msdn.microsoft.com

    I>У нас ветка продуктов в сумме потянет мегов 150 кода который писался на 1.0 и перекочевал в 3.5, сейчас будет переводиться на 4.0. Там заюзаны практически все фичи языка. Не было ни одной проблемы.

    А я помню перевод 10 метров с первого на второй. Было несколько проблем.
    Они конечно решились в течении дня но они были.

    I>Мне кажется у тебя хронические проблемы в общении с людьми которые хоть в чем то знают меньше тебя

    У меня с ними проблем нет. Те кто может писать программы очень быстро подтягиваются. Им нужно только один раз рассказать как.
    У меня есть проблемы с теми, кто не может FizzBuzz. Ибо сколько времени на них не трать, а всё равно получается говнокод.

    I>>>Были. Задачи изменились. История лиспа тебя ничему не научила ?

    WH>>А чему она должна научить?
    WH>>Лисп, динамически типизированный язык без синтаксиса.
    WH>>Это само по себе огромные проблемы.
    I>Хорошая отмазка
    Это не отмазка.
    Это причины по которым я его не использую.

    I>С C# все хорошо. А вот с немерле — не очень. Я забил когда в очередной версии перестал компилиться старый код и выбросил эту поделку на помойку.

    Не верю в то, что ты пытался его использовать.
    Я вот использую его весьма активно.
    Проблем с тем, что старый код не компилируется новой версией не помню.

    I>Да ты все акцентируешь внимание на этом натягивании. Я вот не могу этого понять, как ни кручу, а решение задачи занимает много больше времени чем запись решения. Может ты не теми задачами занимаешься ?

    Ты просто в решение задачи включаешь натягивание ее на целевой язык.
    А это сложно.
    Вот поэтому у тебя столько времени и уходит.

    I>Вот смотри.

    Я буду по ходу дела комментировать и задавать вопросы.

    I>У юзеров есть тонны своих файлов в экселе которые он хочет засунуть в нашу прогу.

    Те нужно написать парсер эксельных документов.
    И конвертер во внутренний формат вашей проги.
    Какой формат внутри вашей проги?
    Что за данные?

    I>Файлики он редактирует руками, что накладывает кучу ограничений.

    Ты это рассказываешь человеку который компиляторы пишет?

    I>При импорте кое какие объекты нужно удалять, кое какие — создавать, в некоторых случаях обновление вообще нельзя выполнять. Например так — строчка в xls-файле это создание около десятка сущностей при выполнении ряда условий или же поиск-модификация этого десятка сущностей при выполнении ряда условий. Естественно, может быть все вместе — и создание и поиск и удаление и модификация и тд.

    Примеры правил можно?

    I>Нужен дсл для того, что бы написать сценарии импора покрыть все закладки в файле.

    Всё ещё мало информации.

    I>Если продукты, то почему не можешь дать ссылку ?

    90% программистов не могут дать ссылку на то, что они делают.
    Это означает то, что они ничего не делают?
    Или то, что они не работают на бизнес?

    I>В мейнстриме БЛ вроде той что показал AVK это норма. А пачка технологий означает использование готовых инструментов, а не создание собственных.

    Для стандартных задачек будут стандартные ДСЛ.
    А самое веселое в том, что то же AVK как раз технологии и создает.

    I>Ты похоже меряешь способности к решению задач исключительно в понятиях программирования.

    Ох. Человек, который не может FizzBuzz писать не может совсем.
    Условие этого самого FizzBuzz я привел выше.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[32]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 26.04.12 19:26
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    V>Как раз в С++ конфликты совсем детские и решаются еще до парсинга, на этапе лексера + таблицы символов. Без отдельного этапа пост-обработки после парсинга.


    Опять ерунду говоришь. Конфликты там решаются на стадии парсинга. В таблицу символов нужно добавлять информацию о типах описанных выше. Иначе нельзя различить банального "x * y?". Если "x" тип — это определение переменной, если — нет, то это умножение.

    Короче, на стадии лексера там ничего разрешить нельзя.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[29]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 26.04.12 19:49
    Оценка: :)
    Здравствуйте, VladD2, Вы писали:

    VD>А грамматика это что? Что она описывает? Варианты ответа:

    VD>1. Описывает правила порождения (генерации) строк языка.
    VD>2. Правила разбора строк принадлежащих к языку.

    Вариант 3, правильный: система уравнений, которой должна удовлетворять цепочка символов. Считай, что при распознавании ты дополняешь это уравнение еще одной строкой — фактической входной цепочкой:
    S -> 'abcdef...'
    И ищешь все решения уравнения. А при генерации ты производишь тривиальную последовательную подстановку переменных, точно так же как в системе линейных уравнений, имеющей бесконечное кол-во решений, для выбора одного из решений ты задаешь произвольный базис части переменных и находишь остальные через подстановки.

    Тебя же не смущает, что обычные системы математических уравнений могут не иметь решения или иметь несколько решений?
    Неужели, когда мы говорим о некоей системе, например, линейных уравнений, имеющей бесконечное мн-во решений, то мы говорим, что система имеет бесконечное мн-во решений исключительно из-за своей математической нотации? Сказал бы ты на экзамене по вышке профессору такое... У него бы очки лопнули от зависти к такому полету мысли.

    VD>>>Приведенный ниже пример является корректным описанием с точки зрения БНФ?

    ...
    V>>Вполне
    VD>ОК, раз описывает, то является ли данная грамматика однозначной?

    Если это была БНФ, ес-но нет.

    V>>, если речь о нотации.

    VD>Можно подробнее об "если"? О чем еще может идти речь?

    Потому что это не классичесская БНФ нотация, т.е. это могла быть нотация чего угодно... но придираться не буду. Это я подстраховался на случай потенциальных каверзных вопросов, заведомо неинтересных по этой теме.


    VD>>>Если — да, то какой парсер он описывает? Если нет, то почему?

    V>>При чем тут парсер?
    VD>ОК, заменим слово "парсер" на более нейтральное "разбор строки принадлежащей языку".

    Проверка, скорее. Ведь любая система уравнений есть ни что иное, как система ограничений на возможные значения. Эдакая декларация правил существования решения.


    VD>Так грамматика в формате BNF описывает то как можно разобрать строку принадлежащую языку?


    Ес-но нет и не должна. Обобщенный разбор по БНФ-грамматике, независимо — нисходящий он или восходящий, потенциально рекурсивный и бесконечный, требует автомат с бесконечной магазинной памятью (Тюринга), поэтому ес-но БНФ не описывает как ее разобрать. Но так же как для разных классов математических уравнений есть методы решения (напр: линейные, гармонические, ДИ, квадратичные и т.д.), так же есть методы решения и для разных подклассов КС-грамматик, описываемых БНФ.


    VD>Иными словами, можно ли, в общем случае, имея BNF-грамматику построить по ней парсер (без дополнительной информации)?


    Можно, если удастся привести исходную систему уравнений (или она уже приведена) к некоему известному подклассу. Тогда берется известный способ решения для этого класса уравнений. Аналогично как в исходном математическом уравнении после преобразований могут сократиться некоторые члены и уравнение станет принадлежать, например, к линейным, легко решаемым одним из многих известных способов.


    V>>Парсер выполняется по какой-то технике,

    VD>+1

    V>>а БНФ заведомо нейтральна к любой технике.

    VD>-1

    VD>И ты это поймешь сам как только правильно ответишь на заданные мной выше вопросы.


    Правильно я ответил в первом предложении этого поста. А потом просто воду лью, для закрепления материала.
    По-прежнему настаиваю, что нейтральность — это естественное св-во математической нотации.


    V>> Это просто нотация КС-грамматик и ничего более.

    VD>Нет не просто... ОК, я дам тебе подсказку. А то ты там еще долго будешь кругами ходить.
    VD>Грамматики бывают порождающие и разбирающие.
    VD>Теперь, внимание, вопрос! Какого типа грамматики описывает BNF?
    VD>В ответе на этот вопрос кроется ответ на все остальные вопросы, а стало быть понимание того что так долго пытается донести до тебя Вольфхаунд.

    Тю, блин. Сравнивать аналитические и порождающие грамматики — это как сравнивать спецификацию и алгоритм. Конечно, БНФ используется как спецификация, поэтому она столь распространена. Но по спецификации (если она непротиворечива) можно составить алгоритм.

    А почему же непосредственный алгоритм не очень хорош в кач-ве спецификаций? Наверно из-за теоремы:

    Никакое нетривиальное свойство вычисляемых функций не является алгоритмически разрешимым.
    Смысл этой теоремы в том, что по описанию алгоритма, т.е. Машины Тьюринга, ничего нельзя узнать о свойствах функции, которую он вычисляет.

    Это то, что я уже десяток раз, если не больше, говорил о ПЕГ. Это как сравнивать функциональное и императивное программирование. Т.е. мне даже лень рассуждать, сравнивали на этом сайте уже многократно. БНФ — декларатив, ПЕГ — императив.

    V>> И задачи у парсеров могут быть разные. Если стоит задача дать любую удачную ветку разбора, то построить такой парсер по твоей грамматике не проблема.

    VD>У парсера есть только одна задача — разобрать строку принадлежащую языку и выдать дерево разбора (в том или ином виде) описывающее распознанные конструкции.

    Это если парсер ЯВУ. А то ведь вовсе не факт, например валидатор какой-нить может что-то валидировать по сильно упрощенной схеме, без знания полной семантики. Так оно и есть в EDI или утилитах проверки орфографии.


    V>>Если стоит задача написать парсер ЯП, то сам язык должен быть заведомо однозначным.

    VD>Все ЯП заведомо однозначны.

    Это от багов спецификации языка зависит.

    VD>Иначе на них нельзя было бы писать программы.


    Можно. Но получать на разных реализациях разное поведение. Что и наблюдается периодически.

    VD>Так что должно быть однозначным, чтобы можно было разобрать код на ЯП?


    Спецификация должна быть непротиворечивой. А с помощью БНФ можно описать лишь ничтожную часть этой спецификации — отдельные элементы синтаксиса. БНФ себя проявляет во всей красе именно как спецификация грамматики для человека из-за удобной декомпозиции своих определений. Это хорошо ложится на то, как человек разбирает материал — от общего к частному.
    Re[33]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 26.04.12 19:51
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    V>>Как раз в С++ конфликты совсем детские и решаются еще до парсинга, на этапе лексера + таблицы символов. Без отдельного этапа пост-обработки после парсинга.


    VD>Опять ерунду говоришь. Конфликты там решаются на стадии парсинга. В таблицу символов нужно добавлять информацию о типах описанных выше. Иначе нельзя различить банального "x * y?". Если "x" тип — это определение переменной, если — нет, то это умножение.


    VD>Короче, на стадии лексера там ничего разрешить нельзя.


    Ниже в том же посте я более подробно пояснил. Да, м/у лексером и парсером обратная связь через таблицу идентификаторов. Но конфликты упомянутых значков действительно решаются еще ПЕРЕД подачей нетерминалов на парсер. В парсере уже никаких конфликтов.
    Re[34]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 26.04.12 20:35
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    V>Ниже в том же посте я более подробно пояснил. Да, м/у лексером и парсером обратная связь через таблицу идентификаторов. Но конфликты упомянутых значков действительно решаются еще ПЕРЕД подачей нетерминалов на парсер. В парсере уже никаких конфликтов.


    Это не на стадии лексера, а на стадии парсинга все же. Другое дело, что они еще хачат лексер.

    Нам это делать ненадо. У нас тупо будут предикаты которые смогут использовать таблицу символов.

    Ну, лексера у нас отдельного не будет. Все правила носят свои лексеры с собой.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[30]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 26.04.12 21:51
    Оценка: :)
    Здравствуйте, vdimas, Вы писали:

    Поставил на сообщение закладку.
    Буду показывать людям, до чего дракон доводит.

    :полностью офигевший смайлик:
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[30]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 26.04.12 22:12
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    V>Здравствуйте, VladD2, Вы писали:


    VD>>А грамматика это что? Что она описывает? Варианты ответа:

    VD>>1. Описывает правила порождения (генерации) строк языка.
    VD>>2. Правила разбора строк принадлежащих к языку.

    V>Вариант 3, правильный: система уравнений, которой должна удовлетворять цепочка символов...


    Это очередной флуд которым ты пытаешься прикрыть несостоятельность твоей позиции.

    V>Считай, что при распознавании ты дополняешь это уравнение еще одной строкой — фактической входной цепочкой:

    V>S -> 'abcdef...'
    V>И ищешь все решения уравнения. А при генерации ты производишь тривиальную последовательную подстановку переменных, точно так же как в системе линейных уравнений, имеющей бесконечное кол-во решений, для выбора одного из решений ты задаешь произвольный базис части переменных и находишь остальные через подстановки.

    Ты свои фантазии для ненаучно-фантастических рассказов оставь.

    Я же не просто так тебе вопрос задал. Грамматики бывает порождающими и разбирающими. Разбирающие по определению однозначны.

    Вот БНФ — это формализм для описания порождающих грамматик. По этому с его помощью и можно с легкостью описать неоднозначную грамматику.

    V>Тебя же не смущает, что обычные системы математических уравнений могут не иметь решения или иметь несколько решений?


    Не смущает, так как я ими не пользуюсь.
    Не стоит любое обсуждение во флуд превращать.

    VD>>ОК, раз описывает, то является ли данная грамматика однозначной?


    V>Если это была БНФ, ес-но нет.


    Вот это ключевой момент! В БНФ нужно выполнить кучу приседаний чтобы превратить простую и понятную но неоднозначною грамматику в однозначную. При этом очень трудно понять однозначная ли получилась грамматика. А в итоге мы получаем еще и намного более сложную грамматику. Ее и читать, и развивать сложнее чем исходную.

    Мы же делаем проще. Мы делаем описание таким, чтобы неоднозначностей просто не было или были средства их декларативного устранения.

    V>Это я подстраховался на случай потенциальных каверзных вопросов, заведомо неинтересных по этой теме.


    Если бы ты меньше "страховался" разговаривать было бы проще .
    Мы тут не хотим тебя в дерьмо втоптать. А хотим объяснить свой подход. И почему он решает проблемы не разрешимые для "классического" подхода.

    VD>>>>Если — да, то какой парсер он описывает? Если нет, то почему?

    V>>>При чем тут парсер?
    VD>>ОК, заменим слово "парсер" на более нейтральное "разбор строки принадлежащей языку".

    V>Проверка, скорее. Ведь любая система уравнений есть ни что иное, как система ограничений на возможные значения. Эдакая декларация правил существования решения.


    Что "проверка"? И не надо тут матан приплетать.

    Я тебя подвожу к тому, что БНФ создан для описания порождающих грамматик. Они по определению неоднозначны.

    Но можно придумать грамматику которая будет разбирающей. Отличие от порождающей в том, что она описывает не просто язык, а то как можно разобрать строку на этом языке.

    Такие грамматики содержат больше информации делая грамматику однозначной.

    Есть правда еще одна проблема — соединение однозначных грамматик может дать неоднозначную. Но это скорее теоретическая проблема нежели практическая. На практике для людей достаточно выдать сообщение о неоднозначности в рантайме.

    VD>>Так грамматика в формате BNF описывает то как можно разобрать строку принадлежащую языку?


    V>Ес-но нет и не должна.


    Так зачем же их для описания парсеров тогда используют?

    V>Обобщенный разбор по БНФ-грамматике, независимо — нисходящий он или восходящий, потенциально рекурсивный и бесконечный, требует автомат с бесконечной магазинной памятью (Тюринга), поэтому ес-но БНФ не описывает как ее разобрать.


    Ну, да. Только БНФ вообще не касается разбора. БНФ — это чистая теория. Как и все теории не имеющий применений на практике в чистом виде. Но его ведь суют во все дыры! Вот в этом и проблема.

    V> Но так же как для разных классов математических уравнений есть методы решения (напр: линейные, гармонические, ДИ, квадратичные и т.д.), так же есть методы решения и для разных подклассов КС-грамматик, описываемых БНФ.


    БНФ не дает решений. Он дает проблемы.


    VD>>Иными словами, можно ли, в общем случае, имея BNF-грамматику построить по ней парсер (без дополнительной информации)?


    V>Можно,


    Нельзя! Я же не даром написал "в общем случае".

    V>если удастся привести исходную систему уравнений


    Ты достал со своими уравнениями. Они тут не в кассу.

    V>(или она уже приведена) к некоему известному подклассу. Тогда берется известный способ решения для этого класса уравнений.


    Это называется преобразовать грамматику и решить частный случай. Я же говорю про общий. Люди, описывая парсеры на БНФ, не могут понять что можно использовать, а что нет.

    Кроме того люди крайне хреново переписывают грамматики. При этом у них начинает рвать мозг.

    Для того чтобы сделать возможным написание грамматик неопытными (в этом) людьми, а не матерыми волками парсинга нужно устранить необходимость в любом переписывании. Если формальное описание позволяет грамматику, то по ней должен быть создан работающих парсер.

    У БНФ просто не хватает выразительных средств для этого.

    V> Аналогично как в исходном математическом уравнении


    Задолбал

    V>после преобразований могут сократиться некоторые члены и уравнение станет принадлежать, например, к линейным, легко решаемым одним из многих известных способов.


    Это из серии если бы калькулятор вместо того чтобы вычислить выражение предложил бы его преобразовать в некоторую форму для начала. Короче, неюзабельно.

    V>По-прежнему настаиваю, что нейтральность — это естественное св-во математической нотации.


    Ты можешь настаивать хоть полынь на вине — это ничего не изменит. Факт заключается в том, что математика не нужна простым смертным. Им нужны удобные средства разрабтки и понятные формализмы.

    Потом приводя аналогии не доказывая аналогичности ты просто тратишь свое время. Только дурак тебя будет слушать. А на доказательство ты потратишь оставшуюся жизнь.


    VD>>Грамматики бывают порождающие и разбирающие.

    VD>>Теперь, внимание, вопрос! Какого типа грамматики описывает BNF?
    VD>>В ответе на этот вопрос кроется ответ на все остальные вопросы, а стало быть понимание того что так долго пытается донести до тебя Вольфхаунд.

    V>Тю, блин. Сравнивать аналитические и порождающие грамматики — это как сравнивать спецификацию и алгоритм. Конечно, БНФ используется как спецификация, поэтому она столь распространена. Но по спецификации (если она непротиворечива) можно составить алгоритм.


    Нельзя, если в ней не хватает данных. А в БНФ не хватает. Кроме того на БНФ можно строить правильные спецификации, и не правильные. Правильные запутаны и сложно пишутся. Не правильные "понятны" но по ним ничего правильного не сделаешь.

    Спецификацией как раз является разбирающая грамматика. Оно и ее нужно дополнить контекстно-зависимой информацией.

    V>А почему же непосредственный алгоритм не очень хорош в кач-ве спецификаций?


    V>Наверно из-за теоремы:...


    Не. Все банальнее. Спецификация должна легко читаться. А в алгоритмах слишком много лишнего. Алгоритм парсера Н2 мудрен. А грамматика по которой он работает вполне себе читаема.

    V>Это то, что я уже десяток раз, если не больше, говорил о ПЕГ.


    Ты много стандартных заблуждений повторяешь. Был бы лучше, если бы ты пытался оспорить и переосмыслить догмы, а не повторял бы их.

    V>БНФ — декларатив, ПЕГ — императив.


    Бред, из которого следует, что императивное описание более удобно, компактно и понятно.

    Выразительные возможности ПЕГ и БНФ очень близки. И у обоих есть свои проблемы. Скажем операторые грамматики ни на том, ни на другом по человечески не описать. На то есть нотация с приоритетами или силой связывания. Она затыкает за пояс оба формализма. Потому мы ее и используем.

    V>>>Если стоит задача написать парсер ЯП, то сам язык должен быть заведомо однозначным.

    VD>>Все ЯП заведомо однозначны.

    V>Это от багов спецификации языка зависит.


    Я не помню, говорил ли я тебе, что единственная точная специфкация языка — это его компилятор.

    Компилятор то нельзя неоднозначным сделать. Ведь он то не может генерировать разные программы по одному коду в зависимости от фазы луны.

    VD>>Иначе на них нельзя было бы писать программы.


    V>Можно. Но получать на разных реализациях разное поведение. Что и наблюдается периодически.


    Нельзя. Разные реализации будут иметь разные спецификации, если их точно описывать.

    В общем, ты снова полез в бессмысленную философию. Рассматривать вопрос багов и глупости нет смысла. Мы же говорим о формальной системе реализации языков. А в ней спецификация и реализация — это одно и то же.

    VD>>Так что должно быть однозначным, чтобы можно было разобрать код на ЯП?


    V>Спецификация должна быть непротиворечивой. А с помощью БНФ можно описать лишь ничтожную часть этой спецификации — отдельные элементы синтаксиса.


    Вывод почти правильный. Только с помощью БНФ вообще не нужно что-то описывать. Нужен другой формализм.

    Вот в задачи N2 и входит создать такой формализм. Формализм мы уже практически придумал. Для парсинга вольфхаунд уже даже написал работающую (хотя и далекую от релиза) реализацию.

    V> БНФ себя проявляет во всей красе именно как спецификация грамматики для человека


    Вот это заблуждение. БНФ просто непригоден для описания формальных спецификаций. Про него просто нужно забыть. Это игрушка для ученых цель которых влепить в дисер красивые диаграммы.

    Для практического использования нужен другой формализм. ПЕГ более лучший формализм для практического использования, но и он не идеален. Совмещение ПЕГ-а и TDOP дает практически идеальное решение. Вот оно, доработанное напильником (очень сильно) и используется в N2.

    V>из-за удобной декомпозиции своих определений. Это хорошо ложится на то, как человек разбирает материал — от общего к частному.


    Не говори ерунды. Человеку не нужны ошибочные спецификации (а именно это он получает используя БНФ). Человеку нужны спецификации которые он может понять, и которые позволяют автоматически получить по ним работающее приложение. И это даже не парсер. Ведь человеку нужны: компилятор, документация, поддержка IDE и т.п.

    Вот все это и будет давать наше N2. Кстати, я буквально сегодня дополнил его описание
    Автор: VladD2
    Дата: 26.04.12
    новым материалом. Описание все еще не полное и незаконченное, но все же оценить что получится в итоге можно. Предлагаю тебе именно этим и заняться. С удовольствием послушаю взвешенное мнение и конструктивную критику.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[31]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 27.04.12 06:40
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>Поставил на сообщение закладку.

    WH>Буду показывать людям, до чего дракон доводит.

    WH>:полностью офигевший смайлик:


    Наздоровье!
    Re[35]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 27.04.12 07:22
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    V>>Ниже в том же посте я более подробно пояснил. Да, м/у лексером и парсером обратная связь через таблицу идентификаторов. Но конфликты упомянутых значков действительно решаются еще ПЕРЕД подачей нетерминалов на парсер. В парсере уже никаких конфликтов.

    VD>Это не на стадии лексера, а на стадии парсинга все же.

    Скорее фильтр м/у лексером и парсером, а к чему его отнести — это уже вопрос вкуса. Я отнес к лексеру лишь потому, что поток лексем — это именно то, что требуется от лексера. Т.е. автоматный блок, бьющий на токены, можно рассматривать как часть лексера. Ведь нам от лексера всегда нужен точный ТИП токена: число (целое/двробное), идентификатор, оператор языка и т.д. Ты решил отнести уточнение типа токена уже к стадии парсинга? Но это столь же с натяжкой, как и относить к лексеру, т.к. магазинный автомат парсера по КС тоже всем этим никак не занят — банально не умеет в рамках КС-грамматики. Описанные действия совершает внешний по отношению к этим двум автоматам механизм, использующий оба автомата лишь как часть своего полного алгоритма.

    VD>Другое дело, что они еще хачат лексер.


    Ты имеешь ввиду более эффективный ручной разбор комментариев? Это не принципиально ни разу. Я же говорю — рассматривай автоматные блоки как вспомогательные.


    VD>Нам это делать ненадо. У нас тупо будут предикаты которые смогут использовать таблицу символов.


    Ну т.е. помимо просто генерации двух автоматов — ДКА и магазинного, у вас будет некая инфраструктура, заточенная под специфику разбора грамматик ЯП? Замечательно! Это очень близко к классическому устройству компиляторов.


    VD>Ну, лексера у нас отдельного не будет. Все правила носят свои лексеры с собой.


    Ты хотел сказать, что отдельного языка описания правил для лексера не будет? Это не одно и то же. И этой идее уже очень много лет. У меня как раз диплом на эту тему был: из одного описания строить одновременно лексер и парсер. Это была вспомогательная утилита для комплекса разработки программ на ассемблере под различные микро-ЭВМ. Утилита нужна была, чтобы кодировать сами эти ассемблеры относительно быстро (парочку полноценных асмов с кое-какой макросистемой я в те года написал. Для 8051 пользовался только своим асмом затем в течении нескольких лет.)
    Re[31]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 27.04.12 07:42
    Оценка: :)
    Здравствуйте, VladD2, Вы писали:

    Во-первых, зря ты пытался отвечать на каждое предложение отдельно. Была высказана единое стройное мнение о том, что есть БНФ. Ты пытался назвать их фантазиями, но если это и фантазии, то уж никак не мои. Повторю, БНФ — это просто еще одна разновидность синтаксиса для КС-редукций. Нельзя от уравнений редукций требовать того, что ты требовал, как нельзя от математических уравнений требовать, чтобы они сами себя решали. Это просто декларация условия сущестования решения в обоих случаях. Пара этих фраз никакой не матан, это школьный уровень, когда ребятам объясняют, что же такое уравнение.

    V>>Это то, что я уже десяток раз, если не больше, говорил о ПЕГ.

    VD>Ты много стандартных заблуждений повторяешь. Был бы лучше, если бы ты пытался оспорить и переосмыслить догмы, а не повторял бы их.

    Во-вторых, приведенная теорема вовсе не заблуждение, а фундаментальная относительно машины Тьюринга и всего современного ПО, работающего по похожей модели. Именно с помощью этой теоремы функциональщики высмеивают императивщиков, и более ни с помощью какой другой. Просто размусоливают ее своими словами в меру собственной испорченности.


    V>>БНФ — декларатив, ПЕГ — императив.

    VD>Бред, из которого следует, что императивное описание более удобно, компактно и понятно.

    Не бред, а аксиома (относительно БНФ и ПЕГ). Зря ты так торопишься отвечать. Императив не обязан иметь бОльшее описание, чем декларатив, это зависит от заточенности языка императива или декларатива под конкретную задачу. Например, ПЕГ вносит упорядоченность в набор правил, в то время как системе уравнений до фени, в каком порядке перечисленны ее правила.


    VD>Выразительные возможности ПЕГ и БНФ очень близки. И у обоих есть свои проблемы. Скажем операторые грамматики ни на том, ни на другом по человечески не описать. На то есть нотация с приоритетами или силой связывания. Она затыкает за пояс оба формализма. Потому мы ее и используем.


    Да я не против. Единственно портив чего я высказывался, чтобы не сравнивали теплое с зеленым. А вы именно что пытаетесь. Вы разрабатываете язык для описания алгоритма разбирающих грамматик — ну отлично! Особенно если вы сумеете опять же отделить зерна от плевел, т.к. отделить язык описания алгоритма разбора от конкретной реализации "компилятора" этого языка и всей инфраструктуры вокруг. Банально чтобы иметь возможность сохранять будущие инвестиции потенциальной целевой аудитории.

    Но пытаться сравнивать аналитическую грамматику с порождающей в кач-ве рекламы этого языка — это ведь подставляться по полной, не находишь? Что о вас люди подумают? Чтобы сравнение было адекватным, надо сравнивать грамматики аналогичных классов.


    VD>Я не помню, говорил ли я тебе, что единственная точная специфкация языка — это его компилятор.


    Нет, лично мне не говорил, но все и так знают, что в случае Немерле это именно так. Это вовсе не страшно на исследовательской стадии. Но потом, увы, придется отделить язык от его конкретного воплощения. И для отделения нужны будут спецификации на каком-то общепонятном языке. Какие твои предложения относительно языка спецификаций?


    VD>Компилятор то нельзя неоднозначным сделать. Ведь он то не может генерировать разные программы по одному коду в зависимости от фазы луны.


    Это пять!
    Спасибо, поднял настроение.


    VD>>>Иначе на них нельзя было бы писать программы.

    V>>Можно. Но получать на разных реализациях разное поведение. Что и наблюдается периодически.

    VD>Нельзя. Разные реализации будут иметь разные спецификации, если их точно описывать.


    Вот это и повеселило в предыдущем абзаце. Программисты кодируют программы обычно по спецификациям, а не наоборот. Именно спецификации позволяют работать над кодом совместно. Другого способа совместной разработки просто нет.


    VD>В общем, ты снова полез в бессмысленную философию. Рассматривать вопрос багов и глупости нет смысла. Мы же говорим о формальной системе реализации языков. А в ней спецификация и реализация — это одно и то же.


    Ес-но не одно и то же. Второе должно стремиться к первому, но ты же настаиваешь, что первое выходит из второго. А это бывает только по результатам исследовательских этапов разработки и никогда более.


    VD>>>Так что должно быть однозначным, чтобы можно было разобрать код на ЯП?

    V>>Спецификация должна быть непротиворечивой. А с помощью БНФ можно описать лишь ничтожную часть этой спецификации — отдельные элементы синтаксиса.

    VD>Вывод почти правильный. Только с помощью БНФ вообще не нужно что-то описывать. Нужен другой формализм.


    Можно пример?
    ИМХО, отдельные элементы синтаксиса прекрасно в БНФ описываются, что вот мол объявление класса выглядит так, а выражение new — эдак. Заметь, связь м/у объявленным классом и аргументом new в синтаксисе КС-грамматики невыразима, зато прекрасно понимается человеком через конкретный идентификатор и область его видимости. Именно поэтому спецификация элементов синтаксиса в БНФ запросто может быть непротиворечива, что оперирует непротиворечивыми элементами языка. А уже как эта непротиворечивость достигается, дело десятое. Например, как описал тут
    Автор: vdimas
    Дата: 27.04.12
    и выше по ветке на пару сообщений.


    VD>Вот в задачи N2 и входит создать такой формализм. Формализм мы уже практически придумал. Для парсинга вольфхаунд уже даже написал работающую (хотя и далекую от релиза) реализацию.


    Прекрасно. Но сам этот формализм и язык к нему, боюсь, вам придется представить публике в виде БНФ.
    Этот болезненный, но необходимый акт и будет ответом на все ваши вопросы относительно роли БНФ в жизни обычного программиста. В том числе вашей.


    V>> БНФ себя проявляет во всей красе именно как спецификация грамматики для человека

    VD>Вот это заблуждение. БНФ просто непригоден для описания формальных спецификаций. Про него просто нужно забыть. Это игрушка для ученых цель которых влепить в дисер красивые диаграммы.

    Угу... давай дождемся того момента, когда вам надо будет выкатить свой формализм на публику. Потом вернемся сюда еще раз.


    VD>Для практического использования нужен другой формализм. ПЕГ более лучший формализм для практического использования, но и он не идеален. Совмещение ПЕГ-а и TDOP дает практически идеальное решение. Вот оно, доработанное напильником (очень сильно) и используется в N2.


    С помощью какого интсрумента единообразно описать всё множество таких языков, каждый из которых является описанием входных правил для своих собственных алгоримов? Ребят, вы же, к сожалению, не понимаете слова оппонента. Когда я говорил о нейтральности или о том, что вы пытаетесь использовать термины не по назначению или пытаетесь создавать сложности в обмене информациями с коллегами — вы даже не понимали, что именно вам говорят. Любое знание, любую информацию вам надо как-то выносить из своего круга в общественность, а для этого действа подойдут только всем понятные нотации и определения. Увы и ах. Даже если вы разработаете другую УНИВЕРСАЛЬНУЮ нотацию (в чем я сильно сомневаюсь) и захотите представить ее общественности именно как замену другим универсальным нотациям, вам придется представить ее публике (хотя бы первый раз) в терминах имеющихся нотаций. Кароч, никуда вы от БНФ не денетесь.



    VD>Не говори ерунды. Человеку не нужны ошибочные спецификации (а именно это он получает используя БНФ). Человеку нужны спецификации которые он может понять, и которые позволяют автоматически получить по ним работающее приложение. И это даже не парсер. Ведь человеку нужны: компилятор, документация, поддержка IDE и т.п.


    Это ты про ход работы разработчика компилятора говоришь, а пользователю компилятора вообще до фени, как этот компилятор устроен и работает. Ему нужно нейтральное описание любого из языков.


    VD>Вот все это и будет давать наше N2. Кстати, я буквально сегодня дополнил его описание
    Автор: VladD2
    Дата: 26.04.12
    новым материалом. Описание все еще не полное и незаконченное, но все же оценить что получится в итоге можно. Предлагаю тебе именно этим и заняться. С удовольствием послушаю взвешенное мнение и конструктивную критику.


    С удовольствием почитаю. Заметь, никто не высказывался против вашей системы, наоборот — многим интересно. Но критика БНФ у вас выходит, мягко говоря, как спорт по прыжкам в сторону.
    Re[32]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 27.04.12 08:12
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    V>Увы и ах. Даже если вы разработаете другую УНИВЕРСАЛЬНУЮ нотацию (в чем я сильно сомневаюсь) и захотите представить ее общественности именно как замену другим универсальным нотациям, вам придется представить ее публике (хотя бы первый раз) в терминах имеющихся нотаций. Кароч, никуда вы от БНФ не денетесь.

    Ржу как конь.
    И как же сам БНФ то публики представили, когда никакого БНФ еще не было?
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re: Языки общего назначения не имеют смысла!
    От: Alexander Polyakov  
    Дата: 27.04.12 08:33
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>Никак. Языки общего назначения не имеют смысла.

    WH>Чем больше изучаю, тем сильнее утверждаюсь в этом мнении.
    Что с тулзами аля ReSharper в случае DSL-ей? Причем у текущей версии ReSharper еще огромные просторы для совершенствования и развития. Поэтому интересно обсуждать с учетом этих потенциальных возможностей развития.

    В частности, как в код, написанный на DSL, вносятся изменения?
    Re[33]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 27.04.12 08:39
    Оценка: :)
    Здравствуйте, WolfHound, Вы писали:

    WH>И как же сам БНФ то публики представили, когда никакого БНФ еще не было?


    Через ее строгое отображение на КС-редукции. Ее единственное отличие от них — это удобная запись нескольких редукций через "или" — '|'.
    ИМХО, отсюда и бОльшая популярность — из-за более гибкой/компактной записи.
    Re[35]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 27.04.12 08:49
    Оценка: +1 :)
    Здравствуйте, WolfHound, Вы писали:


    WH>AVK и сам не сможет по тому куску восстановить архитектуру.

    WH>Он все понимает только по тому, что все спроектировал.

    Архитектура банальная — связанные сущности. Набор связей стандартный: 1:1, 1:oo, oo:oo.
    Для приведенного куска одни связи, для другого куска будут другие. Конкретные связи определяются прикладной областью, а не платформой. Платформа лишь предоставляет для каждой связи способы ее реализации более одного в общем случае)


    I>>Тогда у тебя должен быть ДСЛ для примера AVK.

    WH>После того как AVK удосужится нормально ответить на вопросы.

    А что было непонятно из приведенного отрывка? Спрашивай.
    Re[2]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 27.04.12 10:22
    Оценка:
    Здравствуйте, Alexander Polyakov, Вы писали:

    AP>Что с тулзами аля ReSharper в случае DSL-ей? Причем у текущей версии ReSharper еще огромные просторы для совершенствования и развития. Поэтому интересно обсуждать с учетом этих потенциальных возможностей развития.

    Это решаемый вопрос.

    AP>В частности, как в код, написанный на DSL, вносятся изменения?

    Как и в любой другой код.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[37]: Языки общего назначения не имеют смысла!
    От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
    Дата: 27.04.12 10:53
    Оценка: +1 :))
    Здравствуйте, WolfHound, Вы писали:

    I>>>>Консольный компилер, без изысков.

    WH>>>А я что написал?
    I>>Я предлагаю тебе взять да оценить. Не надо придуриваться, сравнивать нужно сравнимое, а не табурет с бегемотом.
    WH>Что оценить?

    Время на написание консольного компилятора модула с нуля.

    И кстати, ты так и не привел перечень скилов и время на прокачку каждого необходимые для овледения дсл.

    Смотри, раз ты на это не способен, показываю пример

    Берем самое простое, которое чуть не все проходият, польская запись, 1й курс института. Задача много сложнее FizzBuzz. Позволяет оформить простецкий язык и вычислитель на ём, что и делают в конце первого курса.
    Для оптимизации нужно понимать структуры данных, вычислительную сложность, дискретную математику. Опаньки, сложность резко подросла до 3го курса.
    Далее, для сокращения времени разработки нужно ООП(на раз) и ФП (на раз). По минимум это 4-5й курс. А что бы "на раз" это надо года два попахать уже после института.

    Теперь собственно ДСЛ. Сделать формализацию простецкой бизнес-задачи может и студент. ДСЛ нужен для семейства задач, а не решения одной единственной. Вот формализовать все это семейство и предложить качественное решение нужно уже минимум 5 лет опыта в конкретном бизнесе. просто потому что ДСЛ для простых задач никому не нужен.

    Взять тот же складской учет — тут надо убить вагоны времени, что бы понимать все нюансы и методы моделирования решения таких задач. Т.е. как ни крути, 5 лет после института.

    Что имеем по факту. Студенты идут работать на 2-3м курсе. На таких проектах всегда есть несколько экспертов, которые делает формализацию и студенту остаётся решать небольшие инженерные задачи, набивать скилы в бизнес-специфике, программухе и тд и тд.
    Если взять типичного (sic!) депелопера с 5ю годами опыта, то у него два-три места работы, то есть, в бизнес-специфике он нуб куда бы ни пошел. Какие он умеет скилы в программухе — не важно. Он нуб в бизнес-специфике и потому никому не нужен. То есть, он просто не сможет формализовать задачу настолько что бы родить ДСЛ, просто не хватит сведений про бизнес-специфику.



    I>>На чистом немерле без ваших императивных костылей сильно вряд ли. А если взять макросы, то совершенно очевидно, что не любой. Тебе просто удобно игнорировать сообщения тех, кто попробовал и забил.

    WH>А мне совершенно очевидно обратное.

    Ну да, только ты почему то хочешь выгнать из индустрии без малого 80-90% разработчиков и почему то в рассчет их не берешь.

    Ты в курсе, что макросы это метапрограммирование ? Ну то есть, это само по себе сложнее обычного программирования, поскольку это совершенно другой уровень абстракции. В C# сильно слабое метапрограммирование , да и используют его в основном неявно, типа, накликал мышом, получил модель и работаешь. И после этого утверждать, что любой девелопер на C# сможет на раз писать макры на немерле мягко говоря слишком сильно.
    Сколько времени ты собираешься такого готовить ?

    I>>Правильно. Только сложность там специфике бизнеса и совершенно необязательно код должен быть таким же сложным.

    WH>Каким сложным? Ты хоть знаешь что такое FizzBuzz?

    Давно перестал опохмеляться ?

    I>>Он дал все необходимые пояснения.

    WH>Не дал. На чуть менее чем все вопросы он ответил "не важно".

    Они и не важны

    WH>>>А что с ней?

    I>>Все хорошо, отдохни.
    WH>Давай конкретно.

    Извини, с того времени у меня сменилось два компа и такой мусор я не храню.

    I>>У нас ветка продуктов в сумме потянет мегов 150 кода который писался на 1.0 и перекочевал в 3.5, сейчас будет переводиться на 4.0. Там заюзаны практически все фичи языка. Не было ни одной проблемы.

    WH>А я помню перевод 10 метров с первого на второй. Было несколько проблем.
    WH>Они конечно решились в течении дня но они были.

    Мелочовочка. Единственная серьезная проблема у Микрософта это отказ от J# в 2008й вижле.

    I>>С C# все хорошо. А вот с немерле — не очень. Я забил когда в очередной версии перестал компилиться старый код и выбросил эту поделку на помойку.

    WH>Не верю в то, что ты пытался его использовать.

    С твоей верой спорить бесмысленно. Вы мне 5 итли 6 лет доказываете что я чего не пробовал Можно я буду лучше знать, чего я пробовал а чего нет ?

    WH>Я вот использую его весьма активно.

    WH>Проблем с тем, что старый код не компилируется новой версией не помню.

    Поздравляю тебя, соврамши "Народ сошёлся на том, что поломанные макросы не большая проблема." @ Wolfhound




    I>>Да ты все акцентируешь внимание на этом натягивании. Я вот не могу этого понять, как ни кручу, а решение задачи занимает много больше времени чем запись решения. Может ты не теми задачами занимаешься ?

    WH>Ты просто в решение задачи включаешь натягивание ее на целевой язык.
    WH>А это сложно.

    Что там сложно ? Для любых задач ? Почему если задача натягивается на реляционную модель, то возникнут какие то проблемы с натягиванием её например на объектную модель ?

    I>>У юзеров есть тонны своих файлов в экселе которые он хочет засунуть в нашу прогу.

    WH>Те нужно написать парсер эксельных документов.

    Забудь про парсер, это 0% времени.

    WH>И конвертер во внутренний формат вашей проги.


    И конвертер забудь. Это 0% времени.

    WH>Какой формат внутри вашей проги?

    WH>Что за данные?

    Просто объектная модель. Куда и как она персистится — совершенно не важно.

    I>>Файлики он редактирует руками, что накладывает кучу ограничений.

    WH>Ты это рассказываешь человеку который компиляторы пишет?

    Я указываю важное ограничение. У меня нет сведений чего у тебя в голове есть, а чего нет.

    I>>При импорте кое какие объекты нужно удалять, кое какие — создавать, в некоторых случаях обновление вообще нельзя выполнять. Например так — строчка в xls-файле это создание около десятка сущностей при выполнении ряда условий или же поиск-модификация этого десятка сущностей при выполнении ряда условий. Естественно, может быть все вместе — и создание и поиск и удаление и модификация и тд.

    WH>Примеры правил можно?

    Примерно так: закладка NetworkElement, колонка SiteName указывает имя объекта-привязки это Site. По нему нужно найти объект SiteFitout или создать если такой отсутствует. Колонка Name содержит имя элемента, который принадлежит SiteFitout, если такой существует, то выдать мессагу и продолжить с новой строчки
    Если нет, то создать новый, при этом свойства нового нужно вычислить по колонкам в файле. Где то нужно брать дефолтное, где то нужно брать нуль, где то нужно вычислять по содержимомум колонок или даже сгонять в модель за значением. "Сгонять в модель" == выполнить запрос по модели.

    Другий пример — TransportSystem — найти в ранее загруженых или создать систему. Если система уже существовала до загрузки, то выдать ошибку и начать новую строчку. Если система была создана, проапдетить одни свойства, если найдена — другие. В обоих случах проапдейтить еще один набор свойств. На систему прямо или косвенно ссылается кучка сущностей, всех их нужно обновить определенным образом, вся инфа есть в каждой строчке
    После всего этого пересчитать некоторые свойства системы на основании top-owner. После этого все системы нужно добавить в сабнет, который нужно вычислить. Если сабнетов оказалось больше одного или хотя бы одна система не может быть добавлена в него, это ошибка и импорт невалидный.

    Еще бывает так — строка определяет не один элемент, а несколько, при чем создавать часть из них нужно 1 до инициализации основного 2 после 3 после обработки всей таблицы(закладки)

    Самое интересно — все это часто меняется по ряду причин.

    И кстати, дсл для импорта уже был. От него отказались, т.к. было слишком тяжело поддерживать, вдобавок он постепенно выродился в тьюринг-полный язык. Он еще болтается, на ём можно покрыть практически всё, но не осталось ни одного человека, кто бы понимал внутренности этого дсл и все тонкости скриптов.

    Замеряли расход времени таким образом — один фиксит дсл и скрпты, другой делает в лоб. Во всех случаях дсл проиграл. ну и во всех ветках продуктов(разные люди, разные бюджеты, разное руководство) девелперы бегали от этого дсл и писали свои велосипеды.

    Соответсвенно вопрос — где взять ту пульку о которой ты говоришь. Вроде все как надо, ДСЛ и тд, а головняка было примерно на 6 лет и руководство приняло решение забить на этот дсл.

    I>>Если продукты, то почему не можешь дать ссылку ?

    WH>90% программистов не могут дать ссылку на то, что они делают.
    WH>Это означает то, что они ничего не делают?
    WH>Или то, что они не работают на бизнес?

    90% процентов программистов или 90% программистов которые заняты на продуктовых проектах ? Ты определись. Если первое, то неясно к чемы ты это сказал. Если второе, то это мягко говоря неправда. Продукт это рынок, а не закрытая фенька которая никто не видел.

    I>>В мейнстриме БЛ вроде той что показал AVK это норма. А пачка технологий означает использование готовых инструментов, а не создание собственных.

    WH>Для стандартных задачек будут стандартные ДСЛ.
    WH>А самое веселое в том, что то же AVK как раз технологии и создает.

    Да чет непохоже. Кстати, немерле уже умеет сервелат ? Winphone ? Unity3d ? Xna ?

    I>>Ты похоже меряешь способности к решению задач исключительно в понятиях программирования.

    WH>Ох. Человек, который не может FizzBuzz писать не может совсем.
    WH>Условие этого самого FizzBuzz я привел выше.

    Ты так и не привел перечень скилов и время на прокачку каждого необходимые для овледения дсл.
    Re[38]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 27.04.12 11:54
    Оценка:
    Здравствуйте, Ikemefula, Вы писали:

    I>Время на написание консольного компилятора модула с нуля.

    Я уже оценил.
    Один день. Вместе с ИДЕ. Ибо она бесплатно получится.

    I>И кстати, ты так и не привел перечень скилов и время на прокачку каждого необходимые для овледения дсл.

    Нужен обыкновенный вменяемый программист.
    И пара дней на изучение.

    I>Берем самое простое, которое чуть не все проходият, польская запись, 1й курс института. Задача много сложнее FizzBuzz. Позволяет оформить простецкий язык и вычислитель на ём, что и делают в конце первого курса.

    I>Для оптимизации нужно понимать структуры данных, вычислительную сложность, дискретную математику. Опаньки, сложность резко подросла до 3го курса.
    I>Далее, для сокращения времени разработки нужно ООП(на раз) и ФП (на раз). По минимум это 4-5й курс. А что бы "на раз" это надо года два попахать уже после института.
    И все это сделает инструмент.
    Короче вменяемый студент вполне справится.

    I>Теперь собственно ДСЛ. Сделать формализацию простецкой бизнес-задачи может и студент. ДСЛ нужен для семейства задач, а не решения одной единственной. Вот формализовать все это семейство и предложить качественное решение нужно уже минимум 5 лет опыта в конкретном бизнесе. просто потому что ДСЛ для простых задач никому не нужен.

    Неверный посыл.
    ДСЛ нужен для решения конкретной задачи.
    На все остальные он обобщится итерациями по мере поступления новых задач.

    I>>>Правильно. Только сложность там специфике бизнеса и совершенно необязательно код должен быть таким же сложным.

    WH>>Каким сложным? Ты хоть знаешь что такое FizzBuzz?
    I>Давно перестал опохмеляться ?
    Кроме демагогии аргументы будут?

    I>>>Он дал все необходимые пояснения.

    WH>>Не дал. На чуть менее чем все вопросы он ответил "не важно".
    I>Они и не важны


    WH>>Давай конкретно.

    I>Извини, с того времени у меня сменилось два компа и такой мусор я не храню.
    Понятно. Фактов нет.

    I>Мелочовочка. Единственная серьезная проблема у Микрософта это отказ от J# в 2008й вижле.

    У мелкософта значит мелочевка, а в немерле конец света.
    Двойные стандарты на марше.

    WH>>Я вот использую его весьма активно.

    WH>>Проблем с тем, что старый код не компилируется новой версией не помню.
    I>Поздравляю тебя, соврамши "Народ сошёлся на том, что поломанные макросы не большая проблема." @ Wolfhound
    Разговор шел про Н2!
    Это совершенно другой проект.
    К немерлу отношения не имеющий.
    Никакого.
    Кроме того что он сможет компилировать похожий язык.

    WH>>А это сложно.

    I>Что там сложно ?
    Все. Просто ты привык. И не понимаешь что можно иначе.

    I>Для любых задач ?

    Да.

    I>Почему если задача натягивается на реляционную модель, то возникнут какие то проблемы с натягиванием её например на объектную модель ?



    I>Забудь про парсер, это 0% времени.

    I>И конвертер забудь. Это 0% времени.
    I>Просто объектная модель. Куда и как она персистится — совершенно не важно.
    Идем по пути AVK?
    Если ты не будешь отвечать на вопросы, то ничего не получится.

    Из твоих примеров я понял только то, что все можно свести к некому подобию реляционной модели.
    Парсим документы в таблицы.
    Описываем ограничения. Они автоматически проверятся и выведутся в лог.
    Далее описываем процедуру импорта.
    Опять же отдельно описываем ограничения на результирующую модель приложения.
    Они так же будут автоматам проверятся при всех операциях с моделью приложения.

    I>Замеряли расход времени таким образом — один фиксит дсл и скрпты, другой делает в лоб. Во всех случаях дсл проиграл. ну и во всех ветках продуктов(разные люди, разные бюджеты, разное руководство) девелперы бегали от этого дсл и писали свои велосипеды.

    И кто же этот ДСЛ сделал? Уж не человек ли который FizzBuzz осилить не смог?
    Кстати можешь показать код на этом ДСЛ?

    I>Соответсвенно вопрос — где взять ту пульку о которой ты говоришь. Вроде все как надо, ДСЛ и тд, а головняка было примерно на 6 лет и руководство приняло решение забить на этот дсл.

    У меня практика прямо противоположная.
    Народ очень радовался тому, что моему демоническому кластеру можно писать запросы на ДСЛ.
    Ведь они могли менять его поведение, так как им захочется легким движением руки.
    Мне даже ничего объяснять не пришлось. Они сами все поняли.
    Хотя конечно они все могут написать FizzBuzz не приходя в сознание.
    Из документации был лишь список команд.
    Поддержка ДСЛ сводилась к тому, что раз в несколько месяцев добавлялись новые команды.

    I>Ты так и не привел перечень скилов и время на прокачку каждого необходимые для овледения дсл.

    Ох. Учитывая, что у тебя первым в списке идёт то чтобы этим мог пользоваться человек, который не может FizzBuzz это все бесполезно.
    Да и не слушаешь ты то, что тебе говорят.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[3]: Языки общего назначения не имеют смысла!
    От: Alexander Polyakov  
    Дата: 27.04.12 13:09
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    AP>>Что с тулзами аля ReSharper в случае DSL-ей? Причем у текущей версии ReSharper еще огромные просторы для совершенствования и развития. Поэтому интересно обсуждать с учетом этих потенциальных возможностей развития.

    WH>Это решаемый вопрос.
    Как? Опиши основные принципы.

    AP>>В частности, как в код, написанный на DSL, вносятся изменения?

    WH>Как и в любой другой код.
    Любой код? Везде же по-разному. Например, я вношу изменения в C#, используя фичи ReSharper-а.
    Re[4]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 27.04.12 13:32
    Оценка:
    Здравствуйте, Alexander Polyakov, Вы писали:

    AP>Как? Опиши основные принципы.

    Благодаря тому, что все будет на ДСЛях по ним будет сгенерирован не только компилятор, но и ИДЕ. Это дело техники.
    Так же для ИДЕ понадобятся специальные ДСЛ для описания рефакторингов и форматирования.
    С другой стороны ИДЕ не будет использовать трансформации кода.

    Еще можно почитать тут (черновик все, что там написано, может быть пересмотрено, но общая идея должна быть понятна):
    http://www.rsdn.ru/article/nemerle/N2/N2-Project.rsdnml.xml
    Автор(ы): Чистяков Владислав Юрьевич
    Дата: 17.05.2012
    В данной статье рассказывается о новом проекте языкового фрэймворка – N2


    WH>>Как и в любой другой код.

    AP>Любой код? Везде же по-разному. Например, я вношу изменения в C#, используя фичи ReSharper-а.
    А я вношу изменения, в код используя фичи головного мозга.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[5]: Языки общего назначения не имеют смысла!
    От: Alexander Polyakov  
    Дата: 27.04.12 14:02
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    AP>>Как? Опиши основные принципы.

    WH>Благодаря тому, что все будет на ДСЛях по ним будет сгенерирован не только компилятор, но и ИДЕ. Это дело техники.
    WH>Так же для ИДЕ понадобятся специальные ДСЛ для описания рефакторингов и форматирования.
    WH>С другой стороны ИДЕ не будет использовать трансформации кода.
    Реализация пока не интересует. Опишите основные принципы с точки зрения пользователя.

    WH>>>Как и в любой другой код.

    AP>>Любой код? Везде же по-разному. Например, я вношу изменения в C#, используя фичи ReSharper-а.
    WH>А я вношу изменения, в код используя фичи головного мозга.
    Противопоставляете ReSharper своему головному мозгу? ReSharper довольно дешев. Вам не удалось продать подороже ресурсы своего головного мозга?
    Re[36]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 27.04.12 14:48
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    V>Здравствуйте, WolfHound, Вы писали:



    WH>>AVK и сам не сможет по тому куску восстановить архитектуру.

    WH>>Он все понимает только по тому, что все спроектировал.

    V>Архитектура банальная — связанные сущности. Набор связей стандартный: 1:1, 1:oo, oo:oo.

    V>Для приведенного куска одни связи, для другого куска будут другие. Конкретные связи определяются прикладной областью, а не платформой. Платформа лишь предоставляет для каждой связи способы ее реализации более одного в общем случае)

    Мозг то связями не компостируй. Опиши словами что происходит и зачем.

    V>А что было непонятно из приведенного отрывка? Спрашивай.


    В общем — ничего. Давай ты переводчиком поработаешь. Опиши что там происходит и с чем... в деталях.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[24]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 27.04.12 14:50
    Оценка: -1
    Здравствуйте, Ikemefula, Вы писали:

    I>И как ты решил что я это часть твоей ЦА? У меня не вера, а факты, как вы забили на обратную совместимость.


    У тебя не вера и не факты. У тебя безответственный треп. И это уже надоело. Толку от общения — 0.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[39]: Языки общего назначения не имеют смысла!
    От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
    Дата: 27.04.12 15:01
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    I>>Время на написание консольного компилятора модула с нуля.

    WH>Я уже оценил.
    WH>Один день. Вместе с ИДЕ. Ибо она бесплатно получится.

    С нуля что ли ? Студенты пишут всё с _нуля_. то есть, твоя производительность не в 100 раз, а всего в 14 раз больше, чем у студента третьего курса

    I>>И кстати, ты так и не привел перечень скилов и время на прокачку каждого необходимые для овледения дсл.

    WH>Нужен обыкновенный вменяемый программист.
    WH>И пара дней на изучение.

    Не ясно, что должен уметь этот вменяемый программист и сколько у него должно быть опыта, и отдельно — сколько опыта в предметной области.

    I>>Для оптимизации нужно понимать структуры данных, вычислительную сложность, дискретную математику. Опаньки, сложность резко подросла до 3го курса.

    I>>Далее, для сокращения времени разработки нужно ООП(на раз) и ФП (на раз). По минимум это 4-5й курс. А что бы "на раз" это надо года два попахать уже после института.
    WH>И все это сделает инструмент.
    WH>Короче вменяемый студент вполне справится.

    Смешно. Я хорошо представляю за какое время студенты осваивают регулярные выражения, sql и тд.

    I>>>>Правильно. Только сложность там специфике бизнеса и совершенно необязательно код должен быть таким же сложным.

    WH>>>Каким сложным? Ты хоть знаешь что такое FizzBuzz?
    I>>Давно перестал опохмеляться ?
    WH>Кроме демагогии аргументы будут?

    Ты сам начал

    I>>Извини, с того времени у меня сменилось два компа и такой мусор я не храню.

    WH>Понятно. Фактов нет.

    Когда были факты, вы все хором обвиняли людей в тупизне.

    I>>Мелочовочка. Единственная серьезная проблема у Микрософта это отказ от J# в 2008й вижле.

    WH>У мелкософта значит мелочевка, а в немерле конец света.
    WH>Двойные стандарты на марше.

    Попробуй перечитать внимательно. Мелочовочка — это про твои ссылки. J# это "серьезная проблема". И да, это конец света, для J# разумеется. Мы вот в свое время вляпались, сейчас есть 10% важного кода который ни портировать, ни переписать за разумное время нельзя, потому переход на 4.0 откладывается уже целый год.

    I>>Поздравляю тебя, соврамши "Народ сошёлся на том, что поломанные макросы не большая проблема." @ Wolfhound

    WH>Разговор шел про Н2!

    Когда будет следующий релиз немерле ?

    WH>>>А это сложно.

    I>>Что там сложно ?
    WH>Все. Просто ты привык. И не понимаешь что можно иначе.

    Я могу для любой вещи рассказать и показать минимальный набор знаний и умений + указать время примерное для освоение. У тебя с ДСЛ ничего подобного нет и вряд ли когда либо будет.

    I>>Просто объектная модель. Куда и как она персистится — совершенно не важно.

    WH>Идем по пути AVK?
    WH>Если ты не будешь отвечать на вопросы, то ничего не получится.

    Хорошо, один из вариантов — такой же файлик, как и принимаем у юзера. Второй вариант — xml на старом дсл, нужен для обратной совместимости. Третий вариант еще не появился, это будет какой нибудь шустрый ОРМ, пока здесь препятствие наша вычислительная модель которая оптимизировалась под перформанс операций, а не персистанс.

    С сохранением всё предельно просто:

    private Export Sites()
            {
                var sites = ... здесь тупо Linq2Objects запрос;
    
                var exporter = Export.From(sites)
                    .Column(ColumnNames.SiteId, obj => obj.Name)
                     // так все колонки
                    .Column(ColumnNames.ServerId, obj => obj.ServerId);
    
                return exporter;
            }


    Хотелось бы чтото навроде с импортом.

    WH>Из твоих примеров я понял только то, что все можно свести к некому подобию реляционной модели.


    Спасибо, капитан, скажи что нибудь менее очевидное.

    WH>Описываем ограничения. Они автоматически проверятся и выведутся в лог.

    WH>Далее описываем процедуру импорта.
    WH>Опять же отдельно описываем ограничения на результирующую модель приложения.
    WH>Они так же будут автоматам проверятся при всех операциях с моделью приложения.

    Покажи какая модель будет использоваться для этих четырех строчек и как будет выглядеть ДСЛ.

    I>>Замеряли расход времени таким образом — один фиксит дсл и скрпты, другой делает в лоб. Во всех случаях дсл проиграл. ну и во всех ветках продуктов(разные люди, разные бюджеты, разное руководство) девелперы бегали от этого дсл и писали свои велосипеды.

    WH>И кто же этот ДСЛ сделал? Уж не человек ли который FizzBuzz осилить не смог?

    Его делал человек который фактически был архитектором, сарказм абсолютно неуместен.

    WH>Кстати можешь показать код на этом ДСЛ?


    Column="Node" 
    Type="string"
    ImportPath="ServiceEndA.Node"
    ExportPath="ServiceEndA.Node.Site.Name"
    ConvertImport="FindOrCreate(Root.NetworkStructure.ServiceLayer.Nodes, Site, FindObjByName(Root.SiteMap.Sites, ColumnValue, typeof(Site)), typeof(Node))"


    WH>Мне даже ничего объяснять не пришлось. Они сами все поняли.

    WH>Хотя конечно они все могут написать FizzBuzz не приходя в сознание.

    А ты не думал, что это и есть основная причина , что они "сами всё поняли" ?

    I>>Ты так и не привел перечень скилов и время на прокачку каждого необходимые для овледения дсл.

    WH>Ох. Учитывая, что у тебя первым в списке идёт то чтобы этим мог пользоваться человек, который не может FizzBuzz это все бесполезно.
    WH>Да и не слушаешь ты то, что тебе говорят.

    Ну, раз у тебя такого списка нет, то можно и закончить.
    Re[25]: Языки общего назначения не имеют смысла!
    От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
    Дата: 27.04.12 15:02
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    I>>И как ты решил что я это часть твоей ЦА? У меня не вера, а факты, как вы забили на обратную совместимость.


    VD>У тебя не вера и не факты. У тебя безответственный треп. И это уже надоело. Толку от общения — 0.


    Да, расслабься, отдохни.
    Re[6]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 27.04.12 15:11
    Оценка:
    Здравствуйте, Alexander Polyakov, Вы писали:

    AP>Реализация пока не интересует. Опишите основные принципы с точки зрения пользователя.

    Какие еще принципы?
    Не понимаю чего ты хочешь.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[26]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 27.04.12 15:28
    Оценка:
    Здравствуйте, Ikemefula, Вы писали:

    I>Да, расслабься, отдохни.


    Спасибо за бесценный совет.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[40]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 27.04.12 15:57
    Оценка:
    Здравствуйте, Ikemefula, Вы писали:

    I>С нуля что ли ? Студенты пишут всё с _нуля_. то есть, твоя производительность не в 100 раз, а всего в 14 раз больше, чем у студента третьего курса

    Что они пишут?
    Они пишут кривой компилятор.
    Который генерирует тормозной код с кучей ошибок.
    Отладка, ИДЕ и оптимизации в эти две недели не входят. Доведение компилятора до промышленного качества тоже.
    Добавь все это и получишь лет 5.

    I>Смешно. Я хорошо представляю за какое время студенты осваивают регулярные выражения, sql и тд.

    Это, смотря какие студенты.

    I>>>>>Правильно. Только сложность там специфике бизнеса и совершенно необязательно код должен быть таким же сложным.

    WH>>>>Каким сложным? Ты хоть знаешь что такое FizzBuzz?
    I>>>Давно перестал опохмеляться ?
    WH>>Кроме демагогии аргументы будут?
    I>Ты сам начал
    Что я начал? Это ты тут вещаешь, что FizzBuzz сложнее бизнеслогики.

    I>>>Извини, с того времени у меня сменилось два компа и такой мусор я не храню.

    WH>>Понятно. Фактов нет.
    I>Когда были факты, вы все хором обвиняли людей в тупизне.
    У тебя их никогда не было.

    I>>>Мелочовочка. Единственная серьезная проблема у Микрософта это отказ от J# в 2008й вижле.

    WH>>У мелкософта значит мелочевка, а в немерле конец света.
    WH>>Двойные стандарты на марше.
    I>Попробуй перечитать внимательно. Мелочовочка — это про твои ссылки. J# это "серьезная проблема". И да, это конец света, для J# разумеется. Мы вот в свое время вляпались, сейчас есть 10% важного кода который ни портировать, ни переписать за разумное время нельзя, потому переход на 4.0 откладывается уже целый год.
    Причём тут J#?
    Ты тут утверждал про какие-то фатальные проблемы с обратной совместимостью немерла.

    I>>>Поздравляю тебя, соврамши "Народ сошёлся на том, что поломанные макросы не большая проблема." @ Wolfhound

    WH>>Разговор шел про Н2!
    I>Когда будет следующий релиз немерле ?
    Спроси у Влада. Я немерлом не занимаюсь. Я туда влезаю, только если мне нужны фичи которых еще нет в компиляторе.

    I>Хорошо, один из вариантов — такой же файлик, как и принимаем у юзера. Второй вариант — xml на старом дсл, нужен для обратной совместимости. Третий вариант еще не появился, это будет какой нибудь шустрый ОРМ, пока здесь препятствие наша вычислительная модель которая оптимизировалась под перформанс операций, а не персистанс.

    Я ничего не понял.

    WH>>Из твоих примеров я понял только то, что все можно свести к некому подобию реляционной модели.

    I>Спасибо, капитан, скажи что нибудь менее очевидное.
    Из той информации, что ты дал что-то еще вытащить очень трудно.

    WH>>Описываем ограничения. Они автоматически проверятся и выведутся в лог.

    WH>>Далее описываем процедуру импорта.
    WH>>Опять же отдельно описываем ограничения на результирующую модель приложения.
    WH>>Они так же будут автоматам проверятся при всех операциях с моделью приложения.
    I>Покажи какая модель будет использоваться для этих четырех строчек и как будет выглядеть ДСЛ.

    Примерно так: закладка NetworkElement, колонка SiteName указывает имя объекта-привязки это Site. По нему нужно найти объект SiteFitout или создать если такой отсутствует. Колонка Name содержит имя элемента, который принадлежит SiteFitout, если такой существует, то выдать мессагу и продолжить с новой строчки
    Если нет, то создать новый, при этом свойства нового нужно вычислить по колонкам в файле. Где то нужно брать дефолтное, где то нужно брать нуль, где то нужно вычислять по содержимомум колонок или даже сгонять в модель за значением. "Сгонять в модель" == выполнить запрос по модели.

    Из этого мало что понятно можно получить что-то типа такого
    // Общая модель приложения
    table SiteFitout
        field SiteName : String;
    end
    
    // Это ограничение на модель
    // Проверяется при каждой транзакции
    check uniq SiteFitout.SiteName
    error $"$SiteName blablabla";
    
    //========================
    // Конкретный импорт
    table SiteNames
        field SiteName : String;
    end
    
    import to SiteNames
        SiteName <- NetworkElement.SiteName
    end
    
    check uniq SiteNames.SiteName
    error $"$SiteName blablabla";
    
    check SiteNames.SiteName not in SiteFitout.SiteName
    error $"$SiteName blablabla";

    Чтобы написать остальное не хватает информации.

    WH>>И кто же этот ДСЛ сделал? Уж не человек ли который FizzBuzz осилить не смог?

    I>Его делал человек который фактически был архитектором, сарказм абсолютно неуместен.
    Одно другому не мешает. Особенно если верить тебе что подавляющее большинство программистов не могут FizzBuzz.

    WH>>Кстати можешь показать код на этом ДСЛ?

    I>
    I>Column="Node" 
    I>Type="string"
    I>ImportPath="ServiceEndA.Node"
    I>ExportPath="ServiceEndA.Node.Site.Name"
    I>ConvertImport="FindOrCreate(Root.NetworkStructure.ServiceLayer.Nodes, Site, FindObjByName(Root.SiteMap.Sites, ColumnValue, typeof(Site)), typeof(Node))"
    I>

    В ConvertImport код на C#?
    Почему это все задается для одной колонки? У вас, что связанных колонок не бывает?

    WH>>Мне даже ничего объяснять не пришлось. Они сами все поняли.

    WH>>Хотя конечно они все могут написать FizzBuzz не приходя в сознание.
    I>А ты не думал, что это и есть основная причина , что они "сами всё поняли" ?
    Думал. И именно поэтому я и не работаю с теми, кто не может FizzBuzz.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[31]: Языки общего назначения не имеют смысла!
    От: netch80 Украина http://netch80.dreamwidth.org/
    Дата: 30.04.12 10:55
    Оценка: :)
    Здравствуйте, WolfHound, Вы писали:

    I>>С когнитивной тз она сложнее, например потому что юзер не в курсе про то что такое солнце. Для него солнце это шарик на синем небе. шарик и небо ему понятны. А все остальное он не может пощупать. Соответсвенно гелиоцентричекую ты такому юзеру в голову не вобьёшь до тех пор, пока он не потрогает все руками.

    WH>И как же мне это еще в детском саду объяснили то?

    Ты принял на веру, а не как практически проверяемый тобой и значимый факт.
    (См. отношение Ш.Холмса к астрономии по Конан-Дойлю.)
    Фактически, это было постороннее знание, которое ты запомнил механически без осмысления.
    Осмысление наступило бы только тогда, когда ты бы сам летал в космос или занялся программированием полёта космического аппарата.

    WH>>>Нет. Годы я потратил на то чтобы перекопать мегатонны навоза и понять, как правильно делать.

    I>>Ну то есть ты напрочь отрицаешь ценность практики ?
    WH>Нет. Я говорю, что создание компиляторов на много проще чем принято думать.

    Пока что ты доказал это разве что для создания парсеров. Дальше — у компиляторов есть ещё множество важных частей.

    WH>Ты действительно думаешь, что все кто заходит в форму по немерле пишут компилятор немерла? Или тем более работают над Н2?

    WH>Над Н2 сейчас работает ровно один человек. И еще один статьи пишет.

    Хм... узок их круг, страшно далеки они от народа... и вы надеетесь чего-то достичь?

    WH>Ох. В драконе когнитивная сложность тоже зашкаливает. Попробуй, объясни человеку что такое конфликт сдвиг/свертка.


    Именно это достаточно тривиально. Вот многое другое — да, сложно.
    The God is real, unless declared integer.
    Re[41]: Языки общего назначения не имеют смысла!
    От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
    Дата: 30.04.12 11:40
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>Здравствуйте, Ikemefula, Вы писали:


    I>>С нуля что ли ? Студенты пишут всё с _нуля_. то есть, твоя производительность не в 100 раз, а всего в 14 раз больше, чем у студента третьего курса

    WH>Что они пишут?
    WH>Они пишут кривой компилятор.
    WH>Который генерирует тормозной код с кучей ошибок.
    WH>Отладка, ИДЕ и оптимизации в эти две недели не входят. Доведение компилятора до промышленного качества тоже.
    WH>Добавь все это и получишь лет 5.

    Вот если бы ты предложил рефакторинг кода на ДСЛ, то можно обойтись и без отладки, и даже без оптимизаций. "Промышленное" нужно для массового применения, т.е. когда компилер будет широко использоваться. Судя по тому, что на разных проектах используются и хорошо работают самопальные примитивные интерпретаторы-вычислителисовершенно не очевидно, что твое "промышленное" будет давать значительный профит.

    Есть большая проблема — в случае с дсл нет инструментов автоматического рефакторинга, то есть нужно или суппортить все версии, или же писать миграционные скрипты или же колбасить код руками. то есть тупо управлять сложностью и понижать её любыми способами.
    Но это еще пол-беды. Качественный ДСЛ требует хороший функциональный базис, то есть серьезную мат-подготовку. Например linq тянет серьезный мат-бекграунд.
    В кратце это означает, что для создания такого ДСЛ тебе нужен Erik Meijer. Таких людей единицы, ну десятки, а проектов миллионы в год.

    То есть, по факту, твой подход незначительно превосходит студенческую поделку и требует всего в ~10 раз меньше времени.

    Теперь про актуальность того, что ты предлагаешь.

    Даже много большей экономии недостаточно для перехода на ДСЛ для большинства проектов, тупо потому что программирование в них не является узким местом.
    Будешь смеяться, узкое место в длинных проектах вообще и продуктовых софтверных продуктах в частности ни разу не программирование. Программирование является узким местом в небольших проектах, шароварах, R&D и узких задачах где нужно именно системное программирование и где высокая цена ошибка.

    То есть это значит, что все такие оптимизации не дают значимого профита, зато вводят новые риски, как напрамер сильную зависимость от ЧФ которую ты упорно отрицаешь или же переход на полностью новый стек технологий, да-да.

    I>>Смешно. Я хорошо представляю за какое время студенты осваивают регулярные выражения, sql и тд.

    WH>Это, смотря какие студенты.

    Какие есть и других не будет в принципе.

    WH>>>Кроме демагогии аргументы будут?

    I>>Ты сам начал
    WH>Что я начал? Это ты тут вещаешь, что FizzBuzz сложнее бизнеслогики.

    Для бизнеслогики необходимый минимум это
    1. хорошие знания в бизнес специфике
    2. минимальные навыки программирования == FizzBuzz
    Отсюда неудивительно, что люди которые проводят годы в 1С(и подобной хрени) практически не умеют программировать.

    I>>Попробуй перечитать внимательно. Мелочовочка — это про твои ссылки. J# это "серьезная проблема". И да, это конец света, для J# разумеется. Мы вот в свое время вляпались, сейчас есть 10% важного кода который ни портировать, ни переписать за разумное время нельзя, потому переход на 4.0 откладывается уже целый год.

    WH>Причём тут J#?

    Пример для сравнения, который показывает проблемы для бизнеса которые возникают если ктото забивает на совместимость, суппорт и тд и тд и тд.

    WH>Ты тут утверждал про какие-то фатальные проблемы с обратной совместимостью немерла.


    Наверное я не правильно чего то сказал ну или где то не разобрался. Я взял код из статей, кое что попробовал, потом через какое то время в релизной версии немерла это отвалилось. Разбираться что к чему нет никакого желания, ибо тот же F# работает и не жужжит, а сами статьи вычитывать не вижу смысла, с другим языками это почему то не нужно, хватает и кода. Я так вообще все языки программирования выучил. Первая книга по ЯП которую я купил, это F# и основная причина в том, что у меня дома нет компьютера а блокнота мне жалко, он ручной работы и в ём хорошая, плотная, бескислотная бумага которую жалко тратить на такие пустяки.

    I>>Хорошо, один из вариантов — такой же файлик, как и принимаем у юзера. Второй вариант — xml на старом дсл, нужен для обратной совместимости. Третий вариант еще не появился, это будет какой нибудь шустрый ОРМ, пока здесь препятствие наша вычислительная модель которая оптимизировалась под перформанс операций, а не персистанс.

    WH>Я ничего не понял.

    1. Модель персистится в такой же файлик, как и тот из которого она подымалась. Это я описал и вроде даже код сохранения привел.
    2. Модель персистится в таблички (xml) с помощью старого дсл
    3. Будет персист в БД, сейчас есть препятствие — вычислительная модель не подходит под ОРМ.

    WH>>>Они так же будут автоматам проверятся при всех операциях с моделью приложения.

    I>>Покажи какая модель будет использоваться для этих четырех строчек и как будет выглядеть ДСЛ.
    WH>
    WH>// Общая модель приложения
    WH>table SiteFitout
    WH>    field SiteName : String;
    WH>end
    
    WH>// Это ограничение на модель
    WH>// Проверяется при каждой транзакции
    WH>check uniq SiteFitout.SiteName
    WH>error $"$SiteName blablabla";
    
    WH>//========================
    WH>// Конкретный импорт
    WH>table SiteNames
    WH>    field SiteName : String;
    WH>end
    
    WH>import to SiteNames
    WH>    SiteName <- NetworkElement.SiteName
    WH>end
    
    WH>check uniq SiteNames.SiteName
    WH>error $"$SiteName blablabla";
    
    WH>check SiteNames.SiteName not in SiteFitout.SiteName
    WH>error $"$SiteName blablabla";
    
    WH>

    WH>Чтобы написать остальное не хватает информации.

    Реально check uniq должно уметь несколько сценариев, все я не могу перескахзать. Некоторые объекты уникальны глобально, некоторые в пределах какого то объекта модели, некоторые в пределах какого то источника не привязаного четко к конкретному объекту модели. Это зависит от того насколько сильная разница между двумя структурами.

    В примере ниже ты видишь два Findxxx, реально их много больше. И проверка уникальности тож была реализована. Собтсвенно из за такой хрени все и встало колом. Нужно было или добавлять встроеную поддержку всех таких функций или давать способ описывать их в коде. Мы пошли по второму пути и получился тьюринг-полный язык.
    В любом случае начинается хаос — девелопер должен на раз знать и понимать все CheckXXX и FindXXX (а также другие вещи) со всеми вырожденными случаями и оптимизациями.
    С нашим подходм — изменения в одном месте не затрагивают другие места и это помогает решить многие проблемы связаные с отсутствие автоматического рефакторинга.
    Теоретически, можно отрефакторить код, но это ручная работа => высокое количетсво ошибок.
    ну и повторюсь, что бы предложить хороший функциональный базис нужны серьезная прокачка не девелоперских скилов, а математических. Например теория категорий и тд.

    I>>Его делал человек который фактически был архитектором, сарказм абсолютно неуместен.

    WH>Одно другому не мешает. Особенно если верить тебе что подавляющее большинство программистов не могут FizzBuzz.

    Эти умения они демонстрируют на собеседовании, хотя уже имеют работу

    WH>>>Кстати можешь показать код на этом ДСЛ?

    I>>
    I>>Column="Node" 
    I>>Type="string"
    I>>ImportPath="ServiceEndA.Node"
    I>>ExportPath="ServiceEndA.Node.Site.Name"
    I>>ConvertImport="FindOrCreate(Root.NetworkStructure.ServiceLayer.Nodes, Site, FindObjByName(Root.SiteMap.Sites, ColumnValue, typeof(Site)), typeof(Node))"
    I>>

    WH>В ConvertImport код на C#?

    Это все дсл, только небошие оптимизации, например typeof, и я вижу что он ничем не хуже того что предложил ты, разница только в синтаксисе.
    Оптимизации были нужны из за того, что вычислитель работает чз рефлексию. Он был написан еще на фреймворке 1.1.
    Без оптимизаций будет так
    ConvertImport="FindOrCreate(Root.NetworkStructure.ServiceLayer.Nodes, Site, FindObjByName(Root.SiteMap.Sites, ColumnValue))

    Эквивалентный код на C#

    FindOrCreate(Root.NetworkStructure.ServiceLayer.Nodes, (node)=>node.Site, FindObjBy(Root.SiteMap.Sites, (site)=>Site.Name == ColumnValue))


    Можно кое что упростить, но есть вещи вроде FindByPosAnd, FindIf и тд и тд.

    WH>Почему это все задается для одной колонки? У вас, что связанных колонок не бывает?


    Бывает. Для них точно такой же код, только сама логика указана другая. Точно так же будет вызваться Findxxx и тд и тд.

    I>>А ты не думал, что это и есть основная причина , что они "сами всё поняли" ?

    WH>Думал. И именно поэтому я и не работаю с теми, кто не может FizzBuzz.

    В кратце, ты отстаиваешь идею сильной зависимости от высококлассных специалистов только не хочешь этого признавать.
    Из теории риск-менеджмента известно, что риски берутся аккурат из таких вот сильных зависимостей.
    То есть, это именно то с чем бизнес борется любыми способами, следовательно на большинстве проектов это в принципе неприемлемо, ибо основной приоритет это бизнес-специфика.
    Re[42]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 30.04.12 14:18
    Оценка:
    Здравствуйте, Ikemefula, Вы писали:

    I>Вот если бы ты предложил рефакторинг кода на ДСЛ, то можно обойтись и без отладки, и даже без оптимизаций.

    Так я и предложил.
    Читай внимательней.
    За один день можно сделать и компилятор с отладчиком и ИДЕ с рефакторингами.
    Только для этого правильные инструменты нужны. Над чем я и работаю.

    I>"Промышленное" нужно для массового применения, т.е. когда компилер будет широко использоваться.

    Оно нужно всегда. Другое дело что на C# его достижение требует таких затрат что закачаешься.

    I>Судя по тому, что на разных проектах используются и хорошо работают самопальные примитивные интерпретаторы-вычислителисовершенно

    Это по тому что современными инструментами промышленного качества приемлемыми затратами не достичь.

    I>не очевидно, что твое "промышленное" будет давать значительный профит.

    Очевидно.

    I>Есть большая проблема — в случае с дсл нет инструментов автоматического рефакторинга,

    Так я тебе и говорю, что при наличии инструментов это получается почти автоматом.

    I>Но это еще пол-беды. Качественный ДСЛ требует хороший функциональный базис, то есть серьезную мат-подготовку. Например linq тянет серьезный мат-бекграунд.

    Может хватит считать программистов дураками?
    linq может сделать любой толковый студент.

    I>В кратце это означает, что для создания такого ДСЛ тебе нужен Erik Meijer.

    Erik Meijer нужен чтобы пропихнуть linq в компилятор C#.

    I>То есть, по факту, твой подход незначительно превосходит студенческую поделку и требует всего в ~10 раз меньше времени.

    То есть по факту ты не читаешь того что тебе пишут.

    I>Даже много большей экономии недостаточно для перехода на ДСЛ для большинства проектов, тупо потому что программирование в них не является узким местом.

    И что же в них является узким местом?
    Вот сколько проектов видел, везде все упиралось в тормознутость программистов.
    Включая сугубо прикладные проекты.

    I>>>Смешно. Я хорошо представляю за какое время студенты осваивают регулярные выражения, sql и тд.

    WH>>Это, смотря какие студенты.
    I>Какие есть и других не будет в принципе.
    У меня в группе было 2 человека которые могли писать. На соседних специальностях было еще несколько человек.
    Что там делали остальные я не знаю.
    Может быть, тебе всегда попадаются остальные?
    А те, кто может писать обходят твою контору стороной?

    I> 2. минимальные навыки программирования == FizzBuzz

    Ты мне тут пытаешься доказать что FizzBuzz не нужен.

    WH>>Ты тут утверждал про какие-то фатальные проблемы с обратной совместимостью немерла.

    I>Наверное я не правильно чего то сказал ну или где то не разобрался. Я взял код из статей, кое что попробовал, потом через какое то время в релизной версии немерла это отвалилось. Разбираться что к чему нет никакого желания, ибо тот же F# работает и не жужжит,
    http://msdn.microsoft.com/en-us/library/hh416791%28v=vs.110%29.aspx
    Может в немерле тоже что-то такое исправили?

    I>а сами статьи вычитывать не вижу смысла, с другим языками это почему то не нужно, хватает и кода. Я так вообще все языки программирования выучил. Первая книга по ЯП которую я купил, это F# и основная причина в том,

    Те прочитать статью про немерле слишком сложно, а купить целую книгу по F# нормально.
    Опять двойные стандарты на марше.

    I>что у меня дома нет компьютера

    Оно заметно.

    I>а блокнота мне жалко, он ручной работы и в ём хорошая, плотная, бескислотная бумага которую жалко тратить на такие пустяки.

    Чего?

    I>Реально check uniq должно уметь несколько сценариев, все я не могу перескахзать.

    А ты попробуй.

    I>Некоторые объекты уникальны глобально, некоторые в пределах какого то объекта модели, некоторые в пределах какого то источника не привязаного четко к конкретному объекту модели. Это зависит от того насколько сильная разница между двумя структурами.

    Хе-хе. Это не имеет никакого отношения к check uniq.
    Вся разница в том, как формировать таблицу.

    I>В любом случае начинается хаос — девелопер должен на раз знать и понимать все CheckXXX и FindXXX (а также другие вещи) со всеми вырожденными случаями и оптимизациями.

    Это разработчик ДСЛ не должен разводить зоопарк.
    Ибо он реально не нужен.
    Ты еще не показал ничего такого, для чего реляционной алгебры бы не хватило.

    I>С нашим подходм — изменения в одном месте не затрагивают другие места и это помогает решить многие проблемы связаные с отсутствие автоматического рефакторинга.

    А это-то тут причем?
    Какая разница добавить в язык новую конструкцию или новую функцию?
    Да никакой.

    I>ну и повторюсь, что бы предложить хороший функциональный базис нужны серьезная прокачка не девелоперских скилов, а математических. Например теория категорий и тд.

    Нужен просто здравый смысл.
    Не более того.

    I>Это все дсл, только небошие оптимизации, например typeof, и я вижу что он ничем не хуже того что предложил ты, разница только в синтаксисе.

    I>Оптимизации были нужны из за того, что вычислитель работает чз рефлексию. Он был написан еще на фреймворке 1.1.
    И это вместо того чтобы типизировать код. Найти кучу ошибок. И сгенерировать очень быстрый код?
    Генерировать код можно было и на 1.0
    Генератор железный. Он без проблем может нагенарировать все специализации генериков сам.

    I>Можно кое что упростить, но есть вещи вроде FindByPosAnd, FindIf и тд и тд.

    Вот только они все выражаются через where.

    I>Бывает. Для них точно такой же код, только сама логика указана другая. Точно так же будет вызваться Findxxx и тд и тд.

    Продемонстрируй.
    Хочу посмотреть, как вы колонки связываете.

    I>В кратце, ты отстаиваешь идею сильной зависимости от высококлассных специалистов только не хочешь этого признавать.

    Я отстаиваю идею о том, что прибыль могут генерировать только сильные.
    Остальные одни убытки. Не считая распил-проектов.

    I>Из теории риск-менеджмента известно, что риски берутся аккурат из таких вот сильных зависимостей.

    I>То есть, это именно то с чем бизнес борется любыми способами, следовательно на большинстве проектов это в принципе неприемлемо, ибо основной приоритет это бизнес-специфика.
    Бизнес не борется с рисками. Бизнес ими управляет.
    И тут мы имеем вот что:
    Твой вариант: Гарантированный срыв сроков. Куча багов. Раздутый до небес бюджет.
    Мой вариант: Быстрое и качественное решение проблемы. Но придется повозиться с подбором персонала.

    Хотя если я сейчас кину клич о разработке на ДСЛ, сбежится куча очень сильного народа.
    Я гарантирую это.
    Ибо всех их C# с жабой достали.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[43]: Языки общего назначения не имеют смысла!
    От: alex_public  
    Дата: 30.04.12 15:14
    Оценка: :)
    Здравствуйте, WolfHound, Вы писали:

    I>>Но это еще пол-беды. Качественный ДСЛ требует хороший функциональный базис, то есть серьезную мат-подготовку. Например linq тянет серьезный мат-бекграунд.

    WH>Может хватит считать программистов дураками?
    WH>linq может сделать любой толковый студент.
    I>>В кратце это означает, что для создания такого ДСЛ тебе нужен Erik Meijer.
    WH>Erik Meijer нужен чтобы пропихнуть linq в компилятор C#.

    Ммм, а вот тут я бы разделил реализацию и придумывание самих принципов.

    Реализация linq на нормальных языках не представляется мне сложной задачей вообще. Вот например http://habrahabr.ru/post/142632/ человек на коленке сделал разновидность для C++.

    Если же говорить о продумывание принципов, то тут всё гораздо сложнее. Хотя например конкретно в случае linq его авторы тоже не особо потрудились, взяв всё нужное из sql. А вот уже за sql стоят вполне определённые наработки, которые продумывались явно не за пару минут.
    Re[43]: Языки общего назначения не имеют смысла!
    От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
    Дата: 30.04.12 15:57
    Оценка: :)
    Здравствуйте, WolfHound, Вы писали:

    WH>Так я и предложил.

    WH>Читай внимательней
    WH>За один день можно сделать и компилятор с отладчиком и ИДЕ с рефакторингами.
    WH>Только для этого правильные инструменты нужны. Над чем я и работаю.

    Рефакторинг нужен для каждого языка свой. Кто будет это делать ? Сейчас например тулы для рефакторинга вобщем случае не умеют определять эквивалентный код, это приходится делать руками. Ты сможешь сделать лучше ?

    I>>"Промышленное" нужно для массового применения, т.е. когда компилер будет широко использоваться.

    WH>Оно нужно всегда. Другое дело что на C# его достижение требует таких затрат что закачаешься.

    Не нужно и я объяснил почему — в мейнстриме узкое место ни разу не программисты.

    I>>Судя по тому, что на разных проектах используются и хорошо работают самопальные примитивные интерпретаторы-вычислителисовершенно

    WH>Это по тому что современными инструментами промышленного качества приемлемыми затратами не достичь.

    Если работают в реальных проектах значит это уже промышленный эффект.

    I>>не очевидно, что твое "промышленное" будет давать значительный профит.

    WH>Очевидно.

    Возможно только тебе одному.

    I>>Есть большая проблема — в случае с дсл нет инструментов автоматического рефакторинга,

    WH>Так я тебе и говорю, что при наличии инструментов это получается почти автоматом.

    Откуда тул узнает, что цепочка кода может быть преобразована в другую цепочку кода которая будет гораздо эффективнее ? ну и критерии эффективности в разных случаях будут разные.

    I>>Но это еще пол-беды. Качественный ДСЛ требует хороший функциональный базис, то есть серьезную мат-подготовку. Например linq тянет серьезный мат-бекграунд.

    WH>Может хватит считать программистов дураками?
    WH>linq может сделать любой толковый студент.

    Написать любую из функций в linq может почти любой студент. А что бы предложить такую концепцию как Linq нужен Erik Meijer.

    I>>В кратце это означает, что для создания такого ДСЛ тебе нужен Erik Meijer.

    WH>Erik Meijer нужен чтобы пропихнуть linq в компилятор C#.

    Ты хоть знаешь, что linq != query comprehension ? Первое даже без C# работает, а второе нужно много для чего и точно не является обязательным для linq.

    I>>То есть, по факту, твой подход незначительно превосходит студенческую поделку и требует всего в ~10 раз меньше времени.

    WH>То есть по факту ты не читаешь того что тебе пишут.

    На себя посмотри. RX по твоему тоже любой студент напишет ? Почему же миллионы девелоперов ждали 15 лет пока это сделал Erik Meijer ?

    I>>Даже много большей экономии недостаточно для перехода на ДСЛ для большинства проектов, тупо потому что программирование в них не является узким местом.

    WH>И что же в них является узким местом?

    В разных по разному, в некоторых тестирование, в некоторых маркетинг.

    WH>Вот сколько проектов видел, везде все упиралось в тормознутость программистов.


    WH>Включая сугубо прикладные проекты.

    Я не знаю, что такое "сугубо прикладные проекты"

    I>>Какие есть и других не будет в принципе.

    WH>У меня в группе было 2 человека которые могли писать. На соседних специальностях было еще несколько человек.

    Тебе "повезло", вот из моего выпуска почти все стали девелоперами и большАя часть уже "там" и многие даже свои фирмы пооткрывали.

    WH>Что там делали остальные я не знаю.

    WH>Может быть, тебе всегда попадаются остальные?

    Мы и так отфильтровываем примерно 90% кандидатов и это уже является слишком большой проблемой. Если и дальше задирать планку, как ты предлагаешь, то мы вообще никого не найдем. Классные программисты которые не шарят в бизнес-специфике или не готовы её осваивать не нужны и задаром. Брать их чисто ради девелоперских задач смысла не имеет, в перспективе такие работают год-два и им становится скучно.

    WH>А те, кто может писать обходят твою контору стороной?


    Разумеется по этой причине контора доминирует в своем сегменте, ага. Чисто между прочим — AT&T это даже не конкурент, а так, конкурентик, хотя он может выкупить нас с потрохами до десятого колена.

    I>> 2. минимальные навыки программирования == FizzBuzz

    WH>Ты мне тут пытаешься доказать что FizzBuzz не нужен.

    Я говорю о том, что бизнес-специфика важнее и навыки программирования на уровне FizzBuzz в большинстве случаев более чем достаточно.

    WH>>>Ты тут утверждал про какие-то фатальные проблемы с обратной совместимостью немерла.

    I>>Наверное я не правильно чего то сказал ну или где то не разобрался. Я взял код из статей, кое что попробовал, потом через какое то время в релизной версии немерла это отвалилось. Разбираться что к чему нет никакого желания, ибо тот же F# работает и не жужжит,
    WH>http://msdn.microsoft.com/en-us/library/hh416791%28v=vs.110%29.aspx
    WH>Может в немерле тоже что-то такое исправили?

    Я уже сказал, нет у меня желания разбираться в ваших проблемах.

    I>>а сами статьи вычитывать не вижу смысла, с другим языками это почему то не нужно, хватает и кода. Я так вообще все языки программирования выучил. Первая книга по ЯП которую я купил, это F# и основная причина в том,

    WH>Те прочитать статью про немерле слишком сложно, а купить целую книгу по F# нормально.
    WH>Опять двойные стандарты на марше.

    Ты как то хронически делаешь вывод по фрагментарной информации. Книгу я купил потому, что F# мне понравился. Про Nemerle я уже писал, что ничего не имею против языка но без макров. Макры кушайте сами.

    I>>а блокнота мне жалко, он ручной работы и в ём хорошая, плотная, бескислотная бумага которую жалко тратить на такие пустяки.

    WH>Чего?

    Эту строчку надо понимать буквально.

    I>>Реально check uniq должно уметь несколько сценариев, все я не могу перескахзать.

    WH>А ты попробуй.

    А чего пробовать, нам нужен набор абстракций, вроде монад хаскеля а не набор слов вроде check uniq или набор селекторов-фильтров

    I>>Некоторые объекты уникальны глобально, некоторые в пределах какого то объекта модели, некоторые в пределах какого то источника не привязаного четко к конкретному объекту модели. Это зависит от того насколько сильная разница между двумя структурами.

    WH>Хе-хе. Это не имеет никакого отношения к check uniq.

    Я говорю о том, что твой check uniq ни разу не решение, это уже пройденый этап, нужны абстрации.

    WH>Вся разница в том, как формировать таблицу.


    Формировать таблицу проще простого, вопрос в том, как упростить всю логику, а в ней самое проблемное место это уникальность объектов и всякие выборки-инстанцирование-связывание. Вот здесь и нужно решение.

    I>>В любом случае начинается хаос — девелопер должен на раз знать и понимать все CheckXXX и FindXXX (а также другие вещи) со всеми вырожденными случаями и оптимизациями.

    WH>Это разработчик ДСЛ не должен разводить зоопарк.

    А мы делали ровно так же как ты говорил — добали команду,добавили еще одну и тд и тд. не хочешь ли ты сказать, что надо полностю формализовать всю проблему ?
    Спасибо, не надо, фремворк работает без этого и благодаря рефакторигу в вижле есть способы борьбы со сложностью кода.

    WH>Ибо он реально не нужен.

    WH>Ты еще не показал ничего такого, для чего реляционной алгебры бы не хватило.

    Нужно высокоуровневое средство которое будет явно привязано к нашей модели
    1 если можно зарегить в ней например объект Node, то точно точно так же можно зарегить любой похожий объект.
    2 много типов регятся своим уникальным способом и это очевидно
    3 много разных констреинтов

    I>>С нашим подходм — изменения в одном месте не затрагивают другие места и это помогает решить многие проблемы связаные с отсутствие автоматического рефакторинга.

    WH>А это-то тут причем?
    WH>Какая разница добавить в язык новую конструкцию или новую функцию?
    WH>Да никакой.

    Я говорю про то, что это и есть причина хаоса. Нужно не только добавлять, но менять сам язык по мере формализации. А без инструментов рефакторинга это будет хаос.

    I>>ну и повторюсь, что бы предложить хороший функциональный базис нужны серьезная прокачка не девелоперских скилов, а математических. Например теория категорий и тд.

    WH>Нужен просто здравый смысл.
    WH>Не более того.

    Если здравый смыс включает в себя теорию категорий то я полностью согласен.

    I>>Это все дсл, только небошие оптимизации, например typeof, и я вижу что он ничем не хуже того что предложил ты, разница только в синтаксисе.

    I>>Оптимизации были нужны из за того, что вычислитель работает чз рефлексию. Он был написан еще на фреймворке 1.1.
    WH>И это вместо того чтобы типизировать код. Найти кучу ошибок. И сгенерировать очень быстрый код?
    WH>Генерировать код можно было и на 1.0
    WH>Генератор железный. Он без проблем может нагенарировать все специализации генериков сам.

    Это мелочевка, так, пятно пыли на плаще могучего Хорезма

    I>>Можно кое что упростить, но есть вещи вроде FindByPosAnd, FindIf и тд и тд.

    WH>Вот только они все выражаются через where.

    where дает ровно тот же результат, только вместо FindXXX будет один Where + пачки предопределенных предикатов. Всё, приехали.

    I>>Бывает. Для них точно такой же код, только сама логика указана другая. Точно так же будет вызваться Findxxx и тд и тд.

    WH>Продемонстрируй.
    WH>Хочу посмотреть, как вы колонки связываете.

    Все связывания это вызов встроеной функции, т.к. они все разные. Логика каждой написана в C# или на том же ДСЛ.

    I>>В кратце, ты отстаиваешь идею сильной зависимости от высококлассных специалистов только не хочешь этого признавать.

    WH>Я отстаиваю идею о том, что прибыль могут генерировать только сильные.
    WH>Остальные одни убытки. Не считая распил-проектов.

    I>>Из теории риск-менеджмента известно, что риски берутся аккурат из таких вот сильных зависимостей.

    I>>То есть, это именно то с чем бизнес борется любыми способами, следовательно на большинстве проектов это в принципе неприемлемо, ибо основной приоритет это бизнес-специфика.
    WH>Бизнес не борется с рисками. Бизнес ими управляет.

    Это одно и то же.

    WH>И тут мы имеем вот что:

    WH>Твой вариант: Гарантированный срыв сроков. Куча багов. Раздутый до небес бюджет.

    И потому контора нумер один в своем сегменте ? Браво !

    WH>Мой вариант: Быстрое и качественное решение проблемы. Но придется повозиться с подбором персонала.


    То есть, все таки зависимость от ЧФ есть и есть связаные с ней риске ? Тебе не кажется, что все студенты первого курса искаропки должны уметь на раз как минимум монады хаскеля ?

    WH>Хотя если я сейчас кину клич о разработке на ДСЛ, сбежится куча очень сильного народа.


    Конечно. Лисперы до сих пор так и ищут. Это ничего не доказывает.
    Re[43]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 30.04.12 21:42
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>Хотя если я сейчас кину клич о разработке на ДСЛ, сбежится куча очень сильного народа.

    WH>Я гарантирую это.
    WH>Ибо всех их C# с жабой достали.

    +1

    Только если вдруг ситуация изменится и ДСЛ-и начнут использовать повсеместно, то проблема с кадрами возникнет снова. К сожалению количество мозга на земле величина постоянна, а количество людей увеличивается.

    В прочем, ДСЛ-подход один фиг выгоднее. Грамотно ограниченный ДСЛ позволит использовать людей со слабой квалификацией и ограниченными возможностями. Фрэймворки и библиотеки такого же эффекта не дадут. А уж о решении проблем в лоб, что характерно для ламеров, вообще завали любую сложную задачу.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[44]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 01.05.12 09:51
    Оценка:
    Здравствуйте, alex_public, Вы писали:

    _>Ммм, а вот тут я бы разделил реализацию и придумывание самих принципов.


    Там единственный принцип — использование функций высшего порядка. 90% функций использованных в линке были были известны со времен царя гороха (использовались в раннем ML). Почти все они являются абстрагированием тех или иных видов циклов.

    Все что было превнесено в linq с точки зрения ФВП — это join. И то он получился на редкость кривым.

    _>Реализация linq на нормальных языках не представляется мне сложной задачей вообще. Вот например http://habrahabr.ru/post/142632/ человек на коленке сделал разновидность для C++.


    Мил человек. В линке одна из самых важных составляющих — это возможность автоматически преобразовать код в его AST. Так вот это на С++ делать запаришся, так как язык убог неимоверно.

    Да и ФВП повторены крайне хренов. И виноват в этом не автор библиотеки, а Страуструп и ко. Уровень синтаксического шума зашкаливает. Если взять пример по сложнее, то он превратится в кашу. И это еще с использованием С++11. На старом С++ (которым насиловали мозг более 10 лет) и это повторить не удастся. Получится полный урод.

    Ну, и библиотека пока что еще только игрушка нет selectMany, join, ThenBy, ... Хотя это конечно это просто объем работы.

    И наконец синтаксис. Повторить синтаксис линка на С++ нельзя в принципе. И пока что нигде нельзя. Потому как тут нужно качественное расширение синтаксиса языка библиотеками. И возможность бесшовной композиции разных языков.

    _>Если же говорить о продумывание принципов, то тут всё гораздо сложнее. Хотя например конкретно в случае linq его авторы тоже не особо потрудились, взяв всё нужное из sql. А вот уже за sql стоят вполне определённые наработки, которые продумывались явно не за пару минут.


    К sql-ю линк имеет очень отдаленное отношение. Автор, несомненно, взял за основу линк-паттерн описанный в стандарте шарпа и немного его "доработал" (в основном упростил). Линк же, повторюсь, это библиотека функций высшего порядка. И базируется она на сто лет назад обкатанных идиомах и паттернах.

    То что линк похож на язык — это следствие применения так называемого "свободного интерфейса" (fluent interface). Свободный интерфейс — это один из способов реализовать встроенный ДСЛ в языке который на большее неспособен. Заключается он в протаскивании контекста "через точку", т.е. в записи выражения ДСЛ-я в виде последовательности вызовов методов в ООЯ. Именно потому что используется ДЧСЛ, кстати, разница между синтаксисом линка и линк-паттерном (свободным интерфейсом) не такая уж убийственная (правда на более сложных запросах она становится критической).

    В общем, усилия автора этой либы с точки зрения проектирования были ничтожными. Он только попытался перевести на крайне ограниченный язык идиомы давно известные в более развитых языках.

    Но таки да, на проектирование ДСЛ-я неизбежно уходят силы. Создать хреновый ДСЛ так же легко как создать хреновую библиотеку. Но это же верно для всего что делает программист. Создать говнокод намного проще чем хорошую реализацию.

    Применение ДСЛ-ей хорошо хотя бы тем, что заставляет задумываться (прорабатывать) над моделью вычислений решаемой задачи и над лингвистическими идиомами используемыми при описании решений.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[44]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 01.05.12 10:11
    Оценка:
    Здравствуйте, Ikemefula, Вы писали:

    I>Рефакторинг нужен для каждого языка свой. Кто будет это делать ? Сейчас например тулы для рефакторинга вобщем случае не умеют определять эквивалентный код, это приходится делать руками. Ты сможешь сделать лучше ?


    Несомненно!

    Некоторые виды рефакторинга можно сделать доступными из коробки. Например, рефакторинги переименования разных символов будут доступны сразу, так как единственное что для них нужно — это использование единого механизма управления символами и связывания имен (таблицы символов).

    Создание других рефакторингов можно будет резко упростить.

    Сейчас даже в самых современных средствах рефакторинга создание нового рефакторинга (плагина) выливается в жуткий императивный код манипулирующий деревьями.
    Только перевод этого дела на квази-цитирование уже упростит жизнь во много раз.

    I>>>"Промышленное" нужно для массового применения, т.е. когда компилер будет широко использоваться.

    WH>>Оно нужно всегда. Другое дело что на C# его достижение требует таких затрат что закачаешься.

    I>Не нужно и я объяснил почему — в мейнстриме узкое место ни разу не программисты.


    Очень приятно увидеть человека знающий все проблемы мэйнстрима (а это, кстати, не одно и то же с миллионом мух?).
    Хочется пожелать ему — отучаться говорить за всех.

    I>>>Судя по тому, что на разных проектах используются и хорошо работают самопальные примитивные интерпретаторы-вычислителисовершенно

    WH>>Это по тому что современными инструментами промышленного качества приемлемыми затратами не достичь.

    I>Если работают в реальных проектах значит это уже промышленный эффект.


    От бедности, в 60-ых в проектах отлично работало кодирование в машкодах. Что это доказывает?

    I>То есть, все таки зависимость от ЧФ есть и есть связаные с ней риске ? Тебе не кажется, что все студенты первого курса искаропки должны уметь на раз как минимум монады хаскеля ?


    Он тебе раз 10 повторил — опора на вменяемые кадры. Для использования ДСЛ нужно просто быть вменяемым программистом. Для их разработку нужно к тому же быть вменяемым архитектором ПО.

    Сейчас это не так, потому что у людей в руках каменные молотки. Причем без инструкции по эксплуатации (внятных методик).

    Первое (вопрос наличия инстурментов) — это вопрос реализации. Это большой объем очень сложной работы. Ее средние программисты сделать не смогут — 100%.
    Второй — это вопрос образования и пиара. Было бы замечательно, если бы наши вузы перестали убивать новые поколения программистов, а начали бы обучать тем самым методикам. В том числе и методикам разработки и эксплуатации ДСЛ-ей при разработке ПО.

    WH>>Хотя если я сейчас кину клич о разработке на ДСЛ, сбежится куча очень сильного народа.


    I>Конечно. Лисперы до сих пор так и ищут. Это ничего не доказывает.


    Лисп сложен для рядового пользователя и оторван от жизни. Хотя то что он с успехом применяется вот уже 50 лет говорит о том, что он явно не пустышка. Вот в мире явы сейчас набирает обороты Closur, например.

    Главная проблема Лиспа — отсутствие синтаксиса. По сути программисту предлагается писать в АСТ. Причем АСТ выраженном в виде списков. Читаемость такого кода довольно низка.

    Плюс Лисп — это динамически типизированный язык. И в мир статики он вписывается крайне хреново.

    Если же создать инструмент который предоставлял бы легкий путь создания языковых расширений и внешних ДСЛ-ей для типизированного мира, причем с блэкджеком и шлюхами (т.е. с поддержкой IDE, отладки, и т.п.), то в сочетании с внятными методиками это могло бы изменить положение дел. Ведь то же ФП просочилось в мэйнстрим! Даже С++ обзавелся подобием лямбд.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[45]: Языки общего назначения не имеют смысла!
    От: alex_public  
    Дата: 01.05.12 14:45
    Оценка: -1 :)
    Здравствуйте, VladD2, Вы писали:

    VD>Там единственный принцип — использование функций высшего порядка. 90% функций использованных в линке были были известны со времен царя гороха (использовались в раннем ML). Почти все они являются абстрагированием тех или иных видов циклов.


    Да вообще все базовые строительные кирпичики известны давно. Весь вопрос в том какие взять для решения задачи. В случае конкретной задачи обычно проблем нет в принципе. В случае же разработки некого универсального решения, нам надо взять такой набор кирпичиков, что бы он покрыл все возможные задачи, но строго не больше этого, иначе получится неудобно пользоваться.

    Для обработки последовательностей данных эту задачу когда-то решили авторы sql.

    VD>Мил человек. В линке одна из самых важных составляющих — это возможность автоматически преобразовать код в его AST. Так вот это на С++ делать запаришся, так как язык убог неимоверно.


    Эта особенность как раз всю кривизну и привносит, причём при отсутствие реальной необходимости.

    В C++ это вполне можно привнести, но тогда потеряются преимущества полноценной статической типизации — не надо такого.

    VD>Ну, и библиотека пока что еще только игрушка нет selectMany, join, ThenBy, ... Хотя это конечно это просто объем работы.


    Вообще то там уже есть возможности которых нет и в самом .net linq. А уж если говорить о скорости, то... )))

    VD>В общем, усилия автора этой либы с точки зрения проектирования были ничтожными. Он только попытался перевести на крайне ограниченный язык идиомы давно известные в более развитых языках.


    Так я же вроде именно это и сказал — реализация уже известных схем обычно не представляет труда.

    Далее, вообще то все эти известные идиомы давно были ещё в древнем C++. Все нужные функции есть в том же stl. Там есть map, fold, filter и т.п, только под другими именами.

    Автор же этого решения просто привнёс понравившийся ему linq (или лучше говорить sql?) стиль записи. Причём его решение позволяет избежать создания промежуточных элементов.

    Кстати, можно тут http://habrahabr.ru/post/142657/ посмотреть подробнее. Особенно был интересен пункт про производительность. Надо было бы ему посоветовать ещё провести сравнительные тесты с linq вариантом.)))

    VD>Но таки да, на проектирование ДСЛ-я неизбежно уходят силы. Создать хреновый ДСЛ так же легко как создать хреновую библиотеку. Но это же верно для всего что делает программист. Создать говнокод намного проще чем хорошую реализацию.


    Ага, причём не малые силы. Так что наверное это имеет смысл только если этот наш dsl можно будет использовать во многих задачах.

    VD>Применение ДСЛ-ей хорошо хотя бы тем, что заставляет задумываться (прорабатывать) над моделью вычислений решаемой задачи и над лингвистическими идиомами используемыми при описании решений.


    Удобных инструментов для этого не видно. Кстати, я тут попробовал перебрать в памяти... Пожалуй местом с максимальной концентрацией dsl'ей является как ни странно Boost.
    Re[45]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 01.05.12 16:29
    Оценка: :))
    Здравствуйте, VladD2, Вы писали:

    VD>Некоторые виды рефакторинга можно сделать доступными из коробки. Например, рефакторинги переименования разных символов будут доступны сразу, так как единственное что для них нужно — это использование единого механизма управления символами и связывания имен (таблицы символов).


    Рефакторинг — зло. Чем скорее человечество забудет это гнусное слово, тем лучше.

    VD>Сейчас даже в самых современных средствах рефакторинга создание нового рефакторинга (плагина) выливается в жуткий императивный код манипулирующий деревьями.

    VD>Только перевод этого дела на квази-цитирование уже упростит жизнь во много раз.

    Только не это! И сейчас-то уже спасу нет от рефакторинга, а если его еще и проще делать будет, то совсем беда.

    VD>Он тебе раз 10 повторил — опора на вменяемые кадры. Для использования ДСЛ нужно просто быть вменяемым программистом. Для их разработку нужно к тому же быть вменяемым архитектором ПО.


    Я бы сказал, для разработки DSL нужно куда как меньше интеллекта чем для современных чрезмерно переусложненных ООП-методологий. Так что людей в индустрии, способных с этим справиться, уже и так предостаточно.

    VD>Сейчас это не так, потому что у людей в руках каменные молотки. Причем без инструкции по эксплуатации (внятных методик).


    Даже существующих инструментов достаточно. Чего нет, так это книг с баззвордами и агрессивных евангелистов (как у TDD или у того же мерзопакостного, ненавистного рефакторинга).

    VD>Первое (вопрос наличия инстурментов) — это вопрос реализации. Это большой объем очень сложной работы. Ее средние программисты сделать не смогут — 100%.


    Могут, ничего там сложного нет в большинстве случаев.

    VD>Второй — это вопрос образования и пиара. Было бы замечательно, если бы наши вузы перестали убивать новые поколения программистов, а начали бы обучать тем самым методикам. В том числе и методикам разработки и эксплуатации ДСЛ-ей при разработке ПО.


    Наши ВУЗы даже ООП учить пока не научились, куда уж им через поколения перескакивать.

    VD>Лисп сложен для рядового пользователя и оторван от жизни.


    Он не сложен, он всего лишь непривычен для тех, кого испортили другими языками. Насчет оторванности от жизни тоже не замечал.

    VD>Главная проблема Лиспа — отсутствие синтаксиса.


    Это не проблема, это преимущество. Синтаксис языкам вредит, отвлекает от сути.

    VD> По сути программисту предлагается писать в АСТ. Причем АСТ выраженном в виде списков. Читаемость такого кода довольно низка.


    Только первые десять минут знакомства с языком. Потом все просто и естественно.

    VD>Плюс Лисп — это динамически типизированный язык. И в мир статики он вписывается крайне хреново.


    Это не обязательное свойство Лиспа, он может быть как угодно типизированным (см. Shen, бывший Qi).
    Re[46]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 01.05.12 18:06
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    O> Рефакторинг — зло. Чем скорее человечество забудет это гнусное слово, тем лучше.

    И что вместо него?
    Вот поменялись у нас требования.
    В существующий код они не вписываются.
    Что дальше?

    O> Я бы сказал, для разработки DSL нужно куда как меньше интеллекта чем для современных чрезмерно переусложненных ООП-методологий. Так что людей в индустрии, способных с этим справиться, уже и так предостаточно.

    +1000
    Правда Ikemefula хочет работать с теми, для кого FizzBuzz проблема...
    А они вообще ничего не могут.

    VD>>Сейчас это не так, потому что у людей в руках каменные молотки. Причем без инструкции по эксплуатации (внятных методик).

    O> Даже существующих инструментов достаточно.
    Не достаточно. Трудозатраты слишком велики.

    O>Чего нет, так это книг с баззвордами и агрессивных евангелистов (как у TDD или у того же мерзопакостного, ненавистного рефакторинга).

    Это да.

    VD>>Первое (вопрос наличия инстурментов) — это вопрос реализации. Это большой объем очень сложной работы. Ее средние программисты сделать не смогут — 100%.

    O> Могут, ничего там сложного нет в большинстве случаев.
    Это, смотря на каком уровне делать.
    Если на том уровне что ты тут показывал, то там все просто.
    А если нужны качественные сообщения об ошибках.
    Предметно-ориентированные системы типов.
    Вывод типов, понимающий перегрузки.
    ИДЕ и коробки.
    ...
    То тут все совсем не просто.

    O> Он не сложен, он всего лишь непривычен для тех, кого испортили другими языками. Насчет оторванности от жизни тоже не замечал.

    Он динамически типизирован.
    Одно это уже делает его оторванным по самые не балуйся.

    Кстати ты обещал продемонстрировать невообразимую крутизну макросов, которые генерируют другие макросы.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[46]: Языки общего назначения не имеют смысла!
    От: netch80 Украина http://netch80.dreamwidth.org/
    Дата: 02.05.12 03:54
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    VD>>Некоторые виды рефакторинга можно сделать доступными из коробки. Например, рефакторинги переименования разных символов будут доступны сразу, так как единственное что для них нужно — это использование единого механизма управления символами и связывания имен (таблицы символов).

    O> Рефакторинг — зло. Чем скорее человечество забудет это гнусное слово, тем лучше.

    Оч-чень интересно.
    Есть этому обоснование?
    Вы можете предложить другой метод изменения структуры программы в нужную сторону с сохранением всей известной функциональности?
    The God is real, unless declared integer.
    Re[47]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 02.05.12 09:02
    Оценка:
    Здравствуйте, netch80, Вы писали:

    O>> Рефакторинг — зло. Чем скорее человечество забудет это гнусное слово, тем лучше.


    N>Оч-чень интересно.

    N>Есть этому обоснование?

    Есть, даже два: product branches и merge. Неоднократно уже наблюдал такую картину — приходит в проект новый team lead, весь из себя с горящими глазами, баззвордами во все стороны так и швыряется. И начинает его команда рефакторить фанатично все, что под руку подвернется. Причем, работает эта команда над какой-то одной частью функциональности, а в компании еще пятьдесят других команд, и код для всех общий. И только тогда, когда строго по регламенту, через месяц, все product branch-и в trunk сливают, до несчастных доходит, что за урод этот евангелист, и куда его надо послать.

    Что характерно, к приходу следующего евангелиста (уже в другую команду, их много, опытом делиться не научились как следует) история повторяется.

    И это в ынтырпрайзе. В open source же все еще хуже. Приползает очередной такой юный фанатик Фаулера, правдами и неправдами получивший право коммита, и начинает радостно рефакторить (ради самого рефакторинга, без каких либо к тому показаний). Потом сотни или даже тысячи людей, работающие над своими патчами и регулярно rebase-ящие свои репозитории до trunk-а этого фанатика и его матушку склоняют на десятках разных языков и с разной степентю цинизма. Хорошо это?

    N>Вы можете предложить другой метод изменения структуры программы в нужную сторону с сохранением всей известной функциональности?


    Переписывать. По-старинке. Аккуратно, вдумчиво, ручками, с полным осознанием ответственности за последствия. Без всяких там автоматизированных тулзов, которые разом тонны кода перелопачивают.
    Re[45]: Языки общего назначения не имеют смысла!
    От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
    Дата: 02.05.12 09:06
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Некоторые виды рефакторинга можно сделать доступными из коробки. Например, рефакторинги переименования разных символов будут доступны сразу, так как единственное что для них нужно — это использование единого механизма управления символами и связывания имен (таблицы символов).


    Прикольная фенька но не фатально.

    VD>Создание других рефакторингов можно будет резко упростить.


    То есть, я пишу ДСЛ и я же должен буду рефакторинги писать ? Кушайте сами.

    VD>Сейчас даже в самых современных средствах рефакторинга создание нового рефакторинга (плагина) выливается в жуткий императивный код манипулирующий деревьями.

    VD>Только перевод этого дела на квази-цитирование уже упростит жизнь во много раз.

    Ну то есть тихо ненавязчиво переложить разработку среды на того кто возьмется за ДСЛ

    I>>Не нужно и я объяснил почему — в мейнстриме узкое место ни разу не программисты.


    VD>Очень приятно увидеть человека знающий все проблемы мэйнстрима (а это, кстати, не одно и то же с миллионом мух?).


    Все не знаю. Наибольшее влияние на бизнес оказывает менеджмет. Далее — маркетинг. Уже потом инженеры, дизайнеры и тд, из которых часть админов, часть безопасников, часть тестировщиков, аналитиков и тд.

    Это самый лучший расклад. Все остальные еще хуже. Например берем знакомую тебе полиграфию. Доход от печатной продукции. Программинг всего лишь обслуживающая система. Опаньки !

    I>>Если работают в реальных проектах значит это уже промышленный эффект.

    VD>От бедности, в 60-ых в проектах отлично работало кодирование в машкодах. Что это доказывает?

    Доказывает, что для тех потребностей хватало машинных кодов и никто не умер от недостатка немерле.
    Ты сам то подумай, Лисп уже был, а писали и в машинных кодах, потом на асме, потом на фортранах-коболах, потом на си.
    История Лиспа тебя ничему не научила ? Сочувствую.

    I>>То есть, все таки зависимость от ЧФ есть и есть связаные с ней риске ? Тебе не кажется, что все студенты первого курса искаропки должны уметь на раз как минимум монады хаскеля ?


    VD>Он тебе раз 10 повторил — опора на вменяемые кадры. Для использования ДСЛ нужно просто быть вменяемым программистом. Для их разработку нужно к тому же быть вменяемым архитектором ПО.


    Не ясно, что такое вменяемые и где их брать, как готовить. Для бизнеса очень хорошо брать людей "на вырост", то есть, чем моложе, тем лучше. Чему их готовить ? Сразу монады хаскеля вливать в головы ?

    VD>Второй — это вопрос образования и пиара. Было бы замечательно, если бы наши вузы перестали убивать новые поколения программистов, а начали бы обучать тем самым

    методикам. В том числе и методикам разработки и эксплуатации ДСЛ-ей при разработке ПО.

    Ну так вы с Wolfhoundon молчите, как партизаны, и не говорите кто же такой вменяемый программист. А между тем бизнес-специфика выражается чуть ли не линейным кодом, максимум круд, где сложность в написании запроса, для чего уже есть все необходимые инструменты.

    VD>Главная проблема Лиспа — отсутствие синтаксиса. По сути программисту предлагается писать в АСТ. Причем АСТ выраженном в виде списков. Читаемость такого кода довольно низка.


    Вижу, есть сдвиги — всего пару лет назад ты чуть не с пеной кидался на людей у кого были такие же аргументы
    Re[48]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 02.05.12 09:46
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    N>>Вы можете предложить другой метод изменения структуры программы в нужную сторону с сохранением всей известной функциональности?


    O> Переписывать. По-старинке. Аккуратно, вдумчиво, ручками, с полным осознанием ответственности за последствия. Без всяких там автоматизированных тулзов, которые разом тонны кода перелопачивают.


    А. Все ясно. Для любимой игрушки рефакторинг не сделали, так мы этот рефакторинг во вселенское зло запишем.

    Не серьезно'c.

    В реальной жизни бывает, что дизайн меняется или просто имя полю дали не самое красивое. Тратить на это часы или даже дни — не позволительная роскошь.

    Мощный инструмент, порою, может сэкономить очень много времени и повысить уровень задачи. Но это никак не отменяет необходимости средств рефакторинга. Лучше когда есть и мощный инструмент, и мощные средства рефакторинга.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[48]: Языки общего назначения не имеют смысла!
    От: netch80 Украина http://netch80.dreamwidth.org/
    Дата: 02.05.12 09:47
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    N>>Вы можете предложить другой метод изменения структуры программы в нужную сторону с сохранением всей известной функциональности?


    O> Переписывать. По-старинке. Аккуратно, вдумчиво, ручками, с полным осознанием ответственности за последствия. Без всяких там автоматизированных тулзов, которые разом тонны кода перелопачивают.


    Я под рефакторингом подразумеваю все варианты преобразований с сохранением функциональности, не обязательно автоматом, поэтому мне такой праведный гнев просто неуместен. Но если бы был автомат — то применил бы и автомат. А почему так сразу "тонны" кода? Обычно, мне кажется, меняются только определённые места, и не делается незапрошенных прогонок по всему коду.

    O> Есть, даже два: product branches и merge. Неоднократно уже наблюдал такую картину — приходит в проект новый team lead, весь из себя с горящими глазами, баззвордами во все стороны так и швыряется. И начинает его команда рефакторить фанатично все, что под руку подвернется. Причем, работает эта команда над какой-то одной частью функциональности, а в компании еще пятьдесят других команд, и код для всех общий. И только тогда, когда строго по регламенту, через месяц, все product branch-и в trunk сливают, до несчастных доходит, что за урод этот евангелист, и куда его надо послать.


    Знаешь, есть такая поговорка: дай дураку нефритовый стебель в руки, он и его сломает
    Тут больша виновата команда, что не одернула его. Потому что рефакторинг допустим и нужен, но только тогда, когда не предполагается таких вот мержей втихую в одном месте без корреляции с остальными.
    А ещё больше виновата контора в целом — что не контролирует процесс.

    O> Что характерно, к приходу следующего евангелиста (уже в другую команду, их много, опытом делиться не научились как следует) история повторяется.


    Так виноват ли молоток, что им закручивают винты? Может, таки с людьми надо разобраться?

    O> И это в ынтырпрайзе. В open source же все еще хуже. Приползает очередной такой юный фанатик Фаулера, правдами и неправдами получивший право коммита, и начинает радостно рефакторить (ради самого рефакторинга, без каких либо к тому показаний). Потом сотни или даже тысячи людей, работающие над своими патчами и регулярно rebase-ящие свои репозитории до trunk-а этого фанатика и его матушку склоняют на десятках разных языков и с разной степентю цинизма. Хорошо это?


    Нет, не хорошо. Но см. выше.

    Вы как-то очень странно относитесь именно к средствам. Вот Вам в качестве обратного примера — sendmail. Там явно сидят Ваши сторонники — 30 лет развития без единого рефакторинга. Почитайте код, например, getrequests(), sendall(), dropenvelope(), затем залезьте в alias.c. (Приготовьте противорвотное, пригодится.) Если бы были шнобелевские премии для кодеров, давно бы уже автор этого кода имел всю грудь в орденах. Может, надо всё-таки начать думать о том, что иногда надо и менять структуру, даже если кому-то придётся адаптироваться?
    The God is real, unless declared integer.
    Re[47]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 02.05.12 10:01
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    O>> Рефакторинг — зло. Чем скорее человечество забудет это гнусное слово, тем лучше.

    WH>И что вместо него?

    Ручками, аккуратно, вдумчиво, страдая и мучаясь. Потому как если это будет слишком легко делать, этим будут злоупотреблять.

    WH>Вот поменялись у нас требования.

    WH>В существующий код они не вписываются.
    WH>Что дальше?

    Переписывать. Без фанатизма. Без постоянного переименовывания всего подряд.

    WH>Правда Ikemefula хочет работать с теми, для кого FizzBuzz проблема...

    WH>А они вообще ничего не могут.

    Вот-вот, я не представляю, какая вообще польза от таких может быть. Ни разу живьем их в реальной работе не видел (а видел очень много всякого), какие-то они мифические, все про них пишут, и никто показать не может.

    Хотя вру, видел однажды последствия их работы. Индийский аутсорсинг. За ними, понятное дело, потом полностью с нуля все переписывали, так что экономическая выгода крайне сомнительна.

    VD>>>Сейчас это не так, потому что у людей в руках каменные молотки. Причем без инструкции по эксплуатации (внятных методик).

    O>> Даже существующих инструментов достаточно.
    WH>Не достаточно. Трудозатраты слишком велики.

    По сравнению с альтернативой (делать все без DSL) — не так уж и велики.

    VD>>>Первое (вопрос наличия инстурментов) — это вопрос реализации. Это большой объем очень сложной работы. Ее средние программисты сделать не смогут — 100%.

    O>> Могут, ничего там сложного нет в большинстве случаев.
    WH>Это, смотря на каком уровне делать.
    WH>Если на том уровне что ты тут показывал, то там все просто.

    Обычно уровень нужен вообще тупейший. То, что на Лиспе делается макрой в десяток строк кода. Более сложные DSL крайне редко встречаются. DSL очень легко получаются комбинацией элементов уже ранее написанных DSL, так что каждый новый получается проще предыдущего.

    WH>А если нужны качественные сообщения об ошибках.


    Какие с этим проблемы? Ассертов в макре расставить, и все.

    WH>Предметно-ориентированные системы типов.


    С системами типов никаких проблем нет, если есть Пролог.

    WH>Вывод типов, понимающий перегрузки.


    Опять же, с Прологом не проблема.

    WH>ИДЕ и коробки.


    Не убежден в ценности IDE для DSL-ей. Много там у нас IDE, поддерживающих SQL? Не особо. И никто не жалуется. Много IDE для навороченных DSL-ей в разного рода CAD-ах? Для того же автокада, для инструментов Cadence? Ничего нет, и народ не жалуется, пишут миллионы строк кода на DSL без всяких IDE.

    IDE нужны для работы с гигантскими фреймворками, для жаба-ынтырпрайза всякого. То есть для того, что с массовым введением DSL станет просто ненужным.

    WH>...

    WH>То тут все совсем не просто.

    А не надо усложнять. Как по мне, так большинству DSL и синтаксиса-то никакого не надо (но понимаю прекрасно, что лисперу по этому пункту со всеми остальными никогда не договориться). Тем, кому надо, часто больше подходит графическое представление (а тут для нас уже Microsoft расстаралась).

    O>> Он не сложен, он всего лишь непривычен для тех, кого испортили другими языками. Насчет оторванности от жизни тоже не замечал.

    WH>Он динамически типизирован.

    Как и подавляющее большинство очень популярных и очень жизненных языков. Кто жизненнее — популярнейшие Python, Javascript, Ruby, Perl, Shell-ы всякие или мертвый Haskell и унылая ынтырпрайзная Java? Не такой уж и простой вопрос.

    WH>Одно это уже делает его оторванным по самые не балуйся.


    Я в эту типизированную религию не верю, вверх и вниз по лямбда-кубу налазился в свое время, понял, что тлен это все и суета.

    WH>Кстати ты обещал продемонстрировать невообразимую крутизну макросов, которые генерируют другие макросы.


    Да, помню. Времени постоянно не хватает. В ближайшее время нарисую пример.
    Re[46]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 02.05.12 10:15
    Оценка:
    Здравствуйте, Ikemefula, Вы писали:

    VD>>Создание других рефакторингов можно будет резко упростить.

    I>То есть, я пишу ДСЛ и я же должен буду рефакторинги писать ? Кушайте сами.
    Если написание рефакторинга займет десяток строк то в чем проблема?

    I>Это самый лучший расклад. Все остальные еще хуже. Например берем знакомую тебе полиграфию. Доход от печатной продукции. Программинг всего лишь обслуживающая система. Опаньки !

    А сколько та же контора использует софта, который пишется конторой, которая только софт и пилит?
    Опаньки!

    I>Доказывает, что для тех потребностей хватало машинных кодов и никто не умер от недостатка немерле.

    Не доказывает.
    Просто тогда из-за немощности машин даже ассемблер был роскошью.

    I>Ты сам то подумай, Лисп уже был, а писали и в машинных кодах, потом на асме, потом на фортранах-коболах, потом на си.

    I>История Лиспа тебя ничему не научила ? Сочувствую.
    Ох. Лисп динамически типизированное тормизилово.
    А в те годы каждый такт был на счету. Ибо стоил на несколько порядков дороже, чем сейчас.
    Так же у лиспа есть еще одна огромная проблема: Отсутствие синтаксиса.
    Одно это от него отталкивает кучу народа.

    Так что опыт лиспа учтен. Ошибки повторены не будут.

    А что касается мета-программирования то посмотри, сколько шума вокруг Ruby on Rails.
    25 700 000 результатов в гугле.
    А ведь это ДСЛ.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[49]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 02.05.12 10:16
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    O>> Переписывать. По-старинке. Аккуратно, вдумчиво, ручками, с полным осознанием ответственности за последствия. Без всяких там автоматизированных тулзов, которые разом тонны кода перелопачивают.


    VD>А. Все ясно. Для любимой игрушки рефакторинг не сделали, так мы этот рефакторинг во вселенское зло запишем.


    Мой основной рабочий инструмент — C++. А для него какие-то падлы рефакторинг автоматический сделали.

    VD>В реальной жизни бывает, что дизайн меняется или просто имя полю дали не самое красивое. Тратить на это часы или даже дни — не позволительная роскошь.


    Вот этим любителям все переименовывать просто красоты ради я бы вообще все выступающие части тела поотрубал. Самый гнусный, мерзкий вариант рефакторинга. И хуже всего, когда это не проявляется сразу в виде merge conflict, когда автоматический merge легко проходит и потом ошибки приходится отлавливать хорошо если при компиляции (а бывает что и только в рантайме вылезет). И все ради какой-то идиотской красоты идентификатора?

    VD>Мощный инструмент, порою, может сэкономить очень много времени и повысить уровень задачи.


    Я против решения этой задачи вообще. Так что вполне естественно, что я против и инструментов для этого предназначенных.

    VD> Но это никак не отменяет необходимости средств рефакторинга.


    Какое громкое слово — "необходимость"! А я вот подумываю о необходимости выдачи лицензий на отстрел проповедников идей рефакторинга. Начал бы лично с Фаулера, не смотря на все его заслуги на поприще популяризации DSL.

    VD> Лучше когда есть и мощный инструмент, и мощные средства рефакторинга.


    Хуже. Слишком много кругом дураков. Ленивых дураков. Когда у них инструмента нет, они и рефакторить не лезут. А дай им инструмент, и дураков потом не остановишь. Тем более что рефакторинг идеально подходит для имитации бурной деятельности, а это дураки очень любят.
    Re[49]: Языки общего назначения не имеют смысла!
    От: oldjackal Россия  
    Дата: 02.05.12 10:24
    Оценка:
    Здравствуйте, netch80, Вы писали:

    N>Я под рефакторингом подразумеваю все варианты преобразований с сохранением функциональности, не обязательно автоматом, поэтому мне такой праведный гнев просто неуместен.


    Не обязательно. Есть вокруг до фига преисполненных энтузиазма идиотов, которые это и без автомата делают. Поубивал бы.

    N> Но если бы был автомат — то применил бы и автомат. А почему так сразу "тонны" кода? Обычно, мне кажется, меняются только определённые места, и не делается незапрошенных прогонок по всему коду.


    Например, изменение имени какого либо класса или метода, используемого во множестве модулей.

    N>Знаешь, есть такая поговорка: дай дураку нефритовый стебель в руки, он и его сломает


    А дураков слишком много. Лучше им стеблей не давать.

    N>Тут больша виновата команда, что не одернула его.


    Не положено в таких местах начальство одергивать.

    N> Потому что рефакторинг допустим и нужен, но только тогда, когда не предполагается таких вот мержей втихую в одном месте без корреляции с остальными.


    Рефакторинг допустим только тогда, когда вообще никаких merge-ей не предполагается в принципе. Когда все тысячи разработчиков дружно гадят в один общий trunk. Ну прямо таки идеал организации разработки, не находите?

    N>А ещё больше виновата контора в целом — что не контролирует процесс.


    Процесс-то как раз устоявшийся за десятилетия, отлаженный как часы. И никакого рефакторинга не предполагающий по определению. Конечно же, на ошибках учиться надо, это их вина, что после первого такого евангелиста не вкличили в интервью вопросы об отношении к рефакторингу.

    O>> Что характерно, к приходу следующего евангелиста (уже в другую команду, их много, опытом делиться не научились как следует) история повторяется.


    N>Так виноват ли молоток, что им закручивают винты? Может, таки с людьми надо разобраться?


    Надо, надо. Надо энтузиастов рефакторинга сажать в клетки и размножаться не давать.

    N>Вы как-то очень странно относитесь именно к средствам. Вот Вам в качестве обратного примера — sendmail. Там явно сидят Ваши сторонники — 30 лет развития без единого рефакторинга.


    Там с самого начала была идиотская архитектура. Не очень хороший пример.

    N> Может, надо всё-таки начать думать о том, что иногда надо и менять структуру, даже если кому-то придётся адаптироваться?


    Иногда. С частотой глобальных катаклизмов. С тотальным code freeze и тому подобными жесткими мерами. А не как адепты этой религии пропагандируют, что мол "когда тебе нечем заняться, порефакторь-ка чего нибудь".
    Re[46]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 02.05.12 10:38
    Оценка:
    Здравствуйте, Ikemefula, Вы писали:

    VD>>Создание других рефакторингов можно будет резко упростить.


    I>То есть, я пишу ДСЛ и я же должен буду рефакторинги писать ? Кушайте сами.


    Или ты, или кто-то еще. Например, тот кто твой ДСЛ использует. Задача создания рефакторингов упростится. Ее сможет решать любой вменяемый программист.

    VD>>Сейчас даже в самых современных средствах рефакторинга создание нового рефакторинга (плагина) выливается в жуткий императивный код манипулирующий деревьями.

    VD>>Только перевод этого дела на квази-цитирование уже упростит жизнь во много раз.

    I>Ну то есть тихо ненавязчиво переложить разработку среды на того кто возьмется за ДСЛ :)))


    На того кому нужно, или на того кому поручат. И не среды, а мелких кусочков кода описывающих рефакторинги. Типа найти такой паттерн, заменить на такое.

    Так как языки теперь можно будет поставлять в виде библиотек (даже самые мелкие ДСЛ-и), то компании которые выпускают компоненты смогут выпускать и свои языки. Вот они то уж точно смогут обеспечить блэкджек и шлюх.

    Твой скепсис просто умиляет. Сейчас люди клепают ДСЛ-и которые вообще не имеют средств рефакторинга. Никаких! Мы же предлагаем дать им комплексное решение.

    Сделать некоторые виды рефакторинга автоматом физически невозможно. Но можно упростить их создание сделав, тем самым, их создание доступным массам.

    I>Все не знаю. Наибольшее влияние на бизнес оказывает менеджмет. Далее — маркетинг. Уже потом инженеры, дизайнеры и тд, из которых часть админов, часть безопасников, часть тестировщиков, аналитиков и тд.


    Это такой защитный гон. Типа разработка ПО — это пустяки. "Фигня война! Главное — маневры!".

    Маркетологи могут работать совершенно независимо от разработчиков. Они из другой "вселенной". И по их вине крайне редко заваливаются сроки или выпускается некачественный продукт. А вот по вине программистов — постоянно!

    Так что если тебе хочется поговорить о маркетинге или управлении, то иди на соответствующие форумы. А этот форум посвящено разработке ПО.

    I>Это самый лучший расклад. Все остальные еще хуже. Например берем знакомую тебе полиграфию. Доход от печатной продукции. Программинг всего лишь обслуживающая система. Опаньки !


    Какую из систем? Ты видел как сейчас печатают малотиражную продукцию? Ее печатают на автоматизированных комплексах. Эдакий мега-принтер. Там ПО решает чуть меньше чем все вопросы. А его сложность весьма высока.

    Вопросы организации заказов решаются финансовыми системами мало чем отличающимися от аналогичных на других видах предприятиях. Обычно это банальный 1Эс. Максимум с небольшими доработками.

    I>>>Если работают в реальных проектах значит это уже промышленный эффект.

    VD>>От бедности, в 60-ых в проектах отлично работало кодирование в машкодах. Что это доказывает?

    I>Доказывает, что для тех потребностей хватало машинных кодов и никто не умер от недостатка немерле.


    От отсутствия компьютеров в 30-ых годах тоже никто не умер.

    В общем, не моли чепуху. Потребности всегда больше чем возможности. И уровень инструментов будет постоянно расти чтобы обеспечить расширение круга задач и уровня их сложности.

    Ты договорился до полного абсурда. Следующим шагом, видимо, будет апелляция к тому что на свете живут вообще глухие и слепые люди, и им Немерл не нужен.

    I>Ты сам то подумай, Лисп уже был, а писали и в машинных кодах, потом на асме, потом на фортранах-коболах, потом на си.


    Лисп был, есть и будет пока не появятся более мощные инструменты. За последние 5 лет появилось несколько его разновидностей. Это не говоря о матерых Комон Лиспе и Схеме, которые похоронили уже не один язык.

    Проблема в том, что Лисп требует ломки сознания и динамически типизирован. В динамическом мире есть как минимум две альтернативы Лиспу — Питон и Руби. Их мэйнстрим принимает куда охотнее. В них тоже есть метапрограммирование, но другого рода. А гибкость достигается за счет динамики. В статически же типизированном мире ничего подобного нет.

    I>История Лиспа тебя ничему не научила ? Сочувствую.


    Научила. Сродства должны быть доступны простым смертным. Не идиотам, но и не тем не многим кто ради возможностей может сломать свое сознание и начать думать по другому.

    Боюсь, что Лисп как раз и стал косвенным "доказательством" проблемности языкового подхода. Испортил общественное мнение, так сказать. К тому же он сильно опередил свое время. Но то что он жив, не смотря на свой странный вид, говорит о том, что он появился не спроста.

    VD>>Он тебе раз 10 повторил — опора на вменяемые кадры. Для использования ДСЛ нужно просто быть вменяемым программистом. Для их разработку нужно к тому же быть вменяемым архитектором ПО.


    I>Не ясно, что такое вменяемые и где их брать, как готовить.


    Это тоже уже обсуждалось. Невменяемые программисты могут писать только говнокод. А вменяемых программистов очень много, если не сказать — большинство.

    I>Для бизнеса очень хорошо брать людей "на вырост", то есть, чем моложе, тем лучше. Чему их готовить ? Сразу монады хаскеля вливать в головы ?


    Да бери на вырост. Тут никакой разницы с обычным подходом нет. Сколько можно одно и то же повторять?

    VD>>Второй — это вопрос образования и пиара. Было бы замечательно, если бы наши вузы перестали убивать новые поколения программистов, а начали бы обучать тем самым методикам. В том числе и методикам разработки и эксплуатации ДСЛ-ей при разработке ПО.


    I>Ну так вы с Wolfhoundon молчите, как партизаны, и не говорите кто же такой вменяемый программист.


    Тебе уже сто раз ответили. Я уже было хотел сказать тебе что это ты (в том числе), но то как ты упорно отстаиваешь явно неверную позицию останавливает меня :).

    Вообще прикольно, что каждый считает себя вменяемым программистом, а все вокруг него идиоты. Прям как на этом рисунки:


    I> А между тем бизнес-специфика выражается чуть ли не линейным кодом, максимум круд, где сложность в написании запроса, для чего уже есть все необходимые инструменты.


    Сам то в это веришь? Если так, то зачем все эти форумы, книги, средства разработки? И почему весь нужный софт еще не написан, а сроки разработки постоянно срываются?

    VD>>Главная проблема Лиспа — отсутствие синтаксиса. По сути программисту предлагается писать в АСТ. Причем АСТ выраженном в виде списков. Читаемость такого кода довольно низка.


    I>Вижу, есть сдвиги — всего пару лет назад ты чуть не с пеной кидался на людей у кого были такие же аргументы :))


    Ты что-то путаешь. Ссылку в студию, плиз.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[50]: Языки общего назначения не имеют смысла!
    От: netch80 Украина http://netch80.dreamwidth.org/
    Дата: 02.05.12 10:49
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    N>>Тут больша виновата команда, что не одернула его.

    O> Не положено в таких местах начальство одергивать.

    ORLY? Тогда не надо вообще ни на один метод грешить, потому что в таких условиях ни один метод не будет нормально работать. Прежде чем вообще хоть что-то использовать и разрабатывать, надо создать рабочую среду, при которой любой метод будет применяться адекватно ситуации, а не наобум.

    А так сейчас у тебя будет ненависть ко всему, что модно, только потому, что оно модно. Но ведь метод не виноват, что он стал модным именно сейчас?

    N>>Вы как-то очень странно относитесь именно к средствам. Вот Вам в качестве обратного примера — sendmail. Там явно сидят Ваши сторонники — 30 лет развития без единого рефакторинга.

    O> Там с самого начала была идиотская архитектура. Не очень хороший пример.

    Именно что поэтому очень хороший пример! У чего угодно может быть изначально идиотская архитектура (а в 99% случаев и будет), потому что


    и после этого, если ставится цель не потратить грант или распилить бюджет, а именно сделать как следует, минимально и управляемо ломая уже существующее — именно рефакторинг и нужен. И, между прочим, это не только в программировании.

    N>> Но если бы был автомат — то применил бы и автомат. А почему так сразу "тонны" кода? Обычно, мне кажется, меняются только определённые места, и не делается незапрошенных прогонок по всему коду.

    O> Например, изменение имени какого либо класса или метода, используемого во множестве модулей.

    Если публичный API — да, плохо. Тогда придумывают какую-то совместимость, переходные меры.
    А если внутренний — страдающих мало, или же и так надо было переделывать, потому что архитектура была ужасная.

    N>> Потому что рефакторинг допустим и нужен, но только тогда, когда не предполагается таких вот мержей втихую в одном месте без корреляции с остальными.

    O> Рефакторинг допустим только тогда, когда вообще никаких merge-ей не предполагается в принципе. Когда все тысячи разработчиков дружно гадят в один общий trunk. Ну прямо таки идеал организации разработки, не находите?

    Не нахожу. На практике или есть адекватное разделение структуры, и тогда большинство этих преобразований не влияют на "тысячи разработчиков", или его нет, тогда его и так надо было делать, и внешняя необходимость только подтолкнула процессы.

    N>>А ещё больше виновата контора в целом — что не контролирует процесс.

    O> Процесс-то как раз устоявшийся за десятилетия, отлаженный как часы. И никакого рефакторинга не предполагающий по определению. Конечно же, на ошибках учиться надо, это их вина, что после первого такого евангелиста не вкличили в интервью вопросы об отношении к рефакторингу.

    А также — что радикальные меры не были отменены и применены, если и нужно, то в месяц по чайной ложке.
    Итого — просто плохая контора. Бывает, тут вокруг таких на рупь десяток.

    O> Надо, надо. Надо энтузиастов рефакторинга сажать в клетки и размножаться не давать.


    Я бы лично сажал в клетки тех, кто оценивает инструмент по последствиям неадекватных применений в заведомо неадекватных местах. Ничего личного.
    The God is real, unless declared integer.
    Re[48]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 02.05.12 11:16
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    O> Ручками, аккуратно, вдумчиво, страдая и мучаясь. Потому как если это будет слишком легко делать, этим будут злоупотреблять.

    Я не согласен.

    O> Вот-вот, я не представляю, какая вообще польза от таких может быть. Ни разу живьем их в реальной работе не видел (а видел очень много всякого), какие-то они мифические, все про них пишут, и никто показать не может.

    Тебе повезло.
    Я видел.
    Убить был готов.

    O> Хотя вру, видел однажды последствия их работы. Индийский аутсорсинг. За ними, понятное дело, потом полностью с нуля все переписывали, так что экономическая выгода крайне сомнительна.

    Во-во. Только Ikemefula это не понимает.

    WH>>А если нужны качественные сообщения об ошибках.

    O> Какие с этим проблемы? Ассертов в макре расставить, и все.
    Не только. Нужно еще нормальные сообщения от парсера.
    Как бы ты не старался, но тебе меня не убедить в том, что синтаксис не нужен.

    WH>>Предметно-ориентированные системы типов.

    O> С системами типов никаких проблем нет, если есть Пролог.
    Только писать много. И понять, как работает не просто.

    WH>>Вывод типов, понимающий перегрузки.

    O> Опять же, с Прологом не проблема.
    Не все так просто. Ибо если делать в лоб, то тебя комбинаторные взрывы прикончат.

    O> Не убежден в ценности IDE для DSL-ей. Много там у нас IDE, поддерживающих SQL? Не особо. И никто не жалуется.

    Ты удивишься.
    http://www.jetbrains.com/idea/img/injection_before_after.gif

    O>Много IDE для навороченных DSL-ей в разного рода CAD-ах? Для того же автокада, для инструментов Cadence? Ничего нет, и народ не жалуется, пишут миллионы строк кода на DSL без всяких IDE.

    у них просто выбора нет.
    Ибо создание ИДЕ при использовании современных инструментов это очень дорого.
    А если бы IDE получалась сама. А такие вещи как автодополнение и некоторые рефакторинги можно генерировать полностью автоматически.
    То это все было бы.
    Даже были бы те рефакторинги которые бы пришлось писать руками ибо на правильных ДСЛ это десятки строк на рефакторинг.

    O> IDE нужны для работы с гигантскими фреймворками, для жаба-ынтырпрайза всякого. То есть для того, что с массовым введением DSL станет просто ненужным.

    Категорически не согласен.

    O> А не надо усложнять. Как по мне, так большинству DSL и синтаксиса-то никакого не надо (но понимаю прекрасно, что лисперу по этому пункту со всеми остальными никогда не договориться). Тем, кому надо, часто больше подходит графическое представление (а тут для нас уже Microsoft расстаралась).

    Графическое представление не работает чуть менее чем всегда.
    Вон тот же AndrewVK пытался делать графические ДСЛ.
    На маленьких задачах все было отлично.
    Как только задача разрастается. Понять, что там происходит, становилось невозможно.

    Единственный известный мне, графический язык которой имеет шансы, не скатится в говно на задачах больше чем hello world это ДРАКОН.

    O> Как и подавляющее большинство очень популярных и очень жизненных языков. Кто жизненнее — популярнейшие Python, Javascript, Ruby, Perl, Shell-ы всякие или

    Вопрос в том среди кого они популярны.
    Я их даже в руки не возьму. Кроме однострочников Shell ибо выбора нет. Пока.

    O>мертвый Haskell

    Я думаю, он как минимум не менее живой чем лисп.
    И вообще поосторожней с заявлениями о том что хаскель мертв
    http://lurkmore.to/%D0%A4%D0%B0%D0%B9%D0%BB:Z150_03.jpg


    O>и унылая ынтырпрайзная Java? Не такой уж и простой вопрос.

    В больших конторах более популярны статически типизированные языки.

    WH>>Одно это уже делает его оторванным по самые не балуйся.

    O> Я в эту типизированную религию не верю,
    А я статическую типизация каждый день использую.
    Очень удобно, когда компилятор ошибки ловит.

    O>вверх и вниз по лямбда-кубу налазился в свое время, понял, что тлен это все и суета.

    Матанистые системы типов действительно суета.
    Ведь все эти навороты используются только для того чтобы выразить некие прикладные ограничения. И получается это всё равно через жопу.

    Если дать людям создавать свои типы типов (кайнды) которые могут ровно, то, что нужно в предметной области то все станет намного проще и практичнее.
    Вот, например, так:
    Re[2]: N2 &mdash; драфт &mdash; почти окончательный вариант
    Автор: WolfHound
    Дата: 27.04.12
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[47]: Языки общего назначения не имеют смысла!
    От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
    Дата: 02.05.12 12:44
    Оценка: :)
    Здравствуйте, WolfHound, Вы писали:

    VD>>>Создание других рефакторингов можно будет резко упростить.

    I>>То есть, я пишу ДСЛ и я же должен буду рефакторинги писать ? Кушайте сами.
    WH>Если написание рефакторинга займет десяток строк то в чем проблема?

    Ну вот покажи, как абзац текста убрать в пяток функций

    I>>Это самый лучший расклад. Все остальные еще хуже. Например берем знакомую тебе полиграфию. Доход от печатной продукции. Программинг всего лишь обслуживающая система. Опаньки !

    WH>А сколько та же контора использует софта, который пишется конторой, которая только софт и пилит?

    Копейки.

    I>>Ты сам то подумай, Лисп уже был, а писали и в машинных кодах, потом на асме, потом на фортранах-коболах, потом на си.

    I>>История Лиспа тебя ничему не научила ? Сочувствую.
    WH>Ох. Лисп динамически типизированное тормизилово.
    WH>А в те годы каждый такт был на счету. Ибо стоил на несколько порядков дороже, чем сейчас.

    Не было никогда на счету всяких тактов, задачи были другими.

    WH>А что касается мета-программирования то посмотри, сколько шума вокруг Ruby on Rails.

    WH>25 700 000 результатов в гугле.
    WH>А ведь это ДСЛ.

    Ну вот один руби нужен. А зоопарк дсл да в одном проекте — нет, не нужен.
    Re[47]: Языки общего назначения не имеют смысла!
    От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
    Дата: 02.05.12 13:02
    Оценка: :)))
    Здравствуйте, VladD2, Вы писали:

    I>>То есть, я пишу ДСЛ и я же должен буду рефакторинги писать ? Кушайте сами.


    VD>Или ты, или кто-то еще. Например, тот кто твой ДСЛ использует. Задача создания рефакторингов упростится. Ее сможет решать любой вменяемый программист.


    Не ясно, кто такой "вменяемый программист"

    VD>Твой скепсис просто умиляет. Сейчас люди клепают ДСЛ-и которые вообще не имеют средств рефакторинга. Никаких! Мы же предлагаем дать им комплексное решение.


    Ну так давай, кто ж мешает ?

    VD>Сделать некоторые виды рефакторинга автоматом физически невозможно. Но можно упростить их создание сделав, тем самым, их создание доступным массам.


    I>>Все не знаю. Наибольшее влияние на бизнес оказывает менеджмет. Далее — маркетинг. Уже потом инженеры, дизайнеры и тд, из которых часть админов, часть безопасников, часть тестировщиков, аналитиков и тд.


    VD>Это такой защитный гон. Типа разработка ПО — это пустяки. "Фигня война! Главное — маневры!".


    Это факты.

    VD>Маркетологи могут работать совершенно независимо от разработчиков. Они из другой "вселенной". И по их вине крайне редко заваливаются сроки или выпускается некачественный продукт. А вот по вине программистов — постоянно!


    Цена ошибки разработчка это сорваный срок. Цена ошибки маркетолога это проценты в доле рынка а следовательно заработок конторы. Цена ошибки менеджмента == цена бизнеса.

    Мне что, объяснить, что важнее из этих трех вещей ?

    VD>Так что если тебе хочется поговорить о маркетинге или управлении, то иди на соответствующие форумы. А этот форум посвящено разработке ПО.


    Ты предлагаешь решения для бизнеса и при этом знать нехочешь ничего про этот бизнес. ТАк не выйдет.

    I>>Это самый лучший расклад. Все остальные еще хуже. Например берем знакомую тебе полиграфию. Доход от печатной продукции. Программинг всего лишь обслуживающая система. Опаньки !


    VD>Какую из систем? Ты видел как сейчас печатают малотиражную продукцию?


    Неужели в Visual Studio ?

    >Ее печатают на автоматизированных комплексах. Эдакий мега-принтер. Там ПО решает чуть меньше чем все вопросы. А его сложность весьма высока.


    Ну и менеджмент-маркетинг конечно же ничего не решает. Ага

    VD>Вопросы организации заказов решаются финансовыми системами мало чем отличающимися от аналогичных на других видах предприятиях. Обычно это банальный 1Эс. Максимум с небольшими доработками.


    Ну решаются, что с того ? Менеджмет и маркетинг всё равно бОльшее влияние имеют, примерно на порядок а то и больше.

    VD>Ты договорился до полного абсурда. Следующим шагом, видимо, будет апелляция к тому что на свете живут вообще глухие и слепые люди, и им Немерл не нужен.


    Я указываю про особенности бизнеса и прошу раскрыть формулу "вменяемый разработчик" а тебе мерещится "Немерл не нужен"
    По моему это к доктору

    VD>Проблема в том, что Лисп требует ломки сознания и динамически типизирован. В динамическом мире есть как минимум две альтернативы Лиспу — Питон и Руби. Их мэйнстрим принимает куда охотнее. В них тоже есть метапрограммирование, но другого рода. А гибкость достигается за счет динамики. В статически же типизированном мире ничего подобного нет.


    Не требует они никакой ломки. Как только ты раскроешь формулу "вменяемый разработчик" все станет очевидно.

    VD>Научила. Сродства должны быть доступны простым смертным. Не идиотам, но и не тем не многим кто ради возможностей может сломать свое сознание и начать думать по другому.


    Похоже, не научила.

    I>>Не ясно, что такое вменяемые и где их брать, как готовить.

    VD>Это тоже уже обсуждалось. Невменяемые программисты могут писать только говнокод. А вменяемых программистов очень много, если не сказать — большинство.

    Ну да и потому вы оба 80-90% предлагаете вообще выгнать из индустрии ?

    I>>Для бизнеса очень хорошо брать людей "на вырост", то есть, чем моложе, тем лучше. Чему их готовить ? Сразу монады хаскеля вливать в головы ?

    VD>Да бери на вырост. Тут никакой разницы с обычным подходом нет. Сколько можно одно и то же повторять?

    Конечно нет. Только не ясно, какие знания и умения требуются на входе и сколько времени их нужно прокачивать.

    VD>Вообще прикольно, что каждый считает себя вменяемым программистом, а все вокруг него идиоты. Прям как на этом рисунки:

    VD>

    Это про вас c WH.

    I>> А между тем бизнес-специфика выражается чуть ли не линейным кодом, максимум круд, где сложность в написании запроса, для чего уже есть все необходимые инструменты.


    VD>Сам то в это веришь? Если так, то зачем все эти форумы, книги, средства разработки? И почему весь нужный софт еще не написан, а сроки разработки постоянно срываются?


    Потому что код не является узким местом в большинстве проектов.

    I>>Вижу, есть сдвиги — всего пару лет назад ты чуть не с пеной кидался на людей у кого были такие же аргументы


    VD>Ты что-то путаешь. Ссылку в студию, плиз.


    Пофикси поиск сначала. Щас в одном топике нельзя ничего найти, не то что на всем сайте
    Re[48]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 02.05.12 13:33
    Оценка:
    Здравствуйте, Ikemefula, Вы писали:

    I>Цена ошибки разработчка это сорваный срок. Цена ошибки маркетолога это проценты в доле рынка а следовательно заработок конторы. Цена ошибки менеджмента == цена бизнеса.


    Да. Согласен. Не выполненная работа, сделанная в неприемлемое время или с ненадлежащим качеством — это ни разу не проблема. В мире все ради управления и маркетинга. Без них прожить нельзя. Без остального — легко.

    Тут, конечно, не поспорить.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[48]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 02.05.12 13:43
    Оценка:
    Здравствуйте, Ikemefula, Вы писали:

    I>Цена ошибки разработчка это сорваный срок. Цена ошибки маркетолога это проценты в доле рынка а следовательно заработок конторы. Цена ошибки менеджмента == цена бизнеса.


    I>Ну решаются, что с того ? Менеджмет и маркетинг всё равно бОльшее влияние имеют, примерно на порядок а то и больше.


    Уважаемый, у тебя все перевернуто с ног на голову. Это не производство ради макретинга и менеджмента, а макретинг и менеджмент для производства.

    Что будут "маркетировать" маркетологи, если не будет продукта или он будет не качественным? А что это за управление такое, которое привело к ситуации когда программисты заняты хрен знает чем, а маретологи пиарят воздух?

    Мы точно о софтовой конторе речь ведем, а не об МММ?
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[46]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 02.05.12 14:00
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    VD>>Плюс Лисп — это динамически типизированный язык. И в мир статики он вписывается крайне хреново.


    O> Это не обязательное свойство Лиспа, он может быть как угодно типизированным (см. Shen, бывший Qi).


    Посмотрел Shen. Shen мне понравился. Паттерн-матчинг, удобные лямбды, встроенный пролог, континюэшоны — это все красиво.

    Но он такой же динамически типизированный как и все остальные живые варианты Лиспа. То что нем можно врубить опцию (tc +) еще не делает его полноценным статически-типизированным языком. Все проблемы динамики в нем присутствуют.

    Кроме того у него куча других проблем.

    Начнем с того, что его толком еще и не сделали. Стабильного релиза для Винды нет. Мои эксперименты быстро привели к появления AV.

    Далее это обертка над другими лиспами. Так что реально его возможности упираются в возможности базовой лисп-платформы.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[45]: Языки общего назначения не имеют смысла!
    От: Mamut Швеция http://dmitriid.com
    Дата: 02.05.12 18:39
    Оценка:
    VD>Он тебе раз 10 повторил — опора на вменяемые кадры. Для использования ДСЛ нужно просто быть вменяемым программистом. Для их разработку нужно к тому же быть вменяемым архитектором ПО.

    Тут где-то рядом Wolfhound, вроде, говорил, что для разработки ДСЛя особо мозгов не надо. Вы уже договоритесь, а


    dmitriid.comGitHubLinkedIn
    Re[46]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 03.05.12 13:19
    Оценка:
    Здравствуйте, Mamut, Вы писали:

    M>Тут где-то рядом Wolfhound, вроде, говорил, что для разработки ДСЛя особо мозгов не надо. Вы уже договоритесь, а :)


    Ты откровенно извращаешь его слова. Он говорил, что для этого не надо быть особо одаренным.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[47]: Языки общего назначения не имеют смысла!
    От: Mamut Швеция http://dmitriid.com
    Дата: 03.05.12 19:21
    Оценка:
    M>>Тут где-то рядом Wolfhound, вроде, говорил, что для разработки ДСЛя особо мозгов не надо. Вы уже договоритесь, а
    VD>Ты откровенно извращаешь его слова. Он говорил, что для этого не надо быть особо одаренным.

    Может быть и извратил, но точно не откровенно. Ща, правда, совсем лень искать. В отпуске я


    dmitriid.comGitHubLinkedIn
    Re[48]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 03.05.12 20:10
    Оценка:
    Здравствуйте, Mamut, Вы писали:

    M>Может быть и извратил, но точно не откровенно. Ща, правда, совсем лень искать. В отпуске я :)


    Ну, ты давай тогда поищи на досуге и процитируй. А переверать чужие слова не надо.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[48]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 03.05.12 21:21
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    O> IDE нужны для работы с гигантскими фреймворками, для жаба-ынтырпрайза всякого. То есть для того, что с массовым введением DSL станет просто ненужным.


    Ты не верно оцениваешь ресурсы. Человеческие (умственные) ресурсы константы. Однако человеческие потребности беспредельны.

    Если мы переводим разработку на массовое использование ДСЛ-ей, то у нас неизбежно поднимется производительность труда программистов. Но она приведет не к облегчению их жизни, а к усложнению задач и/или к увеличению их объемов.

    В результате, мы получим такие объемы кода на ДСЛ-ях и такую их взаимосвязанность, что проблемы проявятся на новом уровне. Так что потребность в качественных инструментах работы с ДСЛ-ями — это всего лишь вопрос времени.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[44]: Языки общего назначения не имеют смысла!
    От: Mamut Швеция http://dmitriid.com
    Дата: 04.05.12 06:06
    Оценка:
    VD>Грамотно ограниченный ДСЛ позволит использовать людей со слабой квалификацией и ограниченными возможностями. Фрэймворки и библиотеки такого же эффекта не дадут.

    Зависит от языка, фреймворков и библиотек. RoR и Django вполне себе позволяют использовать людей со слабой квалификацией и ограниченными возможностями. При том, что RoR — это, по сути, DSL, а Django — нет.


    dmitriid.comGitHubLinkedIn
    Re[45]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 04.05.12 18:26
    Оценка:
    Здравствуйте, Mamut, Вы писали:

    M>Зависит от языка, фреймворков и библиотек. RoR и Django вполне себе позволяют использовать людей со слабой квалификацией и ограниченными возможностями. При том, что RoR — это, по сути, DSL, а Django — нет.


    А можно показать типичный код на Django?
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[45]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 04.05.12 18:29
    Оценка:
    Здравствуйте, Mamut, Вы писали:

    M>Зависит от языка, фреймворков и библиотек. RoR и Django вполне себе позволяют использовать людей со слабой квалификацией и ограниченными возможностями. При том, что RoR — это, по сути, DSL, а Django — нет.


    Вот это он?

    И это не ДСЛ?
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[46]: Языки общего назначения не имеют смысла!
    От: Mamut Швеция http://dmitriid.com
    Дата: 07.05.12 15:25
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Здравствуйте, Mamut, Вы писали:


    M>>Зависит от языка, фреймворков и библиотек. RoR и Django вполне себе позволяют использовать людей со слабой квалификацией и ограниченными возможностями. При том, что RoR — это, по сути, DSL, а Django — нет.


    VD>Вот это он?


    VD>И это не ДСЛ?


    Это вюуха с шаблонизатором для HTML'я, а есть и вполне себе контроллеры и модели, написанные на Python'е. Но особой квалификации и там уже не требуется: https://docs.djangoproject.com/en/1.4/intro/overview/


    dmitriid.comGitHubLinkedIn
    Re[47]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 07.05.12 17:38
    Оценка:
    Здравствуйте, Mamut, Вы писали:

    M>Это вюуха с шаблонизатором для HTML'я,


    И это не ДСЛ? Вообще, удивительно как можно уходить от столь прямого вопроса.

    M> а есть и вполне себе контроллеры и модели, написанные на Python'е. Но особой квалификации и там уже не требуется: https://docs.djangoproject.com/en/1.4/intro/overview/


    urlpatterns = patterns('',
        (r'^articles/(\d{4})/$', 'news.views.year_archive'),
        (r'^articles/(\d{4})/(\d{2})/$', 'news.views.month_archive'),
        (r'^articles/(\d{4})/(\d{2})/(\d+)/$', 'news.views.article_detail'),
    )


    Вот еще ДСЛ-чик.

    Короче, ты явно однобоко смотришь на код.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[48]: Языки общего назначения не имеют смысла!
    От: Mamut Швеция http://dmitriid.com
    Дата: 07.05.12 18:02
    Оценка: :))
    M>>Это вюуха с шаблонизатором для HTML'я,

    VD>И это не ДСЛ? Вообще, удивительно как можно уходить от столь прямого вопроса.


    Это DSL

    M>> а есть и вполне себе контроллеры и модели, написанные на Python'е. Но особой квалификации и там уже не требуется: https://docs.djangoproject.com/en/1.4/intro/overview/


    VD>
    VD>urlpatterns = patterns('',
    VD>    (r'^articles/(\d{4})/$', 'news.views.year_archive'),
    VD>    (r'^articles/(\d{4})/(\d{2})/$', 'news.views.month_archive'),
    VD>    (r'^articles/(\d{4})/(\d{2})/(\d+)/$', 'news.views.article_detail'),
    VD>)
    VD>


    VD>Вот еще ДСЛ-чик.


    Ничего, что это — вызов библиотечной функции? Не помню, кто тут говорил (может и не ты), что библиотеками ДСЛ не заменить

    VD>Короче, ты явно однобоко смотришь на код.


    Однобоко смотришь ты, но тебе можно простить, ты Джанго не знаешь.

    В Джанго, по сути, есть ровно один DSL — это Django Template Language для вьюх. Но ведь вьюхами дело не заканчивается, так ведь

    Есть модели:
    class Article(models.Model):
        pub_date = models.DateTimeField()
        headline = models.CharField(max_length=200)
        content = models.TextField()
        reporter = models.ForeignKey(Reporter)
    
        def __unicode__(self):
            return self.headline

    Вролне себе декларативно-ДСЛеподобное описание модели/ORM'а, которое легко и просто разворачивается в
    >>> from datetime import datetime
    >>> a = Article(pub_date=datetime.now(), headline='Django is cool',
    ...     content='Yeah.', reporter=r)
    >>> a.save()
    
    # Now the article is in the database.
    >>> Article.objects.all()
    [<Article: Django is cool>]

    и прочую толпу методов При этом это как бы совсем не DSL, а просто ООП, но для использования мозгов не требуется вообще:
    all_entries = Entry.objects.all()
    Entry.objects.filter(pub_date__year=2006)
    Entry.objects.filter(
         headline__startswith='What'
     ).exclude(
         pub_date__gte=datetime.now()
     ).filter(
         pub_date__gte=datetime(2005, 1, 1)
     )
    
    Book.objects.all().aggregate(Avg('price'))

    и т.п. Так оно еще и ленивое (то есть выполняется общий конечный запрос, а не по запросу на каждый вызов метода).

    Ну и контроллер ко всему этому, где основное-то и происходит. Что-то типа
    def vote(request, poll_id):
        p = get_object_or_404(Poll, pk=poll_id)
        try:
            selected_choice = p.choice_set.get(pk=request.POST['choice'])
        except (KeyError, Choice.DoesNotExist):
            # Redisplay the poll voting form.
            return render_to_response('polls/detail.html', {
                'poll': p,
                'error_message': "You didn't select a choice.",
            }, context_instance=RequestContext(request))
        else:
            selected_choice.votes += 1
            selected_choice.save()
    
            # Always return an HttpResponseRedirect after successfully dealing
            # with POST data. This prevents data from being posted twice if a
            # user hits the Back button.
            return HttpResponseRedirect(reverse('polls.views.results', args=(p.id,)))


    К чему я это? А, к этому:

    VD>Грамотно ограниченный ДСЛ позволит использовать людей со слабой квалификацией и ограниченными возможностями. Фрэймворки и библиотеки такого же эффекта не дадут.

    Зависит от языка, фреймворков и библиотек. RoR и Django вполне себе позволяют использовать людей со слабой квалификацией и ограниченными возможностями. При том, что RoR — это, по сути, DSL, а Django — нет.


    Повторюсь, в Django из действительно DSL — только Template Language. И его роль я не хочу нисколько не преуменьшить — вещь крутая, и особой квалификации тоже не требует. Но и сам фреймворк дает вполне такой же эффект, как и гипотетические DSLи


    dmitriid.comGitHubLinkedIn
    Re[49]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 07.05.12 19:12
    Оценка:
    Здравствуйте, Mamut, Вы писали:

    VD>>
    VD>>urlpatterns = patterns('',
    VD>>    (r'^articles/(\d{4})/$', 'news.views.year_archive'),
    VD>>    (r'^articles/(\d{4})/(\d{2})/$', 'news.views.month_archive'),
    VD>>    (r'^articles/(\d{4})/(\d{2})/(\d+)/$', 'news.views.article_detail'),
    VD>>)
    VD>>

    VD>>Вот еще ДСЛ-чик.

    M>Ничего, что это — вызов библиотечной функции?


    Ничего. Для встроенных ДСЛ-ей это характерно. Раз есть спец.синтаксис, то — это ДСЛ. Или вот это '^articles/(\d{4})/$' код на Питоне?

    M>Не помню, кто тут говорил (может и не ты), что библиотеками ДСЛ не заменить :))


    VD>>Короче, ты явно однобоко смотришь на код.


    M>Однобоко смотришь ты, но тебе можно простить, ты Джанго не знаешь.


    Ну, спасибо за прощение. :))

    M>В Джанго, по сути, есть ровно один DSL — это Django Template Language для вьюх. Но ведь вьюхами дело не заканчивается, так ведь ;)


    Нет. Как и ДСЛ не один. Это мы уже видели выше. Ну, а то что ты явно видишь его в шаблонизаторе — это от того, что там встроенный ДСЛ не канает. Точнее канает, но выглядеть будет не комильфо.

    M>Есть модели:

    M>
    M>class Article(models.Model):
    M>    pub_date = models.DateTimeField()
    M>    headline = models.CharField(max_length=200)
    M>    content = models.TextField()
    M>    reporter = models.ForeignKey(Reporter)
    
    M>    def __unicode__(self):
    M>        return self.headline
    M>

    M>Вролне себе декларативно-ДСЛеподобное описание модели/ORM'а, которое легко и просто разворачивается в
    M>
    
    Ага. Я бы даже был более смел и сказал бы - встроенный ДСЛ. Да еще и с метапрограммированием. На Яве так не прокатит.
    
    >>>> from datetime import datetime
    >>>> a = Article(pub_date=datetime.now(), headline='Django is cool',
    M>...     content='Yeah.', reporter=r)
    >>>> a.save()
    
    M># Now the article is in the database.
    >>>> Article.objects.all()
    M>[<Article: Django is cool>]
    M>

    M>и прочую толпу методов При этом это как бы совсем не DSL, а просто ООП,

    Ах это простое ООП? Ну, тогда тебя не затруднит объяснить мне как простой ООП превращает классы в записи БД? Или есть еще некий ДСЛ мапинга который осуществляет эту магию?

    M>но для использования мозгов не требуется вообще:

    M>
    M>all_entries = Entry.objects.all()
    M>Entry.objects.filter(pub_date__year=2006)
    M>Entry.objects.filter(
    M>     headline__startswith='What'
    M> ).exclude(
    M>     pub_date__gte=datetime.now()
    M> ).filter(
    M>     pub_date__gte=datetime(2005, 1, 1)
    M> )
    M>Book.objects.all().aggregate(Avg('price'))
    M>


    О, как? А о суффиксах этих (_year, _startswith, _gte) нужно телепатией догадываться? Их кто делает?
    Они случаем не есть расширение языка за счет обработки отсутствующих методов?

    M>и т.п. Так оно еще и ленивое (то есть выполняется общий конечный запрос, а не по запросу на каждый вызов метода).


    Ну, дык видно же что пытались линк сэмулировать имеющимися средствами. А линк — это не встроенный ДСЛ часом? :))

    Короче, молодец. Лучше меня опроверг свою позицию.


    M>К чему я это? А, к этому:


    Мне кажется ты просто хотел сказать, что не знаешь что ДСЛ может быть внутренним, сделанным средствами языка. Именно это и сделано в Джанго.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[50]: Языки общего назначения не имеют смысла!
    От: Mamut Швеция http://dmitriid.com
    Дата: 07.05.12 20:26
    Оценка: :)
    VD>>>
    VD>>>urlpatterns = patterns('',
    VD>>>    (r'^articles/(\d{4})/$', 'news.views.year_archive'),
    VD>>>    (r'^articles/(\d{4})/(\d{2})/$', 'news.views.month_archive'),
    VD>>>    (r'^articles/(\d{4})/(\d{2})/(\d+)/$', 'news.views.article_detail'),
    VD>>>)
    VD>>>

    VD>>>Вот еще ДСЛ-чик.

    M>>Ничего, что это — вызов библиотечной функции?


    VD>Ничего. Для встроенных ДСЛ-ей это характерно. Раз есть спец.синтаксис, то — это ДСЛ. Или вот это '^articles/(\d{4})/$' код на Питоне?


    Это код на Питоне По сути, мы просто передаем RegExp, по которому матчим путь.

    M>>Вролне себе декларативно-ДСЛеподобное описание модели/ORM'а, которое легко и просто разворачивается в

    VD>Ага. Я бы даже был более смел и сказал бы — встроенный ДСЛ. Да еще и с метапрограммированием. На Яве так не прокатит.

    Ну да. Раз в Яве не прокатит, то это — смело DSL

    M>>и прочую толпу методов При этом это как бы совсем не DSL, а просто ООП,


    VD>Ах это простое ООП? Ну, тогда тебя не затруднит объяснить мне как простой ООП превращает классы в записи БД? Или есть еще некий ДСЛ мапинга который осуществляет эту магию?


    Как-как. Кодом. ООП. Например, https://github.com/django/django/blob/master/django/db/models/base.py, https://github.com/django/django/blob/master/django/db/models/query.py и т.п.

    M>>но для использования мозгов не требуется вообще:

    M>>
    M>>Entry.objects.filter(
    M>>     headline__startswith='What'
    M>> ).exclude(
    M>>     pub_date__gte=datetime.now()
    M>> ).filter(
    M>>     pub_date__gte=datetime(2005, 1, 1)
    M>> )
    M>>


    VD>О, как? А о суффиксах этих (_year, _startswith, _gte) нужно телепатией догадываться?


    Зачем же телепатией? Для этого документация есть
    И все делается банальным кодом https://github.com/django/django/blob/master/django/db/models/fields/__init__.py
    elif lookup_type in ('exact', 'gt', 'gte', 'lt', 'lte'):
                return self.get_prep_value(value)



    VD>Их кто делает?

    VD>Они случаем не есть расширение языка за счет обработки отсутствующих методов?

    Вот оно как. Наличие в языке method_missing (как в Руби) ВНЕЗАПНО делает из него DSL? Что-то мне кажется, что ты сторонники DSL'изации всего и вся трактуют DSL так, как им выгодно. Не гворя о том, что никакой тут обработкой несуществующих методов и не пахнет. Вызывается функция с какими-то параметрами, количество которых в Питоне может быть неограниченно, и парсится название ключей (сорри, сейчас не найду точную строчку кода).

    M>>и т.п. Так оно еще и ленивое (то есть выполняется общий конечный запрос, а не по запросу на каждый вызов метода).

    VD>Ну, дык видно же что пытались линк сэмулировать имеющимися средствами. А линк — это не встроенный ДСЛ часом?

    LINQ — DSL. Где ты тут видишь DSL? Или ты считаешь, что из утверждения «Linq — DSL, Django типа эмулирует Linq» моментально следует «то, как Django эмулирует значит, что это — DSL»? Не говоря о том, что Django нифига не эмулирует Linq, как бы тебе этого ни хотелось бы.

    VD>Короче, молодец. Лучше меня опроверг свою позицию.


    M>>К чему я это? А, к этому:


    VD>Мне кажется ты просто хотел сказать, что не знаешь что ДСЛ может быть внутренним, сделанным средствами языка. Именно это и сделано в Джанго.


    Мне кажется, что твоя фраза про «фреймворки так не смогут» неверна — это все, что я хочу сказать. И Джанго это прекрасно показывает. Или тогда возвращаемся к тому, что «DSL — это любой ЯП (язык программирования) использованный в некотором приложении которое специализируется на какой-то предметной области» (http://rsdn.ru/forum/philosophy/4703108.1.aspx
    Автор: VladD2
    Дата: 15.04.12
    )


    dmitriid.comGitHubLinkedIn
    Re[50]: Языки общего назначения не имеют смысла!
    От: netch80 Украина http://netch80.dreamwidth.org/
    Дата: 08.05.12 06:46
    Оценка:
    Здравствуйте, oldjackal, Вы писали:

    O> Например, изменение имени какого либо класса или метода, используемого во множестве модулей.


    история в тему
    Автор: мыщъх
    Дата: 08.05.12
    .
    The God is real, unless declared integer.
    Re[46]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 09.05.12 12:48
    Оценка: +1
    Здравствуйте, alex_public, Вы писали:

    _>Для обработки последовательностей данных эту задачу когда-то решили авторы sql.


    SQL не работает с последовательностями, он работает с кортежами и отношениями (TOP/LIMIT оставим за бортом).

    VD>>Мил человек. В линке одна из самых важных составляющих — это возможность автоматически преобразовать код в его AST. Так вот это на С++ делать запаришся, так как язык убог неимоверно.


    _>Эта особенность как раз всю кривизну и привносит, причём при отсутствие реальной необходимости.


    Поподробнее раскроешь мысль, как expression tree привносят в linq кривизну?
    ... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[51]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 09.05.12 20:54
    Оценка:
    Здравствуйте, Mamut, Вы писали:

    VD>>Они случаем не есть расширение языка за счет обработки отсутствующих методов?


    M>Вот оно как. Наличие в языке method_missing (как в Руби) ВНЕЗАПНО делает из него DSL?


    Наличие в языке method_missing (как в Руби) ВНЕЗАПНО делает возможным изменение смысла конструкций хост-языка, что ВНЕЗАПНО упрощает создание внутренних DSL-й.

    Советую тебе почитать книжку Фаулера про ДСЛ-и. Он в ней как раз этот метод описывает.

    M>Что-то мне кажется, что ты сторонники DSL'изации всего и вся трактуют DSL так, как им выгодно.


    Я просто потратил нное количество времени на то, чтобы разобраться в вопросе. Только и всего!
    ДСЛ-и используются намного чаще чем может показаться на первый взгляд. В динамических языках ДСЛ-ли делать проще (удобнее), так как есть множество средств для этого. method_missing одно из таких средств.

    В статических языках до недавнего времени делать ДСЛ-и было очень сложно. Но и в них можно извернуться. Проблема только в том, что результат не всегда получается приемлемым.

    M>Не гворя о том, что никакой тут обработкой несуществующих методов и не пахнет. Вызывается функция с какими-то параметрами, количество которых в Питоне может быть неограниченно, и парсится название ключей (сорри, сейчас не найду точную строчку кода).


    Ключевое слово тут "парсится".

    M>LINQ — DSL. Где ты тут видишь DSL?


    Как где? Да вот же он:

    Entry.objects.filter(
         headline__startswith='What'
     ).exclude(
         pub_date__gte=datetime.now()
     ).filter(
         pub_date__gte=datetime(2005, 1, 1)
     )


    M>Или ты считаешь, что из утверждения «Linq — DSL, Django типа эмулирует Linq» моментально следует «то, как Django эмулирует значит, что это — DSL»?


    Сори. Я не смог этого понять.

    M>Не говоря о том, что Django нифига не эмулирует Linq, как бы тебе этого ни хотелось бы.


    Можешь назвать это как хочешь, но язык запросов на лицо. Это явно не доступ к БД через АПИ.

    M>Мне кажется, что твоя фраза про «фреймворки так не смогут» неверна — это все, что я хочу сказать.


    В какой-то мере могу согласиться, так как большая часть фрэймворков как раз и привлекает ДСЛ-подход. Просто фрэймворки в понимании дотнета и явы частенько делают это крайне уродливо. Скажем за неимением гибких средств в языке или качественных средство вроде N2/Nemerle они скатываются к программированию в ХМЛ или жутким встроенным ДСЛ-ям.

    У динамики с этим все намного лучше. Но все равно результат получается не идеальным. К тому же есть куча проблем связанных с самой динамикой. Тут тебе и недостаточная производительность, и некачественная поддержка IDE. Об автоматических рефакторингах вообще можно забыть.

    M>И Джанго это прекрасно показывает.


    Джанго показывает только то, что в динамических языках проще клепать ДСЛ-и.


    M>Или тогда возвращаемся к тому, что «DSL — это любой ЯП (язык программирования) использованный в некотором приложении которое специализируется на какой-то предметной области» (http://rsdn.ru/forum/philosophy/4703108.1.aspx
    Автор: VladD2
    Дата: 15.04.12
    )


    А это просто заблуждение.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[12]: Языки общего назначения не имеют смысла?
    От: netch80 Украина http://netch80.dreamwidth.org/
    Дата: 12.05.12 15:14
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    N>>А жаль. Это значит, что слишком много флеймов, где спорят, совершенно не согласовав, о чём вообще говорят.

    AVK>Моя практика показывает, что как только разговор заходит о трактовке терминов, ветку сразу можно бросать читать, потому что ничего интересного в ней уже не будет, один пустой срач.

    А моя — что с этого и начинается конструктив.
    Хотя, конечно, если у тебя собеседники, как некоторые здешние апологеты уездных языков, то они в принципе не способны что-то сказать не на своём языке, который больше мало кто понимает. Из таких — да, надо вытаскивать на их языке. Но я лично не хочу работать психоаналитиком на форуме.
    The God is real, unless declared integer.
    Re[49]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 13.05.12 19:06
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>Графическое представление не работает чуть менее чем всегда.

    WH>Вон тот же AndrewVK пытался делать графические ДСЛ.

    Почему пытался? Делал.

    WH>На маленьких задачах все было отлично.


    На реальных задачах тоже все неплохо получается. Просто надо было заменить уродский Netron на полноценный движок.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[48]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 13.05.12 19:06
    Оценка: +1
    Здравствуйте, oldjackal, Вы писали:

    O>>> Рефакторинг — зло. Чем скорее человечество забудет это гнусное слово, тем лучше.

    WH>>И что вместо него?

    O> Ручками, аккуратно, вдумчиво, страдая и мучаясь. Потому как если это будет слишком легко делать, этим будут злоупотреблять.


    Рефакторинг, сделанный руками, перестает быть рефакторингом?
    ... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[50]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 13.05.12 22:54
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    WH>>Графическое представление не работает чуть менее чем всегда.

    WH>>Вон тот же AndrewVK пытался делать графические ДСЛ.
    AVK>Почему пытался? Делал.
    По тому что, то, что я видел, было ужасно.

    WH>>На маленьких задачах все было отлично.

    AVK>На реальных задачах тоже все неплохо получается. Просто надо было заменить уродский Netron на полноценный движок.
    И чем же другой движок помогает от паутины стрелок?
    Покажи скриншот.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[51]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 14.05.12 08:15
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    AVK>>Почему пытался? Делал.

    WH>По тому что, то, что я видел, было ужасно.

    Ты видел не финальный вариант.

    WH>>>На маленьких задачах все было отлично.

    AVK>>На реальных задачах тоже все неплохо получается. Просто надо было заменить уродский Netron на полноценный движок.
    WH>И чем же другой движок помогает от паутины стрелок?

    Нормальными алгоритмами роутинга этих стрелок. Ну и добавление новых элементов позволило кардинально сократить количество стрелочек.

    WH>Покажи скриншот.


    Лень, если честно.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[52]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 14.05.12 09:27
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    AVK>Нормальными алгоритмами роутинга этих стрелок.

    От лапши никакой алгоритм роутинга не поможет.

    AVK>Ну и добавление новых элементов позволило кардинально сократить количество стрелочек.

    Это только немного оттягивает конец.
    Графические ДСЛ не масштабируются.

    WH>>Покажи скриншот.

    AVK>Лень, если честно.
    Понятно. Показывать нечего.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[53]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 14.05.12 09:34
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    AVK>>Нормальными алгоритмами роутинга этих стрелок.

    WH>От лапши никакой алгоритм роутинга не поможет.

    Помогает вот.

    AVK>>Ну и добавление новых элементов позволило кардинально сократить количество стрелочек.

    WH>Это только немного оттягивает конец.

    Нет никакого конца. Верхняя граница сложностив моем случае фиксирована.

    WH>Графические ДСЛ не масштабируются.


    И не нужно.

    WH>>>Покажи скриншот.

    AVK>>Лень, если честно.
    WH>Понятно. Показывать нечего.

    Ты действительно в это веришь?
    ... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[52]: Языки общего назначения не имеют смысла!
    От: Mamut Швеция http://dmitriid.com
    Дата: 14.05.12 09:49
    Оценка:
    VD>>>Они случаем не есть расширение языка за счет обработки отсутствующих методов?
    M>>Вот оно как. Наличие в языке method_missing (как в Руби) ВНЕЗАПНО делает из него DSL?
    VD>Наличие в языке method_missing (как в Руби) ВНЕЗАПНО делает возможным изменение смысла конструкций хост-языка, что ВНЕЗАПНО упрощает создание внутренних DSL-й.
    VD>Советую тебе почитать книжку Фаулера про ДСЛ-и. Он в ней как раз этот метод описывает.

    Останусь при своем мнении:

    M>>Что-то мне кажется, что ты сторонники DSL'изации всего и вся трактуют DSL так, как им выгодно.


    M>>Не гворя о том, что никакой тут обработкой несуществующих методов и не пахнет. Вызывается функция с какими-то параметрами, количество которых в Питоне может быть неограниченно, и парсится название ключей (сорри, сейчас не найду точную строчку кода).


    VD>Ключевое слово тут "парсится".


    Да не там этого ключевого слова. От того, что ты передал в метод ассоциативный массив, ручками пробежался по ключам и написал диспатчер, состоящий из if'ов это стало DSL'ем? В общем, отцитированное выше.

    M>>Или ты считаешь, что из утверждения «Linq — DSL, Django типа эмулирует Linq» моментально следует «то, как Django эмулирует значит, что это — DSL»?

    VD>Сори. Я не смог этого понять.

    Твоя фраза выглядела так: Django эмулирует Linq. Linq — DSL, следовательно в Джанго DSL. Я ставлю под сомнение это «следовательно»

    M>>Не говоря о том, что Django нифига не эмулирует Linq, как бы тебе этого ни хотелось бы.

    VD>Можешь назвать это как хочешь, но язык запросов на лицо. Это явно не доступ к БД через АПИ.

    И? Открою СТРАШНУЮ тайну — любой ORM — это не доступ к БД через АПИ. Клепим ярлык «это DSL, а не фреймворк» на все ORM'ы?

    M>>Мне кажется, что твоя фраза про «фреймворки так не смогут» неверна — это все, что я хочу сказать.


    VD>В какой-то мере могу согласиться, так как большая часть фрэймворков как раз и привлекает ДСЛ-подход. Просто фрэймворки в понимании дотнета и явы частенько делают это крайне уродливо. Скажем за неимением гибких средств в языке или качественных средство вроде N2/Nemerle они скатываются к программированию в ХМЛ или жутким встроенным ДСЛ-ям.


    VD>У динамики с этим все намного лучше. Но все равно результат получается не идеальным. К тому же есть куча проблем связанных с самой динамикой. Тут тебе и недостаточная производительность, и некачественная поддержка IDE. Об автоматических рефакторингах вообще можно забыть.



    Какое отношение это к обсуждаемой теме известно только тебе


    M>>И Джанго это прекрасно показывает.


    VD>Джанго показывает только то, что в динамических языках проще клепать ДСЛ-и.


    Грамотно ограниченный ДСЛ позволит использовать людей со слабой квалификацией и ограниченными возможностями. Фрэймворки и библиотеки такого же эффекта не дадут.


    Джанго показывает, что с использованием фреймворка Джанго можно использовать людей со слабой квалификацией и ограниченными возможностями.

    M>>Или тогда возвращаемся к тому, что «DSL — это любой ЯП (язык программирования) использованный в некотором приложении которое специализируется на какой-то предметной области» (http://rsdn.ru/forum/philosophy/4703108.1.aspx
    Автор: VladD2
    Дата: 15.04.12
    )


    VD>А это просто заблуждение.


    Ну да, ну да. Django — приложение, используемое в некой предметной области (в вебе), в нем использован «любой ЯП» (Питон).

    Тогда или давай полноценное формальное определение DSL, или перестань подгонять любую удобную тебе фичу любого удобного тебе языка под понятие DSL


    dmitriid.comGitHubLinkedIn
    Re[54]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 14.05.12 09:53
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    AVK>Ты действительно в это веришь?

    Я еще не видел ни одного графического ДСЛ, который бы не скатывался в говно, но больших задачах.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[55]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 14.05.12 10:01
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    AVK>>Ты действительно в это веришь?

    WH>Я еще не видел ни одного графического ДСЛ, который бы не скатывался в говно, но больших задачах.

    Будем обсуждать твой кругозор? И что насчет ситуации, когда большие задачи не нужны?
    ... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[56]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 14.05.12 10:14
    Оценка: :)
    Здравствуйте, AndrewVK, Вы писали:

    AVK>Будем обсуждать твой кругозор?

    Ну, так покажи класс.

    AVK>И что насчет ситуации, когда большие задачи не нужны?

    Один хрен текст лучше.
    Тем более что ненужность больших задач весьма сомнительна.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[57]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 14.05.12 10:19
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    AVK>>Будем обсуждать твой кругозор?

    WH>Ну, так покажи класс.

    С ренисометрией, это не ко мне.

    AVK>>И что насчет ситуации, когда большие задачи не нужны?

    WH>Один хрен текст лучше.

    Далеко не всегда.

    WH>Тем более что ненужность больших задач весьма сомнительна.


    Что, вот прям так во всех ситуациях сомнительна?
    ... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[20]: Языки общего назначения не имеют смысла!
    От: Gaperton http://gaperton.livejournal.com
    Дата: 18.05.12 10:07
    Оценка: 36 (1) :))
    Здравствуйте, AndrewVK, Вы писали:

    K>>Скорее так: годами и десятками лет пытаются выразить специфику неудобными конструкциями языков общего назначения. Колются, плачут, но продолжают мучиться.


    AVK>Ну давай проведем эксперимент. Вот типовой серверный бизнес-код на универсальном языке — C#. Давай ты продемонстрируешь, как все будет круто на DSL?


    Да без проблем.

    rollback for each doc in XO


    Одного не пойму — почему они все стушевались. Смешной вопрос для труъ-ценителей DSL, право .
    Re[53]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 19.05.12 11:16
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>Графические ДСЛ не масштабируются.


    Почему?
    Схемы электрические принципиальные, например, спокойно масштабируются. Вводи себе блоки с интерфейсами, вводи сущность "шина", объединяющая несколько связей и т.д.
    Масштабирование зависит от поддержки языка и инструмента. В нормальных графических редакторах схем кликнул по блоку — и входишь в редактирование блока. Или выделил несколько элементов — и в контекстном меню сказал им "сделать из них блок" и т.д.

    Иначе бы схемы из миллионов вентилей просто не взлетели бы...
    Re[55]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 19.05.12 11:18
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>Здравствуйте, AndrewVK, Вы писали:


    AVK>>Ты действительно в это веришь?

    WH>Я еще не видел ни одного графического ДСЛ, который бы не скатывался в говно, но больших задачах.

    Не смотрел, потому и не видел. А как же железки разрабатывают? Ты утонешь уже в сотнях элементов на одном уровне, а их сейчас на многие тысячи и даже миллионы в процах.
    Re[32]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 19.05.12 11:35
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    V>>Я не считаю таковым JS и не согласен приравнивать его к C++. JS ничем не лучше Logo в своей ограниченности, идущей изкаробки. Поэтому на JS можно делать свои DSL, которые заведомо будут specific.

    S>И всё же в самом С++ нет никаких LoadLibrary и GetProcAddress.

    А ему и не надо. Нам были нужны произвольные внешние библиотеки, чтобы из безопасного DSL сделать опасный язык общего назначения. С++ — это как раз тот язык, на котором эти опасные DLL общего назначения можно писать, т.е. ему для этого не нужны дополнительные ср-ва. Могу 100-й раз напомнить про CRT. С этого CRT взлетает весь современный нейтив, большего и не надо.
    Re[56]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 19.05.12 11:54
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    V>Не смотрел, потому и не видел.

    Смотрел. Все ужасны.

    V>А как же железки разрабатывают? Ты утонешь уже в сотнях элементов на одном уровне, а их сейчас на многие тысячи и даже миллионы в процах.

    Verilog, VHDL,...
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[39]: Не понял
    От: Wolverrum Ниоткуда  
    Дата: 19.05.12 13:53
    Оценка:
    WH>Неверный посыл.
    WH>ДСЛ нужен для решения конкретной задачи.

    Один вопрос: "Зачем нужен?"
    Я вижу, разработку ДСЛ лишь если (ВремяРазработкиТестированияДСЛ+ВремяРешенияКонкретнойЗадачиВТерминахДСЛ) << (ВремяРешенияКонкретнойЗадачи)
    Мой опыт подсказывает, что вот это неравенство — не в пользу разработки/нужности ДСЛ для конкретных задач в подавляющем большинстве случаев (ergo — ...) Нет, если под конкретным задачами подразумевается ДСЛи вида "аналог синтаксиса params" или там "with", то вопрос снимается.
    Re[40]: Не понял
    От: WolfHound  
    Дата: 19.05.12 14:03
    Оценка:
    Здравствуйте, Wolverrum, Вы писали:

    W>Я вижу, разработку ДСЛ лишь если (ВремяРазработкиТестированияДСЛ+ВремяРешенияКонкретнойЗадачиВТерминахДСЛ) << (ВремяРешенияКонкретнойЗадачи)

    И почему <<?
    Даже при == создание ДСЛ имеет смысл.
    Ибо поддержка потом будет намного проще.

    А это все задачи, которые чуть сложнее хелловорлд.

    W>Мой опыт подсказывает, что вот это неравенство — не в пользу разработки/нужности ДСЛ для конкретных задач в подавляющем большинстве случаев (ergo — ...)

    И что же за опыт у тебя такой?
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[5]: Есть просьба
    От: Wolverrum Ниоткуда  
    Дата: 19.05.12 14:06
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>Благодаря тому, что все будет на ДСЛях по ним будет сгенерирован не только компилятор, но и ИДЕ. Это дело техники.

    WH>Так же для ИДЕ понадобятся специальные ДСЛ для описания рефакторингов и форматирования.
    WH>С другой стороны ИДЕ не будет использовать трансформации кода.

    Осильте сперва документацию хоть под какой-нибудь Немерле, а потом удже расписывайте про воздушные замки. Меня лазить по плохо комментированным исходникам N совершенно не прёт — время для меня стало сильно дороже сакрального знания.
    Я про этот теракосяк проекта давно говорил, говорю и буду говорить. Мало того — мое предложение по документирования осталось неуслышанным, и в репозиторий я так и не был допущен.
    Re[6]: Есть просьба
    От: WolfHound  
    Дата: 19.05.12 14:15
    Оценка:
    Здравствуйте, Wolverrum, Вы писали:

    W>Осильте сперва документацию хоть под какой-нибудь Немерле, а потом удже расписывайте про воздушные замки.

    Документации достаточно.
    http://rsdn.ru/summary/3766.xml

    W>Меня лазить по плохо комментированным исходникам N совершенно не прёт — время для меня стало сильно дороже сакрального знания.

    Меня Н1 не волнует. Совсем.
    Я правлю Н1 только если натыкаюсь на ограничения которые мне мешают.
    А это случается очень редко.

    W>Я про этот теракосяк проекта давно говорил, говорю и буду говорить. Мало того — мое предложение по документирования осталось неуслышанным, и в репозиторий я так и не был допущен.

    Разговаривай с Владом.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[41]: Не понял
    От: Wolverrum Ниоткуда  
    Дата: 19.05.12 14:20
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>Здравствуйте, Wolverrum, Вы писали:


    W>>Я вижу, разработку ДСЛ лишь если (ВремяРазработкиТестированияДСЛ+ВремяРешенияКонкретнойЗадачиВТерминахДСЛ) << (ВремяРешенияКонкретнойЗадачи)

    WH>И почему <<?
    WH>Даже при == создание ДСЛ имеет смысл.
    WH>Ибо поддержка потом будет намного проще.

    Про поддержку бабушка надвое говорит: микрофичи (как обычно бывает с большинством требований) вносятся дешево скорее всего в обоих случаях, поэтому поддержка сильно проще не будет.

    При == может иметь смысл, если разработчик/команда уже знает и умеет. Иначе — появляется слагаемое ВремяНаИзучениеПарадигмыИСоответствующихСредств — снова не в пользу ДСЛ "во все дыры для конкретных задач чуть сложнее хелловорлд"

    W>>Мой опыт подсказывает, что вот это неравенство — не в пользу разработки/нужности ДСЛ для конкретных задач в подавляющем большинстве случаев (ergo — ...)

    WH>И что же за опыт у тебя такой?
    Ну какой есть, читай ветку — я тут примерно месяц назад отписывался уже.
    Re[42]: Не понял
    От: WolfHound  
    Дата: 19.05.12 14:33
    Оценка:
    Здравствуйте, Wolverrum, Вы писали:

    W>Ну какой есть, читай ветку — я тут примерно месяц назад отписывался уже.

    Пролистал. Там ты тоже юлишь и уходишь от ответов.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[7]: Есть просьба
    От: Wolverrum Ниоткуда  
    Дата: 19.05.12 14:40
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>Документации достаточно.

    WH>http://rsdn.ru/summary/3766.xml
    Ну так и как из этой документации понять как сваять макрос для генерации множества производных System.Delegate? Год назад фокус не прошел. С тех пор что-то кардинально поменялось
    Автор: _d_m_
    Дата: 01.04.12
    ?

    WH>Разговаривай с Владом.

    Снова?..
    Re[43]: Не понял
    От: Wolverrum Ниоткуда  
    Дата: 19.05.12 15:05
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>Здравствуйте, Wolverrum, Вы писали:


    W>>Ну какой есть, читай ветку — я тут примерно месяц назад отписывался уже.

    WH>Пролистал. Там ты тоже юлишь и уходишь от ответов.
    Хм, в этой ветке мне и вопросов-то не было задано ранее — одни лишь оправдания.
    И вообще я ошибся — оказывается, я отписывался в другую тему — Влада про "мысли о ДСЛ"
    Автор: Wolverrum
    Дата: 17.04.12
    но и там не сказать, что я как-то юлил и уходил.
    Re: Языки общего назначения не имеют смысла!
    От: batu Украина  
    Дата: 19.05.12 15:16
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>Здравствуйте, VoidEx, Вы писали:


    VE>>А как бы стоило сделать на твой взгляд?

    WH>Никак. Языки общего назначения не имеют смысла.
    WH>Чем больше изучаю, тем сильнее утверждаюсь в этом мнении.


    WH>56 страниц сильно оптимизированного кода на жабе (год разработки) против 17 строк на ДСЛ (год разработки компилятора).

    WH>ДСЛ работал в 2 раза быстрее. Плюс на этом ДСЛ еще кучу кода, потом понаписали. Как следствие сэкономили десятилетия работы.
    WH>Про то, что код на ДСЛ проще понять, поддерживать, развивать и там намного меньше багов я думаю можно даже не заикаться.

    Я здесь вижу два опрометчивых момента.
    1. Не мудро говорить обо всем. На сегодняшний момент да, но мало ли что ждет нас в будущем.
    2. А почему обязательно противоречие или язык общего назначения или DSL? Может это временный недостаток или языков называемых общего назначения или конструкторов языков DSL.
    Re[41]: Не понял
    От: Mamut Швеция http://dmitriid.com
    Дата: 19.05.12 15:25
    Оценка:
    WH>Даже при == создание ДСЛ имеет смысл.
    WH>Ибо поддержка потом будет намного проще.

    Мне интересно, откуда этот миф про легкую поддержку взялся.


    dmitriid.comGitHubLinkedIn
    Re[42]: Не понял
    От: WolfHound  
    Дата: 19.05.12 15:33
    Оценка:
    Здравствуйте, Mamut, Вы писали:

    WH>>Даже при == создание ДСЛ имеет смысл.

    WH>>Ибо поддержка потом будет намного проще.
    M>Мне интересно, откуда этот миф про легкую поддержку взялся.
    Это не миф. Это опыт поддержки нескольких ДСЛ.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[44]: Не понял
    От: WolfHound  
    Дата: 19.05.12 15:37
    Оценка:
    Здравствуйте, Wolverrum, Вы писали:

    W>Хм, в этой ветке мне и вопросов-то не было задано ранее — одни лишь оправдания.

    W>И вообще я ошибся — оказывается, я отписывался в другую тему — Влада про "мысли о ДСЛ"
    Автор: Wolverrum
    Дата: 17.04.12
    но и там не сказать, что я как-то юлил и уходил.

    Так тебе был задан прямой вопрос как ты ДСЛ делал?
    На него ты не ответил.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[8]: Есть просьба
    От: WolfHound  
    Дата: 19.05.12 15:43
    Оценка:
    Здравствуйте, Wolverrum, Вы писали:

    W>Ну так и как из этой документации понять как сваять макрос для генерации множества производных System.Delegate?

    Очевидно также как и любой другой член класса.
    <[decl: public delegate Bar(asd : string) : int; ]>;

    W>Год назад фокус не прошел. С тех пор что-то кардинально поменялось
    Автор: _d_m_
    Дата: 01.04.12
    ?

    Это как относится к твоему предыдущему вопросу?

    WH>>Разговаривай с Владом.

    W>Снова?..
    Немерлом занимается Влад.
    Я немерлом не занимаюсь.
    Ну и почему ты говоришь со мной?
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[43]: Не понял
    От: Mamut Швеция http://dmitriid.com
    Дата: 19.05.12 15:44
    Оценка: :)
    WH>>>Даже при == создание ДСЛ имеет смысл.
    WH>>>Ибо поддержка потом будет намного проще.
    M>>Мне интересно, откуда этот миф про легкую поддержку взялся.
    WH>Это не миф. Это опыт поддержки нескольких ДСЛ.

    А. Ну так и думал. Один человек свой личный опыт обобщает до всех. Где-то я это видел уже. Скучно и предсказуемо.


    dmitriid.comGitHubLinkedIn
    Re[2]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 19.05.12 15:48
    Оценка: +1
    Здравствуйте, batu, Вы писали:

    B>1. Не мудро говорить обо всем. На сегодняшний момент да, но мало ли что ждет нас в будущем.

    Других вариантов не будет.
    Достичь большей выразительности, чем язык, на котором задача описывается напрямую в терминах предметной области невозможно теоритически.

    B>2. А почему обязательно противоречие или язык общего назначения или DSL? Может это временный недостаток или языков называемых общего назначения или конструкторов языков DSL.

    Это не временный недостаток.
    Это фундаментально.
    Просто по тому, что ЯОНы имеют вычислительную модель чуть менее чем всегда не имеющую ничего общего с предметной областью.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[44]: Не понял
    От: WolfHound  
    Дата: 19.05.12 15:52
    Оценка:
    Здравствуйте, Mamut, Вы писали:

    M>А. Ну так и думал. Один человек свой личный опыт обобщает до всех. Где-то я это видел уже. Скучно и предсказуемо.

    Когда в 100% случаев получается один и тот же результат...
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[45]: Не понял
    От: Wolverrum Ниоткуда  
    Дата: 19.05.12 16:04
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>Так тебе был задан прямой вопрос как ты ДСЛ делал?

    А вот так:
    1. Собрал начальные требования
    2. Происследовал форму представления (разработали синтаксис удобный и понятный для конечного пользователя)
    3. Закодировал реализацию (разбор, семантика)
    4. Покрыл тестами
    5. Задокументировал (язык, правила обработки, нюансы)

    Как-то так делал. Подозреваю, есть непонятный нюанс. Раскрою его. "Задокументировал" — понятным языком описал сам ДСЛ, утилиты для удобного его ипользования, командные строки, особенности работы с внешними системами (БД, планировщики, веб-сайты, и т.п.), и своевременно обновляю документацию, чтобы не возникало лишних вопросов по поводу "А как там сделать так, чтобы...?"
    Re[45]: Не понял
    От: Mamut Швеция http://dmitriid.com
    Дата: 19.05.12 16:06
    Оценка:
    M>>А. Ну так и думал. Один человек свой личный опыт обобщает до всех. Где-то я это видел уже. Скучно и предсказуемо.
    WH>Когда в 100% случаев получается один и тот же результат...

    Это все равно ничего не значит.

    Потому что, например: http://www.cis.uab.edu/courses/managed/cs593/spring2004/DSLAnnotatedBib.pdf

    The disadvantages of the use of a DSL are:
    — The costs of designing, implementing and maintaining a DSL.


    Но да. У нас есть Wolfhound, его личный экспириенс === экспириенс бога, и не обсуждается, а принимается на веру


    dmitriid.comGitHubLinkedIn
    Re[9]: Есть просьба
    От: Wolverrum Ниоткуда  
    Дата: 19.05.12 16:27
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>Здравствуйте, Wolverrum, Вы писали:


    W>>Ну так и как из этой документации понять как сваять макрос для генерации множества производных System.Delegate?

    WH>Очевидно также как и любой другой член класса.
    WH><[decl: public delegate Bar(asd : string) : int; ]>;
    А потом
    <[decl: public delegate Bar(asd : string; fgh: string) : int; ]>;
    <[decl: public delegate Bar(asd : string; fgh: string; jkl: string) : int; ]>;
    <[decl: public delegate Bar(asd : string; fgh: string; jkl: string; ...) : int; ]>;
    а потом
    <[decl: public delegate Bar(asd : int; fgh: int) : int; ]>;
    <[decl: public delegate Bar(asd : int; fgh: int; jkl: int) : int; ]>;
    <[decl: public delegate Bar(asd : int; fgh: int; jkl: int; ...) : int; ]>;
    а потом...

    WH>Это как относится к твоему предыдущему вопросу?

    А так — документация по макрам скудна и отрывочна до безобразия.
    Re[46]: Не понял
    От: WolfHound  
    Дата: 19.05.12 16:31
    Оценка:
    Здравствуйте, Mamut, Вы писали:

    M>Потому что, например: http://www.cis.uab.edu/courses/managed/cs593/spring2004/DSLAnnotatedBib.pdf

    M>

    M>The disadvantages of the use of a DSL are:
    M>- The costs of designing, implementing and maintaining a DSL.

    Фреймворк, который возникает в 100% случае при написании чего-то большого не нужно проектировать, реализовывать и поддерживать.
    Я тебя правильно понял?
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[46]: Не понял
    От: WolfHound  
    Дата: 19.05.12 16:32
    Оценка:
    Здравствуйте, Wolverrum, Вы писали:

    WH>>Так тебе был задан прямой вопрос как ты ДСЛ делал?

    W>А вот так:
    И опять ничего не сказал.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[47]: Не понял
    От: Wolverrum Ниоткуда  
    Дата: 19.05.12 17:02
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>Здравствуйте, Wolverrum, Вы писали:


    WH>>>Так тебе был задан прямой вопрос как ты ДСЛ делал?

    W>>А вот так:
    WH>И опять ничего не сказал.
    А что ты хотел услышать? С радостию расскажу.
    Re[47]: Не понял
    От: Mamut Швеция http://dmitriid.com
    Дата: 19.05.12 17:03
    Оценка:
    M>>Потому что, например: http://www.cis.uab.edu/courses/managed/cs593/spring2004/DSLAnnotatedBib.pdf
    M>>

    M>>The disadvantages of the use of a DSL are:
    M>>- The costs of designing, implementing and maintaining a DSL.

    WH>Фреймворк, который возникает в 100% случае при написании чего-то большого не нужно проектировать, реализовывать и поддерживать.
    WH>Я тебя правильно понял?

    Нет, неправильно. Не говоря о том, что это вообще никак не следует из моих слов.

    ЗЫ. Вообще, казалось бы, вот оно, выражение, «X легче, чем Y». Наверное, есть какие-то внятные способы описать, почему так? Более того, это выражение постоянно используется. Можно же предположить, что где-то кто-то уже внятно описал, почему он так считает, приведя примеры и/или доказательства. Ан нет. Есть только это заявление. Просишь объяснить, откуда оно появилось, и надеешься, что вот, сейчас будет объяснение. Неа. «Вы все тупые и не лечитесь, у меня опыт». И если бы так было в первый раз.


    dmitriid.comGitHubLinkedIn
    Re[48]: Не понял
    От: WolfHound  
    Дата: 19.05.12 17:19
    Оценка:
    Здравствуйте, Mamut, Вы писали:

    WH>>Фреймворк, который возникает в 100% случае при написании чего-то большого не нужно проектировать, реализовывать и поддерживать.

    WH>>Я тебя правильно понял?
    M>Нет, неправильно.
    И к чему ты это написал?

    M>Не говоря о том, что это вообще никак не следует из моих слов.

    Именно это и следует.

    M>ЗЫ. Вообще, казалось бы, вот оно, выражение, «X легче, чем Y». Наверное, есть какие-то внятные способы описать, почему так? Более того, это выражение постоянно используется. Можно же предположить, что где-то кто-то уже внятно описал, почему он так считает, приведя примеры и/или доказательства. Ан нет. Есть только это заявление. Просишь объяснить, откуда оно появилось, и надеешься, что вот, сейчас будет объяснение. Неа. «Вы все тупые и не лечитесь, у меня опыт». И если бы так было в первый раз.

    Много раз описано в этой теме. Но чукча не читатель.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[3]: Языки общего назначения не имеют смысла!
    От: batu Украина  
    Дата: 19.05.12 17:20
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>Здравствуйте, batu, Вы писали:


    B>>1. Не мудро говорить обо всем. На сегодняшний момент да, но мало ли что ждет нас в будущем.

    WH>Других вариантов не будет.
    WH>Достичь большей выразительности, чем язык, на котором задача описывается напрямую в терминах предметной области невозможно теоритически.
    И где противоречие? Почему язык общего назначения не может работать в терминах предметной области?

    B>>2. А почему обязательно противоречие или язык общего назначения или DSL? Может это временный недостаток или языков называемых общего назначения или конструкторов языков DSL.

    WH>Это не временный недостаток.
    WH>Это фундаментально.
    WH>Просто по тому, что ЯОНы имеют вычислительную модель чуть менее чем всегда не имеющую ничего общего с предметной областью.
    Та не надо про вычислительную модель.. Она так же мало имеет общего и с языками общего назначения.. Так что это не аргумент совсем..
    Ну, и, кроме всего, у меня есть универсальная модель.
    Re[4]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 19.05.12 17:32
    Оценка:
    Здравствуйте, batu, Вы писали:

    B>И где противоречие? Почему язык общего назначения не может работать в терминах предметной области?

    По тому, что я не знаю ни одной предметной области, которая бы формулировалась бы в терминах, например методов и классов.

    WH>>Просто по тому, что ЯОНы имеют вычислительную модель чуть менее чем всегда не имеющую ничего общего с предметной областью.

    B>Та не надо про вычислительную модель.. Она так же мало имеет общего и с языками общего назначения.. Так что это не аргумент совсем..
    Так я и написал, что вычислительная модель языка общего назначения не имеет никакого отношения к задаче.
    Читай иногда то, что тебе пишут.

    B>Ну, и, кроме всего, у меня есть универсальная модель.

    Нет у тебя такой модели.
    Просто по тому, что ее не существует в принципе.

    Да и просто тот факт, что ты в прошлый раз, когда пытался ее объяснять начал петь про адресацию говорит о том, что ты не понимаешь что ты делаешь.
    Ибо есть масса вычислительных моделей, которые ничего ни про какую адресацию не знают.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[5]: Языки общего назначения не имеют смысла!
    От: batu Украина  
    Дата: 19.05.12 18:07
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>Здравствуйте, batu, Вы писали:


    B>>И где противоречие? Почему язык общего назначения не может работать в терминах предметной области?

    WH>По тому, что я не знаю ни одной предметной области, которая бы формулировалась бы в терминах, например методов и классов.
    ЯОН не обязательно должны содержать методы и классы. Это говорить только об ООП и императивных языках. Кроме этой парадигмы существует еще масса других.

    WH>>>Просто по тому, что ЯОНы имеют вычислительную модель чуть менее чем всегда не имеющую ничего общего с предметной областью.

    B>>Та не надо про вычислительную модель.. Она так же мало имеет общего и с языками общего назначения.. Так что это не аргумент совсем..
    WH>Так я и написал, что вычислительная модель языка общего назначения не имеет никакого отношения к задаче.
    WH>Читай иногда то, что тебе пишут.
    Да. Не внимательно прочитал. Но, тем не менее, я по прежнему сомневаюсь в правоте вашего высказывания насчет вычислительной модели. Объяснитель о какой можели речь. Их много. И языков много.

    B>>Ну, и, кроме всего, у меня есть универсальная модель.

    WH>Нет у тебя такой модели.
    WH>Просто по тому, что ее не существует в принципе.

    Поясните о каком принципе идет речь. Мне не понятно.

    WH>Да и просто тот факт, что ты в прошлый раз, когда пытался ее объяснять начал петь про адресацию говорит о том, что ты не понимаешь что ты делаешь.

    Я не говорил что не понимаю. Я говорил что не до конца понимаю. Сомнения признак интеллекта. Я б вам тоже советовал сомневаться.
    WH>Ибо есть масса вычислительных моделей, которые ничего ни про какую адресацию не знают.
    Да. И что? В моем языке тоже нет адресов, есть имена. Но фактически-то это адреса. И вообще, считаю это одним из главных вопросом архитектуры компьютера особенно в части его возможностей эффективно реализовывать эти самые ЯОН и DSL тоже. Скажем так что меня не совсем устроила адресация та, которая принята в современных компьютерах. Там есть что добавить.
    Re[6]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 19.05.12 18:19
    Оценка:
    Здравствуйте, batu, Вы писали:

    B>ЯОН не обязательно должны содержать методы и классы. Это говорить только об ООП и императивных языках. Кроме этой парадигмы существует еще масса других.

    Я в курсе.
    Но к ним это тоже относится.
    Только вместо методов и классов будут объекты и сообщения, АТД и функции, итд.

    B>Да. Не внимательно прочитал. Но, тем не менее, я по прежнему сомневаюсь в правоте вашего высказывания насчет вычислительной модели. Объяснитель о какой можели речь. Их много. И языков много.

    Я все они чуть менее чем всегда не имеют никакого отношения к конкретной предметной области.

    WH>>Просто по тому, что ее не существует в принципе.

    B>Поясните о каком принципе идет речь. Мне не понятно.
    Ну так покажи мне вычислительную модель которая одинаково хорошо подходит и для парсера и для запросов к базе данных.
    Кстати и парсеры и базы данных бывают очень разными и языки им нужны разные

    WH>>Да и просто тот факт, что ты в прошлый раз, когда пытался ее объяснять начал петь про адресацию говорит о том, что ты не понимаешь что ты делаешь.

    B>Я не говорил что не понимаю. Я говорил что не до конца понимаю. Сомнения признак интеллекта. Я б вам тоже советовал сомневаться.
    Это не ты говоришь. Это я говорю.

    B>Да. И что? В моем языке тоже нет адресов, есть имена. Но фактически-то это адреса. И вообще, считаю это одним из главных вопросом архитектуры компьютера особенно в части его возможностей эффективно реализовывать эти самые ЯОН и DSL тоже. Скажем так что меня не совсем устроила адресация та, которая принята в современных компьютерах. Там есть что добавить.

    Вот я и говорю, что ты не понимаешь что такое предметно ориентированные вычислительные модели.
    Они чуть менее чем всегда не имеют никакой адресации.

    А то во что они транслируются, не имеет никакого значения.
    Это детали реализации, не имеющие к самому языку никакого отношения.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[49]: Не понял
    От: Mamut Швеция http://dmitriid.com
    Дата: 19.05.12 18:22
    Оценка:
    M>>Не говоря о том, что это вообще никак не следует из моих слов.
    WH>Именно это и следует.

    Нет, не следует. Даже близко. С логикой у тебя сильнейшие проблемы.

    M>>ЗЫ. Вообще, казалось бы, вот оно, выражение, «X легче, чем Y». Наверное, есть какие-то внятные способы описать, почему так? Более того, это выражение постоянно используется. Можно же предположить, что где-то кто-то уже внятно описал, почему он так считает, приведя примеры и/или доказательства. Ан нет. Есть только это заявление. Просишь объяснить, откуда оно появилось, и надеешься, что вот, сейчас будет объяснение. Неа. «Вы все тупые и не лечитесь, у меня опыт». И если бы так было в первый раз.

    WH>Много раз описано в этой теме. Но чукча не читатель.

    Ссылку в студию, раз описано.


    dmitriid.comGitHubLinkedIn
    Re[7]: Языки общего назначения не имеют смысла!
    От: batu Украина  
    Дата: 19.05.12 18:44
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>Здравствуйте, batu, Вы писали:


    B>>ЯОН не обязательно должны содержать методы и классы. Это говорить только об ООП и императивных языках. Кроме этой парадигмы существует еще масса других.

    WH>Я в курсе.
    WH>Но к ним это тоже относится.
    WH>Только вместо методов и классов будут объекты и сообщения, АТД и функции, итд.
    У Пролога нет ни объектов ни функций..

    B>>Да. Не внимательно прочитал. Но, тем не менее, я по прежнему сомневаюсь в правоте вашего высказывания насчет вычислительной модели. Объяснитель о какой можели речь. Их много. И языков много.

    WH>Я все они чуть менее чем всегда не имеют никакого отношения к конкретной предметной области.
    В общем случае, да. Но...

    WH>>>Просто по тому, что ее не существует в принципе.

    B>>Поясните о каком принципе идет речь. Мне не понятно.
    WH>Ну так покажи мне вычислительную модель которая одинаково хорошо подходит и для парсера и для запросов к базе данных.
    WH>Кстати и парсеры и базы данных бывают очень разными и языки им нужны разные
    Запросто. Но, по парсеру это ж надо много текста.. хотя бы пару страниц что б было понятно.. Ну, и по базам данных надо пообщаться.. Кстати, ото что называется связями с таблицами это тоже адрес.. в моем представлении.. Ну, и еще много спорных тем.. Тоже не здесь же..
    Кстати, по парсерам.. Меня больше всего раздражает то, что нет отпределений что такое буква..Писать, то пишут.. А четкого определения алфавита нет..

    WH>>>Да и просто тот факт, что ты в прошлый раз, когда пытался ее объяснять начал петь про адресацию говорит о том, что ты не понимаешь что ты делаешь.

    B>>Я не говорил что не понимаю. Я говорил что не до конца понимаю. Сомнения признак интеллекта. Я б вам тоже советовал сомневаться.
    WH>Это не ты говоришь. Это я говорю.
    И я говорю..

    WH>А то во что они транслируются, не имеет никакого значения.

    WH>Это детали реализации, не имеющие к самому языку никакого отношения.
    К языку не имеют, а к его реализации очень даже имеют.. И такая фишка как стековые регистры в компьютерах тоже пояилась для реализации функций и алгоритмов разбора. В первых компах их не было. Хотя, казалось, ну, каким боком регистры к реализации языка. И вообще, дъявол частенько именно в деталях..
    Re[50]: Не понял
    От: WolfHound  
    Дата: 19.05.12 18:47
    Оценка: -1
    Здравствуйте, Mamut, Вы писали:

    M>Нет, не следует. Даже близко. С логикой у тебя сильнейшие проблемы.

    Выключи дурака.
    Ты приводишь это как недостаток ДСЛ.
    Значит, при другом подходе это не требуется.
    А другой подход это колбасить все на языке общего назначения.

    Но как мы выяснили это не правда. Так что к чему ты это написал совершенно не ясно.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[8]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 19.05.12 19:07
    Оценка:
    Здравствуйте, batu, Вы писали:

    B>У Пролога нет ни объектов ни функций..

    И его примитивы тоже не имеют отношения к чуть менее чем всем предметным областям.
    Ты можешь назвать любой другой язык и с ним будет та же история.
    Ты действительно не можешь понять, что я тебе говорю или прикалываешься?

    B>>>Да. Не внимательно прочитал. Но, тем не менее, я по прежнему сомневаюсь в правоте вашего высказывания насчет вычислительной модели. Объяснитель о какой можели речь. Их много. И языков много.

    WH>>Я все они чуть менее чем всегда не имеют никакого отношения к конкретной предметной области.
    B>В общем случае, да. Но...
    Никаких но.

    WH>>>>Просто по тому, что ее не существует в принципе.

    B>>>Поясните о каком принципе идет речь. Мне не понятно.
    WH>>Ну так покажи мне вычислительную модель которая одинаково хорошо подходит и для парсера и для запросов к базе данных.
    WH>>Кстати и парсеры и базы данных бывают очень разными и языки им нужны разные
    B>Запросто.
    А ничего что SQL и EBNF не имеют ничего общего?
    Да даже PEG и EBNF не смотря на внешнюю похожесть не имеют между собой ничего общего кроме того что их для разбора текста используют.

    B>Но, по парсеру это ж надо много текста.. хотя бы пару страниц что б было понятно..

    По какому парсеру?
    Ничего что я не один десяток способов разбора текста знаю?
    И они все очень разные.

    B>Ну, и по базам данных надо пообщаться..

    По каким базам данных?
    Они все очень разные.

    B>Кстати, ото что называется связями с таблицами это тоже адрес.. в моем представлении.. Ну, и еще много спорных тем.. Тоже не здесь же..

    В твоем представлении очень много странного.

    B>Кстати, по парсерам.. Меня больше всего раздражает то, что нет отпределений что такое буква..Писать, то пишут.. А четкого определения алфавита нет..

    Как это нет? Алфавит это конечное множество букв.
    Больше ничего не нужно.

    WH>>А то во что они транслируются, не имеет никакого значения.

    WH>>Это детали реализации, не имеющие к самому языку никакого отношения.
    B>К языку не имеют, а к его реализации очень даже имеют..
    И к реализации часто тоже не имеют.
    Ибо язык обычно переписывают в что-то очень похожее.
    Иначе озвереешь.

    B>И такая фишка как стековые регистры в компьютерах тоже пояилась для реализации функций и алгоритмов разбора. В первых компах их не было. Хотя, казалось, ну, каким боком регистры к реализации языка. И вообще, дъявол частенько именно в деталях..

    Я тебе по секрету скажу, что и сейчас они далеко не везде есть.
    И даже там где есть их не всегда по прямому назначению используют.
    Ибо не все языки могут использовать обычный стек, на который заточены push/pop/call/ret/...
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[51]: Не понял
    От: Mamut Швеция http://dmitriid.com
    Дата: 19.05.12 19:15
    Оценка:
    M>>Нет, не следует. Даже близко. С логикой у тебя сильнейшие проблемы.
    WH>Выключи дурака.

    Советую этого тебе

    WH>Ты приводишь это как недостаток ДСЛ.


    Это — что?

    WH>Значит, при другом подходе это не требуется.

    WH>А другой подход это колбасить все на языке общего назначения.
    WH>Но как мы выяснили это не правда. Так что к чему ты это написал совершенно не ясно.

    Мде. Из фразы «я не верю, что поддержка DSL намного легче, чем поддержка других решений» (а именно это я и сказал, а не то, что кажется твоему воспаленному воображению) никак не следует «я считаю, что для других решений поддержка не требуется вообще».

    Настоятельно советую тебе две вещи:
    — пройти курс логики
    — научиться понимать, что тебе пишут


    И да, я все еще с нетерпением жду ссылку на якобы присутсвующее в обсуждении объяснение, почему DSL'и поддерживать намного легче. Хотя да, тебе удобнее считать всех вокруг тупыми и бороться с создаваемыми тобой же вымышленными врагами, чем отвечать на вопросы.


    dmitriid.comGitHubLinkedIn
    Re[9]: Языки общего назначения не имеют смысла!
    От: batu Украина  
    Дата: 19.05.12 19:36
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>Здравствуйте, batu, Вы писали:


    B>>У Пролога нет ни объектов ни функций..

    WH>И его примитивы тоже не имеют отношения к чуть менее чем всем предметным областям.
    WH>Ты можешь назвать любой другой язык и с ним будет та же история.
    WH>Ты действительно не можешь понять, что я тебе говорю или прикалываешься?
    Нет. Прсото пример привел..

    B>>В общем случае, да. Но...

    WH>Никаких но.
    Все таки но..

    WH> А ничего что SQL и EBNF не имеют ничего общего?

    У меня есть общее и в бвзвх данных и EBNF. И даже формат хранения общий. У меня он вообще единый для всего.

    WH>Да даже PEG и EBNF не смотря на внешнюю похожесть не имеют между собой ничего общего кроме того что их для разбора текста используют.

    Да. Там есть недостатки.. И вообще правила ФБН и сами регуляоные выражения выбраны не удачно. В свое время это был шаг вперед.

    B>>Но, по парсеру это ж надо много текста.. хотя бы пару страниц что б было понятно..

    WH>По какому парсеру?
    По своему парсеру. И синтаксис вообще не отличается от самого языка.Обычная программа. Даже сразу транслятор получаем. Без вяких обработок грамматик.
    WH>Ничего что я не один десяток способов разбора текста знаю?
    WH>И они все очень разные.
    В каком смысле разные? Один и тот же разбор регулярных выражений.. Ну, у функциональных языков есть средства для разбора более широкого класса грамматик.

    WH>По каким базам данных?

    WH>Они все очень разные.
    Они разные. У меня одна.

    B>>Кстати, ото что называется связями с таблицами это тоже адрес.. в моем представлении.. Ну, и еще много спорных тем.. Тоже не здесь же..

    WH>В твоем представлении очень много странного.
    Согласен. Потому мне и трудно объяснять. Даже с терминологией проблемы..

    B>>Кстати, по парсерам.. Меня больше всего раздражает то, что нет отпределений что такое буква..Писать, то пишут.. А четкого определения алфавита нет..

    WH>Как это нет? Алфавит это конечное множество букв.
    WH>Больше ничего не нужно.
    Больше ничего не нужно. Нужно только именно так и определять. Обычно этого определения нет. Подразумевается. Ну и стандарты. А я именно так и определяю.

    WH>>>А то во что они транслируются, не имеет никакого значения.

    WH>>>Это детали реализации, не имеющие к самому языку никакого отношения.
    B>>К языку не имеют, а к его реализации очень даже имеют..
    WH>И к реализации часто тоже не имеют.
    WH>Ибо язык обычно переписывают в что-то очень похожее.
    WH>Иначе озвереешь.
    Опять согласен. Когда проблема известна осталось только ее решить. А решение одно. Убрать все лишнее и выделить минимум с помощью которого можно построить все остальное. У меня это и получилось. Ц меня всего 5 базовых понятий из которых строится вообще все.

    B>>И такая фишка как стековые регистры в компьютерах тоже пояилась для реализации функций и алгоритмов разбора. В первых компах их не было. Хотя, казалось, ну, каким боком регистры к реализации языка. И вообще, дъявол частенько именно в деталях..

    WH>Я тебе по секрету скажу, что и сейчас они далеко не везде есть.
    WH>И даже там где есть их не всегда по прямому назначению используют.
    WH>Ибо не все языки могут использовать обычный стек, на который заточены push/pop/call/ret/...
    Как я понимаю детали тебя не интересуют.. Тогда какой смысл их обсуждать.. Согласен да и все..
    Re[21]: Языки общего назначения не имеют смысла!
    От: Mamut Швеция http://dmitriid.com
    Дата: 19.05.12 19:54
    Оценка:
    VD>Так что остается только одна проблема. Как заставить неверующих Фом хотя бы взглянуть на то, что у нас получается. Я уже не говорю об использовании.

    Поблема такая же, как и с Н1:
    — сделать хоть один killer-проект на этом
    — сделать один killer-туториал по этому
    — документация
    — популяризация


    dmitriid.comGitHubLinkedIn
    Re[10]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 19.05.12 20:34
    Оценка:
    Здравствуйте, batu, Вы писали:

    B>>>У Пролога нет ни объектов ни функций..

    WH>>И его примитивы тоже не имеют отношения к чуть менее чем всем предметным областям.
    WH>>Ты можешь назвать любой другой язык и с ним будет та же история.
    WH>>Ты действительно не можешь понять, что я тебе говорю или прикалываешься?
    B>Нет. Прсото пример привел..
    И зачем ты это сделал?
    Учитывая, что он 100% в мою пользу.

    WH>> А ничего что SQL и EBNF не имеют ничего общего?

    B>У меня есть общее и в бвзвх данных и EBNF. И даже формат хранения общий. У меня он вообще единый для всего.
    В XML тоже что угодно запихнуть можно.
    Дальше что?
    Ибо когда мы попытаемся это все выполнить, то поймем что ничего общего между ними нет.

    WH>>Да даже PEG и EBNF не смотря на внешнюю похожесть не имеют между собой ничего общего кроме того что их для разбора текста используют.

    B>Да. Там есть недостатки.. И вообще правила ФБН и сами регуляоные выражения выбраны не удачно. В свое время это был шаг вперед.
    Ты говоришь о чем-то своем.
    Причем совершенно не в тему.

    B>Согласен. Потому мне и трудно объяснять. Даже с терминологией проблемы..

    Терминология фигня. Проблемы с логикой.

    WH>>Как это нет? Алфавит это конечное множество букв.

    WH>>Больше ничего не нужно.
    B>Больше ничего не нужно. Нужно только именно так и определять. Обычно этого определения нет. Подразумевается. Ну и стандарты. А я именно так и определяю.
    Это как это не определяется?

    B>Опять согласен. Когда проблема известна осталось только ее решить. А решение одно. Убрать все лишнее и выделить минимум с помощью которого можно построить все остальное. У меня это и получилось. Ц меня всего 5 базовых понятий из которых строится вообще все.

    Много.
    http://en.wikipedia.org/wiki/Iota_and_Jot
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[52]: Не понял
    От: WolfHound  
    Дата: 19.05.12 20:34
    Оценка:
    Здравствуйте, Mamut, Вы писали:

    M>Мде. Из фразы «я не верю, что поддержка DSL намного легче, чем поддержка других решений» (а именно это я и сказал, а не то, что кажется твоему воспаленному воображению) никак не следует «я считаю, что для других решений поддержка не требуется вообще».

    Это то что ты процитировал.

    The disadvantages of the use of a DSL are:
    — The costs of designing, implementing and maintaining a DSL.


    M>Настоятельно советую тебе две вещи:

    M>- пройти курс логики
    M>- научиться понимать, что тебе пишут
    Так что это все к тебе.

    И еще нужно не забывать про то, что кроме поддержки ДСЛ есть еще код на этом ДСЛ.
    Так вот: поддержка ДСЛ и кода на ДСЛ всегда намного проще, чем поддержка фреймворка и кода на этом фреймворке.

    Просто по тому, что в результате прикладного кода получается намного меньше и при реалиации ДСЛ не нужно думать, как натянуть предметную область на целевой язык. Ибо это всегда можно изменить. С фреймворком такой фокус не пройдет.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[53]: Не понял
    От: Mamut Швеция http://dmitriid.com
    Дата: 19.05.12 20:45
    Оценка:
    M>>Мде. Из фразы «я не верю, что поддержка DSL намного легче, чем поддержка других решений» (а именно это я и сказал, а не то, что кажется твоему воспаленному воображению) никак не следует «я считаю, что для других решений поддержка не требуется вообще».
    WH>Это то что ты процитировал.
    WH>

    WH>The disadvantages of the use of a DSL are:
    WH>— The costs of designing, implementing and maintaining a DSL.


    Правильно. Почему я это процитировал? Потому что я не верю в то, что опыт одного человека является значимым и что я не верю в то, что поддержка DSL'ей намного легче, чем подержка других решений. В доказательство своей точки зрения я привел ссылку и цитату.

    Как из контекста разговора можно было сделать тот вывод, который сделал ты, известно только тебе, потому что никакому логическому объяснению это не поддается.

    WH>И еще нужно не забывать про то, что кроме поддержки ДСЛ есть еще код на этом ДСЛ.

    WH>Так вот: поддержка ДСЛ и кода на ДСЛ всегда намного проще, чем поддержка фреймворка и кода на этом фреймворке.

    WH>Просто по тому, что в результате прикладного кода получается намного меньше и при реалиации ДСЛ не нужно думать, как натянуть предметную область на целевой язык. Ибо это всегда можно изменить. С фреймворком такой фокус не пройдет.


    Вау. Ты заговорил человеческим языком. Понадобилось всего лишь четыре сообщения фантазий.

    По теме: проблема поддержки не заключается же только в поддержке кода, написанного на DSL. Это и развитие/расширение, это инструментирование, это документация, это интеграция с существующей системой. Даже если у нас внезапно нарисуется идеальный мир, где все создается DSL'ями, возникаеют вопросы их взаимодействия — API, форматы данных, изменения в этих API и форматах данных. В существующих ныне системах с DSL'ями тот же вопрос — взаимодействие с системой, форматы данных, API и т.п. Это ведь тоже надо поддерживать и это не достигается автоматически


    dmitriid.comGitHubLinkedIn
    Re[54]: Не понял
    От: WolfHound  
    Дата: 19.05.12 21:41
    Оценка:
    Здравствуйте, Mamut, Вы писали:

    M>Правильно. Почему я это процитировал? Потому что я не верю в то, что опыт одного человека является значимым

    Так тут много человек об этом говорит.
    Спорят только те кто ДСЛ не пробовал.

    M>и что я не верю в то, что поддержка DSL'ей намного легче, чем подержка других решений. В доказательство своей точки зрения я привел ссылку и цитату.

    Это цитата капитана очевидность вообще ничего не доказывает.
    Ибо ровно то же самое относится и к другим подходам.
    Они тоже требуют проектирования, реализации и поддержки.

    Причем из-за того что не нужно заниматься натягиванием предметной области на примитивы языка реализации это все сильно упрощается.

    M>Как из контекста разговора можно было сделать тот вывод, который сделал ты, известно только тебе, потому что никакому логическому объяснению это не поддается.

    Так ты эе тут пытаешься доказать ущербность ДСЛ.

    M>Вау. Ты заговорил человеческим языком. Понадобилось всего лишь четыре сообщения фантазий.

    А ты разве понимаешь по-человечески?
    Вот и сейчас вижу, что не понял.

    M>По теме: проблема поддержки не заключается же только в поддержке кода, написанного на DSL. Это и развитие/расширение, это инструментирование, это документация, это интеграция с существующей системой. Даже если у нас внезапно нарисуется идеальный мир, где все создается DSL'ями, возникаеют вопросы их взаимодействия — API, форматы данных, изменения в этих API и форматах данных. В существующих ныне системах с DSL'ями тот же вопрос — взаимодействие с системой, форматы данных, API и т.п. Это ведь тоже надо поддерживать и это не достигается автоматически

    Оно получается не автоматически, но намного проще.
    Просто по тому, что поменять генератор намного проще, чем переписать весь код.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[57]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 20.05.12 01:22
    Оценка:
    Здравствуйте, WolfHound, Вы писали:


    V>>Не смотрел, потому и не видел.

    WH>Смотрел. Все ужасны.

    Плохо смотрел, они точно так же иерархичны, как адекватное ПО.


    V>>А как же железки разрабатывают? Ты утонешь уже в сотнях элементов на одном уровне, а их сейчас на многие тысячи и даже миллионы в процах.

    WH>Verilog, VHDL,...

    Дудки, это только 30% работы или меньше, остальные все равно в графике. Текст хорош исключительно для copy&paste и прочего быстрого размножения похожих частей, или для глобального поиска/земены, собсно, для таких работ в него и переключаются. А так в нем работать невозможно, ты на экране максимум пару десятков строчек кода увидишь, а это катастрофически мало. Поэтому все эти редакторы Verilog на самом деле графические.
    Re[33]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 20.05.12 03:55
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    V>А ему и не надо. Нам были нужны произвольные внешние библиотеки, чтобы из безопасного DSL сделать опасный язык общего назначения. С++ — это как раз тот язык, на котором эти опасные DLL общего назначения можно писать, т.е. ему для этого не нужны дополнительные ср-ва.

    Непонятно, каким образом вы напишете эти опасные DLL, с учётом того, что в языке, на котором вы их пишете, нет никаких опасных возможностей (ну, кроме прямого обращения к произвольному адресу в памяти).
    Непонятно, каким образом вы их заимпортируете, с учётом отсутствия в языке встроенных средств для этого. На всякий случай напомню, что в самом языке С++ ничего про DLL нету. И он прекрасно работал задолго до того, как DLL вообще появились в природе.
    V>Могу 100-й раз напомнить про CRT. С этого CRT взлетает весь современный нейтив, большего и не надо.
    А я в ответ напомню, что CRT не написан на C++. Он написан на "чём-то ещё", что доступно в языке благодаря "магии компилятора".
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[55]: Не понял
    От: Mamut Швеция http://dmitriid.com
    Дата: 20.05.12 09:43
    Оценка:
    M>>Как из контекста разговора можно было сделать тот вывод, который сделал ты, известно только тебе, потому что никакому логическому объяснению это не поддается.
    WH>Так ты эе тут пытаешься доказать ущербность ДСЛ.

    Ты бы эта, проверился у специалистов, а то ты в каждом врагов видишь. Я всего лишь пытаюсь найти основание для твоих невероятно общих заявлений. Вместо того, чтобы это понять, ты начинаешь бурно фантазировать на какие-то темы, которые из моих слов не следуют вообще никак. Внезапно я уже ущербность DSL'ей пытаюсь доказать, о как

    M>>По теме: проблема поддержки не заключается же только в поддержке кода, написанного на DSL. Это и развитие/расширение, это инструментирование, это документация, это интеграция с существующей системой. Даже если у нас внезапно нарисуется идеальный мир, где все создается DSL'ями, возникаеют вопросы их взаимодействия — API, форматы данных, изменения в этих API и форматах данных. В существующих ныне системах с DSL'ями тот же вопрос — взаимодействие с системой, форматы данных, API и т.п. Это ведь тоже надо поддерживать и это не достигается автоматически

    WH>Оно получается не автоматически, но намного проще.
    WH>Просто по тому, что поменять генератор намного проще, чем переписать весь код.

    Ну да, ну да. Замена генератора — это не переписывание кода, ну вообще никак, ага (если ты только не используешь поменять в значении «изменить»).


    dmitriid.comGitHubLinkedIn
    Re[56]: Не понял
    От: WolfHound  
    Дата: 20.05.12 11:04
    Оценка:
    Здравствуйте, Mamut, Вы писали:

    M>Ну да, ну да. Замена генератора — это не переписывание кода, ну вообще никак, ага (если ты только не используешь поменять в значении «изменить»).

    Ну да. Всего пару порядков меньше работы. Фигня, а не преимущество.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[57]: Не понял
    От: Mamut Швеция http://dmitriid.com
    Дата: 20.05.12 11:27
    Оценка:
    M>>Ну да, ну да. Замена генератора — это не переписывание кода, ну вообще никак, ага (если ты только не используешь поменять в значении «изменить»).
    WH>Ну да. Всего пару порядков меньше работы. Фигня, а не преимущество.

    Откуда взялось это «пару порядков»? Ах, да. «Из опыта». Я так предполагаю, ты опять говоришь о сферовакуумных DSL'ях написанных на сферовакуумных инструментах.

    Я, заметь, не спорю, что изменить/расширить DSL вполне может быть легче, и намного, чем изменить/расширить существующую систему. Что, правда, подразумевает, что этот самый DSL грамотно спроектирован и вообще поддается этому самому расширению/изменению.

    Вопрос о дальнейшей поддержке самого DSL'я (а не только кода, на нем написанного) все еще остается открытым.


    dmitriid.comGitHubLinkedIn
    Re[58]: Не понял
    От: WolfHound  
    Дата: 20.05.12 12:21
    Оценка:
    Здравствуйте, Mamut, Вы писали:

    M>Откуда взялось это «пару порядков»? Ах, да. «Из опыта». Я так предполагаю, ты опять говоришь о сферовакуумных DSL'ях написанных на сферовакуумных инструментах.

    Из объема кода, который генерируется.
    И этого кода может быть в десятки и сотни, раз больше чем занимает ДСЛ + код на ДСЛ.

    M>Вопрос о дальнейшей поддержке самого DSL'я (а не только кода, на нем написанного) все еще остается открытым.

    Ты вообще читаешь, что тебе пишут?
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[59]: Какие порядки?!
    От: Wolverrum Ниоткуда  
    Дата: 20.05.12 13:27
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    M>>Ну да, ну да. Замена генератора — это не переписывание кода, ну вообще никак, ага (если ты только не используешь поменять в значении «изменить»).

    WH>Ну да. Всего пару порядков меньше работы. Фигня, а не преимущество.
    M>>Откуда взялось это «пару порядков»?
    WH>Из объема кода, который генерируется.
    WH>И этого кода может быть в десятки и сотни, раз больше чем занимает ДСЛ + код на ДСЛ.

    Имхо, что-то с методикой подсчета и сравнения не то. Я бы не додумался сравнивать объем C# кода, который генерит скрипт Ruby, с объемом кода этого скрипта, и уж тем более сравнивать стоимость внесения изменений в скрипт и в созданный скриптом код . Это ж вроде как две параллельные несравнимые сущности.

    Сравнивать надо сравнимое. По-моему, вполне уместно сравнивать ДСЛ с другим ДСЛ или, скажем, длины входа различных ДСЛ (например, ini-файлы с xml-файлами)
    Re[60]: Какие порядки?!
    От: WolfHound  
    Дата: 20.05.12 14:54
    Оценка:
    Здравствуйте, Wolverrum, Вы писали:

    W>Имхо, что-то с методикой подсчета и сравнения не то.

    С ней все нормально.

    W>Я бы не додумался сравнивать объем C# кода, который генерит скрипт Ruby, с объемом кода этого скрипта, и уж тем более сравнивать стоимость внесения изменений в скрипт и в созданный скриптом код . Это ж вроде как две параллельные несравнимые сущности.

    Именно что сравнимые.
    Ибо без генератора тот код, который генерируется, пришлось бы писать и поддерживать руками.
    А мы тут сравниваем рукопашный подход и ДСЛный.

    W>Сравнивать надо сравнимое. По-моему, вполне уместно сравнивать ДСЛ с другим ДСЛ или, скажем, длины входа различных ДСЛ (например, ini-файлы с xml-файлами)

    Вот я и сравниваю язык с языком.
    И на одном языке кода получается намного больше чем на другом.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[59]: Не понял
    От: Mamut Швеция http://dmitriid.com
    Дата: 21.05.12 07:34
    Оценка:
    M>>Откуда взялось это «пару порядков»? Ах, да. «Из опыта». Я так предполагаю, ты опять говоришь о сферовакуумных DSL'ях написанных на сферовакуумных инструментах.
    WH>Из объема кода, который генерируется.
    WH>И этого кода может быть в десятки и сотни, раз больше чем занимает ДСЛ + код на ДСЛ.

    Ты опять говоришь только про код.

    M>>Вопрос о дальнейшей поддержке самого DSL'я (а не только кода, на нем написанного) все еще остается открытым.

    WH>Ты вообще читаешь, что тебе пишут?

    В отличие от тебя, читаю. Ты упорно гнешь только линию про код,и только про код.

    Ладно. Замнем. Разговор с тобой — пустая трата времени. Ты слушаешь только звук собственного голоса и отвечаешь только на то, что ты предпочитаешь видеть.


    dmitriid.comGitHubLinkedIn
    Re[60]: Не понял
    От: WolfHound  
    Дата: 21.05.12 08:07
    Оценка:
    Здравствуйте, Mamut, Вы писали:

    M>Ты опять говоришь только про код.

    А про что еще можно говорить?

    M>В отличие от тебя, читаю. Ты упорно гнешь только линию про код,и только про код.

    Ну что поделать, если программы состоят из кода чуть менее чем полностью?

    M>Ладно. Замнем. Разговор с тобой — пустая трата времени. Ты слушаешь только звук собственного голоса и отвечаешь только на то, что ты предпочитаешь видеть.

    Очередной слив засчитан.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[61]: Не понял
    От: Mamut Швеция http://dmitriid.com
    Дата: 21.05.12 08:10
    Оценка:
    M>>Ты опять говоришь только про код.
    WH>А про что еще можно говорить?

    По теме: проблема поддержки не заключается же только в поддержке кода, написанного на DSL. Это и развитие/расширение, это инструментирование, это документация, это интеграция с существующей системой. Даже если у нас внезапно нарисуется идеальный мир, где все создается DSL'ями, возникаеют вопросы их взаимодействия — API, форматы данных, изменения в этих API и форматах данных. В существующих ныне системах с DSL'ями тот же вопрос — взаимодействие с системой, форматы данных, API и т.п. Это ведь тоже надо поддерживать и это не достигается автоматически


    Но да, но да. Говорить надо только и исключительно про код, а как же еще. Ведь все остальное за нас сделают феи и гномы.

    И этот человек еще мне засчитывает какие-то сливы


    dmitriid.comGitHubLinkedIn
    Re[58]: Языки общего назначения не имеют смысла!
    От: SleepyDrago Украина  
    Дата: 21.05.12 08:59
    Оценка: 5 (1)
    Здравствуйте, vdimas, Вы писали:

    ...
    V>Дудки, это только 30% работы или меньше, остальные все равно в графике. Текст хорош исключительно для copy&paste и прочего быстрого размножения похожих частей, или для глобального поиска/земены, собсно, для таких работ в него и переключаются. А так в нем работать невозможно, ты на экране максимум пару десятков строчек кода увидишь, а это катастрофически мало. Поэтому все эти редакторы Verilog на самом деле графические.

    могу констатировать полную победу текста на цифровых схемах. Аналоговые блоки описываются в текст и вставляются как черные ящики. за счет этого геометрии и шины и тп все генерируется исходя из текстовых моделей. В графику переключаются считанные люди которым надо править нетривиальную аналоговую часть.
    Re[62]: Не понял
    От: WolfHound  
    Дата: 21.05.12 10:33
    Оценка:
    Здравствуйте, Mamut, Вы писали:

    M>

    M>По теме: проблема поддержки не заключается же только в поддержке кода, написанного на DSL. Это и развитие/расширение, это инструментирование, это документация, это интеграция с существующей системой. Даже если у нас внезапно нарисуется идеальный мир, где все создается DSL'ями, возникаеют вопросы их взаимодействия — API, форматы данных, изменения в этих API и форматах данных. В существующих ныне системах с DSL'ями тот же вопрос — взаимодействие с системой, форматы данных, API и т.п. Это ведь тоже надо поддерживать и это не достигается автоматически


    M>Но да, но да. Говорить надо только и исключительно про код, а как же еще. Ведь все остальное за нас сделают феи и гномы.

    Все это относится и к работе с обычными языками.
    Но работы будет в 10-100 раз больше.

    При этом если понадобится портировать на другую платформу. Например с жабы на С++ тебе придется переписать все.
    Мне только бекенд. А это небольшая часть кода.

    M>И этот человек еще мне засчитывает какие-то сливы

    Конечно. Сказать то тебе нечего.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[63]: Не понял
    От: Mamut Швеция http://dmitriid.com
    Дата: 21.05.12 10:42
    Оценка:
    M>>

    M>>По теме: проблема поддержки не заключается же только в поддержке кода, написанного на DSL. Это и развитие/расширение, это инструментирование, это документация, это интеграция с существующей системой. Даже если у нас внезапно нарисуется идеальный мир, где все создается DSL'ями, возникаеют вопросы их взаимодействия — API, форматы данных, изменения в этих API и форматах данных. В существующих ныне системах с DSL'ями тот же вопрос — взаимодействие с системой, форматы данных, API и т.п. Это ведь тоже надо поддерживать и это не достигается автоматически


    M>>Но да, но да. Говорить надо только и исключительно про код, а как же еще. Ведь все остальное за нас сделают феи и гномы.

    WH>Все это относится и к работе с обычными языками.
    WH>Но работы будет в 10-100 раз больше.

    Откда ты берешь эту цифру? [1]

    И, учитывая, что, например, инструментарий для DSL'ей отсутсвует, как класс, то работы будет совсем-совсем мало, ага ага. Нет, можно обойтись без инструментария, но тогда возникнет вопрос с покрытием всего нагенеренного кода тестами. Любое изменение/расширение DSL'я невозможно будет отловить кроме как полным тестированием всего и вся. И этих усилий явно не будет не в 10-100 раз меньше.

    WH>При этом если понадобится портировать на другую платформу. Например с жабы на С++ тебе придется переписать все.

    WH>Мне только бекенд. А это небольшая часть кода.

    Кто будет гарантировать правильность генерируемого кода? Пушкин?


    [1] У меня перед глазами два DSL'я. Один соответсвует твоим критериям, один — нет. В частности, поэтому твои пафосные и ничем не подтверждаемые высказывания оставь неофитам. Казалось бы, «Философия» не «(К)СВ» и тут принято приводить больше доводов, чем «я так сказал, падите ниц».


    dmitriid.comGitHubLinkedIn
    Re[64]: Не понял
    От: WolfHound  
    Дата: 21.05.12 11:11
    Оценка: :)
    Здравствуйте, Mamut, Вы писали:

    WH>>Все это относится и к работе с обычными языками.

    WH>>Но работы будет в 10-100 раз больше.
    M>Откда ты берешь эту цифру? [1]
    Из того во что разворачиваются мои ДСЛ.

    M>И, учитывая, что, например, инструментарий для DSL'ей отсутсвует, как класс, то работы будет совсем-совсем мало, ага ага.

    Какой инструментарий тебе нужен?

    M>Нет, можно обойтись без инструментария, но тогда возникнет вопрос с покрытием всего нагенеренного кода тестами.

    Ты так говоришь, как будто написанный руками код покрывать тестами не нужно.
    Я тебе больше скажу весь генерируемый код тестами покрывать и не надо.
    Ошибки в генераторе кода ловятся на раз-два. После чего весь генерируемый код будет всегда правильный.
    Чего не скажешь про рукописный. Ибо человек может в любой момент ошибиться, а компилятор железный.

    M>Любое изменение/расширение DSL'я невозможно будет отловить кроме как полным тестированием всего и вся. И этих усилий явно не будет не в 10-100 раз меньше.

    Глупости.

    M>Кто будет гарантировать правильность генерируемого кода? Пушкин?

    Кто будет гарантировать правильность написанного руками кода? Пушкин?

    M>[1] У меня перед глазами два DSL'я. Один соответсвует твоим критериям, один — нет.

    И что это за ДСЛи такие?

    M>В частности, поэтому твои пафосные и ничем не подтверждаемые высказывания оставь неофитам. Казалось бы, «Философия» не «(К)СВ» и тут принято приводить больше доводов, чем «я так сказал, падите ниц».

    Этим ты у нас занимаешься.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[65]: Не понял
    От: Mamut Швеция http://dmitriid.com
    Дата: 21.05.12 12:15
    Оценка:
    WH>>>Все это относится и к работе с обычными языками.
    WH>>>Но работы будет в 10-100 раз больше.
    M>>Откда ты берешь эту цифру? [1]
    WH>Из того во что разворачиваются мои ДСЛ.

    В случае, если разница в 10 раз, нас мало интересует, во что он там разворачивается. Boilerplate-код можно выносить в библиотеки и т.п. В случае, если разница — в 100 раз, уже можно думать, что да, это было бы сложнее писать/поддерживать. Что опять же выливается в дикое количество параметров — от архитектуры системы до архитектуры DSL'я и т.п. Но да, но да, надо обязательно побить себя пяткой в грудь с максимально громкими, ничем не подтвержденными заявлениями.

    M>>И, учитывая, что, например, инструментарий для DSL'ей отсутсвует, как класс, то работы будет совсем-совсем мало, ага ага.

    WH>Какой инструментарий тебе нужен?

    От дебаггеров и подсветки синтаксиса до отладочной печати и логгирования.

    M>>Нет, можно обойтись без инструментария, но тогда возникнет вопрос с покрытием всего нагенеренного кода тестами.

    WH>Ты так говоришь, как будто написанный руками код покрывать тестами не нужно.

    Нужно, а DSL'ный не нужно?

    WH>Я тебе больше скажу весь генерируемый код тестами покрывать и не надо.

    WH>Ошибки в генераторе кода ловятся на раз-два. После чего весь генерируемый код будет всегда правильный.
    WH>Чего не скажешь про рукописный. Ибо человек может в любой момент ошибиться, а компилятор железный.

    Ну да, люди никогда не смогут ошибиться в написании компилятора, ты что.

    M>>Любое изменение/расширение DSL'я невозможно будет отловить кроме как полным тестированием всего и вся. И этих усилий явно не будет не в 10-100 раз меньше.

    WH>Глупости.

    О да. Безусловно. Дай ка я воспользуюсь твоим приемом: ты заявляешь, что DSL тестировать не надо. Что за бред?

    M>>Кто будет гарантировать правильность генерируемого кода? Пушкин?

    WH>Кто будет гарантировать правильность написанного руками кода? Пушкин?

    Угу. емнип, не в первый раз я задаю тебе этот вопрос, и все так же ты уходишь от ответа.


    M>>[1] У меня перед глазами два DSL'я. Один соответсвует твоим критериям, один — нет.

    WH>И что это за ДСЛи такие?

    Один — декларативное описание правил оценки рисков, второй — описание контрактов между службами (какие данные входят, какие выходят, и откуда эти данные берутся).

    Первый — «железный компилятор», который легко поддерживать только потому, что есть люди, которые знают, как он работает, и результирующий код полностью покрыт тестами.
    Второй — трэш угар и содомия, который пытаются поменять уже вторую неделю.

    Дададада. В этом месте ты начинаешь вещать про криворуких уродов, которые пользуются не теми инструментами. Предсказуемо и неинтересно. Я не живу в сферовакуумном мире.


    M>>В частности, поэтому твои пафосные и ничем не подтверждаемые высказывания оставь неофитам. Казалось бы, «Философия» не «(К)СВ» и тут принято приводить больше доводов, чем «я так сказал, падите ниц».

    WH>Этим ты у нас занимаешься.

    Я, как минмиум, ищу подтверждения своим словам и заявлениям. Можешь перечитать эту подветку. На любой мой вопрос у тебя ровно три варианта ответа:
    — я так сказал
    — а в другом случае не так?
    — борьба с какими-то идеями, которые я никогда не высказывал

    Ни на один прямо поставленный вопросы ты ни разу не ответил хотя бы с минимальным подтверждением своих слов.


    dmitriid.comGitHubLinkedIn
    Re[66]: Не понял
    От: WolfHound  
    Дата: 21.05.12 13:22
    Оценка:
    Здравствуйте, Mamut, Вы писали:

    M>В случае, если разница в 10 раз, нас мало интересует, во что он там разворачивается.

    Разница на порядок ерунда.
    Подумаешь, проект будут делать 10-100 человеколет, а не один.
    Фигня какая.

    M> Boilerplate-код можно выносить в библиотеки и т.п.

    В 10-100 раз с учетом вынесения в библиотеки.
    И это факт.

    M>В случае, если разница — в 100 раз, уже можно думать, что да, это было бы сложнее писать/поддерживать. Что опять же выливается в дикое количество параметров — от архитектуры системы до архитектуры DSL'я и т.п. Но да, но да, надо обязательно побить себя пяткой в грудь с максимально громкими, ничем не подтвержденными заявлениями.

    Подтверждений полно.
    Только ты их игнорируешь.

    M>От дебаггеров и подсветки синтаксиса

    Генерируется автоматически.

    M>до отладочной печати и логгирования.

    Это делается в несколько строк кода.
    И после таких заявлений ты хочешь, чтобы я тебя воспринимал в серьез?

    WH>>Ты так говоришь, как будто написанный руками код покрывать тестами не нужно.

    M>Нужно, а DSL'ный не нужно?
    Нужно. Но так как его в 10-100 раз меньше то и тестировать его нужно в 10-100 раз меньше.
    А если учесть то что нормальные люди делают кучу проверок при компиляции ДСЛ то и того меньше.
    Хотя фанат динамической типизации это всё равно не поймет.

    M>Ну да, люди никогда не смогут ошибиться в написании компилятора, ты что.

    Мест для ошибок в 10-100 раз меньше.
    И каждая ошибка проявляется сразу по всему коду, а не в одном месте которое вызывается раз в год.
    Так что мало того что ошибок будет в 10-100 раз меньше. Но их еще и поймать проще.

    M>Угу. емнип, не в первый раз я задаю тебе этот вопрос, и все так же ты уходишь от ответа.

    Я на него уже отвечал. И в этом сообщении еще раз ответил. Смотри выше.

    M>Дададада. В этом месте ты начинаешь вещать про криворуких уродов, которые пользуются не теми инструментами. Предсказуемо и неинтересно. Я не живу в сферовакуумном мире.

    И ты мне тут на полном серьезе хочешь заявить что авторы второго ДСЛ без ДСЛ сделали бы конфетку?
    Я тебя правильно понял?

    M>Я, как минмиум, ищу подтверждения своим словам и заявлениям.

    Ни разу.

    M>Ни на один прямо поставленный вопросы ты ни разу не ответил хотя бы с минимальным подтверждением своих слов.

    Какие тебе нужны подтверждения?
    Показать тебе сколько кода генерируется из нескольких строк ДСЛ?
    Или что?
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[67]: Не понял
    От: Mamut Швеция http://dmitriid.com
    Дата: 21.05.12 13:51
    Оценка:
    M>>В случае, если разница в 10 раз, нас мало интересует, во что он там разворачивается.
    WH>Разница на порядок ерунда.
    WH>Подумаешь, проект будут делать 10-100 человеколет, а не один.
    WH>Фигня какая.

    А, ну да. Мы уже ВНЕЗАПНО весь проект DSL'ями заменили, ага-ага.

    M>> Boilerplate-код можно выносить в библиотеки и т.п.

    WH>В 10-100 раз с учетом вынесения в библиотеки.
    WH>И это факт.

    Ога. Может, ты дашь хоть одну ссылку на подтверждение этого «факта»?


    M>>В случае, если разница — в 100 раз, уже можно думать, что да, это было бы сложнее писать/поддерживать. Что опять же выливается в дикое количество параметров — от архитектуры системы до архитектуры DSL'я и т.п. Но да, но да, надо обязательно побить себя пяткой в грудь с максимально громкими, ничем не подтвержденными заявлениями.

    WH>Подтверждений полно.
    WH>Только ты их игнорируешь.

    Ссылку или цитату хоть на одно. Напомню, что 8 сообщений тому назад
    Автор: Mamut
    Дата: 19.05.12
    я просил ссылки. Как не было, так и нет. И не предвидится.

    M>>От дебаггеров и подсветки синтаксиса

    WH>Генерируется автоматически.

    Что генерируется автоматически? Подсветка синтаксиса и дебаггинг для DSL'я? Ну ну. Это в какой такой сферовакуумной вселенной так происходит?

    M>>до отладочной печати и логгирования.

    WH>Это делается в несколько строк кода.

    ВОт из такиз мелочей и складывается дальнейшая поддержка, развитие и т.п. А то тут что-то забыли, там что-то забыли, тут пришлось дописать, там пришлось дописать. Но у нас же DSL!!!одинодин.


    WH>>>Ты так говоришь, как будто написанный руками код покрывать тестами не нужно.

    M>>Нужно, а DSL'ный не нужно?
    WH>Нужно. Но так как его в 10-100 раз меньше то и тестировать его нужно в 10-100 раз меньше.

    Да ты что? То, что он разворачивается — как ты там говоришь? — в 10-100 раз больше кода, то ни строчки этого кода тестировать не надо?

    WH>А если учесть то что нормальные люди делают кучу проверок при компиляции ДСЛ то и того меньше.


    А, ну что я говорил. «Нормальные люди» и т.п.

    WH>Хотя фанат динамической типизации это всё равно не поймет.


    Ну да, главное — попытаться оскорбить оппонента в отсутсвие аргументов.

    M>>Ну да, люди никогда не смогут ошибиться в написании компилятора, ты что.

    WH>Мест для ошибок в 10-100 раз меньше.
    WH>И каждая ошибка проявляется сразу по всему коду, а не в одном месте которое вызывается раз в год.
    WH>Так что мало того что ошибок будет в 10-100 раз меньше. Но их еще и поймать проще.

    Ты так и не ответил про то, кто и как гарантирует правильность сгенерированного кода. Что в итоге «непонятных адепту динамической типизации» проверок и оптимизаций не сгенерируется код, который логически неверен? Что в итоге расширения/изменения существующего DSL'я не навернется — именно логически — сгенерированный код.

    Ах, ну да. Ответ патамушта!, как я мог забыть.


    M>>Угу. емнип, не в первый раз я задаю тебе этот вопрос, и все так же ты уходишь от ответа.

    WH>Я на него уже отвечал. И в этом сообщении еще раз ответил. Смотри выше.

    Нет, ты ничего не ответил. Ты говорил про количество ошибок. Ты ничего не говорил про доказательство верности генерируемого кода.


    M>>Дададада. В этом месте ты начинаешь вещать про криворуких уродов, которые пользуются не теми инструментами. Предсказуемо и неинтересно. Я не живу в сферовакуумном мире.

    WH>И ты мне тут на полном серьезе хочешь заявить что авторы второго ДСЛ без ДСЛ сделали бы конфетку?
    WH>Я тебя правильно понял?

    Я не понял твоего вопроса.

    M>>Я, как минмиум, ищу подтверждения своим словам и заявлениям.

    WH>Ни разу.

    Ну да ну да. Это ты у нас постоянно фонтанируешь ссылками и примерами.

    M>>Ни на один прямо поставленный вопросы ты ни разу не ответил хотя бы с минимальным подтверждением своих слов.

    WH>Какие тебе нужны подтверждения?
    WH>Показать тебе сколько кода генерируется из нескольких строк ДСЛ?
    WH>Или что?

    Подтверждения всем твоим голословным заявлениям, которых, якобы, было уже много.
    — что поддержка DSL обязательно намного/на порядки/в 10-100 раз легче, чем других решений[1]
    — что для DSL'я все подряд генерируется автоматически
    — что DSL надо покрывать меньшим количеством тестов [2]

    [1] Это верно только если речь идет о коде, написанном на этом DSL'е, потому что вся инфраструктура для поддержки работы этого DSL'я — это такая же система, кем-то написанная, которую надо исправлять, поддерживать, изменять, интегрировать и т.п.
    [2] Опять же — верно только при условии, что мы говорим только о коде. Только вот кто доказывает корректность сгенерированного кода?


    dmitriid.comGitHubLinkedIn
    Re[68]: Не понял
    От: WolfHound  
    Дата: 21.05.12 14:33
    Оценка:
    Здравствуйте, Mamut, Вы писали:

    M>А, ну да. Мы уже ВНЕЗАПНО весь проект DSL'ями заменили, ага-ага.

    А почему нет?

    M>Ога. Может, ты дашь хоть одну ссылку на подтверждение этого «факта»?

    Я тут уже не один раз код показывал.
    Re[12]: Языки общего назначения не имеют смысла!
    Автор: WolfHound
    Дата: 09.04.12


    M>Ссылку или цитату хоть на одно. Напомню, что 8 сообщений тому назад
    Автор: Mamut
    Дата: 19.05.12
    я просил ссылки. Как не было, так и нет. И не предвидится.

    http://lurkmore.to/%D0%9F%D1%80%D1%83%D1%84%D0%BF%D0%B8%D0%BA

    M>Что генерируется автоматически? Подсветка синтаксиса и дебаггинг для DSL'я? Ну ну. Это в какой такой сферовакуумной вселенной так происходит?

    Это в реальности происходит.

    M>ВОт из такиз мелочей и складывается дальнейшая поддержка, развитие и т.п. А то тут что-то забыли, там что-то забыли, тут пришлось дописать, там пришлось дописать.

    Дописать в кодогенератор.

    M>Но у нас же DSL!!!одинодин.

    Именно для этого ДСЛ и нужен.
    Ибо написали несколько строк в генераторе и получили тыщи размазанные ровным слоем по всему коду.

    M>Да ты что? То, что он разворачивается — как ты там говоришь? — в 10-100 раз больше кода, то ни строчки этого кода тестировать не надо?

    Тестировать надо только прикладную логику.

    WH>>А если учесть то что нормальные люди делают кучу проверок при компиляции ДСЛ то и того меньше.

    M>А, ну что я говорил. «Нормальные люди» и т.п.
    Ты что тоже как Ikemefula хочешь не нормальных для разработки софта использовать?
    Так они и на жабке дров наломают.

    WH>>Хотя фанат динамической типизации это всё равно не поймет.

    M>Ну да, главное — попытаться оскорбить оппонента в отсутсвие аргументов.
    Этим тут ты занимаешься.

    M>Ты так и не ответил про то, кто и как гарантирует правильность сгенерированного кода. Что в итоге «непонятных адепту динамической типизации» проверок и оптимизаций не сгенерируется код, который логически неверен? Что в итоге расширения/изменения существующего DSL'я не навернется — именно логически — сгенерированный код.

    Еще раз. Если ошибка будет в генераторе кода, эта ошибка будет везде.
    И ее сразу обнаружат и исправят.

    M>Нет, ты ничего не ответил. Ты говорил про количество ошибок. Ты ничего не говорил про доказательство верности генерируемого кода.

    Я говорил и говорю, что в подходе с ДСЛ ошибки искать и править значительно проще, чем, если писать все руками.

    M>>>Дададада. В этом месте ты начинаешь вещать про криворуких уродов, которые пользуются не теми инструментами. Предсказуемо и неинтересно. Я не живу в сферовакуумном мире.

    WH>>И ты мне тут на полном серьезе хочешь заявить что авторы второго ДСЛ без ДСЛ сделали бы конфетку?
    WH>>Я тебя правильно понял?
    M>Я не понял твоего вопроса.
    А что тут не понятного?
    Ты занимаешься противопоставлением ДСЛ и рукопашного кода.
    В данном случае ты размахиваешь тем, что что-то не осилил ДСЛ.
    Значит, ты намекаешь на то, что они осилят решение на обычном языке.

    M>Подтверждения всем твоим голословным заявлениям, которых, якобы, было уже много.

    M>- что поддержка DSL обязательно намного/на порядки/в 10-100 раз легче, чем других решений[1]
    Следует из того что кода будет в 10-100 раз меньше.

    M>- что для DSL'я все подряд генерируется автоматически

    Возьми да посмотри современные инструменты.

    M>- что DSL надо покрывать меньшим количеством тестов [2]

    Кода меньше.
    Тестов тоже.

    M>[1] Это верно только если речь идет о коде, написанном на этом DSL'е, потому что вся инфраструктура для поддержки работы этого DSL'я — это такая же система, кем-то написанная, которую надо исправлять, поддерживать, изменять, интегрировать и т.п.

    Только в ней кода кот наплакал.

    M>[2] Опять же — верно только при условии, что мы говорим только о коде. Только вот кто доказывает корректность сгенерированного кода?

    Довести генерированный код до рабочего состояния гораздо проще, чем рукопашный.
    Я готов спорить что ты при написании руками того кода который я генерирую и за год из него всех тараканов не выловишь.
    Re[12]: Языки общего назначения не имеют смысла!
    Автор: WolfHound
    Дата: 09.04.12


    А если в исходник на ДСЛ добавить что типа такого LetterCharacter = [Lu, Ll, Lt, Lm, Lo, Nl] то там такое начнется
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[69]: Не понял
    От: Mamut Швеция http://dmitriid.com
    Дата: 21.05.12 15:46
    Оценка:
    M>>А, ну да. Мы уже ВНЕЗАПНО весь проект DSL'ями заменили, ага-ага.
    WH>А почему нет?

    Потому что вокруг нас реальный мир, а не сферовакуумный.

    M>>Ога. Может, ты дашь хоть одну ссылку на подтверждение этого «факта»?

    WH>Я тут уже не один раз код показывал.
    WH>Re[12]: Языки общего назначения не имеют смысла!
    Автор: WolfHound
    Дата: 09.04.12


    В случае, если разница — в 100 раз, уже можно думать, что да, это было бы сложнее писать/поддерживать.


    Я же говорю, ты изначально видишь во всех врагов и не способен понять, что тебе пишут.

    M>>Что генерируется автоматически? Подсветка синтаксиса и дебаггинг для DSL'я? Ну ну. Это в какой такой сферовакуумной вселенной так происходит?

    WH>Это в реальности происходит.

    Где?

    M>>Да ты что? То, что он разворачивается — как ты там говоришь? — в 10-100 раз больше кода, то ни строчки этого кода тестировать не надо?

    WH>Тестировать надо только прикладную логику.

    Тестируем. Кто доказывает корректность генерируемого кода?

    M>>Ты так и не ответил про то, кто и как гарантирует правильность сгенерированного кода. Что в итоге «непонятных адепту динамической типизации» проверок и оптимизаций не сгенерируется код, который логически неверен? Что в итоге расширения/изменения существующего DSL'я не навернется — именно логически — сгенерированный код.

    WH>Еще раз. Если ошибка будет в генераторе кода, эта ошибка будет везде.
    WH>И ее сразу обнаружат и исправят.

    Нет, она необязательно будет везде.

    M>>>>Дададада. В этом месте ты начинаешь вещать про криворуких уродов, которые пользуются не теми инструментами. Предсказуемо и неинтересно. Я не живу в сферовакуумном мире.

    WH>>>И ты мне тут на полном серьезе хочешь заявить что авторы второго ДСЛ без ДСЛ сделали бы конфетку?
    WH>>>Я тебя правильно понял?
    M>>Я не понял твоего вопроса.
    WH>А что тут не понятного?
    WH>Ты занимаешься противопоставлением ДСЛ и рукопашного кода.
    WH>В данном случае ты размахиваешь тем, что что-то не осилил ДСЛ.
    WH>Значит, ты намекаешь на то, что они осилят решение на обычном языке.

    Теперь понятно. Нет, я ни на что не намекаю. Я говорю то, что говорю: у меня перед глазами два DSL с разными по сложности затратами. Возможно, второй вполне можно было решить соглашениями об API на уровне документации.

    M>>- что для DSL'я все подряд генерируется автоматически

    WH>Возьми да посмотри современные инструменты.

    Покажи мне эти современные инструменты.

    M>>[1] Это верно только если речь идет о коде, написанном на этом DSL'е, потому что вся инфраструктура для поддержки работы этого DSL'я — это такая же система, кем-то написанная, которую надо исправлять, поддерживать, изменять, интегрировать и т.п.

    WH>Только в ней кода кот наплакал.

    Зависит от DSL, зависит от уровня инструментации, зависит от системы/систем, в которые он интегрируется.

    M>>[2] Опять же — верно только при условии, что мы говорим только о коде. Только вот кто доказывает корректность сгенерированного кода?

    WH>Довести генерированный код до рабочего состояния гораздо проще, чем рукопашный.

    Ты опять не отвечаешь на заданный вопрос.

    WH>А если в исходник на ДСЛ добавить что типа такого LetterCharacter = [Lu, Ll, Lt, Lm, Lo, Nl] то там такое начнется


    Юоавили. Двльше что. Кто гарантирует корректность сгенерированного кода?


    dmitriid.comGitHubLinkedIn
    Re[70]: Не понял
    От: WolfHound  
    Дата: 21.05.12 17:23
    Оценка:
    Здравствуйте, Mamut, Вы писали:

    M>Потому что вокруг нас реальный мир, а не сферовакуумный.

    Понятно. Сказать нечего.

    M>

    M>В случае, если разница — в 100 раз, уже можно думать, что да, это было бы сложнее писать/поддерживать.

    M>Я же говорю, ты изначально видишь во всех врагов и не способен понять, что тебе пишут.
    Способен. Мне пытаются втереть, что ДСЛ имеют смысл только если кода в 100 раз меньше.
    Но он имеет смысл даже когда кода всего в два раза меньше.
    А иногда ДСЛ имеет смысл даже тогда когда генератор занимает столько же, сколько генерируемый код. Ибо занимается такими оптимизациями, что реками их не сделать. Особенно учитывая, что малейшие изменения модели могут изменить весь генерируемый код.

    M>Тестируем. Кто доказывает корректность генерируемого кода?

    Так если генерируемый код не правильный то ты никогда не добьёшься чтобы прикладная логика работала правильно.

    WH>>Еще раз. Если ошибка будет в генераторе кода, эта ошибка будет везде.

    WH>>И ее сразу обнаружат и исправят.
    M>Нет, она необязательно будет везде.
    Еще ни разу не видел ошибку в кодогенераторе которая не отсвечивала бы по всему генерируемому коду.
    А даже если такие иногда и встречаются, то в рукописном коде все ошибки такие.

    M>Теперь понятно. Нет, я ни на что не намекаю. Я говорю то, что говорю: у меня перед глазами два DSL с разными по сложности затратами. Возможно, второй вполне можно было решить соглашениями об API на уровне документации.

    Та говоришь что люди не осилили сделать ДСЛ.
    И к чему ту это вообще говоришь?

    M>Юоавили. Двльше что.

    Спокойней.

    M>Кто гарантирует корректность сгенерированного кода?

    Сначала ответь, кто гарантирует корректность написанного руками кода?
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[22]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 21.05.12 17:27
    Оценка: -2 :)
    Здравствуйте, Mamut, Вы писали:

    M>Поблема такая же, как и с Н1:

    M>- сделать хоть один killer-проект на этом

    А неверующий Фома банально не посмотрит на него.

    M>- сделать один killer-туториал по этому


    А он не прочтет его.

    M>- документация


    А он скажет, что она плохая и вообще не так выглядит.

    M>- популяризация


    Вот только и остается. И то периодически появится идиот с лозунгом "не нужно" и воплями "достали своей рекламой".

    Потом без бабла и мощного ПиАр-отдела — это не простая задача.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[71]: Не понял
    От: Mamut Швеция http://dmitriid.com
    Дата: 21.05.12 17:46
    Оценка:
    M>>Потому что вокруг нас реальный мир, а не сферовакуумный.
    WH>Понятно. Сказать нечего.

    Ну, сказать нечего тебе. Ты рассказываешь небылицы про то все радужно, как все автоматически генерируется, как все абсолютно инструменты заменены ДСЛями и т.п. Только все это сказки, потому что в реально мире такого нет, или такого исчезающе мало. Вот, ты даже мой вопрос про инструменты решил полностью поскипать.

    M>>Тестируем. Кто доказывает корректность генерируемого кода?

    WH>Так если генерируемый код не правильный то ты никогда не добьёшься чтобы прикладная логика работала правильно.


    WH>>>Еще раз. Если ошибка будет в генераторе кода, эта ошибка будет везде.

    WH>>>И ее сразу обнаружат и исправят.
    M>>Нет, она необязательно будет везде.
    WH>Еще ни разу не видел ошибку в кодогенераторе которая не отсвечивала бы по всему генерируемому коду.
    WH>А даже если такие иногда и встречаются, то в рукописном коде все ошибки такие.

    M>>Теперь понятно. Нет, я ни на что не намекаю. Я говорю то, что говорю: у меня перед глазами два DSL с разными по сложности затратами. Возможно, второй вполне можно было решить соглашениями об API на уровне документации.

    WH>Та говоришь что люди не осилили сделать ДСЛ.

    В этом месте ты начинаешь вещать про криворуких уродов, которые пользуются не теми инструментами.


    Сказал ты не так грубо, но реакция предсказана еще пару сообщений тому назад.

    WH>И к чему ту это вообще говоришь?


    К тому, что ты сказочник, живущий в сферовакуумном мире, где все прекрасно и замечательно.

    M>>Юоавили. Двльше что.

    WH>Спокойней.

    Это было слово «добавили». У меня сегодня проблема с попаданием по нужным клавишам.

    M>>Кто гарантирует корректность сгенерированного кода?

    WH>Сначала ответь, кто гарантирует корректность написанного руками кода?

    Тесты и еще раз тесты.


    З.Ы.

    Проигнорировано тобой:

    M>>Что генерируется автоматически? Подсветка синтаксиса и дебаггинг для DSL'я? Ну ну. Это в какой такой сферовакуумной вселенной так происходит?
    WH>Это в реальности происходит.

    Где?

    M>>- что для DSL'я все подряд генерируется автоматически
    WH>Возьми да посмотри современные инструменты.

    Покажи мне эти современные инструменты.



    dmitriid.comGitHubLinkedIn
    Re[23]: Языки общего назначения не имеют смысла!
    От: Mamut Швеция http://dmitriid.com
    Дата: 21.05.12 17:58
    Оценка: +1
    Специально оставляю все цитаты, это не оверквотинг

    M>>Поблема такая же, как и с Н1:

    M>>- сделать хоть один killer-проект на этом
    VD>А неверующий Фома банально не посмотрит на него.

    M>>- сделать один killer-туториал по этому

    VD>А он не прочтет его.

    M>>- документация

    VD>А он скажет, что она плохая и вообще не так выглядит.

    M>>- популяризация

    VD>Вот только и остается. И то периодически появится идиот с лозунгом "не нужно" и воплями "достали своей рекламой".

    С таким подходом ваш продукт никогда даром не нужен будет. Более того, твоя позиция по killer-проекту давно известна:

    http://rsdn.ru/forum/philosophy/1690584.aspx



    Надеюсь на Nemerle никогда не будет создано killer app-ов, так как надесю, что Nemerle не станет очередным экзотическим извращением.


    И т.п.

    Аналогично про документацию. Если ее не будут читать, значит, ее не надо писать? Если кто-то не прочтет туториала по языку, эти туториалы не надо писать?

    Я к Немерле подхожу с периодичностью раз в год-полтора. Я до сих пор не знаю, зачем он нужен. Сейчас хоть вменяемые вводные статьи появились ().


    VD>Потом без бабла и мощного ПиАр-отдела — это не простая задача.


    Естественно. Но это значит, что надо сидеть, сложа руки, и ничего не делать? Ну или можно дождаться, как Ruby, пока что-то не напишет какой-нибудь RoR, который введет язык в мейнстрим.


    dmitriid.comGitHubLinkedIn
    Re[72]: Не понял
    От: WolfHound  
    Дата: 21.05.12 18:28
    Оценка:
    Здравствуйте, Mamut, Вы писали:

    M>Ну, сказать нечего тебе. Ты рассказываешь небылицы про то все радужно, как все автоматически генерируется, как все абсолютно инструменты заменены ДСЛями и т.п. Только все это сказки, потому что в реально мире такого нет, или такого исчезающе мало. Вот, ты даже мой вопрос про инструменты решил полностью поскипать.

    Так ты даже на немерле не посмотрел.
    В нем это в большинстве случаев само происходит.

    M>

    M>В этом месте ты начинаешь вещать про криворуких уродов, которые пользуются не теми инструментами.


    M>Сказал ты не так грубо, но реакция предсказана еще пару сообщений тому назад.
    А что еще можно ожидать, если ты сам говоришь, что они не осилили задачу?
    И причем тут ДСЛ совершенно не ясно.
    Ибо где гарантия, что они бы ее без ДСЛ осилили?

    M>>>Кто гарантирует корректность сгенерированного кода?

    WH>>Сначала ответь, кто гарантирует корректность написанного руками кода?
    M>Тесты и еще раз тесты.
    Вот и тут тесты. Только их надо намного меньше.

    Плюс не озвереешь тестами вот такой код проверять:
      Скрытый текст
    Вместо вопросов там юникодные символы.
          when (if (c >= '?') 
          {
            if (c >= '?') 
            {
              if (c >= '?') 
              {
                if (c >= '?') 
                {
                  if (c >= '?') 
                  {
                    if (c >= '?') 
                    {
                      if (c >= '?') 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          c <= '?'
                        }
                      }; else 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          c <= '?'
                        }
                      }
                    }; else 
                    {
                      if (c >= '?') 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          c <= '?'
                        }
                      }; else 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          if (c >= '?') 
                          {
                            c <= '?'
                          }; else 
                          {
                            c <= '?'
                          }
                        }
                      }
                    }
                  }; else 
                  {
                    if (c >= '?') 
                    {
                      if (c >= '?') 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          c <= '?'
                        }
                      }; else 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          c <= '?'
                        }
                      }
                    }; else 
                    {
                      if (c >= '?') 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          c <= '?'
                        }
                      }; else 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          if (c >= '?') 
                          {
                            c <= '?'
                          }; else 
                          {
                            c <= '?'
                          }
                        }
                      }
                    }
                  }
                }; else 
                {
                  if (c >= '?') 
                  {
                    if (c >= '?') 
                    {
                      if (c >= '?') 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          c <= '?'
                        }
                      }; else 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          c <= '?'
                        }
                      }
                    }; else 
                    {
                      if (c >= '?') 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          c <= '?'
                        }
                      }; else 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          if (c >= '?') 
                          {
                            c <= '?'
                          }; else 
                          {
                            c <= '?'
                          }
                        }
                      }
                    }
                  }; else 
                  {
                    if (c >= '?') 
                    {
                      if (c >= '?') 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          c <= '?'
                        }
                      }; else 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          if (c >= '?') 
                          {
                            c <= '?'
                          }; else 
                          {
                            c <= '?'
                          }
                        }
                      }
                    }; else 
                    {
                      if (c >= '?') 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          c <= '?'
                        }
                      }; else 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          if (c >= '?') 
                          {
                            c <= '?'
                          }; else 
                          {
                            c <= '?'
                          }
                        }
                      }
                    }
                  }
                }
              }; else 
              {
                if (c >= '?') 
                {
                  if (c >= '?') 
                  {
                    if (c >= '?') 
                    {
                      if (c >= '?') 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          c <= '?'
                        }
                      }; else 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          c <= '?'
                        }
                      }
                    }; else 
                    {
                      if (c >= '?') 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          c <= '?'
                        }
                      }; else 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          if (c >= '?') 
                          {
                            c <= '?'
                          }; else 
                          {
                            c <= '?'
                          }
                        }
                      }
                    }
                  }; else 
                  {
                    if (c >= '?') 
                    {
                      if (c >= '?') 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          c <= '?'
                        }
                      }; else 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          if (c >= '?') 
                          {
                            c <= '?'
                          }; else 
                          {
                            c <= '?'
                          }
                        }
                      }
                    }; else 
                    {
                      if (c >= '?') 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          c <= '?'
                        }
                      }; else 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          if (c >= '?') 
                          {
                            c <= '?'
                          }; else 
                          {
                            c <= '?'
                          }
                        }
                      }
                    }
                  }
                }; else 
                {
                  if (c >= '?') 
                  {
                    if (c >= '?') 
                    {
                      if (c >= '?') 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          c <= '?'
                        }
                      }; else 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          c <= '?'
                        }
                      }
                    }; else 
                    {
                      if (c >= '?') 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          c <= '?'
                        }
                      }; else 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          if (c >= '?') 
                          {
                            c <= '?'
                          }; else 
                          {
                            c <= '?'
                          }
                        }
                      }
                    }
                  }; else 
                  {
                    if (c >= '?') 
                    {
                      if (c >= '?') 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          c <= '?'
                        }
                      }; else 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          if (c >= '?') 
                          {
                            c <= '?'
                          }; else 
                          {
                            c <= '?'
                          }
                        }
                      }
                    }; else 
                    {
                      if (c >= '?') 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          c <= '?'
                        }
                      }; else 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          if (c >= '?') 
                          {
                            c <= '?'
                          }; else 
                          {
                            c <= '?'
                          }
                        }
                      }
                    }
                  }
                }
              }
            }; else 
            {
              if (c >= '?') 
              {
                if (c >= '?') 
                {
                  if (c >= '?') 
                  {
                    if (c >= '?') 
                    {
                      if (c >= '?') 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          c <= '?'
                        }
                      }; else 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          c <= '?'
                        }
                      }
                    }; else 
                    {
                      if (c >= '?') 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          c <= '?'
                        }
                      }; else 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          if (c >= '?') 
                          {
                            c <= '?'
                          }; else 
                          {
                            c <= '?'
                          }
                        }
                      }
                    }
                  }; else 
                  {
                    if (c >= '?') 
                    {
                      if (c >= '?') 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          c <= '?'
                        }
                      }; else 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          c <= '?'
                        }
                      }
                    }; else 
                    {
                      if (c >= '?') 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          c <= '?'
                        }
                      }; else 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          if (c >= '?') 
                          {
                            c <= '?'
                          }; else 
                          {
                            c <= '?'
                          }
                        }
                      }
                    }
                  }
                }; else 
                {
                  if (c >= '?') 
                  {
                    if (c >= '?') 
                    {
                      if (c >= '?') 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          c <= '?'
                        }
                      }; else 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          c <= '?'
                        }
                      }
                    }; else 
                    {
                      if (c >= '?') 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          c <= '?'
                        }
                      }; else 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          if (c >= '?') 
                          {
                            c <= '?'
                          }; else 
                          {
                            c <= '?'
                          }
                        }
                      }
                    }
                  }; else 
                  {
                    if (c >= '?') 
                    {
                      if (c >= '?') 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          c <= '?'
                        }
                      }; else 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          if (c >= '?') 
                          {
                            c <= '?'
                          }; else 
                          {
                            c <= '?'
                          }
                        }
                      }
                    }; else 
                    {
                      if (c >= '?') 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          c <= '?'
                        }
                      }; else 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          if (c >= '?') 
                          {
                            c <= '?'
                          }; else 
                          {
                            c <= '?'
                          }
                        }
                      }
                    }
                  }
                }
              }; else 
              {
                if (c >= '?') 
                {
                  if (c >= '?') 
                  {
                    if (c >= '?') 
                    {
                      if (c >= '?') 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          c <= '?'
                        }
                      }; else 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          c <= '?'
                        }
                      }
                    }; else 
                    {
                      if (c >= '?') 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          c <= '?'
                        }
                      }; else 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          if (c >= '?') 
                          {
                            c <= '?'
                          }; else 
                          {
                            c <= '?'
                          }
                        }
                      }
                    }
                  }; else 
                  {
                    if (c >= '?') 
                    {
                      if (c >= '?') 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          c <= '?'
                        }
                      }; else 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          if (c >= '?') 
                          {
                            c <= '?'
                          }; else 
                          {
                            c <= '?'
                          }
                        }
                      }
                    }; else 
                    {
                      if (c >= '?') 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          c <= '?'
                        }
                      }; else 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          if (c >= '?') 
                          {
                            c <= '?'
                          }; else 
                          {
                            c <= '?'
                          }
                        }
                      }
                    }
                  }
                }; else 
                {
                  if (c >= '?') 
                  {
                    if (c >= '?') 
                    {
                      if (c >= '?') 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          c <= '?'
                        }
                      }; else 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          c <= '?'
                        }
                      }
                    }; else 
                    {
                      if (c >= '?') 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          c <= '?'
                        }
                      }; else 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          if (c >= '?') 
                          {
                            c <= '?'
                          }; else 
                          {
                            c <= '?'
                          }
                        }
                      }
                    }
                  }; else 
                  {
                    if (c >= '?') 
                    {
                      if (c >= '?') 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          c <= '?'
                        }
                      }; else 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          if (c >= '?') 
                          {
                            c <= '?'
                          }; else 
                          {
                            c <= '?'
                          }
                        }
                      }
                    }; else 
                    {
                      if (c >= '?') 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          c <= '?'
                        }
                      }; else 
                      {
                        if (c >= '?') 
                        {
                          c <= '?'
                        }; else 
                        {
                          if (c >= '?') 
                          {
                            c <= '?'
                          }; else 
                          {
                            c <= '?'
                          }
                        }
                      }
                    }
                  }
                }
              }
            }
          }; else 
          {
            false
          }) goto l4687 [1];;

    Меж тем при создании ДСЛ генерация такой лапши отлаживается один раз.
    После чего эта лапша очень много раз генерируется без единой ошибки.

    M>Проигнорировано тобой:

    Да чуть менее чем все языковые фреймворки.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[61]: Какие порядки?!
    От: Wolverrum Ниоткуда  
    Дата: 21.05.12 19:04
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    W>>Имхо, что-то с методикой подсчета и сравнения не то.

    WH>С ней все нормально.
    Отношение КодДСП/ГенереныйКод асимптотически к нулю стремится. Очень похоже, где-то лажа в методе, не находишь?
    Re[62]: Какие порядки?!
    От: WolfHound  
    Дата: 21.05.12 19:08
    Оценка:
    Здравствуйте, Wolverrum, Вы писали:

    WH>>С ней все нормально.

    W>Отношение КодДСП/ГенереныйКод асимптотически к нулю стремится. Очень похоже, где-то лажа в методе, не находишь?
    Генеренный код обычно примерно равен рукописному.
    Так что не нахожу.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[68]: Не понял
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 21.05.12 21:58
    Оценка: +3
    Здравствуйте, Mamut, Вы писали:

    M>>>В случае, если разница в 10 раз, нас мало интересует, во что он там разворачивается.

    WH>>Разница на порядок ерунда.
    WH>>Подумаешь, проект будут делать 10-100 человеколет, а не один.
    WH>>Фигня какая.

    M>А, ну да. Мы уже ВНЕЗАПНО весь проект DSL'ями заменили, ага-ага.

    У вас проблема в том, что ты под DSL имеешь в виду неопределённый артикль. Отсюда и сомнения. А он имеет в виду артикль определённый — то есть DSL, построенный не вручную, из глины и навоза, а при помощи DSL для DSL. Тогда всё окружение и полный development experience доступны из коробки.

    Это предельный переход второго порядка. То есть сначала ты понимаешь, что DSL позволяет решить прикладную задачу в 2 раза дешевле. Но если сам DSL дорогой, то ты не станешь им заморачиваться, кроме случаев очень дорогих прикладных задач.
    А если ты имеешь DSL2, который позволяет в десять раз сократить стоимость написания DSL, то DSL резко становится выгодным даже на маленьких задачах.
    Предполагается, что в DSL2 тоже есть все средства полного development experience — отладка, тестирование, и прочее. Таким образом, ты относительно дешёво отлаживаешь удочку, при помощи которой ловишь гарантированно корректную рыбу.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[69]: Не понял
    От: Mamut Швеция http://dmitriid.com
    Дата: 22.05.12 11:48
    Оценка:
    M>>А, ну да. Мы уже ВНЕЗАПНО весь проект DSL'ями заменили, ага-ага.
    S>У вас проблема в том, что ты под DSL имеешь в виду неопределённый артикль. Отсюда и сомнения. А он имеет в виду артикль определённый — то есть DSL, построенный не вручную, из глины и навоза, а при помощи DSL для DSL. Тогда всё окружение и полный development experience доступны из коробки.

    Ну так я про это говор много раз. Что Wolfhound имеет в виду некий сферовакуумный мир, где бегают пони и какают бабочками. Я, как и большинство людей, живу в реальном мире, где вся эта «изкаробка» недоступна в принципе.

    S>Это предельный переход второго порядка. То есть сначала ты понимаешь, что DSL позволяет решить прикладную задачу в 2 раза дешевле. Но если сам DSL дорогой, то ты не станешь им заморачиваться, кроме случаев очень дорогих прикладных задач.

    S>А если ты имеешь DSL2, который позволяет в десять раз сократить стоимость написания DSL, то DSL резко становится выгодным даже на маленьких задачах.
    S>Предполагается, что в DSL2 тоже есть все средства полного development experience — отладка, тестирование, и прочее. Таким образом, ты относительно дешёво отлаживаешь удочку, при помощи которой ловишь гарантированно корректную рыбу.

    Дело в том, что это только предполагается. Wolfhound упорно говорит об этом, как о свершившемся факте


    dmitriid.comGitHubLinkedIn
    Re[73]: Не понял
    От: Mamut Швеция http://dmitriid.com
    Дата: 22.05.12 12:04
    Оценка:
    M>>Ну, сказать нечего тебе. Ты рассказываешь небылицы про то все радужно, как все автоматически генерируется, как все абсолютно инструменты заменены ДСЛями и т.п. Только все это сказки, потому что в реально мире такого нет, или такого исчезающе мало. Вот, ты даже мой вопрос про инструменты решил полностью поскипать.
    WH>Так ты даже на немерле не посмотрел.
    WH>В нем это в большинстве случаев само происходит.

    А ну да. Немерле. Который, как нам известно со слов самих разработчиков, в природе существует чуть менее, чем полностью (Н1 на такое не тянет, Н2 в разработке). И который невозможно будет использовать в 100% проектов, которые не используют .NET. Но да, ты что, это такие мелочи.

    M>>

    M>>В этом месте ты начинаешь вещать про криворуких уродов, которые пользуются не теми инструментами.


    M>>Сказал ты не так грубо, но реакция предсказана еще пару сообщений тому назад.
    WH>А что еще можно ожидать, если ты сам говоришь, что они не осилили задачу?
    WH>И причем тут ДСЛ совершенно не ясно.
    WH>Ибо где гарантия, что они бы ее без ДСЛ осилили?

    Ага. Wolfhound в своем репертуаре. Главное изменить тему обсуждения — авось никто не заметит.

    Я утверждаю, что твои пламенные речи про то, что поддержка DSL'я (не только кода, написанного на DSL'е, а всей инфраструктуры для этого DSL'я) прям-таки намного легче, чем альтернативные решения не имеют подтверждения, кроме твоих плменных речей, которые не имеют подтверждения кроме...

    Я не утверждаю, что они осилили бы решение без DSL. Я утверждаю ровно одно: у нас два DSL'я. Один поддерживать легко (пока что легко, потому что есть люди, которые писали компилятор, и которые знают, как он работает) второй — нет. Первый подтверждает твою точку зрения, второй — нет.

    Задачу они осилили. DSL — вот он. Есть и используется. Только вот ВНЕЗАПНО его поддержка не «в 10-100 раз легче».

    M>>>>Кто гарантирует корректность сгенерированного кода?

    WH>>>Сначала ответь, кто гарантирует корректность написанного руками кода?
    M>>Тесты и еще раз тесты.
    WH>Вот и тут тесты. Только их надо намного меньше.

    WH>Плюс не озвереешь тестами вот такой код проверять:

    WH>
      Скрытый текст
    WH>Вместо вопросов там юникодные символы.


    для этого есть инструменты типа PropEr

    WH>Меж тем при создании ДСЛ генерация такой лапши отлаживается один раз.


    Приведенный код — тупая генерация кода. Что не иллюстрирует, как ты там говорил? «кучу проверок при компиляции ДСЛ». А если взяться за оптимизацию генерируемого кода... . В общем, пока что между «есть ДСЛ» и «он нам нагенерит!!!одинодинодин» ты постоянно пропускаешь шаг проверки валидности окда. Нет, если это простейший DSL, который тупо генерит if'ы на проверку юникодных символов, это да, там можно чуть ли не ручками проверить.

    Но тут же рядом ты приводишь язык
    Автор: WolfHound
    Дата: 07.04.12
    , на разработку которого потрачен год работы. Но да, ты что, этот компилятор не надо ни поддерживать, ни фиксить, ни проверять на правильность работы — оно ВСЕ САМО!!!!

    M>>Проигнорировано тобой:

    WH>Да чуть менее чем все языковые фреймворки.

    Какие? Заметь, это в третий раз задаю вопрос. Такое впечатление, что ты просто не знаешь ответа на этот вопрос. Заметь, ты говоришь про фреймворки во множественном числе. То есть одним Немерле (который вообще только находится в разработке) обойтись сложно.


    dmitriid.comGitHubLinkedIn
    Re[74]: Не понял
    От: WolfHound  
    Дата: 22.05.12 13:16
    Оценка:
    Здравствуйте, Mamut, Вы писали:

    M>А ну да. Немерле. Который, как нам известно со слов самих разработчиков, в природе существует чуть менее, чем полностью (Н1 на такое не тянет,

    Н1 много чего тянет.

    M>Н2 в разработке). И который невозможно будет использовать в 100% проектов, которые не используют .NET. Но да, ты что, это такие мелочи.

    Это твои домыслы.
    Уже много раз говорилось что Н2 не будет привязан к платформе.

    M>Ага. Wolfhound в своем репертуаре. Главное изменить тему обсуждения — авось никто не заметит.

    Это не изменение темы.
    Просто ты пытаешься на одном примере доказать что ДСЛ не работают.

    M>Я утверждаю, что твои пламенные речи про то, что поддержка DSL'я (не только кода, написанного на DSL'е, а всей инфраструктуры для этого DSL'я) прям-таки намного легче, чем альтернативные решения не имеют подтверждения, кроме твоих плменных речей, которые не имеют подтверждения кроме...

    Так ты же сам сказал, что у других ребят проблем нет.
    У меня проблем нет.
    Еще у кучи народа проблем нет.
    А один перец не осилил.

    M>для этого есть инструменты типа PropEr

    Название не гуглится.

    M>Приведенный код — тупая генерация кода. Что не иллюстрирует, как ты там говорил? «кучу проверок при компиляции ДСЛ».

    Конечно, не иллюстрирует.
    Ибо проверки выполняются в другом месте.

    M>А если взяться за оптимизацию генерируемого кода... .

    Сказал человек, который ни разу в жизни не писал оптимизацию.

    M>В общем, пока что между «есть ДСЛ» и «он нам нагенерит!!!одинодинодин» ты постоянно пропускаешь шаг проверки валидности окда. Нет, если это простейший DSL, который тупо генерит if'ы на проверку юникодных символов, это да, там можно чуть ли не ручками проверить.

    Это ты не понимаешь что все ДСЛ и их оптимизации тупейшие.
    Просто по тому, что это все делается маленькими шагами.
    Каждый, из которых отлаживается отдельно.
    После чего куча шагов склеивается.

    M>Но тут же рядом ты приводишь язык
    Автор: WolfHound
    Дата: 07.04.12
    , на разработку которого потрачен год работы. Но да, ты что, этот компилятор не надо ни поддерживать, ни фиксить, ни проверять на правильность работы — оно ВСЕ САМО!!!!

    1)Там, на суровый ресерч потрачено год работы.
    2)Еще один год потрачен на разработку одного анализа на обычном языке. Причем он получился медленней.
    3)Эта ссылка как раз демонстрирует выигрыш в несколько десятков раз. Ибо на этом языке потом еще кучу анализов написали.

    M>Какие? Заметь, это в третий раз задаю вопрос. Такое впечатление, что ты просто не знаешь ответа на этот вопрос. Заметь, ты говоришь про фреймворки во множественном числе. То есть одним Немерле (который вообще только находится в разработке) обойтись сложно.

    Немерле уже давно как релиз.
    Но и кроме него проектов хватает.
    http://www.eclipse.org/Xtext/
    http://www.jetbrains.com/mps/
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[59]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 23.05.12 02:16
    Оценка:
    Здравствуйте, SleepyDrago, Вы писали:

    SD>могу констатировать полную победу текста на цифровых схемах. Аналоговые блоки описываются в текст и вставляются как черные ящики. за счет этого геометрии и шины и тп все генерируется исходя из текстовых моделей.


    Ну так генерится и визуально наблюдается. Без графического представления никак.
    Re[60]: Языки общего назначения не имеют смысла!
    От: FragMent  
    Дата: 23.05.12 11:02
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    V>Здравствуйте, SleepyDrago, Вы писали:


    SD>>могу констатировать полную победу текста на цифровых схемах. Аналоговые блоки описываются в текст и вставляются как черные ящики. за счет этого геометрии и шины и тп все генерируется исходя из текстовых моделей.


    V>Ну так генерится и визуально наблюдается. Без графического представления никак.

    Упрощенно маршрут проектирования цифровой схемы выглядит так:
    1. Текст на Verilog или VHDL
    2. Программа синтеза генерирует Verilog/VHDL нетлист (текстовый файл, содержащий библиотечные элементы и связи между ними)
    3. Программа автоматического размещения генерирует распложение элементов на будущем кристалле.
    4. Программа автоматической трассировки генерирует связи между ячейками.
    5. Программы физической верификации проверяют правильность шага 3 и 4.

    На любом из этапов 2-4 ты можешь посмотреть результаты в графическом виде, но особого смысла это не имеет.
    Как и программисту в большинстве случаев не имеет смысла смотреть в ассемблерный код после компилятора — даже если что-то там не устраивает,
    ты будешь менять программу на языке высокого уровня, а не латать код по живому.
    Так и цифровой дизайнер будем изменять verilog-код и генерирующие скрипты, а не сгенерированную из нетлиста схему электрическую.

    Для примера, можешь попробовать найти что-то кроме кода на http://opencores.org/

    С аналоговым дизайном это пока не так. Хотя и там понемногу ситуация меняется. Появляются коммерческие решения, в которых аналоговые блоки описываются уравнениями, из которых генерируются нетлисты.
    Re[61]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 25.05.12 09:10
    Оценка:
    Здравствуйте, FragMent, Вы писали:

    Не знаю, как там с проектированием кристаллов, но по многолетнему опыту проектирования схем и печатных плат на дискретных элементах:

    FM>1. Текст на Verilog или VHDL


    Это возможно только в "голой" цифровой логике из-за ее однородности. Я же говорю, текст прижился именно на таких однородных операциях, типа сплошного "copy&paste" и прочего глобального рефакторинга. Еще во времена PCAD если надо было выполнить какое-либо однородное переименование или массовое переподключение на другие шины — то делали это в текстовых исходниках, а не в графике. Но это менее 1% от всего разнообразия современной схемотехники. Сегодня одних только способов организовать емкости и индуктивности десятки, помимо дискретных элементов (на гигагерцовых диапазонах). А эти вещи только ручками.

    FM>3. Программа автоматического размещения генерирует распложение элементов на будущем кристалле.


    На печатной плате ВСЕГДА приходится поправлять расположение.

    FM>4. Программа автоматической трассировки генерирует связи между ячейками.


    ВСЕГДА приходится делать ревью трассировки и доводить вручную. Эта операция итеративная по кругу с предыдущей. Т.е. трассировка во многом управляет расположением и наоборот.

    FM>5. Программы физической верификации проверяют правильность шага 3 и 4.


    Это и так понятно, на то оно и CASE.

    А взять сложную схему с многообразием технологий (а не только одну булевскую логику)... я с трудом представляю как разбираться в принципиальной схеме без графического представления. Ты банально не поймешь принцип работы схемы, если там кол-во элементов перевалит за единицы десятков. Если же я не прав, просьба привести примеры, где бы в тексте разнообразная электроника смотрелась бы лучше. (Может я и не прав и сильно отстал за последние годы, когда уже не занимаюсь этим).

    FM>Для примера, можешь попробовать найти что-то кроме кода на http://opencores.org/


    Одна цифровая логика?

    FM>С аналоговым дизайном это пока не так. Хотя и там понемногу ситуация меняется. Появляются коммерческие решения, в которых аналоговые блоки описываются уравнениями, из которых генерируются нетлисты.


    Есть примеры достаточно сложных схем в текстовом виде с адаптивными фильтрами, умножителями (сигналов и частот), ФАПЧ и т.д.?

    В графическом виде в самую сложную и разнообразную по технологиям схему можно "воткнуть" за считанные минуты. Мне интересно сравнить с текстом.
    Re[62]: Языки общего назначения не имеют смысла!
    От: FragMent  
    Дата: 26.05.12 13:16
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    V>Здравствуйте, FragMent, Вы писали:


    V>Не знаю, как там с проектированием кристаллов, но по многолетнему опыту проектирования схем и печатных плат на дискретных элементах:


    FM>>1. Текст на Verilog или VHDL


    V>Это возможно только в "голой" цифровой логике из-за ее однородности. Я же говорю, текст прижился именно на таких однородных операциях, типа сплошного "copy&paste" и прочего глобального рефакторинга. Еще во времена PCAD если надо было выполнить какое-либо однородное переименование или массовое переподключение на другие шины — то делали это в текстовых исходниках, а не в графике. Но это менее 1% от всего разнообразия современной схемотехники. Сегодня одних только способов организовать емкости и индуктивности десятки, помимо дискретных элементов (на гигагерцовых диапазонах). А эти вещи только ручками.


    И я и SleepyDrago специально оговаривали что речь идет о цифровых схемах.
    Код процессора не более однороден, чем код на обычных языках программирования (с их циклами, условными операторами и вызовами функций). Ты же не используешь C# вместо ДРАКОНА только из за сплошного "copy&paste" и прочего глобального рефакторинга?
    FM>>3. Программа автоматического размещения генерирует распложение элементов на будущем кристалле.

    V>На печатной плате ВСЕГДА приходится поправлять расположение.


    FM>>4. Программа автоматической трассировки генерирует связи между ячейками.


    V>ВСЕГДА приходится делать ревью трассировки и доводить вручную. Эта операция итеративная по кругу с предыдущей. Т.е. трассировка во многом управляет расположением и наоборот.

    Если у тебя схема состоит из миллиона гейтов, ручками особо не поправишь.

    FM>>5. Программы физической верификации проверяют правильность шага 3 и 4.


    V>Это и так понятно, на то оно и CASE.


    V>А взять сложную схему с многообразием технологий (а не только одну булевскую логику)... я с трудом представляю как разбираться в принципиальной схеме без графического представления. Ты банально не поймешь принцип работы схемы, если там кол-во элементов перевалит за единицы десятков. Если же я не прав, просьба привести примеры, где бы в тексте разнообразная электроника смотрелась бы лучше. (Может я и не прав и сильно отстал за последние годы, когда уже не занимаюсь этим).

    Ну вот посмотри скриншот схемы, сгенерированной из верилога. Слишком много связей и понять, что происходит, сложно. А ведь это еще не самый тяжелый случай.

    FM>>Для примера, можешь попробовать найти что-то кроме кода на http://opencores.org/


    V>Одна цифровая логика?

    Да, учитывая что цифра сейчас самый распространенный тип дизайна.
    FM>>С аналоговым дизайном это пока не так. Хотя и там понемногу ситуация меняется. Появляются коммерческие решения, в которых аналоговые блоки описываются уравнениями, из которых генерируются нетлисты.

    V>Есть примеры достаточно сложных схем в текстовом виде с адаптивными фильтрами, умножителями (сигналов и частот), ФАПЧ и т.д.?

    Странно, что тебя нужно убеждать, что декларативное лучше императивного
    Из чего больше понятно, что происходит с сигналом?
    Из формулы или из схемы?


    И если будет нормальный инструмент позволяющий переводить формулы в схемы с гибкой настройкой конфигурации (тип фильтра, power/area/noise margin etc) с учетом используемой технологии, то вполне им вполне можно будет пользоваться для ускорения дизайна.
    Такой подход предлагала Magma Design Automation.
    Сейчас их сайт почему-то лежит, но был у них white paper, где они таким способом разработали LDO (low dropout regulator) — чисто аналоговую схему. К сожалению я не успел попробовать подход Magma da — их недавно приобрел Synospys.
    V>В графическом виде в самую сложную и разнообразную по технологиям схему можно "воткнуть" за считанные минуты. Мне интересно сравнить с текстом.
    В графическом виде ты получишь:
    1. Проблему, если поставщик схемы не имеет версии для твоего САПР-а
    2. Отсутствие diff
    3. Отсутствие version control
    4. Сотни связей для сложного блока.
    5. Слабую интеоперабельность между различными тулзами (только не надо про edif )

    Повторюсь. Цифровая схемотехника очень быстро упёрлась в ограничение графического представления и в настоящий момент полностью перешла на текстовый формат.
    Аналоговый дизайн еще использует графическое представление, но активно исследует возможности ухода от него. У меня половина блоков имеют дополнительное описание на аналоговом варианте HDL под названием verilog-a (очень удобно для ускорения моделирования).
    Re: Языки общего назначения не имеют смысла!
    От: Andrei N.Sobchuck Украина www.smalltalk.ru
    Дата: 28.05.12 06:04
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    btw, Scala-Virtualized
    Я ненавижу Hibernate
    Автор: Andrei N.Sobchuck
    Дата: 08.01.08
    !
    Re[61]: Языки общего назначения не имеют смысла!
    От: SleepyDrago Украина  
    Дата: 28.05.12 08:08
    Оценка:
    Здравствуйте, FragMent, Вы писали:

    ...
    FM>ты будешь менять программу на языке высокого уровня, а не латать код по живому.
    ...
    FM>С аналоговым дизайном это пока не так. Хотя и там понемногу ситуация меняется.

    у меня был реальный анекдот: мы делали sram память. И в одном из тестовых запусков обнаружили что и немцы (как заказчик и фаб) и мы профукали контакт торчащий из подложки. Причем когда заметили шаблон подложки уже был изготовлен, а контактов уже сгенерен. Дурное дело не хитрое — поправили шаблон жалко было запуск срывать. Работало Так что латать можно если не в космос летит. Имхо vdimas рассуждает исходя из плат и наводок — там все еще вуду и шаманы рулят открыто. В фабричных кристаллах уже все — поезд ушел. Аналоговые вещи типа sram делают избранные шаманы и то как они это делают достоянием общественности никогда не будет ибо там нарушаются любые правила, которые для обычных схем немыслимо нарушать.
    Re[62]: Языки общего назначения не имеют смысла!
    От: FragMent  
    Дата: 28.05.12 15:33
    Оценка:
    Здравствуйте, SleepyDrago, Вы писали:

    SD>Здравствуйте, FragMent, Вы писали:


    SD>...

    FM>>ты будешь менять программу на языке высокого уровня, а не латать код по живому.
    SD>...
    FM>>С аналоговым дизайном это пока не так. Хотя и там понемногу ситуация меняется.

    SD>у меня был реальный анекдот: мы делали sram память. И в одном из тестовых запусков обнаружили что и немцы (как заказчик и фаб) и мы профукали контакт торчащий из подложки. Причем когда заметили шаблон подложки уже был изготовлен, а контактов уже сгенерен. Дурное дело не хитрое — поправили шаблон жалко было запуск срывать. Работало Так что латать можно если не в космос летит.

    Ретушь шаблонов Лет 10 назад делал. Не знал, что и сейчас такое возможно.
    Мы в последнее время использовали FIB (focused ion beam) для разрезания проводников на пластине и напайке шин сверху. Заказчику такое не покажешь,
    но проверить дальшейшую работоспособность можно.
    А такие ошибки возникают из-за того, что разработчики правил lvs не на физику ориентируются, а на конкретные элементы
    В результате отдельные транзисторы нормально верифицируются, а как начинаешь вместе собирать, вылазит всякое.

    SD> Имхо vdimas рассуждает исходя из плат и наводок — там все еще вуду и шаманы рулят открыто. В фабричных кристаллах уже все — поезд ушел. Аналоговые вещи типа sram делают избранные шаманы и то как они это делают достоянием общественности никогда не будет ибо там нарушаются любые правила, которые для обычных схем немыслимо нарушать.

    Вуду на платах, потому что нормально не просимулируешь — все равно моделей чипов нет. Проще на макете убедится.
    А как начинаются тысячи и миллионы транзисторов на кристалле, то и оказывается, что и текстом схемы приходится описывать, и сутками симуляторы гонять.
    Даже не знаю где проще.

    Офтоп: мы с тобой пару раз в ЖЖ пересекались (я там анонимусом был). Ты утверждал, что спецжелезо (CUDA, CELL BE) не очень подходит для физической верификации.
    И судя по отсутствию прогресса в этой области, оказался прав
    Re: Языки общего назначения не имеют смысла!
    От: AlexCab LinkedIn
    Дата: 29.05.12 06:19
    Оценка:
    Здравствуйте, WolfHound, Вы писали:
    WH>Мест для ошибок в 10-100 раз меньше.
    WH>И каждая ошибка проявляется сразу по всему коду, а не в одном месте которое вызывается раз в год.
    WH>Так что мало того что ошибок будет в 10-100 раз меньше. Но их еще и поймать проще.

    Предположим, есть проект на N2, большой, много DSL, много участников. Были внесены изменения в один из DSL,ошибка проявилась по всему проекту. Какова цена исправления ошибки с сохранением изменений(по сравнению с использованием библиотек)?
    Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
    Re[2]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 29.05.12 09:03
    Оценка:
    Здравствуйте, AlexCab, Вы писали:

    AC>Предположим, есть проект на N2, большой, много DSL, много участников. Были внесены изменения в один из DSL,ошибка проявилась по всему проекту. Какова цена исправления ошибки с сохранением изменений(по сравнению с использованием библиотек)?

    По всему проекту?
    Замечательно.
    Эту ошибку с вероятностью 99% найдет тот кто ее сделал. До коммита. Ибо куча тестов покраснеет.
    В худшем случае первый же тестер.
    Соответственно будет известно, в какой правке ошибка.
    Цена исправления минимальна.
    Твой КО.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[3]: Языки общего назначения не имеют смысла!
    От: AlexCab LinkedIn
    Дата: 29.05.12 09:14
    Оценка:
    Здравствуйте, WolfHound, Вы писали:
    AC>>Предположим, есть проект на N2, большой, много DSL, много участников. Были внесены изменения в один из DSL,ошибка проявилась по всему проекту. Какова цена исправления ошибки с сохранением изменений(по сравнению с использованием библиотек)?
    WH>По всему проекту?
    WH>Замечательно.
    WH>Эту ошибку с вероятностью 99% найдет тот кто ее сделал. До коммита. Ибо куча тестов покраснеет.
    WH>В худшем случае первый же тестер.
    WH>Соответственно будет известно, в какой правке ошибка.
    Ok.

    WH>Цена исправления минимальна.

    Возможно ты имел ввиду цену поиска(выявления) ошибки?
    Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
    Re[4]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 29.05.12 09:30
    Оценка:
    Здравствуйте, AlexCab, Вы писали:

    WH>>Цена исправления минимальна.

    AC>Возможно ты имел ввиду цену поиска(выявления) ошибки?
    Нет. Если ошибка найдена в тот же момент, когда ее посадили, цена ее исправления минимальна.
    Ибо все данные об изменениях еще в кэше головного мозга разработчика.
    Такие ошибки обычно правятся, не приходя в сознание.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[5]: Языки общего назначения не имеют смысла!
    От: AlexCab LinkedIn
    Дата: 29.05.12 11:16
    Оценка:
    Здравствуйте, WolfHound, Вы писали:
    AC>>Возможно ты имел ввиду цену поиска(выявления) ошибки?
    WH>Нет. Если ошибка найдена в тот же момент, когда ее посадили, цена ее исправления минимальна.
    WH>Ибо все данные об изменениях еще в кэше головного мозга разработчика.
    Об изменениях им внесённых, да. Об том почему внесённые им изменения дают ошибку вне его части кода, и как это исправить, нет.
    И вот что ему делать, изменения необходимо внести, но это приводит к множеству ошибок в других местах? Как узнать что и как исправлять?

    Ещё сценарий:
    Тот же проект, на это раз изменение семантике одного из DSL, например незначительные изменение в логике работы какого ни будь оператора(с целью рефакторинга к примеру).
    Всё собралось без ошибок. Всё работает, кроме некоторых кусков кода, программисты которых не любят внимательно читать документацию и/или предпочитают использовать метод научного тыка.
    То есть высока вероятность возникновения сайдэфектов(вроде тех что возникают из-за глобальных переменных).
    Как ты планируешь с подобным "бороться"?
    Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
    Re[6]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 29.05.12 12:37
    Оценка:
    Здравствуйте, AlexCab, Вы писали:

    AC>Об изменениях им внесённых, да. Об том почему внесённые им изменения дают ошибку вне его части кода, и как это исправить, нет.

    AC>И вот что ему делать, изменения необходимо внести, но это приводит к множеству ошибок в других местах? Как узнать что и как исправлять?
    Точно так же как и с любым другим кодом.
    Садится и анализирует что сломалось.
    После чего чинит.

    Не понимаю в чем ты видишь трудности.

    AC>Ещё сценарий:

    AC>Тот же проект, на это раз изменение семантике одного из DSL, например незначительные изменение в логике работы какого ни будь оператора(с целью рефакторинга к примеру).
    AC>Всё собралось без ошибок. Всё работает, кроме некоторых кусков кода, программисты которых не любят внимательно читать документацию и/или предпочитают использовать метод научного тыка.
    AC>Как ты планируешь с подобным "бороться"?
    То же самое можно сказать про библиотечный код.

    Но в случае с ДСЛ при обнаружении таких проблем можно сделать анализатор кода который на все места не правильного использования выдаст ошибку или предупреждение.

    С библиотекой такой фокус не пройдет.

    AC>То есть высока вероятность возникновения сайдэфектов(вроде тех что возникают из-за глобальных переменных).

    Ничего общего.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[7]: Языки общего назначения не имеют смысла!
    От: AlexCab LinkedIn
    Дата: 29.05.12 13:44
    Оценка:
    Здравствуйте, WolfHound, Вы писали:
    WH>Точно так же как и с любым другим кодом.
    WH>Садится и анализирует что сломалось.
    WH>После чего чинит.
    WH>Не понимаю в чем ты видишь трудности.
    В том что анализировать придётся генерированный код, который будет мягко говоря путаным(из-за концепции N2 "не важно во что оно скомпилируется" и эволюции).

    WH>То же самое можно сказать про библиотечный код.

    WH>Но в случае с ДСЛ при обнаружении таких проблем можно сделать анализатор кода который на все места не правильного использования выдаст ошибку или предупреждение.
    WH>С библиотекой такой фокус не пройдет.
    Библиотеки можно тестировать, что трудней писать(тесты или анализатор)не знаю, спорить не буду. Подумай, может быть есть решение лучше.

    AC>>То есть высока вероятность возникновения сайдэфектов(вроде тех что возникают из-за глобальных переменных).

    WH>Ничего общего.
    Изменения в одном DSL влияют на другие DSL основанные на/использующие первый(как изменение глобальной переменной влияет на результат функций её использующих), разве это не побочные эфекты.
    Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
    Re[8]: Языки общего назначения не имеют смысла!
    От: WolfHound  
    Дата: 29.05.12 14:34
    Оценка: 2 (1)
    Здравствуйте, AlexCab, Вы писали:

    AC>В том что анализировать придётся генерированный код, который будет мягко говоря путаным(из-за концепции N2 "не важно во что оно скомпилируется" и эволюции).

    Это не так сложно как ты думаешь.
    Поверь тому, кто его анализировал.

    В любом случае обычно сразу ясно, где косяк. Даже не заглядывая в генерируемый код.

    AC>Библиотеки можно тестировать, что трудней писать(тесты или анализатор)не знаю, спорить не буду. Подумай, может быть есть решение лучше.

    ДСЛи точно так же можно тестировать.
    Но кроме тестов можно еще и анализ написать который бует проверять код который пишет пользователь ДСЛ.
    Библиотеки такое не могут.

    AC>Изменения в одном DSL влияют на другие DSL основанные на/использующие первый(как изменение глобальной переменной влияет на результат функций её использующих), разве это не побочные эфекты.

    Изменения в одной библиотеке влияют на другие библиотеки, основанные на/использующие первую (как изменение глобальной переменной влияет на результат функций её использующих), разве это не побочные эффекты.

    Пожалуйста, не путай зависимость одного кода от другого и глобальное состояние.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[9]: Языки общего назначения не имеют смысла!
    От: AlexCab LinkedIn
    Дата: 29.05.12 14:57
    Оценка:
    Здравствуйте, WolfHound, Вы писали:
    WH>Это не так сложно как ты думаешь.
    WH>Поверь тому, кто его анализировал.
    WH>В любом случае обычно сразу ясно, где косяк. Даже не заглядывая в генерируемый код.
    Допилите — узнаем

    AC>>Изменения в одном DSL влияют на другие DSL основанные на/использующие первый(как изменение глобальной переменной влияет на результат функций её использующих), разве это не побочные эфекты.

    WH>Пожалуйста, не путай зависимость одного кода от другого и глобальное состояние.
    D'oh
    Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
    Re[13]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 04.06.12 11:19
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    T>>Я видел проекты где решения вроде string.split работали десятками лет. Для чего там полноценный парсер ? Я вот не смог объяснить, потому там и по сей день string.split.


    V>Если объемы данных невелики, то пойдет string.split, если же велики — то только оперативная обработка.


    Именно из за объемов данных был выбран string.split, поскольку он рвёт любой другой парсер в хлам.
    "оперативная обработка" — я не понял этот термин — если это полноценный парсер, то он нужен только в том случае, если не хватит возможностей string.split. Даже так — если проблемы со string.split превысят определенный порог.
    The animals went in two by two, hurrah, hurrah...
    Re[25]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 04.06.12 11:20
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    T>>Тут самое интересное начинается. Есть ДСЛ для организации всяких импортов ?


    AVK>По странному стечению обстоятельств мне в ближайшее время предстоит спроектировать такой DSL.


    Покажи на досуге пару вариантов для импорта ?
    The animals went in two by two, hurrah, hurrah...
    Re[26]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 04.06.12 13:01
    Оценка: 2 (1)
    Здравствуйте, Tanker, Вы писали:

    T>Покажи на досуге пару вариантов для импорта ?


    А смысл? Все равно это все привязано к конкретным требованиям.
    Впрочем, мне не сложно:
    <import xmlns="http://parus.ru/ImportFileSchema.xsd" xmlns:v="http://parus.ru/ImportFileValuesSchema.xsd">
      <include>Include.xml</include>
      
      <class name=’Common.Currency’>
        <extern id=’Currency.USD’ v:Mnemo=’USD’/>
      </class>
    
      <class name=’My.MyClass’>
        <set v:Date='$(CurrentDate)'/>
    
        <where v:Foo=’4’ v:Bar=’Value’>
          <insert v:X=’14’ v:Y=’OLaLa’/>
        </where>
    
        <where v:Foo=’5’>
          <delete/>
        </where>
        
        <table action="insert-or-update"
               key-attrs="Foo, Bar"
               value-attrs="X, Y, Z">
          1,1,'x1','y1','z1'
          1,2,'x2','y2','z2'
          2,1,'x3','y3','z3'
          2,2,'x4','y4','z4'
          1,3,'x5','y5','z5'
        </table>
      </class>
    </import>
    ... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[63]: Языки общего назначения не имеют смысла!
    От: netch80 Украина http://netch80.dreamwidth.org/
    Дата: 04.06.12 16:39
    Оценка:
    Здравствуйте, FragMent, Вы писали:

    FM>В графическом виде ты получишь:

    FM>1. Проблему, если поставщик схемы не имеет версии для твоего САПР-а
    FM>2. Отсутствие diff
    FM>3. Отсутствие version control
    FM>4. Сотни связей для сложного блока.
    FM>5. Слабую интеоперабельность между различными тулзами (только не надо про edif )

    По-моему, ты таки путаешь графический дизайн с неизвестным внутренним представлением с дизайном с известным, текстовым, но с адаптацией под графические средства. Например, в описание объекта могут входить желаемые экранные координаты, номер слоя, и тому подобное.
    Я не работал плотно с САПР и не знаю, делает ли такое кто-то, но теоретически оно беспроблемно допустимо.

    А что плохого в сотнях связей для сложного блока, если он действительно сложный?

    FM>Повторюсь. Цифровая схемотехника очень быстро упёрлась в ограничение графического представления и в настоящий момент полностью перешла на текстовый формат.


    Они друг другу не противоречат.

    FM>Аналоговый дизайн еще использует графическое представление, но активно исследует возможности ухода от него.


    Вопрос, наверно, больше в выборе оптимального для всех САПР стандарта описания? Каждое конкретное запихнуть в текст будет несложно.
    The God is real, unless declared integer.
    Re[64]: Языки общего назначения не имеют смысла!
    От: FragMent  
    Дата: 04.06.12 18:17
    Оценка:
    Здравствуйте, netch80, Вы писали:

    N>Здравствуйте, FragMent, Вы писали:


    FM>>В графическом виде ты получишь:

    FM>>1. Проблему, если поставщик схемы не имеет версии для твоего САПР-а
    FM>>2. Отсутствие diff
    FM>>3. Отсутствие version control
    FM>>4. Сотни связей для сложного блока.
    FM>>5. Слабую интеоперабельность между различными тулзами (только не надо про edif )

    N>По-моему, ты таки путаешь графический дизайн с неизвестным внутренним представлением с дизайном с известным, текстовым, но с адаптацией под графические средства. Например, в описание объекта могут входить желаемые экранные координаты, номер слоя, и тому подобное.

    N>Я не работал плотно с САПР и не знаю, делает ли такое кто-то, но теоретически оно беспроблемно допустимо.
    Нет, не путаю. Просто перечислил возможные проблемы. Их можно разделить на две группы.
    1. Проблема формата хранения схемы (п. 1, 2, 3, 5)
    2. Проблема работы с графическим представлением (п. 4).

    N>Например, в описание объекта могут входить желаемые экранные координаты, номер слоя, и тому подобное.

    N>Я не работал плотно с САПР и не знаю, делает ли такое кто-то, но теоретически оно беспроблемно допустимо.
    В теории — да. А на практике получается следующее. Имеется некая схема, тебе нужно вставить новый блок между старыми.
    Для этого придется раздвинуть старые блоки, разместить новый символ, изменить соединения, если между старыми блоками еще остались связи, провести их мимо нового блока. В результате любая система version control не будет иметь смысла, поскольку за изменениями визуального представления не видно сути.
    N>А что плохого в сотнях связей для сложного блока, если он действительно сложный?
    1. Та же самая ситуация со вставкой нового блока. Раздвигаем старые блоки и случайно закорачиваем две из сотен связей. Очень легко упустить этот момент, особенно если у связей нету имен.
    2. Допустим есть глобальная связь, которая идет во множество блоков (например какой-нибудь clock). Нужно проверить все входы к которым эта связь подключена. В текстовом варианте, ты запускаешь поиск по файлам и легко видишь все вхождения. В графическом режиме ты подсвечиваешь нужную связь и обнаруживаешь, что она представляет собой ломанную линию с множеством ответвлений.
    Нужно просмотреть каждую ветку, заходя рекурсивно в каждый блок. Очень легко пропустить что-нибудь.

    FM>>Повторюсь. Цифровая схемотехника очень быстро упёрлась в ограничение графического представления и в настоящий момент полностью перешла на текстовый формат.


    N>Они друг другу не противоречат.

    Не противоречат, но по факту в современной цифровой схемотехнике используют vhdl, verilog, а не schematic capture.
    Все что я выше описывал — это поиск причин post factum. Как только появилась возможность синтезировать схемы из HDLs,
    цифровики стройными рядами двинулись в этом направлении.

    FM>>Аналоговый дизайн еще использует графическое представление, но активно исследует возможности ухода от него.


    N>Вопрос, наверно, больше в выборе оптимального для всех САПР стандарта описания? Каждое конкретное запихнуть в текст будет несложно.

    Нет. Чуть выше в том посте я описал, что имею в виду (синтез аналоговых схем из формул и язык verilog-a (не путать c verilog) для моделирования
    аналоговых блоков на более высоком уровне).

    А стандарт на графическое типа есть, я уже упоминал edif. Дважды пытался его использовать, первый раз обломался и перерисовал все руками (благо схема была небольшая).
    Второй раз, при помощи питоновского скрипта и такой-то матери удалось худо-бедно перенести схему между САПРами. Но все равно пришлось еще пару тысяч элементов поправлять ручками.

    P.S. Я не противник графического представления. Более того, мне с графикой приходится работать больше, чем с текстом. Просто vdimas выбрал не очень удачный пример для демонстрации преимуществ графического dsl.
    Re[15]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 05.06.12 09:51
    Оценка: 30 (1) +1
    Здравствуйте, VladD2, Вы писали:

    VD>Берем книгу дракона, глядим... Ба да там ни TDOP Пратта, ни PEG Форда нет. Ну, с PEG еще можно понять. Ему не так много лет (хотя базе уже лет 40, не меньше). Но TDOP — это 1974 год.


    VD>А где доценты материал для курсов берут? Да из кнжек, что купили на Озоне, и из того пиара, что валит из-за всех дыр.


    Конспироложество в чистом виде. Доцент не берет материал, ему ставят задачу, какой материал читать студентам. Т.е. Грамматики, BNF + LR-парсеры. Всё, приехали, у доцента выбора нет.

    Почему доценту ставят такую задачу. Надо понимать, что такое система образования. В этом частном аспекте она работает таким образом — если широко используется скажем gcc, то студентов нужно готовить таким образом, что бы они понимали весь мат-бекграунд который стоит за gcc.
    То есть, обязательный минимум именно этот бекграунд. То есть, внимание — не конкретные алгоритмы, методики, техники — а весь матбекграунд.

    Абсолютно такой же подход например с случае с высшей математикой — конкретный инженер не использует 95% знаний которые даются в вузовском курсе. Но это вовсе не значит, что не надо давать эти 95% процентов.
    В этой математике есть точно такие же как ты, которые орут, что де не надо давать весь этот мусор, дескать достаточно научить студента считать интеграл или преобразования фурье конкретным методом.

    Теперь про TDOP пратта.
    Для него нет необходимости делать специальные курсы и тд — любой студент, который освоил обычный top down и operator precedence сможет освоить и Пратта без каких либо эксцессов. И то и другое есть в книге дракона. Математика она вообще разивается в отрыве от прикладных областей, на то она и математика.
    The animals went in two by two, hurrah, hurrah...
    Re[19]: Языки общего назначения не имеют смысла!
    От: Tanker  
    Дата: 05.06.12 14:04
    Оценка:
    Здравствуйте, fmiracle, Вы писали:

    T>>Так и думают теоретики. Практики понимают, что задача сводится к импорту данных кастомера и импортируют даже ничего не зная про CSV. Собтсвенно string.split это однозначно доказывает.


    F>Ну да. Ничего не зная про некоторый формат Х, они делают импорт из другого формата, лишь частично совпадающего с указанным, и гордо называют это "импорт из Х".


    Идейка гораздо проще — парсинг в импорте дело однозначно второстепенное. Самое главное это сам импорт, это просто чудовищный workflow по трудозатратам и важности он на порядки превосходит парсинг.
    The animals went in two by two, hurrah, hurrah...
    Re[25]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 06.06.12 22:21
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    AVK>>Да без проблем могу привести. Только непонятно, чем это тебе поможет...


    VD>Это уже лучше. Только это все еще очень поверхностное описание интерефейса модели. А нужна конкретика. Опиши зачем нужны эти сущности. Каковы между ними связи...


    Да какая фиг разница? У разных сущностей разные связи. В системах учета предприятий гвоздем является документ (даже если для него нет соотв. твердой копии). Документ описывает "исходник" некоей бизнес-операции. Система выполняет вычисления по внутренним регистрам на основании "исходников". Связь м/у регистрами и первичкой в общем случае многие ко многим. Самые популярные связи в самих документах — это master-detail, где реляция 1:oo, master предствляет из себя сам документ и к нему один или несколько списков detail. Но точно такая же связь со справочными данными рассматривается уже как просто отсылка к справочнику, а не master-detail. Связи м/у документами — аналогично, это просто связи, от 1(null):1(null) вплоть до oo:oo. Пожалуй, на этом особенности бизнес-логик, пляшущих от документов, заканчиваются. Остальное вполне стандартное, присущее не только системам с эмуляцией документооборота: необходимо реляционную модель в базе выворачивать "наоборот" в граф объектов, чтобы получать навигационную ОО-модель из реляционной.


    VD>Ну, и в двух словах опиши что же делала та замечательная простыня кода. Ведь она явно делала что-то не сложное. Да? Там что-то откуда-то удалялось. Вот и объясни: что, откуда, зачем и по каким правилам.


    Абсолютно неважно. Там просто навигация по связанным объектам, проверка бизнес-условий, выборка во временные коллекции для следующего этапа алгоритма и т.д. Ничего военного технологически и ничего интересного с прикладной т.з. В итоге, кол-во интересующих операций — ровно 4: CRUD. Остальные прикладные операции — это просто операции более высокого уровня на основе базовых.
    Re[22]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 06.06.12 22:24
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    AVK>Дернуть из конфигурации 1С код — будет примерно то же самое.


    Не совсем. Я точно такой же код предпочитал писать на VB, чтобы не приводить к типизированным интерфейсам. Код получался немного чище. В этом смысле VB — неплохой DSL. ))
    Аналогично язык 1С.
    Re[14]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 07.06.12 09:15
    Оценка: 3 (1)
    Здравствуйте, Tanker, Вы писали:

    T>Именно из за объемов данных был выбран string.split, поскольку он рвёт любой другой парсер в хлам.


    Это не совсем так. Вот что сам МС пишет:

    Performance Considerations
    The Split methods allocate memory for the returned array object and a String object for each array element. If your application requires optimal performance or if managing memory allocation is critical in your application, consider using the IndexOf or IndexOfAny method, and optionally the Compare method, to locate a substring within a string.
    If you are splitting a string at a separator character, use the IndexOf or IndexOfAny method to locate a separator character in the string. If you are splitting a string at a separator string, use the IndexOf or IndexOfAny method to locate the first character of the separator string. Then use the Compare method to determine whether the characters after that first character are equal to the remaining characters of the separator string.
    In addition, if the same set of characters is used to split strings in multiple Split method calls, consider creating a single array and referencing it in each method call. This significantly reduces the additional overhead of each method call.

    ... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[63]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 08.06.12 08:58
    Оценка:
    Здравствуйте, FragMent, Вы писали:

    V>>А взять сложную схему с многообразием технологий (а не только одну булевскую логику)... я с трудом представляю как разбираться в принципиальной схеме без графического представления. Ты банально не поймешь принцип работы схемы, если там кол-во элементов перевалит за единицы десятков. Если же я не прав, просьба привести примеры, где бы в тексте разнообразная электроника смотрелась бы лучше. (Может я и не прав и сильно отстал за последние годы, когда уже не занимаюсь этим).

    FM>Ну вот посмотри скриншот схемы, сгенерированной из верилога. Слишком много связей и понять, что происходит, сложно. А ведь это еще не самый тяжелый случай.

    Ну вижу много связей. Вижу лишь слабость инструмента. Почему не произведено группрование связей по шинам? ТАм будет всего 2-3 шины (разрешение скриншота не позволяет сказать точно), и порядка десятка отдельных управляющих концов. полнейший примитив, если правильно представить в графике. Сложные схемы начинаются от полусотни цифровых и от несколькьких сотен аналоговых элементов и от десятков шин.

    Кстати, а можно посмотреть на соответствующий этой схеме исходный код?

    V>>Одна цифровая логика?

    FM>Да, учитывая что цифра сейчас самый распространенный тип дизайна.

    Учитывая распространенность мобильных, обычных проводных сетевых технологий, встроенных жжидкокристаллических и т.д. — ты сильно заблуждаешься. Просто тебе из подвала не видно.

    FM>>>С аналоговым дизайном это пока не так. Хотя и там понемногу ситуация меняется. Появляются коммерческие решения, в которых аналоговые блоки описываются уравнениями, из которых генерируются нетлисты.


    V>>Есть примеры достаточно сложных схем в текстовом виде с адаптивными фильтрами, умножителями (сигналов и частот), ФАПЧ и т.д.?

    FM>Странно, что тебя нужно убеждать, что декларативное лучше императивного
    FM>Из чего больше понятно, что происходит с сигналом?
    FM>Из формулы или из схемы?

    Я бы взял чуть другую схему для бОльшей добротности, но не суть.

    FM>И если будет нормальный инструмент позволяющий переводить формулы в схемы с гибкой настройкой конфигурации (тип фильтра, power/area/noise margin etc) с учетом используемой технологии, то вполне им вполне можно будет пользоваться для ускорения дизайна.


    Можно. Но только в узких рамках заранее заготовленных кирпичиков, увы. Точно так же как в графике можно строить на заранее заготовленных кирпичиках. Но если их не хватает — определять их самим. Покажи мне как в тексте определить свой, достаточно сложный кирпичик? Я уже 3-й пост подряд прошу показать пример на языке для аналоговых схем.


    FM>В графическом виде ты получишь:

    FM>1. Проблему, если поставщик схемы не имеет версии для твоего САПР-а

    Для того и существуют взаимные экспорты в разные популярные форматы.

    FM>2. Отсутствие diff


    Почти все форматы таки текстовые и даже вполне читабельные.

    FM>3. Отсутствие version control


    См. предыдущий пункт.

    FM>4. Сотни связей для сложного блока.


    Это от неумения готовить графику. Пример тут показывает это неумение: http://svenand.blogdrive.com/archive/16.html
    Вместо трех шин развели обычную грязь. Такая же грязь будет в коде.

    FM>5. Слабую интеоперабельность между различными тулзами (только не надо про edif )


    Это у тебя опять же от незнания. Давно устоялось относительно малое число стандартов файлов в этой области.


    FM>Повторюсь. Цифровая схемотехника очень быстро упёрлась в ограничение графического представления и в настоящий момент полностью перешла на текстовый формат.


    Боюсь, динамическую ячейку памяти в текстовом формате не спроектировать, это сугубо технологический трюк. Хотя, упомянуть заранее спроектированную ячейку затем из текста — запросто.


    FM>Аналоговый дизайн еще использует графическое представление, но активно исследует возможности ухода от него. У меня половина блоков имеют дополнительное описание на аналоговом варианте HDL под названием verilog-a (очень удобно для ускорения моделирования).


    Я таки не увидел для сравнения соответствующую аналоговую схему и текстовое описание, чтобы можно было всерьез сравнивать.
    Re[65]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 08.06.12 09:24
    Оценка:
    Здравствуйте, FragMent, Вы писали:

    FM>Для этого придется раздвинуть старые блоки, разместить новый символ, изменить соединения, если между старыми блоками еще остались связи, провести их мимо нового блока. В результате любая система version control не будет иметь смысла, поскольку за изменениями визуального представления не видно сути.


    Суть см. по нетлисту.

    N>>А что плохого в сотнях связей для сложного блока, если он действительно сложный?

    FM>1. Та же самая ситуация со вставкой нового блока. Раздвигаем старые блоки и случайно закорачиваем две из сотен связей. Очень легко упустить этот момент, особенно если у связей нету имен.

    Для этого надо двигать элементы из режима прокладки связей, что есть "сам себе злобный буратино". Иначе их закоротить никак. Ну и после трассировки выдаст ошибку, не боись.


    FM>2. Допустим есть глобальная связь, которая идет во множество блоков (например какой-нибудь clock). Нужно проверить все входы к которым эта связь подключена. В текстовом варианте, ты запускаешь поиск по файлам и легко видишь все вхождения. В графическом режиме ты подсвечиваешь нужную связь и обнаруживаешь, что она представляет собой ломанную линию с множеством ответвлений.


    А всего-то надо попросить вывести список всех пинов всех компонент, подключенных туда. Это многократно удобнее поиска по всем файлам.


    FM>Нужно просмотреть каждую ветку, заходя рекурсивно в каждый блок. Очень легко пропустить что-нибудь.


    Враки.

    N>>Они друг другу не противоречат.

    FM>Не противоречат, но по факту в современной цифровой схемотехнике используют vhdl, verilog, а не schematic capture.

    Это если цифровая схемотехника "сама в себе" и собрана из готовых кирпичиков (или вентилей). А если требуется эти кирпичики разрабатывать с 0-ля — то увы.

    FM>Все что я выше описывал — это поиск причин post factum. Как только появилась возможность синтезировать схемы из HDLs,

    FM>цифровики стройными рядами двинулись в этом направлении.

    Да пожайлуйста. Для цифровых подзадач вполне пойдет. Как когда-то процессоры заменили автоматику и вместо разработки автоматики стали писать программы на процессора на других языках. Только это не отменяет этапа разработки схемы даже на основе процессора со всей требуемой обвеской, когда процессор управляет некоим реальным блоком вместо автоматики. Все-равно конечную схемы на основе процессора без графики не представить, хоть тресни. Пусть даже в нем "унутре" сколь угодно сложная программа. Даже возьми материнки современных компов или любые платы раширения. Я периодически взглядываюьс в разводку и расположение и могу тебя заверить, что там ручками доводилось обязательно как первое, так и второе. Но в тексте это на сегодня невозможно ни в одном из тулзов. Получается, что де-факто компьютерные платы таки разрабатывают в графике? Просто ты работаешь в другом направлении.



    N>>Вопрос, наверно, больше в выборе оптимального для всех САПР стандарта описания? Каждое конкретное запихнуть в текст будет несложно.

    FM>Нет. Чуть выше в том посте я описал, что имею в виду (синтез аналоговых схем из формул и язык verilog-a (не путать c verilog) для моделирования
    FM>аналоговых блоков на более высоком уровне).

    С аналоговыми упираемся в отображение "формул" на конкретную схему. Слово "конкретное" — ключевое. А если я хочу сами схемы пробовать/варьировать?


    FM>А стандарт на графическое типа есть, я уже упоминал edif. Дважды пытался его использовать, первый раз обломался и перерисовал все руками (благо схема была небольшая).

    FM>Второй раз, при помощи питоновского скрипта и такой-то матери удалось худо-бедно перенести схему между САПРами. Но все равно пришлось еще пару тысяч элементов поправлять ручками.

    А что за САПР-ы были?

    FM>P.S. Я не противник графического представления. Более того, мне с графикой приходится работать больше, чем с текстом. Просто vdimas выбрал не очень удачный пример для демонстрации преимуществ графического dsl.


    Я выбрал из своего опыта. Как раз делал довольно много микропроцессорных плат и для радиосвязи и для самолетных блоков. Не вижу там даже близко сценария работы "text-only", т.к. микрпроцессор всегда чем-то управляет и от чего-то получает сигналы и полно всякой обвязки. И никто не показал пока в реальной жизни "text-only" кроме FPGA или аналогичных сугубо цифровых самодостаточных микросхем.

    Но даже расположи эти сугубо цифровые схемы на плате. Пусть автоматом. Зато мы потом берем и измеряем мощность*длину/ширину питающих соединений, полученных де-факто после размещения и разводки (даже если они автоматические). Уже кое-где требуется кондеры вставлять по питанию, а кое-где увеличивать их емкость. И вот уже появляются новые элементы в схеме или меняются номиналы имеющихся, что влечет за собой изменение их размеров и заход на новую итерацию размещения и разводки. В голом тексте это вообще никак не работает.
    Re[64]: Языки общего назначения не имеют смысла!
    От: FragMent  
    Дата: 09.06.12 09:15
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    V>Здравствуйте, FragMent, Вы писали:


    V>>>А взять сложную схему с многообразием технологий (а не только одну булевскую логику)... я с трудом представляю как разбираться в принципиальной схеме без графического представления. Ты банально не поймешь принцип работы схемы, если там кол-во элементов перевалит за единицы десятков. Если же я не прав, просьба привести примеры, где бы в тексте разнообразная электроника смотрелась бы лучше. (Может я и не прав и сильно отстал за последние годы, когда уже не занимаюсь этим).

    FM>>Ну вот посмотри скриншот схемы, сгенерированной из верилога. Слишком много связей и понять, что происходит, сложно. А ведь это еще не самый тяжелый случай.

    V>Ну вижу много связей. Вижу лишь слабость инструмента. Почему не произведено группрование связей по шинам? ТАм будет всего 2-3 шины (разрешение скриншота не позволяет сказать точно), и порядка десятка отдельных управляющих концов. полнейший примитив, если правильно представить в графике. Сложные схемы начинаются от полусотни цифровых и от несколькьких сотен аналоговых элементов и от десятков шин.

    А я вот вижу, что они уже сгруппированы по шинам (толстые линие на рисунке), а остальное отдельные связи.

    V>Кстати, а можно посмотреть на соответствующий этой схеме исходный код?

    Не знаю.
    Если интересно, сейчас есть бесплатные приложения для синтеза цифровых схем. Поставь, поиграйся, сравни работу на больших схемах (от десятков тысяч вентилей)

    V>>>Одна цифровая логика?

    FM>>Да, учитывая что цифра сейчас самый распространенный тип дизайна.

    V>Учитывая распространенность мобильных, обычных проводных сетевых технологий, встроенных жжидкокристаллических и т.д. — ты сильно заблуждаешься. Просто тебе из подвала не видно.

    Я восхищаюсь твоими телепатическими способностями! Особенно, если учитывать что в эти подвалы ты вообще не заглядывал.
    Давай спросим у экспертов http://www.electronicsweekly.com/blogs/david-manners-semiconductor-blog/2009/10/how-big-is-the-analoguemixed-s.html
    Как видишь они спорят составляет ли аналоговый и цифроаналоговый дизайн 16% или 34% от всего рынка. Причем сюда включаются и те цифровые схемы, в которых аналог служит чисто для вспомогательных целей (трансиверы-ресиверы).
    Видел оценку, что только 2% транзисторов "аналоговые", хотя, конечно, время разработки сравнимо.
    Можем еще сравнить по количеству вакансий.

    FM>>>>С аналоговым дизайном это пока не так. Хотя и там понемногу ситуация меняется. Появляются коммерческие решения, в которых аналоговые блоки описываются уравнениями, из которых генерируются нетлисты.


    V>>>Есть примеры достаточно сложных схем в текстовом виде с адаптивными фильтрами, умножителями (сигналов и частот), ФАПЧ и т.д.?

    FM>>Странно, что тебя нужно убеждать, что декларативное лучше императивного
    FM>>Из чего больше понятно, что происходит с сигналом?
    FM>>Из формулы или из схемы?

    V>Я бы взял чуть другую схему для бОльшей добротности, но не суть.

    Опять телепатия.

    FM>>И если будет нормальный инструмент позволяющий переводить формулы в схемы с гибкой настройкой конфигурации (тип фильтра, power/area/noise margin etc) с учетом используемой технологии, то вполне им вполне можно будет пользоваться для ускорения дизайна.


    V>Можно. Но только в узких рамках заранее заготовленных кирпичиков, увы. Точно так же как в графике можно строить на заранее заготовленных кирпичиках. Но если их не хватает — определять их самим. Покажи мне как в тексте определить свой, достаточно сложный кирпичик? Я уже 3-й пост подряд прошу показать пример на языке для аналоговых схем.

    Про кирпичики: количество конфигураций ограничено, например токовых зеркал я могу вспомнить около десятка, число дифкаскадов тоже невелико и т.д.
    Основная проблема не в самой конфигурации, а выборе нужной из design constraints и последующем выборе оптимальных размеров элементов. На это уходит основное время.
    Еще раз. Такие системы еще не слишком распространены, поэтому в открытом доступе инфы практически нет.
    Единственным поставщиком системы промышленного качества была Magma Design Automation. Вот здесь описание системы.
    Истории успеха
    Fujitsu
    Fraunhofer IIS
    Финал немного предсказуем: Magma DA приобретена Synopsys за полмиллиарда. Причем из непересекающихся продуктов у них фактически только FlexCells и FinSim.

    FM>>В графическом виде ты получишь:

    FM>>1. Проблему, если поставщик схемы не имеет версии для твоего САПР-а

    V>Для того и существуют взаимные экспорты в разные популярные форматы.

    Разумеется в таком случае тебе не составит труда взять какой-нибудь пример из LTSpice и сконвертировать его, скажем, в SIMetrix.

    FM>>2. Отсутствие diff


    V>Почти все форматы таки текстовые и даже вполне читабельные.

    Что же это за форматы?

    FM>>3. Отсутствие version control


    V>См. предыдущий пункт.

    Ага, в соседнем топике ты предлагал нетлисты таскать с собой. Самому не смешно? Хочешь сравнить

    FM>>4. Сотни связей для сложного блока.


    V>Это от неумения готовить графику. Пример тут показывает это неумение: http://svenand.blogdrive.com/archive/16.html

    V>Вместо трех шин развели обычную грязь. Такая же грязь будет в коде.
    Это машина генерировала. И качество отображение показывает какой приоритет данной функции у разрабочиков.

    FM>>5. Слабую интеоперабельность между различными тулзами (только не надо про edif )


    V>Это у тебя опять же от незнания. Давно устоялось относительно малое число стандартов файлов в этой области.

    Так назови же мне их.

    FM>>Повторюсь. Цифровая схемотехника очень быстро упёрлась в ограничение графического представления и в настоящий момент полностью перешла на текстовый формат.


    V>Боюсь, динамическую ячейку памяти в текстовом формате не спроектировать, это сугубо технологический трюк. Хотя, упомянуть заранее спроектированную ячейку затем из текста — запросто.

    И как это противоечит моим словам? А разработкой ячеек памяти, как, впрочем, и цифровых ячеек занимаются отдельные аналоговые специалисты,
    так называемые Standard Cell Library Design Engineers.

    FM>>Аналоговый дизайн еще использует графическое представление, но активно исследует возможности ухода от него. У меня половина блоков имеют дополнительное описание на аналоговом варианте HDL под названием verilog-a (очень удобно для ускорения моделирования).


    V>Я таки не увидел для сравнения соответствующую аналоговую схему и текстовое описание, чтобы можно было всерьез сравнивать.

    Пожалуйста (схему для соответствия можешь найти в любом учебнике, где описывается сигма-дельта ацп первого порядка)

    module firstorder_sigmadelta(in,clk,out);
     input in,clk;
     output out;
     voltage in,clk,out;
     parameter real quantizer_vth=0.0;
     parameter real clk_vth=2.5;
     parameter real d2a_gain=5.0;
    
     real vsum;
     real vd;
     real vint;
     real vout;
     real hi,lo;
    
     analog
     begin
       @(initial_step)
       begin
         vd=0;vint=0;vout=0;
         hi = 1; lo = -1;
       end
    
       @(cross(V(clk) - clk_vth,1))
       begin
    // summing junction
         vsum = V(in) - vd ;
    // integrator
         vint = vint + vsum;
    // quantizer
         if (vint > quantizer_vth) vout = hi ;
         else                      vout = lo ;
    // D to A
         vd = d2a_gain*vout ;
       end
       V(out) <+ vout ;
     end
    endmodule

    Еще раз этот код не для синтеза, а для ускорения моделирования.
    Я обычно делаю так: в процессе создания аналоговых блоков, одновременно пишу поведенческую модель, которую затем подставляю вместо реальной ячейки, когда мне не нужно точное функционирования данного блока.
    Re[65]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 09.06.12 10:25
    Оценка:
    Здравствуйте, FragMent, Вы писали:

    FM>Если интересно, сейчас есть бесплатные приложения для синтеза цифровых схем. Поставь, поиграйся, сравни работу на больших схемах (от десятков тысяч вентилей)


    Я вот этого аргумента не понимаю насчет десятка тыщ вентилей... Это точно всерьез аргумент не ради троллинга? По основанию 2 — это 11 уровней иерархии всего. А если взять нормальную декомпозицию по основанию несколько десятков, то получим всего лишь 4 уровня иерархии типовых "кирпичиков". Полнейшая ерунда.


    V>>>>Одна цифровая логика?

    FM>>>Да, учитывая что цифра сейчас самый распространенный тип дизайна.

    V>>Учитывая распространенность мобильных, обычных проводных сетевых технологий, встроенных жжидкокристаллических и т.д. — ты сильно заблуждаешься. Просто тебе из подвала не видно.

    FM>Я восхищаюсь твоими телепатическими способностями! Особенно, если учитывать что в эти подвалы ты вообще не заглядывал.
    FM>Давай спросим у экспертов [url=http://www.electronicsweekly.com/blogs/david-manners-semiconductor-blog/2009/10/how-big-is-the-analoguemixed-s.html
    FM>]http://www.electronicsweekly.com/blogs/david-manners-semiconductor-blog/2009/10/how-big-is-the-analoguemixed-s.html
    FM>[/url]
    FM>Как видишь они спорят составляет ли аналоговый и цифроаналоговый дизайн 16% или 34% от всего рынка.

    Если спор идет в ~2 раза, то таким спором можно подтереться, согласись... В любом случае, бери любую аппаратуру вокруг тебя: цифровая начинка во-многом "типовая", а аналоговый дизайн каждый раз уникальный. Опять же, что они тамсравнивают? Гибридные и аналоговые микросхемы с цифровыми? Когда я говорил о конечном изделии, включающем в т.ч. всю аналоговую обвеску? Боюсь, если сравнивать в деньгах, то конечное устройство стоит многократно больше стоимости примененных цифровых элементов. Даже взять микроволновку — там излучатель и обвеска к нему на порядок дороже управляющего микропроцессора. Даже такой факт — презиционный АЦП стоит сранимо с микропроцессором, который способен обрабатывать с той скоростью, с которой АЦП способен оцифровывать данные. Вот почему встраиваемые контроллеры с хорошим АЦП стоят относительно дорого — за счет своей гибридной части.

    Ну и опять же, учитывая относительно большую повторяемость цифровых компонент, то бишь относительно малое их разнообразие, оценивать объем дизайна по денежному обороту — это самое настоящее нубство. Например, на одних и тех же ядрах MIPS без переделок выпускают многие сотни (если не тысячи) номиналов якобы "железных" микросхем: видео/аудио/сетевых кодеков. А реально там один и тот же цифровой дизайн, где отличия идут в основном в гибридной части и в прошитом софте.


    FM>Причем сюда включаются и те цифровые схемы, в которых аналог служит чисто для вспомогательных целей (трансиверы-ресиверы).


    ИМХО, вот он взгляд из подвала. Это цифра идет как вспомогательная.


    FM>Видел оценку, что только 2% транзисторов "аналоговые", хотя, конечно, время разработки сравнимо.


    Напоминаю, что речь о разнообразии дизайнов, а не о кол-ве транзисторов. Цифровой транзистор проще многократно, к нему идут низкие требования относительно шумов и нагрузок... к тому же их в одних только центральных процессорах миллиарды... Но блин, если только в кеш-памяти сидит миллиард транзисторов, разве это означает миллиард уникальных дизайнов? Это размноженный один и тот же дизай. Это единица.

    FM>Можем еще сравнить по количеству вакансий.


    Смотря где искать вакансии. Мне постоянно приходят предложения, связанные с дизайном схем и конечных устройств.


    V>>Я бы взял чуть другую схему для бОльшей добротности, но не суть.

    FM>Опять телепатия.

    Чего-чего?
    Приведена не самая удачная композиция для фильтра 2-го порядка. Есть другая, где можно достичь бОльшей добротности.


    FM>>>И если будет нормальный инструмент позволяющий переводить формулы в схемы с гибкой настройкой конфигурации (тип фильтра, power/area/noise margin etc) с учетом используемой технологии, то вполне им вполне можно будет пользоваться для ускорения дизайна.


    V>>Можно. Но только в узких рамках заранее заготовленных кирпичиков, увы. Точно так же как в графике можно строить на заранее заготовленных кирпичиках. Но если их не хватает — определять их самим. Покажи мне как в тексте определить свой, достаточно сложный кирпичик? Я уже 3-й пост подряд прошу показать пример на языке для аналоговых схем.


    FM>Про кирпичики: количество конфигураций ограничено, например токовых зеркал я могу вспомнить около десятка, число дифкаскадов тоже невелико и т.д.


    Одних фильтров многие десятки, если не многие сотни. Не получится с формулой-то. Тем более, что отталкиваясь от формулы, мы отрезаем себе самую фишку аналогового дизайна — это "уровень полезности" каждого элемента. В хорошем аналоговом идзайне на активных элементах зачастую более одной ф-ии. Например, "образцовая" точка компрессора может служить дополнительно ФВЧ с нужной частотой среза. Формулой и кирпичиками это не выразить в общем случае, надо смотреть конкретный дизайн. Ну и я плохо себе представляю тектовую аннотацию к формуле, когда у нас выбор кирпичиков идет из сотен. Эта аннотация становится невыразительной, т.е. китайской грамотой. Уже захочется именно посмотреть на саму схему реализации. Т.е. опять придем к графическому отображению.


    FM>Основная проблема не в самой конфигурации, а выборе нужной из design constraints и последующем выборе оптимальных размеров элементов. На это уходит основное время.


    Это в простейших случаях так... Например, для подбора кондеров по питающим шинам.


    FM>Еще раз. Такие системы еще не слишком распространены, поэтому в открытом доступе инфы практически нет.


    Т.е. я таки прав относительно обобщенного дизайна? Я правильно понимаю приведенный тобой факт?


    FM>>>В графическом виде ты получишь:

    FM>>>1. Проблему, если поставщик схемы не имеет версии для твоего САПР-а

    V>>Для того и существуют взаимные экспорты в разные популярные форматы.

    FM>Разумеется в таком случае тебе не составит труда взять какой-нибудь пример из LTSpice и сконвертировать его, скажем, в SIMetrix.

    FM>>>2. Отсутствие diff


    V>>Почти все форматы таки текстовые и даже вполне читабельные.

    FM>Что же это за форматы?

    Ну мне приходилось переносить м/у 3-мя разными сапрами и я не видел проблем. Правда, в одном случае накатал за пол-дня конвертер сам, т.к. автоматом не умел. Но там текстовый формат таков, что как раз хорошо подходит для машинного чтения. Реально сложных форматов у САПР-ов из этой области я не видел. Покажи сложный формат, на котором у тебя случились те самые проблемы.


    V>>Вместо трех шин развели обычную грязь. Такая же грязь будет в коде.

    FM>Это машина генерировала. И качество отображение показывает какой приоритет данной функции у разрабочиков.

    Это показывает уровень разработчиков и ничего более. Если для 4-х компонент мы имеем такую грязь, то там разговаривать сразу не о чем.


    V>>Это у тебя опять же от незнания. Давно устоялось относительно малое число стандартов файлов в этой области.

    FM>Так назови же мне их.

    Форматы PCAD в свое время поддерживали почти все и до сих многие поддерживают.


    V>>Боюсь, динамическую ячейку памяти в текстовом формате не спроектировать, это сугубо технологический трюк. Хотя, упомянуть заранее спроектированную ячейку затем из текста — запросто.

    FM>И как это противоечит моим словам? А разработкой ячеек памяти, как, впрочем, и цифровых ячеек занимаются отдельные аналоговые специалисты,
    FM>так называемые Standard Cell Library Design Engineers.

    Ну так у этих специалистов должен быть какой-то инструмент? Или они по-старинке ручками рисуют? А если я сам хочу разработать такой кирпичик, что мне делать? Таки будет мне нужна графика или нет?


    V>>Я таки не увидел для сравнения соответствующую аналоговую схему и текстовое описание, чтобы можно было всерьез сравнивать.

    FM>Пожалуйста (схему для соответствия можешь найти в любом учебнике, где описывается сигма-дельта ацп первого порядка)

    (скипнул код)

    FM>Еще раз этот код не для синтеза, а для ускорения моделирования.


    Отличный пример, спасибо. Сравни теперь со схемой функциональной из 3-х квадратиков. ИМХО, приведенный код — китайская грамота в сравнении с наглядным представлением. По крайней мере, объяснить принцип этого способа АЦП новичку по исходному коду невозможно никак. В тексте отсутствует важный момент — наглядность одновременности происходящего.


    FM>Я обычно делаю так: в процессе создания аналоговых блоков, одновременно пишу поведенческую модель, которую затем подставляю вместо реальной ячейки, когда мне не нужно точное функционирования данного блока.


    А Симулинк не пробовал?
    Re[66]: Языки общего назначения не имеют смысла!
    От: FragMent  
    Дата: 09.06.12 11:11
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    V>Здравствуйте, FragMent, Вы писали:


    FM>>Для этого придется раздвинуть старые блоки, разместить новый символ, изменить соединения, если между старыми блоками еще остались связи, провести их мимо нового блока. В результате любая система version control не будет иметь смысла, поскольку за изменениями визуального представления не видно сути.


    V>Суть см. по нетлисту.

    А зачем? Если суть можно смотреть по тексту на VHDL?

    N>>>А что плохого в сотнях связей для сложного блока, если он действительно сложный?

    FM>>1. Та же самая ситуация со вставкой нового блока. Раздвигаем старые блоки и случайно закорачиваем две из сотен связей. Очень легко упустить этот момент, особенно если у связей нету имен.

    V>Для этого надо двигать элементы из режима прокладки связей, что есть "сам себе злобный буратино". Иначе их закоротить никак. Ну и после трассировки выдаст ошибку, не боись.

    Ой, ну тогда ручками будешь перерисовывать сотни связей. Кстати, что это у тебя за трассировка такая умная, что знает что у тебя net0078 не должна быть закорочена с net0126?

    FM>>2. Допустим есть глобальная связь, которая идет во множество блоков (например какой-нибудь clock). Нужно проверить все входы к которым эта связь подключена. В текстовом варианте, ты запускаешь поиск по файлам и легко видишь все вхождения. В графическом режиме ты подсвечиваешь нужную связь и обнаруживаешь, что она представляет собой ломанную линию с множеством ответвлений.


    V>А всего-то надо попросить вывести список всех пинов всех компонент, подключенных туда. Это многократно удобнее поиска по всем файлам.

    Пожалуйста, назови хотя бы три САПРа, поддерживающих такую функциональность.

    FM>>Нужно просмотреть каждую ветку, заходя рекурсивно в каждый блок. Очень легко пропустить что-нибудь.


    V>Враки.

    Это следует понимать как "Я, vdimas, создал N схем с более чем 10К элементов и ни разу не сталкивался с такой проблемой" или "я -- болтун-теоретик не воспринимающий факты, которые противоречат моему мнению"?

    N>>>Они друг другу не противоречат.

    FM>>Не противоречат, но по факту в современной цифровой схемотехнике используют vhdl, verilog, а не schematic capture.

    V>Это если цифровая схемотехника "сама в себе" и собрана из готовых кирпичиков (или вентилей). А если требуется эти кирпичики разрабатывать с 0-ля — то увы.

    Жаль тебя разочаровывать, но эти цифровые кирпичики разрабатываются даже в случае схемотехнического ввода схемы.

    Еще одну причину вспомнил. В нормальной цифровой схеме обычно применяется Boundary scan testing. Представляешь как весело руками последовательно соединить все ячейки?
    И работа с нетлистом тебе в этом случае особо не поможет, потому что в нетлисте нет информации о взаимном расположении ячеек и можешь получить лишние проводники из одного края кристалла на другой. В то же время синтезатор знает какой регистр за каким следует и может, при необходимости, перекоммутировать BS связи.
    А представляешь какую визуальную грязь добавит эта дополнительная куча связей, идущая сквозь все ячейки по иерархии?

    FM>>Все что я выше описывал — это поиск причин post factum. Как только появилась возможность синтезировать схемы из HDLs,

    FM>>цифровики стройными рядами двинулись в этом направлении.

    V>Да пожайлуйста. Для цифровых подзадач вполне пойдет. Как когда-то процессоры заменили автоматику и вместо разработки автоматики стали писать программы на процессора на других языках. Только это не отменяет этапа разработки схемы даже на основе процессора со всей требуемой обвеской, когда процессор управляет некоим реальным блоком вместо автоматики. Все-равно конечную схемы на основе процессора без графики не представить, хоть тресни. Пусть даже в нем "унутре" сколь угодно сложная программа. Даже возьми материнки современных компов или любые платы раширения. Я периодически взглядываюьс в разводку и расположение и могу тебя заверить, что там ручками доводилось обязательно как первое, так и второе. Но в тексте это на сегодня невозможно ни в одном из тулзов. Получается, что де-факто компьютерные платы таки разрабатывают в графике? Просто ты работаешь в другом направлении.

    Итак, ты согласился, что для цифровых подзадач текст подходит. А, учитывая полную победу цифровых HDLs над schematic entry, текст подходит для них лучше графики.
    В этом то и суть. Ни ты (со стороны board level engineers), ни я (со стороны analog IC designers) не можем утверждать, что графика по удобству превосходит текст, поскольку мы просто не имеем дело со схемами таких масштабов. Цифровые инженеры первыми столкнулись с дизайнами в сотни тысяч и миллионы элементов и деньгами проголосовали за текст.

    N>>>Вопрос, наверно, больше в выборе оптимального для всех САПР стандарта описания? Каждое конкретное запихнуть в текст будет несложно.

    FM>>Нет. Чуть выше в том посте я описал, что имею в виду (синтез аналоговых схем из формул и язык verilog-a (не путать c verilog) для моделирования
    FM>>аналоговых блоков на более высоком уровне).

    V>С аналоговыми упираемся в отображение "формул" на конкретную схему. Слово "конкретное" — ключевое. А если я хочу сами схемы пробовать/варьировать?

    Да кто тебе мешает? Имеешь нетлист, перерисовываешь его руками и меняй сколько хочешь.

    FM>>А стандарт на графическое типа есть, я уже упоминал edif. Дважды пытался его использовать, первый раз обломался и перерисовал все руками (благо схема была небольшая).

    FM>>Второй раз, при помощи питоновского скрипта и такой-то матери удалось худо-бедно перенести схему между САПРами. Но все равно пришлось еще пару тысяч элементов поправлять ручками.

    V>А что за САПР-ы были?

    Cadence Composer -> Mentor Graphics DesignArchitect
    Mentor Graphics DXDesigner -> Cadence Composer

    FM>>P.S. Я не противник графического представления. Более того, мне с графикой приходится работать больше, чем с текстом. Просто vdimas выбрал не очень удачный пример для демонстрации преимуществ графического dsl.


    V>Я выбрал из своего опыта. Как раз делал довольно много микропроцессорных плат и для радиосвязи и для самолетных блоков. Не вижу там даже близко сценария работы "text-only", т.к. микрпроцессор всегда чем-то управляет и от чего-то получает сигналы и полно всякой обвязки. И никто не показал пока в реальной жизни "text-only" кроме FPGA или аналогичных сугубо цифровых самодостаточных микросхем.


    V>Но даже расположи эти сугубо цифровые схемы на плате. Пусть автоматом. Зато мы потом берем и измеряем мощность*длину/ширину питающих соединений, полученных де-факто после размещения и разводки (даже если они автоматические). Уже кое-где требуется кондеры вставлять по питанию, а кое-где увеличивать их емкость. И вот уже появляются новые элементы в схеме или меняются номиналы имеющихся, что влечет за собой изменение их размеров и заход на новую итерацию размещения и разводки. В голом тексте это вообще никак не работает.

    Еще раз. Когда у тебя окажется сотня тысяч связей, то руками ты физически не сможешь модифицировать все сложные места за приемлемое время. Ты просто синтезируешь схему (например при помощи IC compiler), экстрагируешь паразитные параметры (StarRC) и моделируешь схему с их учетом (PrimeTime для проверки целостности сигналов и проблем с мощностью). Если есть проблемы с какими-то связями, то возвращаешься к IC Compiler и вписываешь дополнительные ограничения в скрипт для синтеза (например команда set_clock_latency, set_clock_transition для установки правильного тайминга сигналов генератора)
    Re[66]: Языки общего назначения не имеют смысла!
    От: FragMent  
    Дата: 09.06.12 12:58
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    V>Здравствуйте, FragMent, Вы писали:


    FM>>Если интересно, сейчас есть бесплатные приложения для синтеза цифровых схем. Поставь, поиграйся, сравни работу на больших схемах (от десятков тысяч вентилей)


    V>Я вот этого аргумента не понимаю насчет десятка тыщ вентилей... Это точно всерьез аргумент не ради троллинга? По основанию 2 — это 11 уровней иерархии всего. А если взять нормальную декомпозицию по основанию несколько десятков, то получим всего лишь 4 уровня иерархии типовых "кирпичиков". Полнейшая ерунда.

    Обычный эффект масштаба. Тебя не смущает, что СУБД для хранения 100Мб данных и 1 Тб данных, скорее всего потребуются разные.

    V>>>>>Одна цифровая логика?

    FM>>>>Да, учитывая что цифра сейчас самый распространенный тип дизайна.

    FM>>Как видишь они спорят составляет ли аналоговый и цифроаналоговый дизайн 16% или 34% от всего рынка.


    V>Если спор идет в ~2 раза, то таким спором можно подтереться, согласись...

    Не соглашусь. Тут вопрос только в определении.
    Вот есть микроконроллер, у которого схема тактирования работает от внешнего кварца (маленький аналоговый блочок в десяток транзисторов), он какой? Цифровой или цифроаналоговый? Скорее всего цифровой.
    А если мы добавим внутрь микроконтроллера PLL как черный ящик, он превратиться в цифро-аналоговую схему? На мой взгляд — нет, но кто-то может думать иначе.

    V>В любом случае, бери любую аппаратуру вокруг тебя: цифровая начинка во-многом "типовая", а аналоговый дизайн каждый раз уникальный. Опять же, что они тамсравнивают? Гибридные и аналоговые микросхемы с цифровыми? Когда я говорил о конечном изделии, включающем в т.ч. всю аналоговую обвеску? Боюсь, если сравнивать в деньгах, то конечное устройство стоит многократно больше стоимости примененных цифровых элементов. Даже взять микроволновку — там излучатель и обвеска к нему на порядок дороже управляющего микропроцессора. Даже такой факт — презиционный АЦП стоит сранимо с микропроцессором, который способен обрабатывать с той скоростью, с которой АЦП способен оцифровывать данные. Вот почему встраиваемые контроллеры с хорошим АЦП стоят относительно дорого — за счет своей гибридной части.


    Мне это говорит о том, что стоимость аналоговых схем выше за счет более сложного техпроцесса, более низкого выхода годных, и маркетинговых соображений.
    А также, что производительность цифровых дизайнеров выше, чем аналоговых.
    Кстати, здесь написано, что производительность дизайнера на уровне схемы 100-200 гейтов в неделю, а на уровне HDL — 1-2 килогейта.

    V>Ну и опять же, учитывая относительно большую повторяемость цифровых компонент, то бишь относительно малое их разнообразие, оценивать объем дизайна по денежному обороту — это самое настоящее нубство. Например, на одних и тех же ядрах MIPS без переделок выпускают многие сотни (если не тысячи) номиналов якобы "железных" микросхем: видео/аудио/сетевых кодеков. А реально там один и тот же цифровой дизайн, где отличия идут в основном в гибридной части и в прошитом софте.

    Да, да. Просто вставить ядро процессора и никаких проблем. А цифровую обвязку для него и аналоговой части писать не надо?

    FM>>Причем сюда включаются и те цифровые схемы, в которых аналог служит чисто для вспомогательных целей (трансиверы-ресиверы).


    V>ИМХО, вот он взгляд из подвала. Это цифра идет как вспомогательная.

    Значит если между процессором и видеокартой связь осуществляется через аналоговые трансиверы-ресиверы, то цифра в процессоре стала вспомогательной?

    FM>>Можем еще сравнить по количеству вакансий.


    V>Смотря где искать вакансии. Мне постоянно приходят предложения, связанные с дизайном схем и конечных устройств.

    Там где ищут одновременно аналоговых и цифровых спецов.
    Например сегодня на http://www.ic-resources.com/ Digital IC 233 вакансии, analog/rf IC 112 вакансий.
    Зачем столько цифровиков, если можно просто вставить MIPS ядро?

    V>>>Я бы взял чуть другую схему для бОльшей добротности, но не суть.

    FM>>Опять телепатия.

    V>Чего-чего?

    V>Приведена не самая удачная композиция для фильтра 2-го порядка. Есть другая, где можно достичь бОльшей добротности.
    Всего лишь первая попавшаяся картинка фильтра, поэтому пытаться что-либо получить из нее имхо есть телепатия.

    FM>>>>И если будет нормальный инструмент позволяющий переводить формулы в схемы с гибкой настройкой конфигурации (тип фильтра, power/area/noise margin etc) с учетом используемой технологии, то вполне им вполне можно будет пользоваться для ускорения дизайна.


    V>>>Можно. Но только в узких рамках заранее заготовленных кирпичиков, увы. Точно так же как в графике можно строить на заранее заготовленных кирпичиках. Но если их не хватает — определять их самим. Покажи мне как в тексте определить свой, достаточно сложный кирпичик? Я уже 3-й пост подряд прошу показать пример на языке для аналоговых схем.


    FM>>Про кирпичики: количество конфигураций ограничено, например токовых зеркал я могу вспомнить около десятка, число дифкаскадов тоже невелико и т.д.


    V>Одних фильтров многие десятки, если не многие сотни. Не получится с формулой-то. Тем более, что отталкиваясь от формулы, мы отрезаем себе самую фишку аналогового дизайна — это "уровень полезности" каждого элемента. В хорошем аналоговом идзайне на активных элементах зачастую более одной ф-ии. Например, "образцовая" точка компрессора может служить дополнительно ФВЧ с нужной частотой среза. Формулой и кирпичиками это не выразить в общем случае, надо смотреть конкретный дизайн. Ну и я плохо себе представляю тектовую аннотацию к формуле, когда у нас выбор кирпичиков идет из сотен. Эта аннотация становится невыразительной, т.е. китайской грамотой. Уже захочется именно посмотреть на саму схему реализации. Т.е. опять придем к графическому отображению.

    Вот ты используешь в своем фильтре операционый усилитель. Ты как его описываешь? В виде полной электрической схемы или используешь как черный ящик модель, предоставляемую изготовителем? А теперь представь себе, что ты описываешь нужные тебе характеристки ОУ в виде текста, а программа автоматически находит подходящий компонент либо генерит свой собственный. Неужели это не ускорит разработку?
    И не всегда нужны такие навороченные фильтры, иначе бы не существовало кучи генераторов фильтров.
    Ты, почему-то, занимаешь экстремальную позицию, или текст или графика. Ради бога, никто не мешает в нужных местах спуститься на уровень ниже и немного подшаманить.

    FM>>Основная проблема не в самой конфигурации, а выборе нужной из design constraints и последующем выборе оптимальных размеров элементов. На это уходит основное время.


    V>Это в простейших случаях так... Например, для подбора кондеров по питающим шинам.

    Это для печатных плат. А для чипов, если у тебя операционник из десятка транзисторов, то ты должен выбрать правильный размер (длина, ширина) каждого из них, исходя из взаимосвязанных критериев: Noise, Linearity, Gain, Supply Voltage, Voltage Swing, Speed, Input/Output Impedance, Power Dissipation

    FM>>Еще раз. Такие системы еще не слишком распространены, поэтому в открытом доступе инфы практически нет.


    V>Т.е. я таки прав относительно обобщенного дизайна? Я правильно понимаю приведенный тобой факт?

    Очередной раз повторяю
    "C аналоговым дизайном это пока не так. Хотя и там понемногу ситуация меняется. Появляются коммерческие решения, в которых аналоговые блоки описываются уравнениями, из которых генерируются нетлисты."
    Что может быть непонятного? Да, в аналоге используются схемы. При этом с точки зрения количества элементов аналог с сотни раз проще цифры.
    Считать при этом, что из-за простоты составляющих элементов, цифровой дизайн проще, чем аналоговый, это такая же глупость, как считать
    что программа в 1000 строк на ассемблере сложнее 100К строк на C++.

    FM>>>>В графическом виде ты получишь:

    FM>>>>1. Проблему, если поставщик схемы не имеет версии для твоего САПР-а

    V>>>Для того и существуют взаимные экспорты в разные популярные форматы.

    FM>>Разумеется в таком случае тебе не составит труда взять какой-нибудь пример из LTSpice и сконвертировать его, скажем, в SIMetrix.

    FM>>>>2. Отсутствие diff


    V>>>Почти все форматы таки текстовые и даже вполне читабельные.

    FM>>Что же это за форматы?

    V>Ну мне приходилось переносить м/у 3-мя разными сапрами и я не видел проблем. Правда, в одном случае накатал за пол-дня конвертер сам, т.к. автоматом не умел. Но там текстовый формат таков, что как раз хорошо подходит для машинного чтения. Реально сложных форматов у САПР-ов из этой области я не видел. Покажи сложный формат, на котором у тебя случились те самые проблемы.


    V>>>Это у тебя опять же от незнания. Давно устоялось относительно малое число стандартов файлов в этой области.

    FM>>Так назови же мне их.
    V>Форматы PCAD в свое время поддерживали почти все и до сих многие поддерживают.
    Это стандарт? Вот openAcces более менее можно назвать стандартом (сюрпрайз — формат бинарный).
    edif можно назвать стандартом.

    V>>>Боюсь, динамическую ячейку памяти в текстовом формате не спроектировать, это сугубо технологический трюк. Хотя, упомянуть заранее спроектированную ячейку затем из текста — запросто.

    FM>>И как это противоечит моим словам? А разработкой ячеек памяти, как, впрочем, и цифровых ячеек занимаются отдельные аналоговые специалисты,
    FM>>так называемые Standard Cell Library Design Engineers.

    V>Ну так у этих специалистов должен быть какой-то инструмент? Или они по-старинке ручками рисуют? А если я сам хочу разработать такой кирпичик, что мне делать? Таки будет мне нужна графика или нет?

    Да, нарисовали схему, сделали нетлист, и началась основная работа. Написание скриптов для corner analysis, для monte-carlo simulation, скриптов для обработки результатов симуляции, написания правил drc, lvs, erc, синтеза.

    V>(скипнул код)


    FM>>Еще раз этот код не для синтеза, а для ускорения моделирования.


    V>Отличный пример, спасибо. Сравни теперь со схемой функциональной из 3-х квадратиков. ИМХО, приведенный код — китайская грамота в сравнении с наглядным представлением. По крайней мере, объяснить принцип этого способа АЦП новичку по исходному коду невозможно никак. В тексте отсутствует важный момент — наглядность одновременности происходящего.

    Прости, зачем мне наглядность для данного случая? Я не буду использовать ее чтобы объяснять новичку. Мне нужно чтобы оно моделировалось не сутки, а хотя бы часов 6.
    Твоя схема из трех квадратиков может состоять из таких же блоков написанных на verilog-a.
    FM>>Я обычно делаю так: в процессе создания аналоговых блоков, одновременно пишу поведенческую модель, которую затем подставляю вместо реальной ячейки, когда мне не нужно точное функционирования данного блока.

    V>А Симулинк не пробовал?

    Нет, потому что мне нужно одновременно использовать блоки из реальных элементов. Симулинк получил возможность совместного моделирования с моим симулятором не очень давно.
    Re[67]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 09.06.12 23:38
    Оценка:
    Здравствуйте, FragMent, Вы писали:

    V>>Я вот этого аргумента не понимаю насчет десятка тыщ вентилей... Это точно всерьез аргумент не ради троллинга? По основанию 2 — это 11 уровней иерархии всего. А если взять нормальную декомпозицию по основанию несколько десятков, то получим всего лишь 4 уровня иерархии типовых "кирпичиков". Полнейшая ерунда.

    FM>Обычный эффект масштаба. Тебя не смущает, что СУБД для хранения 100Мб данных и 1 Тб данных, скорее всего потребуются разные.

    Признаюсь, я не понял сути возражения... если это было возражение, конечно...


    FM>Вот есть микроконроллер, у которого схема тактирования работает от внешнего кварца (маленький аналоговый блочок в десяток транзисторов), он какой? Цифровой или цифроаналоговый? Скорее всего цифровой.


    Ес-но цифро-аналоговый прямо по-определению. К тому же, а порты вводы/вывода прямо таки цифровые у всего девайса в целом? Да фактически никогда. Т.е. еще будет согласование и преобразование. Итого, в типовой схеме из полусотни элементов цифровым будет только один элемент — микроконтроллер... Который, повторюсь, типовой, а схема на нем — уникальна.


    FM>А если мы добавим внутрь микроконтроллера PLL как черный ящик, он превратиться в цифро-аналоговую схему? На мой взгляд — нет, но кто-то может думать иначе.


    Я думаю, что цифровых дизайнов относительно немного. Относительно всех дизайнов. Практически ВСЕГДА одни и те же цифровые компоненты используются более чем в одной конечной схеме. И коэффициент тут несколько порядков обычно, от 3-х и более. Т.е. на одну цифровую микросхему рано или поздно наберется тысячи схем, где ее применяют со всевозможной аналоговой обвеской. Мне вообще кажутся смешными эти споры, каких дизайнов больше. Похоже, кое-кто кое-что не догоняет. Высокоинтегрированная цифра от того и стала популярна, что она инкапсулирует в себе некое типовое решение. Ведь высокоинтегрированные микросхемы окупаются только в приличных партиях. Поэтому, если где-то цифра уникальна — это заведомая профанация всей идеи. Всякие уникальности должен обыгрывать софт.

    Ну я конечно всерьез не рассматриваю FPGA. Эта штука изначально предназначалась для прототипирования. Делать на ней конечные решения — это получать то самое "решение для бедных". И скорости не те и шум и потребление и вообще...

    FM>Мне это говорит о том, что стоимость аналоговых схем выше за счет более сложного техпроцесса, более низкого выхода годных, и маркетинговых соображений.


    Нет, просто меньшая масштабируемость. Вот выпустили партию печатных плат под материнки из 10000 шт и всё. А выпуск цифровых микросхем идет на миллионы. Поэтому в большинстве конечных потребительских схем сидит приличная доля стоимости разработки. Да и сложнее эти схемы, чем цифровые. Слишком много подробностей технологии нужно учитывать в дизайне. Сравни с голой булевской логикой, где ничего не надо учитывать, кроме задержек.


    FM>А также, что производительность цифровых дизайнеров выше, чем аналоговых.


    Потому что специализация Уже, а работа однообразнее. Производительность веб-мастеров тоже выше производительности С++ программистов, если в тиках процессора считать по готовой программе...
    Потому что меньше болит голова о технологической стороне продукта. Знай себе в песочнице ковыряй.


    FM>Кстати, здесь написано, что производительность дизайнера на уровне схемы 100-200 гейтов в неделю, а на уровне HDL — 1-2 килогейта.


    Когда тебе порты выхода с реальными исполнительными устройствами сопрягать надо будет, не поможет тебе никакой HDL. Будут те же 100-200 компонент в неделю.


    V>>Ну и опять же, учитывая относительно большую повторяемость цифровых компонент, то бишь относительно малое их разнообразие, оценивать объем дизайна по денежному обороту — это самое настоящее нубство. Например, на одних и тех же ядрах MIPS без переделок выпускают многие сотни (если не тысячи) номиналов якобы "железных" микросхем: видео/аудио/сетевых кодеков. А реально там один и тот же цифровой дизайн, где отличия идут в основном в гибридной части и в прошитом софте.

    FM>Да, да. Просто вставить ядро процессора и никаких проблем. А цифровую обвязку для него и аналоговой части писать не надо?

    Дык и я про то, что меняется существенно только гибридная часть, которую на HDL писать не эффективно до сих пор.


    V>>ИМХО, вот он взгляд из подвала. Это цифра идет как вспомогательная.

    FM>Значит если между процессором и видеокартой связь осуществляется через аналоговые трансиверы-ресиверы, то цифра в процессоре стала вспомогательной?

    Да, цифра изначально и задумывалась как вспомогательный инструмент, апроксимирующий требуемые аналоговые сигналы, что не так?
    По мере своего удешевления цифра заменяет аналог. Решение-то в цифре сложнее, ес-но, но при этом все дешевле и дешевле, именно из-за той самой однородности дизайна и гибкости через софт или микропрограммы (таблицы истинности ф-ий переходов автоматов, вшитые в ПЗУ).



    FM>>>Можем еще сравнить по количеству вакансий.


    V>>Смотря где искать вакансии. Мне постоянно приходят предложения, связанные с дизайном схем и конечных устройств.

    FM>Там где ищут одновременно аналоговых и цифровых спецов.
    FM>Например сегодня на http://www.ic-resources.com/ Digital IC 233 вакансии, analog/rf IC 112 вакансий.
    FM>Зачем столько цифровиков, если можно просто вставить MIPS ядро?

    Цифровой дизайн сложнее гораздо. Для эмуляции простого бивадратного аналогового фильтра на 15 элементах надо десятки тысяч вентилей для умножителей, сумматора, ПЗУ микропрограммы, ЦАП/АЦП.

    И вообще, ты не туда смотришь. Надо смотреть на вакансии разработчиков конечных схем и интересоваться, чем они занимаются. Я работал по цифровой "половине" дизайна, но почему-то минимум половину трудозатрат шло на разработку сопряжений с аналоговой частью, в т.ч. через софт. Думаю, ты не верно представляешь себе занятость цифровика в процессе разработки конечных устройств.

    V>>>>Я бы взял чуть другую схему для бОльшей добротности, но не суть.

    FM>>>Опять телепатия.

    V>>Чего-чего?

    V>>Приведена не самая удачная композиция для фильтра 2-го порядка. Есть другая, где можно достичь бОльшей добротности.
    FM>Всего лишь первая попавшаяся картинка фильтра, поэтому пытаться что-либо получить из нее имхо есть телепатия.

    Э нет, коль в исходной формуле участвует добротность и шла речь об отображении формулы на схему, а не наоборот, то пример был неудачен. Читать предыдущее предложение до просветления.

    Задача отображения схему на формулу и формулы на схему — они ой какие разные.


    FM>>>Про кирпичики: количество конфигураций ограничено, например токовых зеркал я могу вспомнить около десятка, число дифкаскадов тоже невелико и т.д.


    V>>Одних фильтров многие десятки, если не многие сотни. Не получится с формулой-то. Тем более, что отталкиваясь от формулы, мы отрезаем себе самую фишку аналогового дизайна — это "уровень полезности" каждого элемента. В хорошем аналоговом идзайне на активных элементах зачастую более одной ф-ии. Например, "образцовая" точка компрессора может служить дополнительно ФВЧ с нужной частотой среза. Формулой и кирпичиками это не выразить в общем случае, надо смотреть конкретный дизайн. Ну и я плохо себе представляю тектовую аннотацию к формуле, когда у нас выбор кирпичиков идет из сотен. Эта аннотация становится невыразительной, т.е. китайской грамотой. Уже захочется именно посмотреть на саму схему реализации. Т.е. опять придем к графическому отображению.

    FM>Вот ты используешь в своем фильтре операционый усилитель. Ты как его описываешь? В виде полной электрической схемы или используешь как черный ящик модель, предоставляемую изготовителем? А теперь представь себе, что ты описываешь нужные тебе характеристки ОУ в виде текста, а программа автоматически находит подходящий компонент либо генерит свой собственный. Неужели это не ускорит разработку?

    Дык, а в чем тогда профит текста, если я и так в графике могу нарисовать в виде черного ящика любой, сколь угодно сложный элемент.

    Ты же ведь манипулирующие высказывания приводил (из разряда рекламных, очевидно), что вот мол в графике 200 гейтов в неделю. Реально будет 200 компонент, а не гейтов. А при правильно выбранной декомпозии/иерархии счет гейтов может пойти на миллионы, а не на тысячи. Просто работать в графике надо уметь. Без ложной скромности скажу так, что очень и очень немногие люди обладают умением проектировать конечные схемы хотя бы близко к потребительскому качеству. Или те самые упомянутые "трюки", типа ячейки динамической памяти на обычном транзисторе с висящим эмиттером. Т.е. полноценно проектировать и в графике в т.ч. (а реальное проектирование любых технологических вещей идет только в графике), в общем, работать с этим с нужной отдачей могут очень немногие. Сие факт, наблюдаемый мною много лет. Зато с текстом работать может любой, кому под силу освоить язык хотя бы уровня BASIC. ИМХО, причины распространенности текста ровно такие же, почему убогая Джава стала мейнстримом. В ограниченности сила, бо меньше поле для ошибок.


    FM>И не всегда нужны такие навороченные фильтры, иначе бы не существовало кучи генераторов фильтров.


    Если бы не нужны, то генераторов было бы немного, не находишь? Да и генераторы-то по большей части для цифровых фильтров.
    "Навороченные фильтры", как ты говоришь, они от экономии. Например, некоторые структуры биквадратных могут работать как ФНЧ, ФВЧ, ПФ, РФ. Всё в одном. Ну и при распознавании сигналов действительно сначала аппроксимируют передаточную ф-ию, а потом подбирают структуру фильтра, чтобы эта ф-ия была заведомо реализуемой. Цифра-то на сегодня все еще способна обслужить лишь низкочастотный диапазон, се ля ви. Остальное как и прежде. Поломай как-нить сотовый да распили ему экранирующие запаянные коробки в радиочасти, полюбуйся.


    FM>Ты, почему-то, занимаешь экстремальную позицию, или текст или графика. Ради бога, никто не мешает в нужных местах спуститься на уровень ниже и немного подшаманить.


    Я? Боже упаси. Если читал сначала, то наоборот. Я говорил, что максимальная отдача от обоих. Более того, высказывал такую мысль, что многую рутину удобнее бывает набить в тексте, но просматривать результат таки в графике. Как всем понятный пример приводил ход работы веб-дизайнера. Пишет он HTML-код, но смотрит затем на графическое представление страницы. Что есть "графическое" я пытался дать определение здесь: http://www.rsdn.ru/forum/philosophy/4755042.1.aspx
    Автор: vdimas
    Дата: 28.05.12


    V>>Это в простейших случаях так... Например, для подбора кондеров по питающим шинам.

    FM>Это для печатных плат. А для чипов, если у тебя операционник из десятка транзисторов, то ты должен выбрать правильный размер (длина, ширина) каждого из них, исходя из взаимосвязанных критериев: Noise, Linearity, Gain, Supply Voltage, Voltage Swing, Speed, Input/Output Impedance, Power Dissipation

    И че? Все эти тулзы автоматом никак?


    FM>>>Еще раз. Такие системы еще не слишком распространены, поэтому в открытом доступе инфы практически нет.


    V>>Т.е. я таки прав относительно обобщенного дизайна? Я правильно понимаю приведенный тобой факт?

    FM>Очередной раз повторяю
    FM>"C аналоговым дизайном это пока не так. Хотя и там понемногу ситуация меняется. Появляются коммерческие решения, в которых аналоговые блоки описываются уравнениями, из которых генерируются нетлисты."
    FM>Что может быть непонятного? Да, в аналоге используются схемы. При этом с точки зрения количества элементов аналог с сотни раз проще цифры.

    С т.з. кол-ва элементов да. А т.з. характеристик происходящих процессов — гораздо сложнее. Ну и про кол-во уникальных дизайнов замечание делал многократно.


    FM>Считать при этом, что из-за простоты составляющих элементов, цифровой дизайн проще, чем аналоговый, это такая же глупость, как считать

    FM>что программа в 1000 строк на ассемблере сложнее 100К строк на C++.

    Сложность обычно оценивается в трудоемкости помноженной на требуемую квалификацию. Да, я считаю, что "голый" цифровой дизайн относительно несложный. Не сложнее программирования на Джава или VB. Собственно, уже все процессы и наработки из управления разработкой в ПО перешли в отрасль цифрового дизайна. Потому что характеры работ близки.

    V>>Форматы PCAD в свое время поддерживали почти все и до сих многие поддерживают.

    FM>Это стандарт?

    Да. Все популярные тулзы для проектирования схем и печатных плат умели экспортировать/импортировать его форматы файлов.
    Кстати, с первых страниц гугля нашел насчет DIFF файлов от P-CAD:
    http://billauer.co.il/blog/2010/07/net-pcad-netlist-files-perl/

    Обрати внимание на смешной размер снипетта кода, полностью решающего проблему.


    FM>Вот openAcces более менее можно назвать стандартом (сюрпрайз — формат бинарный).


    На мой взгляд бинарные форматы парсить несоизмеримо легче текстовых. Во-первых они более детерминированы, во-вторых, меньше требуется преобразований числовых значений. А если еще разработчики формата, не будь дураки, описали его спецификацию через ASN.1 — вообще сказка. Само будет парсится... Или таки дураки?


    FM>edif можно назвать стандартом.


    Посмотрел... Улыбнулся. Смотрел PDIF? Та же хрень, только в профиль. И так же банально парсится.
    И вообще: http://www.gigatest.net/ifr/new/fabmaster


    V>>>>Боюсь, динамическую ячейку памяти в текстовом формате не спроектировать, это сугубо технологический трюк. Хотя, упомянуть заранее спроектированную ячейку затем из текста — запросто.

    FM>>>И как это противоечит моим словам? А разработкой ячеек памяти, как, впрочем, и цифровых ячеек занимаются отдельные аналоговые специалисты,
    FM>>>так называемые Standard Cell Library Design Engineers.

    V>>Ну так у этих специалистов должен быть какой-то инструмент? Или они по-старинке ручками рисуют? А если я сам хочу разработать такой кирпичик, что мне делать? Таки будет мне нужна графика или нет?

    FM>Да, нарисовали схему, сделали нетлист, и началась основная работа.

    Основная работа — это разработка работющей схемы. Остальное — это лишь ее расчеты и доводка. Во многом автоматизированная и не творческая стадия... которую женщины, по моим наблюдениям, делают лучше мужчин.


    V>>А Симулинк не пробовал?

    FM>Нет, потому что мне нужно одновременно использовать блоки из реальных элементов.

    А какие проблемы импортировать туда VHDL/verilog?
    Re[67]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 10.06.12 08:58
    Оценка:
    Здравствуйте, FragMent, Вы писали:

    V>>Суть см. по нетлисту.

    FM>А зачем? Если суть можно смотреть по тексту на VHDL?

    Дык, если только булевскую логику — то ради бога. А если сложная схема из активных/пассивных элементов, то я без графики даже не разберусь, как она работает. Надо в голове представить одновременно происходящие аналоговые процессы в куче связанных элементов и без графического отображения это просто нереально.

    N>>>>А что плохого в сотнях связей для сложного блока, если он действительно сложный?

    FM>>>1. Та же самая ситуация со вставкой нового блока. Раздвигаем старые блоки и случайно закорачиваем две из сотен связей. Очень легко упустить этот момент, особенно если у связей нету имен.

    V>>Для этого надо двигать элементы из режима прокладки связей, что есть "сам себе злобный буратино". Иначе их закоротить никак. Ну и после трассировки выдаст ошибку, не боись.

    FM>Ой, ну тогда ручками будешь перерисовывать сотни связей.

    Ниче не понял... что за CAD?
    Почему нельзя просто подвинуть блоки и почему связи сами не двигаются за блоками? А если использовать шины, то подвинуть целую шину — это вообще ерунда.

    FM>Кстати, что это у тебя за трассировка такая умная, что знает что у тебя net0078 не должна быть закорочена с net0126?


    Дык, если на получившуются результирующую линию выйдет пара out-пинов, то какие проблемы?

    V>>А всего-то надо попросить вывести список всех пинов всех компонент, подключенных туда. Это многократно удобнее поиска по всем файлам.

    FM>Пожалуйста, назови хотя бы три САПРа, поддерживающих такую функциональность.

    Как минимум PCAD, ORCAD и если склероз не изменяет — Protel.


    FM>>>Нужно просмотреть каждую ветку, заходя рекурсивно в каждый блок. Очень легко пропустить что-нибудь.


    V>>Враки.

    FM>Это следует понимать как "Я, vdimas, создал N схем с более чем 10К элементов и ни разу не сталкивался с такой проблемой" или "я -- болтун-теоретик не воспринимающий факты, которые противоречат моему мнению"?

    Нет, не сталкивался на сотнях схем ни разу. А факты мы сейчас рассматриваем очень субъективные. И 10К элементов, требующих ревью — это нубство, сорри. На любом уровне иерархии не должно быть более нескольких десятков/сотен элементов, иначе такой дизайн только в мусорку. Если же тебе понадобилось просмотреть ЛЮБОЙ сигнал сквозь мн-во уровней иерархии, то это лишь говорит о кривизне дизайна и ни о чем более. В ПО я тоже наблюдал аналогичные косяки, но, тем не менее, на попытки подобных заявлений, о необходимости сквозного ревью сразу нескольких уровней иерархии, буду отвечать — враки. Не требуется! При нормальной декомпозиции и грамотном разделении функциональности этого не надо. Принципы "грамотного" разделения давно сформулированы и они универсальны как для ПО, так и для схемотехники... аналоговой в т.ч.

    V>>Это если цифровая схемотехника "сама в себе" и собрана из готовых кирпичиков (или вентилей). А если требуется эти кирпичики разрабатывать с 0-ля — то увы.

    FM>Жаль тебя разочаровывать, но эти цифровые кирпичики разрабатываются даже в случае схемотехнического ввода схемы.

    Дык, я не против кирпичиков, я говорю о том, что возможности разрабатывать кирпичики исключительно в тексте очень ограничены, т.к. могут стартовать лишь с уровня других, заранее предопределенных кирпичиков.


    FM>Еще одну причину вспомнил. В нормальной цифровой схеме обычно применяется Boundary scan testing. Представляешь как весело руками последовательно соединить все ячейки?


    Зачем руками? И почему все?


    FM>И работа с нетлистом тебе в этом случае особо не поможет, потому что в нетлисте нет информации о взаимном расположении ячеек и можешь получить лишние проводники из одного края кристалла на другой. В то же время синтезатор знает какой регистр за каким следует и может, при необходимости, перекоммутировать BS связи.


    Похоже ты уже грубо путаешь то, что делаешь ручками и то, что делают тулзы. Так вот, verilog (коль ты его упоминаешь) прекрасно отображается на схематику и обратно. Поэтому всё, что доступно после этапа текстовой набивки схемы, доступно и после этапа ее графической набивки. Более того, есть тулзы, которые позволяют и так и так практически одновременно.

    FM>А представляешь какую визуальную грязь добавит эта дополнительная куча связей, идущая сквозь все ячейки по иерархии?


    Курить понятие "шины" до полного просветления. Пример Ленинград-1 я уже приводил. Это пример относительно несложной схемы, которая, темне менее, имеет несколько сотен связей. Без шин была бы грязь. А представь более сложные блоки?


    V>>Да пожайлуйста. Для цифровых подзадач вполне пойдет. Как когда-то процессоры заменили автоматику и вместо разработки автоматики стали писать программы на процессора на других языках. Только это не отменяет этапа разработки схемы даже на основе процессора со всей требуемой обвеской, когда процессор управляет некоим реальным блоком вместо автоматики. Все-равно конечную схемы на основе процессора без графики не представить, хоть тресни. Пусть даже в нем "унутре" сколь угодно сложная программа. Даже возьми материнки современных компов или любые платы раширения. Я периодически взглядываюьс в разводку и расположение и могу тебя заверить, что там ручками доводилось обязательно как первое, так и второе. Но в тексте это на сегодня невозможно ни в одном из тулзов. Получается, что де-факто компьютерные платы таки разрабатывают в графике? Просто ты работаешь в другом направлении.


    FM>Итак, ты согласился, что для цифровых подзадач текст подходит.


    Я с этим не спорил ни разу. Наоборот, я поправляю все твои попытки неправомерного обобщения, что речь идет сугубо об однородном цифровом дизайне.


    FM>А, учитывая полную победу цифровых HDLs над schematic entry, текст подходит для них лучше графики.


    Для этой весьма узкой этой ниши дизайна кристаллов — да ради бога. Это пришло из FPGA, напомню. Эдакое прототипирование, только не в софте, а железе. Сам бог велел писать ПО. Но как-то ты весело уже наверно 10-й раз игнорируешь момент разработки конечных схем на основе цифровых. И вот сейчас про упомянутые материнки сделал вид что понял. Сколько разновидностей материнок приходится на один чипсет?

    И тут я писал:

    Я думаю, что цифровых дизайнов относительно немного. Относительно всех дизайнов. Практически ВСЕГДА одни и те же цифровые компоненты используются более чем в одной конечной схеме. И коэффициент тут несколько порядков обычно, от 3-х и более. Т.е. на одну цифровую микросхему рано или поздно наберется тысячи схем, где ее применяют со всевозможной аналоговой обвеской. Мне вообще кажутся смешными эти споры, каких дизайнов больше. Похоже, кое-кто кое-что не догоняет. Высокоинтегрированная цифра от того и стала популярна, что она инкапсулирует в себе некое типовое решение. Ведь высокоинтегрированные микросхемы окупаются только в приличных партиях. Поэтому, если где-то цифра уникальна — это заведомая профанация всей идеи.


    Поэтому я лишь вижу, что дизайнов конечных схем на несколько порядков больше дизайнов цифровых микросхем, а в этих дизайнах конечных схем обязательно используется графика. Итого, в современной схемотехнике работают в графике на порядки больше, чем с текстом.

    FM>В этом то и суть. Ни ты (со стороны board level engineers), ни я (со стороны analog IC designers) не можем утверждать, что графика по удобству превосходит текст, поскольку мы просто не имеем дело со схемами таких масштабов. Цифровые инженеры первыми столкнулись с дизайнами в сотни тысяч и миллионы элементов и деньгами проголосовали за текст.


    Потому что цифровая разработка сегодня — это разработка модели. Это классическое прототипирование. Это и есть ПО. И дело тут не в кол-ве вентилей. Это упирание на кол-во вентилей нубство и еще рекламный трюк (мне уже надоело упоминать иерархии и декомпозицию, которые разруливают хоть миллионы вентилей на раз). Дело в самой однородности процесса. Все происходит в "песочнице", т.е. в изолированных от подробностях абстракциях. Поэтому наработки ПО вполне прокатывают. Но таки при проектировании тех же микропроцессоров, все-равно графика используется и видел не раз. Основные блоки, их функциональность и связи, протокол м/у ними и т.д., все это разрабатывается в графике, хоть пусть подробности реализации потом — в тексте. Дык, подробности всегда было удобней в тексте, даже вовремена PCAD. Например, проставить ли быстро заменить номиналы транзисторов на аналоги и т.д. — нет ничего удобнее чем работа через текст в таких операциях, ес-но, но лишь потому, что идет редактирование сугубо текстовых св-в элементов. Это надо понимать.


    V>>С аналоговыми упираемся в отображение "формул" на конкретную схему. Слово "конкретное" — ключевое. А если я хочу сами схемы пробовать/варьировать?

    FM>Да кто тебе мешает? Имеешь нетлист, перерисовываешь его руками и меняй сколько хочешь.

    В нетлисте из более десятка связей утонешь, уже ничего не понятно. Тем более, если делаешь всякие технологические трюки. Поэтому без графики — никуда.
    Да и вообще, посмотри хоть раз за работой разработчика схемотехнических решений (трюков). Даже если он "салфетке" что-то чиркает, поверь, он не текстовую таблицу связей там чиркает, а графические элементы и связи.


    FM>>>А стандарт на графическое типа есть, я уже упоминал edif. Дважды пытался его использовать, первый раз обломался и перерисовал все руками (благо схема была небольшая).

    FM>>>Второй раз, при помощи питоновского скрипта и такой-то матери удалось худо-бедно перенести схему между САПРами. Но все равно пришлось еще пару тысяч элементов поправлять ручками.

    V>>А что за САПР-ы были?

    FM>Cadence Composer -> Mentor Graphics DesignArchitect
    FM>Mentor Graphics DXDesigner -> Cadence Composer

    Ну, посмотрел форматы... Коллега, не прими за наезд, но похоже от программирования ты малость далек, что написать утилиту конвертирования вылилось в "такую-то матерь" и еще пришлось что-то делать ручками. Кстати, именно во время работы схемотехником мне пришлось написать просто тонны утилит. В т.ч. для расчета параметров схем и моделирования. Возьмите полноценного программиста в команду. Вы даже не представляете, какой буст разработки это даст.


    V>>Но даже расположи эти сугубо цифровые схемы на плате. Пусть автоматом. Зато мы потом берем и измеряем мощность*длину/ширину питающих соединений, полученных де-факто после размещения и разводки (даже если они автоматические). Уже кое-где требуется кондеры вставлять по питанию, а кое-где увеличивать их емкость. И вот уже появляются новые элементы в схеме или меняются номиналы имеющихся, что влечет за собой изменение их размеров и заход на новую итерацию размещения и разводки. В голом тексте это вообще никак не работает.

    FM>Еще раз. Когда у тебя окажется сотня тысяч связей, то руками ты физически не сможешь модифицировать все сложные места за приемлемое время. Ты просто синтезируешь схему (например при помощи IC compiler), экстрагируешь паразитные параметры (StarRC) и моделируешь схему с их учетом (PrimeTime для проверки целостности сигналов и проблем с мощностью). Если есть проблемы с какими-то связями, то возвращаешься к IC Compiler и вписываешь дополнительные ограничения в скрипт для синтеза (например команда set_clock_latency, set_clock_transition для установки правильного тайминга сигналов генератора)

    Т.е. загублять параметры дизайна вместо того, чтобы попытаться переиначить декомпозицию и связь м/у "блоками"?
    А что схема делает, если не секрет?
    Re[68]: Языки общего назначения не имеют смысла!
    От: FragMent  
    Дата: 10.06.12 14:22
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    FM>>Обычный эффект масштаба. Тебя не смущает, что СУБД для хранения 100Мб данных и 1 Тб данных, скорее всего потребуются разные.

    V>Признаюсь, я не понял сути возражения... если это было возражение, конечно...
    Не притворяйся. Методы работающие для малых систем (или для малого числа элементов) не всегда подходят для больших. Примеров тысячи.

    FM>>Вот есть микроконроллер, у которого схема тактирования работает от внешнего кварца (маленький аналоговый блочок в десяток транзисторов), он какой? Цифровой или цифроаналоговый? Скорее всего цифровой.


    V>Ес-но цифро-аналоговый прямо по-определению. К тому же, а порты вводы/вывода прямо таки цифровые у всего девайса в целом? Да фактически никогда. Т.е. еще будет согласование и преобразование. Итого, в типовой схеме из полусотни элементов цифровым будет только один элемент — микроконтроллер... Который, повторюсь, типовой, а схема на нем — уникальна.

    Не понял. Я спросил микропроцессор цифровой или цифроаналоговый. Ты ответил "Ес-но цифро-аналоговый прямо по-определению" и буквально в следующей строчке пишешь "цифровым будет только один элемент — микроконтроллер". Ты уж определись.

    FM>>А если мы добавим внутрь микроконтроллера PLL как черный ящик, он превратиться в цифро-аналоговую схему? На мой взгляд — нет, но кто-то может думать иначе.


    V>Я думаю, что цифровых дизайнов относительно немного. Относительно всех дизайнов. Практически ВСЕГДА одни и те же цифровые компоненты используются более чем в одной конечной схеме. И коэффициент тут несколько порядков обычно, от 3-х и более. Т.е. на одну цифровую микросхему рано или поздно наберется тысячи схем, где ее применяют со всевозможной аналоговой обвеской. Мне вообще кажутся смешными эти споры, каких дизайнов больше. Похоже, кое-кто кое-что не догоняет. Высокоинтегрированная цифра от того и стала популярна, что она инкапсулирует в себе некое типовое решение. Ведь высокоинтегрированные микросхемы окупаются только в приличных партиях. Поэтому, если где-то цифра уникальна — это заведомая профанация всей идеи. Всякие уникальности должен обыгрывать софт.

    Противоречие. Если цифровых дизайнов немного, то и вакансий должно быть мало. Чего в природе не наблюдается.
    V>Ну я конечно всерьез не рассматриваю FPGA. Эта штука изначально предназначалась для прототипирования. Делать на ней конечные решения — это получать то самое "решение для бедных". И скорости не те и шум и потребление и вообще...
    Фирма Xilinx смотрит на тебя с недоумением. FPGA отличное решение, когда не нужно большое количество конечных устройств или перепрограммирование налету. Опять же количество вакансий говорит само за себя.
    FM>>Мне это говорит о том, что стоимость аналоговых схем выше за счет более сложного техпроцесса, более низкого выхода годных, и маркетинговых соображений.

    V>Нет, просто меньшая масштабируемость. Вот выпустили партию печатных плат под материнки из 10000 шт и всё. А выпуск цифровых микросхем идет на миллионы. Поэтому в большинстве конечных потребительских схем сидит приличная доля стоимости разработки. Да и сложнее эти схемы, чем цифровые. Слишком много подробностей технологии нужно учитывать в дизайне. Сравни с голой булевской логикой, где ничего не надо учитывать, кроме задержек.

    Попробуй спроектировать простой процессор с 5-stage конвейером и блоком предсказания переходов и потом обсудим простоту цифрового дизайна.

    FM>>А также, что производительность цифровых дизайнеров выше, чем аналоговых.


    V>Потому что специализация Уже, а работа однообразнее. Производительность веб-мастеров тоже выше производительности С++ программистов, если в тиках процессора считать по готовой программе...

    V>Потому что меньше болит голова о технологической стороне продукта. Знай себе в песочнице ковыряй.
    А у ассемблерщиков еще круче! Сидят эти C++ программисты в своей скучной песочнице и не болит у них голова о распределении регистров.
    И C++ программы состоят из типовых решений. Везде там for-ы да if-ы.

    FM>>Кстати, здесь написано, что производительность дизайнера на уровне схемы 100-200 гейтов в неделю, а на уровне HDL — 1-2 килогейта.


    V>Когда тебе порты выхода с реальными исполнительными устройствами сопрягать надо будет, не поможет тебе никакой HDL. Будут те же 100-200 компонент в неделю.

    А когда тебе потребуется сделать в железе свою систему для high frequency trading ты тоже будешь пилить 100-200 компонент в неделю или перейдешь все же на более подходящий инструмент?

    FM>>Да, да. Просто вставить ядро процессора и никаких проблем. А цифровую обвязку для него и аналоговой части писать не надо?

    V>Дык и я про то, что меняется существенно только гибридная часть, которую на HDL писать не эффективно до сих пор.
    Я не про гибридную часть, а про сопряжение покупных IP блоков между собой (например ядро ARM, DSP core, MPEG-декодер).

    V>Да, цифра изначально и задумывалась как вспомогательный инструмент, апроксимирующий требуемые аналоговые сигналы, что не так?

    V>По мере своего удешевления цифра заменяет аналог. Решение-то в цифре сложнее, ес-но, но при этом все дешевле и дешевле, именно из-за той самой однородности дизайна и гибкости через софт или микропрограммы (таблицы истинности ф-ий переходов автоматов, вшитые в ПЗУ).
    Я тебя не пойму. То ты говоришь, что цифры очень мало, то что она все больше заменяет аналог.

    FM>>>>Можем еще сравнить по количеству вакансий.

    V>>>Смотря где искать вакансии. Мне постоянно приходят предложения, связанные с дизайном схем и конечных устройств.
    FM>>Там где ищут одновременно аналоговых и цифровых спецов.
    FM>>Например сегодня на http://www.ic-resources.com/ Digital IC 233 вакансии, analog/rf IC 112 вакансий.
    FM>>Зачем столько цифровиков, если можно просто вставить MIPS ядро?

    V>Цифровой дизайн сложнее гораздо. Для эмуляции простого бивадратного аналогового фильтра на 15 элементах надо десятки тысяч вентилей для умножителей, сумматора, ПЗУ микропрограммы, ЦАП/АЦП.

    Цитирую тебя

    Ну и опять же, учитывая относительно большую повторяемость цифровых компонент, то бишь относительно малое их разнообразие, оценивать объем дизайна по денежному обороту — это самое настоящее нубство. Например, на одних и тех же ядрах MIPS без переделок выпускают многие сотни (если не тысячи) номиналов якобы "железных" микросхем: видео/аудио/сетевых кодеков. А реально там один и тот же цифровой дизайн, где отличия идут в основном в гибридной части и в прошитом софте.

    и повторяю вопрос: зачем столько цифровиков?
    V>И вообще, ты не туда смотришь. Надо смотреть на вакансии разработчиков конечных схем и интересоваться, чем они занимаются. Я работал по цифровой "половине" дизайна, но почему-то минимум половину трудозатрат шло на разработку сопряжений с аналоговой частью, в т.ч. через софт. Думаю, ты не верно представляешь себе занятость цифровика в процессе разработки конечных устройств.
    Да без проблем. Первая страница Приглашаем на работу на электониксе. Вакансий инженеров-разработчиков три. В двух из них требуется знание
    verilog/VHDL

    V>Э нет, коль в исходной формуле участвует добротность и шла речь об отображении формулы на схему, а не наоборот, то пример был неудачен. Читать предыдущее предложение до просветления.

    V>Задача отображения схему на формулу и формулы на схему — они ой какие разные.
    Спасибо, что разоблачил товарищей Сталлена и Кея, предложивших данную структуру полвека назад.

    V>Дык, а в чем тогда профит текста, если я и так в графике могу нарисовать в виде черного ящика любой, сколь угодно сложный элемент.

    Нарисуй мне, например, корректор фактора мощности из элементов в виде черного ящика.

    V>Ты же ведь манипулирующие высказывания приводил (из разряда рекламных, очевидно), что вот мол в графике 200 гейтов в неделю. Реально будет 200 компонент, а не гейтов. А при правильно выбранной декомпозии/иерархии счет гейтов может пойти на миллионы, а не на тысячи. Просто работать в графике надо уметь.

    Конечно, ты просто мастер. А те "манипулирующие высказывания приводил (из разряда рекламных, очевидно" написал какой-то лох из University of California, Berkeley.
    V>Без ложной скромности скажу так, что очень и очень немногие люди обладают умением проектировать конечные схемы хотя бы близко к потребительскому качеству. Или те самые упомянутые "трюки", типа ячейки динамической памяти на обычном транзисторе с висящим эмиттером. Т.е. полноценно проектировать и в графике в т.ч. (а реальное проектирование любых технологических вещей идет только в графике), в общем, работать с этим с нужной отдачей могут очень немногие. Сие факт, наблюдаемый мною много лет. Зато с текстом работать может любой, кому под силу освоить язык хотя бы уровня BASIC. ИМХО, причины распространенности текста ровно такие же, почему убогая Джава стала мейнстримом. В ограниченности сила, бо меньше поле для ошибок.
    Мой тезис: переход от схем к тексту в цифровом дизайне позволил увеличить продуктивность разработчиков и разрабатывать более сложные конструкции.
    Все разговоры о дураках только от непонимания специфики.

    FM>>Ты, почему-то, занимаешь экстремальную позицию, или текст или графика. Ради бога, никто не мешает в нужных местах спуститься на уровень ниже и немного подшаманить.


    V>Я? Боже упаси. Если читал сначала, то наоборот. Я говорил, что максимальная отдача от обоих. Более того, высказывал такую мысль, что многую рутину удобнее бывает набить в тексте, но просматривать результат таки в графике. Как всем понятный пример приводил ход работы веб-дизайнера. Пишет он HTML-код, но смотрит затем на графическое представление страницы. Что есть "графическое" я пытался дать определение здесь: http://www.rsdn.ru/forum/philosophy/4755042.1.aspx
    Автор: vdimas
    Дата: 28.05.12


    V>>>Это в простейших случаях так... Например, для подбора кондеров по питающим шинам.

    FM>>Это для печатных плат. А для чипов, если у тебя операционник из десятка транзисторов, то ты должен выбрать правильный размер (длина, ширина) каждого из них, исходя из взаимосвязанных критериев: Noise, Linearity, Gain, Supply Voltage, Voltage Swing, Speed, Input/Output Impedance, Power Dissipation

    V>И че? Все эти тулзы автоматом никак?

    Я ж и говорю. Только магма делала что-то автоматическое. Там ведь еще сложности, что параметры внутри схемы имеют огромный разброс. +/- 30% номинала резистора это нормальная ситуация. По прежнему больше искусство, чем наука.

    V>>>Форматы PCAD в свое время поддерживали почти все и до сих многие поддерживают.

    FM>>Это стандарт?

    V>Да. Все популярные тулзы для проектирования схем и печатных плат умели экспортировать/импортировать его форматы файлов.

    V>Кстати, с первых страниц гугля нашел насчет DIFF файлов от P-CAD:
    V>http://billauer.co.il/blog/2010/07/net-pcad-netlist-files-perl/
    Ни один из САПРов, с которыми я работал его не поддерживал

    V>Обрати внимание на смешной размер снипетта кода, полностью решающего проблему.

    Ты сам когда-нибудь сравнивал нетлисты? Мне приходилось не раз. Удовольствие ниже среднего

    FM>>Вот openAcces более менее можно назвать стандартом (сюрпрайз — формат бинарный).


    V>На мой взгляд бинарные форматы парсить несоизмеримо легче текстовых. Во-первых они более детерминированы, во-вторых, меньше требуется преобразований числовых значений. А если еще разработчики формата, не будь дураки, описали его спецификацию через ASN.1 — вообще сказка. Само будет парсится... Или таки дураки?

    Дураки. Они сразу код предоставляют. Но появился он относительно недавно. И не все его поддерживают, да и вряд ли будут.

    V>>>Ну так у этих специалистов должен быть какой-то инструмент? Или они по-старинке ручками рисуют? А если я сам хочу разработать такой кирпичик, что мне делать? Таки будет мне нужна графика или нет?

    FM>>Да, нарисовали схему, сделали нетлист, и началась основная работа.

    V>Основная работа — это разработка работющей схемы. Остальное — это лишь ее расчеты и доводка. Во многом автоматизированная и не творческая стадия... которую женщины, по моим наблюдениям, делают лучше мужчин.

    Витать в облаках и придумывать новое — для молокососов . А вот сделать дизайн ячейки памяти работающей во всем диапазоне разбросов параметров, напряжений и температур с шестью сигмами (значит один дефект на миллиард ячеек) — вот работа для настоящих инженеров, которые не боятся ковыряться в деталях.

    V>>>А Симулинк не пробовал?

    FM>>Нет, потому что мне нужно одновременно использовать блоки из реальных элементов.

    V>А какие проблемы импортировать туда VHDL/verilog?

    При чем тут VHDL? Мне нужно допустим, чтобы интегратор состоял из реальных транзисторов и конденсаторов, а компаратор был упрощенной моделью.
    Кстати, даже с том же симулинке, если вдруг не окажется модели компаратора (я знаю что он там есть), все равно его придется описывать на языке m.
    Re[68]: Языки общего назначения не имеют смысла!
    От: FragMent  
    Дата: 10.06.12 17:12
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    V>>>Для этого надо двигать элементы из режима прокладки связей, что есть "сам себе злобный буратино". Иначе их закоротить никак. Ну и после трассировки выдаст ошибку, не боись.

    FM>>Ой, ну тогда ручками будешь перерисовывать сотни связей.

    V>Ниче не понял... что за CAD?

    V>Почему нельзя просто подвинуть блоки и почему связи сами не двигаются за блоками? А если использовать шины, то подвинуть целую шину — это вообще ерунда.
    Я подумал, ты под режимом "прокладки связей" имеешь в виду как раз когда связи тянуться за блоками. Поэтому и предложил вариант, когда сначала отключаешь связи от блока, перемещаешь его и снова доводишь их. Но раз я тебя не так понял, то проблема закоротки, если связи случайно совпали остается. Пару раз у меня такое было. Повезло, словил быстро.

    FM>>Кстати, что это у тебя за трассировка такая умная, что знает что у тебя net0078 не должна быть закорочена с net0126?

    V>Дык, если на получившуются результирующую линию выйдет пара out-пинов, то какие проблемы?
    А если два in-пина?

    V>>>А всего-то надо попросить вывести список всех пинов всех компонент, подключенных туда. Это многократно удобнее поиска по всем файлам.

    FM>>Пожалуйста, назови хотя бы три САПРа, поддерживающих такую функциональность.

    V>Как минимум PCAD, ORCAD и если склероз не изменяет — Protel.

    Надо будет поставить — посмотреть.

    FM>>>>Нужно просмотреть каждую ветку, заходя рекурсивно в каждый блок. Очень легко пропустить что-нибудь.


    V>>>Враки.

    FM>>Это следует понимать как "Я, vdimas, создал N схем с более чем 10К элементов и ни разу не сталкивался с такой проблемой" или "я -- болтун-теоретик не воспринимающий факты, которые противоречат моему мнению"?

    V>Нет, не сталкивался на сотнях схем ни разу.

    Переформулирую: "я написал 100 десятистрочных программ, поэтому знаю как написать программу в 100 тыс. строк"
    V>А факты мы сейчас рассматриваем очень субъективные. И 10К элементов, требующих ревью — это нубство, сорри. На любом уровне иерархии не должно быть более нескольких десятков/сотен элементов, иначе такой дизайн только в мусорку. Если же тебе понадобилось просмотреть ЛЮБОЙ сигнал сквозь мн-во уровней иерархии, то это лишь говорит о кривизне дизайна и ни о чем более. В ПО я тоже наблюдал аналогичные косяки, но, тем не менее, на попытки подобных заявлений, о необходимости сквозного ревью сразу нескольких уровней иерархии, буду отвечать — враки. Не требуется! При нормальной декомпозиции и грамотном разделении функциональности этого не надо. Принципы "грамотного" разделения давно сформулированы и они универсальны как для ПО, так и для схемотехники... аналоговой в т.ч.
    Да даже в программировании есть такая проблема. Если бы ее не было, не появилось бы Аспектно-ориентированное программирование.
    А уж для электроники и подавно. Нарисуй токовое зеркало и проведи от него два тока в разные блоки. Повесь на один из них шумящую схему — получишь шум на второй ветке. И блоки могут оказаться на разных уровнях иерархии. И цифровых сигналов по всей иерархии полно: POR, reset, clock, boundary scan.

    FM>>Еще одну причину вспомнил. В нормальной цифровой схеме обычно применяется Boundary scan testing. Представляешь как весело руками последовательно соединить все ячейки?


    V>Зачем руками? И почему все?

    Это такой метод быстрого тестирования работоспособности цифровых схем. В тестовом режиме все регистры соединяются последовательно и на вход микросхемы подается последовательность сигналов, если она появляется на выходе без искажений, значит как минимум нет неработающих регистров и имеет смысл выполнять функциональное тестирование.

    FM>>И работа с нетлистом тебе в этом случае особо не поможет, потому что в нетлисте нет информации о взаимном расположении ячеек и можешь получить лишние проводники из одного края кристалла на другой. В то же время синтезатор знает какой регистр за каким следует и может, при необходимости, перекоммутировать BS связи.


    V>Похоже ты уже грубо путаешь то, что делаешь ручками и то, что делают тулзы. Так вот, verilog (коль ты его упоминаешь) прекрасно отображается на схематику и обратно. Поэтому всё, что доступно после этапа текстовой набивки схемы, доступно и после этапа ее графической набивки. Более того, есть тулзы, которые позволяют и так и так практически одновременно.

    Это ты путаешь RTL verilog с Verilog netlist, который в принципе ничем не отличается от обычного нетлиста.
    Вот тебе пример RTL кода
    always @(posedge clk) begin
        for (int i=0; i<3; i++) begin
            if (enable[i]) begin
                foo[i] <= newval[i];
         end
      end
    end

    а вот verilog netlist
    y00EnFlop(foo_0,newval_0,enable_0, clk);
    y00EnFlop(foo_1,newval_1,enable_1, clk);
    y00EnFlop(foo_2,newval_2,enable_2, clk);
    y00EnFlop(foo_3,newval_3,enable_3, clk);

    В каком случае у программы больше информации о дизайне думаю объяснять не нужно.

    V>Я с этим не спорил ни разу. Наоборот, я поправляю все твои попытки неправомерного обобщения, что речь идет сугубо об однородном цифровом дизайне.

    Где я обобщал? Я всего лишь отметил, что люди столкнувшиеся со структурной сложностью, ушли от графики к тексту.

    FM>>А, учитывая полную победу цифровых HDLs над schematic entry, текст подходит для них лучше графики.


    V>Для этой весьма узкой этой ниши дизайна кристаллов — да ради бога. Это пришло из FPGA, напомню. Эдакое прототипирование, только не в софте, а железе. Сам бог велел писать ПО. Но как-то ты весело уже наверно 10-й раз игнорируешь момент разработки конечных схем на основе цифровых. И вот сейчас про упомянутые материнки сделал вид что понял. Сколько разновидностей материнок приходится на один чипсет?

    Любой проц по сложности уделывает все материнки на его основе вместе взятые. В Интеле несколько сот инженеров работают над одним ядром в течении некольких лет.


    V>Поэтому я лишь вижу, что дизайнов конечных схем на несколько порядков больше дизайнов цифровых микросхем, а в этих дизайнах конечных схем обязательно используется графика. Итого, в современной схемотехнике работают в графике на порядки больше, чем с текстом.

    Напоминаю начало разговора:
    V>>А как же железки разрабатывают? Ты утонешь уже в сотнях элементов на одном уровне, а их сейчас на многие тысячи и даже миллионы в процах.
    WH>Verilog, VHDL,...

    V>Дудки, это только 30% работы или меньше, остальные все равно в графике. Текст хорош исключительно для copy&paste и прочего быстрого размножения похожих частей, или для глобального поиска/земены, собсно, для таких работ в него и переключаются. А так в нем работать невозможно, ты на экране максимум пару десятков строчек кода увидишь, а это катастрофически мало. Поэтому все эти редакторы Verilog на самом деле графические.


    На что тебе справедливо возразили, что процы в графике не разрабатывают. Теперь ты отстаиваешь другую позицию, что цифра однородна, поэтому ее можно в тексте описывать, и зачем-то переводишь разговор на конечные схемы. Думаю этот разговор стоит продолжать только если ты предъявишь современный графический дизайн (неважно цифровой или аналоговый) в сотню тысяч элементов.

    V>Потому что цифровая разработка сегодня — это разработка модели. Это классическое прототипирование. Это и есть ПО. И дело тут не в кол-ве вентилей. Это упирание на кол-во вентилей нубство и еще рекламный трюк (мне уже надоело упоминать иерархии и декомпозицию, которые разруливают хоть миллионы вентилей на раз). Дело в самой однородности процесса. Все происходит в "песочнице", т.е. в изолированных от подробностях абстракциях. Поэтому наработки ПО вполне прокатывают. Но таки при проектировании тех же микропроцессоров, все-равно графика используется и видел не раз. Основные блоки, их функциональность и связи, протокол м/у ними и т.д., все это разрабатывается в графике, хоть пусть подробности реализации потом — в тексте. Дык, подробности всегда было удобней в тексте, даже вовремена PCAD. Например, проставить ли быстро заменить номиналы транзисторов на аналоги и т.д. — нет ничего удобнее чем работа через текст в таких операциях, ес-но, но лишь потому, что идет редактирование сугубо текстовых св-в элементов. Это надо понимать.

    "Любую проблему можно решить путём введения дополнительного уровня абстракции, кроме проблемы слишком большого количества уровней абстракции"
    Непонятно, где ты мог видеть разработку микропроцессоров, ну да ладно. В топике про ДРАКОН ты ратовал за графику для программистов. Вот тебе, как ты сам говоришь, фактически программеры, которые имея выбор предпочли текст.

    V>>>С аналоговыми упираемся в отображение "формул" на конкретную схему. Слово "конкретное" — ключевое. А если я хочу сами схемы пробовать/варьировать?

    FM>>Да кто тебе мешает? Имеешь нетлист, перерисовываешь его руками и меняй сколько хочешь.

    V>В нетлисте из более десятка связей утонешь, уже ничего не понятно. Тем более, если делаешь всякие технологические трюки. Поэтому без графики — никуда.

    Можешь использовать SpiceVision например
    V>Да и вообще, посмотри хоть раз за работой разработчика схемотехнических решений (трюков). Даже если он "салфетке" что-то чиркает, поверь, он не текстовую таблицу связей там чиркает, а графические элементы и связи.
    Что мне смотреть, я сам придумываю схемотехнические решения

    FM>>>>А стандарт на графическое типа есть, я уже упоминал edif. Дважды пытался его использовать, первый раз обломался и перерисовал все руками (благо схема была небольшая).

    FM>>>>Второй раз, при помощи питоновского скрипта и такой-то матери удалось худо-бедно перенести схему между САПРами. Но все равно пришлось еще пару тысяч элементов поправлять ручками.

    V>>>А что за САПР-ы были?

    FM>>Cadence Composer -> Mentor Graphics DesignArchitect
    FM>>Mentor Graphics DXDesigner -> Cadence Composer

    V>Ну, посмотрел форматы... Коллега, не прими за наезд, но похоже от программирования ты малость далек, что написать утилиту конвертирования вылилось в "такую-то матерь" и еще пришлось что-то делать ручками. Кстати, именно во время работы схемотехником мне пришлось написать просто тонны утилит. В т.ч. для расчета параметров схем и моделирования. Возьмите полноценного программиста в команду. Вы даже не представляете, какой буст разработки это даст.

    "Такая-то матерь" была, потому что надо сделать быстро. Проблема была не в том, чтобы написать парсер, а в том что во-первых некоторые проперти разным софтом воспринимались по разному, а во-вторых разные координатные сетки и гриды приводили к тому, что элементы оказались слегка сдвинутыми относительно своих связей и уменьшенными. Первая проблема была решена регулярными выражениями, а вот бы вторая потребовала полноценного парсера, на который просто не было времени. В результате немного схитрил и сдвинул символы и потом руками довел шины.
    Эта функциональность понадобилась мне два раза за 14 лет. Предлагаешь держать программиста ради такого случая? Если буду знать, что понадобится еще раз, сделаю без проблем.
    А утилиты пишутся конечно. От лиспа до плюсов И dsl-и используются в полный рост.

    FM>>Еще раз. Когда у тебя окажется сотня тысяч связей, то руками ты физически не сможешь модифицировать все сложные места за приемлемое время. Ты просто синтезируешь схему (например при помощи IC compiler), экстрагируешь паразитные параметры (StarRC) и моделируешь схему с их учетом (PrimeTime для проверки целостности сигналов и проблем с мощностью). Если есть проблемы с какими-то связями, то возвращаешься к IC Compiler и вписываешь дополнительные ограничения в скрипт для синтеза (например команда set_clock_latency, set_clock_transition для установки правильного тайминга сигналов генератора)


    V>Т.е. загублять параметры дизайна вместо того, чтобы попытаться переиначить декомпозицию и связь м/у "блоками"?

    Не понял.
    V>А что схема делает, если не секрет?
    Какая схема, я тебе описываю как делается дизайн цифровых микросхем.
    Re[13]: Языки общего назначения не имеют смысла!
    От: iHateLogins  
    Дата: 11.06.12 12:11
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    G>>Покажи некривой. Только реальный, не академический.

    AVK>Ну вот Парус 10 такой Реальный, не академический.

    А можно почитать спеки по этому продукту, документацию по API и какие-нибудь презы с кейсами?

    Тут http://www.parus.ru/products/gov/#parus10 инфы как-то не очень много.
    Re[14]: Языки общего назначения не имеют смысла!
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 11.06.12 20:43
    Оценка:
    Здравствуйте, iHateLogins, Вы писали:

    HL>А можно почитать спеки по этому продукту, документацию по API и какие-нибудь презы с кейсами?


    Вопрос не ко мне. Я занимаюсь разработкой платформы, которая сама по себе не продается, а не маркетингом. Основной сайт — https://tornado.parus.ru:8181/, там вроде бы все, что публично доступно. Остальное — только для партнеров.
    ... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>
    AVK Blog
    Re[69]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 03.07.12 19:45
    Оценка:
    Здравствуйте, FragMent, Вы писали:

    V>>Нет, не сталкивался на сотнях схем ни разу.

    FM>Переформулирую: "я написал 100 десятистрочных программ, поэтому знаю как написать программу в 100 тыс. строк"

    Ну дык, даже программу из миллиона строк я пишу как набор программ из 100 строк. Вот и посчитай (грубо), сколько надо слоёв ПО, чтобы получить миллион по основанию ~100. Как раз стандартные 3-4 слоя и получаются. В схемотехнике примерно аналогично.

    Какой смысл было указывать на общее кол-во вентилей, если я использую в некоей цифро-аналоговой схеме микросхемы относительно высокого уровня? Да, я не делал ничего на FPGA и не разрабатывал кристаллы, но почему-то я уверен, что регистр-защелку на нужное кол-во бит или дешифратор на нужное кол-во бит ты каждый раз с 0-ля не делаешь. Я прав? Т.е. даже если нужного библиотечного элемента нет и его надо делать, то эти библиотечные элементы создаются на своём уровне иерархии и потом исопльзуются как такие же точно библиотечные элементы "изкаробки". В итоге ты оперируешь примерно одинаковой сложностью на каждом уровне.

    Ну и такой момент, что после схемотехники обнаружил в себе способность быстро "въезжать" именно в большие программные продукты в сравнении с коллегами (на относительно небольших проектах этот эффект незаметен). Т.е. мне наоборот всегда казалось, что электронщики умеют декомопозицию лучше программистов... А ты пытаешься меня убедить в обратном.


    FM>Да даже в программировании есть такая проблема. Если бы ее не было, не появилось бы Аспектно-ориентированное программирование.

    FM>А уж для электроники и подавно. Нарисуй токовое зеркало и проведи от него два тока в разные блоки. Повесь на один из них шумящую схему — получишь шум на второй ветке.

    И? Для любых парных каналов в аналоге есть коэф. взаимного влияния в децибелах. Задача разработчика выбрать минимальный (т.е. самый дешевый) вариант, удовлетворяющий заданным параметрам. Этих схем токовых зеркал всяко побольше одной — выбирай нужную.

    FM>И блоки могут оказаться на разных уровнях иерархии.


    Нам не блоки нужны, а спецификации: уровень шумов * коэф. взаимного влияния. Ты ЛЮБОЙ другой блок можешь рассматривать как черный ящик. Иначе утонешь.

    FM>И цифровых сигналов по всей иерархии полно: POR, reset, clock, boundary scan.


    Ну так отлаживал я процессоры от ЕС-1033... куча плат на шасси, куча рассыпухи в каждой и тактовых сигналов. И абсолютно никаких сложностей как на уровне конкретной платы так и на уровне всего процессора, потому что каждый раз сложность вполне обозримая. Короче, я все-равно не поверю, что все ваши 100 тыщ вентилей расположены на одном уровне подробностей. Человек такое не осилит.


    Ладно... На самом деле я уже говорю тоже самое, что в предыдущих постах, ничего нового не изобрету. Если перводить на кол-во элементарных логических ключей, то схемы в десятки тыщ и более ключей тоже разрабатывал, ес-но... Хотя не припомню ни одной схемы сложнее сотни "корпусов". Неужели наличие пластикового корпуса вокруг выделенной логической сущности что-то кардинально меняет? Вот он, вопрос на миллион $$.

    V>>Зачем руками? И почему все?

    FM>Это такой метод быстрого тестирования работоспособности цифровых схем. В тестовом режиме все регистры соединяются последовательно и на вход микросхемы подается последовательность сигналов, если она появляется на выходе без искажений, значит как минимум нет неработающих регистров и имеет смысл выполнять функциональное тестирование.

    Хм... что-то мне подсказывает, что общее кол-во вентилей должно вырасти на ощутимое кол-во %.

    V>>Я с этим не спорил ни разу. Наоборот, я поправляю все твои попытки неправомерного обобщения, что речь идет сугубо об однородном цифровом дизайне.

    FM>Где я обобщал? Я всего лишь отметил, что люди столкнувшиеся со структурной сложностью, ушли от графики к тексту.

    Скорее, они столкнулись с недостатками инструментов разработки.

    V>>Для этой весьма узкой этой ниши дизайна кристаллов — да ради бога. Это пришло из FPGA, напомню. Эдакое прототипирование, только не в софте, а железе. Сам бог велел писать ПО. Но как-то ты весело уже наверно 10-й раз игнорируешь момент разработки конечных схем на основе цифровых. И вот сейчас про упомянутые материнки сделал вид что понял. Сколько разновидностей материнок приходится на один чипсет?

    FM>Любой проц по сложности уделывает все материнки на его основе вместе взятые. В Интеле несколько сот инженеров работают над одним ядром в течении некольких лет.

    А сколько инженеров разрабатвают потом материнки на этих процах?
    Напомню, что тут мы всё еще бодаемся про общее кол-во аналоговых дизайнов и этих аналоговых в любом случае будет больше. Даже если цифровой дизайн сложнее.


    FM>На что тебе справедливо возразили, что процы в графике не разрабатывают. Теперь ты отстаиваешь другую позицию, что цифра однородна, поэтому ее можно в тексте описывать, и зачем-то переводишь разговор на конечные схемы. Думаю этот разговор стоит продолжать только если ты предъявишь современный графический дизайн (неважно цифровой или аналоговый) в сотню тысяч элементов.


    Любая плата с богатой обвеской на проце пойдет?
    Ничем не отличается от того же самого, выполненого по гибридной технологии, когда делается спец-чип на основе стандартного ядра.


    V>>Да и вообще, посмотри хоть раз за работой разработчика схемотехнических решений (трюков). Даже если он "салфетке" что-то чиркает, поверь, он не текстовую таблицу связей там чиркает, а графические элементы и связи.

    FM>Что мне смотреть, я сам придумываю схемотехнические решения

    Ну дык, и в каком виде? Вот сознайся сейчас на весь и-нет.
    Re[69]: Языки общего назначения не имеют смысла!
    От: vdimas Россия  
    Дата: 03.07.12 20:22
    Оценка:
    Здравствуйте, FragMent, Вы писали:

    FM>Не притворяйся. Методы работающие для малых систем (или для малого числа элементов) не всегда подходят для больших. Примеров тысячи.


    Дык, дело-то не размерах системы, а в изменении взаимных пропорций значений основных св-в. Тут размер — дело десятое. Просто при изменении размера пропорции (например, задержек) плывут, что корректирует сценарии использования.

    V>>Ес-но цифро-аналоговый прямо по-определению. К тому же, а порты вводы/вывода прямо таки цифровые у всего девайса в целом? Да фактически никогда. Т.е. еще будет согласование и преобразование. Итого, в типовой схеме из полусотни элементов цифровым будет только один элемент — микроконтроллер... Который, повторюсь, типовой, а схема на нем — уникальна.

    FM>Не понял. Я спросил микропроцессор цифровой или цифроаналоговый. Ты ответил "Ес-но цифро-аналоговый прямо по-определению" и буквально в следующей строчке пишешь "цифровым будет только один элемент — микроконтроллер". Ты уж определись.

    Это ты определись, о чем ты споришь. Речь шла о дизайне. Соответствено, вопрос я прочитал так: "Он (дизайн) цифровой или цифро-аналоговый?".


    V>>Я думаю, что цифровых дизайнов относительно немного. Относительно всех дизайнов. Практически ВСЕГДА одни и те же цифровые компоненты используются более чем в одной конечной схеме. И коэффициент тут несколько порядков обычно, от 3-х и более. Т.е. на одну цифровую микросхему рано или поздно наберется тысячи схем, где ее применяют со всевозможной аналоговой обвеской. Мне вообще кажутся смешными эти споры, каких дизайнов больше. Похоже, кое-кто кое-что не догоняет. Высокоинтегрированная цифра от того и стала популярна, что она инкапсулирует в себе некое типовое решение. Ведь высокоинтегрированные микросхемы окупаются только в приличных партиях. Поэтому, если где-то цифра уникальна — это заведомая профанация всей идеи. Всякие уникальности должен обыгрывать софт.

    FM>Противоречие. Если цифровых дизайнов немного, то и вакансий должно быть мало. Чего в природе не наблюдается.

    Демагогия. Ты же сам сказал, что на одну схему надо 100 человек. И я это подтвердил, что да, она сложнее, поэтому нужна массовость. Т.е. малое кол-во дизайнов относительно дизайнов конечных схем на ней.

    Даже взять самое-самое популярное направление сегодня: вот выпускает Samsung новый чип на ядрах ARM, и этот чип идет в десятки конечных моделей устройств.


    V>>Ну я конечно всерьез не рассматриваю FPGA. Эта штука изначально предназначалась для прототипирования. Делать на ней конечные решения — это получать то самое "решение для бедных". И скорости не те и шум и потребление и вообще...

    FM>Фирма Xilinx смотрит на тебя с недоумением. FPGA отличное решение, когда не нужно большое количество конечных устройств или перепрограммирование налету. Опять же количество вакансий говорит само за себя.

    На вкус и цвет, как говорится...

    FM>Попробуй спроектировать простой процессор с 5-stage конвейером и блоком предсказания переходов и потом обсудим простоту цифрового дизайна.


    И ты проектируешь блок предсказания переходов? А если спроектирую в схеме функциональной, что тогда?


    V>>Потому что специализация Уже, а работа однообразнее. Производительность веб-мастеров тоже выше производительности С++ программистов, если в тиках процессора считать по готовой программе...

    V>>Потому что меньше болит голова о технологической стороне продукта. Знай себе в песочнице ковыряй.
    FM>А у ассемблерщиков еще круче! Сидят эти C++ программисты в своей скучной песочнице и не болит у них голова о распределении регистров.
    FM>И C++ программы состоят из типовых решений. Везде там for-ы да if-ы.

    Да. Я ведь с этим не спорю, а ты пытаешься. Ес-но на С++ всяко проще даже чем на Си, не то, что на ассемблере.

    Аналоговая схемотехника — это до сих пор тот самый ассемблер, а цифровой дизайн — это джава. На неё тоже вакансий больше, чем на асеемблер... и системы на ней разрабатывают объемнее, чем типовые ассемблерные задачи. )))

    V>>Когда тебе порты выхода с реальными исполнительными устройствами сопрягать надо будет, не поможет тебе никакой HDL. Будут те же 100-200 компонент в неделю.

    FM>А когда тебе потребуется сделать в железе свою систему для high frequency trading ты тоже будешь пилить 100-200 компонент в неделю или перейдешь все же на более подходящий инструмент?

    Я пилю даже горадо меньше, чем 100-200 компонент в неделю. Просто за счет иерархичности и повторного использования библиотечных компонент, после компиляции в инструкции процессора выходят совсем другие цифры, на порядок больше твоих. Вот как выглядит твоя демагогия об измерении всего и вся в "логических ключах" (С).


    FM>>>Да, да. Просто вставить ядро процессора и никаких проблем. А цифровую обвязку для него и аналоговой части писать не надо?

    V>>Дык и я про то, что меняется существенно только гибридная часть, которую на HDL писать не эффективно до сих пор.
    FM>Я не про гибридную часть, а про сопряжение покупных IP блоков между собой (например ядро ARM, DSP core, MPEG-декодер).

    Гы, а как же это раньше делали вообще на обвеске? Раньше даже сами DSP собирали из "запчастей" и никто не считал это чем-то сложным... ИМХО, сейчас всё гораздо проще, бо у тебя мильон библиотек и огромный интернет в минутной доступности. В любом случае сопрягать м/у собой сугубо цифровые блоки — это всегда считалось ерундой. Там же все характиристики детерминированные. Давай спеки, т.е. формулируй задачу, и ответ можно выдавать начинать практически сразу, без долгих раздумий. В аналоге так не получается — думать надо.


    FM>Я тебя не пойму. То ты говоришь, что цифры очень мало, то что она все больше заменяет аналог.


    Дизайнов мало. И чем дальше, тем меньше, из-за монопролизации. Как пример — на сегодня выжило смешное кол-во архитектур процов. Т.е. остается всё меньше и меньше дизайнов. Десятки заводов штампуют один и тот же покупной дизайн ARM-ядер.

    В общем ладно, тебе захотелось просто пободаться, и ты делаешь вид, что не понимаешь аргументы..
    Re[2]: Языки общего назначения не имеют смысла!
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 11.10.12 22:57
    Оценка:
    Здравствуйте, Mamut, Вы писали:

    M>Хотя, о чем это я. Вон, Ruby on Rails — это, посути, один большой DSL, который позволяет двумя строчками описать то, что обычно описывается сотней строчек. В итоге шаг вправо-влево (за рамки DSL) — расстрел, во что разворачиваются вызовы этих двух строчек, неизвестно никому, и точки просаживания по производительности тоже неочевидны. Хотя да, это, видимо, плохо спроектированный DSL. С истинно правильным труъ DSL'ем такого не бывает, потому что такого не может быть никогда.


    ДСЛ-и не решают задачи автоматически. Задачу все так же придется решать. Прост при правильном подходе, решение окажется более легким.

    Хотя, о чем это я. Вон, Java (С++, C#, Python, ...) — это, посути, один высокоуровенвый язык, который позволяет двумя строчками описать то, что обычно описывается сотней строчек на ассемлере. В итоге шаг вправо-влево (за рамки ЯОН) — расстрел, во что разворачиваются вызовы этих двух строчек, неизвестно никому, и точки просаживания по производительности тоже неочевидны. Хотя да, это, видимо, плохо спроектированный ЯОН. С истинно правильным труъ ЯОН'ем такого не бывает, потому что такого не может быть никогда.


    M>Хотя не спорю — DSL'и на самом деле рулят. Только вот они тоже далеко не панацея, и применять их лучше дозированно.


    +1 Только вот на сегодня дозы микроскопически. А в большинстве случаев нулевые.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[3]: Языки общего назначения не имеют смысла!
    От: hardcase Пират http://nemerle.org
    Дата: 13.10.12 19:00
    Оценка: +1
    Здравствуйте, VladD2, Вы писали:

    M>>Хотя не спорю — DSL'и на самом деле рулят. Только вот они тоже далеко не панацея, и применять их лучше дозированно.


    VD>+1 Только вот на сегодня дозы микроскопически. А в большинстве случаев нулевые.


    Я бы сказал гомеопатические
    /* иЗвиНите зА неРовнЫй поЧерК */
    Re[3]: Языки общего назначения не имеют смысла!
    От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
    Дата: 14.10.12 22:46
    Оценка: :)))
    Здравствуйте, VladD2, Вы писали:

    VD>Хотя, о чем это я. Вон, Java (С++, C#, Python, ...) — это, посути, один высокоуровенвый язык, который позволяет двумя строчками описать то, что обычно описывается сотней строчек на ассемлере. В итоге шаг вправо-влево (за рамки ЯОН) — расстрел, во что разворачиваются вызовы этих двух строчек, неизвестно никому, и точки просаживания по производительности тоже неочевидны. Хотя да, это, видимо, плохо спроектированный ЯОН. С истинно правильным труъ ЯОН'ем такого не бывает, потому что такого не может быть никогда.


    Для 90% насущных задач этого за глаза хватает. Точки просаживания по производительности вобщем то хорошо известны, описаны чуть нигде угодно. Для дотнета это стало известно примерно в тот же месяц, когда он вышел.
    Re[2]: Языки общего назначения не имеют смысла!
    От: Ziaw Россия  
    Дата: 06.11.12 20:38
    Оценка:
    Здравствуйте, Mamut, Вы писали:

    M>Хотя, о чем это я. Вон, Ruby on Rails — это, посути, один большой DSL, который позволяет двумя строчками описать то, что обычно описывается сотней строчек. В итоге шаг вправо-влево (за рамки DSL) — расстрел, во что разворачиваются вызовы этих двух строчек, неизвестно никому, и точки просаживания по производительности тоже неочевидны. Хотя да, это, видимо, плохо спроектированный DSL. С истинно правильным труъ DSL'ем такого не бывает, потому что такого не может быть никогда.


    Я тоже так думал про РоР, пока не познакомился чуть ближе. Нет там особой магии, все довольно предсказуемо разворачивается. Расстрелов, при выходе за рамки, не больше чем в том же ASP.NET MVC (в MVC эти рамки даже построже будут). Вообще конечно хотелось бы увидеть эти рамки для РоР, может быть они просто от незнания.

    Просадки производительности конечно есть, что заставляет включать кеши заметно раньше того же ASP.NET, но включать их все равно приходится и там и там. Есть конечно и те пессемизации производительности в которых виноваты именно DSL, но в этом плане ruby сильно проигрывает nemerle в возможностях оптимизации генерируемого кода.
    Re[23]: Языки общего назначения не имеют смысла!
    От: LaPerouse  
    Дата: 19.12.12 22:46
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Здравствуйте, AndrewVK, Вы писали:


    VD>>>Этот код никто кроме авторов понять не может.


    AVK>>Ну я то понял.


    VD>А ты найди на этом форуме еще одного человека который бы понял этот код, но не работал бы в Парусе. ;)


    А, так это был Парус? То-то у меня возникло дежавю при взгляде на этот код. Я писал интеграцию одной системы с Парусом. InventoryObject, InventoryObjectItem, Operations, Repairs, я до сих пор это помню...
    Социализм — это власть трудящихся и централизованная плановая экономика.
    Re[27]: Языки общего назначения не имеют смысла!
    От: LaPerouse  
    Дата: 19.12.12 22:53
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>6. Опять даункаст. В целом, выглядит, как размазанная запись правила, которое в оригинале звучало как "убить все карточки, которые входят в бла-бла-бла". DSL, который бы позволял написать "убить все карточки, которые входят в бла-бла-бла", не отвлекаясь на порядок обхода итераторов, даункасты, и скобочки, был бы крайне уместен.


    Этот т.н. "ДСЛ" представляет собой одну функцию по обходу дерева с условием.
    Социализм — это власть трудящихся и централизованная плановая экономика.
    Re[28]: Языки общего назначения не имеют смысла!
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 20.12.12 05:40
    Оценка:
    Здравствуйте, LaPerouse, Вы писали:


    LP>Этот т.н. "ДСЛ" представляет собой одну функцию по обходу дерева с условием.

    Тем лучше.
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[29]: Языки общего назначения не имеют смысла!
    От: LaPerouse  
    Дата: 20.12.12 14:30
    Оценка: 12 (1)
    Здравствуйте, Sinclair, Вы писали:

    S>Здравствуйте, LaPerouse, Вы писали:



    LP>>Этот т.н. "ДСЛ" представляет собой одну функцию по обходу дерева с условием.

    S>Тем лучше.

    Вообще, сторонники DSL в этом топике игнорируют одну простую вещь. В приведенном примере уже используется DSL — это модель предметной области, выполненная на ОО-языке. Которая, кстати говоря может быть элементарно сгенерирована. Я например в последние годы вообще редко пишу модель руками. Хоть модели и не принято называть этим словом, очевидно, это есть самый что ни на есть настоящий DSL в понимании WH и прочих (по крайней мере част этого DSL,остальное привносится средствами языка). Причем этот подход — он оптимален для большинства т.н. "бизнес-задач".
    Социализм — это власть трудящихся и централизованная плановая экономика.
     
    Подождите ...
    Wait...
    Пока на собственное сообщение не было ответов, его можно удалить.