Ответ на »сообщение 3080« (Руслан Богатырев)
___________________________
Ой, пока писал свой "памфлет", еще одно сообщение появилось ;-)

>>> А теперь попробуйте объяснить, что такое формальный не-текст (комбинация текста, графики, возможно -- звука). Видимо, это какой-то набор правил... (раз формальный). Эти правила представляются формальным языком (текстовым). Или как-то иначе? Так что первично?
Одним из способов определения правил формального текста являются синтаксические диаграммы. Так что первично? ;-)

А если без шуток, то не надо смешивать две разных вещи: задание правил, формализующих не-текст -- это одно. А его применение для решениях поставленных для него задач -- это другое. Как формализовать не текст? Да как угодно. Допускается использование любых способов, которые понятны человеку и удобны для его восприятия. Если мы вдруг осовим телепатию и научимся ее формализовать, то пусть будут телепатические правила.

Уф! Попытаюсь ответить всем сразу

Ответ на »сообщение 3076« (Руслан Богатырев)
___________________________
>>> в определенных ситуациях нетекстовое представление предпочтительнее?
С этой формулировкой согласен.

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

Использование же неформальных форм представления (пардон за каламбур) лично я считаю на данном этапе ненужным.

* * *
Ответ на »сообщение 3077« (Сергей Прохоренко)
___________________________
+1 ;-)
Согласен практически по всем пунктам, за исключением, может быть, непринципиальных деталей. Типа, "Эта комбинация должна автоматически преобразовываться в исходный текст программы". Теоретически нет необходимости в промежуточном этапе в виде текста программы на ЯВУ, комбинация графики и текста (и, может быть, чего-то еще) может сразу переводиться в набор машинных команд.

* * *
Ответ на »сообщение 3078« (Илья Ермаков)
___________________________
Я, конечно, понимаю, что "XML взял для примера", но увидев слова "графическую модель хранить можно в XML" невольно напрягся. Дело в том, что, по-моему, сама возможность использования форматов типа XML обусловлена тем, что у нас сейчас на компьюетрах избыток ресурсов по отношению к решаемым задачам. Если бы это было не так, то я своими руками убил бы человека, предложившего мне формат хранения данных, КПД которого порядка 10%.

Форматы XML, HTML, RTF и т.п. -- это, опять же по-моему, попытка создания формтаов, имеющих сосбтвенный "пользовательский интерфейс". Нрубо говоря, чтобы изменения было просто и удобно вносить в том же блокноте. Однако, практика показывает, что среднестатистический пользовтель часто предпочитает этого не делать, если имеется специальный разработанная утилита. Таким образом можно предположить, что если развитие аппаратных средств притормозится и возникнут реальные потребности в экономии ресурсов, то подобные форматы останутся только для мелочей (типа, BAT-файлы в MS DOS). В основном же данные будут хранится в бинарных файлах специального формата.

А по существу ответа согласен.

* * *
Ответ на »сообщение 3079« (Сергей Перовский)
___________________________
Самое "вкусное" я оставил напоследок ;-)

>>> Вообще, давайте все же не смешивать в кучу <...>
Каюсь, грешен... отчасти. Просто разговор как-то плавно перешел на обсуждение соотношения графики и текста вообще, что я не мог удержаться.

>>> Но, ради бога, объясните, чем удобнее создавать обработчик события в графическом виде?
Знаю о коварности аналогий, но все же не могу удержаться...
Ради бога, объясните, чем удобнее загружать значение из ячейки памяти в регистр процессора на ЯВУ? ;-)

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

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

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

Ну, и в качестве бонуса -- повод для флейма ;-)
>>> На этот случай у меня есть стандартная структура БД для описания технологических систем. И  BP-Win мы использовали только для демонстрации структуры.
Описание -- это одно, а разработка -- другое. В прикладных системах данные тоже храгятся в БД, но работают с этими данными порчему-то не через IB Expert, а через специально разработанные интерфейсные формы. Так что если вы и разрабатываете процессные описания пользуясь только табличным представлением, то я не знаю: то ли вами восхищаться, то ли жалеть ;-)

Ответ на »сообщение 3077« (Сергей Прохоренко)
___________________________

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

Оригинально. Давайте для простоты вынесем за скобки неформальные текст и не-текст (тем более, что Вы им все равно отказываете в праве на жизнь).

Остаются формальные текст и не-текст. А теперь попробуйте объяснить, что такое формальный не-текст (комбинация текста, графики, возможно -- звука). Видимо, это какой-то набор правил... (раз формальный). Эти правила представляются формальным языком (текстовым). Или как-то иначе? Так что первично?

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

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

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

