Здравствуйте, oldjackal, Вы писали:
O> Про "все" я не говорил. Я привожу конкретный факт, в компиляторостроении полностью отсуствует связь между теорией и практикой. Факт объективный и тривиально доказуемый.
Мне правда интересно, т.к. в компиляторостроении я некомпетентен. Ищу жизненные ориентиры. Дракона прочитать так и не сподобился; после вашей рецензии, возможно, уже и не сподоблюсь.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, 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) А. Эйнштейн
Здравствуйте, 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>И получаем всю гибкость без лишнего кода.
Здравствуйте, Sinclair, Вы писали:
S>Не, он не про это. Он про то, что кроме инженеров, у компаний есть и другие источники затрат. Скажем, чтобы твой продукт купили, нужно оплачивать расходы на маркетинг. Руководству компании эффективность труда одного подразделения, пусть даже и самого важного, важна пропорционально доле ФОТ этого подразделения в бюджете компании.
Это не правда.
Если идиоты будут делать продукт в десять раз дольше конкурентов и с кучей багов, то нужен очень суровый маркетинг чтобы этот продукт впарить.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Tanker, Вы писали:
O>> До крайности идиотская аналогия. В геометрии полно всяких там теорем и прочей мути, без которой практические задачи решать невозможно.
T>Любая теорема выводится из трех аксиом с помощью формальной логики. Что бы решать задачи нужно этот навык довести до автоматизма. После этого спокойно можешь утверждать, что на всё хватит логики и трех аксиом
Путь от аксиом до решения задачи может быть очень длинным. Путь от неформального описания языка к компилятору этого языка в другой язык, немного более низкого уровня — тривиальный, в один шаг. Сравнивать нельзя.
O>> А в компиляторах нет ни-че-го. Вообще. Никаких сущностей более высокого уровня чем тривиальные, очевидные переписывания.
T>Напиши книгу, я куплю, почитаю.
Может мне еще и про "2+2=4" и про "Hello, World!" написать? Сопоставимые по сложности темы.
O>> Прекращайте уже спорить о "сложности" темы, про которую вы не знаете ровным счетом ничего. Ознакомьтесь с ней сначала, это легко и просто, а потом уже рассуждайте.
T>Так где же ознакомиться, если весь материал, что есть, по твоим словам негодны
Что, кроме драконьей книги ничего нет? Вранье. Полно отличного материала. Одно из лучших, что я видел:
А так же одна из глав SICP. Он вообще весь малость затянутый, там все мелочи разжевывают многократно, но относительно компиляции они палку не слишком сильно перегибают.
Здравствуйте, Tanker, Вы писали:
T>Оптимизации есть, только высокоуровневые, а что бы не пришлось кодить на ассемблере проще взять готовое ядро которое умеет реалтаймную диспетчеризацию.
Вы опять с умным видом рассуждаете о теме, в которой ни бум-бум. Лучше про "фильтры" и контроллы рассуждайте, это явно ваш конек.
Какая такая "диспетчеризация"? Часто вообще никакой ОС нет, все на голом железе живет. И нужно уместить довольно сложные вычисления в заданное количество миллисекунд, любыми путями. Казалось бы, как раз для ассемблера задача — ан нет, на C быстрее получается. Нельзя человеку соревноваться с современными компиляторами, компиляторы умнее.
T>>>А я говорю про то, что у каждого практика в голове свои уникальные понятия и связи. O>> Чушь. Они настолько примитивные, что никакого расхождения быть не может.
T>И поэтому ты через сообщение записывашь в дураки чуть не всех подряд ?
Не всех. Только дураков. А их очень мало. Это вы тут распинаетесь, что мол все программисты тупые и ничего сложнее string.split никогда не осилят, а у меня есть все основания вам не верить, мне дураки редко попадаются.
O>> Вы хотя бы отдаленное представление имеете о Колмогоровской сложности?
T>Конечно, только я довожу до тебя простую мысль, которая никакого отношения к его сложности не имеет.
Мне абсолютно не интересны ваши нерелевантные простые мысли. Мы обсуждали сравнение сложности двух предметных областей.
Здравствуйте, WolfHound, Вы писали: WH>Это не правда. WH>Если идиоты будут делать продукт в десять раз дольше конкурентов и с кучей багов, то нужен очень суровый маркетинг чтобы этот продукт впарить.
Ты не переживай. Каждый род войск думает, что он главный.
Реальная картина — именно такая, как я сказал. Затраты на разработчиков составляют совсем не такую большую долю в бюджетах компаний, как думают разработчики. Более того, если эта доля велика, то вы недополучаете прибыль, т.к. вложения в sales force окупятся гораздо быстрее вложений в инженерный департамент.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Так вот: они — тоже не работают. Работают парсеры, честно построенные на стейт-машине. У них всё в порядке с быстродействием и надёжностью. Плохо у них только с объёмом ручного кода. DSL для построения парсеров позволил бы значительно сократить время разработки и избежать приседаний с внезапным переходом с CSV на TDV после запуска системы в эксплуатацию в РФ, где десятичной точкой неожиданно является запятая.
Это не совсем так. Точнее, совсем не так. Самые быстрые парсеры получаются ручной оптимизацией рекурсивного ad hoc кода. Посмотрите на clang, на gcc. А вот "построенные на стейт-машине" — это как раз та самая драконовщина, которую надо всячески искоренять.
Здравствуйте, Sinclair, Вы писали:
S>Скажите мне Киса, как художник художнику, вот Аппель — он по делу пишет, или только теоретик? Я имею в виду http://www.cs.princeton.edu/~appel/modern/
Я его не читал. Но судя по первым страницам та же драконщина.
Только менее фундаментальная.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Sinclair, Вы писали:
O>> Про "все" я не говорил. Я привожу конкретный факт, в компиляторостроении полностью отсуствует связь между теорией и практикой. Факт объективный и тривиально доказуемый.
S>Скажите мне Киса, как художник художнику, вот Аппель — он по делу пишет, или только теоретик? Я имею в виду http://www.cs.princeton.edu/~appel/modern/
S>Мне правда интересно, т.к. в компиляторостроении я некомпетентен. Ищу жизненные ориентиры. Дракона прочитать так и не сподобился; после вашей рецензии, возможно, уже и не сподоблюсь.
Аппель на порядки лучше и практичнее драконьей книги. Тоже конечно же хватает лишнего, но большая часть по делу, особенно если про парсинг не читать. Правда, там слишком низкий уровень описывается, для DSL это все просто не нужно (instruction scheduling всякий, алгоритмы раскраски регистров и т.д.). Если хотите писать компилятор Си, то книга годная. Если простые DSL, то где-то треть от книги пригодится.
Здравствуйте, oldjackal, Вы писали: O> Это не совсем так. Точнее, совсем не так. Самые быстрые парсеры получаются ручной оптимизацией рекурсивного ad hoc кода. Посмотрите на clang, на gcc. А вот "построенные на стейт-машине" — это как раз та самая драконовщина, которую надо всячески искоренять.
В общем случае — возможно. Но для разбора CSV быстрее стейт-машины вы в принципе ничего не получите. Уж очень формат простой: там нет никакой рекурсии, состояний всего четыре.
Может, я чего-то не понимаю? Покажите, какой парсер CSV вы имеете в виду.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Ты не переживай. Каждый род войск думает, что он главный. S>Реальная картина — именно такая, как я сказал. Затраты на разработчиков составляют совсем не такую большую долю в бюджетах компаний, как думают разработчики. Более того, если эта доля велика, то вы недополучаете прибыль, т.к. вложения в sales force окупятся гораздо быстрее вложений в инженерный департамент.
Я не про то.
Если программеры выкатили продукт на несколько лет позже конкурентов с кучей багов и тормозов то этому продукту никакие маркетойды не помогут.
Точно также случится, если рынок уже типа занят, но приходит конкурент, который выкатывает фичи в 10 раз быстрее. При этом его продукт не тормозит и не глюкает. А если он еще и импортом данных из монстрика конкурентов озиботится.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, 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. При этом уровень языка в обработчиках состояний может быть сколь угодно высоким.
Здравствуйте, Tanker, Вы писали:
T>>>Это и показывает, что материал сложный. Когда материал простой, все студенты его на раз умеют. WH>>Нет. Это показывает, что студентов учат не правильному материалу. T>Если так, то это значит, что тема компиляторов сложна даже для преподавателей.
Я помню в школе у нас учительница преподавала химию и было все просто и понятно. Потом она переехала, вместо нее пришел новы преподавать, и сразу резко стало сложно и непонятно. Хотя сложность предмета при этом явно не изменилась.
Здравствуйте, 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>Матан — это не теоремы, это исследование ф-ий и их систем.
Он про другой матан.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, WolfHound, Вы писали: WH>Если программеры выкатили продукт на несколько лет позже конкурентов с кучей багов и тормозов то этому продукту никакие маркетойды не помогут.
К сожалению, и это тоже не так.
WH>Точно также случится, если рынок уже типа занят, но приходит конкурент, который выкатывает фичи в 10 раз быстрее. При этом его продукт не тормозит и не глюкает. А если он еще и импортом данных из монстрика конкурентов озиботится.
То ему всё равно потребуются бешеные затраты на маркетинг, т.к. волшебного самораспространения информации не бывает.
Вообще, есть много стратегий поведения на рынке. И совершенствование продукта — вовсе не единственная из них.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, WolfHound, Вы писали:
WH>Если программеры выкатили продукт на несколько лет позже конкурентов с кучей багов и тормозов то этому продукту никакие маркетойды не помогут.
Здравствуйте, Sinclair, Вы писали: S>В общем случае — возможно. Но для разбора CSV быстрее стейт-машины вы в принципе ничего не получите. Уж очень формат простой: там нет никакой рекурсии, состояний всего четыре.
А, ну да, для CSV даже ad hoc будет реализацией той же самой стейт-машины.
Здравствуйте, 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> Что-то я не видел, чтобы гиганты набирали идиотов. Там как раз все сурово. Идиоты в основном кучкуются в больших аутсорсинговых конторах в некоторых всем известных странах.
Не далее чем пару сообщений назад ты назвал людей из конторы-гиганта идиотами. Сейчас ты пошел дальше — назвал тех, кто предлагает всерьез внедрить ДСЛ, идиотами.
Я уже боюсь оставаться на форуме после таких заявлений
Здравствуйте, 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#.
Хотя лично я живу на исходниках. Ибо иногда компилятор правлю.
O> А, для таких warning-ов все еще веселее. В AST нужной информации уже нет. a||b && c||d распарсится в точно такое же AST, что и (a||b) && (c||d).
Нет. Я сохраняю все. Так что скобки в AST останутся.
O> Естественно. Не ясно только, как их в виде правил изобразить-то, без императивного тупого кода.
А в чем проблема? Пример можно?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
