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

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

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

N>Но и там знают, что разработка языков — дело сложное и неблагодарное: выживает 1 из 1000, в лучшем случае.
А откуда, по-твоему, драконщина пошла?
Плюс ты специально, что ли путаешь ДСЛ и ЯОН?
ДСЛ они все выживают в том проекте, для которых их делают. А на большее они обычно и не претендуют.

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

T>>Предполагается что понятия и отношения привезет волшебник в голубом вертолете ?

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

Бизнес(энтерпрайз) он весь в формуле из детской сказки: "иди туда не знаю куда и принеси то не знаю что."

T>>В модель данных.

O> Какую модель? В каком виде представленную?

В

T>>Вопрос был — "зачем" ? Не можешь ответить ?

O> Затем, что иначе это не будет поддежкой CSV. Потому как валидный CSV поломает этот "парсер" запросто.

правильно. Поддержка CSV ради поддержки CSV не нужна. Задача решена — парсер не нужен. А решена ли задача или нет, проверяет и определяет человек из бизнеса.

T>>Недостаточно.
O> Ну, в таком случае надо всех уволить. С волчьим билетом. Потому что дебилы опасны для общества.

Эти дебилы платят тебе и мне(платили) зарплату

T>>Неужели наличие экспертизы в нескольких областях автоматически гарантирует умение дсл и компиляторов ?
O> Да.

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

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

T>>Не хочешь ли ты сказать, что преподаватели сами не понимают этот материал ?
O> Да, именно так.

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

T>>Откуда тогда возьмется та самая простота ?

O> Из жизни, из практики. А преподаватели — это недоумки-теоретики, в основном. Много вы видели в ВУЗах преподавателей с реальным опытом в индустрии? Они не только компиляторов не понимают, они вообще-то ничего не понимают.

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

T>>И как объяснить тот факт, что преподаватели одни и те же, а одни предметы усваиваются хорошо, а другие — плохо ?

O> Что-то я сомневаюсь в том, что что-то там "хорошо" усваивается с помощью преподавателей. Просто по одним предметам студенты догадываются заниматься самостоятельно, решать практические задачи, а по другим боятся (благодаря недоумкам-преподавателям, конечно же). Посмотрите на выпускников ВУЗов — они ни черта вообще не умеют, если у них не было реальной практики.

Да, теория ничего не может там, где практики не накопили достаточно опыта.

Здравствуйте, 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>У меня этого не будет.

Было бы очень интересно посмотреть на существующие наработки.

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

T>>>Не хочешь ли ты сказать, что преподаватели сами не понимают этот материал ?
O>> Да, именно так.

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

Меня более всего удивляет то, что вас этот простой факт удивляет. Преподаватели много в чем ни в зуб ногой. Я бы сказал, почти во всем ни в зуб ногой.

T>>>Откуда тогда возьмется та самая простота ?

O>> Из жизни, из практики. А преподаватели — это недоумки-теоретики, в основном. Много вы видели в ВУЗах преподавателей с реальным опытом в индустрии? Они не только компиляторов не понимают, они вообще-то ничего не понимают.

T>Это потому, что теория идет позади практики.

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

T> Как только практики накопили опыт, формализоваля, подтягиваются теоретики и делают сложное простым, т.к. занимаются распространением опыта. Слабость теоретиков означает что до простоты еще как до небес.

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

O>> Что-то я сомневаюсь в том, что что-то там "хорошо" усваивается с помощью преподавателей. Просто по одним предметам студенты догадываются заниматься самостоятельно, решать практические задачи, а по другим боятся (благодаря недоумкам-преподавателям, конечно же). Посмотрите на выпускников ВУЗов — они ни черта вообще не умеют, если у них не было реальной практики.

T>Да, теория ничего не может там, где практики не накопили достаточно опыта.

Я говорю про даже самые примитивные вещи. Студенты, выпускники CS-специальностей, не умеют программировать. Вообще. На fizz-buzz ломаются. Даже если круглые отличники. Умеют программировать только те, кто подрабатывал налево или программировал что-то реальное just for fun. А они как правило, наоборот, вовсе не отличники, на учебу у них времени маловато остается.

