Re[21]: JRuby, RubyCLR, IronPython - зачем?
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 01.11.06 16:43
Оценка:
Здравствуйте, vdimas, Вы писали:

VD>>Более того любой НКА можно переписать в ДКА.


V>Как это любой? Не любой, а приводимый к ДКА.


Нетрудно доказать, что любой НКА приводится к ДКА.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[15]: JRuby, RubyCLR, IronPython - зачем?
От: WolfHound  
Дата: 01.11.06 16:59
Оценка:
Здравствуйте, konsoletyper, Вы писали:

K>Руками они пишутся день-два. Файл с описанием регулярной грамматики пишется за час-полтора (учитывая исправление граблей). Спрашивается, зачем тратить лишнее время?

На правильных языках гораздо быстрее.

K>А какие есть тулзы для генерации кода парсеров? А то я что-то кроме как о вездесущем yacc ничего не слышал. Вроде есть что-то yacc-подобное в VS SDK. Но мне сам подход yacc не нравится. Очень уж коряво выглядит БНФ + код, всё это тяжеловато сопровождать. Почему бы не сделать генератор именно магазинного КА, а мы просто пишем парсер, который есть удобная обёртка над этим КА? Уж всё проще написать один небольшой декларативный файлик, по которому выйдет готовый КА, чем весь рекурсивный спуск ручками прописывать.

Если в языке есть паттерн-матчинг и алгебраические типы то внешние тулзы нафиг не уперлись ибо ручками проще и качественней получается. Проверено.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[15]: JRuby, RubyCLR, IronPython - зачем?
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.11.06 17:11
Оценка:
Здравствуйте, konsoletyper, Вы писали:

K>Руками они пишутся день-два. Файл с описанием регулярной грамматики пишется за час-полтора (учитывая исправление граблей). Спрашивается, зачем тратить лишнее время?


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

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

Еще один бенефит — отсуствие зависимотей. Ведь генератор лексаров прийдется за собой таскать. Если в нем баги их еще править нужно...

В общем, зачастую в этом есть свой резон.

K>А какие есть тулзы для генерации кода парсеров?


Если кратко, то их море но 99% дерьмо еще то. А хорошие генераторы платные. Тот же GLR я так и не нашел в бесплатном варианте.

K> А то я что-то кроме как о вездесущем yacc ничего не слышал. Вроде есть что-то yacc-подобное в VS SDK.


В VS SDK ничего нет. Они использовали (точнее предлагали использовать) Бизон. Это несколько расширенный клон Яка. Есть еще КокаР и ANTLR. Последний пожалуй самый навороченный, но и самый безолаберно написанный.

K> Но мне сам подход yacc не нравится. Очень уж коряво выглядит БНФ + код, всё это тяжеловато сопровождать. Почему бы не сделать генератор именно магазинного КА, а мы просто пишем парсер, который есть удобная обёртка над этим КА?


Яки и порождают магазинный автомат. Дерьмовый правада. В общем, я не понимаю о чем идет речь. Если не наравится то что код семантики встраивается по месту, то можно поглядеть на ANTLR. Там есть возможность декларативного построения AST.

K> Уж всё проще написать один небольшой декларативный файлик, по которому выйдет готовый КА, чем весь рекурсивный спуск ручками прописывать.


Так и делается. Только что толку с голого разбора? Разбор делается ради каких-то действий. Вот именно эти действия и помещаются в файл с декларативной грамматикой. Естественно они ухудщают читаемость, но как от этого избавиться не ясно. К ANTLR делается визуальная среда где сама грамматика отображается в виде графического дерева. Плюс рефакторинг и отладчик. Если одни доведут это дело до работоспособного состояния, то будет удобно.

ЗЫ

Вот только оно "но". Я сейчас использую язык Nemerle который повзоляет расширять свой синтаксис. И что-то не тянет писать какие-то там парсеры. Расширяемость языка позволяет делать очень многое и на значительно более высоком уровне нежели создание языков с помощью посторителей парсеров.

Так что возможно, что язык с изменяющимся синтаксисом — это отличная замена парсерам.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: JRuby, RubyCLR, IronPython - зачем?
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 02.11.06 05:33
Оценка:
Здравствуйте, VladD2, Вы писали:

K>> Но мне сам подход yacc не нравится. Очень уж коряво выглядит БНФ + код, всё это тяжеловато сопровождать. Почему бы не сделать генератор именно магазинного КА, а мы просто пишем парсер, который есть удобная обёртка над этим КА?


VD>Яки и порождают магазинный автомат. Дерьмовый правада. В общем, я не понимаю о чем идет речь. Если не наравится то что код семантики встраивается по месту, то можно поглядеть на ANTLR. Там есть возможность декларативного построения AST.


