Пытаюсь не ерничать, но вы не могли бы рассказать, что нового по сравнению с этими, уже очень широко используемыми языками вы привносите? Сейчас каждый уважающий себя производитель микроконтроллеров почти полный комплект инструментов для этих языков предоставляет. Более того, многие промышленные контроллеры сейчас уже не программируются в машинных кодах, ассемблере или на C — а только при помощи перечисленных языков, ну или еще при помощи IL или ST.
Вам надо искать инвестиции, в Сколково податься, что ли. Можно попытаться сделать универсальный инструмент, который поддерживает как МК с IL/ST, так и те, которые программируются на своем ассемблере или на C. Другой вариант — взять свою команду и пойти в Сименс или еще куда, может они заинтересуются вашими наработками.
Здравствуйте, minorlogic, Вы писали:
M>«Если вы не можете своему ребенку за пять минут объяснить, чем вы занимаетесь, значит, вы занимаетесь какой-то ерундой».
Только что хотел сам написать, но решил глянуть ветку дальше
Здравствуйте, Mazay, Вы писали:
M>Запостите лучше сюда алгоритм балансировки AVL-дерева, пожалуйста. А то все эти "Обед в ресторане" и "Покрасить забор" как-то не тянут на типичные задачи.
Думаю, что запрошеный алгоритм неудобно будет рассматривать, придется прокручивать много вверх-вниз и вправо-влево.
Дракон этот, как я понял, типичный высокоуровневый инструмент промышленной автоматизации, которым пользуется инженер, знакомый с предметной областью, и умеющий рисовать блок-схемы. Низкоуровневые кирпичики либо уже забиты в контроллере, либо этот инженер идет в отдел к программистам, и говорит, что он хочет чтобы они этот кирпичик запрограмили ему на Cях, чтобы он этот кирпичик мог вставлять в свои блок-схемы.
Здравствуйте, Marty, Вы писали:
WH>>Если задача не сводится к конечному автомату, то дракон работать перестает. M>А какая задача не сводится к конечному автомату? Если дополнить его стеком состояний? У меня в генераторе (см выше) как раз в парсере IDL был случай, когда нужна была рекурсия. классический автомат не мог это обработать, я просто добавил генерацию стека состояний в генератор и ввел способ вызова подавтоматов с сохранением состояния на стеке, и все заработало. В местах, где не было рекурсии, я просто делал подстановку подавтомата в объемлющий автомат.
Меня полнота по Тьюрингу не волнует.
Совсем.
Просто пойми одну простую вещь: Решения задачи в терминах предметной области, которая не имеет ничего общего с КА будет раз в 100 меньше чем то, что ты напишешь на этих своих КА со стеком состояний.
Ссылку на пример я дал в том сообщении, на которое ты отвечал.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[4]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, Mazay, Вы писали:
M>Да? И как же выделенное облегчает "алгоритмизацию"? Повторенье мать ученья? M>
Кстати, даже этот детский пример — неправильный.
К примеру, не обрабатывается ситуация "кончились черви" или "жена позвонила и сказала бежать домой". Причём если их добавлять, то схема (и так уже сложная) перестанет быть понимаемой.
Да, и ещё непонятно как легко откомментировать кусочек схемы. Оверквотинг сплошной получается.
Sapienti sat!
Re[4]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, WolfHound, Вы писали:
WH>Просто пойми одну простую вещь: Решения задачи в терминах предметной области, которая не имеет ничего общего с КА будет раз в 100 меньше чем то, что ты напишешь на этих своих КА со стеком состояний.
WH>Ссылку на пример я дал в том сообщении, на которое ты отвечал.
Ок, глянул, и, думаю, понял. Я сам вообще любитель писать DSL, есть грешок, бывает и не совсем к месту в плане трудозатрат на разработку DSL и выгод от его использования. Когда ясно, что надо одну шестую часть суши перепахать при помощи предполагаемого DSL — тут вопросов нет, а когда это на текущий момент три дачных огорода, правда в планах работодателя прикупить еще то ли 10, то ли 1000 тыщ гектар, тут сложно решить, как быть.
Ну а свой КА со стеком состояний я как раз и использовал для написания IDL, то есть некоторым образом DSL. Из того IDL генерились интерфейсы для С/C++, что было приятно для межмодульного взаимодйствия — приятно было то, что можно было использовать только то, что поддерживает IDL, который сам по себе, если его знать, как и во что он преобразует, является документацией. Можно было написать coding std, потратив наверно еще и больше времени, и получив бумагу, которая ничего не гарантирует.
Ну а КА также хороши как для создания DSL, так и для создания программ на этом DSL. Был бы хороший расширяемый инструмент, а новый бэкэнд всегда можно присунуть.
Здравствуйте, Cyberax, Вы писали:
C>К примеру, не обрабатывается ситуация "кончились черви" или "жена позвонила и сказала бежать домой". Причём если их добавлять, то схема (и так уже сложная) перестанет быть понимаемой.
C>Да, и ещё непонятно как легко откомментировать кусочек схемы. Оверквотинг сплошной получается.
State-машина гораздо приятнее в этом плане. Надо просто для нового типа события "позвонила жена" или "кончились черви" обойти состояния, и решить в каждом случае, как реагировать. Можно проигнорировать (по дефолту) или добавить новые состояния и/или новые дуги на графе переходов. Топик-стартер отстал от жизни лет на 10, видимо он так плотно занимался Драконом, что некогда было по сторонам смотреть. Такое бывает, в этом нет ничего странного или зазорного. Сам с таким
возился (и таки лелею мечту продолжить — скрестить C,C++,D и динамические языки типа Питона и Lua через пачку интерфесов). Я пока правда отложил это занятие — за паровозами индустрии тяжело успевать, подустал лабать, решил отдышаться и посмотреть, куда дальше двигаться.
Ну я отвлекся. ТС'у надо по сторонам оглядеться, я уже пару раз тут писал, что следовало бы посмотреть. Человек не побоялся озвучить свои мысли — это плюс. Человек сильно отстал от жизни — это минус. Хочу пожелать ему удачи, и надеюсь, что в следующий раз он выйдет более подготовленным.
Здравствуйте, Marty, Вы писали:
C>>К примеру, не обрабатывается ситуация "кончились черви" или "жена позвонила и сказала бежать домой". Причём если их добавлять, то схема (и так уже сложная) перестанет быть понимаемой. C>>Да, и ещё непонятно как легко откомментировать кусочек схемы. Оверквотинг сплошной получается. M>State-машина гораздо приятнее в этом плане. Надо просто для нового типа события "позвонила жена" или "кончились черви" обойти состояния, и решить в каждом случае, как реагировать. Можно проигнорировать (по дефолту) или добавить новые состояния и/или новые дуги на графе переходов.
Получится уйма переходов — жена может позвонить на каждом шаге. Нужно вводить что-то типа исключений, которые графически не особо красиво рисуются.
Для state-машины графическое представление может быть удобно. А может быть и неудобно — я сейчас как раз пишу планировщик задач, где state-машин полно. Но мне их удобнее описывать кодом (в виде набора узлов и переходов), а потом генерировать по ним graphviz'овский .dot-файл для документации (собственно, я так и нарисовал "эргономичный quicksort").
Ну и в любом случае, state-машины — это крайне нишевая область. По крайней мере из-за того, что в них нельзя описать структуру данных — у чистой state-машины вообще данных нет (кроме состояния). Как графически описать связный список или хэш-карту — очень интересный вопрос.
Sapienti sat!
Re[5]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, Cyberax, Вы писали:
C>>>Да, и ещё непонятно как легко откомментировать кусочек схемы. Оверквотинг сплошной получается. M>>State-машина гораздо приятнее в этом плане. Надо просто для нового типа события "позвонила жена" или "кончились черви" обойти состояния, и решить в каждом случае, как реагировать. Можно проигнорировать (по дефолту) или добавить новые состояния и/или новые дуги на графе переходов. C>Получится уйма переходов — жена может позвонить на каждом шаге. Нужно вводить что-то типа исключений, которые графически не особо красиво рисуются.
Так дефолтный переход по необрабатываемым событиям — "Послать нах" А где жену можно обработать — так обрабатывем явно
C>Для state-машины графическое представление может быть удобно. А может быть и неудобно — я сейчас как раз пишу планировщик задач, где state-машин полно. Но мне их удобнее описывать кодом (в виде набора узлов и переходов), а потом генерировать по ним graphviz'овский .dot-файл для документации (собственно, я так и нарисовал "эргономичный quicksort").
Тут да, согласен. Нужен удобный язык для state-машин, как текстовый, так и графический, и желательна возможность редактирования как текста, так и графики, со сведением в один текстовый и читабельный исходник.
C>Ну и в любом случае, state-машины — это крайне нишевая область. По крайней мере из-за того, что в них нельзя описать структуру данных — у чистой state-машины вообще данных нет (кроме состояния). Как графически описать связный список или хэш-карту — очень интересный вопрос.
Ну, структуры могут быть либо частью состояния машины, либо параметрами event'а для state-машины. А вообще, конечно, всю программу целиком нельзя или очень сложно описать стейт-машиной, но реакция машины на события обычно не тривиальная, и подразумевает вызов метода обработчика, который может и со структурами работать.
Связанный список или хэш-мэп — это проблемы пользователя state-машины, который должен переопределить метод save_to_hash_map или save_to list, или более обще — save_to_storage, если такой заявлен в машине.
Автоматное программирование и концепция state-machine, и их развитие мне стало интересно после того, как мне удалось сделать при помощи автоматов вполне функциональный http-сервер, с которым работали ie, chrome, opera и firefox для веб-настройки девайса на x86, где под программу и данные было около 100Кб, и большую часть занимал код 10ти или 15ти страничек, которые надо было выводить, а также код, обрабатывающий запросы. Не то чтобы я хвалюсь, но это был вин, ну по крайней мере для меня
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Marty, Вы писали:
C>>>К примеру, не обрабатывается ситуация "кончились черви" или "жена позвонила и сказала бежать домой". Причём если их добавлять, то схема (и так уже сложная) перестанет быть понимаемой. C>>>Да, и ещё непонятно как легко откомментировать кусочек схемы. Оверквотинг сплошной получается. M>>State-машина гораздо приятнее в этом плане. Надо просто для нового типа события "позвонила жена" или "кончились черви" обойти состояния, и решить в каждом случае, как реагировать. Можно проигнорировать (по дефолту) или добавить новые состояния и/или новые дуги на графе переходов. C>Получится уйма переходов — жена может позвонить на каждом шаге. Нужно вводить что-то типа исключений, которые графически не особо красиво рисуются.
Если новые состояния переключаются event`ом будет только одна точка входа wait_events -> process.
Прерывания, насколько знаю, тоже можно в одной функции обрабатывать и иметь одну точку входа обработчик.
C>Для state-машины графическое представление может быть удобно. А может быть и неудобно — я сейчас как раз пишу планировщик задач, где state-машин полно. Но мне их удобнее описывать кодом (в виде набора узлов и переходов), а потом генерировать по ним graphviz'овский .dot-файл для документации (собственно, я так и нарисовал "эргономичный quicksort").
Диаграмма нагляднее отображает что происходит, даже в случае очень высокоуровневых шаблонов.
C>Ну и в любом случае, state-машины — это крайне нишевая область. По крайней мере из-за того, что в них нельзя описать структуру данных — у чистой state-машины вообще данных нет (кроме состояния). Как графически описать связный список или хэш-карту — очень интересный вопрос.
Вот не надо, установить tcp соединение это уже стейт-машина примитивная.
Re[9]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, LaptevVV, Вы писали:
LVV>Вы давно преподавали в вузе, чтобы так БЕЗАПЕЛЛЯЦИОНННО судить о качестве преподавательских технологий?
Я слава господу не преподавал. Я просто периодически наблюдаю разницу в людях вышедших из ВУЗ-ов, т.е. получивших образование определенного качества. И вывод очень прост — те люди которые получали классическое математическое или CS-образование имеют гораздо более высокий уровень компетентности и адекватности. LVV>Знает тот, кто делает (с)
Кто умеет, делает; кто не умеет, учит других. (с)
LVV>Значит, так учили. Или сам учился.
Система учила и получился возможно умный но не образованный человек. А мог бы быть образованным.
LVV>UML вначале тоже только три человека делали.
UML прошел полный путь от идеи до международного признания и стандартизации за 10 лет. А известность получил через 5 лет после старта. А сколько вы говорите дракон жив? 20-30 лет?
Re[10]: Язык ДРАКОН — новая идея в программировании
Предлагаю вашему вниманию Заключение по книге 2012 года.
АЛГОРИТМЫ ДОЛЖНЫ БЫТЬ ПОНЯТНЫМИ
(вместо заключения)
ЗАЧЕМ НАПИСАНА ЭТА КНИГА?
В этой книге мы попытались:
• провести четкую грань между алгоритмизацией и программированием;
• сосредоточить внимание на алгоритмах, оставив программирование за рамками книги;
• изложить основы алгоритмизации;
• создать средства, обеспечивающие максимально возможную понятность алгоритмов. И за счет этого сделать алгоритмы доступными для «народа».
КРИТИКА ТРАДИЦИОННЫХ ПОДХОДОВ
Прежние способы записи алгоритмов устарели. Они слишком трудны для понимания и требуют неоправданно больших трудозатрат.
Древние, но живучие привычки ставят непреодолимый барьер для большинства людей, которые хотят научиться выражать свои знания, мысли и планы в форме алгоритмов.
Традиционные формы представления алгоритмов отжили свой век и должны сойти со сцены. Именно они несут ответственность за господствующую на нашей планете алгоритмическую неграмотность.
КАКИЕ РЕЗУЛЬТАТЫ ПОЛУЧЕНЫ?
• Предложен новый способ записи алгоритмов – дракон-схемы.
• Благодаря этому новшеству алгоритмы становятся значительно более понятными, общедоступными, кристально ясными.
• Использование дракон-схем позволяет повысить производительность труда при разработке, анализе и проверке алгоритмов (возможно, в несколько раз).
• Дракон-схемы облегчают и ускоряют обучение алгоритмизации.
• Новый способ записи дает возможность коренным образом изменить систему образования в области алгоритмизации. И познакомить с алгоритмами более широкие слои населения;
Можно предположить, что внедрение дракон-схем в массовую практику поможет обеспечить ликвидацию алгоритмической неграмотности.
ПОНЯТНОСТЬ АЛГОРИТМОВ
При разработке языков для записи алгоритмов (алгоритмических языков) обычно выдвигается ряд требований. К сожалению, среди них, как правило, отсутствует самое важное для человека:
«Алгоритмы, записываемые на алгоритмическом языке, должны быть понятны для человеческого зрительного восприятия и удобны для человеческого мышления».
Слово «понятны» следует пояснить. Нужны не просто понятные, а в высшей степени понятные алгоритмы. Это значит, что должен выполняться принцип: «Взглянул – и сразу понял!», «Посмотрел – и мигом во всем разобрался!».
С учетом этих пояснений вводится термин «критерий сверхвысокой понятности».
Отличие языка ДРАКОН состоит в том, что язык должен удовлетворять данному критерию. Это значит, что требование понятности алгоритмов рассматривается как главное, приоритетное, наиболее важное требование к языку.
Чтобы выполнить указанное требование, одной математики мало. Наряду с математикой, необходимо использовать когнитивную эргономику.
КОГНИТИВНАЯ ЭРГОНОМИКА
Язык ДРАКОН имеет две опоры. Первая – математика. Вторая – психология, точнее, когнитивная эргономика. Именно эргономика позволяет сделать дракон-схемы изящными и доступными. При создании ДРАКОНа был использован научный подход к эргономизации конструкций языка.
Такой подход позволил улучшить визуальные образы языка (визуальные формы фиксации знаний), согласовав их с тонкими характеристиками глаза и мозга. Тонкими, но хорошо известными в когнитивной эргономике, психофизиологии, нейробиологии.
Когнитивная эргономика позволила преобразовать неудобные и устаревшие блок-схемы в элегантные очертания приятных и доходчивых дракон-схем.
С появлением дракон-схем разработка алгоритмов существенно облегчается.
ДРАКОН – качественно новый этап работы с алгоритмами.
СТАНЕТ ЛИ ДРАКОН ЧЕМПИОНОМ МИРА
ПО КРИТЕРИЮ «ПОНЯТНОСТЬ АЛГОРИТМОВ»?
Претензия ДРАКОНа на «мировое господство» ограничена. Он вступает в конкурентную борьбу только с императивными и процедурными языками (точнее, с императивно-процедурными частями языков). И только в том случае, когда понятность алгоритмов является главным требованием к языку. Тем, кто желает писать непонятные или трудные для понимания алгоритмы, ДРАКОН не нужен.
Требование удобопонятности алгоритмов все чаще выходит на передний план. Поэтому шансы ДРАКОНа на победу в конкурентной борьбе с другими языками растут.
ДРАКОН-КОНСТРУКТОР
Дракон-конструктор – верный слуга алгоритмиста. Эта компьютерная программа способна оказать человеку огромную помощь при создании алгоритмов.
Внутри программы спрятана сложная математика (исчисление икон и др.), но прелесть в том, что пользователю знать эту математику не нужно. Чтобы обеспечить максимальные удобства для человека, большинство функций по созданию алгоритмов (кроме творческих операций) берет на себя дракон-конструктор.
Кроме того, дракон-конструктор осуществляет автоматическое доказательство правильности дракон-схем, гарантируя принципиальную невозможность ошибок визуального синтаксиса.
Безошибочное проектирование графики дракон-схем – важное преимущество, повышающее производительность труда при практической работе.
Здравствуйте, a_g_99, Вы писали:
LVV>>Знает тот, кто делает (с) __>Кто умеет, делает; кто не умеет, учит других. (с)
Вот именно!
Учить вы не умеете, а беретесь судить о преподавании.
А писать программы в 60 лет вы умеете? LVV>>Значит, так учили. Или сам учился. __>Система учила и получился возможно умный но не образованный человек. А мог бы быть образованным.
У нас таких нет. Наши — все умеют и образованные. LVV>>UML вначале тоже только три человека делали. __>UML прошел полный путь от идеи до международного признания и стандартизации за 10 лет. А известность получил через 5 лет после старта. А сколько вы говорите дракон жив? 20-30 лет?
Проектирование Бурана — секретность была большая.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[11]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, LaptevVV, Вы писали:
LVV>Учить вы не умеете, а беретесь судить о преподавании.
Вы абсолютно правы учить я не умею, тут каждому свое. Но я сталкиваюсь с современным продуктом образования и могу судить о его качестве, а следовательно о качестве преподавания этого образования. И когда преподающий мне, как человеку из индустрии, для которой готовится этот продукт (специалист), сообщает что рисование это хорошо, это приоритет, мне становится смешно. Специалист должен понимать суть мат. аппарата и основные cs-алгоритмы, он должен выражать их куцым математическим языком формул и алгоритмов. А блок-схемы и подобные рисуночки пусть чертят на кафедре художников.
Меня кстати поражает тот факт, как в своем подавляющем большинстве (не касается нескольких вузов и пары мат. институтов) российская система образования упорно пытается превратить студента в идиота. Креативный подход. LVV>А писать программы в 60 лет вы умеете?
Мне не 60 лет, но писать программы я умею. Надеюсь, что хорошо. Уверен когда мне будет 60 я буду делать это еще лучше.
LVV>У нас таких нет. Наши — все умеют и образованные.
Чьи это ваши? Прямо интересно стало
LVV>Проектирование Бурана — секретность была большая.
Ну да. Кровавая гэбня зарубила такой язычище. Просто плакать от смеха хочется
Re[12]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, a_g_99, Вы писали:
__>Здравствуйте, LaptevVV, Вы писали:
LVV>>Учить вы не умеете, а беретесь судить о преподавании. __>Вы абсолютно правы учить я не умею, тут каждому свое. Но я сталкиваюсь с современным продуктом образования и могу судить о его качестве, а следовательно о качестве преподавания этого образования. И когда преподающий мне, как человеку из индустрии, для которой готовится этот продукт (специалист), сообщает что рисование это хорошо, это приоритет, мне становится смешно. Специалист должен понимать суть мат. аппарата и основные cs-алгоритмы, он должен выражать их куцым математическим языком формул и алгоритмов. А блок-схемы и подобные рисуночки пусть чертят на кафедре художников.
1. Насчет приоритета — вы передергиваете.
2. Рисование — это и SADT, и UML, и DFD и Дракон и многое еще другое...
И это составляет ЧАСТЬ профессиональных знаний разработчика.
Так же как теория графов — тоже ЧАСТЬ тех же самых знаний. __>Меня кстати поражает тот факт, как в своем подавляющем большинстве (не касается нескольких вузов и пары мат. институтов) российская система образования упорно пытается превратить студента в идиота. Креативный подход.
Система может и пытается, а мы, наоборот, стараемся из идитота сделать специалиста... LVV>>А писать программы в 60 лет вы умеете? __>Мне не 60 лет, но писать программы я умею. Надеюсь, что хорошо. Уверен когда мне будет 60 я буду делать это еще лучше.
Если только вам не надоест и вы не уйдете в управленцы... LVV>>У нас таких нет. Наши — все умеют и образованные. __>Чьи это ваши? Прямо интересно стало
Наши выпускники — нашей каферы. LVV>>Проектирование Бурана — секретность была большая. __>Ну да. Кровавая гэбня зарубила такой язычище. Просто плакать от смеха хочется
Попалчьте — это иногда бывает сильно полезно...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Почему многие сразу принимаются за критику, толком не разобравшись?
Причина банальна — любая новая технология угрожает уже имеющимся специалистам, ведь им как минимум, надо понять что она из себя представляет, оценить насколько она может конкурировать с их собственной, какие задачи на ней возможно решаются лучше, и в конечном итоге — может быть даже заняться ее изучением.
Но это нерационально с точки зрения эгоизма, поэтому лучше сразу назвать технологию говном, а тех кто ее продвигают — недоучками.
Не знаю ничего насчет именно языка ДРАКОН, слышал где-то, подумал что это что-то детское, но мне в глаза сразу бросилось одно обстоятельство. То что этот (или похожий) язык будет очень хорош для планшетов. А в дальнейшем я думаю появятся еще более революционные интерфейсы чем сенсорные пальце-ориентированные.
В конечном итоге, возможно что управление компьютером лет через 20 будет выглядеть как комбинированное использование жестов руками в воздухе, движения глаз и губ, мимики лица, и голосовых команд. При этом будет достигнута очень важная цель — скорость взаимодействия между мозгом и компьютером возрастет на порядок и возможно, любая идея, только зародившаяся в голове, сможет обретать свое представление в формальных схемах. Конечно эти схемы будут графическими, и похожими на карты разума.
Таково мое видение будущего.
Так что я думаю, что язык ДРАКОН безусловно имеет будущее, но он в этом не одинок.
On 23/05/12 23:31, Владимир Паронджанов wrote:
> Существующие способы записи алгоритмов и программ (принятые во всем мире) слишком трудны для понимания и требуют неоправданно больших трудозатрат.
Мне все таки кажется, что будущее — за дешкомпьютерами
