Здравствуйте, AleksandrN, Вы писали:
AN>Конечные автоматы известны и применяются давно. Легко реализуются с помощью матриц. Применяются в программировании уже давно — например, при создании лексических анализаторов в компиляторах. AN>Поэтому прошу пояснить, что имеется в виду в предложении "именно ДРАКОН даёт автоматам дорогу в остальные отрасли программирования"?
Размещаю ответ Степана Митькина:
Здравствуйте, AleksandrN, Вы писали:
AN>например, при создании лексических анализаторов в компиляторах.
Правильно! А ещё для парсеров.
Также они удобны для: хождения по деревьям/графам, управления гуём, управления долгими операциями ввода-вывода (например, в браузере) и много чего другого.
AN>Поэтому прошу пояснить, что имеется в виду в предложении "именно ДРАКОН даёт автоматам дорогу в остальные отрасли программирования"?
К сожалению, для большинства программистов конечные автоматы — экзотика.
Скажешь "класс" — кивают головой.
Скажешь "автомат" — морщат лоб, вспоминают универ. То есть каждый день автоматы не применяют.
Оно понятно. В языке C#, например, родной поддержки автоматов нет. А ДРАКОНовская конструкция "силуэт" прям как будто специально сделана для автоматов.
ДРАКОН чем тут хорош? На одной визуальной сцене есть:
1. Описание состояний и переходов.
2. Логика автомата (то есть принятие решений, чего делать. "если, то" и т.п.)
Здравствуйте, Владимир Паронджанов, Вы писали: ВП>Скажешь "автомат" — морщат лоб, вспоминают универ. То есть каждый день автоматы не применяют. ВП>Оно понятно. В языке C#, например, родной поддержки автоматов нет. А ДРАКОНовская конструкция "силуэт" прям как будто специально сделана для автоматов.
Еще раз в C# есть yield который используется в куче итераторов. В том числе и для async await
Так что поддержка есть и используется в огромном числе итераторов для рекурсивного обхода деревьев и для асинхронного программирования.
Во всех случаях запоминается состояние и при вызове MoveNext переходит в новое состояние.
Так, что если не знают, это не значит, что не используют
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Владимир Паронджанов, Вы писали:
ВП>Существующие способы записи алгоритмов и программ (принятые во всем мире) слишком трудны для понимания и требуют неоправданно больших трудозатрат. ВП>Это обстоятельство ставит непреодолимый барьер для многих специалистов, работа которых связана с алгоритмами, но которые не имеют резерва времени, чтобы научиться выражать свои профессиональные знания в форме алгоритмов и программ.
Для кого ни слишком трудны? Какие конкретно специалисты не могут преодолеть этот барьер?
Более серьёзно по теме: по-моему все эти затеи с рисованием вместо писания решают не ту проблему. Проблема не в том, что алгоритм сложно записать. Проблема в том, что алгоритм сложно составить. Для этого надо иметь определенный набор интеллектуальных навыков, которые позволяют формализовать проблему и её решение. То есть перейти от неполного и неоднозначного описания на естественном языке к полному, однозначному и непротиворечивому описанию на формальном. Какой формальный язык не придумай — он останется формальным. Были идеи, что если напихать в язык побольше английских слов, то он станет простым. Не сработало.
Теперь идея в том, что если не писать, а рисовать, то программирование станет простым. Тоже не сработало.
Вот когда "ДРАКОН" или кто там ещё научится понимать постановку задачи "сделай мне чтобы как скайп, только цвета поприкольнее, и чтоб не тормозило.", тогда прорыв и случится.
Re[2]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, 0x7be, Вы писали:
ВП>>Существующие способы записи алгоритмов и программ (принятые во всем мире) слишком трудны для понимания и требуют неоправданно больших трудозатрат. ВП>>Это обстоятельство ставит непреодолимый барьер для многих специалистов, работа которых связана с алгоритмами, но которые не имеют резерва времени, чтобы научиться выражать свои профессиональные знания в форме алгоритмов и программ. 0>Для кого ни слишком трудны? Какие конкретно специалисты не могут преодолеть этот барьер?
Таких людей очень много. Например, инженеры НПЦАП, где я работаю. Добавьте сюда (отчасти) программистов-любителей, то есть непрофессиональных программистов. Да и у профессионалов тоже есть трудности.
Вот цитата:
По нашей статистике, которую мы собираем уже несколько лет, из 20 человек, называющих себя программистами, только один действительно им является. Сначала мы рассчитывали статистику по количеству человек, которые в состоянии на очном собеседовании на листе бумаги написать код по задаче, аналогичной FizzBuzz. Потом мы поняли, что такой проверки недостаточно, и валидировали эту статистику другим способом.
0>Более серьёзно по теме: по-моему все эти затеи с рисованием вместо писания решают не ту проблему. Проблема не в том, что алгоритм сложно записать. Проблема в том, что алгоритм сложно составить. Для этого надо иметь определенный набор интеллектуальных навыков, которые позволяют формализовать проблему и её решение. То есть перейти от неполного и неоднозначного описания на естественном языке к полному, однозначному и непротиворечивому описанию на формальном. Какой формальный язык не придумай — он останется формальным.
Вы высказываете очень интересные соображения. Спасибо.
0>Были идеи, что если напихать в язык побольше английских слов, то он станет простым. Не сработало. 0>Теперь идея в том, что если не писать, а рисовать, то программирование станет простым. Тоже не сработало.
Вы правы. Следует различать текстовое и визуальное программирование.
Почти все современное программирование является текстовым. В этой области накоплен огромный, даже гигантский опыт.
Что касается визуального программирования, то оно делает лишь первые робкие шаги.
Здесь еще пахать и пахать. Тут я с Вами не могу согласиться. Вы говорите: "не сработало".
А я говорю: пока еще рано делать выводы. Цыплят по осени считают.
Что значит "рисовать"? Рисовать можно плохо. А можно хорошо.
Можно ли отличить плохое рисование от хорошего?
Плохое визуальное программирование от хорошего? Где критерий?
Одним из критериев является КОГНИТИВНАЯ ЭРГОНОМИКА.
Я согласен с Вами, что
"Проблема не в том, что алгоритм сложно записать.
Проблема в том, что алгоритм сложно составить".
Мое добавление. Чтобы облегчить сложную работу по составлению сложного алгоритма,
нужно создать не просто формальный язык, а ЭРГОНОМИЧНЫЙ ВИЗУАЛЬНЫЙ формальный язык.
ДРАКОН и является именно таким языком.
С уважением В. Паронджанов
Re[3]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, Владимир Паронджанов, Вы писали:
ВП>Что касается визуального программирования, то оно делает лишь первые робкие шаги. ВП>Здесь еще пахать и пахать. Тут я с Вами не могу согласиться. Вы говорите: "не сработало". ВП>А я говорю: пока еще рано делать выводы. Цыплят по осени считают.
Ну так продемонстрируйте это! Напишите хотя бы компилятор самого себя и пару крупных проектов.
Sapienti sat!
Re[4]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, Cyberax, Вы писали:
C>Ну так продемонстрируйте это! Напишите хотя бы компилятор самого себя и пару крупных проектов.
Такая работа уже давно проделана.
С помощью визуального языка ДРАКОН созданы не два, а 14 не просто крупных, а сверхкрупных, грандиозных по масштабам космических проектов.
Цитирую:
Язык ДРАКОН и ДРАКОН-технология эксплуатируются в НПЦАП уже 20 лет (1996–2016 годы). За это время они помогли создать системы управления четырнадцати космических проектов:
— разгонный блок космических аппаратов ДМ-SL (проект «Морской старт»);
— модернизированная ракета-носитель тяжелого класса ПРОТОН-М;
— семейство разгонных блоков ФРЕГАТ, которое включает: просто ФРЕГАТ, ФРЕГАТ-СБ (со сбрасываемыми баками), ФРЕГАТ-УТТХ (с улучшенными тактико-техническими характеристиками), ФРЕГАТ-МT, предназначенный для запусков из Южной Америки, ФРЕГАТ-СУМ (с модернизированной системой управления);
— разгонный блок космических аппаратов ДМ-SLБ (проект «Наземный старт»),
— разгонный блок космических аппаратов ДМ-03,
— первая cтупень южнокорейской ракеты-носителя KSLV,
— три проекта семейства Ангара: ракета-носитель легкого класса АНГАРА-1.2 первого пуска, ракета-носитель легкого класса АНГАРА-1.2 с агрегатным модулем, ракета-носитель тяжелого класса АНГАРА-А5;
— разгонный блок КВТК (кислородно-водородный тяжелого класса) [5, с. 515].
Пуски ракет-носителей и разгонных блоков, при создании которых использовался язык ДРАКОН, производятся или производились с пяти космодромов мира:
— Плесецк,
— Байконур,
— Kuru (Французская Гвиана),
— плавучий космодром «Морской старт» (экваториальная зона Тихого океана),
— Naro (Южная Корея).
Я процитировал источник, опубликованный в 2016 году. Сегодня к списку космодромов следует добавить шестой космодром — Восточный.
Здравствуйте, Владимир Паронджанов, Вы писали:
C>>Ну так продемонстрируйте это! Напишите хотя бы компилятор самого себя и пару крупных проектов. ВП>Такая работа уже давно проделана.
Не верю.
ВП>С помощью визуального языка ДРАКОН созданы не два, а 14 не просто крупных, а сверхкрупных, грандиозных по масштабам космических проектов.
Покажите код.
Sapienti sat!
Re[5]: Язык ДРАКОН — новая идея в программировании
DRAKON is an algorithmic visual programming language developed within the Buran space project following ergonomic design principles. The language provides a uniform way to represent flowcharts of any complexity that are easy to read and understand.
The DRAKON Editor, which was released in September 2011, is an implementation of the language available in the public domain. It can be used for creating documentation, or for creating visual programs that can be converted to source code in other languages.
Unlike UML's philosophy, DRAKON language philosophy is based on being augmented if needed, by using a hybrid language, which can be illustrated as "eating code snippets from text language used". This way, DRAKON stays a simple visual language, that can, in fact, be used itself as an augmentation language for a programmer, who is interested in improving ergonomics of coding process or to make code easy to review and understand.
DRAKON is Russian acronym that says "Дружелюбный Русский Алгоритмический [язык], Который Обеспечивает Наглядность", i.e. "Friendly Russian algorithmic [language] that provides illustrativeness". The word "наглядность" (pronounced approximately as "naa-glya-dno-st-th") refers to a quality of concept or idea being easy to imagine and understand, and may be translated as "clarity" as well.
It is to note, that DRAKON language can be used both as modelling language (standalone use) and as programming language (use as part of a hybrid language). Such approach allows to view DRAKON as a way to add syntactic sugar into any supported programming language user programmer is qualified to use.
Contents [hide]
1 History
2 Family of DRAKON-languages (hybrid languages)
3 DRAKON's philosophy and purposes
4 Examples
4.1 Branching
4.2 Check-do (while) loop
4.3 Do-check (do-while) loop
5 DRAKON Editor
5.1 Features
6 Notes
7 References
8 External links
History[edit]
The development of DRAKON started in 1986 and was directed by Vladimir Parondzhanov with the participation of Russian Federal Space Agency (Academician Pilyugin Center, Moscow) and Russian Academy of Sciences (Keldysh Institute of Applied Mathematics). The language was constructed by formalization, ergonomization and nonclassical structurization of flowcharts described in the ISO 5807-85 standard and Russian standard «Гост 19.701-90» and for the development of real time programs.[1][2]
The goal was to replace specialised languages PROL2 (ПРОЛ2) (assigned for developing onboard complex software for embedded computer system Biser-4 (Бисер-4) on board of Buran),[3] DIPOL (ДИПОЛЬ) (assigned for developing software for ground maintenance computer system of Buran)[3] and LAKS (ЛАКС) (assigned for modelling) used in the Buran project with one universal programming language.
The work was finished in 1996 (3 years after the Buran project was officially closed), when an automated CASE programming system called "Grafit-Floks" was developed.[4]
This CASE is used since 1996 in many major space programs: an international project Sea Launch, Russian orbit insertion upper stage Fregat (Russian: Фрегат, frigate),[5] upgraded heavy launch vehicle (carrier rocket) Proton-M, etc.
DRAKON rules for creating diagrams are cognitively optimized for easy comprehension, making it a tool for intelligence augmentation.[1][6][7][8]
Family of DRAKON-languages (hybrid languages)[edit]
Icons of DRAKON language
Macroicons of DRAKON language.
DRAKON (Russian: ДРАКОН) is designed with humanistic ideas in mind, as usage of three different languages for the same project was a source of human factor-related hardships such risks of having a mutual misunderstanding.
DRAKON is used not as a single stand-alone language but as a family of hybrid languages, such as DRAKON-C, DRAKON-ASM, DRAKON-Java, etc. All hybrid languages of the DRAKON-family have the uniform graphical syntax, based on flowcharts. The standard graphical syntax provides similarity of drakon-charts for different hybrid languages. The text language used uses its own syntax.
Strict distinction of the graphical and textual syntax along with rich graphics improves flexibility and variety of expressive means of the language. The unification of the rules of the graphical syntax in the hybrid languages secures their conceptual unity.
The basis of the graphical syntax is a graphical alphabet. Graphical elements (graphical letters) of the DRAKON alphabet are called icons (not symbols). There are 27 icons in the DRAKON graphical alphabet.
DRAKON has not only icons, but also macroicons. Macroicons are the graphical words of the DRAKON language. Just as words are made up of letters, macroiсons (graphical words) consist of the icons (graphical letters). There are 21 macroicons in the DRAKON language.
Icons and macroiсons are the building blocks for constructing drakon-charts.
The important parts of maсroiсons are valence points (in the illustration to the right, they are depicted as little black circles). Into these points, icons or microicons can be successively entered and arranged by drakon-editor in neat, orderly vertical rows.
DRAKON's philosophy and purposes[edit]
DRAKON was created as a language with a set of rules that would allow to depict algorithms in fields, not necessarily related to computing, being easy to learn. The main reason that led to the development of the language was emerging risk of misunderstanding, and following errors upon interaction between different programming languages (namely, DIPOL, LAX and PROL2).
DRAKON serves as an easy to use tool, that improves communication between programmers, who mastered different programming languages: drakon-chart, by being closely similar to a traditional flowchart (yet with additional functionality for text language code, such as code snippeds, provided a hybrid is used) allows to produce and keep readable flowchart at hand simultaneously with process of making the program in question.
DRAKON is notable for being used without programming language syntax, but with spoken language, for illustrative purposes. Namely, in the medicine field in Russia as a way to compose flowchart-like algorithms, that both create a map-like gide for patients and form instructions for medical personnel.
Sometimes DRAKON icons are being modified by inserting a photo as icon's filler under the text, forming a sort of formally strict and easy to modify infographics.
Здравствуйте, Владимир Паронджанов, Вы писали:
ВП>Привожу цитату из статьи DRAKON английской Wikipedia
Спасибо, я поправил Вики.
ВП>https://en.wikipedia.org/wiki/DRAKON
Код мне покажите, код. Хватит уже цитат самого себя.
Что сложного-то написать хотя бы компилятор себя? Тем более, что ДРАКОН в текущем виде — это просто препроцессор, без реальной логики.
Рассказываю как это делают другие проекты. Например, возьмём язык Rust — он основан в 2010-м году и предназначен для создания надёжных систем.
Первая версия была на OCaml'е, но уже через год компилятор была переписан на сам Rust.
Первый крупный проект (Servo) был начат в 2012-м году и к 2014-му году уже начал быть полезным на практике. К 2016-му году имеются тысячи проектов сторонних разработчиков (https://crates.io/).
В 2015-м году начат проект по статическому доказательству правильности небезопасных частей стандартной библиотеки ( http://plv.mpi-sws.org/rustbelt/ ). Параллельно идёт проект по переформулировке системы типов в виде логических утверждений с возможностью автоматического доказательства их корректности ( https://github.com/nikomatsakis/chalk ).
Sapienti sat!
Re[7]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, Cyberax, Вы писали:
C>Код мне покажите, код.
Я уже отвечал на такой вопрос:
Дата: 29.05.17 19:15
Здравствуйте, AleksandrN, Вы писали:
AN>прошу выложить какие-нибудь исходники реального ПО на Драконе, а не учебных примеров. Среда разработки и компилятор Дракона написаны на Драконе? Где можно посмотреть исходники?
Я работаю в НПЦАП им. акад. Н.А. Пилюгина (свыше 56 лет). Это закрытый научно-производственный центр. Исходники я выложить, к сожалению, не могу. Не имею права.
Здравствуйте, Владимир Паронджанов, Вы писали:
ВП>Такая работа уже давно проделана. ВП>С помощью визуального языка ДРАКОН созданы не два, а 14 не просто крупных, а сверхкрупных, грандиозных по масштабам космических проектов.
Так у вас же и алгоритм управления дверным замком "сложный" с ваших слов. Нет ли у поклонников Дракона тенденции гипертрофировать сложность и размер задач, как это видно на примерах с логическими выражениями и сортировкой?
У Маска ведь как-то что-то летает без 20-и лет разработок и сверхкрупных программных проектов...
Можно узнать критерии, по которымм вы оцениваете проекты как сверхкрупные? LOC, или там, человеко-часы... Хотя, человеко-часы не надо. Просто я работал в одном ядерном НИИ. Там тоже делали сверхкрупные проекты, умудряясь коллективом из 5и активных разработчиков создавать двухнедельную очередь в тетради на обладание дискетой, на которой был файл с определением глобальных переменных проекта. В этом веке, кстати.
Re[5]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, Владимир Паронджанов, Вы писали:
ВП>Такая работа уже давно проделана. ВП>С помощью визуального языка ДРАКОН созданы не два, а 14 не просто крупных, а сверхкрупных, грандиозных по масштабам космических проектов.
Грандиозность и сверхкрупность это сколько строк кода и сколько элементов на схемах Дракона?
То, что не можете показать код проектов, сделанных для космонавтики — понятно. Возможно — для космической отрасли Дракон годится лучше, чем другие технологии. Поскольку не знаком с предметной областью не могу оценить, насколько Дракон лучше/хуже других подходов для создания ПО для космонавтики.
Но — вы позиционируете Дракон как инструмент для создания ПО для любой цели и утверждаете, что ваш подход лучше, чем другие технологии. Если хотите убедить всех в преимуществах Дракона перед другими технологиями — нужно что-то больше, чем учебные примеры и рассказы о применении. Создайте на Драконе инструменты для программирования на Драконе. Степан Митькин некоторые такие инстументы создал, но их недостаточно. Сделайте библиотеки для работы с, часто используемыми, структурами данных — связанными списками, бинарными деревьями, строками. Сделайте библиотеки для, часто возникающих, задач — работа с сетью, потоками, файлами, GUI, БД, временем (с учётом часовых поясов). Сделайте средства инеграции с системами контроля версий, что бы можно было посмотреть когда и какие изменения вносились в схему. Выложите исходники всех этих библиотек. Если Дракон имеет преимущества, то весь этот код скажет о них лучше, чем множество слов и учебных примеров. Да и обсуждение вашей технологии будет более предметным и можно будет лучше понять преимущества и недостатки вашего подхода к разработке ПО.
Здравствуйте, Владимир Паронджанов, Вы писали:
ВП>Я работаю в НПЦАП им. акад. Н.А. Пилюгина (свыше 56 лет). Это закрытый научно-производственный центр. Исходники я выложить, к сожалению, не могу. Не имею права.
Я уже это слышал. Потому повторяю, вы врёте про то, что ДРАКОН для чего-то существенного используется и просто прикрываетесь "секретностью".
Иначе за 6 лет могли бы потратить пару месяцев на то, чтобы продемонстрировать всю крутизну, написав ХОТЯ БЫ ОДИН существенный публичный проект.
Sapienti sat!
Re[6]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, AleksandrN, Вы писали:
AN> вы позиционируете Дракон как инструмент для создания ПО для любой цели и утверждаете, что ваш подход лучше, чем другие технологии.
Не совсем так. Я не говорил, что дракон лучше, чем другие технологии для создания ПО. Возможно, я где-то употребил неосторожные выражения, и меня неправильно поняли. Если это действительно было сказано, то я готов взять свои слова обратно.
Во избежание недоразумений, позвольте мне заново сформулировать свою позицию.
1. Нотация Дракона лучше, чем другие нотации для записи АЛГОРИТМОВ (именно алгоритмов, а не программ).
2. Существующие нотации для записи алгоритмов (именно алгоритмов, а не программ) уступают нотации ДРАКОНа.
3. Исходя из этого, я делаю предположение (или, что одно и то же, выдвигаю гипотезу), что использование нотации ДРАКОНа в области программирования может дать заметные преимущества. Я отчетливо сознаю, что разработка новых технологий программирования на основе нотации ДРАКОНа — это очень большая работа, которая займет многие годы или даже десятилетия.
4. Но я верю, что рано или поздно найдутся энтузиасты, которые примут близко к сердцу идею ДРАКОНа, поверят в нее и дадут ей путевку в жизнь.
AN>Если хотите убедить всех в преимуществах Дракона перед другими технологиями — нужно что-то больше, чем учебные примеры и рассказы о применении. Создайте на Драконе инструменты для программирования на Драконе. Степан Митькин некоторые такие инстументы создал, но их недостаточно. Сделайте библиотеки для работы с, часто используемыми, структурами данных — связанными списками, бинарными деревьями, строками. Сделайте библиотеки для, часто возникающих, задач — работа с сетью, потоками, файлами, GUI, БД, временем (с учётом часовых поясов). Сделайте средства инеграции с системами контроля версий, что бы можно было посмотреть когда и какие изменения вносились в схему. Выложите исходники всех этих библиотек. Если Дракон имеет преимущества, то весь этот код скажет о них лучше, чем множество слов и учебных примеров. Да и обсуждение вашей технологии будет более предметным и можно будет лучше понять преимущества и недостатки вашего подхода к разработке ПО.
Вы говорите дельные вещи и я полностью согласен с Вашими соображениями.
Для реализации этого нужны молодые силы и соответствующие ресурсы.
Мне 79 лет и мои силы ограничены.
Я вижу свою задачу в том, чтобы написать еще несколько книг про язык ДРАКОН и передать эстафету молодежи.
Здравствуйте, Владимир Паронджанов, Вы писали:
ВП>1. Нотация Дракона лучше, чем другие нотации для записи АЛГОРИТМОВ (именно алгоритмов, а не программ).
Очень может быть. С поправкой — другие ГРАФИЧЕСКИЕ нотации.
ВП>2. Существующие нотации для записи алгоритмов (именно алгоритмов, а не программ) уступают нотации ДРАКОНа.[/b]
Аналогично.
ВП>3. Исходя из этого, я делаю предположение (или, что одно и то же, выдвигаю гипотезу), что использование нотации ДРАКОНа в области программирования может дать заметные преимущества. Я отчетливо сознаю, что разработка новых технологий программирования на основе нотации ДРАКОНа — это очень большая работа, которая займет многие годы или даже десятилетия.[/b]
А вот тут нет. Современное программирование практически никогда не имеет дело с графическим представлением алгоритмов. Ибо это никому не нужно. Первоначальный дизайн алгоритма чаще всего делают на бумажке на псевдокоде в текстовом виде. Графически представлять алгоритмы требуется крайне редко. Графическое представление имеет смысл для общей архитектуры системы, это реально бывает полезно.
Проблема графического представления следующая. Простой алгоритм одинаково легко читается как в графическом представлении, так и в текстовом. Но текстовое представление всегда более компактное. Для текстового представления можно сделать diff, то есть видно что когда поменял ранее. И кстати, современное текстовое представление программ де факто является еще и графическим. Ибо путем хорошего форматирования добиваются понятности, плюс современные среды разработки еще дополнительно стараются выделить важные элементы, например другим шрифтом, другим цветом и т.д, зачастую прямо в IDE делают преобразование каких то громоздких конструкций в гораздо более читаемый вид. То есть именно в программировании сейчас никаких революций именно в нотациях не сделать. Можно только эволюционно делать уже существующее все более и более удобным, что собственно делается и делается весьма успешно.
ВП>4. Но я верю, что рано или поздно найдутся энтузиасты, которые примут близко к сердцу идею ДРАКОНа, поверят в нее и дадут ей путевку в жизнь.[/b]
Вполне возможно. Но только не в программировании! Современное программирование ОЧЕНЬ отличается от того программирования, которое было 30 лет назад. Очень отличается даже от того программирования, которое было 10 лет назад. И будет отличаться от того программирования, которое будет через 10 лет. Здесь революции делаются за годы, и зачастую по ряду причин здесь не взлетают гораздо более перспективные идеи.
С ДРАКОНом лучше идти, например, к юристам, бухгалтерам. Описывать алгоритмы получения какой либо справки, или алгоритмы начисления налогов, или просто правила ПДД, воинские уставы и тому подобное. И на уровне конституции прописать максимальную степень запутанности определенных законов и тому подобному. Вот здесь реально непаханное поле. То, что есть сейчас — это текстовое многословное и зачастую противоречивое представление, в котором крайне проблематично разобраться. И этот бардак не меняется не то, что десятилетиями. А столетиями, а то и вообще хуже становится. Вот здесь графическое представление вполне могло бы помочь. Возможно юристов оно и устраивает, они привыкли к этому многословию. А вот для простых граждан очень бы хотелось чего попроще, с картинками .
А именно в программировании сейчас и так все достаточно неплохо, и будет еще лучше .
Re[8]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, elmal, Вы писали:
ВП>>1. Нотация Дракона лучше, чем другие нотации для записи АЛГОРИТМОВ (именно алгоритмов, а не программ). E>Очень может быть. С поправкой — другие ГРАФИЧЕСКИЕ нотации.
Не могу согласиться с этой поправкой.
ВП>>2. Существующие нотации для записи алгоритмов (именно алгоритмов, а не программ) уступают нотации ДРАКОНа.[/b] E>Аналогично.
Не могу согласиться с этим замечанием.
ВП>>3. Исходя из этого, я делаю предположение (или, что одно и то же, выдвигаю гипотезу), что использование нотации ДРАКОНа в области программирования может дать заметные преимущества. Я отчетливо сознаю, что разработка новых технологий программирования на основе нотации ДРАКОНа — это очень большая работа, которая займет многие годы или даже десятилетия.[/b]
E>А вот тут нет. Современное программирование практически никогда не имеет дело с графическим представлением алгоритмов. Ибо это никому не нужно.
Вы правы. Сегодня не нужно. Потому что почти никто не знает, что есть альтернатива (дракон).
E>Первоначальный дизайн алгоритма чаще всего делают на бумажке на псевдокоде в текстовом виде.
Вы правы. Но это плохо.
E>Графически представлять алгоритмы требуется крайне редко. Графическое представление имеет смысл для общей архитектуры системы, это реально бывает полезно.
Вы правы. Такова практика. Но это устаревшая практика.
E>Проблема графического представления следующая. Простой алгоритм одинаково легко читается как в графическом представлении, так и в текстовом.
Вы правы. Но вся суть в сложных алгоритмах.
E>Но текстовое представление всегда более компактное.
Вы правы. Компактность важное качество. Но не самое главное. Безошибочность важнее.
E>Для текстового представления можно сделать diff, то есть видно что когда поменял ранее.
Вы правы. Это очень важно.
E>И кстати, современное текстовое представление программ де факто является еще и графическим. Ибо путем хорошего форматирования добиваются понятности, плюс современные среды разработки еще дополнительно стараются выделить важные элементы, например другим шрифтом, другим цветом и т.д, зачастую прямо в IDE делают преобразование каких то громоздких конструкций в гораздо более читаемый вид.
Вы правы. Но возможности такого способа очень ограничены.
E>То есть именно в программировании сейчас никаких революций именно в нотациях не сделать. Можно только эволюционно делать уже существующее все более и более удобным, что собственно делается и делается весьма успешно.
Не могу согласиться. Дракон является альтернативой.
ВП>>4. Но я верю, что рано или поздно найдутся энтузиасты, которые примут близко к сердцу идею ДРАКОНа, поверят в нее и дадут ей путевку в жизнь.[/b]
E>Вполне возможно. Но только не в программировании!
Не могу согласиться.
E>Современное программирование ОЧЕНЬ отличается от того программирования, которое было 30 лет назад. Очень отличается даже от того программирования, которое было 10 лет назад. И будет отличаться от того программирования, которое будет через 10 лет.
Вы правы. Согласен с Вами.
E>С ДРАКОНом лучше идти, например, к юристам, бухгалтерам. Описывать алгоритмы получения какой либо справки, или алгоритмы начисления налогов, или просто правила ПДД, воинские уставы и тому подобное.
Вы правы. Я полностью согласен с Вами.
E>И на уровне конституции прописать максимальную степень запутанности определенных законов и тому подобному. Вот здесь реально непаханное поле. То, что есть сейчас — это текстовое многословное и зачастую противоречивое представление, в котором крайне проблематично разобраться. И этот бардак не меняется не то, что десятилетиями. А столетиями, а то и вообще хуже становится. Вот здесь графическое представление вполне могло бы помочь. Возможно юристов оно и устраивает, они привыкли к этому многословию. А вот для простых граждан очень бы хотелось чего попроще, с картинками .
Вы правы. Согласен с Вами.
E>А именно в программировании сейчас и так все достаточно неплохо, и будет еще лучше .
В этом пункте с Вами согласны не все.
Цитирую:
"Третий фактор — сложившийся к настоящему времени кризис программирования, выражающийся в том числе в недостаточном уровне производительности труда программистов".
Источник:
Ильин В.П. Вычислительная математика и информатика: Мировые вызовы и Российская "Дорожная карта". // Вестник Российской академии наук, 2015, том 85, №2. — С. 107-114.
Для распространения идей языка ДРАКОН важную роль может сыграть система образования и университеты.
Сегодня в этой области дела обстоят неблагополучно.
Преподавание ведется (если ведется) лишь в единичных университетах, причем явно недостаточно.
Вот один из примеров.
Цитирую:
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ
Федеральное государственное бюджетное образовательное учреждение
высшего образования
«Кемеровский государственный университет»
Новокузнецкий институт (филиал)
федерального государственного бюджетного образовательного учреждения
высшего образования
«Кемеровский государственный университет»
Факультет информационных технологий
Кафедра Математики и математического моделирования
УТВЕРЖДАЮ
Декан ____ В.О. Каледин
"11" марта 2016 г.
Рабочая программа дисциплины
Б1.В.ДВ.8.2 Инструментальные средства визуального программирования
Направление подготовки
01.04.02 Прикладная математика и информатика
Направленность (профиль) подготовки
«Математическое моделирование»
Программа академической магистратуры
Квалификация выпускника
Магистр
Форма обучения
Очная
Новокузнецк 2016
Стр. 5
2.
Визуальное программирование в ИС ДРАКОН
Язык ДРАКОН и его визуальный синтаксис. Дракон-схемы и их преимущества.
Визуализация циклических алгоритмов. Визуализация
логических формул.
Интегрированная среда ДРАКОН.
Примеры алгоритмов для различных отраслей знаний.
Алгоритмы и формализация профессиональных знаний.
ОПК-1
уметь:
генерировать и продвигать новые идеи применения инструментальных средств ДРАКОН
владеть:
опытом участия в научных и научно-практических конференциях, посвященных современным инструментальным средствам визуального программирования
П-11
знать:
историю развития информационных технологий – предпосылки появления языка ДРАКОН
уметь
использовать современные средства языка ДРАКОН для решения научно-исследовательских и прикладных задач
извлекать полезную научно-техническую информацию из электронных библиотек, реферативных журналов, сети Интернет и т.д. про инструментальные средства ДРАКОН
владеть языком Дракон-схем и их методологией
Здравствуйте, Владимир Паронджанов, Вы писали:
E>>А вот тут нет. Современное программирование практически никогда не имеет дело с графическим представлением алгоритмов. Ибо это никому не нужно. ВП>Вы правы. Сегодня не нужно. Потому что почти никто не знает, что есть альтернатива (дракон).
Иногда "не нужно" это именно "не нужно", а не что-то другое.
E>>Первоначальный дизайн алгоритма чаще всего делают на бумажке на псевдокоде в текстовом виде. ВП>Вы правы. Но это плохо.
Лучше сразу делать его в ИДЕ и запускать на исполнение.
E>>Проблема графического представления следующая. Простой алгоритм одинаково легко читается как в графическом представлении, так и в текстовом. ВП>Вы правы. Но вся суть в сложных алгоритмах.
Тут графическое представление никак не поможет.
Особенно если алгоритм не просто сложный, а ещё и оптимизированный.
ВП>Вы правы. Компактность важное качество. Но не самое главное. Безошибочность важнее.
Безошибочность достигается другими средствами.
Например, вот такими: Dafny доказательство сортировки выбором.
E>>И кстати, современное текстовое представление программ де факто является еще и графическим. Ибо путем хорошего форматирования добиваются понятности, плюс современные среды разработки еще дополнительно стараются выделить важные элементы, например другим шрифтом, другим цветом и т.д, зачастую прямо в IDE делают преобразование каких то громоздких конструкций в гораздо более читаемый вид. ВП>Вы правы. Но возможности такого способа очень ограничены.
Они более чем достаточны.
E>>А именно в программировании сейчас и так все достаточно неплохо, и будет еще лучше .
ВП>В этом пункте с Вами согласны не все. ВП>Цитирую:
ВП>"Третий фактор — сложившийся к настоящему времени кризис программирования, выражающийся в том числе в недостаточном уровне производительности труда программистов".
Только дракон не является решением.
Для того чтобы поднять производительность программистов нужно уменьшить количество сущностей в программе. В идеале там должны быть только сущности предметной области.
Например, вот этот код:
1)Разбирает текстовое представление арифметических выражений.
2)Вычисляет значение выражения.
3)Генерирует качественные сообщения об ошибках.
4)Может быть встроен в текстовый редактор, в котором будет обеспечена подсветка кода и ошибок в реальном времени.
syntax expr
{
Value() : double;
missing Value = double.NaN;
| [SpanClass(Number)]
num = number { override Value = Number.Value(); }
| rounds = '(' expr ')' { override Value = Expr.Value(); }
precedence Additive:
| add = expr sm '+' sm expr { override Value = Expr1.Value() + Expr2.Value(); }
| sub = expr sm '-' sm expr { override Value = Expr1.Value() - Expr2.Value(); }
precedence Multiplicative:
| mul = expr sm '*' sm expr { override Value = Expr1.Value() * Expr2.Value(); }
| div = expr sm '/' sm expr { override Value = Expr1.Value() / Expr2.Value(); }
| mod = expr sm '%' sm expr { override Value = Expr1.Value() % Expr2.Value(); }
precedence Power:
| pow = expr sm '^' sm expr right-associative
{ override Value = System.Math.Pow(Expr1.Value(), Expr2.Value()); }
precedence Unary:
| neg = '-' expr { override Value = -Expr.Value(); }
}
Внимательный читатель может заметить, что тут нет не то что автомата, а даже порядка вычислений.
Как тут поможет дракон, который может только автоматы описывать?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[9]: Язык ДРАКОН — новая идея в программировании
ВП>"Третий фактор — сложившийся к настоящему времени кризис программирования, выражающийся в том числе в недостаточном уровне производительности труда программистов".
ВП>Источник: ВП>Ильин В.П. Вычислительная математика и информатика: Мировые вызовы и Российская "Дорожная карта". // Вестник Российской академии наук, 2015, том 85, №2. — С. 107-114.
Эта мысль посетила не только Ильина. Схожие мысли высказывались уже давно и высказываются до сих пор.
Фредерик Брукс ещё в 1986 году написал статью "Серебряной пули нет", в которой утверждал "ни в одной технологии или в управленческой технике не существует универсального метода, увеличивающего на порядок производительность, надёжность и простоту". В, переизданной в 90-х своей книге "Мифический человеко-месяц" Брукс писал, что несмотря на то, что индустрия сильно развилась со времён первого издания книги, серебряной пули всё ещё нет. И как мы видим — этой пули нет до сих пор. И Дракон тоже не является "серебряной пулей".
