Здравствуйте, tid, Вы писали:
tid>Я имею ввиду не документацию, а небольшое описание деталей.
tid>То есть почему ты создал свой язык, чем он отличается (хотя бы в основном) от java, какие новшества.
Язык я свой создал по причине того, что я люблю делать языки программирования.
Желание улучшить свой текущий язык программирования я пытался неоднократно (лет 15 назад пытался сделать макросы для С/С++ вроде тех, что сделаны в Nemerle).
Лет 10 назад написал таки расширенную java. Понадобавлял туда кучу всего, и в результате пришёл к тому, что это это не выход. С ростом количества фич в языке они начинают конфликтовать друг с другом, всё сложнее поддерживать целостность языка. И самое обидное — всех необходимых фич в язык не добавишь. Каждый новый проект, который я пытался делать на своём языке — требовал новых возможностей, или изменения поведения старых. В результате я пришёл к выводу, что не имеет смысла развивать язык добавляя к нему новые возможности, а нужно сделать нормальные возможности для мета-программирования.
Вариант с макросами я рассматривать не стал (был опыт попытки их реализации, и все ограничения и проблемы этого подхода были мне знакомы).
Пару лет я просто ничего не делал, поскольку не знал что именно делать.
Потом мне пришла в голову идея, которая рано или поздно приходит в голову всем разработчикам языков и IDE — использовать дерево (внутреннее представление) вместо текста.
Я сделал прототип, поплясав от самой печки, то есть имея в распоряжении только понятия "символ", "пространство" (контейнер), попробовал реализовать через них всё остальное. Ну, чтоб уж совсем мета-программирование получилось. В результате я понял, что теория это хорошо, но это уж слишком высокий уровень абстракции, надо что-то более приземлённое взять в качестве основы, а то так оно в теории работать и останется.
Я взял свой компилятор, и переписал его в соответствии со сформировавшимися к тому времени представлениями о SOP (семантическом программировании).
Все (почти все) расширения, которые я добавлял (и которые появились в результате развития java), я сделал не hardcoded, а в виде плагинов. Сделал удобную работу с семантическими понятиями (узлами дерева программы), добавил упрощённое мета-программирование (когда дерево не вручную модицицируется, а макросами, которые реализованы просто в виде ещё одного плагина).
Ну и стал делать IDE к этому компилятору. Вот этот процесс длится уже несколько лет (с перерывами на рождение ребёнка), в свободное от основной работы время.
В язык понадобавлено много чего (ещё когда он был просто расширением к яве, а не своеобразной библиотекой для мета-программирования).
Multimethods, closures, mixins, forwarding (наследование агрегированием, делегированием), properties (доступ к полу через getter/setter), user-defined operators & operator overloading, assert/trace/work-by-contract, встроенный движок логического программирования (поиск решений с бэктрекингом, что-то вроде интегрированного пролога), switch по типам, goto, битовые поля (упакованные битовые поля), части из pizza (был такой проект у Мартина Одерски, который перерос в явовские параметризованные типы и scala), параметризованные типы без erasure (параметры доступны в рантайме), расширения для работы с деревьями, для генерации специальной мета-информации для SymADE, view (что-то вроде existential types) и так далее.
Почти от всего можно было-бы отказаться или вынести в отдельный код, ради работы в нормальной IDE, но без специальных расширений и кодогенерации для работы с деревьями будет настолько грустно и нереально сложно, что я не могу отказаться от своего языка/компилятора.
tid>В двух словах как устроена среда и общее видение дальнейшего процесса.
Весь код доступен среде в виде семантических узлов. Работает с ними она через мета-информацию сгенерированную компилятором.
Есть язык для задания отображения для конкретных узлов, это отображение рисуется на Canvas, или (если присутствуют только текстовые элементы) может быть использовано для экспорта в текстовое представление.
Редактор — структурный. Можно посмотреть на документ с картинками (на сайте есть, в документации). Собственно, идея практически та-же, что и в MPS (поскольку задача одна и та-же — редактирование непосредственно дерева программы). Вообще, нынешнее состояние очень похоже на MPS, только менее доделанное.
Разница в том, что у меня в дереве хранятся семантические узлы, а у MPS синтаксические.
Что дальше.
Главная задача для развития среды — это наконец реализовать IDE для редактирования кода на моём языке программирования.
Тут надо решить ещё много задач. Главная задача — доделать projections семантического дерева в синтаксические деревья.
Вторая задача — это редактирование синтаксических деревьев. Что до редактирования декларативной части — оно было удобно и раньше, с ним почти никаких проблем.
А вот редактирование списков токенов надо доделывать. Теоретически до такого уровня, чтоб его редактирование было максимально похоже на редактирование текста Word и прочих WYSIWYG редакторах. Сам GUI написан на Java, и почти вся эта работа может делаться в Java.
Есть ещё работа по собственно IDE — фоновая компиляция, удобное выведение ошибок и прочее.
Есть задачи по работе с деревьями как таковыми. Например, сейчас они дампятся в XML. Это и долго (для экспорта и импорта), и приводит к необходимости линковки (резолвинга) символов после загрузки дерева из дампа. Хотелось-бы написать экспорт в binary формат, который просто можно было-бы сохранить и загрузить как snapshot дерева. Это было-бы значительно быстрее и решило ещё несколько мелких проблем. Ну, и экспорт/импорт этого бинарного формата в текст (вроде XML или json и пр). Эту часть работы можно легко сделать на обычной Java.
Далее, необходимо что-то делать с версионностью семантических понятий. Они имеют тенденцию меняться со временем, и надо сделать с одной стороны, поддержку указания версий, и с другой стороны, конвертацию из старой версии в новую. Попутно это приведёт к созданию специального языка описания трансформации дерева, возможности декларативно задавать простые projections дерева и пр. Эту часть работы можно почти полностью делать в SymADE (как IDE), без глубокого залазанья в потроха компилятора.
Безнес-часть проекта заключается в доработке IDE до состояния беты, и выхода на бизнес-ниши где технология вроде SymADE/MPS может быть использована (с большим эффектом) уже сейчас, при минимальной адаптации. Соответственно, если инвесторы дадут денег (от 0.5 до 1 лимона баксов), то приоритеты изменятся, комманда будет заниматься не столько доведением SymADE до состояния возможности редактировать код для моего компилятора, сколько доведением его до состояния возможности редактировать код для программ из этих ниш на IT рынке.
Есть ещё задачи, которые могут стать приоритетными при изменении условий — сделать плагин для Eclipse (GUI умеет работать как со Swing, так и с SWT), перейти на .NET платформу (написать backend, заменить прямую работу с базовыми объектами вроде string, hashtable на работу с концепциями строк, хэш-таблиц, для которых будет генерироваться разный код для JVM и .NET) и так далее.
Когда будет нормально работать IDE, к этому времени уже, наверное окончательно, установится API компилятора и внешний вид GUI, и можно будет писать документацию и систему тестирования. То есть когда будет бета — надо будет делать релиз
Здравствуйте, thesz, Вы писали:
T>Ты уж извини, но дальше мне совсем неинтересно. Ты меня не поймёшь, поскольку не желаешь отвечать на вопросы, задаваемые тебе, а я не хочу объяснять тебе долго и нудно истины, ставшие для меня прописными.
А как же просвещение? Тут вас много читают. У вас очень здоровый (в смысле достаточно конструктивный) спор. Я, например, много почерпнул и от тебя и от твоего оппонента.
Программирование, от монолога к диалогу с компьютером
Переход к написанию программы компьютером — это переход от монолога, к диалогу. При этом, так же как и при диалоге человека с человеком, у компьютера должна быть своя, внутренняя модель программы. У компьютера должна быть возможность вводить новые понятия (в терминах которых эта модель и будет выражена). Он будет общаться с человеком (программистом) на некотором языке (языках), достаточно независимом от внутренней модели программы. Эта модель будет изменяться не непосредственно программистом, а в результате диалога между компьютером и программистом. Эти языки общения будут специально приспособлены для удобства понимания человеком и его команд, а модель программы внутри компьютера будет приспособлена для работы с ней компьютером, а не человеком.
Здравствуйте, thesz, Вы писали:
T>Обобщённое программирование? GADT? Зависимые типы?
T>Ты всё это знаешь, точно можешь указать на слабые места?
Программы — это код+данные. Структуры данных и связанный с ними код не всегда удобно описывать (даже не сам код, а мета-код), используя существующие ЯП, иногда хочется наиболее удобного и декларативного (банальности, собственно).
T>Lazy не навязан, а предложен для использования в качестве самого удобного из умолчаний. T>Тебе тоже объяснить, почему он удобен, или ты, всё же, читаешь RSDN?
Он неэффективен для обработки массивов заведомо известной длины или иных фиксированных структур, например, мне для VoIP, кодеков, фильтрации и работы с сокетами — это седло для коровы. Для GUI — аналогично. Всё хорошо к месту.
T>Графовые грамматики сложней обычных. См. DiaGen. Их разбор возможен толком только с помощью CYK алгоритма (не самый сложный в реализации, это не GLR, но сложней многих).
Причём тут формальные грамматики к задаче интерпретации готовых деревьев? Где тут "цепочки" символов, требущих построения графов из них? В графических CAD-тулзах есть способы текстового сохранения и обратной загрузки, но там грамматика простейшая, предназначенная для машинного чтения, а не человеческого, по-сути — сериализация/десериализация состояния графа, что не сложно (не сложнее похожей задачи дизайнера Windows.Forms).
T>Вообще, здесь мы бескомпромиссно задействуем сразу две области — пользовательского интерфейса и языков программирования. В обеих хватает своих предпочтений, обе очень сложны.
И что? Отказаться от помощи графического интерфейса в процессе программирования?
T>С текстовым представлением мы ведём бой всего в одной области, что выгодно.
Да что-то проигрываем, и по крупному, т.к. контекстно-зависимые грамматики слишком сложны в реализациях парсеров. А контекстно-свободные слишком бедны для выражения. Почему бы не работать напрямую с "контекстом", используя более простые контекстно-свободные грамматики для каждого выделенного случая? (Каждая контекстно-зависимая легко разбивается на систему контекстно-свободных). В моделирующих тулзах иногда доступны более одного языка для записи кода. Формулы удобно писать на одном, ИИ-блоки — на другом, автоматы — на третьем и т.д. до бесконечности. А сейчас даже в рамках одного проекта практически невозможно использование смеси языков. Тут нужна была некая довольно-таки мощная интероперабельная платформа исполнения, мне .Net или Java кажется подходящими вариантами.
T>>>Simulink работает в узкой области обработки сигналов, его расширение очень сложно. V>>Он работает в "узкой области" моделирования как такового, необязательно обработки сигналов. Я моделировал как аналоговые и цифровые схемы, так и лексические анализаторы и алгоритмы сервисного обслуживания (СМО). Напр., исходный код dejitter-а для VoIP невелик по объёму, но без качественного предварительного моделирования получается штукенция, нормально работающая только в условиях близком к идеальным (это я намекаю на то, что куча имеющихся исходников по этой теме в сети — полнейшее неграмотное г-но).
T>Скажи, пожалуйста, ты формальную спецификацию этого дела можешь написать? T>В любом виде.
Какого дела? Самих моделирующих тулзов, или приведённого примера с джиттер-буфером?
T>Если можешь, почему ты выполнял моделирование, а не разработку по спецификации?
Спецификация — джиттер-буфер. По сути, обычная хрень из ТАУ, параметры же конкретной САУ — суть система из пропорциональных, интегральных и дифференциальных членов, в структурном виде — это кол-во, тип узлов и способы их соединений (прямые и обратные связи). На кончике пера родить параметры этой модели ИМХО на порядок трудоёмкее, чем отладить на модели. В своё время, лет 15 назад мы обычно писали свои моделирующие тулзы для задач САУ (расчитывали возможные конфигурации схем), т.к. решить конкретную систему уравнений мало, надо для начала задать кол-во и вид уравнений (то бишь структуру схемы), и вот для игрищ с различными структурами моделирование и нужно, оно лишь обсчитывает как статические, так и импульсные характеристики схем. Для джиттер буфера это вылилось в кол-во следящих за кач-вом линии контуров и их T(тау) на фронт и спад условий (угу, схема нелинейная, т.е. её характеристика не представима в операторном виде, а значит на кончике пера родить вообще маловероятно). Так вот, большинство современных программ — суть нелинейные модели, отсюда сложности с выявлением их характеристик (которые, например, можно сравнивать со спецификацией с целью верификации).
Модель Тьюринга — это модель соб-сно вычислительного процесса по заданной программе, в то время как задача-то зачастую состоит в нахождении самой структуры некоей модели, работу которой будет описывать конкретная программа. Написать большую программу по уже полностью готовой "железобетонной" спецификации, где расписано всё — это даже на ассемблере за вполне конечное время можно сделать, но это ведь не задача. Задача — иметь "управляемый" код. Не тот, который "managed" в терминах .Net, а тот, который "живой", структуру которого можно менять небольшими усилиями, параметризовать и т.д., т.е. задача — совместить разработку спецификаций с программированием, проектирование — с логгируемым и анализируемым экспериментом. И мне, проведшему много лет в различных CAD-ах, хочется такой же CAD для программирования, ибо не считаю эту область настолько уж сложнее современной системотехники (местами — скорее ровно наоборот). Утопические рассуждения несколькилетней давности здесь: http://www.rsdn.ru/forum/message/1676773.1.aspx
Там, кстати, интересная мысль про "согласование входных сигналов", может напрямую быть интересна в плане верификации, ведь это нехилое ограничение. А вообще, прочти ту ссылку до конца. Мысль в том, чтобы отказаться от произвольного набора методов классов и "хаотического" их вызова, а всё взаимодействие осуществлять через очень небольшое кол-во универсальных контрактов, примерно как и работают ядра моделирующих тулзов.
T>Если не можешь, то на чём базируется твоя (подразумеваемая мной) уверенность в том, что моделирование показало и проверило всё, что надо, что ты добрался до условий, далеких от идеальных?
Конечно не всё, но это позволило создать довольно много экспериментов за небольшое время, чтобы подобрать подходящую структуру и её параметры, удовлетворяющую некоему диапазону внешних условий.
T>По-моему, это оно. В любом виде, графическом или нет.
Это какой-то минимум из уровня 0, извини. Мне не нужно конкретно "зашитые" св-ва типов в некоем ЯП, я хочу порождать и использовать произвольные св-ва типов (суть — накладывать произвольные требования/ограничения). Дело тут в том, что встраивать подобные синтаксические расширения до бесконечности нельзя без спотыкания об противоречивый синтаксис в итоге, уходить надо от "цепочечно-символьного" представления.
Кстати, в случае цикла с внешним условием описанная параметризация не поможет верификации.
А ведь вполне могли быть какие-то другие критерии, согласно которым данный тип вполне мог считаться проверифицированным.
T>>>Я не могу просто взять, и заточить Simulink на работу с 1С за выходные. V>>Как и твой Хаскель, но за некоторое конечное время — запросто. Складская логистика так и просится на графическое представление.
T>Мы ведём речь не о складской логистике, а об анализе ЯП и работе с какими-то представлениями программ.
T>Вот в случае Хаскеля я справлюсь с разбором и анализом программ на 1С за выходные. Или за пару выходных. Но не больше. Это не абстрактное "конечное время".
Тогда я не понял твою постановку, ибо она мне более чем неинтересна. У меня тут построитель парсера по модели Эрли валяется, так с разбором можно и быстрее справиться. А что ты подразумеваешь под "анализом"? Код 1С надо верифицировать относительно всей метаинформации о структуре/регистрах/разрешениях и т.д. — а она там не в исходниках (хотя, я не большой спец, как там метаинформация хранится).
T>>>А вот <b>разборщик с анализом</b>
написать за выходные на Хаскеле я могу. И ты можешь. Что я выберу? Почему ты выберешь иное? V>>Я выберу другое, потому что табличные сканеры по минимизированному ДКА работают примерно на порядок быстрее, чем построенные на паттерн-матчинге.
T>Преувеличение. Отличие не более, чем в три раза.
T>У тебя какие-то странные сведения, очень устаревшие и перекошенные.
Тем не менее, а смысл? Ну вот есть у меня парсер прямо из описания, зачем мне доп. приседания на Хаскеле?
Да еще в 3 раза медленнее, да еще непонятно сколько памяти ест, а табличный — нисколько, и возврат по "жадному" алгоритму ничего не стоит, в отличие от, где можно на проблемы со стеком нарваться в случае очень длинных входных цепочек (документы EDI по нескольку мег бывают). И еще не факт, что на этих больших цепочках сохранится отставание в 3 раза. В примере язык С, а синтаксическая вложенность и длина выражений в реальных структурированных программах очень невелика.
V>>Увы, тут ведь и обсуждать нечего, без каких-либо исходных требований. А вот если бы был уже готовый параметризуемый элемент модели — парсер, у которого в св-вах указываешь тип алгоритма (ДКА, LR, LL, Earley, LGR и т.д.) а ты ему просто грамматику подаешь (а лучше, чтобы он мог и сам по грамматике модель выбирать), то это не заняло бы целый мой выходной.
T>Ты опять уходишь в сторону.
T>Тут не только разборщик, тут ещё и анализ присутствует. Я его сейчас выделю жирным, и ссылку проставлю на сообщение. Разборщик только часть всего этого дела. И он будет хорошо работать только по заранее заданной верной грамматике. Если ты её толком не знаешь и нужны эксперименты, то добро пожаловать в мир комбинаторов разбора.
Как-то пока не работал с грамматиками для которых нет спецификаций. Даже с естественным английским работал.
T>Сколько из этих тонн человеко-лет пошли на визуальный редактор? Сколько ушло на готовые компоненты? Не было бы дешевле сделать это в текстовом виде?
Тогда его никто не купит за многие тыщи баксов.
И ведь популярный продукт, с чего бы это?
T>Вся индустрия разработки железа, за малым исключением, работает на VHDL/Verilog. Вот дураки!
Я же сказал, что полностью отказываться от текста непрактично. Местами быстрее руками настучать, особенно всякого рода формулы или таблицы с описаниями. Тем не менее, в notepad никто на VHDL не пишет, как-то всё в комплексе с графическими редакторами идёт, отчего бы это?
Опять же, нужен был некий стандарт, т.к. раньше в тулзах обычно было большое меню импорта/экспорта из/в различных конкурирующих продуктов. Скажем, набивать схемы было всегда удобнее в ORCAD, а разводить платы в PCAD, а моделировать еще где. Стандарты давно напрашивались.
V>>Аналогично, многоэтажные формулы, представленные в MathCAD куда как привычнее глазу, чем любое их "плоское" текстовое описание на любом ЯП, и в Хаскеле в т.ч. А это значит, что разбор этой формулы для меня займет куда как меньше времени и усилий.
T>lhs2tex. Если угодно.
И обратно, и двустороннее одновременное редактирование кода?
T>Используй Agda2, там ты можешь писать практически, что угодно. Идентификатор — это последовательность Unicode символов, без, буквально, пробелов и ещё десятка — шести скобок и всяких точек с запятыми. Плюс, в идентификаторе можно указывать куда можно вставлять какие выражения. if_then_else_, если помнишь.
Ладно, похоже, придётся плотнее посмотреть на Agda2.
T>>>Он существует с 1972 года, правда, постоянно развивается. Называется теорией типов или Martin-Lof type theory. V>>Это ты уже говорил, а "удобно" пользоваться в реальной разработке как? И почему до сих пор не используется в популярных языках?
T>В урезанном виде, насколько это поняли авторы языков — используется. См. шаблоны C++, например.
А что мне на них смотреть? Собаку на них съел в своё время. При богатой параметризуемости имеем сложности с декларативными ограничениями на св-ва типов. Т.е. это всё возможно (и даже набаловался прилично), но исходники превращаются в кашу из угловых скобок непонятной вложенности.
T>Подающих мысли тысячи, если не десятки тысяч. Умеющих быстро реализовать мысли на порядок меньше, умеющих проверить (довести до конца) ещё в десять раз меньше и умеющих признать (!) неправоту своих идей — единицы.
T>Поэтому я бы посмотрел на твою реализацию "базы знаний" IT.
А вот там по ссылке давал идею. Под "базой знаний" имел ввиду классифицированный набор параметризуемых компонент, вместе с доками, теориями и примерами, при условии наличия навигации по ней по критериям/запросам этот набор и превращается в классическую "базу знаний".
T>Это мне особенно интересно, поскольку у тебя до сих пор не получалось сделать это в текстовом представлении.
Да как тебе сказать. Баловался с разработкой программных гитарных процессоров (вернее — периодически балуюсь), есть компоненты обработки сигналов, есть минимальный универсальный набор интерфейсов для связи компонент, нужен графический редактор для более интересного баловства (угу, и чтобы ручки в "реал-тайм" крутить можно было). А то я должен остановить программу, подправить исходник, то бишь по другому соединить компоненты, подправить им предустановленные св-ва, откомпиллировать и запустить. Малость не так оперативно, как хотелось бы. Начал было плагин к студии разрабатывать, но там графический свой рутовый дизайнер практически с 0-ля писать надо, такие прелести. В одиночку — это уже перебор для хобби. Мне еще много чем хочется баловаться. Я еще рисовать люблю: http://www.contextfreeart.org/gallery/view.php?id=974 — неплохой язык, кстати, и напрашивается на некое таблично-структурное отображение. Обрати внимание на размер исходника.
T>Я педалирую эту тему потому, что ты не говоришь "у меня плохо получалось, думаю, с SymADE будет лучше, и вот почему", ты говоришь "у меня не получалось, а вот с SymADE магическим образом наверняка получится". Это крайне подозрительно.
Я лишь высказваю одобрение тому, что человек за свой счёт экспериментирует с темой, которая и мне интересна.
T>Я сейчас занят в создании схемотехнической системы. Там есть и редактор тоже. И мой транслятор с VHDL. Я знаю, что такое разработка визуальных редакторов, во что она обходится, не понаслышке. И я могу сравнивать с разработкой транслятора.
И я знаю, как раз пол-года назад графический редактор для conferencing white-board сдавали, вполне конечное человеко-время, на пару порядков меньше, чем разработать компилятор того же С++. Если бы не тупая (тупейшая!!!) завязка behaviour-классов из System.Design на виндовые окна, то еще больше времени сэкономили бы, а так пришлось как бы свой мини-фреймворк писать. Ну да для WPF гораздо больше готового, там редактор слепить довольно грамотно и нетрудоёмко можно. Я же говорю — зря товарищ свою задумка на Java пишет, хотя, учитывая возраст разработки — неудивительно.
В принципе, если увижу/придумаю/пойму "как надо", то графический редактор накатаю быстро, не волнуйся, ибо это будет сугубо инженерная задачка. А пока что в обсуждениях, типа "спроектировать интерфейс визуального редактора запросов" вот это вот угрёбище
Здравствуйте, tid, Вы писали:
tid>У тебя есть более подробная информация: структура Symade, описания классов, пакетов, форматов данных; что сделано, что планируется сделать?
Простой ответ — нету.
Развёрнутый:
По разным причинам.
1. Чтоб это написать — надо сесть и месяца три потратить только на это.
2. Оно устареет уже через несколько месяцев.
3. Описание "что делать" сильно зависит от бизнес-части проекта, под которую ищутся инвесторы; и вот когда инвестор найдётся — с этим можно будет определиться. Слишком разные области есть в программировании, и если делать для всей индустрии — то нужны многие миллионы баксов и годы работы. Если делать для какой-то ниши — то это намного меньше, и в деньгах и в сроках. Но нужно знать для какой!
4. Даже если бы оно и было, то новый человек просто не сможет освоить структуру проекта просто сев и прочитав документацию. Большой объём и очень разные части. От спецического языка программирования до специфической реализации и кодогенерации.
В большой проект люди входят постепенно. Решая какую-то, вначале несложную, потом всё сложней, реальную задачу. Во время этого процесса они знакомятся с достаточно большой частью проекта, и начинают в нём свободно ориентироваться. Так происходит всегда. Даже если этот продукт уже законченный, и на него есть документация и прочие спецификации — всё равно человек входит не через них. Просто в силу специфики устройства и когнитивных процессов нашего мозга.
Если у тебя есть какая-то задача, то я могу рассказать как её делать, с какой стороны подходить, описать общую структуру на текущий момент.
Если просто поиграться — то увы, пока она не дойдёт до стадии беты, что включает в себя и доведение до ума IDE, чтоб на неём можно было полноценно редактировать и отлаживать весь код, и включает в себя тот самый минимум документации — тогда уже можно будет его пощупать.
Здравствуйте, 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]: Программирование, от монолога к диалогу с компьютером
M>>>Ну покажи, где они это умеют. Цитатку там, документик, можешь сам код наваять. T>>Я ж тебе приводил. Ты даже отвечал. M>Не помню такого. И такого я бы не забыл. Ты либо меня с кем-то путаешь (может с MPS-овцем каким), либо не о том говоришь. M>Я тебя спрашиваю следующее — Coq, Agda2 — это доказатели теорем, доказатели каких-то свойство программы (используя систему типов); но могут ли они модифицировать код так, чтоб он удовлетворял заданным свойствам программы? Я этого нигде в них не нашёл. Вот ссылку на это я с тебя и прошу.
Выдачу кода надо писать.
Однако, в отличии от твоей системы, меньше вероятность ошибки и выше уровень описания. Это я про анализ и преобразования.
Что мне ещё подумалось.
Ты апеллируешь к самым низким программистским чувствам — в начале этой нитки ты апеллировал к чувству страха "будет ли у меня тут null pointer exception".
Я думаю, что игра на таких низких чувствах не может возвысить ни сам инструмент, ни его автора, ни, тем более, его пользователя.
Это шутка, конечно, но с правдой на девять десятых вместо обычной доли.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[4]: Программирование, от монолога к диалогу с компьютером
Здравствуйте, mkizub, Вы писали:
M>>2. Оно устареет уже через несколько месяцев.
M>Вообще вся эта затея с SymADE больше похожа на "пойди туда, не знаю куда — найдти то, не знаю что".
Имхо: после того, как автор проекта приходит к пониманию того, что он не знает цели своего проекта, то самое лучшее (как для проекта, так и для автора) -- выбросить проект нафиг.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[9]: Программирование, от монолога к диалогу с компьютером
Угу. До смысла парадокса, как я понял, ты не дочитал.
T>Это не отрицает предсказуемость результата канонического искусства.
То есть разницы между лубочными иконами и "Троицей" Рублёва ты не видишь? А если видишь, то как ты объяснишь, что и те и те писались по канону, а результат разный?
T>И чтобы два раза не вставать.
T>"Пойди туда, не знаю куда, принеси то, не знаю, что" лучше всего делать с наиболее быстроходными и грузоподъёмными инструментами.
T>Java/Kiev в эту категорию, по-моему, не попадают.
Попадают. Мне хочется это практически сделать, а не теоретически. Толку-то, что я напишу IDE которая ни в одну ОЗУ не влезет, по причине immutable структуры дерева программы, занимающего 100 мег в памяти. Покажи мне вообще хоть одну приличную IDE написанную на хаскеле. На лиспе я одну знаю, emacs называется — мне такой не подходит, в том числе и по причинам тормознутости.
Здравствуйте, Курилка, Вы писали:
К>Цитатка "на злобу дня":
К>
К>"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>Я пытаюсь себе представить Амундсена, думающего кому и как продать свою поездку на полюс, или Эйнштейна в размышлениях о продаже соотношения E=mc2. M>И ведь прибыльную вещь придумал, ядрёную бомбу, можно сказать.
Корабли бороздят просторы...
Уже не оригинально
P.S. Комментировать больше не буду, ибо не вижу смысла.
Re[13]: Программирование, от монолога к диалогу с компьютеро
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: Программирование, от монолога к диалогу с компьютером
M>Переход к написанию программы компьютером — это переход от монолога, к диалогу. При этом, так же как и при диалоге человека с человеком, у компьютера должна быть своя, внутренняя модель программы. У компьютера должна быть возможность вводить новые понятия (в терминах которых эта модель и будет выражена). Он будет общаться с человеком (программистом) на некотором языке (языках), достаточно независимом от внутренней модели программы. Эта модель будет изменяться не непосредственно программистом, а в результате диалога между компьютером и программистом. Эти языки общения будут специально приспособлены для удобства понимания человеком и его команд, а модель программы внутри компьютера будет приспособлена для работы с ней компьютером, а не человеком.
Неужели ты, наконец, разобрался с Coq (Epigram, Agda2 и тп)?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[2]: Программирование, от монолога к диалогу с компьютером
Здравствуйте, thesz, Вы писали:
T>Неужели ты, наконец, разобрался с Coq (Epigram, Agda2 и тп)?
Я вижу, ты так и не понял, о чём я писал.
Может Agda2 доказать, что в этом коде не будет NulPointerException?
if (this.a != null)
this.a.foo();
Доказательство этого требует дополнительного знания, исполняемся мы в single-threaded или multi-threaded режиме.
А это указываетя где-то в другом месте. Скажем, в коммандной строке компилятора.
И после всего этого, пусть мы попросили компьютер скомпилировать этот код в multi-threaded режиме, agda2 перепишет
этот код как
var tmp = this.a;
if (tmp != null)
tmp.foo();
или ей слабо? Я не говорю о выдаче ошибки или предупреждений. Я о реакции компьютера на просьбу создать максимально safe код при таких-то условиях выполнения программы.
Вот когда они это научатся делать — тогда будем с ними разбираться.
T>>Неужели ты, наконец, разобрался с Coq (Epigram, Agda2 и тп)? M>Я вижу, ты так и не понял, о чём я писал. M>Может Agda2 доказать, что в этом коде не будет NulPointerException? M>Вот когда они это научатся делать — тогда будем с ними разбираться.
Да умеют они так, умеют. Причём не ad hoc методами.
Видимо, ты так и не понял, зачем Agda2/Coq.
А с твоими творениями мы будем разбираться, когда у них будет основа не хуже, чем у Agda2/Coq.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[4]: Программирование, от монолога к диалогу с компьютером
Здравствуйте, thesz, Вы писали:
M>>Ну покажи, где они это умеют. Цитатку там, документик, можешь сам код наваять.
T>Я ж тебе приводил. Ты даже отвечал.
Не помню такого. И такого я бы не забыл. Ты либо меня с кем-то путаешь (может с MPS-овцем каким), либо не о том говоришь.
Я тебя спрашиваю следующее — Coq, Agda2 — это доказатели теорем, доказатели каких-то свойство программы (используя систему типов); но могут ли они модифицировать код так, чтоб он удовлетворял заданным свойствам программы? Я этого нигде в них не нашёл. Вот ссылку на это я с тебя и прошу.
Здравствуйте, thesz, Вы писали:
T>Выдачу кода надо писать.
Ну хорошо, пусть писать. Но где у них система поиска решения, что именно нужно поменять? Не доказать правильно/неправильно, а сказать — вот если тут поменять, то будет правильно.
T>Однако, в отличии от твоей системы, меньше вероятность ошибки и выше уровень описания. Это я про анализ и преобразования.
Неверно. В SymADE вообще сейчас нет никакого уровня и вероятности ошибки, поскольку никакого формализма в основу не положено.
Хочешь — пиши плагин проверяющий такие-то свойства ad hoc, хочешь — используй Coq для проверки этих свойств.
А уровень описания у меня заведомо выше. По той причине, что задача решается в терминах, максимально соответствующих решаемой задаче.
T>Что мне ещё подумалось. T>Ты апеллируешь к самым низким программистским чувствам — в начале этой нитки ты апеллировал к чувству страха "будет ли у меня тут null pointer exception". T>Я думаю, что игра на таких низких чувствах не может возвысить ни сам инструмент, ни его автора, ни, тем более, его пользователя. T>Это шутка, конечно, но с правдой на девять десятых вместо обычной доли.
Посмотри в зеркало.
Ты сам аппелируешь к этим чувствам, рассказывая, что формальная логика гарантирует нахождение ошибок. Сам в это веришь и хочешь уверить других. Вот возьмут они волшебный Coq, и найдёт он им все ошибки в программе. Хотя найти их и доказать правильность/неправильность программы он может только в отношении тех свойств программы, которые его запрограммировали искать. Запрограммируют искать null pointer — будет что-то анализировать и доказывать. Не запрограммируют — он скажет, что ошибки в программе нет. Запрограммируют искать для single-thread модели — будет пропускать ошибки возникающие в multi-thread модели. И по этой причине никакой у них анализ не лучше и не более общий. Потому как все эти свойства, которые от него требуют доказать — тоже доказываются на основе ad hoc моделей. Как в том примере, что ты мне давал для анализа и гарантии невозникновения блокировки программы из-за взаимных локов. Там они взяли и придумали ad hoc модель — все локи должны быть сравнены по приоритету, и тогда можно эти приоритеты сравнить и что-то доказывать. А если локи нельзя сравнить по приоритету — то извините, алгоритм не работает. И чем их работа, постоенная на введении специальных типов для анализа этих свойств, лучше, чем возможность ввести специальные семантические понятия и их анализировать той-же логикой — для меня загадка.
T>>Выдачу кода надо писать. M>Ну хорошо, пусть писать. Но где у них система поиска решения, что именно нужно поменять? Не доказать правильно/неправильно, а сказать — вот если тут поменять, то будет правильно.
Так это типами ограничивается.
Например, выкинуть просто так a <- b+c нельзя, надо доказать, что смысл программы не поменяется.
T>>Однако, в отличии от твоей системы, меньше вероятность ошибки и выше уровень описания. Это я про анализ и преобразования. M>Неверно. В SymADE вообще сейчас нет никакого уровня и вероятности ошибки, поскольку никакого формализма в основу не положено.
Это ты какую-то глупость говоришь, да. То, что никакого формализма нет, не означает, отсутствия уровня или вероятности ошибки.
M>Хочешь — пиши плагин проверяющий такие-то свойства ad hoc, хочешь — используй Coq для проверки этих свойств.
То есть, можно обойтись без SymADE? Ура!
SymADE — самая мощная система в мире!!! Она может всё, даже когда её не применяешь, а пользуешься Coq!!!
M>А уровень описания у меня заведомо выше. По той причине, что задача решается в терминах, максимально соответствующих решаемой задаче.
То есть, уровень есть и он выше.
"Мы в восхищении!" (С)МиМ
Ну, так покажи, как проверить (или доказать) коммутативность какой-либо бинарной операции над произвольным типом данных.
T>>Что мне ещё подумалось. T>>Ты апеллируешь к самым низким программистским чувствам — в начале этой нитки ты апеллировал к чувству страха "будет ли у меня тут null pointer exception". T>>Я думаю, что игра на таких низких чувствах не может возвысить ни сам инструмент, ни его автора, ни, тем более, его пользователя. T>>Это шутка, конечно, но с правдой на девять десятых вместо обычной доли. M>Посмотри в зеркало. M>Ты сам аппелируешь к этим чувствам, рассказывая, что формальная логика гарантирует нахождение ошибок. Сам в это веришь и хочешь уверить других. Вот возьмут они волшебный Coq, и найдёт он им все ошибки в программе. Хотя найти их и доказать правильность/неправильность программы он может только в отношении тех свойств программы, которые его запрограммировали искать. Запрограммируют искать null pointer — будет что-то анализировать и доказывать. Не запрограммируют — он скажет, что ошибки в программе нет. Запрограммируют искать для single-thread модели — будет пропускать ошибки возникающие в multi-thread модели. И по этой причине никакой у них анализ не лучше и не более общий. Потому как все эти свойства, которые от него требуют доказать — тоже доказываются на основе ad hoc моделей. Как в том примере, что ты мне давал для анализа и гарантии невозникновения блокировки программы из-за взаимных локов. Там они взяли и придумали ad hoc модель — все локи должны быть сравнены по приоритету, и тогда можно эти приоритеты сравнить и что-то доказывать. А если локи нельзя сравнить по приоритету — то извините, алгоритм не работает. И чем их работа, постоенная на введении специальных типов для анализа этих свойств, лучше, чем возможность ввести специальные семантические понятия и их анализировать той-же логикой — для меня загадка.
Сейчас мы зададим тебе вопрос на миллион долларов.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re: Два вопроса, один из которых на миллион долларов.
Сперва вопрос попроще. Долларов, эдак, тыщ на девятьсот девяносто с половиной.
Как известно, коммутативно-ассоциативные операции легко распараллеливаются.
Например, суммирование: вместо последовательного суммирования по одному элементу массива за раз, мы можем просуммировать левую половину параллельно с правой половиной, а потом их сложить.
Это доступно во всех stream-kernel параллельных системах, например, BrookGPU. Однако в них это свойство необходимо держать в голове программисту, сама система ничего не подскажет. Так и останется программа либо недопараллельной, лиоб излишне параллельной.
Вопрос: как в SymADE доказать коммутативность и ассоциативность некоторой операции?
Приведи пример, как это будет описано в SymADE. Текст, весь, от начала до конца. Чтобы мы могли сравнить с текстом на Agda2.
Теперь вопрос посложней. Как раз на миллион долларов ровно.
Вот программа сортировки пузырьком:
void bubble_sort(int* arr, int len) {
int i,j;
for (i=0;i<len-1;i++) {
for (j=0;j<i;j++) {
if (arr[j] > arr[j+1]) {
int t = arrj[j];
arr[j] = arr[j+1];
arr[j+1] = t;
}
}
}
} /* bubble_sort */
Она настолько не параллельна, насколько это возможно.
Прошу указать, какие изменения в коде этой программы необходимо сделать, чтобы программа сортировки пузырьком стала параллельной и что надо сделать в SymADE, чтобы реализовать все эти преобразования. Для SymADE прошу привести полный текст.
Вот эти два вопроса меня и волнуют.
Причем, второй вопрос действительно может принести миллион — это автоматическое распареллеливание, горячая тема.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[2]: Два вопроса, один из которых на миллион долларов.
Здравствуйте, thesz, Вы писали:
T>>>Выдачу кода надо писать. M>>Ну хорошо, пусть писать. Но где у них система поиска решения, что именно нужно поменять? Не доказать правильно/неправильно, а сказать — вот если тут поменять, то будет правильно.
T>Так это типами ограничивается.
Нет, это не типами ограничивается.
T>Например, выкинуть просто так a <- b+c нельзя, надо доказать, что смысл программы не поменяется.
Вот именно. Смысл. В приведённом мной примере (с null) поведение программы меняется, при использовании временной переменной.
Программа начинает себя вести по другому, она не будет бросать NPE, а в исходном варианте она могла его бросать.
Компилятор не вправе делать подобное кэширование (если это не оговорено в спецификации, в яве, кстати, оговорено, что компилятор
может делать такую оптимизацию, а может и не делать). Потому как оно меняет поведение программы.
Но по смыслу, который вкладывает программист в программу — подобное преобразование кода не меняет смысла программы. Программисту
не нужно там иметь exception. А бывают ситуации, когда программист именно хочет иметь exception.
Сейчас компиляторы ограничены формальными правилами — программа не должна менять своего поведения при оптимизации. Это и ставит
предел возможности автоматизации работы программиста компьютером. Это и есть предел задаваемый монологом.
Если же перейти к пониманию компьютером смысла программы, то он сможет автоматизировать частично (а в будущем практически полностью)
процесс кодирования. Но вот именно смысл и нужно вложить в компьютер, а не формальное соответствие скомпилированной программы коду
вбитому программистом.
T>>>Однако, в отличии от твоей системы, меньше вероятность ошибки и выше уровень описания. Это я про анализ и преобразования. M>>Неверно. В SymADE вообще сейчас нет никакого уровня и вероятности ошибки, поскольку никакого формализма в основу не положено.
T>Это ты какую-то глупость говоришь, да. То, что никакого формализма нет, не означает, отсутствия уровня или вероятности ошибки.
Чукча не читатель? Я не пишу про то, что формализма нет. Я пишу о том, что он не предопределён и не фиксирован.
Возожность использовать разный формализм и отсутствие его — это не одно и то-же.
M>>А уровень описания у меня заведомо выше. По той причине, что задача решается в терминах, максимально соответствующих решаемой задаче.
T>То есть, уровень есть и он выше.
Программист задаёт понятия, в которых может программировать. Следовательно, уровень абстракции задаётся программистом.
Захочет — может писать на ассеблере. Захочет — на хаскеле. Захочет — в терминах максимально близких к решаемой задаче.
T>Ну, так покажи, как проверить (или доказать) коммутативность какой-либо бинарной операции над произвольным типом данных.
Зачем? Тебе это ничего не скажет о SymADE, поскольку он не предназначен для этих проверок и доказательств.
В хаскеле правильность определения/поведения монады компилятором не проверяется. Он просто компилирует код так, как будто-бы код для монады определён правильно.
SymADE позволяет определять и использовать произвольные новые понятия. А доказывать правильность их определения или использования он не может и не должен.
Здравствуйте, thesz, Вы писали:
T>Оба вопроса связаны с распараллеливанием.
T>Вопрос: как в SymADE доказать коммутативность и ассоциативность некоторой операции?
А как это сделать в Notepad?
T>Приведи пример, как это будет описано в SymADE. Текст, весь, от начала до конца. Чтобы мы могли сравнить с текстом на Agda2.
Например, это можно сделать определив набор понятий (онтологию) аналогичную онтологии Agda2, написать этот код, сделать экспорт в исходный код на Agda2, и запусть их компилятор. Можно и посложнее — переписав компилятор Agda2, чтоб он на вход принимал своё AST дерево, а не обязательно текстовые исходники. Тогда шаг с экспортом можно пропустить.
T>Теперь вопрос посложней. Как раз на миллион долларов ровно.
T>Вот программа сортировки пузырьком: T>Она настолько не параллельна, насколько это возможно.
T>Прошу указать, какие изменения в коде этой программы необходимо сделать, чтобы программа сортировки пузырьком стала параллельной и что надо сделать в SymADE, чтобы реализовать все эти преобразования. Для SymADE прошу привести полный текст.
Для начала, в С нет понятия параллельного вычисления. В языке. Чтоб что-то распараллеливать, нужно это уметь делать. То есть в С надо добавить возможности параллельного выполнения кода. Вот это SymADE может сделать. К онтологии языка С добавить новые понятия, нужные для параллельного выполнения кода. Выполнить параллельно, подождать когда параллельный процесс закончится и так далее. Понятно, что ради конкретного пузырька с этим возиться не стоит. Мета-программирование — оно для больших проектов и сложных задач. Не алгоритмически сложных, а сложных для понимания (охвата) человеком.
Чтоб привести тебе полный текст этого дополнения, надо вначале полностью определить онтологию для С, а я замахаюсь это делать сейчас. Я ещё с явой не закончил (то есть её ещё не удобно редактировать, и пока я не доделаю редактор — за другие языки браться не буду).
В конце той статьи, с которой началось обсуждение, я написал, что задача по созданию ИИ, который будет заниматься поиском новых знаний среди уже определённых понятий — в SymADE не реализована, это задача для будущего. Когда закончу с текущими проблемами, буду думать о реализации такого ИИ.
T>Причем, второй вопрос действительно может принести миллион — это автоматическое распареллеливание, горячая тема.
К тому времени, как компьютер научится прилично параллелить код автоматом — это уже будет не актуально
Но об этом в статье уже тоже написано.
M>Переход к написанию программы компьютером — это переход от монолога, к диалогу. При этом, так же как и при диалоге человека с человеком, у компьютера должна быть своя, внутренняя модель программы. У компьютера должна быть возможность вводить новые понятия (в терминах которых эта модель и будет выражена). Он будет общаться с человеком (программистом) на некотором языке (языках), достаточно независимом от внутренней модели программы. Эта модель будет изменяться не непосредственно программистом, а в результате диалога между компьютером и программистом. Эти языки общения будут специально приспособлены для удобства понимания человеком и его команд, а модель программы внутри компьютера будет приспособлена для работы с ней компьютером, а не человеком.
Очень сложно понять что ты предлагаешь, если не шарить в этом самому. Я когда-то интересовался MPS, но поскольку на тот момент она была еще сыра, а туториал не соответствовал последней версии продукта, я решил отложить знакомство до «лучших времен».
Главная твоя проблема это то, что ты не можешь толком объяснить свои мысли. Я перечитал несколько тем на RSDN, ixbt, прочитал три твои статьи на developers.org.ua, пробовал найти что-то интересное на твоем сайте запускал программу. Информации много, но все одно и то же. То время, которое ты потратил на общение на форуме можно было бы продуктивнее использовать на написание небольшого документа, от А до Я (правда на developers.org.ua статья хорошая).
Я попытаюсь изложить свое видение материала, а ты, если что не так, подкорректируй меня.
Итак, давайте рассмотрим что же такое процесс программирования, откуда берется задание, как оно представляется в голове у человека и как он его «скармливает» компьютеру в виде программы.
1. Результатом ознакомления и обработки технического задания является некая модель, выраженная совокупностью понятий и связей между ними. Причем эти понятия, зачастую, высокоуровневые. Например
«Система должна позволять менять параметры А, В и С».
2. Далее происходит постоянный процесс конкретизации параметров.
Параметры А, В, С будут храниться в базе данных, и редактироваться пользователем с помощью графического интерфейсаПараметры А, В, С будут храниться в таблице Т, редактироваться в окне «Свойства» приложения «Администрирование»Параметры А, В, С будут храниться в таблице Т, будут представлены строковыми параметрами,
редактироваться в окне «Свойства» приложения «Администрирование».
Параметры А и В будут выбираться из ComboBox, паратетр С будет вводиться врочную в компоненте EditBox
И так далее... По сути это выражение одних понятий с помощью других.
3. В конце концов этот процесс заканчивается построением абстракций (классов и интерфейсов) и имплементацией функциональности. В результате мы получаем набор понятий и связей между ними (сравните с пунктом 1), но набор понятий ограничен такими как «класс», «интерфейс», «метод», «переменная» итд, то есть тем, что нам предоставляет язык программирования.
4. Компилятор (интерпретатор) обрабатывает текст программы, находит синтаксические ошибки, оптимизирует код, предупреждает о возможных логических ошибках итд.
И так, что мы имеем на сегодняшний день? Компьютер вовлечен только в стадию 4, Современные IDE, редакторы форм, плагины пытаются работать на уровне 3, но только если этот уровень ясно определен (например ИДЕ работает с языком программирования, редактор форм — с библиотекой построения графического интерфейса, плагины — с другими популярными и устоявшимися библиотеками)
По сути работа программиста заключается в том, чтобы выразить понятия, которыми оперирует человек, понятиями, которыми оперирует компьютер.
Вы можете возразить: с приходом ООП мы оперируем не понятиями языка программирования а конкретными классами. Например понятие «окно» выражается классом «Window», «кнопка» — «Button», «строка меню» — «Menu». Но ведь компьютер (компилятор) — работает все теми же классами, операторами и методами. Он не имеет информации о том, как связаны Button и Window. Этим и ограничивается автоматизм.
MPS пытается решить проблему путем расширения набора конструкций языка, расширением синтаксиса (то есть сделать класс Window частью языка, зарезервировать для него ключевое слово; добавить в язык дополнительные операции, удобные для редактирования графического интерфейса).
SOP же предлагает автоматизировать этап 2 (т.е. процесс конкретизации понятий). Ведь выражение одних понятий с помощью других это и есть то самое программирование в форме диалога.
Для лучшего понимания разницы между SOP, MPS и традиционным программированием давайте рассмотрим следующую метафору.
Представьте себе некий отчет, который оформлен в виде HTML файла. Отчет предоставляет итоговую информацию о деятельности некоторого предприятия. Чтобы подчеркнуть принадлежность данных к разным категориям используется форматирование.
Отчетприход
прибыль от продаж 200
расход
на рекламу 30
на зарплату 60
налоги 40
инвестиции
транспорт 20
оборудование 50
Это аналог традиционного программирования. Если мы захотим что-то поменять, (ну например, разукрасить всё в разные цвета), мы должны править сам документ, таблицу стилей, сделать рефакторинг (для каждого раздела добавить свой стиль) итд.
Подход MPS: давайте расширим HTML (аналог написания DSL) а к нему напишем свой редактор и компилятор, переводящий данные на нашем языке в обычный HTML. Тогда меняя свой язык мы сможем легко и просто решать трудные задачи.
Подход SOP: а давайте все забабахаем в XML, при этом каждое число будет иметь свой смысл и явно будет прописано что оно значит. Что-то типа такого:
Теперь мы можем сгенерить HTML, doc, rtf, pdf, jpeg, avi, ppt, сколько есть фантазии.... Мы можем редактировать данные как вручную, так и наваять програмку или вообще создать целый комплекс документооборота.
Использование XML это один из способов семантической организации данных. Вопрос: почему бы не использовать такой же способ для написания программ? Для этого нужно чтобы компилятор (точнее IDE) понимал семантику, а не набор команд и интерфейсов.
Re[3]: Два вопроса, один из которых на миллион долларов.
T>>Приведи пример, как это будет описано в SymADE. Текст, весь, от начала до конца. Чтобы мы могли сравнить с текстом на Agda2. M>Например, это можно сделать определив набор понятий (онтологию) аналогичную онтологии Agda2, написать этот код, сделать экспорт в исходный код на Agda2, и запусть их компилятор. Можно и посложнее — переписав компилятор Agda2, чтоб он на вход принимал своё AST дерево, а не обязательно текстовые исходники. Тогда шаг с экспортом можно пропустить.
Вопрос был — "как сделать это средствами SymADE", а не как задействовать Agda2 или её логику.
Иными словами, толком ты ответить не можешь. У тебя всё сводится к "в SymADE всё можно написать". Так это и на ассемблере можно.
T>>Теперь вопрос посложней. Как раз на миллион долларов ровно. T>>Вот программа сортировки пузырьком: T>>Она настолько не параллельна, насколько это возможно. T>>Прошу указать, какие изменения в коде этой программы необходимо сделать, чтобы программа сортировки пузырьком стала параллельной и что надо сделать в SymADE, чтобы реализовать все эти преобразования. Для SymADE прошу привести полный текст. M>Для начала, в С нет понятия параллельного вычисления. В языке. Чтоб что-то распараллеливать, нужно это уметь делать. То есть в С надо добавить возможности параллельного выполнения кода. Вот это SymADE может сделать. К онтологии языка С добавить новые понятия, нужные для параллельного выполнения кода. Выполнить параллельно, подождать когда параллельный процесс закончится и так далее. Понятно, что ради конкретного пузырька с этим возиться не стоит. Мета-программирование — оно для больших проектов и сложных задач. Не алгоритмически сложных, а сложных для понимания (охвата) человеком.
"Конкретный пузырёк" — это сложный пример для современных систем автоматического распараллеливания. Такие вещи мало, кто умеет делать.
M>Чтоб привести тебе полный текст этого дополнения, надо вначале полностью определить онтологию для С, а я замахаюсь это делать сейчас. Я ещё с явой не закончил (то есть её ещё не удобно редактировать, и пока я не доделаю редактор — за другие языки браться не буду).
Иными словами, работать с SymADE очень сложно. Настолько, что ты не можешь выдать ни одного решения ни одной выдаваемой тебе задачи за приемлемое время.
Причем задачи не включают в себя пользовательский интерфейс, базы данных и прочее, для чего надо пыхтеть и стараться. Надо просто собрать правильную логику.
И даже на это тебя не хватает.
А ведь ты автор SymADE, ты умеешь работать с ней лучше кого-либо другого, и даже лучше практически всех, кто станет её использовать (первое время, по крайней мере).
Вот я и думаю. Приду я на работу, начну читать про SymADE, ко мне подойдёт начальник, спросит, что такое, а я ему в ответ: это штука, об идеях которой можно писать длинные статьи и которая отлично подходит для оправдания ничегонеделания, поскольку ничего с её помощью сделать невозможно. Даже миллион баксов заработать. Предвижу несомненное повышение уважения ко мне со стороны коллег.
M>В конце той статьи, с которой началось обсуждение, я написал, что задача по созданию ИИ, который будет заниматься поиском новых знаний среди уже определённых понятий — в SymADE не реализована, это задача для будущего. Когда закончу с текущими проблемами, буду думать о реализации такого ИИ.
Eurisko. Конец 70-х. Её натравили на открытие знаний в области математики — задали несколько аксиом и отправили в путь. Она сама открыла понятие простых чисел, что-то ещё (теорему Пифагора, по-моему), а потом начала открывать бессмысленные связи, никому не нужные. И это ей ещё Ленат помогал, вручную.
Those who do not understand are doomed to reinvent, poorly.
T>>Причем, второй вопрос действительно может принести миллион — это автоматическое распареллеливание, горячая тема.
M>К тому времени, как компьютер научится прилично параллелить код автоматом — это уже будет не актуально
Этим занимаются не компьютеры, а люди. Современные алгоритмы вполне сравнимы с ручным распараллеливанием.
M>Но об этом в статье уже тоже написано.
И совершенно неправильно написано.
Ты пишешь о том, что ты толком не знаешь. Не о реальных проблемах, а о своих о них представлениях.
Чего стоит упоминание о null pointer exception. Про них уже все давно забыли, все работают уровнем выше (или стремятся забыть и работать). А ты всё ещё про них думаешь.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[4]: Два вопроса, один из которых на миллион долларов.
Здравствуйте, thesz, Вы писали:
T>Вопрос был — "как сделать это средствами SymADE", а не как задействовать Agda2 или её логику.
Это и есть "средствами SymADE". SymADE — это среда разработки программ, а не ещё один язык программирования, который должен решить все проблемы человечества.
T>Иными словами, толком ты ответить не можешь. У тебя всё сводится к "в SymADE всё можно написать". Так это и на ассемблере можно.
Иными словами, ты не можешь воспринять ничего нового. Ты можешь только свести информацию к уже привычным, уже известным тебе понятиям. И не понимаешь, что при этом всё новое в информации теряется.
Ну не сводятся законы квантовой механики к привычной нам законам макро-физики. Их надо просто выучить, как есть, не сводя к привычной механике.
Ты пытаешься свести SymADE к языкам программирования. Не надо. Это не приведёт тебя к пониманию. Разве ты только хочешь удостовериться, что в SymADE ничего нового нет, и удовлетворённо пребывать в этом мнении. И к простому редактору это свести нельзя. И к простому мета-программированию нельзя. В SymADE есть эти элементы, но к набору этих элементов он не сводится.
Нельзя на ассемблере всё написать. Практически, на практике нельзя. Не хватит всех ресурсов, всех программистов в мире, на то, чтоб написать даже базовый софт на ассемблере.
T>>Вопрос был — "как сделать это средствами SymADE", а не как задействовать Agda2 или её логику. M>Это и есть "средствами SymADE". SymADE — это среда разработки программ, а не ещё один язык программирования, который должен решить все проблемы человечества.
Иными словами, SymADE выступает здесь в роли посредника. Паразита. Тратя на себя внимание и не принося ничего полезного.
T>>Иными словами, толком ты ответить не можешь. У тебя всё сводится к "в SymADE всё можно написать". Так это и на ассемблере можно. M>Иными словами, ты не можешь воспринять ничего нового. Ты можешь только свести информацию к уже привычным, уже известным тебе понятиям. И не понимаешь, что при этом всё новое в информации теряется.
Я не могу воспринимать ничего, что не упрощает для меня работу.
M>Ну не сводятся законы квантовой механики к привычной нам законам макро-физики. Их надо просто выучить, как есть, не сводя к привычной механике.
Это ты глупость говоришь, как всегда.
Законы квантовой механики сводятся к ньютоновым в предельном случае. Не побоюсь наврать, поскольку давно уже было, и скажу, что устремив константу Планка к нулю ты и получишь законы обычной механики.
Так и тут, в программировании, есть Lambda the Ultimate Imperative, сводящая воедино два формализма.
Поэтому, мил человек, потрудись и сведи SymADE к одному из формализмов. Хотя бы одному.
M>Ты пытаешься свести SymADE к языкам программирования. Не надо. Это не приведёт тебя к пониманию. Разве ты только хочешь удостовериться, что в SymADE ничего нового нет, и удовлетворённо пребывать в этом мнении. И к простому редактору это свести нельзя. И к простому мета-программированию нельзя. В SymADE есть эти элементы, но к набору этих элементов он не сводится.
Синергия, значит.
Синергии работают только в грёзах менеджеров.
Если целое не равно сумме своих частей, то целое, наиболее вероятно, меньше суммы своих частей.
Из чего я предполагаю, что если я возьму части SymADE по отдельности — отдельно язык программирования, отдельно редактор, отдельно система метапрограммирования, — то я получу то же самое, но лучше (мощнее, быстрее и тп).
Доказательств обратного я не вижу.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[2]: Программирование, от монолога к диалогу с компьютером
tid>Теперь мы можем сгенерить HTML, doc, rtf, pdf, jpeg, avi, ppt, сколько есть фантазии.... Мы можем редактировать данные как вручную, так и наваять програмку или вообще создать целый комплекс документооборота.
Проблема в том, что ты взял очень простое представление и очень простое преобразование. Буквально, представление деревянное, даже не DAG, а преобразование "дерево1->дерево2".
tid>Использование XML это один из способов семантической организации данных. Вопрос: почему бы не использовать такой же способ для написания программ?
Потому, что программы представлены графами. С зависимостями.
Вот за этим и нужны зависимые типы данных. Они позволяют проверять практически всё, что нужно на любой стадии программирования. И разрабатываются они с 1972 года, а не пяток лет, и ищут в них слабые места и исправляют ошибки лучшие умы человечества.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[6]: Два вопроса, один из которых на миллион долларов.
Здравствуйте, thesz, Вы писали:
T>Иными словами, SymADE выступает здесь в роли посредника. Паразита. Тратя на себя внимание и не принося ничего полезного.
Твоими словами, ООП паразитирует на концепциях наследования и полиморфизма.
Хочешь играть словами? А смысл?
M>>Ну не сводятся законы квантовой механики к привычной нам законам макро-физики. Их надо просто выучить, как есть, не сводя к привычной механике.
T>Это ты глупость говоришь, как всегда.
Заче ты тогда пишешь эти сообщения?
T>Законы квантовой механики сводятся к ньютоновым в предельном случае. Не побоюсь наврать, поскольку давно уже было, и скажу, что устремив константу Планка к нулю ты и получишь законы обычной механики.
Но она не нулевая. Это раз.
Законы сохранения в квантовой механике нелокальны. Это два.
Виртуальные частицы достаточны, для объяснения понятия "поля", а в макро-физике "поле" есть базовая самостоятельная сущность.
И так далее и тому подобное.
Не сводится квантовая механика к привычному тебе.
T>Поэтому, мил человек, потрудись и сведи SymADE к одному из формализмов. Хотя бы одному.
А MS Word или ООП тебе к формализму не надо привести?
T>Если целое не равно сумме своих частей, то целое, наиболее вероятно, меньше суммы своих частей.
Цитировать надо правильно. Целое — больше суммы своих частей.
T>Из чего я предполагаю, что если я возьму части SymADE по отдельности — отдельно язык программирования, отдельно редактор, отдельно система метапрограммирования, — то я получу то же самое, но лучше (мощнее, быстрее и тп).
T>Доказательств обратного я не вижу.
А я не вижу доказательства твоим словам вообще. Одни предположения, из которых делаются выводы
Может для тебя это будет откровением, но применение строго логического мышления к неверным предпосылкам — приводят к неверным результатам.
Это прямое следствие того, что тебя интересует форма (корень слова "формальный"), а не содержание.
Здравствуйте, tid, Вы писали:
tid>Здравствуйте, mkizub, Вы писали:
tid>Для лучшего понимания разницы между SOP, MPS и традиционным программированием давайте рассмотрим следующую метафору.
tid>Подход MPS: давайте расширим HTML (аналог написания DSL) а к нему напишем свой редактор и компилятор, переводящий данные на нашем языке в обычный HTML. Тогда меняя свой язык мы сможем легко и просто решать трудные задачи.
tid>Подход SOP: а давайте все забабахаем в XML, при этом каждое число будет иметь свой смысл и явно будет прописано что оно значит. Что-то типа такого:
tid>Теперь мы можем сгенерить HTML, doc, rtf, pdf, jpeg, avi, ppt, сколько есть фантазии.... Мы можем редактировать данные как вручную, так и наваять програмку или вообще создать целый комплекс документооборота. tid>Использование XML это один из способов семантической организации данных. Вопрос: почему бы не использовать такой же способ для написания программ? Для этого нужно чтобы компилятор (точнее IDE) понимал семантику, а не набор команд и интерфейсов.
Лучше (точнее) этот пример переформулировать так.
И MPS и SymADE предлагают использовать XML. Но подход MPS — ближе к использованию XML как markup language. Определили XHTML, и взяв текст, отметили в нём один кусок как bold, другой кусок как paragraph. Потом это можно форматировать и отображать используя Style Sheet какой-нибудь. Это их подход, LOP — language oriented programming. Под решение задачи они создают язык, и решают задачу.
А SymADE предлагает использовать XML как средство определения данных — это имя автора, а это название документа и т.п. А конкретные представления (вроде XHTML или RTF) получать при помощи XSLT, и уже потом к полученному можно применять Style Sheet и прочее. Это SOP — semantic oriented programing. Тоже создание языка, но описываются именно семантические понятия, а не синтаксические. А синтаксическое представление уже производное от смыслового, семантического.
Здравствуйте, thesz, Вы писали:
tid>>Теперь мы можем сгенерить HTML, doc, rtf, pdf, jpeg, avi, ppt, сколько есть фантазии.... Мы можем редактировать данные как вручную, так и наваять програмку или вообще создать целый комплекс документооборота.
T>Проблема в том, что ты взял очень простое представление и очень простое преобразование. Буквально, представление деревянное, даже не DAG, а преобразование "дерево1->дерево2".
tid>>Использование XML это один из способов семантической организации данных. Вопрос: почему бы не использовать такой же способ для написания программ?
T>Потому, что программы представлены графами. С зависимостями.
T>Потому, что преобразования программ нетривиальны. Например, оптимизация по размеру эквивалентна решению проблемы останова.
Ну я взял простой и распространненый пример организации данных. Ведь дело не в конкретной структуре, а в самой идее. Насколько я понял автор темы предлагает свою систему как первый шаг к автоматизации процесса программирования, а что делать дальше особо не представляет (или я не прав?).
Отсюда понятно что он не сможет ответить на вопросы по конкретным проблемам (как распараллелить алгоритм, или как сделать код более безопасным).
Это что то типа:
— Давайте введем понятие синуса и косинуса, и с помощью них попытаемся решить существующие проблемы
— А как твой синус поможет нам строить светлое будущее
— Да не знаю я как, нужно сначала его изучить, а потом видно будет
Я не спорю с тем, что перед тем чтобы что-то делать, нужно проблему изучить. Но на этом форуме задаются вопросы, как мне кажется, слабо относящиеся к сути программы. Типа "реши задачу на миллион" и тому подобное.
tid>>Для этого нужно чтобы компилятор (точнее IDE) понимал семантику, а не набор команд и интерфейсов.
T>Вот за этим и нужны зависимые типы данных. Они позволяют проверять практически всё, что нужно на любой стадии программирования. И разрабатываются они с 1972 года, а не пяток лет, и ищут в них слабые места и исправляют ошибки лучшие умы человечества.
А можно попобдробнее о зависимых типах? Пару ссылок, если не затруднит.
Re[4]: Программирование, от монолога к диалогу с компьютером
Здравствуйте, tid, Вы писали:
tid>Ну я взял простой и распространненый пример организации данных. Ведь дело не в конкретной структуре, а в самой идее. Насколько я понял автор темы предлагает свою систему как первый шаг к автоматизации процесса программирования, а что делать дальше особо не представляет (или я не прав?).
Прав, но это очень упрощённый взгляд.
Есть такая замечательная вещь, как мета-программирование. Когда вы пишете программу, которая пишет программу.
Есть такая замечательная вещь, как DSL. Когда вы пишете язык программирования, на котором пишете программу. Вообще-то использование DSL тоже является мета-программированием.
Обе эти технологии позволяют повысить производительность труда программиста. Значительно повысить. В разы.
Но они, в силу некоторых причин, не используются так активно, как могли-бы.
Эти причины я перечислил в статье. Чтоб решить эту проблему (устранить причины, по которым они не используются в мэйнстриме), надо изменить существующие средства разработки программ, и лучшим способом является уход от текстового представления программы. Но сам этот способ порождает множество проблем. Их корень в одном — это совсем другой, совершенно не разработанный ещё способ писать программы. Это просто неудобно, не потому, что это принципиально неудобно, а потому, что средства (редакторы, компиляторы, системы контроля версии) не разработаны. Не создана ещё экосистема. Нет программ, которые позволяют редактировать и компилировать программы в таком виде.
Но если эти программы написать и создать эту экосистему — то производительность труда программиста повысится в несколько раз. За счёт использования мета-программирования, DSL/eDSL.
Вот для этого создаются такие технологии, как Intentional Programming, MPS, SymADE.
Далее, автор темы как раз понимает, что будет дальше. SGML/HTML/XML создавался изначально для разметки текста, и только потом большинство людей обнаружило, что XML можно использовать и для описания структурированных данных, а не только форматировать текст. Понятно, что некоторые авторы SGML с самого начала понимали, что так его можно использовать. Так и автор темы, я то-есть, уже сейчас понимаю, как можно будет использовать технологии типа IP/MPS/SymADE в будущем. И соответственно дизайн SymADE я делаю таким, чтоб его можно было так использовать в будущем. Это как фундамент дома. Как вы фундамент сделали, такой дом и сможете построить в будущем. На фундаменте для одноэтажного домика вы не построите 5-ти этажный дом, а на фундаменте 5-ти этажки не построите высотный дом. Вот я сейчас закладываю такой фундамент, чтоб на нём можно было построить технологию, при которой на компьютер будет переложена большая часть работы по кодированию программы.
А на ближайшие 10 лет вполне хватит и просто IP/MPS.
tid>Отсюда понятно что он не сможет ответить на вопросы по конкретным проблемам (как распараллелить алгоритм, или как сделать код более безопасным).
Не поэтому. А потому, что это не входит в круг решаемых мной задач.
Я Сергею уже не один раз говорил — я пишу, грубо говоря, Notepad. Меня бессмысленно спрашивать, как я собираюсь при помощи текстового редактора компилировать программу. Notepad не для этого предназначен. А он отвечает, что раз с его помощью нельзя скомпилировать программу, то он не нужен. Так он со мной и общается. Зачем — не понятно. Наверное ему приятно думать, что он умнее, и каждый раз находить этому подтверждение
T>>Иными словами, SymADE выступает здесь в роли посредника. Паразита. Тратя на себя внимание и не принося ничего полезного. M>Твоими словами, ООП паразитирует на концепциях наследования и полиморфизма. M>Хочешь играть словами? А смысл?
Покажи, как это получается из моих слов. Пока это выше моего понимания.
M>>>Ну не сводятся законы квантовой механики к привычной нам законам макро-физики. Их надо просто выучить, как есть, не сводя к привычной механике. T>>Это ты глупость говоришь, как всегда. M>Заче ты тогда пишешь эти сообщения?
Чтобы все знали, что ты говоришь глупости, и ты в первую очередь. Мне не нравится, когда говорят глупости.
T>>Законы квантовой механики сводятся к ньютоновым в предельном случае. Не побоюсь наврать, поскольку давно уже было, и скажу, что устремив константу Планка к нулю ты и получишь законы обычной механики. M>Но она не нулевая. Это раз. M>Законы сохранения в квантовой механике нелокальны. Это два. M>Виртуальные частицы достаточны, для объяснения понятия "поля", а в макро-физике "поле" есть базовая самостоятельная сущность. M>И так далее и тому подобное. M>Не сводится квантовая механика к привычному тебе.
Но имеет привычное мне, как краевой случай.
Ты покажи, где краевые случаи SymADE, соответствующие императивному и функциональному программированиям. Это покажет хоть какой-то смысл в твоих действиях.
T>>Поэтому, мил человек, потрудись и сведи SymADE к одному из формализмов. Хотя бы одному. M>А MS Word или ООП тебе к формализму не надо привести?
tid>Ну я взял простой и распространненый пример организации данных. Ведь дело не в конкретной структуре, а в самой идее.
"В теории, практика не отличима от теории. На практике..." (C) мне неизвестен
tid>Насколько я понял автор темы предлагает свою систему как первый шаг к автоматизации процесса программирования, а что делать дальше особо не представляет (или я не прав?).
Если он не представляет, что дальше делать, то он и первого шага не сделал.
tid>Отсюда понятно что он не сможет ответить на вопросы по конкретным проблемам (как распараллелить алгоритм, или как сделать код более безопасным).
А всё остальное не должно интересовать разумного человека.
Да та же самая квантовая механика, любимая Максимом, была открыта (см. уравнение этого самого... Шрёдингера, во!) в процессе решения насущных проблем физиков и сразу же дала возможность расширить поле экспериментов и многое объяснить.
В SymADE я объяснений не вижу. Открытие вижу, что-то типа вечного двигателя. "А он сможет питать лампу? — Да, только подталкивать придётся, минут по пять каждые три минуты, я ещё не всё отработал, трение не могу снизить." Вот такой же диалог у нас с Максимом каждый раз. "А он сможет облегчить мне обнаружение ошибок, как в Agda2? — Да, только Agda2 подцепи плагином и её онтологию реализуй."
tid>А можно попобдробнее о зависимых типах? Пару ссылок, если не затруднит.
tid>>Отсюда понятно что он не сможет ответить на вопросы по конкретным проблемам (как распараллелить алгоритм, или как сделать код более безопасным). M>Не поэтому. А потому, что это не входит в круг решаемых мной задач. M>Я Сергею уже не один раз говорил — я пишу, грубо говоря, Notepad. Меня бессмысленно спрашивать, как я собираюсь при помощи текстового редактора компилировать программу. Notepad не для этого предназначен. А он отвечает, что раз с его помощью нельзя скомпилировать программу, то он не нужен.
Сергей же тебе говорит, что ещё один Notepad не нужен. Их уже кучами.
Сергей также тебе говорит, что если твой Notepad+ так сложен в освоении, что ты с его помощью его же ещё не дописал — а прошло года три или четыре, — то он никому никогда не будет нужен.
А в ответ тишина. Точнее, не тишина per se, а эхо, повторяющее одно и то же. "SymADE — не очередной язык программирования, призванный решить все проблемы человечества"
Ага. Не язык программирования.
SymADE — это очередной Notepad+, призванный решить все проблемы человечества.
Правда, когда заходит речь о настоящих проблемах, которые надо решать, всё время предлагается использовать что-то ещё, что уже умеет решать лучше.
У меня в голове это всё не укладывается.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[8]: Два вопроса, один из которых на миллион долларов.
Здравствуйте, thesz, Вы писали:
T>>>Иными словами, SymADE выступает здесь в роли посредника. Паразита. Тратя на себя внимание и не принося ничего полезного. M>>Твоими словами, ООП паразитирует на концепциях наследования и полиморфизма. M>>Хочешь играть словами? А смысл?
T>Покажи, как это получается из моих слов. Пока это выше моего понимания.
Что тут не понятного? ООП использует концепции наследования и полиморфизма. Некто не видит в ООП ничего нового и полезного. В наследовании видит — меньше надо нажимать клавиш для определения новой структуры. В полиморфизме видит — меньшим количеством понятий должен оперировать человеческий мозг. А то, что соединяя эти понятия ООП привносит новое качество, при котором наследование одновременно определяет полиморфизм — этот некто не видит. Не пробовал этого практически и поэтому ему нечем увидеть от этого пользу. Вот он и считает, что весь хайп вокруг ООП не имеет под собой основания, а авторы этой концепции просто паразитируют на использовании других, полезных концепций.
SymADE — это, грубо, такой редактор. Известно, что редактор текста не позволяет создавать исполняемые программы. Исполняемые программы создаёт компилятор. Некто никогда не пробовал писать программы, он не знает, что для написания программы нужен вначале текстовый редактор, чтоб создать исходный код программы, и только потом компилятор может из этого исходного текста создать исполняемую программу. Поэтому этот некто может считать, что текстовый редактор не нужен для создания программ, и текстовые редакторы просто паразитируют на компиляторах. Формально он прав. Представь себе комп с двумя наборами кнопок — одним набором кнопок выставлялся адрес в памяти, а другим набором выставляется число (значение) для занесение в эту ячейку памяти. Вполне можно набрать текст программы нажимая эти кнопки. А по сути — затрахается программист нажимать эти кнопки на компе, вместь использования текстового редактора.
M>>Заче ты тогда пишешь эти сообщения?
T>Чтобы все знали, что ты говоришь глупости, и ты в первую очередь. Мне не нравится, когда говорят глупости.
На каждый роток не накинешь платок.
Тебе нравится голод в Уганде? Наверное нет. Но ты же не посылаешь деньги голодающим Уганды, и не едешь поднимать ихнюю целину.
Твоё утверждение только маскируют истинную причину твоих действий, это очевидно любого психолога. Так что можешь пребывать в этом заблуждении, или поискать реальную причину.
M>>Не сводится квантовая механика к привычному тебе.
T>Но имеет привычное мне, как краевой случай. T>Ты покажи, где краевые случаи SymADE, соответствующие императивному и функциональному программированиям. Это покажет хоть какой-то смысл в твоих действиях.
SymADE не сводится к императивному или функциональному программированию в предельном случае.
Он сводится к IDE в одном из пределов. К мета-программированию в другом из пределов. В способе написания компиляторов в третьем пределе.
В вырожденном случае, когда ты не используешь его возможностей по определению новых понятий, это просто структурный редактор для некоей онтологии (скажем, онтологии соответствующей языку Java или Haskell).
В вырожденном случае, когда ты не используешь его возможностей по трансформации кода, и передаче уже готового дерева на вход backend-компилятора, ты можешь просто сохранить программу как текст, и использовать компилятор который на вход принимает текст. Это делается теми-же средствами, которыми создаётся отображение кода на экране, только ты используешь исключетельно текстовые элементы.
В вырожденном случае, когда ты не собираешься расширять онтологию языка, ты можешь захардкодить все правила этого языка в backend-компиляторе.
Но тогда, в этих вырожденных случаях, SymADE тебе не понадобится.
SymADE нужен для того, чтоб создавать новые семантические понятия и добавлять их в существующие онтологии или создавать новые онтологии. И сверх того — чтоб с этими новыми понятиями программист мог работать (и компилятор мог компилировать) так-же легко и удобно, как с существовавшими ранее.
T>>>Поэтому, мил человек, потрудись и сведи SymADE к одному из формализмов. Хотя бы одному. M>>А MS Word или ООП тебе к формализму не надо привести?
T>Нет. Приведи SymADE.
T>ООП уже привели, надо сказать.
Ничего не могу сказать, текста книжки там нет, только оглавление.
Вот только не могу понять, для чего он это сделал? И для чего тебе нужен формализм SymADE? Что ты с ним делать собираешься?
T>>>>Иными словами, SymADE выступает здесь в роли посредника. Паразита. Тратя на себя внимание и не принося ничего полезного. M>>>Твоими словами, ООП паразитирует на концепциях наследования и полиморфизма. M>>>Хочешь играть словами? А смысл? T>>Покажи, как это получается из моих слов. Пока это выше моего понимания. M>Что тут не понятного? ООП использует концепции наследования и полиморфизма. Некто не видит в ООП ничего нового и полезного. В наследовании видит — меньше надо нажимать клавиш для определения новой структуры. В полиморфизме видит — меньшим количеством понятий должен оперировать человеческий мозг. А то, что соединяя эти понятия ООП привносит новое качество, при котором наследование одновременно определяет полиморфизм — этот некто не видит. Не пробовал этого практически и поэтому ему нечем увидеть от этого пользу. Вот он и считает, что весь хайп вокруг ООП не имеет под собой основания, а авторы этой концепции просто паразитируют на использовании других, полезных концепций.
Как вот этот параграф связан с моими словами?
По каждому твоему предложению будь добр представь вывод из моих слов. Я вообще ничего не понимаю. Это какой-то личный наезд, бессмысленный и беспощадный.
M>SymADE — это, грубо, такой редактор. Известно, что редактор текста не позволяет создавать исполняемые программы. Исполняемые программы создаёт компилятор. Некто никогда не пробовал писать программы, он не знает, что для написания программы нужен вначале текстовый редактор, чтоб создать исходный код программы, и только потом компилятор может из этого исходного текста создать исполняемую программу. Поэтому этот некто может считать, что текстовый редактор не нужен для создания программ, и текстовые редакторы просто паразитируют на компиляторах. Формально он прав. Представь себе комп с двумя наборами кнопок — одним набором кнопок выставлялся адрес в памяти, а другим набором выставляется число (значение) для занесение в эту ячейку памяти. Вполне можно набрать текст программы нажимая эти кнопки. А по сути — затрахается программист нажимать эти кнопки на компе, вместь использования текстового редактора.
M>>>Заче ты тогда пишешь эти сообщения?
T>>Чтобы все знали, что ты говоришь глупости, и ты в первую очередь. Мне не нравится, когда говорят глупости. M>На каждый роток не накинешь платок. M>Тебе нравится голод в Уганде? Наверное нет. Но ты же не посылаешь деньги голодающим Уганды, и не едешь поднимать ихнюю целину. M>Твоё утверждение только маскируют истинную причину твоих действий, это очевидно любого психолога. Так что можешь пребывать в этом заблуждении, или поискать реальную причину.
О! Диагноз по переписке. Отлично.
T>>Ты покажи, где краевые случаи SymADE, соответствующие императивному и функциональному программированиям. Это покажет хоть какой-то смысл в твоих действиях. M>SymADE не сводится к императивному или функциональному программированию в предельном случае. M>В вырожденном случае, когда ты не собираешься расширять онтологию языка, ты можешь захардкодить все правила этого языка в backend-компиляторе.
Вот, отлично.
Теперь покажи, что "захардкодить все правила этого языка в backend-компиляторе" менее выгодно, чем написать их с помощью SymADE.
В чем выигрыш-то по сравнению с обычным текстуальным преобразованием? По сравнению с тем же, не знаю, StrategoXT?
Прошу учесть в твоём рассказе, что современные системы программирования уже работают в интерактивном режиме и уже позволяют создавать программы пошагово, позволяя человеку задавать и проверять только интересные места (и помечая незаполненные), а также позволяя проверять полноту и непротиворечивость создаваемых человеком конструкций.
M>Но тогда, в этих вырожденных случаях, SymADE тебе не понадобится. M>SymADE нужен для того, чтоб создавать новые семантические понятия и добавлять их в существующие онтологии или создавать новые онтологии. И сверх того — чтоб с этими новыми понятиями программист мог работать (и компилятор мог компилировать) так-же легко и удобно, как с существовавшими ранее.
Без формализма внутри это будет весьма затруднительно.
"Вот здесь у меня плагин в функциональном стиле и мы передаём туда... ой! а я-то думал, чего она падает! оказывается, мы передаём туда значения из прологообразной подсистемы!"
T>>>>Поэтому, мил человек, потрудись и сведи SymADE к одному из формализмов. Хотя бы одному. M>>>А MS Word или ООП тебе к формализму не надо привести? T>>Нет. Приведи SymADE. T>>ООП уже привели, надо сказать. M>Ничего не могу сказать, текста книжки там нет, только оглавление. M>Вот только не могу понять, для чего он это сделал?
Было нужно. У него статья есть, как он 20+ лет этот формализм совершенствовал и через что прошёл. И ради чего.
M>И для чего тебе нужен формализм SymADE? Что ты с ним делать собираешься?
Формализм SymADE нужен для более удобных и менее подверженных ошибкам соединения его частей и написания нужных мне преобразований. Для них обеих.
Причем, он у тебя всё равно внутри есть, это же программа. Все программы формальны с 1936 года. Я не знаю, почему ты его прячешь от моих глаз.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[10]: Два вопроса, один из которых на миллион долларов.
Здравствуйте, thesz, Вы писали:
T>Как вот этот параграф связан с моими словами?
Ну тогда я уже и не знаю, как тебе это показать. Не видишь и ладно.
T>Теперь покажи, что "захардкодить все правила этого языка в backend-компиляторе" менее выгодно, чем написать их с помощью SymADE.
Попробуй добавить что-то в компилятор, где правила языка прописаны в коде, а не в декларативных или подключаемых извне правилах — и поймёшь всю выгоду.
Если у тебя такого опыта нет, то можешь начать с размышлений — зачем, например, пишут специальные расширяемые компиляторы (вроде
этого http://www.cs.cornell.edu/projects/polyglot/ ), а не используют стандартные.
T>В чем выигрыш-то по сравнению с обычным текстуальным преобразованием? По сравнению с тем же, не знаю, StrategoXT?
Это не текстовый преобразователь. Это тулза для преобразования (трансформации) деревьев. У него есть средства для парсинга и экспорта текста, но работает он с деревом во внутреннем своём представлении.
Чем лучше — я уже много раз писал. Например, один из аспектов улучшенности — пусть ты сделал расширение к языку, и при помощи StrategoXT распарсил, трансформировал узлы дерева для расширения в стандартные узлы дерева этого языка, и сделал экспорт (pretty-printing) в этот язык. Но с умным IDE вроде Eclipse или IDEA ты уже этот расширенный язык использовать не сможешь. А используя SymADE ты можешь расширять язык, использовать этот расширенный язык в IDE, и затратить на это расширение меньше сил, так как парсинг и текстовый экспорт тебе не нужны будут.
T>Прошу учесть в твоём рассказе, что современные системы программирования уже работают в интерактивном режиме и уже позволяют создавать программы пошагово, позволяя человеку задавать и проверять только интересные места (и помечая незаполненные), а также позволяя проверять полноту и непротиворечивость создаваемых человеком конструкций.
Ага. Только одни интерактивно работают с фиксированным набором семантических понятий, а другие с расширяемым, но не интерактивным.
Ты хоть читал статью, обсуждение которой тут как-бы идёт? Там это написано уже.
M>>SymADE нужен для того, чтоб создавать новые семантические понятия и добавлять их в существующие онтологии или создавать новые онтологии. И сверх того — чтоб с этими новыми понятиями программист мог работать (и компилятор мог компилировать) так-же легко и удобно, как с существовавшими ранее.
T>Без формализма внутри это будет весьма затруднительно.
T>"Вот здесь у меня плагин в функциональном стиле и мы передаём туда... ой! а я-то думал, чего она падает! оказывается, мы передаём туда значения из прологообразной подсистемы!"
Ну не падает же .NET, когда из программы на VB вызывают процедуру на C#.
При чём тут формализм?
Формализм, это когда действия выполняются формально, следуя инструкции, при этом не требуется понимания смысла действий и пр.
Используется для исключения субъективного фактора, для простых систем позволяет получить детерминированный результат и пр.
Так вот, формальность исполнения программы никоим образом не гарантирует нас от падения этой самой программы.
Она даже не позволяет отличить некорректное завершение программы ("падает") от корректного. Поскольку отличаются они только смыслом, и смысл этот у человека в голове, а не в компьютерной программе. Компьютер честно выполняет инструкции, бросает в некоторых местах exception — но это ожидаемый программистом и правильный exception, или не ожидаемый и неправильный exception — компьютер сказать не может. В этом и суть формализма, в том, что нет понимания, есть лишь форма.
Вот я и не могу понять, на кой ляд тебе сдался формализм в этом случае? Речь идёт о создании новых семантических понятий, имеющих смысл для программиста. Какой вообще может быть формализм, когда мы говорим о смысле, о содержании, а не форме?
T>>>ООП уже привели, надо сказать. M>>Вот только не могу понять, для чего он это сделал? T>Было нужно. У него статья есть, как он 20+ лет этот формализм совершенствовал и через что прошёл. И ради чего.
Где она у него там, как называется?
M>>И для чего тебе нужен формализм SymADE? Что ты с ним делать собираешься?
T>Формализм SymADE нужен для более удобных и менее подверженных ошибкам соединения его частей и написания нужных мне преобразований. Для них обеих.
Формализм сам по себе отношения к ошибкам не имеет. Формализм — это следование форме, а не содержанию.
По аналогии с юриспруденцией — букве закона, а не духу закона. Если бы формализм сам по себе убирал ошибки, то уже давно бы судей не было.
Если тебя интересует минимизация ошибок, это другое дело.
С этим у меня плохо.
Вот, простой пример. В работе с деревом есть метод — заменить этот узел в дереве на другой. Это потенциальный источник ошибок.
По той простой причине, что дерево не знает, и знать не может — можно ли менять этот узел на другой. Скажем, мы меняем узел типа Expression на узел типа Comment.
В одних местах программы это нормально, а в других вызовет ошибку. Что делать с этим методом?
На самом деле ситуация ещё сложнее. Пусть даже мы делаем дерево "ошибочным" (с точки зрения какого-то плагина, который ожидает найти в этом месте определённых узел).
Но иногда нам надо это сделать. Пример этого тоже есть в статье, там где написано про удобство редактирования выражений, если позволить дереву быть временно невалидным.
Конечно, даже если эти проблемы если не решаются полность, но количество ошибок в подобных местах можно сократить используя всякие дополнительные проверки, транзакции и пр. Но есть и такие возможные провероки, которые на несколько порядков увеличат время исполнения программы. И правильной программу они не сделают, просто сообщать об ошибочной ситуации раньше.
T>Причем, он у тебя всё равно внутри есть, это же программа. Все программы формальны с 1936 года. Я не знаю, почему ты его прячешь от моих глаз.
Если это программа, то я её от тебя не прячу. Адрес сайта разработки в каждом моём посте.
T>Однако, в отличии от твоей системы, меньше вероятность ошибки и выше уровень описания. Это я про анализ и преобразования.
Сдаётся мне, вы о разных вещах говорите. Как можно мешать в кучу верификацию и кодогенерацию? Да еще пытаться сравнить какие-то их св-ва. ИМХО, эти процессы вполне могут дополнять/использовать друг-друга.
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[6]: Два вопроса, один из которых на миллион долларов.
Здравствуйте, thesz, Вы писали:
T>>>Вопрос был — "как сделать это средствами SymADE", а не как задействовать Agda2 или её логику. M>>Это и есть "средствами SymADE". SymADE — это среда разработки программ, а не ещё один язык программирования, который должен решить все проблемы человечества.
T>Иными словами, SymADE выступает здесь в роли посредника. Паразита. Тратя на себя внимание и не принося ничего полезного.
Откуда столько негатива?
Изначально системы навроде SymADE — это всего-лишь попытка уйти от текстового представления программ и не надо требовать большего, как не стоит требовать большего от многострадального Notepad. Ты же не считаешь Notepad паразитом? Хотя он и обязательный посредник (или любой другой редактор текста), а ты, очевидно, позволяешь себе лишнее.
Остальные рюшки, касательно SymADE, типа ИИ и прочего, или из той области чего там хочешь увидеть ты (непонятно, с какой стати) — лишь следствие фантазий, подгоняемых наличием "универсального семантическим представлением". Я понимаю, что "автоматом" и прямо сейчас хочется получить всё и сразу. Тем не менее, задача SymADE — предоставить редактор некоей семантики, а даже важнее — разработать сами подходы и способы работы с семантикой вообще (а что с этой семантикой потом делать, повторюсь, пусть ограничивается только фантазией). Вон в Nemerle предоставили доступ к вещам, гораздо более приземлённым — к синтаксису, и то у людей башню откровенно сносит от "понимания открывающихся возможностей".
T>Я не могу воспринимать ничего, что не упрощает для меня работу.
А мне само текстовое представление программ давно надоело, потому и близки попытки, типа SymADE (жаль, что на Яве товарищ пишет). После некоего опыта работы с моделирующим ПО перестаёшь понимать, почему программисты до сих пор барахтаются в текстовом представлении, да еще в столь небольшом наборе синтаксических конструкций. В том же SymuLink до 90% модели (т.е. алгоритма вычисления) можно накидать в виде иерархических аналогов функциональных схем, и только в некоторых местах ручками ввести формулы на пару строк. ИМХО, полностью от текстового представления отказываться бессмысленно, ибо ряд вещей действительно ручками куда как быстрее вбить или в текстовом виде просмотреть, но факт в том, что в горе современных исходников таких мест как раз примерно 10%. А еще факт в том, что раздражает даже не сам текст в исходниках, а именно его "плоскость", ибо в том же MathCAD текст очень даже неплохо представлен, но он такой же "плоский" как результат рендеринга TeX или PDF.
Даже твой пример для колец для Agda2 — полная убогость, с т.з. представления информации. Там всю идею можно было графически уместить на пару экранов, а не на 20.
T>Поэтому, мил человек, потрудись и сведи SymADE к одному из формализмов. Хотя бы одному.
Что именно свести?
Мил человек, сведи для начала к формализму набор символов ANSI, тогда поймешь, о чём вообще идёт речь, а то ты витаешь где-то...
Сами формализмы в каком-то виде представить надо, не задумывался? А связи м/у ними, а следствия и т.д. Еще не понял намёка? Пока этот абзац не поймёшь, рассуждать о назначении SymADE тебе бесполезно и даже вредно.
Я тут рядом пытался с тобой уже общаться о синтаксисе, но ты как сам с собой разговариваешь. Тебя заносило в рассуждения о свойствах типов, тогда как я всё пытался добиться способа отображения/декларации этих св-в (называя это "контрактом типа", "ограничением на тип" и т.д.). А какие сами эти св-ва или какой формальной/неформальной логике подчиняются — это дело абсолютно десятое, ибо пропасть м/у существующими исходниками и формальными системами лежит именно в области представления. Аттрибуты .Net, или макросы Nemerle — это слааабенькая такая попытка снабдить плоский текст "потаённым неплоским смыслом". Вот получится придумать удачное представление формализмов и правил, привязанных каким-либо образом к исходникам — тогда получится прикрутить любые твои любимые формализмы, а не "хотя бы один". Способ дай.
T>Из чего я предполагаю, что если я возьму части SymADE по отдельности — отдельно язык программирования, отдельно редактор, отдельно система метапрограммирования, — то я получу то же самое, но лучше (мощнее, быстрее и тп).
T>Доказательств обратного я не вижу.
Оно более чем простое: возьми любой более-менее сложный проект в исходниках и выдери произвольные куски текста (не модули/классы/ф-ии, а именно плоского текста от произвольной позиции №1 до произвольной позиции №2). Получишь бессмыслицу, из которой состоит вполне осмысленный продукт. В пределе можно выдрать отдельные буквы, чтобы понятнее стало. Только вряд ли это будет достаточно, чтобы перестало заносить на поворотах.
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[7]: Два вопроса, один из которых на миллион долларов.
T>>>>Вопрос был — "как сделать это средствами SymADE", а не как задействовать Agda2 или её логику. M>>>Это и есть "средствами SymADE". SymADE — это среда разработки программ, а не ещё один язык программирования, который должен решить все проблемы человечества. T>>Иными словами, SymADE выступает здесь в роли посредника. Паразита. Тратя на себя внимание и не принося ничего полезного. V>Откуда столько негатива?
Это всё в глазах наблюдателя.
V>Изначально системы навроде SymADE — это всего-лишь попытка уйти от текстового представления программ и не надо требовать большего, как не стоит требовать большего от многострадального Notepad. Ты же не считаешь Notepad паразитом? Хотя он и обязательный посредник (или любой другой редактор текста), а ты, очевидно, позволяешь себе лишнее.
Notepad не требует на себя значительных ресурсов внимания.
V>Остальные рюшки, касательно SymADE, типа ИИ и прочего, или из той области чего там хочешь увидеть ты (непонятно, с какой стати) — лишь следствие фантазий, подгоняемых наличием "универсального семантическим представлением". Я понимаю, что "автоматом" и прямо сейчас хочется получить всё и сразу. Тем не менее, задача SymADE — предоставить редактор некоей семантики, а даже важнее — разработать сами подходы и способы работы с семантикой вообще (а что с этой семантикой потом делать, повторюсь, пусть ограничивается только фантазией). Вон в Nemerle предоставили доступ к вещам, гораздо более приземлённым — к синтаксису, и то у людей башню откровенно сносит от "понимания открывающихся возможностей".
Ты, уж, извини, но "сами подходы и способы работы с семантикой вообще" покрыты чуть более, чем полностью на Вики преобразований программ.
Для текстового вида — деревянного и даже представления в графах, — это всё давно уже разработано, бери и пользуйся.
T>>Я не могу воспринимать ничего, что не упрощает для меня работу. V>А мне само текстовое представление программ давно надоело, потому и близки попытки, типа SymADE (жаль, что на Яве товарищ пишет).
Каков стаж работы?
Мне текстовое представление, например, начало надоедать в районе 9-10 лет опыта. После чего я познакомился с Хаскелем и всё прошло.
Это я не к тому, чтобы обидеть, просто я тоже через это проходил.
V>После некоего опыта работы с моделирующим ПО перестаёшь понимать, почему программисты до сих пор барахтаются в текстовом представлении, да еще в столь небольшом наборе синтаксических конструкций.
[agda2]
if_then_else :: {A : Set} -> Bool -> A -> A -> A
if true then t else e = t
if false then t else e = e
[/agda2]
В нормальных языках какие хочешь, такие конструкции и объявляй. Хоть до квантовых вычислений опускайся.
V>В том же SymuLink до 90% модели (т.е. алгоритма вычисления) можно накидать в виде иерархических аналогов функциональных схем, и только в некоторых местах ручками ввести формулы на пару строк.
На это у меня ответ только один: ФВП. Функции Высших Порядков.
V>ИМХО, полностью от текстового представления отказываться бессмысленно, ибо ряд вещей действительно ручками куда как быстрее вбить или в текстовом виде просмотреть, но факт в том, что в горе современных исходников таких мест как раз примерно 10%. А еще факт в том, что раздражает даже не сам текст в исходниках, а именно его "плоскость", ибо в том же MathCAD текст очень даже неплохо представлен, но он такой же "плоский" как результат рендеринга TeX или PDF.
Я не понимаю, что такое "плоскость" текста.
V>Даже твой пример для колец для Agda2 — полная убогость, с т.з. представления информации. Там всю идею можно было графически уместить на пару экранов, а не на 20.
Прошу доказать это действием. Размести этот пример из библиотеки Agda на паре экранов с помощью графического представления. Необходимо, чтобы графическое представление создавалось программно, чтобы можно было показывать только части.
В этом случае ты хоть примерно поймешь, о чём я говорю. Я говорю о сложности преобразований, необходимых для просто показа отображений, не говоря уж о манипуляции ими.
Simulink работает в узкой области обработки сигналов, его расширение очень сложно. На его создание ушли годы (десятки человеко-лет, я так думаю) и толком результатом труда обычный программист воспользоваться не в силах. Я не могу просто взять, и заточить Simulink на работу с 1С за выходные.
Ровно то же самое будет с SymADE. Поскольку уже было до этого неоднократно.
А вот разборщик с анализом написать за выходные на Хаскеле я могу. И ты можешь. Что я выберу? Почему ты выберешь иное?
T>>Поэтому, мил человек, потрудись и сведи SymADE к одному из формализмов. Хотя бы одному. V>Что именно свести? V>Мил человек, сведи для начала к формализму набор символов ANSI, тогда поймешь, о чём вообще идёт речь, а то ты витаешь где-то...
См. стандартную библиотеку языка Ада.
Я знаю много языков и очень прагматичен. Именно поэтому я идеалист.
V>Сами формализмы в каком-то виде представить надо, не задумывался? А связи м/у ними, а следствия и т.д. Еще не понял намёка? Пока этот абзац не поймёшь, рассуждать о назначении SymADE тебе бесполезно и даже вредно.
Будь добр, расшифруй.
V>Я тут рядом пытался с тобой уже общаться о синтаксисе, но ты как сам с собой разговариваешь.
Я не нашёл. Это где было?
"Сам с собой разговариваешь" получается, в любом случае, когда аргументы, приводимые одной из сторон, слабы для второй стороны. И одна из сторон не желает признать ничтожность своих критериев важности.
Мои критерии очень просты: время разработки и скорость экспериментирования. Дайте мне инструмент, что уменьшит время и повысит скорость, и я буду первый, кто слезет с Хаскеля.
(и я уже начал, кстати)
Те инструменты, на разработку которых я могу повлиять — ну, думаю, что могу повлиять, — я либо хвалю, либо критикую. Это вполне нормально, по-моему. Даже необходимо.
V>Тебя заносило в рассуждения о свойствах типов, тогда как я всё пытался добиться способа отображения/декларации этих св-в (называя это "контрактом типа", "ограничением на тип" и т.д.). А какие сами эти св-ва или какой формальной/неформальной логике подчиняются — это дело абсолютно десятое, ибо пропасть м/у существующими исходниками и формальными системами лежит именно в области представления. Аттрибуты .Net, или макросы Nemerle — это слааабенькая такая попытка снабдить плоский текст "потаённым неплоским смыслом". Вот получится придумать удачное представление формализмов и правил, привязанных каким-либо образом к исходникам — тогда получится прикрутить любые твои любимые формализмы, а не "хотя бы один". Способ дай.
Он существует с 1972 года, правда, постоянно развивается. Называется теорией типов или Martin-Lof type theory.
T>>Из чего я предполагаю, что если я возьму части SymADE по отдельности — отдельно язык программирования, отдельно редактор, отдельно система метапрограммирования, — то я получу то же самое, но лучше (мощнее, быстрее и тп). T>>Доказательств обратного я не вижу. V>Оно более чем простое: возьми любой более-менее сложный проект в исходниках и выдери произвольные куски текста (не модули/классы/ф-ии, а именно плоского текста от произвольной позиции №1 до произвольной позиции №2). Получишь бессмыслицу, из которой состоит вполне осмысленный продукт. В пределе можно выдрать отдельные буквы, чтобы понятнее стало. Только вряд ли это будет достаточно, чтобы перестало заносить на поворотах.
Этого я тоже не понял. Что доказывает твой абзац?
Чтобы меня "перестало заносить на поворотах" всего-то и нужно — доказательств.
Не слов, а доказательств.
Типа, "я сделал то-то и то-то, получил уменьшение кода на столько-то и ошибок на столько-то. Правда, думал над этим столько-то дольше и ещё сколько-то писал, поэтому общий выигрыш не столь большой, как хотелось бы, оценка всего примерно вот такая."
При таком рассмотрении я вижу основную причину расходов именно в наличии SymADE.
Обычный программист, типа меня, будет думать над ней очень много времени (нет заранее готовых путей, читай, формализма) и ещё больше времени писать для неё всякое (Kiev — это та же Java, что плохо). В результате получится уменьшение числа ошибок типа null pointer exception, которые обычного программиста, типа меня, уже давно не волнуют.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[8]: Два вопроса, один из которых на миллион долларов.
Здравствуйте, thesz, Вы писали:
T>Ты, уж, извини, но "сами подходы и способы работы с семантикой вообще" покрыты чуть более, чем полностью на Вики преобразований программ.
T>Для текстового вида — деревянного и даже представления в графах, — это всё давно уже разработано, бери и пользуйся.
Это в памяти с графами и деревьями удобно работать, а визуальных их редакторов для программистов нормальных я еще не видел.
Бери любой моделирующий тул. Все соединения/потоки — суть графы и деревья внутри, однако выглядит для человека не как графы и деревья, а как компоненты и сигналы. Всё-таки ты в упор не видишь, почему всё писать на Лиспе или XML неудобно (или еще чем-то), да Бог с тобой.
T>>>Я не могу воспринимать ничего, что не упрощает для меня работу. V>>А мне само текстовое представление программ давно надоело, потому и близки попытки, типа SymADE (жаль, что на Яве товарищ пишет).
T>Каков стаж работы?
Какая разница? Первый свой мини-лисп был написан более 10 лет назад, если интересно, лет за 5 до этого — пара Фортов и ассемблеров. Формальными грамматиками интересуюсь всю жизнь, есть свои тулзы построения парсеров и лексеров по формальному описанию (отчего мне не особо нужен XML в работе, кстати) т.е. будет интересно поговорить именно о представлении — заходи. Несмотря на вольное мое обращение с любым текстовым представлением (я его выбираю наиболее удобным для каждой задачи), я давно уже чувствую, что "это не то".
T>Мне текстовое представление, например, начало надоедать в районе 9-10 лет опыта. После чего я познакомился с Хаскелем и всё прошло.
T>Это я не к тому, чтобы обидеть, просто я тоже через это проходил.
Через 9-10 лет тебе и это надоест, поговорим тогда еще раз. В языке всё должно быть прекрасно, и формулы и операторы и способ описания данных, и даже желаемая вычислительная модель, а не навязанный lazy.
T>Прошу доказать это действием. Размести этот пример из библиотеки Agda на паре экранов с помощью графического представления. Необходимо, чтобы графическое представление создавалось программно, чтобы можно было показывать только части.
ха-ха насчёт выделенного.
T>В этом случае ты хоть примерно поймешь, о чём я говорю. Я говорю о сложности преобразований, необходимых для просто показа отображений, не говоря уж о манипуляции ими.
Естественно, что "графический синтаксис" требует больше приседаний для реализации. Только вот приседание это обычно одноразово.
T>Simulink работает в узкой области обработки сигналов, его расширение очень сложно.
Он работает в "узкой области" моделирования как такового, необязательно обработки сигналов. Я моделировал как аналоговые и цифровые схемы, так и лексические анализаторы и алгоритмы сервисного обслуживания (СМО). Напр., исходный код dejitter-а для VoIP невелик по объёму, но без качественного предварительного моделирования получается штукенция, нормально работающая только в условиях близком к идеальным (это я намекаю на то, что куча имеющихся исходников по этой теме в сети — полнейшее неграмотное г-но).
T>На его создание ушли годы (десятки человеко-лет, я так думаю) и толком результатом труда обычный программист воспользоваться не в силах.
Не согласен насчёт "не в силах", просто народ не парится на моделирование, что-то пишет, где-то что-то тестирует, а получается как повезёт. Серверные системы годами дорабатываются из-за постоянно дополняемых требований "реальных условий" ввиду отсутствия предварительного моделирования. Да, сейчас такое моделирование потребует доп. ресурсов, и это будет работа, слабо связанная с реальными исходниками... Вот об этом и речь, собственно, о разрыве второго рода.
T>Я не могу просто взять, и заточить Simulink на работу с 1С за выходные.
Как и твой Хаскель, но за некоторое конечное время — запросто. Складская логистика так и просится на графическое представление.
T>Ровно то же самое будет с SymADE. Поскольку уже было до этого неоднократно.
Меня не интересует законченность проекта SymADE как такового, если честно. Мне интересна идея графического построения моделей, ибо любое ПО — суть модель некоей предметной области. Мы не оперируем заказами/товарами/деньгами/сигналами, мы оперируем их моделями, условностями. Если как результат работы над SymADE автор найдет хотя бы еще один удобный момент в плане графического представления и оперирования программными моделями — уже неплохо.
T>А вот разборщик с анализом написать за выходные на Хаскеле я могу. И ты можешь. Что я выберу? Почему ты выберешь иное?
Я выберу другое, потому что табличные сканеры по минимизированному ДКА работают примерно на порядок быстрее, чем построенные на паттерн-матчинге.
Увы, тут ведь и обсуждать нечего, без каких-либо исходных требований. А вот если бы был уже готовый параметризуемый элемент модели — парсер, у которого в св-вах указываешь тип алгоритма (ДКА, LR, LL, Earley, LGR и т.д.) а ты ему просто грамматику подаешь (а лучше, чтобы он мог и сам по грамматике модель выбирать), то это не заняло бы целый мой выходной.
Понимаешь, ядро этого симулинка — тьфу (я уверен), тонны человеко-лет написаны вокруг тонны готовых компонент, визуального редактора и связи с внешними "вычислителями", типа Matlab.
V>>Сами формализмы в каком-то виде представить надо, не задумывался? А связи м/у ними, а следствия и т.д. Еще не понял намёка? Пока этот абзац не поймёшь, рассуждать о назначении SymADE тебе бесполезно и даже вредно.
T>Будь добр, расшифруй.
Дело в том, что сами формальные модели (т.е. их элементы) тоже требуют некоего соглашения о синтаксисе и семантике, суть представления. Смысл SymADE стоять надо всем этим, не интересуясь подробностями, как не интересуется Simulink подробностями каждого используемого компонента, а только лишь оперируя несколькими простыми унифицированными интерфейсами общения с компонентом. Каждый компонент может содержать тонну кастомных св-в (возьмём банальный транзистор — около 3-х десятков св-в), но их семантика скрыта от симулинка. Компонент отображает весьма компактный значок с несколькими текстовыми тагами, для человека достаточно номинала реального транзистора или даже просто его технологии (напр. кремниевый). В текстовом виде описать связь десятка транзисторов можно запросто, но насколько это наглядно для человека, и сколько времени потребуется для понимания этой схемы? А в графическом представлении мне требуется минута, чтобы "воткнуть" в эту же схему.
Аналогично, многоэтажные формулы, представленные в MathCAD куда как привычнее глазу, чем любое их "плоское" текстовое описание на любом ЯП, и в Хаскеле в т.ч. А это значит, что разбор этой формулы для меня займет куда как меньше времени и усилий.
Ведь дело тут банально в подробностях субъективного восприятия информации человеком, графическая — более информативная, чем длинная цепочка букв, ибо во втором случае мы имеем "смысл над смыслом", сначала должны последовательно воспринять/расшифровать эти цепочки, а затем параллельно (образно) построить себе в голове смысл этой цепочки. Простой символ (перевернутое А) гораздо информативнее, чем цепочка "foreach", экономя квант моего внимания, а этих "квантов" в реальных программах набегает многие и многие тысячи.
T>"Сам с собой разговариваешь" получается, в любом случае, когда аргументы, приводимые одной из сторон, слабы для второй стороны. И одна из сторон не желает признать ничтожность своих критериев важности.
Или же собеседнику гораздо интереснее поговорить "о своём".
T>Мои критерии очень просты: время разработки и скорость экспериментирования. Дайте мне инструмент, что уменьшит время и повысит скорость, и я буду первый, кто слезет с Хаскеля.
T>(и я уже начал, кстати)
T>Те инструменты, на разработку которых я могу повлиять — ну, думаю, что могу повлиять, — я либо хвалю, либо критикую. Это вполне нормально, по-моему. Даже необходимо.
V>>Тебя заносило в рассуждения о свойствах типов, тогда как я всё пытался добиться способа отображения/декларации этих св-в (называя это "контрактом типа", "ограничением на тип" и т.д.). А какие сами эти св-ва или какой формальной/неформальной логике подчиняются — это дело абсолютно десятое, ибо пропасть м/у существующими исходниками и формальными системами лежит именно в области представления. Аттрибуты .Net, или макросы Nemerle — это слааабенькая такая попытка снабдить плоский текст "потаённым неплоским смыслом". Вот получится придумать удачное представление формализмов и правил, привязанных каким-либо образом к исходникам — тогда получится прикрутить любые твои любимые формализмы, а не "хотя бы один". Способ дай.
T>Он существует с 1972 года, правда, постоянно развивается. Называется теорией типов или Martin-Lof type theory.
Это ты уже говорил, а "удобно" пользоваться в реальной разработке как? И почему до сих пор не используется в популярных языках?
T>Типа, "я сделал то-то и то-то, получил уменьшение кода на столько-то и ошибок на столько-то. Правда, думал над этим столько-то дольше и ещё сколько-то писал, поэтому общий выигрыш не столь большой, как хотелось бы, оценка всего примерно вот такая."
T>При таком рассмотрении я вижу основную причину расходов именно в наличии SymADE.
T>Обычный программист, типа меня, будет думать над ней очень много времени (нет заранее готовых путей, читай, формализма) и ещё больше времени писать для неё всякое (Kiev — это та же Java, что плохо). В результате получится уменьшение числа ошибок типа null pointer exception, которые обычного программиста, типа меня, уже давно не волнуют.
Поинт тут в том, что меня не интересовало, например, сколько времени потратили разработчики на EWB (предышественник симулинка), но этот тул стал экономить мне время на порядок при знакомстве с ним в своё время, т.к. вместо возни с паяльником и осциллографом я весьма быстро накидывал модели из готовых компонент и постепенно накапливал свои параметризуемые компоненты. А вот накапливать свои параметризуемые компоненты для ПО как-то не получается, из проекта в проект, из года в год на разных языках и технологиях тратишь прилично времени на то, что делал уже неоднократно, и это какое-то уже неотделимое св-во разработки софта как такового.
Я тут уже подавал мысль о том, что системы навроде SymADE должны вылиться в итоге некую "базу знаний" IT, т.е. удобную библиотеку параметризуемых программынх компонент.
Вот есть у нас какой-нить мощный фреймворк, типа .Net. Но в нем реализация отдельно, а дока, классификация и прочее — отдельно. И насколько это отличается от даже устаревших систем, типа PCAD, где есть классификация, где при разработке используется выбор готовых компонент из удобного навигатора по библиотекам, а не "знания" о фреймворке, которые необходимо копить годами. Хаскеля и приведённых тобой ссылок на его библиотеки это тоже касается.
--------
И насчёт "чистого" ФП небольшое такое замечание. Я не вижу общих преимуществ функционального преобразователя без памяти над оным же с памятью, это просто разные мат. аппараты, каждый из которых хорош для своего места, с т.з. IT — для своего класса моделей. Аргумент насчёт автоматического распараллеливания вычислений тоже не ахти сильный, ведь функциональный преобразователь с памятью — это совокупность собственно памяти и как минимум пары функциональных преобразователей без оной. Т.е., выделив явно в модели собственно память и эти 2 "чистых" ФП (один — функция вычисления след. состояния, другой — функция выхода) вполне можно использовать имеющиеся наработки для распараллеливания.
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re: Программирование, от монолога к диалогу с компьютером
T>>Ты, уж, извини, но "сами подходы и способы работы с семантикой вообще" покрыты чуть более, чем полностью на Вики преобразований программ. T>>Для текстового вида — деревянного и даже представления в графах, — это всё давно уже разработано, бери и пользуйся. V>Это в памяти с графами и деревьями удобно работать, а визуальных их редакторов для программистов нормальных я еще не видел. V>Бери любой моделирующий тул. Все соединения/потоки — суть графы и деревья внутри, однако выглядит для человека не как графы и деревья, а как компоненты и сигналы. Всё-таки ты в упор не видишь, почему всё писать на Лиспе или XML неудобно (или еще чем-то), да Бог с тобой.
Именно поэтому я пишу на Хаскеле. Потому, что вижу.
А теперь ещё и инварианты хочу специфицировать, поскольку вижу потребность.
T>>>>Я не могу воспринимать ничего, что не упрощает для меня работу. V>>>А мне само текстовое представление программ давно надоело, потому и близки попытки, типа SymADE (жаль, что на Яве товарищ пишет). T>>Каков стаж работы? V>Какая разница? Первый свой мини-лисп был написан более 10 лет назад, если интересно, лет за 5 до этого — пара Фортов и ассемблеров. Формальными грамматиками интересуюсь всю жизнь, есть свои тулзы построения парсеров и лексеров по формальному описанию (отчего мне не особо нужен XML в работе, кстати) т.е. будет интересно поговорить именно о представлении — заходи. Несмотря на вольное мое обращение с любым текстовым представлением (я его выбираю наиболее удобным для каждой задачи), я давно уже чувствую, что "это не то".
Ты всё это знаешь, точно можешь указать на слабые места?
Уж извини, но я только-только начал разбираться с представлениями с указанием инвариантов. Это 1) очень круто, судя по всему, и 2) очень трудно.
T>>Мне текстовое представление, например, начало надоедать в районе 9-10 лет опыта. После чего я познакомился с Хаскелем и всё прошло. T>>Это я не к тому, чтобы обидеть, просто я тоже через это проходил. V>Через 9-10 лет тебе и это надоест, поговорим тогда еще раз. В языке всё должно быть прекрасно, и формулы и операторы и способ описания данных, и даже желаемая вычислительная модель, а не навязанный lazy.
Lazy не навязан, а предложен для использования в качестве самого удобного из умолчаний.
Тебе тоже объяснить, почему он удобен, или ты, всё же, читаешь RSDN?
T>>Прошу доказать это действием. Размести этот пример из библиотеки Agda на паре экранов с помощью графического представления. Необходимо, чтобы графическое представление создавалось программно, чтобы можно было показывать только части. V>ха-ха насчёт выделенного.
Разворачивай.
T>>В этом случае ты хоть примерно поймешь, о чём я говорю. Я говорю о сложности преобразований, необходимых для просто показа отображений, не говоря уж о манипуляции ими. V>Естественно, что "графический синтаксис" требует больше приседаний для реализации. Только вот приседание это обычно одноразово.
Пожалуй, не соглашусь.
Хотя ты сам указал на "обычно". То есть, не всегда.
Осталось выяснить, как часто и насколько много придётся приседать.
Моё мнение.
Графовые грамматики сложней обычных. См. DiaGen. Их разбор возможен толком только с помощью CYK алгоритма (не самый сложный в реализации, это не GLR, но сложней многих).
Вообще, здесь мы бескомпромиссно задействуем сразу две области — пользовательского интерфейса и языков программирования. В обеих хватает своих предпочтений, обе очень сложны. С текстовым представлением мы ведём бой всего в одной области, что выгодно.
T>>Simulink работает в узкой области обработки сигналов, его расширение очень сложно. V>Он работает в "узкой области" моделирования как такового, необязательно обработки сигналов. Я моделировал как аналоговые и цифровые схемы, так и лексические анализаторы и алгоритмы сервисного обслуживания (СМО). Напр., исходный код dejitter-а для VoIP невелик по объёму, но без качественного предварительного моделирования получается штукенция, нормально работающая только в условиях близком к идеальным (это я намекаю на то, что куча имеющихся исходников по этой теме в сети — полнейшее неграмотное г-но).
Скажи, пожалуйста, ты формальную спецификацию этого дела можешь написать?
В любом виде.
Если можешь, почему ты выполнял моделирование, а не разработку по спецификации? Если не можешь, то на чём базируется твоя (подразумеваемая мной) уверенность в том, что моделирование показало и проверило всё, что надо, что ты добрался до условий, далеких от идеальных?
T>>На его создание ушли годы (десятки человеко-лет, я так думаю) и толком результатом труда обычный программист воспользоваться не в силах. V>Не согласен насчёт "не в силах", просто народ не парится на моделирование, что-то пишет, где-то что-то тестирует, а получается как повезёт. Серверные системы годами дорабатываются из-за постоянно дополняемых требований "реальных условий" ввиду отсутствия предварительного моделирования. Да, сейчас такое моделирование потребует доп. ресурсов, и это будет работа, слабо связанная с реальными исходниками... Вот об этом и речь, собственно, о разрыве второго рода.
По-моему, это оно. В любом виде, графическом или нет.
T>>Я не могу просто взять, и заточить Simulink на работу с 1С за выходные. V>Как и твой Хаскель, но за некоторое конечное время — запросто. Складская логистика так и просится на графическое представление.
Мы ведём речь не о складской логистике, а об анализе ЯП и работе с какими-то представлениями программ.
Вот в случае Хаскеля я справлюсь с разбором и анализом программ на 1С за выходные. Или за пару выходных. Но не больше. Это не абстрактное "конечное время".
T>>Ровно то же самое будет с SymADE. Поскольку уже было до этого неоднократно. V>Меня не интересует законченность проекта SymADE как такового, если честно. Мне интересна идея графического построения моделей, ибо любое ПО — суть модель некоей предметной области. Мы не оперируем заказами/товарами/деньгами/сигналами, мы оперируем их моделями, условностями. Если как результат работы над SymADE автор найдет хотя бы еще один удобный момент в плане графического представления и оперирования программными моделями — уже неплохо.
написать за выходные на Хаскеле я могу. И ты можешь. Что я выберу? Почему ты выберешь иное? V>Я выберу другое, потому что табличные сканеры по минимизированному ДКА работают примерно на порядок быстрее, чем построенные на паттерн-матчинге.
У тебя какие-то странные сведения, очень устаревшие и перекошенные.
V>Увы, тут ведь и обсуждать нечего, без каких-либо исходных требований. А вот если бы был уже готовый параметризуемый элемент модели — парсер, у которого в св-вах указываешь тип алгоритма (ДКА, LR, LL, Earley, LGR и т.д.) а ты ему просто грамматику подаешь (а лучше, чтобы он мог и сам по грамматике модель выбирать), то это не заняло бы целый мой выходной.
Ты опять уходишь в сторону.
Тут не только разборщик, тут ещё и анализ присутствует. Я его сейчас выделю жирным, и ссылку проставлю на сообщение. Разборщик только часть всего этого дела. И он будет хорошо работать только по заранее заданной верной грамматике. Если ты её толком не знаешь и нужны эксперименты, то добро пожаловать в мир комбинаторов разбора.
V>Понимаешь, ядро этого симулинка — тьфу (я уверен), тонны человеко-лет написаны вокруг тонны готовых компонент, визуального редактора и связи с внешними "вычислителями", типа Matlab.
Сколько из этих тонн человеко-лет пошли на визуальный редактор? Сколько ушло на готовые компоненты? Не было бы дешевле сделать это в текстовом виде?
V>>>Сами формализмы в каком-то виде представить надо, не задумывался? А связи м/у ними, а следствия и т.д. Еще не понял намёка? Пока этот абзац не поймёшь, рассуждать о назначении SymADE тебе бесполезно и даже вредно. T>>Будь добр, расшифруй. V>Дело в том, что сами формальные модели (т.е. их элементы) тоже требуют некоего соглашения о синтаксисе и семантике, суть представления. Смысл SymADE стоять надо всем этим, не интересуясь подробностями, как не интересуется Simulink подробностями каждого используемого компонента, а только лишь оперируя несколькими простыми унифицированными интерфейсами общения с компонентом. Каждый компонент может содержать тонну кастомных св-в (возьмём банальный транзистор — около 3-х десятков св-в), но их семантика скрыта от симулинка. Компонент отображает весьма компактный значок с несколькими текстовыми тагами, для человека достаточно номинала реального транзистора или даже просто его технологии (напр. кремниевый). В текстовом виде описать связь десятка транзисторов можно запросто, но насколько это наглядно для человека, и сколько времени потребуется для понимания этой схемы? А в графическом представлении мне требуется минута, чтобы "воткнуть" в эту же схему.
Вся индустрия разработки железа, за малым исключением, работает на VHDL/Verilog. Вот дураки!
VHDL был специально сделан для замены схемотехнического описания и формализации документирования. В середине 1980-х. Вот в US DoD идиоты были! Да и сейчас сидят, поскольку отказываться от него не хотят.
V>Аналогично, многоэтажные формулы, представленные в MathCAD куда как привычнее глазу, чем любое их "плоское" текстовое описание на любом ЯП, и в Хаскеле в т.ч. А это значит, что разбор этой формулы для меня займет куда как меньше времени и усилий.
lhs2tex. Если угодно.
V>Ведь дело тут банально в подробностях субъективного восприятия информации человеком, графическая — более информативная, чем длинная цепочка букв, ибо во втором случае мы имеем "смысл над смыслом", сначала должны последовательно воспринять/расшифровать эти цепочки, а затем параллельно (образно) построить себе в голове смысл этой цепочки. Простой символ (перевернутое А) гораздо информативнее, чем цепочка "foreach", экономя квант моего внимания, а этих "квантов" в реальных программах набегает многие и многие тысячи.
Используй Agda2, там ты можешь писать практически, что угодно. Идентификатор — это последовательность Unicode символов, без, буквально, пробелов и ещё десятка — шести скобок и всяких точек с запятыми. Плюс, в идентификаторе можно указывать куда можно вставлять какие выражения. if_then_else_, если помнишь.
В Maude то же самое, практически (Maude был раньше, кстати).
T>>Он существует с 1972 года, правда, постоянно развивается. Называется теорией типов или Martin-Lof type theory. V>Это ты уже говорил, а "удобно" пользоваться в реальной разработке как? И почему до сих пор не используется в популярных языках?
В урезанном виде, насколько это поняли авторы языков — используется. См. шаблоны C++, например.
V>Поинт тут в том, что меня не интересовало, например, сколько времени потратили разработчики на EWB (предышественник симулинка), но этот тул стал экономить мне время на порядок при знакомстве с ним в своё время, т.к. вместо возни с паяльником и осциллографом я весьма быстро накидывал модели из готовых компонент и постепенно накапливал свои параметризуемые компоненты. А вот накапливать свои параметризуемые компоненты для ПО как-то не получается, из проекта в проект, из года в год на разных языках и технологиях тратишь прилично времени на то, что делал уже неоднократно, и это какое-то уже неотделимое св-во разработки софта как такового. V>Я тут уже подавал мысль о том, что системы навроде SymADE должны вылиться в итоге некую "базу знаний" IT, т.е. удобную библиотеку параметризуемых программынх компонент.
"Подавать мысль" мало. Надо её реализовывать.
Подающих мысли тысячи, если не десятки тысяч. Умеющих быстро реализовать мысли на порядок меньше, умеющих проверить (довести до конца) ещё в десять раз меньше и умеющих признать (!) неправоту своих идей — единицы.
Поэтому я бы посмотрел на твою реализацию "базы знаний" IT.
Это мне особенно интересно, поскольку у тебя до сих пор не получалось сделать это в текстовом представлении. Я педалирую эту тему потому, что ты не говоришь "у меня плохо получалось, думаю, с SymADE будет лучше, и вот почему", ты говоришь "у меня не получалось, а вот с SymADE магическим образом наверняка получится". Это крайне подозрительно.
V>Вот есть у нас какой-нить мощный фреймворк, типа .Net. Но в нем реализация отдельно, а дока, классификация и прочее — отдельно. И насколько это отличается от даже устаревших систем, типа PCAD, где есть классификация, где при разработке используется выбор готовых компонент из удобного навигатора по библиотекам, а не "знания" о фреймворке, которые необходимо копить годами. Хаскеля и приведённых тобой ссылок на его библиотеки это тоже касается.
Там выбор ограничен и локален.
Тут рядом была дискуссия насчёт singleton для Map и Set. Они совершенно разные, поэтому бесшовно заменить их нельзя. Если в аппаратуре есть какая-то шина, и смысл её более-менее не важен, то подай Map вместо Set и получишь кучу ошибок в разных удивительных местах.
То есть, локальность изменений в программировании гораздо ниже. Связность выше, и тп.
V>-------- V>И насчёт "чистого" ФП небольшое такое замечание. Я не вижу общих преимуществ функционального преобразователя без памяти над оным же с памятью, это просто разные мат. аппараты, каждый из которых хорош для своего места, с т.з. IT — для своего класса моделей. Аргумент насчёт автоматического распараллеливания вычислений тоже не ахти сильный, ведь функциональный преобразователь с памятью — это совокупность собственно памяти и как минимум пары функциональных преобразователей без оной. Т.е., выделив явно в модели собственно память и эти 2 "чистых" ФП (один — функция вычисления след. состояния, другой — функция выхода) вполне можно использовать имеющиеся наработки для распараллеливания.
Я на распараллеливании собаку съел, если не лошадь. Ответственно заявляю, что чем меньше памяти, тем лучше параллелить. Идеально параллельно выполняется динамический поток данных, он реализует весь доступный параллелизм и там памяти нет вообще.
Однако соль не в этом. Соль чистого подхода в том, что тебе не надо контролировать побочный эффект вообще. Ты не заморачиваешься на поддержание инвариантов кроме тех, что важны для правильного преобразования входных данных в выходные. Нет ничего скрытого. Нет подводных камней. Это очень, очень важно при разработке.
И вдогонку.
Я сейчас занят в создании схемотехнической системы. Там есть и редактор тоже. И мой транслятор с VHDL. Я знаю, что такое разработка визуальных редакторов, во что она обходится, не понаслышке. И я могу сравнивать с разработкой транслятора.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[11]: Два вопроса, один из которых на миллион долларов.
Здравствуйте, vdimas, Вы писали:
V>И я знаю, как раз пол-года назад графический редактор для conferencing white-board сдавали, вполне конечное человеко-время, на пару порядков меньше, чем разработать компилятор того же С++. Если бы не тупая (тупейшая!!!) завязка behaviour-классов из System.Design на виндовые окна, то еще больше времени сэкономили бы, а так пришлось как бы свой мини-фреймворк писать. Ну да для WPF гораздо больше готового, там редактор слепить довольно грамотно и нетрудоёмко можно. Я же говорю — зря товарищ свою задумка на Java пишет, хотя, учитывая возраст разработки — неудивительно.
Не думаю, что для .NET есть больше готового, чем для явы. Особенно учитывая возраст Java.
Но я тебе больше скажу — ничего из готового я практически не использую. Незачем.
Просты вещи вроде менюшки есть везде, в самой убитой библиотеке.
А сложные мне всё равно не подходят. Другая идеология, другая модель, другое назначение.
Дело же не в том, чтоб накидать диалогов и на них контролы повешать. И не в том, чтоб иметь тулкит, который по статическому XML описанию сделает UI интерфейс.
Это всё должно работать в динамике. Модель динамическая с непредсказуемыми элементами, отображение динамически должно меняться в зависимости от комманд пользователя и пр.
Я там писал в статье про адаптацию и специализацию.
Написать графический редактор для conferencing white-board — это создать специализированный редактор.
А написать редактор, который можно настроить на много чего, в том числе и на conferencing white-board — это совершенно другая задача.
Она минимум на порядок сложнее.
И потом, я не на Java пишу. Я генерирую код для JVM, но язык у меня свой.
Это и удобно и нет. Удобно то, что я могу менять синтаксис и семантику так, как мне удобно, в том числе и для решения конкретной задачи. Что делает возможным само продолжение разработки, иначе он давно уже стал бы не поддерживаемым, просто в силу своего размера.
А неудобно то, что нет ни IDE, в котором можно было-бы работать с ним, ни желающие присоединиться не могут это сделать легко, им надо осваивать новый язык.
Поэтому компилируется оно в JVM или .NET — на этом фоне не имеет никакого практического значения.
Мне так кажется.
Но если у тебя есть мысли, почему это надо делать именно на .NET, а не Java или ещё чём — расскажи.
Здравствуйте, mkizub, Вы писали:
M>2. Оно устареет уже через несколько месяцев.
Вообще вся эта затея с SymADE больше похожа на "пойди туда, не знаю куда — найдти то, не знаю что".
Никто этого ещё не делал, никто не сталкивался со всеми проблемами, и курс приходится менять "на ходу".
Я простой пример приведу.
Поставил я себе задачу реализовать IDE для редактирования своего текста.
И решил её! Сделав достаточно сложным язык отображения дерева (для структурного редактора), потратив кучу времени и сил — решил.
Но оказалось, что при всём удобстве редактирования деклараций (в структурном редакторе), редактирование выражений практически невозможно. Жутко неудобно.
У меня было два варианта — делать как в MPS, подставляя костыли и хаки. Или придумать кардинальное решение.
Ясен пень, я пошёл по второму варианту. Это ясно уже из того, что если б я искал простых путей, то мне даже идея SymADE-а не пришла бы в голову.
Итак, я стал искать решение для проблемы редактирования выражений.
Промежуточной идеей было (автоматически, при начале редактирования) конвертировать дерево выражения в список или текст, его редактировать, и обратно компилировать в дерево. Реализовал прототип. Тоже потратил кучу времени.
В процессе долгих и мучительных размышлений я обобщил эту идею редактирования выражений до идеи создания проекций дерева в другое дерево, при котором оба дерева остаются свянанными, и могут синхронизировать свои состояния после изменений.
В результате, оказалось не нужнной такая сложность для языка отображения и структурного редактирования дерева, и ненужным реализация автоматического конвертирования деревьев выражений в списки токенов. Объём работы размером в пол-года (или больше) фактически прийдётся выкинуть. И реализовывать эти самые проекции деревьев (чем я сейчас и занимаюсь) и их редактирование, синхронизацию и пр.
Да, я сходил в одно место, нашёл там тупик, теперь иду в другое место, и там надеюсь найти проход дальше. И когда пройду дальше — там тоже окажется ещё один лабиринт. Се ля ви. Но дорогу осилит идущий.
T>>Обобщённое программирование? GADT? Зависимые типы? T>>Ты всё это знаешь, точно можешь указать на слабые места? V>Программы — это код+данные. Структуры данных и связанный с ними код не всегда удобно описывать (даже не сам код, а мета-код), используя существующие ЯП, иногда хочется наиболее удобного и декларативного (банальности, собственно).
Чем не декларативны обобщённое программирование? Чем не декларативны GADT? Чем не декларативны зависимые типы данных?
Ты не отвечаешь на вопросы.
T>>Lazy не навязан, а предложен для использования в качестве самого удобного из умолчаний. T>>Тебе тоже объяснить, почему он удобен, или ты, всё же, читаешь RSDN? V>Он неэффективен для обработки массивов заведомо известной длины или иных фиксированных структур, например, мне для VoIP, кодеков, фильтрации и работы с сокетами — это седло для коровы. Для GUI — аналогично. Всё хорошо к месту.
"Неэффективен" — это как? Как я понимаю, с точки зрения "производительности", то есть скорости выполнения. Так? Про производительность программиста здесь ни слова.
Из чего заключаю, что, вот, ещё один сторонник преждевременной оптимизации. Блин.
И эти люди указывают мне на "lazy". Да ещё говорят, что я "разговариваю, как сам с собой."
"Врачу, излечися сам."
Ты уж извини, но дальше мне совсем неинтересно. Ты меня не поймёшь, поскольку не желаешь отвечать на вопросы, задаваемые тебе, а я не хочу объяснять тебе долго и нудно истины, ставшие для меня прописными.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, eao197, Вы писали:
M>>Вообще вся эта затея с SymADE больше похожа на "пойди туда, не знаю куда — найдти то, не знаю что".
E>Имхо: после того, как автор проекта приходит к пониманию того, что он не знает цели своего проекта, то самое лучшее (как для проекта, так и для автора) -- выбросить проект нафиг.
Подставился ты...
Любое творчество — есть путь в неизвестное.
Неужели ты до такой степени банальный?
E>>Имхо: после того, как автор проекта приходит к пониманию того, что он не знает цели своего проекта, то самое лучшее (как для проекта, так и для автора) -- выбросить проект нафиг. M>Подставился ты... M>Любое творчество — есть путь в неизвестное.
Это неверно.
Например, иконопись. Творчество, и результат всегда заранее известен (за исключением качества исполнения).
Технический дизайн.
Да ещё найдётся, если поискать.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[13]: Два вопроса, один из которых на миллион долларов.
T>>Ты уж извини, но дальше мне совсем неинтересно. Ты меня не поймёшь, поскольку не желаешь отвечать на вопросы, задаваемые тебе, а я не хочу объяснять тебе долго и нудно истины, ставшие для меня прописными.
L>А как же просвещение? Тут вас много читают. У вас очень здоровый (в смысле достаточно конструктивный) спор. Я, например, много почерпнул и от тебя и от твоего оппонента.
Я не железный, всё не могу.
Лучше я где-нибудь в другом месте себя проявлю.
И на ниве просвещения тоже.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[7]: Программирование, от монолога к диалогу с компьютером
Здравствуйте, thesz, Вы писали:
M>>Любое творчество — есть путь в неизвестное.
T>Это неверно. T>Например, иконопись. Творчество, и результат всегда заранее известен (за исключением качества исполнения).
Ю. М. Лотман. "Каноническое искусство как информационный парадокс". Ознакомься.
Здравствуйте, thesz, Вы писали:
T>Из чего заключаю, что, вот, ещё один сторонник преждевременной оптимизации. Блин.
Замечание про массивы фиксированной длины было ключевым. На это всё завязано в VoIP, в первую очередь — управление памятью. Нет никакой преждевременной оптимизации, отсутствие постоянного перераспределения памяти как такового — это условие существования, без этого система не живёт. Считай, что входное условие. Там 50 фреймов в секунду на участника, да в обе стороны, да через кодеки и препроцессоры, да в минимальном варианте на lazy это будет по 300 выделений памяти в сек. на участника, и скольких же пользователей одновременно потянет сервак? А пару тысяч, хотя бы, потянет? А десять?
T>И эти люди указывают мне на "lazy". Да ещё говорят, что я "разговариваю, как сам с собой."
Есть немного. Суть всех подобных разговоров — это разговоры о приоритетах, даже если явно это слово не используется. Так вот, задачи "просто реализовать" даже не стояло, ибо никто и не сомневался. Надо реализовать в определённых характеристиках.
T>Ты уж извини, но дальше мне совсем неинтересно. Ты меня не поймёшь, поскольку не желаешь отвечать на вопросы, задаваемые тебе, а я не хочу объяснять тебе долго и нудно истины, ставшие для меня прописными.
А как я тебе буду объяснять банальности про зависимые типы и обобщённое программирование, если всё-равно речь упрётся в итоге в много раз обжёванные здесь DSL? Твой поинт в том, что ты считаешь возможности синтаксиса, предоставляемыми некоторыми ЯП (Хаскелем, например) вполне достаточными, а мне даже лень это обсуждать, почему вовсе не являются достаточными — у меня другие требования. Мне не нужны "достаточно широкие возможности", мне нужен именно тот синтаксис декларации данных/метаданных, который хочется использовать для конкретной ситуации, без подгона под "существующие широкие возможности". В условиях активно-используемых генераторов парсеров я могу и хочу себе это позволить.
Да и это все не важно. Твои вопросы не про то, о чем я высказывался, встревая сюда. Ты упорно хочешь говорить лишь "о своём", уводя в сторону, ну да ладно. Тут товарищей с подобными манерами хватает.
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[8]: Программирование, от монолога к диалогу с компьютером
M>>>Любое творчество — есть путь в неизвестное. T>>Это неверно. T>>Например, иконопись. Творчество, и результат всегда заранее известен (за исключением качества исполнения). M>Ю. М. Лотман. "Каноническое искусство как информационный парадокс". Ознакомься.
Ознакомился.
Каноническое искусство играет огромную роль в общей истории художественного опыта человечества. Вряд ли имеет смысл рассматривать его как некоторую низшую или уже пройденную стадию. И тем более существенно поставить вопрос о необходимости изучать не только его внутреннюю синтагматическую структуру, но и скрытые в нем источники информативности, позволяющие тексту, в котором все, казалось бы, заранее известно, становиться мощным регулятором и строителем человеческой личности и культуры.
Это не отрицает предсказуемость результата канонического искусства.
И чтобы два раза не вставать.
"Пойди туда, не знаю куда, принеси то, не знаю, что" лучше всего делать с наиболее быстроходными и грузоподъёмными инструментами.
Java/Kiev в эту категорию, по-моему, не попадают.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[10]: Программирование, от монолога к диалогу с компьютеро
T>>"Пойди туда, не знаю куда, принеси то, не знаю, что" лучше всего делать с наиболее быстроходными и грузоподъёмными инструментами. T>>Java/Kiev в эту категорию, по-моему, не попадают. M>Попадают. Мне хочется это практически сделать, а не теоретически.
То есть, быстрого прототипа для выяснения реализуемости идеи ты не делал. Это великолепно.
M>Толку-то, что я напишу IDE которая ни в одну ОЗУ не влезет, по причине immutable структуры дерева программы, занимающего 100 мег в памяти.
По-моему, это нормально. Даже мало. Тот же Eclipse на работе не влазит в гиг, а я всего десяток файлов смотрю.
M>Покажи мне вообще хоть одну приличную IDE написанную на хаскеле.
Я IDE не пользуюсь. Глядел ли ты на http://haskell.org/haskellwiki/Leksah хотя бы?
M>На лиспе я одну знаю, emacs называется — мне такой не подходит, в том числе и по причинам тормознутости.
А также по причине того, что он готов и его можно использовать.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[3]: Программирование, от монолога к диалогу с компьютером
Здравствуйте, mkizub, Вы писали:
M>Здравствуйте, tid, Вы писали:
tid>>У тебя есть более подробная информация: структура Symade, описания классов, пакетов, форматов данных; что сделано, что планируется сделать?
M>Простой ответ — нету.
Я имею ввиду не документацию, а небольшое описание деталей. То есть почему ты создал свой язык, чем он отличается (хотя бы в основном) от java, какие новшества. В двух словах как устроена среда и общее видение дальнейшего процесса.
Re[6]: Программирование, от монолога к диалогу с компьютером
Здравствуйте, mkizub, Вы писали:
M>Это всё должно работать в динамике. Модель динамическая с непредсказуемыми элементами, отображение динамически должно меняться в зависимости от команд пользователя и пр.
Именно для подобного сценария замечательно подходить WPF из 3-го дотнета. Никакой SWING так не умеет, ибо у него отображение<=>контрол, в то время как в WPF контрол<=>(много отображений) + настраиваемые шаблоны, декларативный биндинг и т.д.
Тем паче, если у тебя есть в планах поддержка дотнета, то сделай паузу, потрать месяц-другой на плотную работу с WPF, оно того стоит. SWING — прекрасно разработан, образец того, как надо абстрагироваться от оконных систем. WFP — образец того, как надо абстрагироваться от GUI как такового. Там, где в SWING настраиваются скины, в WPF настраиваются сами принципы отображения и поведения, да еще с потрясающим уровнем декларативности.
M>Но если у тебя есть мысли, почему это надо делать именно на .NET, а не Java или ещё чём — расскажи.
В основном из-за того, чтобы не делать приличную часть работы по дизайнеру, а сосредоточиться на "ядре".
Генерики, опять же, экономят много времени, ибо доступны в run-time и можно использовать для заранее неизвестных типов. Опять же, хранить данные как value-types в коллекциях — это эффективно использовать память ввиду понижения косвенности обращений к данным. В этой задаче и так предполагается крайне высокий уровень косвенности, всё априори будет тормозить, а на value-type можно уменьшить косвенность примерно вдвое.
А для твоего языка — прекрасный шанс начать уходить от конкретных примитивных классов, завязанных на конкретную платформу, типа строк, чисел, основных коллекций и т.д.
Да и что-то мне подсказывает, что под .Net ты гораздо легче найдёшь волонтёров, ибо мейн-стрим джава-разработок как-то в другой области. Не хочу никого обидеть, но широкое использование XML джавистами и шараханье от задач кастомного парсинга — это не тот контингент, который тебе нужен. Путь себе своим контентом управляют на джумлах и иже с ним.
К тому же, когда переводил неоднократно наработки из Java в дотнет, то исходники становились заметно короче, иногда более, чем в полтора раза. И если GUI-программки при переводе оказывались короче раза в полтора, то интерпретатор Scheme оказался короче раза в два. Я проникся помнится, т.к. ясно увидел, что чем меньше использовано высокоуровневых билиотек в разработке, тем бесполезнее Java-платформа как таковая. А твоё ядро — это тот случай и есть, нет ничего из готового (кроме банальных коллекций).
Re[5]: Программирование, от монолога к диалогу с компьютером
Здравствуйте, mkizub, Вы писали:
M>Весь код доступен среде в виде семантических узлов. Работает с ними она через мета-информацию сгенерированную компилятором. M>Есть язык для задания отображения для конкретных узлов, это отображение рисуется на Canvas, или (если присутствуют только текстовые элементы) может быть использовано для экспорта в текстовое представление. M>Редактор — структурный. Можно посмотреть на документ с картинками (на сайте есть, в документации).
[...]
M>Что дальше. M>Главная задача для развития среды — это наконец реализовать IDE для редактирования кода на моём языке программирования.
Немного оффтопик. Сразу оговорюсь, что моих познаний не достаточно, чтобы дать характеристику вашему с Сергеем спору по существу. У меня есть несколько замечаний по форме.
Я посмотрел картинки на твоём сайте и демо-документ. Имхо всё изложено излишне сложно, и общее впечатление остаётся из серии "тяжёлая громоздка хрень для редактирования XML", и даже XML в ней редактировать неудобно — надо лазить по пунктам меню, что-то нажимать. В общем вместо обещанного повышения производительности будет её значительное замедление. Имхо чтобы привлечь инвесторов, тебе надо сделать изложение более простым и доступным.
И я до сих пор не понял, кто будет основным потребителем твоей супер-IDE. Вряд ли программисты в классическом понимании, потому что твой очень абстрактный подход всегда будет проигрывать частным специализированным решениям в прикладных областях (ну не поверю я, что с его помощью можно сделать конкурентно способный кросплатформенный веб-сервер или хороший 3D-шутер). Скриптописатели бизнес-логики? аналитики? системные архитекторы? менеджеры? — у каждой из этих специальностей есть свои особенности и пожелания к инструментам. Без них даже самый замечательный в теории проект обречён на неудачу.
И наконец, о форме представления данных — да, в теории прямая работа с деревом может давать определённые преимущества. Но на практике мне предложенный в твоём демо-описании способ кажется очень неудобным. Мне кажется, что мышь и клавиатура — не самые подходящие для этого инструменты. И настоящий вопрос на 1M$ — на самом деле больше дизайнерский, чем научный — придумать устройство ввода, удобное для работы с графическим представлением иерархической структуры данных.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Re[6]: Программирование, от монолога к диалогу с компьютером
Здравствуйте, frogkiller, Вы писали:
F>Немного оффтопик. Сразу оговорюсь, что моих познаний не достаточно, чтобы дать характеристику вашему с Сергеем спору по существу. У меня есть несколько замечаний по форме.
F>Я посмотрел картинки на твоём сайте и демо-документ. Имхо всё изложено излишне сложно, и общее впечатление остаётся из серии "тяжёлая громоздка хрень для редактирования XML", и даже XML в ней редактировать неудобно — надо лазить по пунктам меню, что-то нажимать. В общем вместо обещанного повышения производительности будет её значительное замедление. Имхо чтобы привлечь инвесторов, тебе надо сделать изложение более простым и доступным.
Это 10 с плюсом. Чтоб редактировать, надо что-то нажимать.
Я понимаю, что изложить можно попроще, но тогда может получится перл вроде этого.
Конечно, лазить по пунктам меню — вещь утомительная. Но нужная, когда ты не знаешь какую клавишу нажать, чтоб это действие было выполнено.
Можно писать коротко — "создайте новый узел", и пусть читатель догадывается, как его создать. Можно написать "нажмите Ctrl+N или выберите в меню Edit->New node для создания нового узла". Так будет длинно, и туманно — где-то лазить, что-то нажимать, почему компьютер сам не догадается, что мне нужно создать новый узел...
Удобно в нём редактировать. Я же редактирую, мне удобно. Это не plain text, по ощущениям больше похоже на работу в vi. Переключение между режимами ввода текста, ввода комманд, работы со словами-предложениями. Для редактирования деклараций мне практически так-же удобно, как текст набивать. Это если ты знаешь, какой текст набивать, а если не знаешь — то структурный редактор удобнее. Но можно и нужно сделать ещё более удобно. Чарльз Симони (который делает Intentional Programming) где-то у себя писал, что они делали и делают сравнения по удобству/эргономичности редактирования между своим редактором и текстовым — и в IP надо нажимать меньше кнопок, создание кода происходить быстрее и удобнее. Где можно поправить и улучшить у себя я тоже знаю, только не хватает времени на всё.
Я писал для инвесторов много и разнообразно. Один параграф, три параграфа, страница, три страницы...
Я писал для них ура-предложения, что дадите немного денег и будет вам щастье. Я писал объяснения откуда это щастье возьмётся. Первое им нравилось, и они говорили, что да, очень интересно, вы ещё инвесторов поищите — с таким изложением обязательно найдёте. Второе им совсем не нравилось, оно было заумно и непонятно. Они пытались выяснить что-же на самом деле имеется в виду, какое-то время со мной общались, наконец понимали небольшой процент из сказанного (и то, очень своеобразно). И удовлетворившись своей проницательностью рекомендовали мне это изложить попроще и тогда я обязательно найду инвестора.
F>И я до сих пор не понял, кто будет основным потребителем твоей супер-IDE. Вряд ли программисты в классическом понимании, потому что твой очень абстрактный подход всегда будет проигрывать частным специализированным решениям в прикладных областях (ну не поверю я, что с его помощью можно сделать конкурентно способный кросплатформенный веб-сервер или хороший 3D-шутер).
Вот именно, кросплатформенный веб-сервер, хороший 3D-шутер, и многое другое. То, что ты в этом не веришь сейчас, не значит, что это не так.
Что нужно для хорошего шутера? Красивая графика — а она делается на специализированном языке для шейдеров. Хороший скрипт (сценарий), чтоб было багов поменьше и интеллекта поболее. Значит пишут свой скриптовый язык программирования, ориентированный на данный жанр и даже на данную игру, и пишут на нём код. Много кода. Мегабайты скриптового кода. Ты думаешь, можно написать мегабайты скриптового кода быстро и без багов? Не получается. Пока это пара файлов — всё отлично. А как только пошёл большой код — баг на баге. Вот и делают игрушки 5 лет, вместо 1 года.
Или ты думаешь, что кросс-платформенный веб-сервер можно делать без кросс-платформенных абстракций? Нельзя. Можно взять яву, которая и будет кросс-платформенной абстракцией. Хорошо, если она приспособлена для изготовления веб-серверов, а если нет? Даже понятие файла, уж где взять более общее и стандартное — и то разное в разных операционках, когда доходит до деталей реализации быстрого доступа.
F>Скриптописатели бизнес-логики? аналитики? системные архитекторы? менеджеры? — у каждой из этих специальностей есть свои особенности и пожелания к инструментам. Без них даже самый замечательный в теории проект обречён на неудачу.
SymADE — Symbolic Adaptable Development Environment.
Это значит, что я его хочу написать таким, чтоб его можно было адаптировать, приспособить к разным требованиям, особенностям и пожеланиям.
Адаптировать до такой степени, чтоб он был лишь немного хуже специализированного решения.
F>И наконец, о форме представления данных — да, в теории прямая работа с деревом может давать определённые преимущества. Но на практике мне предложенный в твоём демо-описании способ кажется очень неудобным. Мне кажется, что мышь и клавиатура — не самые подходящие для этого инструменты. И настоящий вопрос на 1M$ — на самом деле больше дизайнерский, чем научный — придумать устройство ввода, удобное для работы с графическим представлением иерархической структуры данных.
Мозг
Научиться думать картинками.
Когда ты знаешь, что писать — уже без разницы, текст это или дерево, сколько нажатий кнопок на это нужно — только бы оно позволило это написать.
Здравствуйте, 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]: Программирование, от монолога к диалогу с компьютером
Здравствуйте, 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 может помочь хорошие игрушки писать. Ты тоже всё ещё сомневаешься, или уже согласен, что таки может?
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)
Мысль в том, чтобы отказаться от произвольного набора методов классов и "хаотического" их вызова, а всё взаимодействие осуществлять через очень небольшое кол-во универсальных контрактов, примерно как и работают ядра моделирующих тулзов. 
