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

В MS Access имеется такая вещь как Схема данных: диаграмма, задающая связи между таблицами. Текстового представления схемы связей нет. По крайней мере, я о таком не знаю.
Юрий, Вы меня пугаете ;-)
Все эти связи можно выразить при помощи SQL (foreign keys и т.д.). Я не хочу спорить о том, лучше это текстовое представление или хуже, чем диаграмма, но оно есть.

Ответ на »сообщение 3089« (Руслан Богатырев)
___________________________
>>> Вот если речь идет о специальном процессоре (набор команд и архитектура которого заточены под исполнение графической спецификации) -- тогда другой разговор.
Честно говоря, не понял мысли. Есть программа, называемая транслятором, которая по определенным правилам переводит последовательности байт, интерпретируемых человеком как текст, в последовательности байт, интерпретируемых процессором как набор машинных команд. Почему при существующем процессоре невозможен графический транслятор, который по определенным правилам переводит последовательности байт, интерпретируемых человеком как графика, в последовательности байт, интерпретируемых процессором как набор машинных команд?

* * *
Ответ на »сообщение 3089« (Руслан Богатырев)
___________________________
>>> Вы согласны с тем, что в тех ситуациях, когда графика выглядит предпочтительнее, имеет смысл иметь (как опцию) и ее текстовый эквивалент (в том числе, для продвинутых товарищей)?
Руслан, Вы, прямо-таки, инквизитор: так и выкручиваете руки ;-) Ответ: не всегда. В MS Access имеется такая вещь как Схема данных: диаграмма, задающая связи между таблицами. Текстового представления схемы связей нет. По крайней мере, я о таком не знаю. Естественно, все эти данные хранятся в БД, их сожно найти и посмотреть с помощью стандартного вьюера таблиц. Но 95% пользователей MS Access даже не знают, где это искать. К тому же я считаю, что отсутствие специальной возможности просмотра схемы данных в виде текста означает именно отсутствие текстового эквивалента. Если это не так, то Вы можете утверждать, что и у бинарного файла (например, EXE) есть текствоое представление. Ведь никто не мешает открыть это файл в любом низкоуровневом редакторе и любоваться набором крякозябриков. Правда, я в ответ могу написать свой вьюер, который будет каждый байт представлять точкой определенного цвета, и на этом основании утверждать, что у всего есть графическое представление ;-)

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

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

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

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

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

Вполне это допускаю. И даже не утверждаю, что для любого формального текста НЕВОЗМОЖНО подобрать формальную графику. Я лишь говорю, что решить эту задачу (подбора представления графики для текста) несколько сложнее (чем наоборот). И что есть текстовое представление (бинарное -- это неважно) -- в общем случае, а есть графическое -- для ряда случаев. Только и всего.

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

Все много проще: есть языки спецификаций (ориентированы на человека, иногда еще и на машину), есть языки программирования (ориентированы на человека и на машину). Роль языков спецификаций (и представления графики) все возрастает. Понятная тенденция. Только базис-то зачем отрицать?

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

Я это уже объяснял. Существование еще не означает получение адекватного по удобству для капризного субъекта.

Ключевая проблема - а вы уверены, что компьютер представляет программу как текст?

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

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

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

Ответ на »сообщение 3083« (Илья Ермаков)
___________________________
>>> удаляемся от машины и "прыгать" к ней гораздо труднее
И что? Пардон, но если бы мне кто-нибудь 15 лет назад сказал, что в будущем Борландовский компилятор Паскаля будет создавать машинный код, по эффективности сравнимый с ассемблером, я бы не поверил.

>>> т.е. уменьшаем универсальность, получаем заточку на узкое конкретное применение
При переходе от пятого Паскаля к шестому в язык были добвавлены объекты. Разве это привело к сужению области применения? Просто Вас, наверное, сбивает с толку то, что большинство нынешни находящихся в зачаточном состоянии инструментов "графического программирования" -- это узконаправленные системы. Но просто другие пока неразвиты. Но это не значит, что они невозможны в принципе. Летательный аппарат тяжелее воздуха тоже когда-то казался нереальным.

>>> нелюбимые Вами мамонты наконец вымрут
Давайте сразу договоримся, что я здесь пишу свои мысли о дальнейшем развитии инструментальных средств, а не свои мечты. Что касается моих пристрастий, то Паскаль и Ассемблер -- это моя любовь на все времена ;-)

* * *
Ответ на »сообщение 3084« (Илья Ермаков)
___________________________
>>> Таблица - это удобный и ёмкий способ представления
Забыли слово "двумерный" ;-)

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

* * *
Ответ на »сообщение 3085« (Руслан Богатырев)
___________________________
>>> Вы (если правильно понял) -- второй пункт
Неправильно. Я говорю, что есть задачи, в которых графическая форма имеет преимущенство перед текстовой. А есть -- наоборот.

>>> Первое у меня вопросов не вызывает (не знаю, как у Вас).
Высказывание слишком сильное. Чтобы автоматически получить формальный текст, устраивающий любого человека, нужно вернуться во времена фортрана, когда формальным требованиям родчинялся не только синтаксис, но и формат. А так... Я в Паскале внутренний блок сдвигаю на два проблеа, а Антон Григорьев на один. В остальном, мысль понятная и я с ней согласен.

Однако, как уже сказано до меня, в данном случае за основу нужно брать машинное представление. У меня даже была статья поэтому поводу, но по специальной тематике и на бумажном носителе. Надо посмотреть, если ее выложили в интернет, то брошу ссылку.

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

