Здравствуйте, dotidot, Вы писали:

D>Здравствуйте, jangle, Вы писали:

J>>Язык программирования Microsoft Visual Programming Language (VPL) — это средство разработки приложений, в котором используется модель
D>а вот интересно. я таких штук много видел, но везде либо примитивный flow данных с переключателями(симулинк в матлабе), либо примитивный процедурный подход на уровне фортрана, ну еще дизайнеры sql запросов видел, но это уже скорее схема, чем ЯП. Как создавать софт такими примитивными средствами? Почему не видно реализаций более абстрактных и высокоуровневых категорий, чем процедуры и функций?

Я, к сожалению, не имею возможности проверить на практике, что такое VPL от MS, но думаю это не плохая штука и хотел бы напомнить знатокам о том, что в родном отечестве некогда развивалось такое направление и не просто развивалось, а активно применялось с большим успехом (да и сейчас применяется).
Делалось это усилиями коллектика центра автоматики и приборостроения им. академика Н. Пилюгина и ИПМ им. Келдыша. В те годы шла активная разработка МКС "Буран" и по инициаливе Юрия Трунова совместно в ИПМ были созданы три языка ПРОЛ2, ДИПОЛЬ и ЛАКС (руководители проектов: Виктор Крюков, Владимир Луцикович и Константин Федоров соотв.). Каждый язык использовался для своих задач и с другими не пересекался: ПРОЛ2 — для разработки бортовых комплексных программ Бурана , ДИПОЛЬ — для создания наземных программ Бурана и ЛАКС — для моделирования. Языки и инструменты были созданы, но возникли сложности с организацикй взаимодействия специалистов-прикладников и программистов. Когда эта проблема была осознана, Трунов выступил с идеей создания нового инструмена, который бы в песпективе заменил три существующие. Такая задача была поставлена перед Владимиров Параджановым, руководителем комплексной группы центра автоматики и приборостроения им. академика Н. Пилюгина. Но Параджанов несколько пересмотрел условия задачи, т.к. понимал, что еще один новый язык проблемы не решит. Нужен был принципиально иной подход, который позволил бы совсем-не-программистам и совсем-уже-программистам разговаривать на одном языке, т.е. думать и решать задачи в схожих понятиях. По сути замахнулись на святое, на способ мышления, на то, что бы улучшить/изменить работу ума. И как ни странно это звучит, задача была решена. Был создан язык ДРАКОН, графический язык. Цель и задачи этого языка были:
1. Предложить эффективные средства для описания структуры человеческой деятельности.
2. Предоставить человеку такие языковые средства, которые резко упро щают восприятие сложных процедурных проблем и общение с кол легами, делают непонятное понятным и за счет этого буквально заставляют человека мыслить отчетливо, глубоко и продуктивно. В этих условиях вероятность заблуждений, просчетов и ошибок неизбежно падает, а производительность растет.
3. Радикально облегчить межотраслевое и междисциплинарное общение между представителями разных организаций, ведомств, отделов, лабораторий, научных школ и профессий.
4. Устранить или уменьшить барьеры взаимного непонимания между работниками различных специальностей (врачами и физиками, математиками и конструкторами, биологами и экономистами и т. д.), а также программистами и теми, у кого аллергия к любому программированию.
5. Добиться кардинального улучшения качества программного обеспечения по критерию «понимаемость алгоритмов и программ».

ДРАКОН начал частично применяться в программе МКС "Буран". И имел успех, но поскольку проект уже близился к заверщению ДРАКОН не являлся основным языком и использовался в основном "на бумаге", т.е. как язык описания алгоритмов во время общения специалистов между собой. Но работы по автоматизации графического языка велись. К сожалению программа МКС "Буран" была в одночасье закрыта. ДРАКОН переживал не лучшие времена, в целом на его разработку ушло 15 лет, но возник и на драконьей улице праздник. Этот праздник назывался проект Sea Launch. В проекте участвовали США, Норвегия, Россия и Украина. Пуски ракет производились с плавучей стартовой платформы, размещенной на экваторе в западной части Тихого океана в районе островов Кирибати. Управление пуском осуществлялось с находящегося поблизости сборочно-командного судна. Для каждого пуска стартовая платформа и сборочно-командное судно совершали морской рейс с базы, расположенной на западном побережье США, к островам Кирибати, а затем возвращались обратно. Результаты применения драконьей технологии оказались блестящими. Они превзошли все ожидания. После этого драконья технология использовалась в российско-французском космическом проекте «Фрегат», а также при модернизации ракеты-носителя «Протон-М». Результаты были стабильно высокими и руководство Пилюгинского центра приняло решение использовать драконью технологию во всех последующих проектах.

Я не историк космонавтики, хотя и работал когда-то в стенах РКК "Энергия" . И возможно, я несколько исказил какие-то факты или намерения людей. То что написано было услышано мною от разных людей и в разное время, а что-то было найдено в книгах и Сети. Проще говоря это моя компиляция истории развития языка ДРАКОН. Но бесспорен только один факт. ДРАКОН, как графический язык и как среда разработки, имел значительный успех в очень крупных проекта. Основываясь на примере ДРАКОНа я хочу поставить под сомнение утверждение некоторых коллег в этом форуме о том, что графические языки пригодны лишь для наглядного предствления простых задач.

Поищите к гугле информацию и проектах "Буран" и "Sea Launch" и их программном обеспецении. Это по меньшей мере просто интересно .

С Уважением,
md034t

Здравствуйте, jangle, Вы писали:

int Test = 1;
while (Test < 10) {
    Test++;
}
print("The number is " + Test);

я так понял что это вот это где-то записано? Мамачки... Я даже не уверен что понял что-то в том рисунке, что за странный Merge?
Ну и места занимает многовато...

Здравствуйте, jangle, Вы писали:

J>Язык программирования Microsoft Visual Programming Language (VPL) — это средство разработки приложений, в котором используется модель

Думаю вполнее имеет и скорее всего будет.
Т.к. если провести паралель с электронникой то это уже похоже на создание схем. На счет того что пишут — плохо читается не согласен. Любая схема читается гораздо лучше чем текст. Есть понятие мастшабирования и выделения — то что не нужно на данный момент можно скрыть/уменьшить. Преставте что электрическую схему бы описывали : эммитер транзистора A подключается к эммитору транзистора Б и т.д.

Помоему будущее за схемами в программировании , а именно соединением компонентов друг с другом. Некоторые компоненты будут объединяться в более функциональные. Также как это делают в любом радиотехническом приборе в том числе и вашем любимом компьютере.