Здравствуйте, 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>Это я так понимаю, ты про себя говоришь?

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

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


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

T>Бизнес(энтерпрайз) он весь в формуле из детской сказки: "иди туда не знаю куда и принеси то не знаю что."

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

O>> Затем, что иначе это не будет поддежкой CSV. Потому как валидный CSV поломает этот "парсер" запросто.

T>правильно. Поддержка CSV ради поддержки CSV не нужна. Задача решена — парсер не нужен. А решена ли задача или нет, проверяет и определяет человек из бизнеса.

И что, у них ни разу не попался CSV, убивающий недоделанный парсер? Так не бывает. Банальный экспорт из Excel (ненависть! ненависть!) генерит CSV, использующие все возможности формата.

T>>>Недостаточно.
O>> Ну, в таком случае надо всех уволить. С волчьим билетом. Потому что дебилы опасны для общества.

T>Эти дебилы платят тебе и мне(платили) зарплату

Программисты? Зарплату? Так не бывает. Они ее получают и тратят, а не платят.

T>>>Неужели наличие экспертизы в нескольких областях автоматически гарантирует умение дсл и компиляторов ?
O>> Да.

T>Неужели ДСЛ это как перк, который качать не надо, но который появляется сам собой случайным образом ?

Это умение уровня "hello, world". Прочитать, один раз сделать и потом всю жизнь пользоваться.

T>Странно, но явидел много специалистов которые прокачаны в разных областях и при этом вообще не знали программирования и это не мешало им работать в софтверных проектах. Пример — сопромат-баллистика-гидроаэродинамика.

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

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

O> Программирование UI никогда проблемой не было. Проблема в его дизайне. А тут DSL не помогут.

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

O> Кроме того, UI это просто неинтересно. Вот никто и не берется за эту чушь.

Это кому как. Кто умеет только мышом кликать в дизайнер, тому UI не будет интересен.

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

T>Практика всегда идет впереди теории. Если у теоретиков представление устаревшее, то это потому, что практики еще не накопили нужное количество опыта и не формализовали этот опыт.
Правильные методики были разработаны в середине 70х.
Но драконисты их затоптали. Инквизиторы хреновы.

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

O> Спасибо, попробую поиграть с разными реализациями.
Можешь начать с моей.
С ней проще всего играться.

WH>>У меня нельзя делать непрямую левую рекурсию.
O> У... Это плохо.
Это не нужно.
На практике левая рекурсия встречается только в операторах.
А там она прямая. В смысле рекурсивно вызывается расширяемое правило.
И именно на такой сценарий все и заточено.
Посмотри на ту грамматику, что я тебе показал.

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

O> Это и пакрат сделает.
Что-то сомневаюсь.

O>Этого мало, для отзывчивости редактора надо быстрее.
Хватает. Если парсить в фоне, то это просто не заметно.

O> Восстановление это еще более интересная тема. Но я привел в пример warning, таких в Clang очень много. Он тем и хорош, что на всякие синтаксические неоднозначности указывать умеет. И возможно это только благодаря страшному, кривому, рукописному парсеру. Очень быстрому, кстати.
Написать правила, которые проходятся по АСТ и дают предупреждения на скользкие места не сложно.
Более того их можно скомпилировать в одну сильно оптимизированную структуру и тогда это будет работать очень быстро.
Скорей всего ручные реализации за таким не угоняться. Я бы точно ручками не смог.

WH>>Так там как раз генератор.
O> Вот и интересно посмотреть, что он генерит.
Очень много говнокода.
Я столько ни прочитать, ни тем более написать не смогу.