Мне в yacc-образном пожходе не нравится то, что код именно встраивается. Почему бы по БНФ не строить автомат, который посылает сообщения, о том, что найден очередной нетерминал, а тот, кто ити сообщения принимает, уже и строит AST.

VD>ЗЫ


VD>Вот только оно "но". Я сейчас использую язык Nemerle который повзоляет расширять свой синтаксис. И что-то не тянет писать какие-то там парсеры. Расширяемость языка позволяет делать очень многое и на значительно более высоком уровне нежели создание языков с помощью посторителей парсеров.


VD>Так что возможно, что язык с изменяющимся синтаксисом — это отличная замена парсерам.


А не нужен компилятор для очередного мега-языка. Нужна подсветка, хинты и autocompletion для уже существующих языков, причём подсветку хотелось бы видеть как в VS или Eclipse — чтобы, скажем, имена типов подсвечивались.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[16]: JRuby, RubyCLR, IronPython - зачем?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 02.11.06 08:50
Оценка:
Здравствуйте, VladD2, Вы писали:

K>> А то я что-то кроме как о вездесущем yacc ничего не слышал. Вроде есть что-то yacc-подобное в VS SDK.


VD>В VS SDK ничего нет.


Начиная с августа есть. См. файлики MPLex.exe и MPPG.exe. И если первый еще можно к чему нить приспособить, то второй это yet another yacc (все тот же LALR(1)). На сегодняшний момент это выглядит, ИМХО, моветоном.
... << RSDN@Home 1.2.0 alpha rev. 642>>
AVK Blog
Re[5]: JRuby, RubyCLR, IronPython - зачем?
От: vdimas Россия  
Дата: 02.11.06 08:51
Оценка: 22 (3) +2
Здравствуйте, AndrewVK, Вы писали:

V>>Не, нужно что-то типа среды смолтолка, чтобы запускать отдельные методы и ф-ии прямо из студии. Кстати, это все уже прекрасно работает в студии для VB.Net. Единственное неудобство — надо компилировать код после изменения. Зато потом играйся не хочу.


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


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

Сейчас для "игр" и исследования/сравнения технологий/библиотек мы используем NUnit, но это все суррогат и лишние приседания. Просто одно время сидел на Fort-е, после этого прекрасно понимаю смолтокеров, которые не нахвалят свой язык, хотя хвалить надо среду разработки и принятый подход, если быть объективным (просто технология языка позволяет легко организовать подбный подход). В общем, написал метод, поиграл с ним вдоволь тут же, отладил, пошел дальше и забыл навсегда — это надо прочувствовать. Такой скорости разработки качественного кода в компилируемых средах не получается, не взирая ни на какой опыт. Например на С++ я мог неделями только писать код даже не компилируя (если участвует большая система взаимодействующих типов). В C# этот срок сократился, но похожие преценденты были, т.е. несколько дней писанины без отладки. Потом, ессно, возврат к подробностям несколькодневной давности.

Самое сложное в нашей работе — это не технически сложности (говорю о себе). Самое сложное, от чего можно потерять интерес к концу дня — это многократное переключение внимания на абсолютно несвязанные вещи. Вникать в проблемки даже мелкие почти всегда необходимо весьма глубоко, т.е. надо на чем-то сосредотачиваться. Чем лучше сосредоточишься, т.е. чем больше попытаешься удержать в голове прямо или косвенно связанных моментов относительно целевого, тем качествене получится итоговый код и меньше вероятность, что потом опять к этому участку вернешься. Это не проблема до тех пор, пока в течении дня не приходится сосредотачиваться на десятках несвязанных моментов, прыгая по ним аки кенгуру. А в случае итеративной разработки-отладки ты сосредотачиваешься на одной мини-задачке, решаешь ее так, чтобы потом никогда к ней не возвращатья. От того и скорость и качество.

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

-------------
Заметил. Почти всегда, если язык и технология позволяет, в среды разработки обязательно вставляют итерактивные возможности. Случайно?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[10]: JRuby, RubyCLR, IronPython - зачем?
От: vdimas Россия  
Дата: 02.11.06 08:51
Оценка:
Здравствуйте, Mamut, Вы писали:


