Г-н Жаринов , по теме - вы как единственный здесь специалист по графическим псевдоязыкам.. хотелось бы услышать ваше мнение о разработке В. Лаптева и Ко. - коль скоро поднят этот вопрос (только без зауми - уважайте собеседников please).
Чой-то польстили Вы мне... до специалиста, полагаю, далеко...
Так чисто для уточнения - по-моему, говорим просто о способе переписать часть текстовой нотации в графовую... "псевдоязык" как-то подразумевает замену текста графом целиком... и в таком разумении вызывает ассоциации с "суперязыком" (возможно, Ваше "псевдо" - естественная реакция на "супер")...
Чё за часть, уже говорил - если без зауми, то описывающая структуру описуемого...
Ну и для меня такая смешанная (графитная) нотация - не что-то, волшебным образом делающее иначе, чем текст (для "адептов" - ессно, всегда лучше
)... А эквивалент текста. Потому, когда дальше буду говорить о свойствах графит-нотаций, операциях с ними - всё можете относить и к прогтексту. Из этого есть только исключение, когда мы чего-то описываем "неинформатизуемое" - т.е. не дискретное/конечное. Пример как-то приводил Крюков для ЛИСПа:
...
В частности, все структуры графовой записи д.б. представимы в текстовой как конечные структуры из абстрактных типов[ данных] - и наоборот. Как только мы имеем запись вида "<что-то> в периоде" - это значит, что в процессе моделирования/формализации мы оказываемся на математической стадии. И "заложить это в машину" в таком виде не удастся.
Это нетрудно видеть на примере из книги Крюкова в
этом сообщении (на с. 11-12). В самом деле, запись граф-схемой конечна, а текстовым скобочным выражением - нет. А это значит, что в текстовой форме информатизация данной сущности на данном языке не получилась.
В частности, эта структура изображает одну из возможных произвольных структур данных. Что означает, что язык скобочных выражений не может описать, скажем, АТ-схемы с указателями в ряде случаев. Причём можно "даже не париться на эту тему" - т.к. пример у Крюкова уже есть контрпример для такого приложения этого языка.[/list]
...
- прошу прощения за вложенные ссылки, но так быстрее ответ готовить...
Ну и что можно сказать по ВЛ-редактору? В принципе уже там говорил, чего бы хотелось:
http://forum.oberoncore.ru/viewtopic.php?p=74176#p74176. Если что-то вызывает вопросы - отвечу.
Сразу могу уточнить, что Илья дело говорил - надо не только напрямую структурные слова текста в графы переводить - но и додумать ряд типов схем, представляющих "то, что неочевидно из текста". Так и в ЕСКД. Для программ в этом смысле пока как "пробный камень" вижу
FIELD - скорее по базовому составу схем (синтаксис в ряде случаев видел бы другим). Нужны ещё схемы для представления работы многих исполнителей - параллельной в том числе. Цель обозначал "один чувак", которому не чужд Оберон на РСДНе:
...
Буквально единицы лет назад в академических кругах научились делать "суперкомпиляторный анализ" императивного кода, до этого вообще был детский сад, представляющий из себя чуть продвинутую бета-редукцию над ФП.
Почему так медленно идёт движение в этой области? Любое ветвление в программе — это лишний множитель комбинаторного кол-ва вариантов исполнения, то бишь сложность анализа от сложности алгоритма — степенная. Современные компиляторы проводят анализ в самых простейших случаях до 10 уровней глубины, в сложных — дай бог 2-3. Исходники gcc открыты, можно посмотреть самому.
Понимаешь, из-за степенной природы происходящего, наблюдаемая вроде бы неплохая геометрическая прогрессия в росте мощщи железа ничего кроме пессимизма не вызывает. Ни ты, ни я не увидим "золотого века IT". Например, gcc в последних версиях медленно но верно догоняет MS VC по эффективности конечного образа. Именно поэтому gcc таки относительно скоро нагонит MSVC, что он его настигнет прямо в точке насыщения возможностей, выжимаемых из машин разработчиков.
Это я всё к тому, что в течении ближайших 10-20 лет никакое самое вылизанное ФП по эффективности не догонит аналогично вылизанный императив даже близко.
На плюсах я сижу неплотно лет 20, плотно более 15 лет. Все их достоинства и недостатки собственной задницей ощущал не раз, так же как знаю как с ними бороться. Я могу выжимать из машины максимум, умею это и люблю. Помимо выжимания, есть определенные способности находить нетривиальные ошибки даже в чужом коде. Считай, у меня в сформировалась некая статистика по причинам всех этих ошибок.
Самые популярные, ес-но, не те ярлыки, которые навешивают на плюсы — типа выхода за границы диапазонов. Самые популярные сегодня — это неверное представление о работе собственных многопоточных программ, иногда откровенные гонки. Причем, эти гонки не из-за непоходимости разработчиков, ес-но, а из-за всего здесь обсуждаемого, из-за скрытого неявного поведения/зависимостей, которое в реальном коде образуется немыслимыми сочетаниями сценариев. Обычный разработчик уже на глубину более 3-х уровней зависимостей смотрят с ооочень большим трудом и не часто. В идеале хотелось бы 1 уровень. И мне/нам обсуждаемые языковые ср-ва помогут заметно сэкономить на отладке. А если брать предлагаемую банальную иммутабельность — наоборот, добавит работы и снизит эффективность решения.
- что здесь так или не так, пусть ИТ-теоретики бодаются...
Вроде как Лаптев заявлял, что многое из этого либо есть, либо планируется.
Но. Ещё неясно, как поддержка работы над проектом реализована - коллективной и с версиями. А как оправданно - это, считаю, не у меня надо спрашивать... у Александра Сергеевича... кстати, и как отобрать эти средства и организовать их в стройную среду поддержки разработки программных
систем - тоже...
И ещё. Позиция авторов уточняется время от времени. Текущее:
http://forum.oberoncore.ru/viewtopic.php?p=74296#p74296 - заставляет предположить, что в "жёстком" учебном режиме все языки будут без goto... Что в "исчислении графов" реализуется как только ввод атомов (ну и добавление/удаление маршрутов в составные атомы/заготовки - вроде как
здесь и
здесь показано). Но надо их самих спрашивать...