И собирать программы в будущем сможет любой пользователь, также как сейчас может собрать компьютер. Зная что куда втыкать.

Здравствуйте, jangle, Вы писали:

J>Язык VPL понятен для начинающих программистов, которые знакомы с такими концепциями, как переменные и логические операции.

Интересно, откуда это бред постоянно всплывает? Если у вас, значит, графика, мышка и дрэг-н-дроп, то оно сразу становится интуитивно понятным, легким в использовании и доступным новичкам? То, что на самом деле понятно новичкам — это ясные объяснения короткими порциями, и предоставление только нужной информации вместо пичканья его мегатоннами документации в духе «вот MSDN, в нем все есть!!!».

J>Интересно, имеет такой язык будущее? Дело в том, что я тоже пытаюсь создать подобный скриптовый язык, для автоматизации в Windows

Это как Apple Automator? Имел бы, если бы все приложения Windows следовали одной спецификации. А так ты кроме соединения плохо документированных COM-объектов (которые реализуют далеко не все) ничего предложить не сможешь.

J>Язык VPL понятен для начинающих программистов, которые знакомы с такими концепциями, как переменные и логические операции.

Нифига он не понятен. Именно из-за этого. Потому что кому-то понадобилось ясные и четкие инструкции вроде for, = (в смысле присваивание), if и прочие не упростить, а усложнить. Потому что сами слова никуда не делись, появилась куча вспомогательных слов (Variable, Data), были заменены какие-то термины (Merge, Join), все это еще позамалевывалось квадратиками и стрелочками.

Похоже на гибрид блок-схем и UML. Будущего у такого нет, потому что блок-схемами и умлем многого не нарисуешь — замучаешься все это потом на листах A0 печатать и пытаться понять, что с чем связано.

Для мелкого и заранее определенного чего-то пожалуйста. Среди популярных примеров Yahoo! Pipes и Apple Automator

Насчет будующего именно этого языка трудно сказать,
но подобные языки существуют десятилетиями, например программирование PLS
(LADDER BUILDER) программирование логических цепей или контроллеров.
Такие языки незаменимы в робототехнике например http://www.paa.co.uk/labauto/products/overlord/overlord2.asp

Здравствуйте, ., Вы писали:
.>А интересно, удалось ли кому стырить в программирование из математики красивые формулы? Которые, конечно, не картинки, но таки не одномерный текст, а довольно нелинейные объекты, там всякие верхние/нижние индексы, структура операторов (что интеграл может иметь область интегрирования, а может иметь только функцию, плюс по каким переменным), формализовать "дефолтные значения".
.>Скажем,
.>
.>выглядит довольно неплохо, даже по сравнению с аналогами на других супер-пупер функциональных языках.

Новый язык Sun — Fortress.
Вот фрагмент кода в pdf: http://research.sun.com/projects/plrg/faq/NAS-CG.pdf
Парсят они эту жуть, кстати, модным PEG парсером XTC Rats!.

Здравствуйте, jangle, Вы писали:

J>Интересно, имеет такой язык будущее?

Конечно, имеет. При одном , правда, условии — что эта программа имеет такое же отношение к программированию, как постройка домика из кубиков первоклассником — к архитектуре. Но таких программ сейчас большинство, так что успех будет

Здравствуйте, D. Mon, Вы писали:

DM>А можете нарисовать сортировку массива? Очень интересно, как будет выглядеть.

пример на Lucid из википедии

qsort(a) = if eof(first a) then a else follow(qsort(b0),qsort(b1)) fi
  where
     p = first a < a;
     b0 = a whenever p;
     b1 = a whenever not p;
     follow(x,y) = if xdone then y upon xdone else x fi
                     where
                        xdone = iseod x fby xdone or iseod x; 
                     end
  end

    --------> whenever -----> qsort ---------
   |             ^                           |
   |             |                           |
   |            not                          |
   |             ^                           |
   |---> first   |                           |
   |       |     |                           |
   |       V     |                           |
   |---> less ---                            |
   |             |                           |
   |             V                           V
---+--------> whenever -----> qsort -----> conc -------> ifthenelse ----->
   |                                                       ^   ^
   |                                                       |   |
    --------> next ----> first ------> iseod --------------    |
   |                                                           |
    -----------------------------------------------------------

Если кто хочет побаловаться — есть lucid-synchrone, который работает поверх Ocaml

Здравствуйте, jangle, Вы писали:

Scratch — интерпретатор «детского» языка программирования, придуманный в Media Lab (лаборатории эргономики) Массачусетского технологического института. Программа на языке Scratch составляется из блоков, которые вы перетаскиваете мышью и складываете вместе, как кусочки мозаики. Блоки представляют собой выражения, переменные и императивные программные конструкции. Эта среда настолько проста, что написать небольшую игру вы сможете за несколько минут. А для обучения программированию детей ничего проще, наверное, еще и не придумано.

Графическое представление этого детского языка, мне нравится гораздо больше чем те блоки и стрелочки принятые в более "взрослых" вариантах.

J>Язык программирования Microsoft Visual Programming Language (VPL)...
Это вариант от MS лишь бы обшестандартный BPEL не реализовывать?

Здравствуйте, jangle, Вы писали:

J>Прикольный язык. Думаю, за такими системами будущее!
За такими системами прошлое . Понаписали таких систем уже до черта, и переодически снова появляются желающие писать. Тема столь же вечная, как и язык программирования на основе русского языка, как специализированные языки, понятные бухгалтеру. Типа — а давайте ка мы избавимся от программистов и пусть его работу выполняет специалист в предметной области, который программировать не умеет. Вот только не учитывается одно — тот, для кого выучить какой-то язык программирования представляет сложность — тот обычно к программированию не способен вообще, и никакая мегасистема на основе построения программы из кубиков ему не поможет. И в результате в конечном счете придется кликать мышкой на этом языке для начинающих, который имеет кучу ограничений, короче придется со всем этим возиться людям, которые программировать более-менее умеют, а не тем, для кого язык предназначался изначально. Профессионалов такой язык отпугнет, так как по возможностям язык будет отставать от современных лет так на 20, а дилетанты на нем такого напишут, что будет один сплошной баг .
А почему за такими системами прошлое, я, например, щас занимаюсь тем, что переписываю с нуля один достаточно приличный проект, который изначально разрабатывался на фреймворке, где все рисовалось мышкой. Ну и довелось в свое время мне и мышкой порисовать достаточно сложные системы. У таких систем есть несколько очень сильных недостатков, от которых не избавиться принципиально:
1) Невозможность сделать diff и merge, и чтоб можно было понять что изменилось. При работе в команде файл приходится лочить, чтоб никто его не менял. Забудешь залочить — с другими членами команды синхронизоваться не получится, придется все писать заново. В принципе, теоретически наверно это можно сделать, но сейчас такого нет, и появится это ох как не скоро;
2) Мышкой набирать получится один черт на порядок медленнее, чем при набивании текста в нормальной IDE. Да, проблема медленного набора решаема, например путем заучивания сотни хоткеев. Но в этом случае для обучения работы с этой системой потребуется до черта времени. И кстати, полностью мышкой один черт не получится — переменным, методам, классам — всему этому надо давать имена.
3) До черта времени требуется, чтобы нормально расставить элементы. Стрелочки чтоб там не пересекались, не налазили сами компоненты друг на друга. Автоформат сделать настолько интеллектуальный, чтоб он мог форматировать сложную схемку для чтения человеком, обеспечить возможность частичного форматирования — крайне тяжелая задача. Теоретически может быть когда-нибудь напишут такой автоформаттер, но пока — увы и ах, автоформаттеры даже для текстовых файлов работают не идеально;
4) Рефакторинг. Тоже для таких систем сделать крайне проблематично. На текущем этапе проще переписать все заново, чем сделать простейший и безопаснейший extract method, про более сложные виды рефакторинга вообще можно забыть — проще переписать все заново;
5) Логика одинаковой сложности будет занимать в текстовом виде гораздо меньшую площадь экрана, чем в графическом. На картинках зачастую показывается только часть необходимой информации, в этом случае что-то разобрать еще можно. Теоретически это даже плюс, так как будет вынуждать писать более просто. Но практически, никто рефакторингом заморачиваться не будет, и будут до крайней степени усложнять диаграмки;

В принципе, теоретически когда-нибудь возможно и удастся кому-то придумать достаточно удобный графический интерфейс, который будет так же удобен, как современные текстовые IDE. Вот только будут ли этим пользоваться, так как к тому времени текстовые среды разработки станут еще более удобными ? И кстати, такая мегасистема будет жрать ресурсов на порядок больше чем текстовая — для приличной работы потребуется наверно терабайт оперативки и 100 террагерцовых процессоров .

Здравствуйте, jangle, Вы писали:

M>>Scratch — интерпретатор «детского» языка программирования, придуманный в Media Lab

J>Прикольный язык. Думаю, за такими системами будущее!

Это будущее уже 30 лет наступить не может По сути Scratch это пост-EToys разработка. Для обучения детей E-Toys доказала свою эффективность.
Т.к. массовое распространение компьютеров только начинается, то, возможно, у таких систем и есть будущее где-то кроме обучения. Но, вряд ли

Здравствуйте, jangle, Вы писали:

J>Интересно, имеет такой язык будущее?

Вот именно такой — нет.
Как только код начнёт вылазить за границы экрана — на этом его полезность закончится.
Текстовое представление намного компактнее, и оно дискурсивное (последовательное), а не графическое (которое в данном случае надо охватить одним взглядом).
Как только человек хоть немного разберётся с языком — ему будет удобнее текстовое или псевдо-текстовое (с форматированием, с иконками) представление.

J>Дело в том, что я тоже пытаюсь создать подобный скриптовый язык, для автоматизации в Windows

Не язык надо создавать, а среду программирования, в которой подобные языки будут реализованы.

M>Как только человек хоть немного разберётся с языком — ему будет удобнее текстовое или псевдо-текстовое (с форматированием, с иконками) представление.

А мне графическое представление больше нравится, наверное из-за того, что я люблю рисованием заниматься.
Вот кусок программы, с одного взгяда понятно как это работает, даже код читать не надо

Здравствуйте, jangle, Вы писали:

Возврат от письменности обратно к наскальной живописи?

Alex EXO wrote:

> Да и математические формулы — скорее текст с расширенным символьным
> рядом, чем картинки.
А интересно, удалось ли кому стырить в программирование из математики красивые формулы? Которые, конечно, не картинки, но таки не одномерный текст, а довольно нелинейные объекты, там всякие верхние/нижние индексы, структура операторов (что интеграл может иметь область интегрирования, а может иметь только функцию, плюс по каким переменным), формализовать "дефолтные значения".
Скажем,

выглядит довольно неплохо, даже по сравнению с аналогами на других супер-пупер функциональных языках.

Здравствуйте, jangle, Вы писали:

Не касательно этого языка, а вообще всех подобных:
На мой взгляд использовать их вместо текста — это извращение.

Но идея интересна для языков, которые редко используются, и поэтому многие их не помнят.
В качестве примера — формат bat-файлов windows. Используется довольно редко, часто пользователю нужно сделать простую операцию, но изучать формат этих файлов у него нет никакого желанию — в следующий раз эти знания потребуется через несколько лет. Было бы удобно набросать из готовых компонентов то, что требуется и сгенерировать нужный файл.

Язык программирования Microsoft Visual Programming Language (VPL) — это средство разработки приложений, в котором используется модель программирования на основе графического потока данных, а не на базе логики управления, которая обычно применяется в программировании. Программа с использованием потока данных — это не набор последовательно выполняемых обязательных команд. Она больше напоминает коллектив рабочих на сборочной линии, которые делают указанную им работу по мере поступления деталей. В результате язык VPL хорошо подходит для программирования различных сценариев с параллельной или распределенной обработкой данных.

Язык VPL понятен для начинающих программистов, которые знакомы с такими концепциями, как переменные и логические операции. Однако этот язык предназначен не только для новичков. Возможность композиционного программирования с помощью этого языка может понравиться и более опытным программистам, поскольку это позволяет быстро разрабатывать программы и создавать прототипы. Кроме того, хотя инструментарий этого языка и предназначен для разработки приложений для роботов, лежащую в его основе архитектуру можно применить и в других приложениях. В результате язык VPL может оказаться привлекательным для широкого круга пользователей, в том числе, студентов, энтузиастов-любителей, и даже веб-разработчиков и профессиональных программистов.




Интересно, имеет такой язык будущее? Дело в том, что я тоже пытаюсь создать подобный скриптовый язык, для автоматизации в Windows

Здравствуйте, jangle, Вы писали:

M>>Как только человек хоть немного разберётся с языком — ему будет удобнее текстовое или псевдо-текстовое (с форматированием, с иконками) представление.

J>А мне графическое представление больше нравится, наверное из-за того, что я люблю рисованием заниматься.
J>Вот кусок программы, с одного взгяда понятно как это работает, даже код читать не надо

Так я же не говорю, что это вообще плохо. Для первого знакомства с программированием и для некоторых людей — удобно.
Если на этом остановится — то пусть так и будет. А если человек дальше начнёт программировать, писать более сложные программы — такое представление станет неудобным. По крайней мере, пока не изобретут телепатическое общение с компьютером.

Другое дело, если одну и ту-же программу можно по разному отобразить. Отобразить в виде диаграммы, или в виде текста, отобразить одни части более детально, другие поверхностно и т.п. То есть отделить саму программу от способа её отображения. Тогда переход от графического отображения к текстовому не потребует полного переучивания. И наборот, есть части программы которые удобней отобразить, скажем, пиктограммками, а не словами, или нарисовать стрелочки и пр. Поборники строго-текстового представления программы ведь пользуются подсветкой синтаксиса — разными цветами и шрифтами. Это же удобно. Так же было-бы удобно и некоторые части программы отображать в виде иконок или стрелок.
А идея этого VPL, как я понял, заключается в том чтоб всё и всегда отображать графикой. Что ещё менее удобно, чем всё и всегда отображать текстом.

Здравствуйте, fddima, Вы писали:


F>я так понял что это вот это где-то записано? Мамачки... Я даже не уверен что понял что-то в том рисунке, что за странный Merge?

Merge это для организации цикла, место куда передается управление

Здравствуйте, jangle, Вы писали:

J>Язык программирования Microsoft Visual Programming Language (VPL)...

Для меня основной недостаток таких визуальных сред, это то они заставляют действовать пользователя по модели глагол->существительное. Тогда как анализируя предметную область гораздо проще плюхнуть сущность и подумать что с ней надо сделать, т.е. имхо проще действовать наоборот, по схеме существительное->глагол.

Здравствуйте, mishaa, Вы писали:

M>Здравствуйте, jangle, Вы писали:

M>Scratch — интерпретатор «детского» языка программирования, придуманный в Media Lab

Прикольный язык. Думаю, за такими системами будущее!

Здравствуйте, indee, Вы писали:

I> Такие языки незаменимы в робототехнике

Так точно. Такие языки необходимы для разработки реализации многопоточной системы конечных автоматов. А это такие сферы:
— программирование логический цепей
— программирование робототехники
— программирование компьютерных моделей.
— и т.д.
Т.е. там где человек, это внешний фактор на систему, а не её винтик. Если еще точнее сказать то это автоматические системы, а не автоматизированные.

J>Интересно, имеет такой язык будущее? Дело в том, что я тоже пытаюсь создать подобный скриптовый язык, для автоматизации в Windows

У графических систем есть большая трудность — это сравнение изменений между двумя версиями. Для обучения (и на этапе продажи системы заказчику ) это не очень важно, но для коммерческого использования это может оказаться очень, очень критичным.

I>> Такие языки незаменимы в робототехнике

AAV>Так точно. Такие языки необходимы для разработки реализации многопоточной системы конечных автоматов. А это такие сферы:
AAV>- программирование робототехники

Интересно, что VPL для этого и предназначен: http://msdn.microsoft.com/en-us/robotics/aa731536.aspx

J>Интересно, имеет такой язык будущее? Дело в том, что я тоже пытаюсь создать подобный скриптовый язык, для автоматизации в Windows
Такие языки давно сущствуют и комерциализованы. Lustre- Estrel-SCADE, функционально-реактивное программирование, CAL Gem Cutter.
http://upload.wikimedia.org/wikipedia/en/7/71/SCADE_Suite_6_in_Windows_XP.png

Подобный подход чаcто применяют в пакетах 3D графики: Virtools, XSI 7.0 ICE

Здравствуйте, Mamut, Вы писали:

J>>Язык VPL понятен для начинающих программистов, которые знакомы с такими концепциями, как переменные и логические операции.

M>Нифига он не понятен. Именно из-за этого. Потому что кому-то понадобилось ясные и четкие инструкции вроде for, = (в смысле присваивание), if и прочие не упростить, а усложнить. Потому что сами слова никуда не делись, появилась куча вспомогательных слов (Variable, Data), были заменены какие-то термины (Merge, Join), все это еще позамалевывалось квадратиками и стрелочками.

M>Похоже на гибрид блок-схем и UML.

Забавно, там где вы видите UML — я вижу Dataflow programming
На SCADA пишут изрядного размера программы для mission-critical и ничего. Не уверен, правда, что в там есть присваивание или for в привычном понимании

Z>Забавно, там где вы видите UML — я вижу Dataflow programming
Z>На SCADA пишут изрядного размера программы для mission-critical и ничего. Не уверен, правда, что в там есть присваивание или for в привычном понимании

Ну, как тут уже заметили, в некоторых специфических задачах оно может быть полезно Но как, грубо говоря, язык общего назначения — никак

Здравствуйте, mishaa, Вы писали:

J>>Язык программирования Microsoft Visual Programming Language (VPL)...
M>Это вариант от MS лишь бы обшестандартный BPEL не реализовывать?

Будет бипел в следующем WF.

Здравствуйте, z00n, Вы писали:

Z>Подобный подход чаcто применяют в пакетах 3D графики: Virtools, XSI 7.0 ICE

Я бы сюда добавил операторы 3Д пакета Houdini. Говорят, что это очень удобный и быстрый в программировании/настройке подход.

Здравствуйте, Lloyd, Вы писали:

L>Здравствуйте, mishaa, Вы писали:

J>>>Язык программирования Microsoft Visual Programming Language (VPL)...
M>>Это вариант от MS лишь бы обшестандартный BPEL не реализовывать?

L>Будет бипел в следующем WF.

Дык, он вроде там уже давно есть
http://www.microsoft.com/downloads/details.aspx?FamilyID=6d0daf00-f689-4e61-88e6-cbe6f668e6a3&DisplayLang=en

Здравствуйте, prVovik, Вы писали:

L>>Будет бипел в следующем WF.

V>Дык, он вроде там уже давно есть
V>http://www.microsoft.com/downloads/details.aspx?FamilyID=6d0daf00-f689-4e61-88e6-cbe6f668e6a3&DisplayLang=en