Видятся три варианта соотношений между ними (с точки зрения первичности):
1) текст первичен;
2) графика первична;
3) равноправны.
Я предпочитаю первый пункт. Вы (если правильно понял) -- второй пункт. Мы не уточняем области применения представлений, а говорим априори, в общем случае.

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


С представлением работает мозг и/или компьютер. Здесь также видятся три варианта:
1) только мозг (нарисовали на салфетке, показали другому мозгу; компьютер вне игры);
2) только компьютер (мозг свихнется понимать, что там такого накодировали, а компьютер -- переварит как свое родное);
3) мозг и компьютер (наиболее распространенная ситуация).

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

Остается третий вариант. Человек и компьютер. Оба должны это представление в конечном счете распознать и интерпретировать.


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


Теперь формулирую два зеркальных тезиса:
1. Для любого формального графического представления можно сформировать формальное текстовое представление (отображение: графика --> текст).
2. Для любого формального текстового представления можно сформировать формальное графическое представление (отображение: текст --> графика).


Что касается формализации графических представлений - не сильно выбирая, наугад и например:
http://creonet.cdu.edu.ua/downloads/vpls.rar
Смею вас заверить, если считать алгоритм системой, элементы и связи которой представлены или посредством текста, или графически - между ними существует изоморфизм (или, в крайнем случае, гомоморфизм). А это означает возможность _свободного_ и _точного_ перехода между двумя формами представления. Я, например, использовал для обучения школьников среду с гетерогенным представлением алгоритма - одновременно создается и графическое представление, и текстовое. Т.е. - два окошка - слева создаем графическое представление в виде дерева - справа автоматически генерируется текстовое, и наоборот. Существуют генераторы визуальных языков программирования (например, GenEd) - задаются правила синтаксической и семантической трансляции и получается "графическая" оболочка. В такой среде можно создавать алгоритм, меняя представление "на лету".


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

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

Одним из способов определения правил формального текста являются синтаксические диаграммы. Так что первично? ;-)

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

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

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

Пытаюсь понять Вашу позицию. Итак, выяснили, что есть два вида представления (чего -- следующий вопрос, пусть будет -- "сущностей и отношений"): текст и графика (не-текст).

Видятся три варианта соотношений между ними (с точки зрения первичности):
1) текст первичен;
2) графика первична;
3) равноправны.

Я предпочитаю первый пункт. Вы (если правильно понял) -- второй пункт. Мы не уточняем области применения представлений, а говорим априори, в общем случае.

С представлением работает мозг и/или компьютер. Здесь также видятся три варианта:
1) только мозг (нарисовали на салфетке, показали другому мозгу; компьютер вне игры);
2) только компьютер (мозг свихнется понимать, что там такого накодировали, а компьютер -- переварит как свое родное);
3) мозг и компьютер (наиболее распространенная ситуация).

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

Остается третий вариант. Человек и компьютер. Оба должны это представление в конечном счете распознать и интерпретировать.

Теперь формулирую два зеркальных тезиса:
1. Для любого формального графического представления можно сформировать формальное текстовое представление (отображение: графика --> текст).
2. Для любого формального текстового представления можно сформировать формальное графическое представление (отображение: текст --> графика).

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

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

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

Так что если вы и разрабатываете процессные описания пользуясь только табличным представлением, то я не знаю: то ли вами восхищаться, то ли жалеть ;-)
Таблица - это удобный и ёмкий способ представления, между прочим.
Попробуйте забавы ради нарисовать орграф импорта для нескольких десятков модулей, расслоив их на уровни.
В Блэкбоксе такой инструмент есть - Info->Show dependencies.
Жуткая мешанина линий, в которой трудно разобраться.
Совершенно иной расклад - разместить модули по уровням в таблице.
Табличку сделать интерактивной - по щелчку на ячейке подсвечиваются зоны прямого и косвенного импорта.
Очень удобно и наглядно. У нас такой инструмент есть, скоро опубликуем.

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

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


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

Вот и ФП-шники всё "мозги компостируют", что вымрут аки мамонты...
На самом деле всё очень просто.
Как отмечал ещё Дейкстра, программист работает через пропасть между машиной и задачами из прикладных областей.

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

Если мы приближаем язык к проблемному краю, то:
а) удаляемся от машины и "прыгать" к ней гораздо труднее, таким образом, рискуем по производительности (что при критических требованиях просто не вытянем);
б) самое главное - точно так же приближаемся к конкретной точке на этом проблемном крае, т.е. уменьшаем универсальность, получаем заточку на узкое конкретное применение.

Держите весь этот баланс в уме, когда говорите про отмирание мамонтов.
Дело в том, что некоторые из текущих мамонтов (это безопасные императивные ЯВУ - т.е. Паскаль-семейство, плюс последователи в виде Явы/Шарпа) находятся как раз в точке оптимума, т.е. равноиндифферентны как по отношению к конкретному оборудованию, так и по отношению к конкретной задаче.
Любая попытка сдвига при текущем раскладе даёт выигрыш для конкретной ситуации при общем проигрыше (уходе из оптимума).

Поэтому, чтобы вытеснить текущую группу универсальных языков, нужно что этот самый текущий расклад изменился. Проблемный край принципиально не меняется, только всё удлиняется (больше задач).
Может измениться только другой край - оборудование.
В некотором смысле это сейчас происходит - мультипроцессорность. Это пока что только закрепляет оптимум за Паскаль-семейством (Це-семейство из этого оптимума окончательно вылетает). ФП подвинулось поближе к этому оптимуму. Но других революций пока не предвидится.

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