Здравствуйте, 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. Кстати, я буквально сегодня дополнил его описание
новым материалом. Описание все еще не полное и незаконченное, но все же оценить что получится в итоге можно. Предлагаю тебе именно этим и заняться. С удовольствием послушаю взвешенное мнение и конструктивную критику.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
WH>Поставил на сообщение закладку. WH>Буду показывать людям, до чего дракон доводит.
WH>:полностью офигевший смайлик:
Здравствуйте, VladD2, Вы писали:
V>>Ниже в том же посте я более подробно пояснил. Да, м/у лексером и парсером обратная связь через таблицу идентификаторов. Но конфликты упомянутых значков действительно решаются еще ПЕРЕД подачей нетерминалов на парсер. В парсере уже никаких конфликтов. VD>Это не на стадии лексера, а на стадии парсинга все же.
Скорее фильтр м/у лексером и парсером, а к чему его отнести — это уже вопрос вкуса. Я отнес к лексеру лишь потому, что поток лексем — это именно то, что требуется от лексера. Т.е. автоматный блок, бьющий на токены, можно рассматривать как часть лексера. Ведь нам от лексера всегда нужен точный ТИП токена: число (целое/двробное), идентификатор, оператор языка и т.д. Ты решил отнести уточнение типа токена уже к стадии парсинга? Но это столь же с натяжкой, как и относить к лексеру, т.к. магазинный автомат парсера по КС тоже всем этим никак не занят — банально не умеет в рамках КС-грамматики. Описанные действия совершает внешний по отношению к этим двум автоматам механизм, использующий оба автомата лишь как часть своего полного алгоритма.
VD>Другое дело, что они еще хачат лексер.
Ты имеешь ввиду более эффективный ручной разбор комментариев? Это не принципиально ни разу. Я же говорю — рассматривай автоматные блоки как вспомогательные.
VD>Нам это делать ненадо. У нас тупо будут предикаты которые смогут использовать таблицу символов.
Ну т.е. помимо просто генерации двух автоматов — ДКА и магазинного, у вас будет некая инфраструктура, заточенная под специфику разбора грамматик ЯП? Замечательно! Это очень близко к классическому устройству компиляторов.
VD>Ну, лексера у нас отдельного не будет. Все правила носят свои лексеры с собой.
Ты хотел сказать, что отдельного языка описания правил для лексера не будет? Это не одно и то же. И этой идее уже очень много лет. У меня как раз диплом на эту тему был: из одного описания строить одновременно лексер и парсер. Это была вспомогательная утилита для комплекса разработки программ на ассемблере под различные микро-ЭВМ. Утилита нужна была, чтобы кодировать сами эти ассемблеры относительно быстро (парочку полноценных асмов с кое-какой макросистемой я в те года написал. Для 8051 пользовался только своим асмом затем в течении нескольких лет.)
Во-первых, зря ты пытался отвечать на каждое предложение отдельно. Была высказана единое стройное мнение о том, что есть БНФ. Ты пытался назвать их фантазиями, но если это и фантазии, то уж никак не мои. Повторю, БНФ — это просто еще одна разновидность синтаксиса для КС-редукций. Нельзя от уравнений редукций требовать того, что ты требовал, как нельзя от математических уравнений требовать, чтобы они сами себя решали. Это просто декларация условия сущестования решения в обоих случаях. Пара этих фраз никакой не матан, это школьный уровень, когда ребятам объясняют, что же такое уравнение.
V>>Это то, что я уже десяток раз, если не больше, говорил о ПЕГ. VD>Ты много стандартных заблуждений повторяешь. Был бы лучше, если бы ты пытался оспорить и переосмыслить догмы, а не повторял бы их.
Во-вторых, приведенная теорема вовсе не заблуждение, а фундаментальная относительно машины Тьюринга и всего современного ПО, работающего по похожей модели. Именно с помощью этой теоремы функциональщики высмеивают императивщиков, и более ни с помощью какой другой. Просто размусоливают ее своими словами в меру собственной испорченности.
V>>БНФ — декларатив, ПЕГ — императив. VD>Бред, из которого следует, что императивное описание более удобно, компактно и понятно.
Не бред, а аксиома (относительно БНФ и ПЕГ). Зря ты так торопишься отвечать. Императив не обязан иметь бОльшее описание, чем декларатив, это зависит от заточенности языка императива или декларатива под конкретную задачу. Например, ПЕГ вносит упорядоченность в набор правил, в то время как системе уравнений до фени, в каком порядке перечисленны ее правила.
VD>Выразительные возможности ПЕГ и БНФ очень близки. И у обоих есть свои проблемы. Скажем операторые грамматики ни на том, ни на другом по человечески не описать. На то есть нотация с приоритетами или силой связывания. Она затыкает за пояс оба формализма. Потому мы ее и используем.
Да я не против. Единственно портив чего я высказывался, чтобы не сравнивали теплое с зеленым. А вы именно что пытаетесь. Вы разрабатываете язык для описания алгоритма разбирающих грамматик — ну отлично! Особенно если вы сумеете опять же отделить зерна от плевел, т.к. отделить язык описания алгоритма разбора от конкретной реализации "компилятора" этого языка и всей инфраструктуры вокруг. Банально чтобы иметь возможность сохранять будущие инвестиции потенциальной целевой аудитории.
Но пытаться сравнивать аналитическую грамматику с порождающей в кач-ве рекламы этого языка — это ведь подставляться по полной, не находишь? Что о вас люди подумают? Чтобы сравнение было адекватным, надо сравнивать грамматики аналогичных классов.
VD>Я не помню, говорил ли я тебе, что единственная точная специфкация языка — это его компилятор.
Нет, лично мне не говорил, но все и так знают, что в случае Немерле это именно так. Это вовсе не страшно на исследовательской стадии. Но потом, увы, придется отделить язык от его конкретного воплощения. И для отделения нужны будут спецификации на каком-то общепонятном языке. Какие твои предложения относительно языка спецификаций?
VD>Компилятор то нельзя неоднозначным сделать. Ведь он то не может генерировать разные программы по одному коду в зависимости от фазы луны.
Это пять!
Спасибо, поднял настроение.
VD>>>Иначе на них нельзя было бы писать программы. V>>Можно. Но получать на разных реализациях разное поведение. Что и наблюдается периодически.
VD>Нельзя. Разные реализации будут иметь разные спецификации, если их точно описывать.
Вот это и повеселило в предыдущем абзаце. Программисты кодируют программы обычно по спецификациям, а не наоборот. Именно спецификации позволяют работать над кодом совместно. Другого способа совместной разработки просто нет.
VD>В общем, ты снова полез в бессмысленную философию. Рассматривать вопрос багов и глупости нет смысла. Мы же говорим о формальной системе реализации языков. А в ней спецификация и реализация — это одно и то же.
Ес-но не одно и то же. Второе должно стремиться к первому, но ты же настаиваешь, что первое выходит из второго. А это бывает только по результатам исследовательских этапов разработки и никогда более.
VD>>>Так что должно быть однозначным, чтобы можно было разобрать код на ЯП? V>>Спецификация должна быть непротиворечивой. А с помощью БНФ можно описать лишь ничтожную часть этой спецификации — отдельные элементы синтаксиса.
VD>Вывод почти правильный. Только с помощью БНФ вообще не нужно что-то описывать. Нужен другой формализм.
Можно пример?
ИМХО, отдельные элементы синтаксиса прекрасно в БНФ описываются, что вот мол объявление класса выглядит так, а выражение new — эдак. Заметь, связь м/у объявленным классом и аргументом new в синтаксисе КС-грамматики невыразима, зато прекрасно понимается человеком через конкретный идентификатор и область его видимости. Именно поэтому спецификация элементов синтаксиса в БНФ запросто может быть непротиворечива, что оперирует непротиворечивыми элементами языка. А уже как эта непротиворечивость достигается, дело десятое. Например, как описал тут
VD>Вот в задачи N2 и входит создать такой формализм. Формализм мы уже практически придумал. Для парсинга вольфхаунд уже даже написал работающую (хотя и далекую от релиза) реализацию.
Прекрасно. Но сам этот формализм и язык к нему, боюсь, вам придется представить публике в виде БНФ.
Этот болезненный, но необходимый акт и будет ответом на все ваши вопросы относительно роли БНФ в жизни обычного программиста. В том числе вашей.
V>> БНФ себя проявляет во всей красе именно как спецификация грамматики для человека VD>Вот это заблуждение. БНФ просто непригоден для описания формальных спецификаций. Про него просто нужно забыть. Это игрушка для ученых цель которых влепить в дисер красивые диаграммы.
Угу... давай дождемся того момента, когда вам надо будет выкатить свой формализм на публику. Потом вернемся сюда еще раз.
VD>Для практического использования нужен другой формализм. ПЕГ более лучший формализм для практического использования, но и он не идеален. Совмещение ПЕГ-а и TDOP дает практически идеальное решение. Вот оно, доработанное напильником (очень сильно) и используется в N2.
С помощью какого интсрумента единообразно описать всё множество таких языков, каждый из которых является описанием входных правил для своих собственных алгоримов? Ребят, вы же, к сожалению, не понимаете слова оппонента. Когда я говорил о нейтральности или о том, что вы пытаетесь использовать термины не по назначению или пытаетесь создавать сложности в обмене информациями с коллегами — вы даже не понимали, что именно вам говорят. Любое знание, любую информацию вам надо как-то выносить из своего круга в общественность, а для этого действа подойдут только всем понятные нотации и определения. Увы и ах. Даже если вы разработаете другую УНИВЕРСАЛЬНУЮ нотацию (в чем я сильно сомневаюсь) и захотите представить ее общественности именно как замену другим универсальным нотациям, вам придется представить ее публике (хотя бы первый раз) в терминах имеющихся нотаций. Кароч, никуда вы от БНФ не денетесь.
VD>Не говори ерунды. Человеку не нужны ошибочные спецификации (а именно это он получает используя БНФ). Человеку нужны спецификации которые он может понять, и которые позволяют автоматически получить по ним работающее приложение. И это даже не парсер. Ведь человеку нужны: компилятор, документация, поддержка IDE и т.п.
Это ты про ход работы разработчика компилятора говоришь, а пользователю компилятора вообще до фени, как этот компилятор устроен и работает. Ему нужно нейтральное описание любого из языков.
VD>Вот все это и будет давать наше N2. Кстати, я буквально сегодня дополнил его описание
новым материалом. Описание все еще не полное и незаконченное, но все же оценить что получится в итоге можно. Предлагаю тебе именно этим и заняться. С удовольствием послушаю взвешенное мнение и конструктивную критику.
С удовольствием почитаю. Заметь, никто не высказывался против вашей системы, наоборот — многим интересно. Но критика БНФ у вас выходит, мягко говоря, как спорт по прыжкам в сторону.
Здравствуйте, vdimas, Вы писали:
V>Увы и ах. Даже если вы разработаете другую УНИВЕРСАЛЬНУЮ нотацию (в чем я сильно сомневаюсь) и захотите представить ее общественности именно как замену другим универсальным нотациям, вам придется представить ее публике (хотя бы первый раз) в терминах имеющихся нотаций. Кароч, никуда вы от БНФ не денетесь.
Ржу как конь.
И как же сам БНФ то публики представили, когда никакого БНФ еще не было?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Никак. Языки общего назначения не имеют смысла. WH>Чем больше изучаю, тем сильнее утверждаюсь в этом мнении.
Что с тулзами аля ReSharper в случае DSL-ей? Причем у текущей версии ReSharper еще огромные просторы для совершенствования и развития. Поэтому интересно обсуждать с учетом этих потенциальных возможностей развития.
В частности, как в код, написанный на DSL, вносятся изменения?
Здравствуйте, WolfHound, Вы писали:
WH>И как же сам БНФ то публики представили, когда никакого БНФ еще не было?
Через ее строгое отображение на КС-редукции. Ее единственное отличие от них — это удобная запись нескольких редукций через "или" — '|'.
ИМХО, отсюда и бОльшая популярность — из-за более гибкой/компактной записи.
WH>AVK и сам не сможет по тому куску восстановить архитектуру. WH>Он все понимает только по тому, что все спроектировал.
Архитектура банальная — связанные сущности. Набор связей стандартный: 1:1, 1:oo, oo:oo.
Для приведенного куска одни связи, для другого куска будут другие. Конкретные связи определяются прикладной областью, а не платформой. Платформа лишь предоставляет для каждой связи способы ее реализации более одного в общем случае)
I>>Тогда у тебя должен быть ДСЛ для примера AVK. WH>После того как AVK удосужится нормально ответить на вопросы.
А что было непонятно из приведенного отрывка? Спрашивай.
Здравствуйте, Alexander Polyakov, Вы писали:
AP>Что с тулзами аля ReSharper в случае DSL-ей? Причем у текущей версии ReSharper еще огромные просторы для совершенствования и развития. Поэтому интересно обсуждать с учетом этих потенциальных возможностей развития.
Это решаемый вопрос.
AP>В частности, как в код, написанный на DSL, вносятся изменения?
Как и в любой другой код.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, 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 я привел выше.
Ты так и не привел перечень скилов и время на прокачку каждого необходимые для овледения дсл.
Здравствуйте, 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) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
AP>>Что с тулзами аля ReSharper в случае DSL-ей? Причем у текущей версии ReSharper еще огромные просторы для совершенствования и развития. Поэтому интересно обсуждать с учетом этих потенциальных возможностей развития. WH>Это решаемый вопрос.
Как? Опиши основные принципы.
AP>>В частности, как в код, написанный на DSL, вносятся изменения? WH>Как и в любой другой код.
Любой код? Везде же по-разному. Например, я вношу изменения в C#, используя фичи ReSharper-а.
Здравствуйте, Alexander Polyakov, Вы писали:
AP>Как? Опиши основные принципы.
Благодаря тому, что все будет на ДСЛях по ним будет сгенерирован не только компилятор, но и ИДЕ. Это дело техники.
Так же для ИДЕ понадобятся специальные ДСЛ для описания рефакторингов и форматирования.
С другой стороны ИДЕ не будет использовать трансформации кода.
WH>>Как и в любой другой код. AP>Любой код? Везде же по-разному. Например, я вношу изменения в C#, используя фичи ReSharper-а.
А я вношу изменения, в код используя фичи головного мозга.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
AP>>Как? Опиши основные принципы. WH>Благодаря тому, что все будет на ДСЛях по ним будет сгенерирован не только компилятор, но и ИДЕ. Это дело техники. WH>Так же для ИДЕ понадобятся специальные ДСЛ для описания рефакторингов и форматирования. WH>С другой стороны ИДЕ не будет использовать трансформации кода.
Реализация пока не интересует. Опишите основные принципы с точки зрения пользователя.
WH>>>Как и в любой другой код. AP>>Любой код? Везде же по-разному. Например, я вношу изменения в C#, используя фичи ReSharper-а. WH>А я вношу изменения, в код используя фичи головного мозга.
Противопоставляете ReSharper своему головному мозгу? ReSharper довольно дешев. Вам не удалось продать подороже ресурсы своего головного мозга?
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, WolfHound, Вы писали:
WH>>AVK и сам не сможет по тому куску восстановить архитектуру. WH>>Он все понимает только по тому, что все спроектировал.
V>Архитектура банальная — связанные сущности. Набор связей стандартный: 1:1, 1:oo, oo:oo. V>Для приведенного куска одни связи, для другого куска будут другие. Конкретные связи определяются прикладной областью, а не платформой. Платформа лишь предоставляет для каждой связи способы ее реализации более одного в общем случае)
Мозг то связями не компостируй. Опиши словами что происходит и зачем.
V>А что было непонятно из приведенного отрывка? Спрашивай.
В общем — ничего. Давай ты переводчиком поработаешь. Опиши что там происходит и с чем... в деталях.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, 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>Кстати можешь показать код на этом ДСЛ?
WH>Мне даже ничего объяснять не пришлось. Они сами все поняли. WH>Хотя конечно они все могут написать FizzBuzz не приходя в сознание.
А ты не думал, что это и есть основная причина , что они "сами всё поняли" ?
I>>Ты так и не привел перечень скилов и время на прокачку каждого необходимые для овледения дсл. WH>Ох. Учитывая, что у тебя первым в списке идёт то чтобы этим мог пользоваться человек, который не может FizzBuzz это все бесполезно. WH>Да и не слушаешь ты то, что тебе говорят.
Ну, раз у тебя такого списка нет, то можно и закончить.
Здравствуйте, VladD2, Вы писали:
I>>И как ты решил что я это часть твоей ЦА? У меня не вера, а факты, как вы забили на обратную совместимость.
VD>У тебя не вера и не факты. У тебя безответственный треп. И это уже надоело. Толку от общения — 0.
Здравствуйте, Alexander Polyakov, Вы писали:
AP>Реализация пока не интересует. Опишите основные принципы с точки зрения пользователя.
Какие еще принципы?
Не понимаю чего ты хочешь.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
.
