Язык ДРАКОН, вариации на тему "No OS" Опции

[kamil yaminov]

С виссимом сталкивался, код генерируется (по крайней мере так было пару-тройку лет назад) мягко говоря плохой. Как его потом после меня будут разбирать, если придется, - неясно. Интересно, как у матлаба с этим обстоит.

[Гость_MrYuran_*]

Вот что я хочу!
Только для дракона.

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

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

[dxp]

Вот что я хочу!
Только для дракона.

А по мне так текстовое представление алгоритма там выглядит куда привлекательнее - компактнее и связнее.

[Гость_MrYuran_*]

А по мне так текстовое представление алгоритма там выглядит куда привлекательнее - компактнее и связнее.

Линейного - может быть.
Но как только пошли ветки...
Паронджановский подход с "заворачиванием хвоста" очень оригинальный.
Он как бы соответствует тексту, написанному в несколько колонок, каждая из которых соответствует своей теме.
При этом алгоритм намного читабельнее, чем в текстовом виде.
Программа из одномерной (длинная простыня линейного кода) становится двумерной.
А если добавить ещё третье измерение, в нашу-то эпоху 3D-визуализации...
Например, расслоить приложение на уровни абстракции, с полупрозрачными слоями и видимыми переходами между ними.

[dxp]

Линейного - может быть.
Но как только пошли ветки...

Так я про пример по ссылке - там весьма ветвисто было.

Паронджановский подход с "заворачиванием хвоста" очень оригинальный.
Он как бы соответствует тексту, написанному в несколько колонок, каждая из которых соответствует своей теме.
При этом алгоритм намного читабельнее, чем в текстовом виде.
Программа из одномерной (длинная простыня линейного кода) становится двумерной.
А если добавить ещё третье измерение, в нашу-то эпоху 3D-визуализации...
Например, расслоить приложение на уровни абстракции, с полупрозрачными слоями и видимыми переходами между ними.

Имхо, это кажущееся. Когда попробуете реальные вещи, достаточно большие, в графике поописывать, энтузиазму поубавится. Я подобные штуки проходил на ПЛИСах - там Top-Level в графике решил делать, и прога хорошая (Aldec Active-HDL), и сама задача прямо для этого, казалось бы, отлично подходит. И сам контекст - Top-Level - как раз отличное место для применения графики - логики почти никакой, сплошные квадратики модулей и сигналы. Но устал довольно быстро. Внешне всё красиво, но когда надо что-то добавить, приходится прилично рисовать, чтобы опять было красиво. Утомительно это. А уж про реализацию логики в графике и говорить нечего - телодвижений получается несоизмеримо больше. Фтопку.

Верный путь для упрощения работы - повышение уровня абстракции, а не изменение типа представления. Поэтому переход от асма к С, от С++, от С++ к питону - это на деле показывает прирост могущества метода. А текст это или схемой нарисовано - дело пятое. В большинстве случаев текст, как раз, оказывается компактнее, нагляднее, гибче и универсальнее.

[Гость_MrYuran_*]

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

А если интерактивно - и текст, и графика?
Быстро накидал графически скелетон, а потом обычным текстом можно обвешивать.

[dxp]

Быстро накидал графически скелетон, а потом обычным текстом можно обвешивать.

Дак ничо не мешает это делать и при традиционном подходе: в визио (или щас yEd пробую, тоже прикольная штука, в чём-то и поудобнее визио, хотя попроще, конечно, безплатная) накидал структурную схему, потом кодируешь. Я ещё практикую в тяжёлых случаях разработку текстового описания (не кода, а просто описания технически-литературным языком) разрабатываемого устройства. Когда вот так вот даже сам себе объяснишь, как оно должно быть, сразу мера понимания поднимается неслабо, что очень способствует эффективности работы.

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

Всё сказанное из личного опыта.

[Гость_MrYuran_*]

Это описание потом может и для отчёта пригодиться, если в таковом возникнет необходимость. Как показывает практика

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

[dxp]

... когда дело доходит до отчета, начертанные первоначальные зарисовки ничего общего не имеют с конечным кодом.

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

Польза от визуализации только тогда, когда она всегда абсолютно соответствует коду.

Польза от визуализации в визуальном представлении структуры и связей - прямых, обратных и перекрёстных. Детализация на уровне примитивов кода не только не полезна, но вредна - она занимает много места и несёт мало информации. Код

if(a > b) d = f(a); else b = f(b);

прост, читается на одном дыхании. Графическое же представление его в виде блок-схемы (странное, кстати, название: термин блок-схема в норме переводится как block diagram - т.е. структурная схема, а то, что у нас под этим понимается, так это flow chart - график потока [выполнения]) займёт три элемента. Когда подобного кода хотя бы на полэкрана, в графике это будет неслабых размеров схема, которую обозреть не так-то просто. Плотность информации в схеме на единицу площади экрана монитора очень низкая. Выручить может иерархичность, но тут уже о визуальном представлении говорить не приходится, запутаться тут в этих иерархиях проще простого.