Community Technology Preview

Z>>Подобный подход чаcто применяют в пакетах 3D графики: Virtools, XSI 7.0 ICE

P>Я бы сюда добавил операторы 3Д пакета Houdini. Говорят, что это очень удобный и быстрый в программировании/настройке подход.

Что-то похожее есть и в Apple Shake

Здравствуйте, jangle, Вы писали:

M>>Как только человек хоть немного разберётся с языком — ему будет удобнее текстовое или псевдо-текстовое (с форматированием, с иконками) представление.

J>Вот кусок программы, с одного взгяда понятно как это работает, даже код читать не надо

Издеваешся, да? Какой то Merge, какие-то точки соединения у квадратиков...
На мой взгляд удобство весьма сомнительно чистой с той точки зрения, что чтобы написать эту программулину (которая на С займет строчки 3) девелоперу придется усиленно шуршать по какому-нить тулбару, выбирая нужный ему квадратик, линию, таская линии к точкам соединения и т.п. У меня щас программулина — так там 1.5 млн строк, и я даже представить боюсь, как бы она выглядела, будь она вот в таком виде напедалина. Да и чисто механически делаеть это неудобно, воспринимается тяжело, а изменяется еще тяжелее. Сколько нужно усилий, чтобы обрамить эту всю твою картинку циклом? В тексте — 2-3 строчки, в этих всех картиночках — куча напряга с какими-то мерджами непонятными и ни о чем не говорящими. А чтобы кусок кода вынести в отдельную функцию?
Короче на мой взгляд перспектив нет.

Здравствуйте, jangle, Вы писали:

J>Интересно, имеет такой язык будущее? Дело в том, что я тоже пытаюсь создать подобный скриптовый язык, для автоматизации в Windows

Как уже неоднократно было написано выше, множество подобных языков уже давно имеют настоящее. Мне довелось познакомиться поближе с подобной системой, существующей уже лет 15, — LabVIEW, — и её языком G (Г ). Да, при первом взгляде на пример небольшой диаграммы умиляешься, как всё красиво, "интуитивно" и разноцветно. Но когда нужно что-либо при помощи этого сделать... Оно подходит разве что для задания правил для dial-up звонилки При более-менее серьёзной логике начанается такое спагетти из проводов, что уже не понимаешь что с чем соединяется и куда этот dataflow собственно flow. Да, есть локальные переменные, позволяющие разрывать непрерывные связи. Привет, goto!
Сам принцип dataflow имеет как преимущества, так и недостатки. Например, когда требуется выполнить некоторые действия строго последовательно, приходится городить огород специальными средствами. И при работе с циклами и другими управляющими структурами на этой почве возникает множество нюансов.
Если бы мне дали выбор между диаграммой и текстом, я бы выбрал текст

Здравствуйте, Mamut, Вы писали:

Z>>>Подобный подход чаcто применяют в пакетах 3D графики: Virtools, XSI 7.0 ICE
P>>Я бы сюда добавил операторы 3Д пакета Houdini. Говорят, что это очень удобный и быстрый в программировании/настройке подход.
M>Что-то похожее есть и в Apple Shake