O> Как правило — да. Но в случае с парсерами это не всегда возможно (см. выше про clang). Тонкости поведения при ошибках декларативно определять пока никто не научился, так что наилучшим решением представляется как раз тоненькая прослойка над низким уровнем — определяем декларативно все, что можно, а где нельзя, там прозрачно скатываемся на низкий уровень. Это не leaky abstraction, это честно, потому как абстракция парсера от низкого уровня сама не далеко ушла.
Так это все из-за дрконщины. С их подходами действительно ничего такого не сделать.
А если изначально проектировать язык разбора, то можно засунуть в него и язык разбора ошибочного кода.
До реализации у меня это пока не дошло, но мысли уже есть.

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

T>>Поэтому, когда ты говоришь что преподают плохо, это значит, что в голове у преподавателей все еще земля на трёх китах. А это значит, что даже преподаватели еще не доросли до внятного понимания компиляторов.
WH>Но это не значит что тема сложна.

Конечно не значит, но это основной симптом.

WH>Просто они пошли по неверному пути.
WH>Что я и пытаюсь тебе втолковать.

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

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

O>> Неверно. DSL нужны там, где решение с DSL будет проще, понятее не поддерживаемее. Никаких таких "общих случаев" не надо, это совершенно нерелевантная тема.

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

Это опечатка. s/не/и/g

O>> Еще бы сказали, что языки высокого уровня нужны там, где можно закрыть общий случай, а "примитивные частные задачи" можно и на ассемблере нафигачить.

T>Я так и говорю — частные задачи можно и нужно решать на ассемблере. Пример — задачи низкоуровневой оптимизации.

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

O>> А не надо сравнивать столь сложную тему (UI) с такой примитивной и убогой как разработка и реализация языков.

T>Как ты померил сложность разработки и реализации языков ? Наверняка "у меня получилось и следовательно это просто" ?

Сложность это понятие объективное. Не верите мне — спросите у Колмогорова.

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

А для компиляторов надо всего лишь понимать, что такое правила переписывания. Причем всю эту мутную теорию про TRS учить не надо, она нерелевантна. И ведь все этим со школы владеют, алгебру-то все учили, а тут как раз то же самое, переписывание выражений по тупым правилам. И все! Ничего кроме этого во всей этой теме нет. Никаких там "формальных грамматик", которыми на 80% все учебники по компиляторам забиты, никакой такой ерунды просто даром не надо, в реальной практике этому нет места. А есть только выражения и правила их преобразования, то есть то, что понятно любому школьнику.

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

T>>Практика всегда идет впереди теории. Если у теоретиков представление устаревшее, то это потому, что практики еще не накопили нужное количество опыта и не формализовали этот опыт.
WH>Правильные методики были разработаны в середине 70х.

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

WH>Но драконисты их затоптали. Инквизиторы хреновы.

Что лишь подтверждает гниль всей академической системы в целом.

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

T>>Бизнес(энтерпрайз) он весь в формуле из детской сказки: "иди туда не знаю куда и принеси то не знаю что."

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

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

T>>правильно. Поддержка CSV ради поддержки CSV не нужна. Задача решена — парсер не нужен. А решена ли задача или нет, проверяет и определяет человек из бизнеса.

O> И что, у них ни разу не попался CSV, убивающий недоделанный парсер? Так не бывает. Банальный экспорт из Excel (ненависть! ненависть!) генерит CSV, использующие все возможности формата.

Откуда негатив к Экселю ? Покажи пример. Например импортируем из экселя колонки чисел в csv формате. Покажи, как правильный файл повалит string split.

T>>Эти дебилы платят тебе и мне(платили) зарплату

O> Программисты? Зарплату? Так не бывает. Они ее получают и тратят, а не платят.

Эти люди не программисты, они из бизнеса.


T>>Неужели ДСЛ это как перк, который качать не надо, но который появляется сам собой случайным образом ?

O> Это умение уровня "hello, world". Прочитать, один раз сделать и потом всю жизнь пользоваться.

Один мой товарищ так говорит про сопромат У тебя с ним разнци только в том, что у него сопромат, а у тебя дсл+компиляторы.

