Здравствуйте, oldjackal, Вы писали:
O> Советую прежде чем продолжать этот нелепый спор, где вы заведомо и на все 100% лажаетесь, посмотрите на существующие промышленные компиляторы. Попробуйте найти там хотя бы малюсенький след того, о чем рассуждают дебилы-теоретики. Найдите там хотя бы одну страницу драконьей книги, на которую теоретики молятся. Не найдете! Ни в gcc, ни clang/llvm, ни в HotSpot, ни в CPython, нигде!
Несколько страниц можно найти.
Те, на которых написано про регулярные грамматики.
Эта часть драконщины оказалась полезной.
Страниц 10 из 1000. Остальное навоз.
Они даже в моих генераторах используются.
Ибо конечные автоматы для распознавания токенов рулят.
O> Нет никакой связи между теоретиками и практикой. И не будет никогда. Теоретики не собираются обобщать практический опыт, потому как он и не нуждается в их нелепых услугах, да и противоречит всему тому, во что они слепо верят.
Я тоже немного теоретик. И занимаюсь как раз анализом, обобщением и формализацией реального опыта.
И это нужный процесс. Ибо долбеж парсеов руками на С это мазохизм. Плавали, знаем.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Tanker, Вы писали: T>Откуда негатив к Экселю ? Покажи пример. Например импортируем из экселя колонки чисел в csv формате. Покажи, как правильный файл повалит string split.
Держите:
A,B
"0,77","1,22"
"12,44","5,23"
Удачи со string.split.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, 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, и уже тогда был локальным рекордсменом по "нелинейности" грамматики.
Здравствуйте, Vain, Вы писали: S>>Расшифруйте. V>Ну SQL и базы данных по сложности, к примеру, не уступают C++ и компиляторам.
Не очень понятно, как вы сделали такое сравнение. Но ладно, допустим, что это так.
Этот ваш аргумент — он какое утверждение доказывает или опровергает?
Складывается ощущение, что вы мне пытаетесь доказать, что можно заменить запрос на SQL процедурой на C++, причём последняя будет иметь сопоставимую с запросом сложность. Но этого не может быть, так как это, очевидно, неверно.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, 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. Компилятор/конвертер, который по описанию разметки генерирует код инициализации на хост-языке.
Не только код инициализации, но теперь уже и код интерфейсной логики.)
Здравствуйте, Tanker, Вы писали:
T>Сразу же это когда ? Когда понимания еще нет или когда понимание уже есть ?
Как только возникнет понимание. Хотя бы небольшое понимание. При традиционном подходе в этом случае будет создана небольшая библиотека с набором функций. В нашем случае будет создан небольшой DSL.
По мере дальнейшего освоения специфики будет развиваться либо библиотека, либо DSL.
T>Специфику бизнеса люди годами осваивают и даже десятками лет.
Скорее так: годами и десятками лет пытаются выразить специфику неудобными конструкциями языков общего назначения. Колются, плачут, но продолжают мучиться.
Здравствуйте, 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.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Sinclair, Вы писали:
S>Не-не-не-не-не, Дэвид Блейн. Это получается бесконечная рекурсия. Вот, допустим, в чистом C у нас нет возможности работать с портами 8086. Подключив библиотеку, я могу добавить туда эту возможность через inp() и outp(). S>Но каким образом я напишу эту библиотеку на С? Если бы я мог обращаться к портам на С, мне не потребовалась бы библиотека.
Через встроенный ассемблер, вестимо.
Но вообще, если программа, порождаемая языком, работает сверху ОС, то языку необходимо только умение подключать библиотеки и больше ничего, чтобы превратиться в язык общего назначения. Поэтому строгий DSL никак не сделаешь на основе языков, которые умеют это изкаробки.
Здравствуйте, 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) А. Эйнштейн
Здравствуйте, 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) А. Эйнштейн
Здравствуйте, Tanker, Вы писали:
O> Не, эквивалентное по глупости утверждение было бы "все частные задачи надо решать на ассемблере". Кстати, низкоуровневую оптимизацию на ассемблере давно уже никто не делает, в этом нет смысла.
T>Это ты сильно заблуждаешься. Шейдеры, аппаратные задачи, даже в менеджед приходится спускаться на il.
DirectX запрещает писать шейдеры на ассемблере, начиная с десятой версии — только HLSL.
Здравствуйте, oldjackal, Вы писали:
T>>Повезло тебе.
O> В чем это мне повезло? В том, что пригодного к немедленному употреблению студента днем с огнем не найдешь? Не назвал бы это везением.
T>>Это значит практика еще не накопила нужное количетсво опыта.
O> Поразительная упертость. Включите мозг! Практика лет 60 существует. Компиляторы всех мастей пишут, не напрягаясь. Наплевав на рассуждения теоретиков. Никаких сложностей и неясных моментов в практике нет уже очень давно. А теоретики как рассуждали про "формальные грамматики", как спорили про разницу между LALR(1) и SLR, так и спорят, тогда как абсолютно все практики всегда пишут ad hoc рекурсивные парсеры и знать не желают про баталии дебилов-теоретиков.
Да хоть сто лет, хоть тысячу. Преобразование опыта в теорию годную для распространения невозможно уложить в фиксированые сроки.
O> Советую прежде чем продолжать этот нелепый спор, где вы заведомо и на все 100% лажаетесь, посмотрите на существующие промышленные компиляторы. Попробуйте найти там хотя бы малюсенький след того, о чем рассуждают дебилы-теоретики. Найдите там хотя бы одну страницу драконьей книги, на которую теоретики молятся. Не найдете! Ни в gcc, ни clang/llvm, ни в HotSpot, ни в CPython, нигде!
Зато знания уложеные в гцц невозможно распространять. А книгу драконо — можно, хотя и сложно.
O> Нет никакой связи между теоретиками и практикой. И не будет никогда. Теоретики не собираются обобщать практический опыт, потому как он и не нуждается в их нелепых услугах, да и противоречит всему тому, во что они слепо верят.
Связь есть но не там где ты хочешь видеть.
T>>Извиния, я далёк от таких обобщений.
O> Это от того, что вы далеки от темы и не имеете представления ни о том, что там накалякали теоретики, ни о том, чем реально пользуются практики. Советую ознакомиться, тогда вы будете вынуждены согласиться с моимим обобщениями.
У каждого практика в голове свой набор понятий и связей. Что бы эти понятия стали общими, нужны теоретики.
T>>Мне честно интересно где ты видел таких студентов ?
O> Мне было бы очень интересно узнать, где можно взять других?
На рынке труда, где и все. Может ты погнался за ДСЛ и теперь твоему направлению понизили приоритет, урезали бюджеты и вообще перевели в суппорт ?
Здравствуйте, oldjackal, Вы писали:
T>>Ну и в качестве примера берем скул и орм
O> А не надо их брать. Я же сказал, это абсолютно иная тема, ничего общего с обсуждаемой не имеющая.
А где граница, что можно брать, а что нельзя ?
T>>Это ты сильно заблуждаешься. Шейдеры, аппаратные задачи, даже в менеджед приходится спускаться на il.
O> За последние лет двадцать я ни разу не сталкивался с необходимостью писать что либо на ассемблере. При том, что моя работа как раз тесно связана с HPC.
HPC не часто требует низкоуровневые оптимизации. А вот отрисовка простого контрола очень даже часто.
T>>То есть, два одинаковых бегуна пробегут две разные дистанции за одно и то же время ? Мне кажется Колмгоров такого не говорил.
O> Что-то вы совсем зарапортовались. Что за нелепая аналогия? Я говорю о том, что сложность областей несопоставимая. Компиляторы — это тупо и примитивно, и изучается за несколько часов полностью. UI — гигантских размеров дисциплина, на поверхностное знакомство с которой могут уйти годы.
А я говорю про то, что у каждого практика в голове свои уникальные понятия и связи. Соответсвено что одному просто, то другому будет сложно. А Колмгоров говорил совсем про другое.
Здравствуйте, oldjackal, Вы писали:
O> Про "все" я не говорил. Я привожу конкретный факт, в компиляторостроении полностью отсуствует связь между теорией и практикой. Факт объективный и тривиально доказуемый.
Боюсь тебя огорчить, но доказательств подобного в этом треде я не видел.
T>>Выдай эти два строки текста. Надеюсь их длина как в хорошей программе ограничена сотней символов ?
O> Уже выдал, чуть раньше, про TRS и алгебру. Ничего кроме этого во всей этой области нет. Денотационные и операционные семантики? Чушь, сводится к TRS. Грамматики? Вообще нерелевантно. Оптимизации? На высоких уровнях сводится к правилам и стратегиям переписывания деревьев, на самых суровых низких уровнях (про которые большинству писателей компиляторов и знать-то не надо) немного сложнее, сводится к правилам и стратегиям переписывания DAG-ов.
Ну можно значит расслабиться, вся евклидова геометрия сводится к трём аксиомам и формальной логике. намёк понятен ?
Здравствуйте, 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 и тп тоже один сплошной матан.
Опять промазал. Это прикладная наука формальных языков и их грамматик. Это не матан. Хотя задевает крылом области раздела традиционной математики при введении понятия мощности языков с помощью теоремы Кантора о мощности мн-в, но это так же не входит в матан.
Здравствуйте, Sinclair, Вы писали:
S>Откуда, вы думаете, берутся шестистраничные запросы на SQL? Да ровно оттуда же: нет никаких возможностей по декомпозиции. Приходится всё писать в теле запроса.
Кто мешает написать своё расширение SQL, которое это может? Вы же все-равно запускаете запросы не из некой "стандартной консоли", а из своего приложения, так? Грамматика SQL проста до безобразия и в сети лежит множество готовых парсеров, которые расширить на свои потребности можно с пол-пинка.
Здравствуйте, 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>Сколько я видел тех, о ком ты говоришь весь их код, после увольнения переписывался. Его даже без ДСЛ становилось в разы меньше и все баги пропадали.
Не всегда есть возможность нанять тех, кого хочется. Квалифицированых специалистов на порядки меньше чем проектов. Да и квалифицированые часто ничего кроме вселенских проблем не хотят решать
Здравствуйте, 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) А. Эйнштейн