Я выше уже предлагал сравнить эффективность подходов на каком-нибудь простом реальном примере, который всем понятен. Например, взять и сделать реализацию кольцевого буфера. Давайте попробуем? Я текстом, а вы графикой. Хоть на драконе, хоть на той примочке, на которую давали ссылку. Результат, думаю, скажет сам за себя, не будет необходимости тратить время на ломание копий.

[Прохожий]

Код

if(a > b) d = f(a); else b = f(b);

прост, читается на одном дыхании. Графическое же представление его в виде блок-схемы (странное, кстати, название: термин блок-схема в норме переводится как block diagram - т.е. структурная схема, а то, что у нас под этим понимается, так это flow chart - график потока [выполнения]) займёт три элемента.

Здесь возразить трудно.
Но, однако, не всегда графика хуже.
Если говорить о языках программирования, то PSpice-ом лучше пользоваться в графическом варианте.
Или схемотехника в чистом виде. Вспоминаем словесное описание схем в авторских и патентах...
Хуже дело, если речь идет о конечных автоматах.
Тут сложно отдать предпочтение чему либо.

[_pasha]

Вот что я хочу!
Только для дракона.

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

[dxp]

Но, однако, не всегда графика хуже.

Никто и не утверждает, что графика хуже. Есть места, где она рулит. ПМСМ, это места, где нужно обозревать структуру - т.е. составляющие и связи между ними. Описание логики и алгоритмов - уже весьма спорно - тоже зависит от детальности. Мелкие детали делают графику очень загромождённой и нечитабельной.

Если говорить о языках программирования, то PSpice-ом лучше пользоваться в графическом варианте.
Или схемотехника в чистом виде.

Безусловно. Там, где важно подчеркнуть топологию схемы, показать тракт прохождения сигнала - обычно это аналог и силовуха, схема рулит безоговорочно (текст там только в виде комментариев). Но если схема цифровая, то тут уже не так однозначно. Наверное, нередко приходится видеть схемы, где накидано эн прямоугольников УГО микросхем с кучей выводов, к которым никаких проводников не подведено, а прицеплены только метки (в лучшем случае проводники всё-таки есть, но выведены с пинов на шину и там тоже метки), и все соединения выполняются по меткам. Т.е. по сути и схемы-то и нет, такое описание отлично делается текстом (пример любого Top-Level'а на Verilog/VHDL). И это не случайно - завести проводками такую пачку связей, не имеющих чёткой структуры, - это просто сделать схему совершенно нечитабельной.

[_pasha]

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

Интересное свойство "графика" VS "текст" - диаграмма полностью себя оправдывает только если описываемый объект имеет большое сродство с графом/орграфом. В других случаях позиции wysiwyg'a ослабляются. В качестве примера можно привести язык в твердотельном моделировании: OpenSCAD. Т.е. количество информации, вводимой в текстовом виде при создании модели, существенно перевешивает кол-во полезных кликов мыши.

[Прохожий]

Интересное свойство "графика" VS "текст" - диаграмма полностью себя оправдывает только если описываемый объект имеет большое сродство с графом/орграфом. В других случаях позиции wysiwyg'a ослабляются. В качестве примера можно привести язык в твердотельном моделировании: OpenSCAD. Т.е. количество информации, вводимой в текстовом виде при создании модели, существенно перевешивает кол-во полезных кликов мыши.

На самом деле не "графика" VS "текст", а "графика & текст", потому как PSpice PSpic-ом, а модель валять лучше текстом.
Точно так же, как и в ДРАКОН-е. Символы символами, а без текста все одно - ничего не выйдет.
В иных случаях тот же автомат выглядит презентабельнее, когда он оформлен в виде switch-case.
С другой стороны - графики и циклограммы.
Для оценки поведения объекта лучше применять графики, а вот для точных расчетов - таблицы.
ПМСМ, здесь уже вопросы философского уровня.

[Гость_MrYuran_*]

Никто и не утверждает, что графика хуже. Есть места, где она рулит. ПМСМ, это места, где нужно обозревать структуру - т.е. составляющие и связи между ними. Описание логики и алгоритмов - уже весьма спорно - тоже зависит от детальности. Мелкие детали делают графику очень загромождённой и нечитабельной.

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

Далее.. условие.
В тексте иконы отображаем самую суть, код можно спрятать внутри.
Между тем, условия бывают иногда многоэтажными, на несколько полных строк.
И приходится вдумчиво вчитываться.

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

[_pasha]

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

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

[kamil yaminov]

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

не один я оказывается такой )

Сообщение отредактировал kamil yaminov - 22.2.2012, 11:48

[Гость_MrYuran_*]

Народное творчество

Раб на галерах
Пашет, мечтая взлететь.
А нужен ДРАКОН.

Апплодирую стоя!

[_pasha]

Народное творчество

Вот так чинарям и уступаются точки невозврата. Со "сверхвысоким пониманием".

[Прохожий]

Апплодирую стоя!

И я тоже.
ПМСМ, Паронджанова надо занести в раздел Великих людей.
Заслужил...