и в vvvv (http://vvvv.org)

Здравствуйте, Огнеплюх, Вы писали:

О>И собирать программы в будущем сможет любой пользователь, также как сейчас может собрать компьютер. Зная что куда втыкать.
PCI-Express карту в AGP-слот не впихнёшь при всём желании. В то же время карту PCI вполне можно заменить на карточку PCI другого производителя. Почему? А потому что интерфейсы и протоколы проработаны и выдерживается производителем. А как с этим у строительных программных блоков будет?

Здравствуйте, Кондраций, Вы писали:
К> А потому что интерфейсы и протоколы проработаны и выдерживается производителем. А как с этим у строительных программных блоков будет?

Точно также. Если IInput <> IOutput то компонент "втыкаться" не будет.
Например в .NET или Delphi если замечали у компонента ListView , TreeView и т.д. есть такой "слот"/свойство называется ImageList из которого берутся иконки для отображения.
Так вот туда воткнуть можно только ImageList, другой компонент воткнуть не получиться.
Также как AGP устройство в PCI-E слот.

Здравствуйте, jangle, Вы писали:

J>А мне графическое представление больше нравится, наверное из-за того, что я люблю рисованием заниматься.
J>Вот кусок программы, с одного взгяда понятно как это работает, даже код читать не надо

А можете нарисовать сортировку массива? Очень интересно, как будет выглядеть.

Здравствуйте, jangle, Вы писали:

J>Язык программирования Microsoft Visual Programming Language (VPL) — это средство разработки приложений, в котором используется модель
а вот интересно. я таких штук много видел, но везде либо примитивный flow данных с переключателями(симулинк в матлабе), либо примитивный процедурный подход на уровне фортрана, ну еще дизайнеры sql запросов видел, но это уже скорее схема, чем ЯП. Как создавать софт такими примитивными средствами? Почему не видно реализаций более абстрактных и высокоуровневых категорий, чем процедуры и функций?

Здравствуйте, dotidot, Вы писали:

D>Здравствуйте, jangle, Вы писали:

J>>Язык программирования Microsoft Visual Programming Language (VPL) — это средство разработки приложений, в котором используется модель
D>а вот интересно. я таких штук много видел, но везде либо примитивный flow данных с переключателями(симулинк в матлабе), либо примитивный процедурный подход на уровне фортрана, ну еще дизайнеры sql запросов видел, но это уже скорее схема, чем ЯП. Как создавать софт такими примитивными средствами? Почему не видно реализаций более абстрактных и высокоуровневых категорий, чем процедуры и функций?

Можно поинтересоваться, что подразумевается под выделенным?
Вот, скажем в хаскеле кроме значений, типов и функций ничего вроде и нету, наверное, тогда это низкоуровневый язык со слабыми абстракциями?

Здравствуйте, Курилка, Вы писали:

К>Можно поинтересоваться, что подразумевается под выделенным?
К>Вот, скажем в хаскеле кроме значений, типов и функций ничего вроде и нету, наверное, тогда это низкоуровневый язык со слабыми абстракциями?
я имел ввиду "процедуры и функции на уровне фортрана". Вопрос был как раз про отсутсвие функций как первоклассных значений, системы типов(нет типа квадрата, есть только типы его входов и выходов, насколько я понимаю), классов типов итд, вообще большинства тех "штук" которые придумали с 60ых, что-то не видно. Видно либо управление потоком данных, либо квадратики на уровне фортрана(я с ним почти совсем не знаком, помню только что там нет динамического выделения памяти, и даже колбэк, хотя бы в виде указателя на функцию не смастериш).

Здравствуйте, D. Mon, Вы писали:

DM>А можете нарисовать сортировку массива? Очень интересно, как будет выглядеть.

Обычно она присутствует в виде отдельного кубика

Здравствуйте, fddima, Вы писали:


F>я так понял что это вот это где-то записано? Мамачки... Я даже не уверен что понял что-то в том рисунке, что за странный Merge?

Это потому, что автор диаграммы еще не дошел до структурного программирования, а остался на уровне GoTo. Интересно, как он перерисует диаграмму, когда поймёт, что for/while это не if+goto, а отдельная конструкция.

Здравствуйте, jangle, Вы писали:
J>Интересно, имеет такой язык будущее?

На мой взгляд — НЕТ.
За исключением может быть каких-нибудь отдельных частных применений.

Поскольку программирование, это не код, а способ думать. И этот способ ближе к письменной речи, нежели к картинкам.
И если посмотреть на аналогии, то текстовая запись оказалась перспективнее иероглифов.
Да и математические формулы — скорее текст с расширенным символьным рядом, чем картинки.

Это все о способах записи мыслей и о способах думать... Картинки, иероглифы и диаграммы удобны для качественных, недоформализованных задач. Но это как раз не программистское мышление, и не программистский результат.

Здравствуйте, ., Вы писали:

.>выглядит довольно неплохо, даже по сравнению с аналогами на других супер-пупер функциональных языках.
APL — http://en.wikipedia.org/wiki/APL_(programming_language)#Examples

Здравствуйте, ., Вы писали:

.>Скажем,
.>
.>выглядит довольно неплохо, даже по сравнению с аналогами на других супер-пупер функциональных языках.

Только вот мне кажется, что array — эт не из математики (там скорей было бы какая-нибудь A)

Здравствуйте, ., Вы писали:

.>А интересно, удалось ли кому стырить в программирование из математики красивые формулы?

В Маткаде очень давно есть похожая смесь математики и программирования. Вот, например, умножение матриц:


Это просто пример, я знаю, что есть уже готовая операция умножения, и что можно было сделать проще.

Здравствуйте, z00n, Вы писали:

DM>>А можете нарисовать сортировку массива? Очень интересно, как будет выглядеть.

Z>пример на Lucid

Но в данном инструменте первичен текст, диаграмма не содержит всей необходимой информации, т.е. сама самостоятельным языком не является, как я понял.

Здравствуйте, D. Mon, Вы писали:

DM>Здравствуйте, z00n, Вы писали:

DM>>>А можете нарисовать сортировку массива? Очень интересно, как будет выглядеть.

Z>>пример на Lucid

DM>Но в данном инструменте первичен текст, диаграмма не содержит всей необходимой информации, т.е. сама самостоятельным языком не является, как я понял.

Является, просто для бесплатных версий языков нет соответствующих IDE. Lucid это практически Lustre, а Lustre — это SCADE:

Здравствуйте, ., Вы писали:

.>А интересно, удалось ли кому стырить в программирование из математики красивые формулы? Которые, конечно, не картинки, но таки не одномерный текст,

Насчет неодномерности записи:
http://en.wikipedia.org/wiki/Epigram_(programming_language)

Здравствуйте, dotidot, Вы писали:

D>Здравствуйте, ., Вы писали:

.>>А интересно, удалось ли кому стырить в программирование из математики красивые формулы? Которые, конечно, не картинки, но таки не одномерный текст,

D>Насчет неодномерности записи:
D>http://en.wikipedia.org/wiki/Epigram_(programming_language)

Интересно чем же запись эпиграмовская стала вдруг сильно неодномерна? Разделение части конструкции на верхнюю/нижнюю сути, на мой взгляд, не меняет.
Визуально оно, наверное, поудобней, но вот в реальности принципиально от записи аля в строчку <Верхнее>, <Нижнее> не отличается.
А то так и языки учитывающие отступы надо будет неодномерными считать (хотя даже само понятие очень спорно и не понятно имеет ли большой смысл)
P.S. Ссылки лучше корректные давать (проверять)

Здравствуйте, Курилка, Вы писали:

К>P.S. Ссылки лучше корректные давать (проверять)
это не я это форум решил, что правая скобочка уже не ссылка.

Википедия про эпиграмм. Попытка II-ая.

а по теме — языки вообще не одномерные. Может компьютер и может прочитать всю программу в одну строку(но не все языки так позволяют записывать), но человек точно не осилит что-либо серьезное. Выделение модулей, под-модулей, разбиение кода на разные категории (конфиги, шаблоны, код...) ИМХО является введением новых измерений в программный проект. И это я только про сравнительно низкоуровневые концепции.

А зачем нужна "многомерная запись"? Что она даст? Повысит удельную плотность информации на квадратный пиксель? Думаю неплохо получится проанализировать результат подобного повышения плотности просто уменьшив размер шрифта. Мне понятнее не становиться, мыслительный процесс не улучшается.

Здравствуйте, Огнеплюх, Вы писали:

О>Т.к. если провести паралель с электронникой то это уже похоже на создание схем. На счет того что пишут — плохо читается не согласен. Любая схема читается гораздо лучше чем текст. Есть понятие мастшабирования и выделения — то что не нужно на данный момент можно скрыть/уменьшить. Преставте что электрическую схему бы описывали : эммитер транзистора A подключается к эммитору транзистора Б и т.д.
Как я понял, это мнение PMа, а не разработчика?

Здравствуйте, elmal, Вы писали:

E> все рисовалось мышкой

В Scratch (и E-Toys) код не рисуется мышкой. Это скорее что-то вроде автокомплита. Т.е. из списка доступных выбирается объект, из списка доступных над объектом действий выбирается действие. Естественно професионалу удобнее писать в редакторе с подсказками от среды. Но не специалисту может быть проще с такой вот штукой. Она, можно сказать, фиксирует синтаксис. Минус — нельзя делать сложные конструкции, плюс — трудно ошибиться. Хотя, для особо одарённых можно переключится в режим, когда скрипт вводится в простом редакторе кода. В майнстриме гораздо более примитивный вариант такого — это макросы в MS Access.

Есть в Squeak еще один режим "графического" представления кода. Tiles (пример смысла никакого не имеет):


Есть однозначное соответсвие между кодом и таким отображением. В таком режиме можно даже код вводить, но у меня не получилось

Здравствуйте, Andrei N.Sobchuck, Вы писали:

[cut]
ANS>Есть в Squeak еще один режим "графического" представления кода. Tiles (пример смысла никакого не имеет):
[cut]
ANS>Есть однозначное соответсвие между кодом и таким отображением. В таком режиме можно даже код вводить, но у меня не получилось
Помнится для людей испытывающих проблемы со скобочками был какой-то плагин к емаксу, который разными цветами помечал блоки.

Здравствуйте, Курилка, Вы писали:

К>Помнится для людей испытывающих проблемы со скобочками был какой-то плагин к емаксу, который разными цветами помечал блоки.

Ага. Вероятно это из той же оперы. Но тут "красота" наводится локально в пределах одного метода. Можно ли отобразить граф без потери выразительности — не ясно.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, Курилка, Вы писали:

К>>Помнится для людей испытывающих проблемы со скобочками был какой-то плагин к емаксу, который разными цветами помечал блоки.

ANS>Ага. Вероятно это из той же оперы. Но тут "красота" наводится локально в пределах одного метода. Можно ли отобразить граф без потери выразительности — не ясно.

Ну если совсем уж общий граф строить, то далеко не факт что на плоскости без пересечений его можно будет нарисовать, забавно было бы посмотреть на 3-мерные программы

Здравствуйте, elmal, Вы писали:

E>Здравствуйте, jangle, Вы писали:

J>>Прикольный язык. Думаю, за такими системами будущее!
E>За такими системами прошлое .
Возможно. Но я знаю несколько успешных примеров даже в совсем программистских местах.
Это всяческие визуальные редакторы xslt, для него есть и diff и merge, xml всё таки, рефакторинг; мышкой его набирать часто быстре, особенно в случае когда надо просто сбиндить один xml в другой(см продукты altova). wsdl и xsd, не непосредственное программирование, но близко. bpel — вообще бейсик на xml-e(см netbeans, oracle jdeveloper). Теоретически bpel создавался как инструмент скорее продвинутого менеджера, чем программиста, о чем свидетельствуют совершенно нечитаемые без визуального редактора простыни xml даже для простых случаев. Еще есть ESB решения конфиг к которым тоже на xml у которых визуальные редакторы либо уже есть, либо находятся в процессе написания, потому что без них туго.

Здравствуйте, dotidot, Вы писали:

D>А зачем нужна "многомерная запись"? Что она даст? Повысит удельную плотность информации на квадратный пиксель? Думаю неплохо получится проанализировать результат подобного повышения плотности просто уменьшив размер шрифта. Мне понятнее не становиться, мыслительный процесс не улучшается.

Повысит удельную плотность информации на количество символов (значков), потому что они тогда смогут быть расположены не последовательно, как в одномерном тексте, а структурно.

И не зря же придумали такую запись в математике. И не спроста она пользуется популярностью.
Большинству людей прочитать формулу, записанную в строку, всё-таки сложнее, чем прочитать её в структурном виде.

Но, я думаю, записывать/редактировать формулы в структурном виде на компьютере мало кому покажется удобным.

Поэтому оптимальным (с моей точки зрения) вариантом будет двойное представление информации. В одномерно-текстовом виде для редактирования и в структурном виде для чтения.

Здравствуйте, maggot, Вы писали:

M>Здравствуйте, dotidot, Вы писали:

D>>А зачем нужна "многомерная запись"? Что она даст? Повысит удельную плотность информации на квадратный пиксель? Думаю неплохо получится проанализировать результат подобного повышения плотности просто уменьшив размер шрифта. Мне понятнее не становиться, мыслительный процесс не улучшается.

M>Повысит удельную плотность информации на количество символов (значков), потому что они тогда смогут быть расположены не последовательно, как в одномерном тексте, а структурно.

M>И не зря же придумали такую запись в математике. И не спроста она пользуется популярностью.
M>Большинству людей прочитать формулу, записанную в строку, всё-таки сложнее, чем прочитать её в структурном виде.

ОК, только вот сравни число символов/переменных в средней формуле со средним числом переменных и других служебных слов в программах. Плюс математические книжки выходит читаются не как обычные (одномерно), а как-то совершенно иначе.
Кстати, на уровне догадки, человеческая мысль она более-менее последовательна, по меньшей мере отслеживать сразу несколько направлений развития мысли довольно сложно (по меньшей мере мне). Мат. формула есть лишь удобная запись какого-нибудь одного (порой довольно сложного) факта, но доказательства и прочие описания в математической литературе состоят из последовательной череды фактов, так же как мысль развивается от одного заключения к другому.

Здравствуйте, dotidot, Вы писали:

D>Это всяческие визуальные редакторы xslt, для него есть и diff и merge, xml всё таки, рефакторинг; мышкой его набирать часто быстре,

Ну так никто не спорит, в языках на основе xml сам черт ногу сломит — лучше уж визуально. Уверен, что мода на них скоро пройдет (лет через 10 точно от них все будут воротить нос). Я имел ввиду языки общего назначения с нормальными возможностями — они в большинстве случаев оказываются гораздо лаконичнее любых специфических xml языков, гораздо понятнее для чтения человеком чем любая диаграмма.

Здравствуйте, Курилка, Вы писали:

К>ОК, только вот сравни число символов/переменных в средней формуле со средним числом переменных и других служебных слов в программах.
Дык если любую формулу записанную в структурном виде переписать в линейный вид (одной строкой), то по любому будет больше символов, тк нужно будет расставлять скобки и запятые. Например в структурном виде
n
----
\
\
/
/
----
i=0
у нас 5 условных символов. Если записать линейно: sum(i,0,n) будет 8 условных символов: "sum" "," "," "(" ")" "i" "0" "n"

К>Кстати, на уровне догадки, человеческая мысль она более-менее последовательна, по меньшей мере отслеживать сразу несколько направлений развития мысли довольно сложно (по меньшей мере мне). Мат. формула есть лишь удобная запись какого-нибудь одного (порой довольно сложного) факта, но доказательства и прочие описания в математической литературе состоят из последовательной череды фактов, так же как мысль развивается от одного заключения к другому.
В книгах они расположены последовательно, потому что по-другому в книге их расположить не получится.
И если факты между собой не связаны, то мы можем спокойно менять их местами.

К>Плюс математические книжки выходит читаются не как обычные (одномерно), а как-то совершенно иначе.
А вообще аналогия с книгами не имеет отношения к тому что я писал, тк я имел ввиду структурный вид на уровне небольших конструкций, а не на уровне целых программ.

Здравствуйте, maggot, Вы писали:

M>Здравствуйте, Курилка, Вы писали:

К>>ОК, только вот сравни число символов/переменных в средней формуле со средним числом переменных и других служебных слов в программах.
M>Дык если любую формулу записанную в структурном виде переписать в линейный вид (одной строкой), то по любому будет больше символов, тк нужно будет расставлять скобки и запятые. Например в структурном виде
M> n
M>----
M>\
M> \
M> /
M>/
M>----
M>i=0
M>у нас 5 условных символов. Если записать линейно: sum(i,0,n) будет 8 условных символов: "sum" "," "," "(" ")" "i" "0" "n"

Ты очень ошибаешься, т.к. представляешь всё лишь в одной форме, которая тебе привычна, а она далеко не единственная.
К примеру на том же Хаскеле это будет sum i 0 n
(правда непонятен "целиковый" пример, так что, скорее всего в реальности выглядеть будет иначе)

На J это будет выглядеть +/ i.n
(Хотя тут чуть вру т.к. i.n не включает n)
На APL вроде примерно так же (правда про n не сильно в курсе).

К>>Кстати, на уровне догадки, человеческая мысль она более-менее последовательна, по меньшей мере отслеживать сразу несколько направлений развития мысли довольно сложно (по меньшей мере мне). Мат. формула есть лишь удобная запись какого-нибудь одного (порой довольно сложного) факта, но доказательства и прочие описания в математической литературе состоят из последовательной череды фактов, так же как мысль развивается от одного заключения к другому.
M>В книгах они расположены последовательно, потому что по-другому в книге их расположить не получится.
Расположены потому что расположены, очень логично.
M>И если факты между собой не связаны, то мы можем спокойно менять их местами.
А в программах наверное никак нельзя

К>>Плюс математические книжки выходит читаются не как обычные (одномерно), а как-то совершенно иначе.
M>А вообще аналогия с книгами не имеет отношения к тому что я писал, тк я имел ввиду структурный вид на уровне небольших конструкций, а не на уровне целых программ.
Только вот указать на это ты не удосужился.

Здравствуйте, md03t4, Вы писали:


M>Поищите к гугле информацию и проектах "Буран" и "Sea Launch" и их программном обеспецении. Это по меньшей мере просто интересно .

Можно автора языка тут http://forum.oberoncore.ru/viewtopic.php?f=28&amp;t=493 попробовать поймать.
Вообще дракон интересная вещь, и по моему намнго удобнее чем UML для алгоритмизации и работе на бумаге.
Но как полноценный язык программирования слабоват и многословен, зато конечно читабелен и кривая обучения
очень пологая
Да про космические корабли, все-таки как я понял (по обсуждению в ссылке выше) там нет объемного
кодирования, зато необходима надежность и легкое использование не программистами, это дракон
вполне обеспечивает.

Здравствуйте, jangle, Вы писали:

Думаю, вопрос выбора между графическим и текстовым представлением не имеет одного абсолютно универсального решения. И разница между этими представлениями куда глубже, нежели наличие тулов для диффа или врозможности таскать мышкой.
Основное отличие текстового и графического представлений состоит в том, каким обрназом человек их воспринимает. Текстовое представление читается последовательно, строчка за строчкой. А графическое — одним охватом, параллельно. Именно это наличие последовательности, текущего положения, и является кардинальным отличием одного от другого, и именно из этого проистекают их достоинства и недостатки.
Исходя из этого, легко понять, где будет выгодно текстовое представление, а где графическое. Первое предпочтительне, когда нужна информация о том, в какой последовательности нужно воспринимать информацию, когда содержащаяся логика слоржна и требует внимательного отслеживания логических цепочек. Ну то есть императивные и функциональные универсальные языки — это именно оно.
В противоположность, графическое представление удобнее, когда нам важно отразить структуру, когда важно понимание этой структуры в целом и связей внутри нее. Отсюда такие вещи, как, скажем, deployment diagramm в студии, ER-диаграммы сотоварищи, предпочтительнее в графическом виде.
Важно — не существует абсолютной границы, разумеется, а есть непрерывный спектр. Скажем, тот же язык запросов к БД в чем то удобнее в текстовом виде, в чем то в графическом, но текстовое все же обычно предпочтительнее просто ввиду того, что текстовые тулзы намного качественее.
Теперь что касается универсальных языков программирования. Суть задачи такова, что, все таки, текстовое представление более предпочтительно. И, если уж выбирать что то одно, такой язык, если это не игрушка и не обучающая программа, должен быть текстовым.
Другое дело что более оптимальным является смешанное представление. Понятно, что, если взять тот же шарп или джаву, то там, по сути, два довольно таки изолированных куска имеем: декларацию сущностей дизайна и наполнение методов. И первое скорее всего в графическом виде все таки удобнее. Первые шажки в этом направлении это, наверное, Смоллток. В студии есть двунаправленная диаграмма классов. Однако два разных редактора для одного и того же — это не совсем то, что способствует продуктивности. Редактор должен быть один. Как это в итоге будет выглядеть — отдельный большой вопрос. Что то такое есть в DevExpress CodeRush. Очень интересна концепция, которую мне Кирилл Осенков показывал, но он, к сожалению, не хочет пока что показывать это публично, так что я не буду об этом распространяться.

Здравствуйте, Кондраций, Вы писали:

К>PCI-Express карту в AGP-слот не впихнёшь при всём желании. В то же время карту PCI вполне можно заменить на карточку PCI другого производителя. Почему? А потому что интерфейсы и протоколы проработаны и выдерживается производителем. А как с этим у строительных программных блоков будет?

Примерно так же как в DirectShow сейчас. Посмотри любой редактор графа для DirectShow.

Здравствуйте, Glоbus, Вы писали:

G>У меня щас программулина — так там 1.5 млн строк, и я даже представить боюсь, как бы она выглядела, будь она вот в таком виде напедалина.

А у тебя вся программулина в один метод вписана, что-ли? Декомпозиция есть и там и там. Если учесть, что рекомендуется каждый метод делать не более 1-2-х экранов монитора, то и схемы будут соответствующие.

Твоя программулина отобразится на иерархию блоков, всего-то.

http://www.gameroo.nl/games/light-bot — кубикоподобный язык для программирования робота