T>>Странно, но явидел много специалистов которые прокачаны в разных областях и при этом вообще не знали программирования и это не мешало им работать в софтверных проектах. Пример — сопромат-баллистика-гидроаэродинамика.

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

Формализовать область могут и делают это много быстрее программистов. ДСЛ+компиляторы — это епархия программистов.

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

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

Не представляю, как DSL может помочь. Программирование UI тривиально и так, да и DSL-ей и так полно под самые разные UI-задачи. Тот же Tcl/Tk или WPF (Xaml), или, пардон, HTML. Главная же проблема это собственно UI придумать, а ее и на бумажке с карандашом решать можно, или в каком либо Balsamiq Mockups. Когда эта задача решена, программирование становится тривиальным, и в сравнении с дизайном занимает исчезающе малое время, независимо от используемой технологии.

O>> Кроме того, UI это просто неинтересно. Вот никто и не берется за эту чушь.

T>Это кому как. Кто умеет только мышом кликать в дизайнер, тому UI не будет интересен.

Это неинтересно программистам. Это интересно дизайнерам.

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

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

O> Меня более всего удивляет то, что вас этот простой факт удивляет. Преподаватели много в чем ни в зуб ногой. Я бы сказал, почти во всем ни в зуб ногой.

Повезло тебе.

T>>Это потому, что теория идет позади практики.

O> Это только в теории так. А на практике же, и в особенности в случае с компиляторами, теория идет где-то своими, параллельными путями, с практикой вообще не пересекающимися. То есть, между той теорией, которой учат на этом предмете, и реальной практикой, нет вообще абсолютно ничего общего. Ни единой точки соприкосновения.

Это значит практика еще не накопила нужное количетсво опыта.

T>> Как только практики накопили опыт, формализоваля, подтягиваются теоретики и делают сложное простым, т.к. занимаются распространением опыта. Слабость теоретиков означает что до простоты еще как до небес.

O> Нет, это означает только то, что теоретики — дебилы. Только и всего. И что про практику они не знают вообще ничего, плевать они на практику хотели. Они сидят в своих башнях из слоновой кости и строят чисто умозрительные теории, в то время как практики прекрасно обходятся без всей этой мути.

Извиния, я далёк от таких обобщений.

T>>Да, теория ничего не может там, где практики не накопили достаточно опыта.

O> Я говорю про даже самые примитивные вещи. Студенты, выпускники CS-специальностей, не умеют программировать. Вообще. На fizz-buzz ломаются. Даже если круглые отличники. Умеют программировать только те, кто подрабатывал налево или программировал что-то реальное just for fun. А они как правило, наоборот, вовсе не отличники, на учебу у них времени маловато остается.

Мне честно интересно где ты видел таких студентов ?

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

T>>Практика всегда идет впереди теории. Если у теоретиков представление устаревшее, то это потому, что практики еще не накопили нужное количество опыта и не формализовали этот опыт.
WH>Правильные методики были разработаны в середине 70х.
WH>Но драконисты их затоптали. Инквизиторы хреновы.

Затоптали — значит идейка была так себе.

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

O>>> Неверно. DSL нужны там, где решение с DSL будет проще, понятее не поддерживаемее. Никаких таких "общих случаев" не надо, это совершенно нерелевантная тема.
T>>"понятее не поддерживаемее" — могу тлько догадываться что это могло означать.
O> Это опечатка. s/не/и/g

Ну и в качестве примера берем скул и орм

O> Не, эквивалентное по глупости утверждение было бы "все частные задачи надо решать на ассемблере". Кстати, низкоуровневую оптимизацию на ассемблере давно уже никто не делает, в этом нет смысла.

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

T>>Как ты померил сложность разработки и реализации языков ? Наверняка "у меня получилось и следовательно это просто" ?
O> Сложность это понятие объективное. Не верите мне — спросите у Колмогорова.

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

Здравствуйте, 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-генератором, то все понятно, можно любые проверки воткнуть куда угодно в процесс разбора. А вот как их декларативно описать, в самом общем виде?