DRAKON.SU

Уважаемый Илья!

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

Моя просьба имеет серьезную причину. Похоже, что наша многосерийная интеллектуальная битва подошла к одному из своих самых острых пиков. Алексей Донской и Сергей Прохоренко поставили вопрос с такой кинжально-убийственной остротой (и я от всего сердца благодарю их за это!), что я просто вынужден изложить свою позицию в предельно-откровенной и не менее острой форме.
В сообщении Алексея Донского, как всегда, немало очень интересных идей, глубоких мыслей и метких замечаний. Но оценивая сообщение в целом (речь идет только о сообщении Четверг, 24 Апрель, 2008 09:47), я считаю, что оно содержит ошибку. Не просто ошибку, а драматическую, роковую, принципиальную, фудаментальную ошибку. Эта ошибка настолько серьезна, что я посвящу ее анализу специальное сообщение. Особенно интересно, что Алексея Донского поддерживают ведущие психологи мира. Так что он ошибся не один, а в очень авторитетной компании.
Подробнее я изложу свою позицию в следующем сообщении, которое отправлю завтра или послезавтра.

Да кто ж тут кого ограничивает? У нас на форуме на выражение мнений и обсуждения ограничений нет... Это мы просто спорим так

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

Предлагаю для обсуждения следующий вопрос:

Если кто-то не воспринимает это как ограничение на выражение прочих мнений, то он глубоко ошибается, увы.

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

Никоим образом. Возможно, я попался в ловушку своей предметной области, думая про анимацию в SCADA... где нет выделенных направлений, как на хорошей блок-схеме (например, в Драконе). Но в том, что грамотное (уместное) применение анимации совершенно бесполезно в программировании, Вы меня пока не убедили

В высшей степени справедливо. То есть необходимо, но недостаточно.

То есть удобочитаемость любой хорошей модели при полном сохранении её семантики можно испортить "внешними эффектами" (несколько направлений я проиллюстрировал). Равно как и улучшить, что я и предлагал

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

Цена, цена! Всё дело в сравнении цены перехода на другую страницу по гиперссылке и перевода глаз из одного угла страницы в другой. Подозреваю, что сознание человека "многопоточно" и сравнительно легко держит общий контекст (периферийным зрением) при сосредоточении на каком-либо объекте в центре поле зрения. Так что, возможно, здесь работы от памяти особо и не требуется.

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

Подозреваю же, что именно об этом и будет говорить Паронджанов...

Здесь речь идет о работе сознания. Память действительно многопоточна, но сознание, увы, нет.
Совершенно справедливо.То есть необходимо, но недостаточно.

Владимиру Паронджанову:
Книга - блеск! Но при "симультанном" взгляде на примеры дракон-схем, бросается в глаза некий дисбаланс.
Слова "ДА" и "НЕТ" около икон "развилка". Это единственный необрамленный элемент + неясно где он должен быть (слева/справа, сверху/снизу от линии).
Предлагаю заменить ДВА слова на один символ НЕ - инверсного выхода логического элемента (маленький пустой кружок вписаный в контур иконы в месте выхода связи).
Да уж, сколько еще классных вещей похоронено под "тополями".....

Нельзя убирать да/нет - потеряется интуитивная понятность для любого человека, поднятого с постели в три часа ночи с бодуна....

Интерактивность не сводится к движению и вспышкам на экране. Воссоздавать на экране пульт управления АЭС с гирляндами огней - это, видимо, перегиб. Главное, чего не позволяет чертеж (и блок-схемы), и для чего нужна интерактивность, - это быстро собирать надежные программы из готовых блоков на основе шаблонов, а затем последовательно настраивать по подсказкам. Я чувствую, что мне сейчас припомнят Емелю из сказки и мои якобы кривые программистские ручки (а я вовсе не программист!). На это есть хороший ответ: в ближайшие годы в России будут сотни тысяч программистов, работающих по технологиям двадцатилетней давности с негарантированным результатом - это нормально? И к ним еще десятки миллионов пользователей, вручную исправляющих огрехи программистов...

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

Ну тогда можно ввести опционально, а жизнь покажет чем народ будет пользоваться.
Согласитесь, маленький кружок гораздо более эргономичен.
Кстати, если не ошибаюсь, в электронных чертежах допускается писать буквы внутри элемента,
одну обычную и одну с чертой над ней для обозначерия инверсии.
Господа эргономисты! Ваше мнение?

Это как раз проблема "чертежей" и представления программ. И я не увидел ни одного аргумента против этого. При том уровне наглядности и интерактивности, который есть у современных систем программирования (включая сюда и блок-схемные примочки вроде UML и "Дракона"), ни о какой быстрой разработке надежных программ речь идти не может.

Вы же не станете утверждать, что "Дракон" более нагляден, чем "Скретч" [url]http://letopisi.ru/index.php/Скретч[/url] , с которым легко разбираются дети за 5 минут:


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



Нет такого термина, как "конфигурирующее программирование". Во всяком случае Google такого не знает. Кстати, если Вы заметили, я предложил аж три уровня инструментария: древовидный блочный исходный код (промежуточный уровень), таблицы/многоколонный текст внутри блоков (нижний уровень) и деревья влияющих и зависимых переменных/функций и т.п. (верхний уровень). Деревья влияния при крайней необходимости могут автоматически преобразовываться в любимые многими графы - с последующим форматированием вручную.


Я имел в виду не типовые задачи, а типовые средства их решения. И не продвинутых пользователей, которым Excel'я хватит за глаза, а системных аналитиков, которые при хорошем инструментарии смогут обойтись без толпы кодеров. Не надо принижать проблему и предложенное решение. Кодирование должно распрощаться с последними намеками на искусство (с неопределенным уровнем качества), а превратиться в незначительный и сильно автоматизированный процесс с гарантированным результатом. (Как говорит Лужков, механизированные средства уборки улиц должны вытеснить гастарбайтеров с мётлами и лопатами.) Творчество должно остаться разработчикам инструментальных средств и постановщикам прикладных задач.


Раз интересует "Дракон", значит интересует и представление программ. А именно об этом и речь. Значит, дело не в интересе к вопросу, а просто в предубеждении. Чем только "Дракон" взял завзятого "текстовика" - поражаюсь. Да, очень качественные и лаконичные блок-схемы. Или сейчас учатся программированию минуя эту стадию? Наверное, все дело в конечном автомате, который реализован на "Драконе", и в других местах в таком красивом виде пока не встречается.


"Непосредственно уровень программирования" уже обеспечен на 200%. Разработчики компиляторов и библиотек уже съели за три десятка лет миллионы собак. Каждую парадигму программирования сотни раз обсосали со всех сторон и придумали по 20 некрасивых решений каждой проблемы. Так что вполне настало время подумать и о инструментах того уровня, о котором я говорю.

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

Немного больше, но еще не всех.

Пример выглядит отвратительно, просто анти эстетика какая-то

Это западная эстетика агрессивного геометризма (термин мой), навеянная конструктором ЛЕГО. Похоже на небоскребы Манхэттена.



Мне такая эстетика тоже не нравится. Угловатость, ненужные выступы, избыток цвета, грязные цвета, мелкий белый шрифт на темном фоне, резкие тени, лишние блоки там, где инструкции выполняются последовательно, тесное сопряжение блоков. Всё это отвлекает внимание.

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

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

Ну, эстетика дело темное. В отличие от эргономики.