Представлен DRAKON Editor 1.4 (http://sourceforge.net/projects/drakon-editor/), свободный кросс-платформенный редактор диаграмм для визуального языка ДРАКОН (http://ru.wikipedia.org/wiki/%D0%94%D0%A... разработанного в рамках космической программы «Буран» и оперирующего созданием наглядных блок-схем. ДРАКОН позволяет переложить работу по созданию технологичных программ на плечи инженеров, которые не обладая должными навыками программирования, досконально владеют материалом и прекрасно разбираются в сущности процессов в прикладной области для которой создаётся программа. Код DRAKON Editor распространяется как общественное достояние (Public Domain), поддерживается работа в Linux, Mac OS X и Windows.<center><img src="http://www.opennet.dev/opennews/pics_base/32208_1320306876.jpeg " style="border-style: solid; border-color: #e9ead6; border-width: 15px;" title="" border=0></center>
URL: http://sourceforge.net/projects/drakon-editor/
Новость: http://www.opennet.dev/opennews/art.shtml?num=32208
IEC61131
Один из языков 1131.
для школ тоже, наверное, полезно
Плохо что оно на tk написано :(
Чем плохо? Зато, поди, просто в разработке (следовательно, меньше багов), и портируется, наверно, хорошо
Тем что он не развивается ;) А для простоты разработки и портирования существует много современных технологий.
Зато нет проблем с поддержкой кода как на питоне - это преимущество Tk.
Подскажите пожалуйста, как запустить?
да, упростило бы распространение проекта, если создать простую html страницу проекта с указаниями скачать ActiveTcl например.
Посоветуйте, что ли компилятор .drn в С/C++?
Может эту технологию можно прикрутить к Freemind?
1. Нужно поставить tcl
http://www.activestate.com/activetcl/downloads
2. В Windows: двойной клик на drakon_editor.tcl
В Линуксе и Макоси: tclsh8.5 drakon_editor.tcl
Вот чему надо учить в школе!
> ДРАКОН позволяет переложить работу по созданию технологичных программ на плечи инженеров, которые не обладая должными навыками программированияВот тут-то и наступит крантец проектам.
да уж. не могу смотреть уже на "программистов" да "программ" на лабвью и агилент без ненависти. вот возьмите кусок такой программы чуть посложнее да оберните в цикл или в условие - полдня надо растаскивать их по экрану чтобы втиснуть пару других пиктограмм. при том что в тексте это делается парой нажатий клавиш. понять синхронизацию и взаимосвязь разных кусков программы так это вообще нечто такое что перл кажется вершиной человеческой мысли.
> да уж. не могу смотреть уже на "программистов" да "программ" на лабвью
> и агилент без ненависти. вот возьмите кусок такой программы чуть посложнее
> да оберните в цикл или в условие - полдня надо растаскивать
> их по экрану чтобы втиснуть пару других пиктограмм. при том что
> в тексте это делается парой нажатий клавиш. понять синхронизацию и взаимосвязь
> разных кусков программы так это вообще нечто такое что перл кажется
> вершиной человеческой мысли.т.е. проблема только в растаскивании? понимать сложные схемы все равно легко?
> понимать сложные схемы все равно легко?Нет, с точностью до наоборот. Кто-то говорил что подобные системы "делают простые вещи еще проще, а сложные еще более сложными". Вся простота на самом деле кажущаяся. Кучка независимых тредов с неочевидными семафорами и вызовами к друг другу - вот что это такое на самом деле. В качестве аналога радиоэлектронной схемы это может и подходит, но в качестве среды программирования - увольте. Невозможно понять в каком состоянии находится программа в произвольный момент времени поэтому от визуального программиста требуется более высокий уровень квалификации чтобы реализовать тот же самый алгоритм что и в обычных языках.
Если инструмент используется не к месту, бездарем, плохо изучившим инструмент, просто не подходит человеку в силу психологических или эмоциональных причин, в силу привычки, в конце концов, то чем виноват инструмент?Почему Вы не можете понять в каком состоянии находится программа? Это ведь Ваша проблема? Может просто, как, Вы говорите, для "визуального программиста требуется более высокий уровень квалификации" и у Вас его просто нет?
Отрицать визуальные средства представления в программировании это тоже самое, что говорить об отсутствии необходимости в трехмерном или твердотельном моделировании т.к. это все гораздо труднее, чем просто набросать эскиз изделия. Это другой взгляд на программу. Что-то, возможно, будет скрыто, но что-то другое - будет более простым и понятным. Никто не запрещает использовать разные инструменты совместно, особенно в сложных проектах (Особенно, если учесть, что "драконовcкие" схема это всего лишь одна из графических схем. Так же как в электронике есть структурные, принципиальная, функциональные, монтажные, блочно-корпусные и т.д. (там за десяток переваливает) схемы. В разных ситуациях удобно использовать разные.)
"Неочевидные семафоры" останутся неочевидными везде. И, если программная система проектируется на коленке, то "пол дня растаскивать на экране" придется даже в vim. Когда-то на OpenNet была ссылка на схему ядра Windows, Linux и какой-то *BSD. Там одного взгляда взгляда достаточно, чтоб понять где быстрее рванет.
Трёхмерное моделирование для трёхмерного объекта — вещь вполне естественная. Но визуальное представление программы — это вовсе не представление программы в её "естественном" виде.Чем плохо такое представление? Самый очевидный момент — оно более громоздкое, то есть программист будет видеть меньшую часть программы, а проще понимать код когда всё нужное перед глазами, когда не нужно прокручивать экран чтобы уточнить тот или иной момент. Ну и мне кажется, что писать код всё-таки быстрее, чем соединять блоки стрелочками.
> Чем плохо такое представление?Проблема кроется в другом, и почему-то в обсуждениях её никто не может увидеть: просто графические языки по натуре своей декларативные, потому и не ложатся они на императивные алгоритмы.
Ибо, значит, инженеров к программированию допускать можно, а вот пусть кто-нибудь попробует программистов к инженерии допустить?
class программист: public инженер
Да уж. Инженеру ошибка в проекте обойдётся очень дорого - перепроектировать и перестраивать здание, отзывать партию автомобилей, а то и ликвидировать взрыва на АЭС. А программист не боится ошибаться - "напишите мне багрепорт в тикет-систему, в следующем релизе всё будет исправлено".
Кто в состоянии сложный алгоритм на блок-схемы расписать, тому выучить какой-нибудь язык программирования нетрудно. Не надо умножать сущности...
таак
скоро можно будет просто сказать компьютеру что нужно и он сам все сделает
)) (((
Боюсь, что в этом случае компьютеру будет проще сделать нормального говорящего ;)
редактор хороший... идеи неплохие заложены . А вот с реализацией ... на TCL/TK погорячились конечно ...Я бы рекомендовал для переносимости на node js/ javascript переписать ... в крайнем случае на java. Совместимость нужна с телефонами и планшетами...