Но, ради бога, объясните, чем удобнее создавать обработчик события в графическом виде?

Ответ на »сообщение 3077« (Сергей Прохоренко)
___________________________

Ответ на »сообщение 3076« (Руслан Богатырев)
___________________________

Ответ на »сообщение 3075« (Geo)
___________________________

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

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

Ответ на »сообщение 3076« (Руслан Богатырев)
___________________________

Ответ на »сообщение 3075« (Geo)
___________________________

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

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


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



Текст может быть формален и неформален. Не-текст (не обязательно графика, будем считать нечто комбинированное) также может быть формален и неформален. При этом восприятие неформального текста нередко дает меньше поводов для недопонимания, нежели неформального не-текста.


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


Если не-текст формален, то он подразумевает наличие своего формального текстового представления. С обратным сложнее: для формального текста иметь (построить) формальный не-текст не всегда просто.


... и в большинстве случаев совершенно не нужно.




Какой отсюда напрашивается вывод: разумнее всегда иметь формальный текст, а для ряда случаев -- соответствующий ему формальный не-текст (взаимно-однозначное соответствие).


Нет. Разумнее всегда иметь формальное комбинированное представление (графика + текст), которое автоматически преобразуется к тесту - для обработки компилятором.
Соответствие вовсе не должно быть взаимно-однозначным, так как одному и тому же текстовому представлению может соответствовать несколько различных комбинированных представлений.



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

Если люди прибегают к неформальному представлению, это лишь говорит о слабости и неудобстве имеющегося формального представления. Неформальное представление - это потеря времени.

Ответ на »сообщение 3075« (Geo)
___________________________

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

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

Текст может быть формален и неформален. Не-текст (не обязательно графика, будем считать нечто комбинированное) также может быть формален и неформален. При этом восприятие неформального текста нередко дает меньше поводов для недопонимания, нежели неформального не-текста.

Если не-текст формален, то он подразумевает наличие своего формального текстового представления. С обратным сложнее: для формального текста иметь (построить) формальный не-текст не всегда просто.

Какой отсюда напрашивается вывод: разумнее всегда иметь формальный текст, а для ряда случаев -- соответствующий ему формальный не-текст (взаимно-однозначное соответствие). Что касается неформального текста и не-текста, то они в программных проектах могут выполнять функцию предшествования формальным тексту и не-тексту в случае идей, спецификаций, документации.

Ответ на »сообщение 3074« (Сергей Перовский)
___________________________
>>> <...> но лишает возможности работать с бумагой. Может быть это для меня и неприемлемо
А может быть, в этом причина неприязни? Типа, как паровая машина на первых парусниках, которая использовалась исключительно для того, чтобы двигать корабль во время штиля, а в остальное время корабль, как и обычно, шел под парусом и ничем не отличался от других парусников.

По личным ощущениям... Для разработки небольшого, но структурного алгоритма мне удобнее работать именно с блок-схемой, так как в тексте с трудом отслеживаются ветвления и переходы. При введении струткуризации блок-схемы можно использовать и для более сложных алгоритмов. Сложный бизнес-процесс только мазохист будет разрабатываит в текстовом представлении, когда есть ARIS или хотя бы BP-Win. Говорю, как человек, который занимается их разработкой и представлением как в той, так и в другой форме: БП хотя бы на полсотни подпроцессов, представленный в комбинированной текстово-графическом форме, понять намного проще, чем тот же БП, заданный в виде исключительно текстового описания. Были даже прецеденты склеивания бумажных схем длиной по 3-4 метра. Опять же проще.

Пример, приведенный в »сообщение 3061« , -- это как раз пример неудачного использования графической формы представления в случае, когда использование текстовой формы проще и нагляднее. Грубо говоря, из того, что никто в здравом уме не будет ездить на карьерном самосвале в магазин за хлебом, не следует, что карьерные самосвалы не нужны.

Не знаю, знаком ли кто-то с математикой Бурбаки (остальным пример будет неопнятен), но я схему конструкции ступени в текстовом виде пишу только тогда, когда это является обязательным. Если нет, то графовое представление (M-граф) намного проще и нагляднее.

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

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

Ответ на »сообщение 3073« (AK)
___________________________
По этой выдержке можно сделать вывод, что алгоритм для Вас, прежде всего (а, возможно, - и только), - текстовое представление.
Из всех определений алгоритма мне ближе всего такое:
algorithm - совокупность четко определенных правил, процедур или команд, обеспечивающих решение поставленной задачи за конечное число шагов.
Форма представления значения не имеет.

