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[10]: Два вопроса, один из которых на миллион долларов.
Здравствуйте, 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 пишет, хотя, учитывая возраст разработки — неудивительно.
В принципе, если увижу/придумаю/пойму "как надо", то графический редактор накатаю быстро, не волнуйся, ибо это будет сугубо инженерная задачка. А пока что в обсуждениях, типа "спроектировать интерфейс визуального редактора запросов" вот это вот угрёбище
Здравствуйте, 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 или ещё чём — расскажи.
Здравствуйте, tid, Вы писали:
tid>У тебя есть более подробная информация: структура Symade, описания классов, пакетов, форматов данных; что сделано, что планируется сделать?
Простой ответ — нету.
Развёрнутый:
По разным причинам.
1. Чтоб это написать — надо сесть и месяца три потратить только на это.
2. Оно устареет уже через несколько месяцев.
3. Описание "что делать" сильно зависит от бизнес-части проекта, под которую ищутся инвесторы; и вот когда инвестор найдётся — с этим можно будет определиться. Слишком разные области есть в программировании, и если делать для всей индустрии — то нужны многие миллионы баксов и годы работы. Если делать для какой-то ниши — то это намного меньше, и в деньгах и в сроках. Но нужно знать для какой!
4. Даже если бы оно и было, то новый человек просто не сможет освоить структуру проекта просто сев и прочитав документацию. Большой объём и очень разные части. От спецического языка программирования до специфической реализации и кодогенерации.
В большой проект люди входят постепенно. Решая какую-то, вначале несложную, потом всё сложней, реальную задачу. Во время этого процесса они знакомятся с достаточно большой частью проекта, и начинают в нём свободно ориентироваться. Так происходит всегда. Даже если этот продукт уже законченный, и на него есть документация и прочие спецификации — всё равно человек входит не через них. Просто в силу специфики устройства и когнитивных процессов нашего мозга.
Если у тебя есть какая-то задача, то я могу рассказать как её делать, с какой стороны подходить, описать общую структуру на текущий момент.
Если просто поиграться — то увы, пока она не дойдёт до стадии беты, что включает в себя и доведение до ума IDE, чтоб на неём можно было полноценно редактировать и отлаживать весь код, и включает в себя тот самый минимум документации — тогда уже можно будет его пощупать.