M>Тут главный вопрос — как они программируют на JScript. 99% nt[? кого я знаю используют его в сугубо процедурном стиле


Для отчетов только так и будут использовать.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[22]: JRuby, RubyCLR, IronPython - зачем?
От: vdimas Россия  
Дата: 02.11.06 08:51
Оценка:
Здравствуйте, konsoletyper, Вы писали:


K>Нетрудно доказать, что любой НКА приводится к ДКА.


Докажи. Только сначала ознакомься с алгоритмами приведения НКА к ДКА, и объясни, откуда в этих алгоритмах такая хрень как конфликт состояний (сам недавно писал реализацию одного из алгоритмов, разумеется выбрасываю исключение, если конфликт состояний).

Вот тебе простейший НКА:
S0, S1, S2.
Состояния S1 и S2 конечные, имеют различные выходные значения.

Граф:
S0 -- 'a' --> S1
S0 -- 'a' --> S2

Давай, доказывай.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[6]: JRuby, RubyCLR, IronPython - зачем?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 02.11.06 09:12
Оценка:
Здравствуйте, vdimas, Вы писали:

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


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


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

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


Надо добавлять "у меня".

V>В C# этот срок сократился, но похожие преценденты были, т.е. несколько дней писанины без отладки.


Ну и что?

V> Потом, ессно, возврат к подробностям несколькодневной давности.


Совершенно неестественно.

V>И еще. Непередаваемое чувство уверенности в результате своего труда, если был возможен описанный подход.


Лично мне такие "подпорки" не нужны.

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


Технология дотнета это позволяла с рождения. Однако таких возможностей в нормальном виде нет до сих пор и никакого движения в Оркасе в этом направлении я тоже не вижу.
... << RSDN@Home 1.2.0 alpha rev. 642>>
AVK Blog
Re[6]: JRuby, RubyCLR, IronPython - зачем?
От: WolfHound  
Дата: 02.11.06 09:52
Оценка:
Здравствуйте, vdimas, Вы писали:

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

Интересно почему у меня на С++ также получается? Писал пару недель без компиляции... запускаю... работает... В худшем случае ловлю пару исключений причину которых устраняю в течении нескольких минут...
Я после этих двух недель долбежки кода с ошибками компиляции дольше разбираюсь... по ходу дела рефакторить приходится..., а ReSharper'а для С++ нету... вот опечатки и накапливаются.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[17]: JRuby, RubyCLR, IronPython - зачем?
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.11.06 10:02
Оценка:
Здравствуйте, konsoletyper, Вы писали:

K>Мне в yacc-образном пожходе не нравится то, что код именно встраивается. Почему бы по БНФ не строить автомат, который посылает сообщения, о том, что найден очередной нетерминал, а тот, кто ити сообщения принимает, уже и строит AST.


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

K>А не нужен компилятор для очередного мега-языка. Нужна подсветка, хинты и autocompletion для уже существующих языков, причём подсветку хотелось бы видеть как в VS или Eclipse — чтобы, скажем, имена типов подсвечивались.


Очередного? А где конкуренты то?
А над подсветкой и всем остальным мы уже работаем. И уже виден очевидный прогресс.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: JRuby, RubyCLR, IronPython - зачем?
От: Gajdalager Украина  
Дата: 02.11.06 10:16
Оценка:
Здравствуйте, VladD2, Вы писали:

K>>А не нужен компилятор для очередного мега-языка. Нужна подсветка, хинты и autocompletion для уже существующих языков, причём подсветку хотелось бы видеть как в VS или Eclipse — чтобы, скажем, имена типов подсвечивались.


VD>Очередного? А где конкуренты то?

VD>А над подсветкой и всем остальным мы уже работаем. И уже виден очевидный прогресс.

Ну... А это?... Правда, макросов нет и хорошей IDE....
Re[7]: JRuby, RubyCLR, IronPython - зачем?
От: FR  
Дата: 02.11.06 10:17
Оценка: +4
Здравствуйте, WolfHound, Вы писали:

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


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

WH>Интересно почему у меня на С++ также получается? Писал пару недель без компиляции... запускаю... работает... В худшем случае ловлю пару исключений причину которых устраняю в течении нескольких минут...
WH>Я после этих двух недель долбежки кода с ошибками компиляции дольше разбираюсь... по ходу дела рефакторить приходится..., а ReSharper'а для С++ нету... вот опечатки и накапливаются.

Я конечно понимаю что вы с vdimas монстры, но все равно мне очень тяжело представить что именно можно в течени двух недель без компиляции вколачивать, может подкинете примерчики?
Re[23]: JRuby, RubyCLR, IronPython - зачем?
От: Centaur Россия  
Дата: 02.11.06 10:39
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Вот тебе простейший НКА:

V>S0, S1, S2.
V>Состояния S1 и S2 конечные, имеют различные выходные значения.

Недетерминированный конечный автомат определяется непустым конечным множеством состояний S, непустым конечным алфавитом входных символов X, мультифункцией перехода T : (S, X union { '' }) => 2^S, начальным состоянием s_0 из S, и подмножеством конечных состояний F в S. Выходные значения — это какое-то неизвестное науке расширение.

Детерминированный конечный автомат задаётся непустым конечным множеством состояний S, непустым конечным алфавитом входных символов X, функцией перехода T : (S, X) => S, начальным состоянием s_0 из S, и подмножеством конечных состояний F в S.

V>Граф:

V>S0 -- 'a' --> S1
V>S0 -- 'a' --> S2

То есть:
S = { S0, S1, S2 }
X = { 'a' }
T(S0, 'a') = { S1, S2 }
T(S0, '') = T(S1, _) = T(S2, _) = { }
s_0 = S0
F = { S1, S2 }

V>Давай, доказывай.


Сначала исходный НКА приводится к виду без e-правил (где T(s1, '') непусто). Предлагаемый НКА уже имеет такой вид, так что этот шаг пропустим.

X' = X = { 'a' }
S' = 2^S = { S'e = {}, S'0 = {S0}, S'1 = {S1}, S'2 = {S2}, S'01 = {S0, S1}, S'02 = {S0, S2}, S'12 = {S1, S2}, S'012 = {S0, S1, S2} }
s'_0 = { s_0 } = S'0
F' = { s' in 2^S | (forall s in s')(s in F) } = { S'12 }
T'(s', x) = union { T(s, x) | s in s' }
T'(S'0, 'a') = T'(S'01, 'a') = T'(S'02, 'a') = T'(S'012, 'a') = S'12
T'(S'e, 'a') = T'(S'1, 'a') = T'(S'2, 'a') = T'(S'12, 'a') = S'e