Единственное, в чем я с Вами полностью согласен - графическое представление алгоритма малопригодно всегда, в общем случае, универсально. Но есть случае, когда оно таки эффективно, например, в обучении или для End User Programming.
Пожалуй шире, графическое представление удобно:
1. для простых алгоритмов (поэтому для обучения и End User),
2. для некоторых специальных алгоритмов (например, табличное представление конечных автоматов).

Используются диаграммы Несси-Шнейдермана, но новшество, в сравнении с классическим - выделение иерархических слоев (подпрограмм) и навигация между ними.
Вот спасибо, а я забыл название...
25 лет назад я был их яростным пропагандистом :)
Тогда в ходу был фортран и требование оформления алгоритма  в виде диаграммы заставляло мыслить структурно.
Но и с минусами мы столкнулись очень быстро.
В знаменитых Законах Паркинсона есть злая шутка, что любая анкета создается при участии консультанта по недостатку места. То же самое относится и к графическому представлению алгоритмов :(
Попробуйте нарисовать на листе или на экране диаграму с несколькими вложенными ветвлениями.
Введение иерархии несколько упрощает дело, но лишает возможности работать с бумагой. Может быть это для меня и неприемлемо.

Ответ на »сообщение 3072« (Сергей Перовский)
___________________________

Ответ на »сообщение 3070« (AK)
___________________________
Очередные терминологические разборки :)


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


Я говорю о малопригодности визуального представления алгоритмов, а мне возражают о полезности визуальных средств разработки.
Из всех приведенных ссылок (которые удалось открыть) непосредственно к представлению алгоритмов относится пожалуй только
http://www.codekana.com/features.html
Графического там только линии соединяющие пары скобок, что я всячески приветствую - на бумаге сам постоянно их рисую, чтобы глаз не промахивался.
Расцветка на мой взгляд сделана неудачно: не нужно цветом дублировать вид оператора, я бы предпочел иметь расцветку в зависимости от уровня вложенности.


По этой выдержке можно сделать вывод, что алгоритм для Вас, прежде всего (а, возможно, - и только), - текстовое представление. Такой вывод я делаю исходя из следующих соображений:
1) Все ссылки, которые я привел, демонстрируют именно визуальное представление алгоритмов, а не только визуальные средства разработки. Конечно, визуальный язык принципиально не может быть реализован вне визуальной среды, но это в данном случае не главное. Ссылки довольно разнообразны, но, по-моему скромному мнению, должны были продемонстрировать, что визуальным представлением алгоритмов занимаются довольно активно, а значит интерес к нему есть.
2) Со всех ссылок вы выбрали
http://www.codekana.com/features.html
которая как раз не удовлетворяет критерию визуального представления алгоритма - это обычное выделение вторичной нотации текстового представления :)

Но, если вдуматься, - разве алгоритм может быть представлен только в текстовой форме?
Если считать, конечно, что алгоритм - это ... :) Кстати, среди ссылок были и ссылки на Workflow Foundation. Подчеркну - workflow. Что мешает представить операторы в виде визуально-графических операторов и графически представить связи между ними? Кстати, в текстовых языках эти связи заданы как раз имплицитно...

Единственное, в чем я с Вами полностью согласен - графическое представление алгоритма малопригодно всегда, в общем случае, универсально. Но есть случае, когда оно таки эффективно, например, в обучении или для End User Programming. Кстати, именно это и послужило мне поводом для ответа в этой ветке - во-первых, использование визуальных языков в обучении моя научная специализация, во-вторых, одной из причин работ над РОСой было замещение windows в учебных заведениях. Или я ошибаюсь? ;) 


Общую идею можно посмотреть на примере EasyCode Developer Suite.
А можно прямую ссылку? А то поисковик выдает кучу "рассуждений о" и кряков.

Страница продукта:
http://www.easycode.de/docs/en/e_produkte_cpp.htm
"Быстрое руководство", по которому можно составить общее представление об представлении :) алгоритмов, которое используется в даной среде:
http://www.easycode.de/pdf/e_v75_quickguide_cpp.pdf
Используются диаграммы Несси-Шнейдермана, но новшество, в сравнении с классическим - выделение иерархических слоев (подпрограмм) и навигация между ними. Что и позволяет оперировать большим количеством графических операторов без перегрузки восприятия.