Здравствуйте, frogkiller, Вы писали:
F>И я до сих пор не понял, кто будет основным потребителем твоей супер-IDE. Вряд ли программисты в классическом понимании, потому что твой очень абстрактный подход всегда будет проигрывать частным специализированным решениям в прикладных областях (ну не поверю я, что с его помощью можно сделать конкурентно способный кросплатформенный веб-сервер или хороший 3D-шутер). Скриптописатели бизнес-логики? аналитики? системные архитекторы? менеджеры? — у каждой из этих специальностей есть свои особенности и пожелания к инструментам. Без них даже самый замечательный в теории проект обречён на неудачу.
Цитатка "на злобу дня":
"The time to think about who it will be sold to and how it will be sold to them is BEFORE the product is built, not afterward."
(c) Dan Kennedy
Комментировать, думаю, излишне...
Re[7]: Программирование, от монолога к диалогу с компьютером
Здравствуйте, Курилка, Вы писали:
К>Цитатка "на злобу дня":
К>
К>"The time to think about who it will be sold to and how it will be sold to them is BEFORE the product is built, not afterward."
К>(c) Dan Kennedy
К>Комментировать, думаю, излишне...
Есть комментарий, есть.
Я пытаюсь себе представить Амундсена, думающего кому и как продать свою поездку на полюс, или Эйнштейна в размышлениях о продаже соотношения E=mc2.
И ведь прибыльную вещь придумал, ядрёную бомбу, можно сказать.
Здравствуйте, mkizub, Вы писали:
M>Конечно, лазить по пунктам меню — вещь утомительная. Но нужная, когда ты не знаешь какую клавишу нажать, чтоб это действие было выполнено. M>Можно писать коротко — "создайте новый узел", и пусть читатель догадывается, как его создать. Можно написать "нажмите Ctrl+N или выберите в меню Edit->New node для создания нового узла". Так будет длинно, и туманно — где-то лазить, что-то нажимать, почему компьютер сам не догадается, что мне нужно создать новый узел... M>Удобно в нём редактировать. Я же редактирую, мне удобно.
Ну, это твой продукт, как говорится, "хозяин — барин". Только, мне кажется, что так ты "слона и не продашь".
F>>И я до сих пор не понял, кто будет основным потребителем твоей супер-IDE. Вряд ли программисты в классическом понимании, потому что твой очень абстрактный подход всегда будет проигрывать частным специализированным решениям в прикладных областях (ну не поверю я, что с его помощью можно сделать конкурентно способный кросплатформенный веб-сервер или хороший 3D-шутер).
M>Вот именно, кросплатформенный веб-сервер, хороший 3D-шутер, и многое другое. То, что ты в этом не веришь сейчас, не значит, что это не так. M>Что нужно для хорошего шутера? Красивая графика — а она делается на специализированном языке для шейдеров. Хороший скрипт (сценарий), чтоб было багов поменьше и интеллекта поболее. Значит пишут свой скриптовый язык программирования, ориентированный на данный жанр и даже на данную игру, и пишут на нём код. Много кода. Мегабайты скриптового кода. Ты думаешь, можно написать мегабайты скриптового кода быстро и без багов? Не получается. Пока это пара файлов — всё отлично. А как только пошёл большой код — баг на баге. Вот и делают игрушки 5 лет, вместо 1 года. M>Или ты думаешь, что кросс-платформенный веб-сервер можно делать без кросс-платформенных абстракций? Нельзя. Можно взять яву, которая и будет кросс-платформенной абстракцией. Хорошо, если она приспособлена для изготовления веб-серверов, а если нет? Даже понятие файла, уж где взять более общее и стандартное — и то разное в разных операционках, когда доходит до деталей реализации быстрого доступа.
Ну, я не очень хорошо знаю, как пишутся игрушки, но вполне представляю, как создаются сервера — кроссплатформенные, высоконагруженные, общего назначения и специализироанные — разные. Выделение семантических абстракций будет идти снизу вверх, а не наоборот, что означает, что твой SymADE будет применяться пост-фактум (если вообще будет) для документирования.
F>>И наконец, о форме представления данных — да, в теории прямая работа с деревом может давать определённые преимущества. Но на практике мне предложенный в твоём демо-описании способ кажется очень неудобным. Мне кажется, что мышь и клавиатура — не самые подходящие для этого инструменты. И настоящий вопрос на 1M$ — на самом деле больше дизайнерский, чем научный — придумать устройство ввода, удобное для работы с графическим представлением иерархической структуры данных.
M>Мозг M>Научиться думать картинками. M>Когда ты знаешь, что писать — уже без разницы, текст это или дерево, сколько нажатий кнопок на это нужно — только бы оно позволило это написать.
По такой логике получается, что если научиться думать картинками — то новый IDE уже не нужен, а если не научиться, то ещё не нужен.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Re[7]: Программирование, от монолога к диалогу с компьютером
M>Что нужно для хорошего шутера? Красивая графика — а она делается на специализированном языке для шейдеров.
Уважаю людей, которые разбираются практически во всём. Очень уважаю.
Вот ты, например, помимо знаний о скорости работы с неизменяемыми данными, знаешь ещё, как устроены игры, в частности, графический движок. Знаешь, что красивая графика делается шейдерами. Это очень, очень сильно.
M>Хороший скрипт (сценарий), чтоб было багов поменьше и интеллекта поболее.
Интеллект скриптами — это не менее сильно. Это в какой такой игре интеллект скриптами делается?
M>Значит пишут свой скриптовый язык программирования, ориентированный на данный жанр и даже на данную игру, и пишут на нём код. Много кода. Мегабайты скриптового кода. Ты думаешь, можно написать мегабайты скриптового кода быстро и без багов? Не получается. Пока это пара файлов — всё отлично. А как только пошёл большой код — баг на баге. Вот и делают игрушки 5 лет, вместо 1 года.
Откуда ты про это знаешь? Когда ты успел поучаствовать в создании игр? Вроде, всё время SymADE пишешь, а тут вона какие знания.
Если серьёзно, то вот они, факты: Half-life 2 — ~7 программистов, больше 80 художников и проектировщиков уровней, Unreal 3, средняя игра — 10 программистов, 20 художников.
Интеллект делается с помощью указания точек на уровне, с графом перехода. F.E.A.R., HL, HL2, Halo...
Сидят люди и расставляют точки. А другие люди берут уровень и играют, а потом по ощущениям игроков точки расставляют заново. и так со всеми артефактми игры — графикой, звуком, настроением врагов... Вот поэтому игры так долго и делаются. Программирование там не очень сильно влияет.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[8]: Программирование, от монолога к диалогу с компьютером
Здравствуйте, mkizub, Вы писали:
M>Есть комментарий, есть. M>Я пытаюсь себе представить Амундсена, думающего кому и как продать свою поездку на полюс, или Эйнштейна в размышлениях о продаже соотношения E=mc2. M>И ведь прибыльную вещь придумал, ядрёную бомбу, можно сказать.
Корабли бороздят просторы...
Уже не оригинально
P.S. Комментировать больше не буду, ибо не вижу смысла.
Re[8]: Программирование, от монолога к диалогу с компьютером
Здравствуйте, thesz, Вы писали:
T>Откуда ты про это знаешь? Когда ты успел поучаствовать в создании игр? Вроде, всё время SymADE пишешь, а тут вона какие знания.
T>Если серьёзно, то вот они, факты: Half-life 2 — ~7 программистов, больше 80 художников и проектировщиков уровней, Unreal 3, средняя игра — 10 программистов, 20 художников.
T>Статистика Unreal 3 Engine. 250RLOC C++ и 250KLOC скриптов/C++.
T>"Может быть, поможет быть..." (C)
Не может быть, а точно. Вот эти, которых ты в художники записал, они скрипты и лабают. А те, которые программисты — движок делают.
В Unreal 3 так много C++ кода потому, что они же этот код и пишут. Они пишут и продают свой движок. А остальные покупают, делают свои уровни, и у них С++ может вообще почти не быть, одни скрипты.
Шутеры — это специфическая игродельная область с точки зрения интеллекта и использования скриптов. Там народ тусуется, который тащщится, когда патронов на уровень выдают по количеству монстров. Когда эта аркада окончательно надоедает — играются в стенка-на-стенку. С живыми противниками. Поскольку интеллект у монстров на нуле.
Посмотреть на количество скриптового кода в RPG и симуляторах вроде X3 Reunion не хочешь?
T>>Откуда ты про это знаешь? Когда ты успел поучаствовать в создании игр? Вроде, всё время SymADE пишешь, а тут вона какие знания. T>>Если серьёзно, то вот они, факты: Half-life 2 — ~7 программистов, больше 80 художников и проектировщиков уровней, Unreal 3, средняя игра — 10 программистов, 20 художников. T>>Статистика Unreal 3 Engine. 250RLOC C++ и 250KLOC скриптов/C++. T>>"Может быть, поможет быть..." (C) M>Не может быть, а точно. Вот эти, которых ты в художники записал, они скрипты и лабают. А те, которые программисты — движок делают.
Ты покажи, куда складывают код эти 80+ "которых я в художники записал" (а на самом деле в они титрах так обозначены).
Когда по сети ходили то, что выдавали за исходники HL2, ничего подобного я там не видел.
В той игре, что делалась с моим участием (недолгим, правда), тоже скриптов AI, как таковых, не было. Поскольку программист ИИ сидел рядом, я был в курсе. Был "думатель" с системой оценок и был "делатель", выдававший команды управляющим органам. Конфигурация ИИ была развесистой, но декларативной — скриптов "сделай так" не было.
M>В Unreal 3 так много C++ кода потому, что они же этот код и пишут. Они пишут и продают свой движок. А остальные покупают, делают свои уровни, и у них С++ может вообще почти не быть, одни скрипты.
Там про количество кода средней Unreal3 игры. Не самого Unreal3.
M>Шутеры — это специфическая игродельная область с точки зрения интеллекта и использования скриптов. Там народ тусуется, который тащщится, когда патронов на уровень выдают по количеству монстров. Когда эта аркада окончательно надоедает — играются в стенка-на-стенку. С живыми противниками. Поскольку интеллект у монстров на нуле.
Рассказы про F.E.A.R. это не подтверждают. ИИ в нём сделан всё теми же точками на уровне, но он не выглядит, как "на нуле". Есть обходные маневры, подавление противника огнём, отвлекающие маневры... Много, чего есть.
M>Посмотреть на количество скриптового кода в RPG и симуляторах вроде X3 Reunion не хочешь?
Покажи.
(про себя замечу, что шутеры не я начал, и на RPG не я свернул
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[10]: Программирование, от монолога к диалогу с компьютеро
Здравствуйте, thesz, Вы писали:
T>Ты покажи, куда складывают код эти 80+ "которых я в художники записал" (а на самом деле в они титрах так обозначены).
Как куда? В UnrealScript или аналогичный DSL.
T>Когда по сети ходили то, что выдавали за исходники HL2, ничего подобного я там не видел.
Что, движок утянули, а саму игру нет? Или ты мне хочешь сказать, что они всю логику игры, весь сценарий — в C++ закодировали?
T>В той игре, что делалась с моим участием (недолгим, правда), тоже скриптов AI, как таковых, не было. Поскольку программист ИИ сидел рядом, я был в курсе. Был "думатель" с системой оценок и был "делатель", выдававший команды управляющим органам. Конфигурация ИИ была развесистой, но декларативной — скриптов "сделай так" не было.
Ты хотел сказать "императивной"? Потому как конфигурация есть декларативная программа.
M>>В Unreal 3 так много C++ кода потому, что они же этот код и пишут. Они пишут и продают свой движок. А остальные покупают, делают свои уровни, и у них С++ может вообще почти не быть, одни скрипты.
T>Там про количество кода средней Unreal3 игры. Не самого Unreal3.
Ну могебыть. Ещё бы они привели разбивку этих 250КLOC на С++ и скриптовый код.
T>Рассказы про F.E.A.R. это не подтверждают. ИИ в нём сделан всё теми же точками на уровне, но он не выглядит, как "на нуле". Есть обходные маневры, подавление противника огнём, отвлекающие маневры... Много, чего есть.
Ну и? Сделали шутер с хорошим AI. Одни-два из сотни. С собственным AI движком, и разумеется, с собственным DSL для этого AI. Могли бы взять MPS/SymADE/etc и сократить себе часть работы по созданию DSL-я и редактора к нему.
M>>Посмотреть на количество скриптового кода в RPG и симуляторах вроде X3 Reunion не хочешь?
T>Покажи.
Gothic 2, больше 8мег / 250KLOC скриптов (исходники доступны в мод-паке).
Всякие Oblivion, X3 и прочие должны иметь ещё больше, они как-бы поновее.
Как ты думаешь, для такого количества кода нужен IDE? И сколько людей лабают это количество скриптового кода?
T>>Ты покажи, куда складывают код эти 80+ "которых я в художники записал" (а на самом деле в они титрах так обозначены). M>Как куда? В UnrealScript или аналогичный DSL.
Ты ресурсы с этим делом покажи.
T>>Когда по сети ходили то, что выдавали за исходники HL2, ничего подобного я там не видел. M>Что, движок утянули, а саму игру нет? Или ты мне хочешь сказать, что они всю логику игры, весь сценарий — в C++ закодировали?
Практически.
Сравни описание "Зафиксировано столкновение Фримена с этой коробкой, надо запускать вот этих товарищей", пусть даже повторенное 1000 раз. с описанием столкновения Фримена и запуска товарищей.
1000 раз повторенное — это 1000*10 секунд = 3 часа игрового времени. А в HL2 восемь часов игрового времени, из которых значительное количество — разнообразные ралли.
AFAIR, в редакторе уровней Source можно задавать триггеры и всё такое. Тоже, своего рода, IDE.
T>>В той игре, что делалась с моим участием (недолгим, правда), тоже скриптов AI, как таковых, не было. Поскольку программист ИИ сидел рядом, я был в курсе. Был "думатель" с системой оценок и был "делатель", выдававший команды управляющим органам. Конфигурация ИИ была развесистой, но декларативной — скриптов "сделай так" не было. M>Ты хотел сказать "императивной"? Потому как конфигурация есть декларативная программа.
Будь добр, разверни.
Я снова логику не улавливаю.
T>>Рассказы про F.E.A.R. это не подтверждают. ИИ в нём сделан всё теми же точками на уровне, но он не выглядит, как "на нуле". Есть обходные маневры, подавление противника огнём, отвлекающие маневры... Много, чего есть. M>Ну и? Сделали шутер с хорошим AI. Одни-два из сотни. С собственным AI движком, и разумеется, с собственным DSL для этого AI. Могли бы взять MPS/SymADE/etc и сократить себе часть работы по созданию DSL-я и редактора к нему.
Сравни подключение Lua/Tcl, обеспечивающих умеренно подходящий к задаче синтаксис, с подключением MPS/SymADE/etc, которые, при некотором опыте, могут обеспечить синтаксис и поддержку получше.
Мы, вон, видели результаты работы товарищей из MPS. На систему типа GNU make у них ушло запредельное количество времени, месяц, что ли. На C это быстрей написать получилось бы.
Поэтому — не могли.
Экономика производства не позволяет.
M>>>Посмотреть на количество скриптового кода в RPG и симуляторах вроде X3 Reunion не хочешь? T>>Покажи. M>Gothic 2, больше 8мег / 250KLOC скриптов (исходники доступны в мод-паке). M>Всякие Oblivion, X3 и прочие должны иметь ещё больше, они как-бы поновее. M>Как ты думаешь, для такого количества кода нужен IDE? И сколько людей лабают это количество скриптового кода?
Дело в том, что игровые скрипты весьма независимы. Их разработка хорошо распареллеливается. В них не надо отслеживать зависимости между, допустим, параллельным прохождением восемью уровней сразу.
В приложении мы сопрягаем несколько компонент, которые работают, можно считать, параллельно, или, по другому, мы их выполнение контролируем весьма узко и опосредованно. Их интерфейсы существенно влияют на код, к тому же. В скриптах всё по другому — взаимоотношения простые, интерфейсы фиксированы.
Почему их и пишут на нетипизированных языках, потому, что цена ошибки мала, а проверять (тестировать) всё равно надо.
Вот если SymADE позволит быстро создавать языки, позволяющие описывать ощущения от уровня, как инвариант действий персонажей...
Например, если уровень тяжёлый, то должно быть темно. А если уровень грустный, то должен быть закат, а враги должны атаковать, понурясь и плача.
Тогда может быть прорыв.
Это я шучу. Диалоги с интонациями же не опишешь, их надо репетировать и записывать.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[12]: Программирование, от монолога к диалогу с компьютеро
Здравствуйте, thesz, Вы писали:
T>>>Ты покажи, куда складывают код эти 80+ "которых я в художники записал" (а на самом деле в они титрах так обозначены). M>>Как куда? В UnrealScript или аналогичный DSL.
T>Ты ресурсы с этим делом покажи.
Не понял, что именно тебе показать?
Есть редактор уровня, у него есть предмет, кнопка, дверь или ещё что. На этот предмет игрок производит действие, выполняется скрипт который это действие обрабатывает.
Если где-то в другом месте на кнопку не нажал, то дверь не откроется. Это сценарий, его в сценарии (скрипте аглицки) и описывают. Кто дизайнит уровни эти точки воздействия обозначает и привязывает их к скриптам. Тебе кусок кода из конкретной игры показать, или о чём ты спрашиваешь?
T>>>Когда по сети ходили то, что выдавали за исходники HL2, ничего подобного я там не видел. M>>Что, движок утянули, а саму игру нет? Или ты мне хочешь сказать, что они всю логику игры, весь сценарий — в C++ закодировали?
T>Практически.
T>Сравни описание "Зафиксировано столкновение Фримена с этой коробкой, надо запускать вот этих товарищей", пусть даже повторенное 1000 раз. с описанием столкновения Фримена и запуска товарищей.
T>1000 раз повторенное — это 1000*10 секунд = 3 часа игрового времени. А в HL2 восемь часов игрового времени, из которых значительное количество — разнообразные ралли.
T>AFAIR, в редакторе уровней Source можно задавать триггеры и всё такое. Тоже, своего рода, IDE.
Ничего не понял. Какие 1000 повторений?
T>Будь добр, разверни. T>Я снова логику не улавливаю.
Извини, не так прочитал.
T>>>Рассказы про F.E.A.R. это не подтверждают. ИИ в нём сделан всё теми же точками на уровне, но он не выглядит, как "на нуле". Есть обходные маневры, подавление противника огнём, отвлекающие маневры... Много, чего есть. M>>Ну и? Сделали шутер с хорошим AI. Одни-два из сотни. С собственным AI движком, и разумеется, с собственным DSL для этого AI. Могли бы взять MPS/SymADE/etc и сократить себе часть работы по созданию DSL-я и редактора к нему.
T>Сравни подключение Lua/Tcl, обеспечивающих умеренно подходящий к задаче синтаксис, с подключением MPS/SymADE/etc, которые, при некотором опыте, могут обеспечить синтаксис и поддержку получше.
Дело не в самом синтаксисе, хотя эта плюшка тоже удобная.
Дело в том, что у тебя в игре 1000 предметов, 1000 функций и пр. Ты пишешь кусок скрипта, ты же не можешь держать в голове все эти 1000 предметов (их имена) и вспомогательных функций (их имена и параметры). Для этого IDE нужны. Для лазанья по проекту, для автокомплита (который тебе из 1000 функций подберёт подходящие 10), для рефакторинга устаревшего кода и так далее.
То, что Lua/Tcl не поддерживают проверки констрайнтов (вроде проверки типов) — это цена за то, что их не надо компилировать, что они предоставляют динамический код (eval) и пр. При небольшом размере кода это прокатывает, а на больших проектах из-за этого вылезают постоянные баги. Я когда померял исходники скриптов для Gothic немного офигел — у них тоже получилось 250 килострок кода, как и в Unreal игрушках. Это похоже на какой-то предел для возможности писать код (в пределах современных бюджетов и сроков создания игр).
Java проверяет кучу всего, но её надо компилировать — только сидя в IDE я этого не замечаю. Я поправил код и запустил отладчик — он запустился сразу, потому как пока я код набивал, IDE уже всё скомпилировала и проверила, и показывает ошибки сразу, а не дожидаясь комманды перекомпиляции всего. В Java есть горячая подстановка изменённых классов, я нахожу в отладчике багу, правлю, и продолжаю исполнять программу дальше. Конечно, ява для этого не предназначалась, поэтому там есть некоторые ограничения на возможные изменения классов. Есть какие-то приблуды для явы, которые препроцессят загружаемый код, и позволяют делать горячую замену практически всегда. Для скриптов можно сделать аналогичо — с произвольной горячей заменой при отладке, и оптимизированный вариант при продакшине.
Ну и та самая плюшка с синтаксисом — это возможность писать более высокоуровневый и более компактный (да хоть в отображении более компактный) код. На тех-же 250 килостроках более высокоуровневого кода можно сделать более интересную игру. И скрипты будут бегать раз в 10 быстрее, и жрать в несколько раз меньше памяти, как минимум.
T>Мы, вон, видели результаты работы товарищей из MPS. На систему типа GNU make у них ушло запредельное количество времени, месяц, что ли. На C это быстрей написать получилось бы.
Смотря что они сделали. Сам make писался намного дольше, чем месяц. Подозреваю, что ты его за месяц не воспроизведёшь.
Уровень поддержки языка в IDE может быть очень разный. От простого редактора с подсветкой синтаксиса и запускалкой комманд-лайн тулзы, до полноценной поддержки вроде их Idea или Eclipse.
Месяц — это долго, если они уже знали, что хотят. Если им надо было по дороге сделать дизайн и придумать как лучше — не так уж и много.
Если на скриптовый язык для игрушки уйдёт месяц работы, для интеграции его в IDE — это окупится, и очень даже окупится. Потому как потом в этой IDE будут работать несколько программистов не менее года. И если у них производительность труда вырастет раза в 2 — можешь себе представить, как это окупится.
T>Поэтому — не могли.
Не могли, потому как MPS ещё совсем бета. Это одна из первых tree-based программерских сред, которая реально работает. Сама концепция не отточена, они спотыкаются обо все углы. Сколько десятков лет разрабатывалась концепция FP или OOP, прежде чем мы получили Haskell или C#?
T>Экономика производства не позволяет.
Угу. Вот кризис долбанёт (уже долбанул, по инерции едем), и тогда очень быстро найдутся желающие увеличить в несколько раз производительность труда программиста. Что на данном этапе можно — применяя DSL интегрированные в IDE, применяя мета-программирование без потери IDE и так далее. Вот когда functional, logic, object programming сольются в экстазе (в языках вроде Scala), к ним прикрутят полноценное мета-программирование, полноценную интеграцию с DSL (и eDSL), и полноценную интеграцию с IDE — вот тогда производительность труда может быть увеличена на порядок. Но без системы типа MPS/IP/SymADE ты этого не сделаешь.
T>Дело в том, что игровые скрипты весьма независимы. Их разработка хорошо распареллеливается. В них не надо отслеживать зависимости между, допустим, параллельным прохождением восемью уровней сразу.
Угу. Для того уровни и делаются. Какой бы дурак делал уровни, если бы без них можно было обойтись. Кстати, большая проблема для MMORPG и прочих MMO игр. У них уровней почти нет. Правда и там пытаются разбить на независимые локации, но при наличии игроков разного уровня — фигня выходит.
T>В приложении мы сопрягаем несколько компонент, которые работают, можно считать, параллельно, или, по другому, мы их выполнение контролируем весьма узко и опосредованно. Их интерфейсы существенно влияют на код, к тому же. В скриптах всё по другому — взаимоотношения простые, интерфейсы фиксированы.
Это не потому, что скрипты такие хорошие, а потому, что они такие плохие. Нельзя в них сделать сложные взаимоотношения, они тогда не будут динамически (без перекомпиляции всего проекта) исполнятся. А ещё они тормознутые и жрут много памяти — тоже цена за динамику. Про решение этой проблемы при наличии хорошего IDE я написал выше.
T>Почему их и пишут на нетипизированных языках, потому, что цена ошибки мала, а проверять (тестировать) всё равно надо.
Цена ошибки — задержанные сроки выхода игры, перерасход бюджета и пр. Задерживают сейчас практически все.
T>Это я шучу. Диалоги с интонациями же не опишешь, их надо репетировать и записывать.
Диалоги тоже в SymADE писать будет удобней. Код один, хоть и многоуровневый. Нажал кнопку — показали диалог на аглицком, нажал другую — тот-же диалог на японском. Поменял текст на аглицком — нарисует предупреждение, что надо бы и японский проверить. Хоть wav-ы в код вставляй, он же не текстовый. text-to-speach интонации и тембры удобней будет редактировать, оно тебе не кракозяблики будет показывать, а разным цветом и шрифтом разные тембры, нарисует восходящие и нисходящие интонации. Мы же на canvas рисуем, можем хоть midi ноты рисовать, хоть tts, хоть фомулы математические.
Так мы начали с того, что человек не поверил, будто SymADE может помочь хорошие игрушки писать. Ты тоже всё ещё сомневаешься, или уже согласен, что таки может?
T>>>>Ты покажи, куда складывают код эти 80+ "которых я в художники записал" (а на самом деле в они титрах так обозначены). M>>>Как куда? В UnrealScript или аналогичный DSL. T>>Ты ресурсы с этим делом покажи. M>Не понял, что именно тебе показать? M>Есть редактор уровня, у него есть предмет, кнопка, дверь или ещё что. На этот предмет игрок производит действие, выполняется скрипт который это действие обрабатывает. M>Если где-то в другом месте на кнопку не нажал, то дверь не откроется. Это сценарий, его в сценарии (скрипте аглицки) и описывают. Кто дизайнит уровни эти точки воздействия обозначает и привязывает их к скриптам. Тебе кусок кода из конкретной игры показать, или о чём ты спрашиваешь?
Да-да. Кусок кода. И чтобы большой кусок кода был.
Что-то я смотрел на игры, только специально построенные под использование скриптов имеют большую базу этих самых скриптов (Nebula Device и производные). Но там всё — модели в скриптах, ИИ в скриптах...
В играх с редактором уровней это всё хранится вместе с уровнем (HL2/Source как ярчайший пример).
T>>>>Когда по сети ходили то, что выдавали за исходники HL2, ничего подобного я там не видел. M>>>Что, движок утянули, а саму игру нет? Или ты мне хочешь сказать, что они всю логику игры, весь сценарий — в C++ закодировали? T>>Практически. T>>Сравни описание "Зафиксировано столкновение Фримена с этой коробкой, надо запускать вот этих товарищей", пусть даже повторенное 1000 раз. с описанием столкновения Фримена и запуска товарищей. T>>1000 раз повторенное — это 1000*10 секунд = 3 часа игрового времени. А в HL2 восемь часов игрового времени, из которых значительное количество — разнообразные ралли. T>>AFAIR, в редакторе уровней Source можно задавать триггеры и всё такое. Тоже, своего рода, IDE. M>Ничего не понял. Какие 1000 повторений?
Есть событие-триггер "игрок пересёк такой-то объём пространства" и привязанные к этому делу действия.
В одном месте мы поставили такой триггер, в другом месте, в третьем, в тысячном.
Вот и тысяча повторений.
T>>>>Рассказы про F.E.A.R. это не подтверждают. ИИ в нём сделан всё теми же точками на уровне, но он не выглядит, как "на нуле". Есть обходные маневры, подавление противника огнём, отвлекающие маневры... Много, чего есть. M>>>Ну и? Сделали шутер с хорошим AI. Одни-два из сотни. С собственным AI движком, и разумеется, с собственным DSL для этого AI. Могли бы взять MPS/SymADE/etc и сократить себе часть работы по созданию DSL-я и редактора к нему. T>>Сравни подключение Lua/Tcl, обеспечивающих умеренно подходящий к задаче синтаксис, с подключением MPS/SymADE/etc, которые, при некотором опыте, могут обеспечить синтаксис и поддержку получше. M>Дело не в самом синтаксисе, хотя эта плюшка тоже удобная. M>Дело в том, что у тебя в игре 1000 предметов, 1000 функций и пр. Ты пишешь кусок скрипта, ты же не можешь держать в голове все эти 1000 предметов (их имена) и вспомогательных функций (их имена и параметры). Для этого IDE нужны. Для лазанья по проекту, для автокомплита (который тебе из 1000 функций подберёт подходящие 10), для рефакторинга устаревшего кода и так далее.
Это всё вносится в редактор уровня — своего рода IDE.
M>То, что Lua/Tcl не поддерживают проверки констрайнтов (вроде проверки типов) — это цена за то, что их не надо компилировать, что они предоставляют динамический код (eval) и пр. При небольшом размере кода это прокатывает, а на больших проектах из-за этого вылезают постоянные баги. Я когда померял исходники скриптов для Gothic немного офигел — у них тоже получилось 250 килострок кода, как и в Unreal игрушках. Это похоже на какой-то предел для возможности писать код (в пределах современных бюджетов и сроков создания игр).
Может быть. Вполне может быть.
T>>Мы, вон, видели результаты работы товарищей из MPS. На систему типа GNU make у них ушло запредельное количество времени, месяц, что ли. На C это быстрей написать получилось бы. M>Смотря что они сделали. Сам make писался намного дольше, чем месяц. Подозреваю, что ты его за месяц не воспроизведёшь.
И там даже функциональности make нет, как выяснилось, короче.
M>Если на скриптовый язык для игрушки уйдёт месяц работы, для интеграции его в IDE — это окупится, и очень даже окупится. Потому как потом в этой IDE будут работать несколько программистов не менее года. И если у них производительность труда вырастет раза в 2 — можешь себе представить, как это окупится.
Два раза — это сильно. Это разница между Ассемблером и Си, между языками соседних уровней.
Вот 10% — это ближе.
T>>Поэтому — не могли. M>Не могли, потому как MPS ещё совсем бета. Это одна из первых tree-based программерских сред, которая реально работает. Сама концепция не отточена, они спотыкаются обо все углы. Сколько десятков лет разрабатывалась концепция FP или OOP, прежде чем мы получили Haskell или C#?
Слушай, в свете наличия уймы теоретических знаний по системам переписывания термов и атрибутным грамматикам слова "концепция не отточена" звучат не очень хорошо.
Тут, извиняюсь, бери эти самые грамматики и не применяй сильно неправильно. Уже так всё заработает со страшной силой.
Двухуровневые грамматики а-ля грамматики Вийнгаардена Тьюринг-полны, что угодно описать можно.
T>>Экономика производства не позволяет. M>Угу. Вот кризис долбанёт (уже долбанул, по инерции едем), и тогда очень быстро найдутся желающие увеличить в несколько раз производительность труда программиста. Что на данном этапе можно — применяя DSL интегрированные в IDE, применяя мета-программирование без потери IDE и так далее. Вот когда functional, logic, object programming сольются в экстазе (в языках вроде Scala), к ним прикрутят полноценное мета-программирование, полноценную интеграцию с DSL (и eDSL), и полноценную интеграцию с IDE — вот тогда производительность труда может быть увеличена на порядок. Но без системы типа MPS/IP/SymADE ты этого не сделаешь.
Ты этот Scala-то видал? Трогал, хотя бы, трехметровой палкой? Он же сложный, как я не знаю, что. И, главное, бессмысленно сложный, как раз из-за "соединения".
А ты на Java/Kiev хотя бы один eDSL сооружал? Хотя бы уровня ассемблера.
T>>Почему их и пишут на нетипизированных языках, потому, что цена ошибки мала, а проверять (тестировать) всё равно надо. M>Цена ошибки — задержанные сроки выхода игры, перерасход бюджета и пр. Задерживают сейчас практически все.
Срыв сроков меньше, чем на половину, это успех проекта.
T>>Это я шучу. Диалоги с интонациями же не опишешь, их надо репетировать и записывать. M>Диалоги тоже в SymADE писать будет удобней. Код один, хоть и многоуровневый. Нажал кнопку — показали диалог на аглицком, нажал другую — тот-же диалог на японском. Поменял текст на аглицком — нарисует предупреждение, что надо бы и японский проверить. Хоть wav-ы в код вставляй, он же не текстовый. text-to-speach интонации и тембры удобней будет редактировать, оно тебе не кракозяблики будет показывать, а разным цветом и шрифтом разные тембры, нарисует восходящие и нисходящие интонации. Мы же на canvas рисуем, можем хоть midi ноты рисовать, хоть tts, хоть фомулы математические.
Завидую оптимизму.
Здесь бы генерацию всего этого из одного источника сделать без ошибок, что уж там про редактирование.
Меня пугает легкость "мы же на canvas рисуем". То, что мы очень просто рисуем что угодно, не отменяет сложности этого самого когерентного рисования во многих представлениях сразу.
M>Так мы начали с того, что человек не поверил, будто SymADE может помочь хорошие игрушки писать. Ты тоже всё ещё сомневаешься, или уже согласен, что таки может?
Я поверю, когда увижу. Пока это только слова, слова фальсифицируются плохо.
Пока у меня стойкое ощущение, что ты не знаешь очень и очень многого.
У SymADE нет метациркулярности.
Ты даже синтаксис Хаскеля, нынешней фабрики теории и практики DSEL, и то не знаешь. Про атрибутные грамматики молчок, а уж на что полезная в твоём деле штука. Про свой опыт создания DSEL тоже ничего не говоришь. Похоже, что ты просто не в теме того, чем занимаешься. Как можно верить такому человеку?
В общем, всё плохо, с моей точки зрения.
Ты хотя бы метациркулярность сделай, чтобы хоть какой-то значительный пример использования был. Глядишь, поймешь, что у тебя не так, и во что оборачивается работа с SymADE.
Заодно, сможешь разом переубедить всех Фом неверующих в моём лице. Ведь когда ты скажешь, что "вот, вы думали, что я никогда это не сделаю, а я сделал всего лишь за двадцать лет, сегодня у меня заработал Hello, world!", это будет впечатляющий аргумент.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[14]: Программирование, от монолога к диалогу с компьютеро
var int EnterDI_Kapitel6;
func void enter_di_firsttime_trigger()
{
if(Npc_HasItems(hero,ItKe_Ship_Levelchange_MIS))
{
Npc_RemoveInvItems(hero,ItKe_Ship_Levelchange_MIS,1);
};
if(hero.attribute[ATR_DEXTERITY] < 15)
{
Wld_InsertItem(ItPo_Perm_DEX,"FP_ITEM_DI_ENTER_05");
};
if(EnterDI_Kapitel6 == FALSE)
{
if(hero.guild == GIL_PAL)
{
CreateInvItems(Archol,ItRu_PalDestroyEvil,1);
};
Wld_InsertItem(ItMi_Flask,"FP_ITEM_SHIP_12");
if(Npc_HasItems(hero,ItMi_InnosEye_MIS) == FALSE)
{
if(Npc_HasItems(hero,ItMi_InnosEye_Discharged_Mis) == FALSE)
{
Wld_InsertItem(ItSe_XardasNotfallBeutel_MIS,"FP_ITEM_SHIP_12");
SC_InnosEyeVergessen_DI = TRUE;
B_LogEntry(TOPIC_HallenVonIrdorath,"Прошлой ночью мне приснился сон. Со мной говорил Ксардас, он попросил меня подойти к алхимическому столу на корабле, чтобы забрать кое-что с него. Это очень странно, но я ничего не пил вчера вечером.");
};
Wld_InsertItem(ItMi_Flask,"FP_ITEM_SHIP_06");
if(((Npc_HasItems(hero,ItAt_IcedragonHeart) >= 1) || (Npc_HasItems(hero,ItAt_RockdragonHeart) >= 1) || (Npc_HasItems(hero,ItAt_FiredragonHeart) >= 1) || (Npc_HasItems(hero,ItAt_SwampdragonHeart) >= 1)) == FALSE)
{
CreateInvItems(OrkElite_AntiPaladinOrkOberst_DI,ItAt_RockdragonHeart,1);
};
};
Log_CreateTopic(TOPIC_MyCrew,LOG_MISSION);
Log_SetTopicStatus(TOPIC_MyCrew,LOG_Running);
if(JorgenIsCaptain == TRUE)
{
Log_AddEntry(TOPIC_MyCrew,"Йорген, мой капитан, будет ждать на корабле моего возвращения.");
};
if(TorlofIsCaptain == TRUE)
{
Log_AddEntry(TOPIC_MyCrew,"Торлоф, мой капитан, будет ждать на корабле и оборонять его во время моего отсутствия. Он также может помочь мне повысить мою силу и ловкость.");
};
if(JackIsCaptain == TRUE)
{
Log_AddEntry(TOPIC_MyCrew,"Джек, мой капитан, будет ждать на корабле моего возвращения. Похоже, он немного испуган. Надеюсь, он возьмет себя в руки. Он нужен мне.");
};
if(Lee_IsOnBoard == LOG_SUCCESS)
{
Log_AddEntry(TOPIC_MyCrew,"Ли будет командовать кораблем в мое отсутствие. Он также может помочь мне научиться лучше владеть двуручным и одноручным оружием.");
};
if(MiltenNW_IsOnBoard == LOG_SUCCESS)
{
Log_AddEntry(TOPIC_MyCrew,"Милтен может помочь мне повысить мою ману.");
if(hero.guild == GIL_KDF)
{
Log_AddEntry(TOPIC_MyCrew,"Кроме этого Милтен может научить меня создавать руны.");
};
};
if(Lester_IsOnBoard == LOG_SUCCESS)
{
Log_AddEntry(TOPIC_MyCrew,"У меня такое впечатление, что состояние Лестера только ухудшилось на этом странном острове.");
};
if(Mario_IsOnBoard == LOG_SUCCESS)
{
Log_AddEntry(TOPIC_MyCrew,"Марио ведет себя немного странно. Он просто сидит на корме и уже давно от него никто не слышал ни слова.");
};
if(Wolf_IsOnBoard == LOG_SUCCESS)
{
Log_AddEntry(TOPIC_MyCrew,"Вольф может обучить меня стрельбе из арбалета и лука.");
};
if(Vatras_IsOnBoard == LOG_SUCCESS)
{
Log_AddEntry(TOPIC_MyCrew,"Ватрас удалился в каюту магов. Он может лечить меня и знает множество рецептов приготовления зелий.");
if(hero.guild == GIL_KDF)
{
Log_AddEntry(TOPIC_MyCrew,"Ватрас также может повысить мой магический круг.");
};
};
if(Bennet_IsOnBoard == LOG_SUCCESS)
{
Log_AddEntry(TOPIC_MyCrew,"Беннет обучит меня кузнечному делу, если я захочу.");
};
if(Diego_IsOnBoard == LOG_SUCCESS)
{
Log_AddEntry(TOPIC_MyCrew,"Диего поможет мне, если я не знаю, что делать, также у него есть амуниция для меня. Он может научить меня пользоваться отмычками и метко стрелять из лука и арбалета.");
};
if(Gorn_IsOnBoard == LOG_SUCCESS)
{
Log_AddEntry(TOPIC_MyCrew,"Горн ни разу не прилег за время нашего путешествия. Он будет присматривать за кораблем. Я думаю, корабль будет в надежных руках.");
Log_AddEntry(TOPIC_MyCrew,"Горн может помочь мне научиться лучше владеть двуручным оружием.");
};
if(Lares_IsOnBoard == LOG_SUCCESS)
{
Log_AddEntry(TOPIC_MyCrew,"Ларес обещал научить меня красться и сражаться одноручным оружием. Кроме этого он может повысить мою ловкость.");
};
if(Biff_IsOnBoard == LOG_SUCCESS)
{
Log_AddEntry(TOPIC_MyCrew,"Бифф слишком жаден до денег, это огорчает. Его тяжело контролировать.");
};
if(Angar_IsOnBoard == LOG_SUCCESS)
{
Log_AddEntry(TOPIC_MyCrew,"Ангар очень беспокоен. Мне кажется, что еще немного, и он побежит куда-нибудь сражаться без приказа.");
};
if(Girion_IsOnBoard == LOG_SUCCESS)
{
Log_AddEntry(TOPIC_MyCrew,"Гирион невозмутим. Его спокойствие поражает. И он превосходный инструктор боя. Это может пригодиться мне.");
};
IntroduceChapter(KapWechsel_6,KapWechsel_6_Text,"chapter6.tga","chapter_01.wav",6000);
EnterDI_Kapitel6 = TRUE;
};
};
Особенно помогают ориентироваться среди 1000 предметов и 1000 функций их имена. Песня, а не имена. ItPo_Perm_DEX,"FP_ITEM_DI_ENTER_05" и пр.
T>Что-то я смотрел на игры, только специально построенные под использование скриптов имеют большую базу этих самых скриптов (Nebula Device и производные). Но там всё — модели в скриптах, ИИ в скриптах...
T>В играх с редактором уровней это всё хранится вместе с уровнем (HL2/Source как ярчайший пример).
Ну так модель уровня и есть тогда такой скрипт. Частично написанный не в виде текста.
А я что делаю? Разве не редактор программы, написанной не в виде текста?
Понятно, что редактор уровня, с его специфической графикой и манипуляцией объектов — будет писаться отдельно от SymADE, и даже не как плагин.
Но ничто не мешает использовать совместимый формат данных, апи для работы с деревьями и пр, не изобретая велосипед в сотый раз (когда среда типа SymADE или MPS или IP получит таки широкое распространение).
T>Вот и тысяча повторений.
Всё равно не понял. Ну ладно, проехали.
T>Это всё вносится в редактор уровня — своего рода IDE.
О. Ребята пишут свою IDE на каждую игру. Ну ладно, для каждого движка.
Теперь вернись на обсуждаемую статью, часть первая, и прочитай про сравнение адаптивного и специализированного подхода.
Я не говорю, что специализированные решения не имеют права на жизнь. Очень даже имеют.
Но недолгую.
Условия изменятся — и жизнь закончится.
T>>>Мы, вон, видели результаты работы товарищей из MPS. На систему типа GNU make у них ушло запредельное количество времени, месяц, что ли. На C это быстрей написать получилось бы. M>>Смотря что они сделали. Сам make писался намного дольше, чем месяц. Подозреваю, что ты его за месяц не воспроизведёшь.
T>http://krlz.livejournal.com/58909.html
T>Байду написали, короче. Писали длинее, короче. T>И там даже функциональности make нет, как выяснилось, короче.
А на самом деле там практикантка изучала систему методом выполнения простенькой задачки.
У них же LOP, она одних языков программирования должна была десяток выучить. И потом, практикантка, вчерашняя студентка, девушка. Среди них редко попадаются супер-программисты, которые за месяц это могут на С написать.
Я, когда начал работать в esmertec, тоже несколько месяцев, по сути, входит в работу, в детали реализации их JVM, системы сборки... да-да, у них тоже была своя система сборки, построенная поверх make-а, и писали её много человек и не один месяц (я там работал больше 3 лет, и всё это время её порывались переписать заново). А ребята в MPS написали свою, поверх ant-а.
M>>Если на скриптовый язык для игрушки уйдёт месяц работы, для интеграции его в IDE — это окупится, и очень даже окупится. Потому как потом в этой IDE будут работать несколько программистов не менее года. И если у них производительность труда вырастет раза в 2 — можешь себе представить, как это окупится.
T>Два раза — это сильно. Это разница между Ассемблером и Си, между языками соседних уровней. T>Вот 10% — это ближе.
Если hello world писать, то и 10% не наберётся.
А если тебе внести изменения в JVM, которая работает на нескольких платформах и в сотне конфигураций, то будет не в 2 раза, а в 10 раз быстрее. Проверено.
T>>>Поэтому — не могли. M>>Не могли, потому как MPS ещё совсем бета. Это одна из первых tree-based программерских сред, которая реально работает. Сама концепция не отточена, они спотыкаются обо все углы. Сколько десятков лет разрабатывалась концепция FP или OOP, прежде чем мы получили Haskell или C#?
T>Слушай, в свете наличия уймы теоретических знаний по системам переписывания термов и атрибутным грамматикам слова "концепция не отточена" звучат не очень хорошо. T>Тут, извиняюсь, бери эти самые грамматики и не применяй сильно неправильно. Уже так всё заработает со страшной силой. T>Товарищи компилятор Хаскеля на атрибутных грамматиках написали. Наверняка и в реализации других языков они будут полезны. T>Двухуровневые грамматики а-ля грамматики Вийнгаардена Тьюринг-полны, что угодно описать можно.
Ты меня извини, но эти граммитики — это ASCII-art.
Какая разница, можно описать всё или не всё. Машина Тьюринга тоже Тьюринг-полная, но на ней же никто не работает.
Зачем использовать ascii-art, если можно взять нетекстовое представление кода и иметь всё это плюс ещё туеву хучу всего?
Ascii-art появился тогда, когда небыло принтеров, печатающих графику. И эти грамматики — это последняя попытка уцепится за текстовое представление кода.
Но всё равно код перестанет быть текстовым, через 5, 10, да хоть 20 лет. Зачем цепляться за этот текст, не лучше ли потратить силы на реализацию нетекстового представления?
T>Ты этот Scala-то видал? Трогал, хотя бы, трехметровой палкой? Он же сложный, как я не знаю, что. И, главное, бессмысленно сложный, как раз из-за "соединения".
При наличии lazy вычислений всего подряд — конечно быстро.
T>А ты на Java/Kiev хотя бы один eDSL сооружал? Хотя бы уровня ассемблера.
Конечно сооружал. Тот-же logic programming (backtracking сделан в виде state machine, что-то вроде генерации кода для yield в С#, только сложнее).
Когда в первый раз и для Kiev — сооружал 3 месяца.
Потом переписал для SymADE за 3 дня. Если бы не было готового кода, то за неделю управился бы.
T>Меня пугает легкость "мы же на canvas рисуем". То, что мы очень просто рисуем что угодно, не отменяет сложности этого самого когерентного рисования во многих представлениях сразу.
Дерево кода одно. Поэтому сложности с рисованием его во многих видах не возникает.
Сложно отловить его изменения, и поправить отображение в соответствии с изменением.
Сейчас при рисовании я просто делаю полл, и при расхождении выкидываю кусок отображения, и создаю и форматирую его заново.
Медленно, но надёжно.
Для projection одного дерева в другое, при возможности менять оба эти дерева — приходится делать на listener-ах. Если при обработке какого-то события произойдёт сбой — то тогда синхронизация, конечно, потеряется. Например, есть дерево для кода a+1 (+ (a) (1)), и его projection в дерево для редактирования, просто список токенов ((a) (+) (1)). Когда дерево для редактирования меняем, скажем, пишем 2*a+1, то выражение временно невалидно, и при отображении в семантическое дерево кода произойдёт сбой (на этапе разбора выражения), и когерентность деревьев пропадёт. Потом, когда выражение доредактируется до конца — деревья снова станут синхронными.
Проблема в том — что делать, если какой-то плагин поменял семантическое дерево, пока мы редактируем синтаксическое?
Выкидывать изменения человека? Игнорировать изменения плагина? Делать локи?
Пока таких проблем не возникает, так как у меня дерево версионное, и компилятор (с плагинами) работает со своей версией дерева, а редактор со своей. Но возникнут, когда редактор станет поумнее, и у него появятся свои плагины.
Так понемногу решаем проблемы, одну за другой, по мере их актуализации. Поэтому я и говорю, что это ещё не разработанная область, редактирование не-текстовых программ ещё развивать и развивать. Поэтому и MPS так сложен в освоении, и ещё не настолько удобен для работы.
M>>Так мы начали с того, что человек не поверил, будто SymADE может помочь хорошие игрушки писать. Ты тоже всё ещё сомневаешься, или уже согласен, что таки может?
T>Я поверю, когда увижу. Пока это только слова, слова фальсифицируются плохо. T>Пока у меня стойкое ощущение, что ты не знаешь очень и очень многого.
Хаскеля?
T>У SymADE нет метациркулярности.
T>Ты даже синтаксис Хаскеля, нынешней фабрики теории и практики DSEL, и то не знаешь. Про атрибутные грамматики молчок, а уж на что полезная в твоём деле штука. Про свой опыт создания DSEL тоже ничего не говоришь. Похоже, что ты просто не в теме того, чем занимаешься. Как можно верить такому человеку?
T>В общем, всё плохо, с моей точки зрения.
T>Ты хотя бы метациркулярность сделай, чтобы хоть какой-то значительный пример использования был. Глядишь, поймешь, что у тебя не так, и во что оборачивается работа с SymADE.
Так ей родимой и занимаюсь последний год. Я сделал уже полный редактор для своего кода. Месяц делал. И увы — выкинул. Теперь подход номер два, с projected деревьями.
T>Заодно, сможешь разом переубедить всех Фом неверующих в моём лице. Ведь когда ты скажешь, что "вот, вы думали, что я никогда это не сделаю, а я сделал всего лишь за двадцать лет, сегодня у меня заработал Hello, world!", это будет впечатляющий аргумент.
Hello world у меня уже года два как работает (я не про компилятор, а про IDE).
M>Особенно помогают ориентироваться среди 1000 предметов и 1000 функций их имена. Песня, а не имена. ItPo_Perm_DEX,"FP_ITEM_DI_ENTER_05" и пр.
Это писали немцы. Это стиль у них такой (у них существительные так строятся, поэтому им можно).
Второе, это скрипты от Готики. Для шутеров тебе такое придётся поискать.
T>>http://krlz.livejournal.com/58909.html T>>Байду написали, короче. Писали длинее, короче. T>>И там даже функциональности make нет, как выяснилось, короче. M>А на самом деле там практикантка изучала систему методом выполнения простенькой задачки. M>У них же LOP, она одних языков программирования должна была десяток выучить. И потом, практикантка, вчерашняя студентка, девушка. Среди них редко попадаются супер-программисты, которые за месяц это могут на С написать.
Сравни это с опытом vshabanov, когда студент, практикант, за полгода выкатил рабочий вариант конфигуратора игр на Хаскеле.
Овчинка выделки не стоит.
M>Я, когда начал работать в esmertec, тоже несколько месяцев, по сути, входит в работу, в детали реализации их JVM, системы сборки... да-да, у них тоже была своя система сборки, построенная поверх make-а, и писали её много человек и не один месяц (я там работал больше 3 лет, и всё это время её порывались переписать заново). А ребята в MPS написали свою, поверх ant-а.
Та, ещё, феерия. Пир духа!
M>>>Если на скриптовый язык для игрушки уйдёт месяц работы, для интеграции его в IDE — это окупится, и очень даже окупится. Потому как потом в этой IDE будут работать несколько программистов не менее года. И если у них производительность труда вырастет раза в 2 — можешь себе представить, как это окупится. T>>Два раза — это сильно. Это разница между Ассемблером и Си, между языками соседних уровней. T>>Вот 10% — это ближе. M>Если hello world писать, то и 10% не наберётся. M>А если тебе внести изменения в JVM, которая работает на нескольких платформах и в сотне конфигураций, то будет не в 2 раза, а в 10 раз быстрее. Проверено.
См. статью про ehc, да.
T>>Двухуровневые грамматики а-ля грамматики Вийнгаардена Тьюринг-полны, что угодно описать можно. M>Ты меня извини, но эти граммитики — это ASCII-art. M>Какая разница, можно описать всё или не всё. Машина Тьюринга тоже Тьюринг-полная, но на ней же никто не работает. M>Зачем использовать ascii-art, если можно взять нетекстовое представление кода и иметь всё это плюс ещё туеву хучу всего?
Дорогой друг, зачем брать нетекстовое представление, к которому ещё надо писать туеву кучу всего, чтобы хоть как-то пользоваться, если можно взять ascii-art и иметь туеву кучу всего путём обучения себя самого некоторым мысленным преобразованиям? Наподобие integr f a b == $\int_{a}^{b}{f(x)dx}$.
Да тот же Strafunski взять, он-то уже готов к использованию, в отличии от чего другого.
M>Ascii-art появился тогда, когда небыло принтеров, печатающих графику. И эти грамматики — это последняя попытка уцепится за текстовое представление кода.
Да брось ты! Им не меньше 30-ти лет и они ещё SymADE переживут.
M>Но всё равно код перестанет быть текстовым, через 5, 10, да хоть 20 лет. Зачем цепляться за этот текст, не лучше ли потратить силы на реализацию нетекстового представления?
Потому, что текст экономней.
T>>Logic programming сооружается на Хаскеле в течении очень короткого времени. M>При наличии lazy вычислений всего подряд — конечно быстро.
О! Не верю своим глазам, а так же центру распознавания печатного текста в мозгу.
T>>А ты на Java/Kiev хотя бы один eDSL сооружал? Хотя бы уровня ассемблера. M>Конечно сооружал. Тот-же logic programming (backtracking сделан в виде state machine, что-то вроде генерации кода для yield в С#, только сложнее). M>Когда в первый раз и для Kiev — сооружал 3 месяца. M>Потом переписал для SymADE за 3 дня. Если бы не было готового кода, то за неделю управился бы.
Похоже, ты всё же не разбираешься в терминологии.
eDSL (embedded domain specific language, он же DSEL) — это язык, встроенный в другой язык. За примером
Вот что-то типа этого собирал на Java/Kiev?
T>>Меня пугает легкость "мы же на canvas рисуем". То, что мы очень просто рисуем что угодно, не отменяет сложности этого самого когерентного рисования во многих представлениях сразу. M>Дерево кода одно. Поэтому сложности с рисованием его во многих видах не возникает. M>Сложно отловить его изменения, и поправить отображение в соответствии с изменением. M>Сейчас при рисовании я просто делаю полл, и при расхождении выкидываю кусок отображения, и создаю и форматирую его заново. M>Медленно, но надёжно.
Ура! Ты самостоятельно додумался до pretty-printing combinators совместно со стрелками.
M>Так понемногу решаем проблемы, одну за другой, по мере их актуализации. Поэтому я и говорю, что это ещё не разработанная область, редактирование не-текстовых программ ещё развивать и развивать. Поэтому и MPS так сложен в освоении, и ещё не настолько удобен для работы.
MPS сложен в освоении и не удобен в работе потому, что нет чёткой теоретической основы. Поэтому и разработка его сложна.
M>>>Так мы начали с того, что человек не поверил, будто SymADE может помочь хорошие игрушки писать. Ты тоже всё ещё сомневаешься, или уже согласен, что таки может? T>>Я поверю, когда увижу. Пока это только слова, слова фальсифицируются плохо. T>>Пока у меня стойкое ощущение, что ты не знаешь очень и очень многого. M>Хаскеля?
Да-да. Его в первую очередь.
Ты же постоянно изобретаешь что-то, давно пользователями Хаскеля изобретённое и доступное в статьях.
Вот и говори, потом, о преимуществах нетекстового представления.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[16]: Программирование, от монолога к диалогу с компьютеро
Здравствуйте, thesz, Вы писали:
T>Второе, это скрипты от Готики. Для шутеров тебе такое придётся поискать.
Да, для шутеров такое сложно найти. Там даже если солдаты и умные как в F.E.A.R., то весь сценарий всё равно укладывается в формулу "вошёл в дверь, и тут выскочило десять немцев". Прям так скриптовую комманду "выскочить 10 немцев" на кнопку в уровне игры и делают.
T>Сравни это с опытом vshabanov, когда студент, практикант, за полгода выкатил рабочий вариант конфигуратора игр на Хаскеле. T>Овчинка выделки не стоит.
ну так давай ссылку, буду сравнивать.
M>>Я, когда начал работать в esmertec, тоже несколько месяцев, по сути, входит в работу, в детали реализации их JVM, системы сборки... да-да, у них тоже была своя система сборки, построенная поверх make-а, и писали её много человек и не один месяц (я там работал больше 3 лет, и всё это время её порывались переписать заново). А ребята в MPS написали свою, поверх ant-а.
T>Ну, вот тебе исчо: http://krlz.livejournal.com/57813.html
T>Та, ещё, феерия. Пир духа!
Ну не месяц же он это делал.
Google: ANTLR IDE -> http://sourceforge.net/projects/antlrv3ide/
делает больше года (судя по сайту релиз выкатил через 8 месяцев), на Eclipse который как-бы заточен под подобные поделки.
M>>Если hello world писать, то и 10% не наберётся. M>>А если тебе внести изменения в JVM, которая работает на нескольких платформах и в сотне конфигураций, то будет не в 2 раза, а в 10 раз быстрее. Проверено.
T>См. статью про ehc, да.
Кто это?
T>Дорогой друг, зачем брать нетекстовое представление, к которому ещё надо писать туеву кучу всего, чтобы хоть как-то пользоваться, если можно взять ascii-art и иметь туеву кучу всего путём обучения себя самого некоторым мысленным преобразованиям? Наподобие integr f a b == $\int_{a}^{b}{f(x)dx}$.
Зачем пользовать компьютер, если можно научиться думать, а не заставлять железяку делать это вместо себя?
T>Да брось ты! Им не меньше 30-ти лет и они ещё SymADE переживут.
Тогда я вырос из Lisp & Forth, и моя пиписька старше.
M>>Но всё равно код перестанет быть текстовым, через 5, 10, да хоть 20 лет. Зачем цепляться за этот текст, не лучше ли потратить силы на реализацию нетекстового представления?
T>Потому, что текст экономней.
Для наколенных поделок.
T>eDSL (embedded domain specific language, он же DSEL) — это язык, встроенный в другой язык. За примером
далеко ходить не надо.
T>Вот что-то типа этого собирал на Java/Kiev?
Я же тебе про это и написал.
@ThisIsANode
public class BindingSet extends DNode implements GlobalDNodeContainer, ExportXMLDump {
@nodeAttr @SymbolRefAutoComplete @SymbolRefAutoResolve
final
public BindingSet^ parent_set;
@nodeAttr
public ASTNode[] members;
...
public rule resolveNameR(ResInfo path)
{
path ?= this
;
path @= members
;
path.isSuperAllowed(),
parent_set.dnode != null,
path.getPrevSlotName() != "parent_set",
path.enterSuper() : path.leaveSuper(),
parent_set.dnode.resolveNameR(path)
}
}
resolveNameR в лучших традициях, находит все имена (в другом месте foreach вызывается), или проверяет есть ли такое имя (в другом месте if вызывается).
Это тебе достаточный eDSL?
В текстовом виде, потому как исторически я его сделал для Kiev-а. Делал бы сейчас — вообще бы без текстового синтаксиса был, как без текстового представления у меня сейчас несколько языков в проекте живут.
T>Ура! Ты самостоятельно додумался до pretty-printing combinators совместно со стрелками.
Там нечего придумывать. Бери больше кидай дальше.
M>>Так понемногу решаем проблемы, одну за другой, по мере их актуализации. Поэтому я и говорю, что это ещё не разработанная область, редактирование не-текстовых программ ещё развивать и развивать. Поэтому и MPS так сложен в освоении, и ещё не настолько удобен для работы.
T>MPS сложен в освоении и не удобен в работе потому, что нет чёткой теоретической основы. Поэтому и разработка его сложна.
Теоретическая основа приходит из практики, а не наоборот.
T>Ты же постоянно изобретаешь что-то, давно пользователями Хаскеля изобретённое и доступное в статьях.
Ты просто всё, что видишь, сводишь к хаскелю. Поэтому, ничего кроме хаскеля и не видишь.
T>>Второе, это скрипты от Готики. Для шутеров тебе такое придётся поискать. M>Да, для шутеров такое сложно найти. Там даже если солдаты и умные как в F.E.A.R., то весь сценарий всё равно укладывается в формулу "вошёл в дверь, и тут выскочило десять немцев". Прям так скриптовую комманду "выскочить 10 немцев" на кнопку в уровне игры и делают.
Отлично. Сведи поведение противников FEAR к кнопке "выскочить 10 немцев".
T>>Сравни это с опытом vshabanov, когда студент, практикант, за полгода выкатил рабочий вариант конфигуратора игр на Хаскеле. T>>Овчинка выделки не стоит. M>ну так давай ссылку, буду сравнивать.
Я с работы по ЖЖ искать толком не могу.
T>>Ну, вот тебе исчо: http://krlz.livejournal.com/57813.html T>>Та, ещё, феерия. Пир духа! M>Ну не месяц же он это делал.
Да то же самое делается на любом ФЯ за часы. Если сравнивать функциональность — создать DSL для описания разборщиков.
Производительность программиста разнится в разы, прошу прощения за каламбур.
M>Google: ANTLR IDE -> http://sourceforge.net/projects/antlrv3ide/ M>делает больше года (судя по сайту релиз выкатил через 8 месяцев), на Eclipse который как-бы заточен под подобные поделки.
Я сейчас под Eclipse пишу.
Java под Eclipse — это не язык ваапстче. Ничего нельзя сделать, а то, что всё-таки можно сделать, надо повторить от двух до бесконечности раз.
Vector<Pair<Long,Long>> vec = new Vector<Pair<Long,Long>> ();
vec.add(new Pair<Long,Long>(new Long(x),new Long(y));
Он (Java под Eclipse) сопротивляется написанию программы в модульном стиле.
M>>>Если hello world писать, то и 10% не наберётся. M>>>А если тебе внести изменения в JVM, которая работает на нескольких платформах и в сотне конфигураций, то будет не в 2 раза, а в 10 раз быстрее. Проверено. T>>См. статью про ehc, да. M>Кто это?
Essential Haskell Compiler, я ссылку давал.
T>>Дорогой друг, зачем брать нетекстовое представление, к которому ещё надо писать туеву кучу всего, чтобы хоть как-то пользоваться, если можно взять ascii-art и иметь туеву кучу всего путём обучения себя самого некоторым мысленным преобразованиям? Наподобие integr f a b == $\int_{a}^{b}{f(x)dx}$. M>Зачем пользовать компьютер, если можно научиться думать, а не заставлять железяку делать это вместо себя?
Именно. Именно!
Компьютер надо использовать для общения.
M>>>Но всё равно код перестанет быть текстовым, через 5, 10, да хоть 20 лет. Зачем цепляться за этот текст, не лучше ли потратить силы на реализацию нетекстового представления? T>>Потому, что текст экономней. M>Для наколенных поделок.
Именно!
А из них всё и растёт.
T>>eDSL (embedded domain specific language, он же DSEL) — это язык, встроенный в другой язык. За примером
M>resolveNameR в лучших традициях, находит все имена (в другом месте foreach вызывается), или проверяет есть ли такое имя (в другом месте if вызывается). M>Это тебе достаточный eDSL?
Если ты eDSL считаешь встроить Kiev в Kiev, то да, достаточный. Если считать eDSL встраиванием заметно отличного по синтаксису и семантике языка в другой, то нет, недостаточный.
Поскольку я считаю, что правильный eDSL это eDSL по второму варианту, то мой вывод — твой eDSL недостаточно e и недостаточно DS. Но вполне себе L.
T>>Ура! Ты самостоятельно додумался до pretty-printing combinators совместно со стрелками. M>Там нечего придумывать. Бери больше кидай дальше.
Именно!
За что мы его и любим.
M>>>Так понемногу решаем проблемы, одну за другой, по мере их актуализации. Поэтому я и говорю, что это ещё не разработанная область, редактирование не-текстовых программ ещё развивать и развивать. Поэтому и MPS так сложен в освоении, и ещё не настолько удобен для работы. T>>MPS сложен в освоении и не удобен в работе потому, что нет чёткой теоретической основы. Поэтому и разработка его сложна. M>Теоретическая основа приходит из практики, а не наоборот.
Дело в том, что с моей точки зрения всё, что им надо, уже разработано. Бери и комбинируй. Причём даже есть средства для удобного комбинирования. Ан нет, считается, что они делают что-то новое, копать-колотить, гордятся новизной.
Ходят по полю поясных граблей со своей манией величия.
Мне они не нравится исключительно этим. Да и ты тоже, чего уж скрывать.
T>>Ты же постоянно изобретаешь что-то, давно пользователями Хаскеля изобретённое и доступное в статьях. M>Ты просто всё, что видишь, сводишь к хаскелю. Поэтому, ничего кроме хаскеля и не видишь.
Я вижу системы переписывания термов и атрибутные грамматики. Я вижу комбинаторы: разбора, красивой печати, создания структурных редакторов.
Я вижу, что всё это было разработано товарищами из сообщества Хаскеля.
Я вижу, как всё это ты изобретаешь по новой.
Я вижу не только Хаскель.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[18]: Программирование, от монолога к диалогу с компьютеро
А. Ну та та барышня тоже за 3 месяца выкатила рабочий вариант конфигурации их сборок.
В обоих случаях время ушло на освоение системы, а про время создания реальных продуктов на этих системах для опытных пользователей мы можем только гадать.
То, что она сделала за 3 месяца я могу на SymADE за неделю сделать. Подозреваю, что и на MPS они тоже так могут.
T>Я с работы по ЖЖ искать толком не могу.
T>>>Ну, вот тебе исчо: http://krlz.livejournal.com/57813.html T>>>Та, ещё, феерия. Пир духа! M>>Ну не месяц же он это делал.
T>Да то же самое делается на любом ФЯ за часы. Если сравнивать функциональность — создать DSL для описания разборщиков.
Где за часы? У vshabanov-а парень выкатил за 4 месяца, а не за часы.
T>Производительность программиста разнится в разы, прошу прощения за каламбур.
T>Java под Eclipse — это не язык ваапстче. Ничего нельзя сделать, а то, что всё-таки можно сделать, надо повторить от двух до бесконечности раз.
Писал тут один type inference и функциональные примочки для Java. Scala получилась. Чегой-то тебе тоже не понравилась.
А ведь "лучшие умы человечества!" (это я тебя копирую) писали.
M>>>>Если hello world писать, то и 10% не наберётся. M>>>>А если тебе внести изменения в JVM, которая работает на нескольких платформах и в сотне конфигураций, то будет не в 2 раза, а в 10 раз быстрее. Проверено. T>>>См. статью про ehc, да. M>>Кто это?
T>Essential Haskell Compiler, я ссылку давал.
M>>Это тебе достаточный eDSL?
T>Если ты eDSL считаешь встроить Kiev в Kiev, то да, достаточный. Если считать eDSL встраиванием заметно отличного по синтаксису и семантике языка в другой, то нет, недостаточный.
По синтаксису отличный — не могу. Потому как в SymADE нету синтаксиса. По семантике тоже не понятно, как должен отличаться, ведь он же eDSL, встроенный.
SQL тебе встроить? Я бы встроил, да мне без надобности.
Вот, скажем, у меня через такой eDSL определяется синтаксис выражений — ключевые слова и операторы (с приоритетом, ассоциативностью, и информацией как строить семантические узлы дерева). Увы, показать не могу, загружается из xml дампа (сейчас делаю загрузку из бинарного дампа, чтоб быстрее и удобнее). Редактируется либо в SymADE, но можно и ручками в XML (иногда бывает редактор поломан).
T>>Отлично. Сведи поведение противников FEAR к кнопке "выскочить 10 немцев". M>Сводили тут одни, пришлось им своё IDE писать для этого M>http://www.thegluefactory.com/forums/showthread.php?t=5571 M>Сколько там редакторов перечиcлено?
Сколько из них относятся к ИИ?
Как свести ИИ FEAR к кнопке "выскочить 10 немцев"? (просто я ответа так и не увидел)
T>>>>Сравни это с опытом vshabanov, когда студент, практикант, за полгода выкатил рабочий вариант конфигуратора игр на Хаскеле. T>>>>Овчинка выделки не стоит. M>>>ну так давай ссылку, буду сравнивать. T>>http://thesz.livejournal.com/666023.html?thread=4492455 M>А. Ну та та барышня тоже за 3 месяца выкатила рабочий вариант конфигурации их сборок. M>В обоих случаях время ушло на освоение системы, а про время создания реальных продуктов на этих системах для опытных пользователей мы можем только гадать. M>То, что она сделала за 3 месяца я могу на SymADE за неделю сделать. Подозреваю, что и на MPS они тоже так могут.
Не могут. У них ЯП — Java. И с неё они не сойдут, потому, как боятся.
T>>Я с работы по ЖЖ искать толком не могу.
T>>>>Ну, вот тебе исчо: http://krlz.livejournal.com/57813.html T>>>>Та, ещё, феерия. Пир духа! M>>>Ну не месяц же он это делал. T>>Да то же самое делается на любом ФЯ за часы. Если сравнивать функциональность — создать DSL для описания разборщиков. M>Где за часы? У vshabanov-а парень выкатил за 4 месяца, а не за часы.
Ты текст-то вообще читаешь? По ссылке выше krlz писал разборщики. Писал долго и нудно. То же самое начинающим мной писалось за часы, после сравнимого с krlz по времени изучения статей про разборщики.
T>>Производительность программиста разнится в разы, прошу прощения за каламбур. T>>Java под Eclipse — это не язык ваапстче. Ничего нельзя сделать, а то, что всё-таки можно сделать, надо повторить от двух до бесконечности раз. M>Писал тут один type inference и функциональные примочки для Java. Scala получилась. Чегой-то тебе тоже не понравилась. M>А ведь "лучшие умы человечества!" (это я тебя копирую) писали.
Именно. Из-под OCaml Java вылезает. Кому это может понравиться?
M>>>Это тебе достаточный eDSL? T>>Если ты eDSL считаешь встроить Kiev в Kiev, то да, достаточный. Если считать eDSL встраиванием заметно отличного по синтаксису и семантике языка в другой, то нет, недостаточный. M>По синтаксису отличный — не могу. Потому как в SymADE нету синтаксиса. По семантике тоже не понятно, как должен отличаться, ведь он же eDSL, встроенный.
Бейсик императивный, на функциональном Хаскеле.
Бейсик Императивный
А Хаскель — язык-носитель, куда бейсик был e(mbedded), — функциональный.
Я ассемблеры на Хаскеле писал. Императивные. Встроенные. На функциональном Хаскеле.
В чем проблемы-то соорудить язык с отличной от языка-носителя (host language) семантикой?
Более того, посмею утверждать, что сооружать язык с семантикой языка-носителя смысла не имеет.
M>SQL тебе встроить? Я бы встроил, да мне без надобности. M>Вот, скажем, у меня через такой eDSL определяется синтаксис выражений — ключевые слова и операторы (с приоритетом, ассоциативностью, и информацией как строить семантические узлы дерева). Увы, показать не могу, загружается из xml дампа (сейчас делаю загрузку из бинарного дампа, чтоб быстрее и удобнее). Редактируется либо в SymADE, но можно и ручками в XML (иногда бывает редактор поломан).
Это не eDSL. Это DSL, поскольку он внешний по отношению к языку-носителю.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[20]: Программирование, от монолога к диалогу с компьютеро
Здравствуйте, thesz, Вы писали:
T>>>Отлично. Сведи поведение противников FEAR к кнопке "выскочить 10 немцев". M>>Сводили тут одни, пришлось им своё IDE писать для этого M>>http://www.thegluefactory.com/forums/showthread.php?t=5571 M>>Сколько там редакторов перечиcлено?
T>Сколько из них относятся к ИИ? T>Как свести ИИ FEAR к кнопке "выскочить 10 немцев"? (просто я ответа так и не увидел)
ИИ у них для солдат, а не для "выскочило 10 немцев". Для выскочки у них, видимо триггер на карте.
Для ИИ наверное GDBEdit.
Вот тут у него http://web.media.mit.edu/~jorkin/gdc2006_orkin_jeff_fear.doc скриншот от этого редактора
T>>>>>Сравни это с опытом vshabanov, когда студент, практикант, за полгода выкатил рабочий вариант конфигуратора игр на Хаскеле. T>>>>>Овчинка выделки не стоит. M>>>>ну так давай ссылку, буду сравнивать. T>>>http://thesz.livejournal.com/666023.html?thread=4492455 M>>А. Ну та та барышня тоже за 3 месяца выкатила рабочий вариант конфигурации их сборок. M>>В обоих случаях время ушло на освоение системы, а про время создания реальных продуктов на этих системах для опытных пользователей мы можем только гадать. M>>То, что она сделала за 3 месяца я могу на SymADE за неделю сделать. Подозреваю, что и на MPS они тоже так могут.
T>Не могут. У них ЯП — Java. И с неё они не сойдут, потому, как боятся.
Они для ant-а написали этот конфигуратор, ant это make с xml конфигурацией. То есть это не java.
T>>>Я с работы по ЖЖ искать толком не могу.
T>Ты текст-то вообще читаешь? По ссылке выше krlz писал разборщики. Писал долго и нудно. То же самое начинающим мной писалось за часы, после сравнимого с krlz по времени изучения статей про разборщики.
Он не только парсер писал, он ещё и IDE к нему писал.
Ты тоже парсер за часы не напишешь, не имея в руках библиотек/тулзы, который это будет разбирать.
Вы там как один заявили, что написали свои парсеры, на комбинаторах и прочее. И повыкидывали. Потому как всё равно хуже чем ANTLR получилось.
Насколько я понимаю, он писал, что докторская — это ANTLR, а вы решили, что он про наколенный парсер.
M>>>>Это тебе достаточный eDSL? T>>>Если ты eDSL считаешь встроить Kiev в Kiev, то да, достаточный. Если считать eDSL встраиванием заметно отличного по синтаксису и семантике языка в другой, то нет, недостаточный. M>>По синтаксису отличный — не могу. Потому как в SymADE нету синтаксиса. По семантике тоже не понятно, как должен отличаться, ведь он же eDSL, встроенный.
T>Бейсик императивный, на функциональном Хаскеле.
T>Бейсик Императивный
T>А Хаскель — язык-носитель, куда бейсик был e(mbedded), — функциональный.
T>Я ассемблеры на Хаскеле писал. Императивные. Встроенные. На функциональном Хаскеле.
T>В чем проблемы-то соорудить язык с отличной от языка-носителя (host language) семантикой?
T>Более того, посмею утверждать, что сооружать язык с семантикой языка-носителя смысла не имеет.
Я логический язык вставил. Логической парадигмы. В императивный Kiev. Тебе этот пример не подошёл.
Так скажи, что ты хочешь увидеть.
Но Kiev не был предназначен для расширения синтаксиса. Вообще. Для этого предназначен SymADE.
M>>SQL тебе встроить? Я бы встроил, да мне без надобности. M>>Вот, скажем, у меня через такой eDSL определяется синтаксис выражений — ключевые слова и операторы (с приоритетом, ассоциативностью, и информацией как строить семантические узлы дерева). Увы, показать не могу, загружается из xml дампа (сейчас делаю загрузку из бинарного дампа, чтоб быстрее и удобнее). Редактируется либо в SymADE, но можно и ручками в XML (иногда бывает редактор поломан).
T>Это не eDSL. Это DSL, поскольку он внешний по отношению к языку-носителю.
Ну как сказать. В нём определяются операторы и пр. Другого способа определить операторы в Kiev сейчас нету. У него даже встроенных операторов нету. Все через этот встроенный язык определяются.
Ты скажи, что ты хочешь увидеть в качестве примера eDSL. Определение синтаксиса? Ни Kiev ни SymADE для расширения текстового синтаксиса не предназначены (не считая задаваемых программистом операторов). Расширения Kiev-а? У него куча всего сделана через расширения, через внешне подключаемые плагины. Однажды на работе попросили сделать функции, которые в качестве кода имели XPath (и работали с DOM моделью XML-я). Ну, я такой плагин соорудил за день. Синтаксис у kiev-а не менял, XPath задавал в строке, синтаксис не проверял (ну, за день то не напишешь, было-бы надо — проверял бы, но это подольше надо писать). Правда, в итоге не понадобилось. Это подойдёт в качестве eDSL? XPath всё-ж не ява.
T>>>>>>Сравни это с опытом vshabanov, когда студент, практикант, за полгода выкатил рабочий вариант конфигуратора игр на Хаскеле. T>>>>>>Овчинка выделки не стоит. M>>>>>ну так давай ссылку, буду сравнивать. T>>>>http://thesz.livejournal.com/666023.html?thread=4492455 M>>>А. Ну та та барышня тоже за 3 месяца выкатила рабочий вариант конфигурации их сборок. M>>>В обоих случаях время ушло на освоение системы, а про время создания реальных продуктов на этих системах для опытных пользователей мы можем только гадать. M>>>То, что она сделала за 3 месяца я могу на SymADE за неделю сделать. Подозреваю, что и на MPS они тоже так могут. T>>Не могут. У них ЯП — Java. И с неё они не сойдут, потому, как боятся. M>Они для ant-а написали этот конфигуратор, ant это make с xml конфигурацией. То есть это не java.
ЯП — Java.
T>>>>Я с работы по ЖЖ искать толком не могу. T>>Ты текст-то вообще читаешь? По ссылке выше krlz писал разборщики. Писал долго и нудно. То же самое начинающим мной писалось за часы, после сравнимого с krlz по времени изучения статей про разборщики. M>Он не только парсер писал, он ещё и IDE к нему писал. M>Ты тоже парсер за часы не напишешь, не имея в руках библиотек/тулзы, который это будет разбирать.
Правильно. Не за часы.
За считанные минуты.
Ядро разборщика на Хаскеле — десять строк. return (1), bind (3), mzero (1), mplus (1). Строгий mplus — ещё два строки.
Ещё десять-пятнадцать строк кода — вспомогательные комбинаторы (many, many1, sepBy, sepBy1, bracket и тп).
25 строк кода — это час работы максимум.
Да я первый раз, когда писал, потратил на понимание с написанием и проверкой два или три часа.
M>Вы там как один заявили, что написали свои парсеры, на комбинаторах и прочее. И повыкидывали. Потому как всё равно хуже чем ANTLR получилось.
Это где это мы все, как один заявили? Перечислишь?
M>Насколько я понимаю, он писал, что докторская — это ANTLR, а вы решили, что он про наколенный парсер.
Да, блин, что-то типа ANTLR пишется на Хаскеле за дни. Я для себя написал генератор кода а-ля Happy для моего монадического разборщика, потом выбросил, потому, что неудобен в использовании оказался (плохо совместим с REPL).
M>>>>>Это тебе достаточный eDSL? T>>>>Если ты eDSL считаешь встроить Kiev в Kiev, то да, достаточный. Если считать eDSL встраиванием заметно отличного по синтаксису и семантике языка в другой, то нет, недостаточный. M>>>По синтаксису отличный — не могу. Потому как в SymADE нету синтаксиса. По семантике тоже не понятно, как должен отличаться, ведь он же eDSL, встроенный. T>>Бейсик императивный, на функциональном Хаскеле. T>>Бейсик Императивный T>>А Хаскель — язык-носитель, куда бейсик был e(mbedded), — функциональный. T>>Я ассемблеры на Хаскеле писал. Императивные. Встроенные. На функциональном Хаскеле. T>>В чем проблемы-то соорудить язык с отличной от языка-носителя (host language) семантикой? T>>Более того, посмею утверждать, что сооружать язык с семантикой языка-носителя смысла не имеет.
M>Я логический язык вставил. Логической парадигмы. В императивный Kiev. Тебе этот пример не подошёл.
Ты не понимаешь, по-моему. То, что ты расширил язык логической парадигмой, не делает логическое подмножество языка DSEL. Это расширение языка Java логической парадигмой вычислений, получившийся язык называется Kiev.
Я, как-то, написал библиотечку на Хаскеле, которая позволяла делать нетлисты. По виду всё это очень напоминало Verilog. Это был встроенный язык. Вот я встроилв полтора десятка строк на Хаскеле ассемблер.
Я Хаскель ничем не расширял. Я писал на нём, как на языке описания аппаратуры Verilog. Это был DSEL. Я прикидывал программы на ассемблере на Хаскеле. Снова на DSEL.
Тот самый бейсик — DSEL.
Твой Kiev — расширенная Java.
M>Так скажи, что ты хочешь увидеть. M>Но Kiev не был предназначен для расширения синтаксиса. Вообще. Для этого предназначен SymADE.
Не надо никакого расширения синтаксиса. На Хаскеле можно писать в синтаксисе Хаскеля, но на бейсике, в синтаксисе Хаскеля, но на Верилоге, в синтаксисе Хаскеля, но на bison.
(На Агде, похоже, ещё круче можно.)
На Kiev этого нельзя. Kiev не проектировался для этого. Ты ни разу не делал DSEL.
У тебя нет опыта разработки языков, ориентированных на DSEL.
Дальше продолжать нет смысла.
M>>>SQL тебе встроить? Я бы встроил, да мне без надобности. M>>>Вот, скажем, у меня через такой eDSL определяется синтаксис выражений — ключевые слова и операторы (с приоритетом, ассоциативностью, и информацией как строить семантические узлы дерева). Увы, показать не могу, загружается из xml дампа (сейчас делаю загрузку из бинарного дампа, чтоб быстрее и удобнее). Редактируется либо в SymADE, но можно и ручками в XML (иногда бывает редактор поломан).
T>>Это не eDSL. Это DSL, поскольку он внешний по отношению к языку-носителю.
M>Ну как сказать. В нём определяются операторы и пр. Другого способа определить операторы в Kiev сейчас нету. У него даже встроенных операторов нету. Все через этот встроенный язык определяются. M>Ты скажи, что ты хочешь увидеть в качестве примера eDSL. Определение синтаксиса? Ни Kiev ни SymADE для расширения текстового синтаксиса не предназначены (не считая задаваемых программистом операторов). Расширения Kiev-а? У него куча всего сделана через расширения, через внешне подключаемые плагины. Однажды на работе попросили сделать функции, которые в качестве кода имели XPath (и работали с DOM моделью XML-я). Ну, я такой плагин соорудил за день. Синтаксис у kiev-а не менял, XPath задавал в строке, синтаксис не проверял (ну, за день то не напишешь, было-бы надо — проверял бы, но это подольше надо писать). Правда, в итоге не понадобилось. Это подойдёт в качестве eDSL? XPath всё-ж не ява.
Нет, не подойдёт. По-моему, конечно. Но не подойдёт. Плагины не засчитываются, всё должно быть в пределах синтаксиса исходного языка. Ты же это делал плагинами, это те же самые макросы, вид сбоку.
For this style of programming to work well, the syntax of the generic language must be flexible and expressive enough to "get out of the way" of the embedded DSL. That usually means that the host language has a very minimal syntax. The technique can easily be used in the LispLanguage, HaskellLanguage, ToolCommandLanguage ForthLanguage and SmalltalkLanguage, but is much harder to use in the JavaLanguage, for example.
Вот поэтому-то я не могу считать тебя имеющим опыт во встраивании языков в язык — ты всю жизнь пользовался Java, где это практически невозможно. И именно поэтому ты меня всё ещё не можешь понять.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