или в виде графа, исключая недостижимые состояния:

S'0 -- 'a' --> (S'12) -- 'a' --> S'e <='a'
Re[19]: JRuby, RubyCLR, IronPython - зачем?
От: Курилка Россия http://kirya.narod.ru/
Дата: 02.11.06 11:00
Оценка:
Здравствуйте, Gajdalager, Вы писали:

G>Ну... А это?... Правда, макросов нет и хорошей IDE....


Эклипс не катит?
Re[7]: JRuby, RubyCLR, IronPython - зачем?
От: Андрей Хропов Россия  
Дата: 02.11.06 11:02
Оценка: +1
Здравствуйте, WolfHound, Вы писали:

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


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

WH>Интересно почему у меня на С++ также получается? Писал пару недель без компиляции... запускаю... работает... В худшем случае ловлю пару исключений причину которых устраняю в течении нескольких минут...
WH>Я после этих двух недель долбежки кода с ошибками компиляции дольше разбираюсь... по ходу дела рефакторить приходится..., а ReSharper'а для С++ нету... вот опечатки и накапливаются.

По-моему писать две недели без запуска — порочный подход.
Не только орфография, но при тестировании выявятся и функциональные, и архитектурные просчеты.
А за 2 недели можно зайти довольно далеко.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[20]: JRuby, RubyCLR, IronPython - зачем?
От: Gajdalager Украина  
Дата: 02.11.06 11:06
Оценка:
Здравствуйте, Курилка, Вы писали:

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


G>>Ну... А это?... Правда, макросов нет и хорошей IDE....


К>Эклипс не катит?

Автодополнения в последней версии нет, и (по крайней мере, у меня), колорайзер запаздывает в смысле секунд 30-40 пишешь серый код, а потом он весь разз! и подкрасился Я б, конечно, сам сделал — но не умею
Re[8]: JRuby, RubyCLR, IronPython - зачем?
От: WolfHound  
Дата: 02.11.06 11:41
Оценка: +1
Здравствуйте, Андрей Хропов, Вы писали:

АХ>По-моему писать две недели без запуска — порочный подход.

АХ>Не только орфография,
А как скомпилировать усли у меня классов и методов не хватает? Причем как эти методы и классы должны выглядить до того как их напишешь вобщемто не понятно.
Рисовать диаграммы классов не предлагать. Оно не работает.
АХ>но при тестировании выявятся и функциональные, и архитектурные просчеты.
Выявляются они при уточнении требований. А требования уточнить без соседей которым нужен полнофункциональный модуль уточнить не получится.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[8]: JRuby, RubyCLR, IronPython - зачем?
От: IT Россия linq2db.com
Дата: 02.11.06 13:28
Оценка: +1
Здравствуйте, FR, Вы писали:

FR>Я конечно понимаю что вы с vdimas монстры


И не говори. Я без компиляции и трёх строчек не напишу Оно у меня фактически вместо кнопки Save, а сохраняюсь я часто.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[9]: JRuby, RubyCLR, IronPython - зачем?
От: IT Россия linq2db.com
Дата: 02.11.06 13:28
Оценка: +2
Здравствуйте, WolfHound, Вы писали:

WH>А как скомпилировать усли у меня классов и методов не хватает?


Всё таки хотелось бы пример, а то без него в недели слабо верится.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.