Ответ на »сообщение 2567« (Руслан Богатырев)
___________________________
Текстовый человеко- и машиночитаемый язык вовсе не обязателен, если есть графический язык. Графическая модель непосредственно отображается не в текстовый язык (т.е., в программу), а в данные (чаще всего в таблицы параметров). Затем эти данные могут либо преобразовываться в код, который может быть прочитан человеком или компьютером, либо непосредственно обрабатываться компьютером как данные - без преобразования в программу на текстовом языке. Первый вариант имеет сомнительную перспективу - достаточно вспомнить о совершенно маргинальной нише машиночитемых документов, не очень удобных для человека.

Пример: в MS Access запрос, сделанный с помощью конструктора, в 99,9% случаев не просматривается разработчиком в виде SQL-кода. Те 0,1% случаев, когда это необходимо, объясняются лишь недоработкой конструктора - тот не содержит средства для объединения строк из запросов одинаковой структуры с помощью UNION.

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

Фрактал: структура, состоящую из частей, которые в каком-то смысле подобны целому
Определение замечательное по сути фрактала, но для моделей вообще очень опасное. Известно, что целое не подобно сумме частей. Эта очевидная мысль обычно ускользает. Система, построенная только из надёжных элементов может быть ненадёжной. Упущение этого - основная трудность Оберон направления.
Я уже приводил пример модели из системы триггеров, какими являются наши компьютеры.
Если добавить волны хаоса от внешнего мира, то построение карточного домика из идеальных игральных карт покажется сомнительной деятельностью.

Вы никогда не пробовали графически формировать топологию сети Петри с 10 тыс. позиций ?
А в каком пакете ПО? :) Кстати, вы не пробовали чертить схемы в PCAD?
Странно слышать такой как бы контрпример от поборника модульного программирования. Разве в визуальной среде нельзя образовывать группы и подгруппы? Разве все винтики в модели автомобиля рисуется в AutoCAD каждый раз заново?
Может Вы боитесь связей "каждый элемент с каждым"? Не будет такой гомогенной структуры.

Графически это все чертить вместо того, чтобы написать формулу композиции, -- не лучший вариант.
Почему? Как говаривали греки приведя в качестве решения чертёж: "Смотри!".

Текстовый язык для этого куда лучше формализуется (четко специфицируется), чем графический. И он более "компьютерогеничен" (в большей степени подготовлен для программной обработки).
А потом вопрошают откуда кризис программирования! Да ничего подобного. Графическая карта в компьютере есть, а вот карта текстового парсера?
Другой аргумент - попробуйте схему процессора описать в текстовом виде или какой-нибудь более-менее сложный чертёж или карту местности.

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

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

Да уж... мешками ее будет, собственности-то энтой...

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

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

"Ты, Петька, прежде чем со сложными вещами разбираться, с простыми разберись." (С) Василий Иванович.

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

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

Хорошо. Давайте рассуждать. Речь идет о связи текстового языка и графического. Графический язык должен быть понятен программе (компьютеру). Разумеется, если предусматривается его обработка не только и не столько мозгом человека. Значит, такой язык требует формализации (некоего внутреннего представления, при этом часть представления -- значимая для обработки, а другая -- косметическая: "смысловой квадратик" сдвинут на 2 пикселя правее и на 3 ниже ожидаемой "стандартной" позиции). Будем говорить о значимой части.

Человек может не иметь доступа к этому внутреннему представлению ("объектному коду"), но само представление существует. Можно ли для такого представления, где фигурируют сущности и связи, сформулировать тестовый язык (подразумевающий исходный текст), который будет читаться человеком и при этом иметь однозначное отображение на внутреннее представление графического языка? Если может, то почему это изначально не предусматривать?

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

В общем, не на том экономим.

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

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

Берем сеть Петри с ограничением на емкость позиции (т.е. позиция содержит не более одной фишки). Тогда наличие фишки в позиции означает, что условие (приписываемое позиции) выполняется. Отсутствие -- не выполняется. Условие и есть атомарное состояние. Состояние сети Петри определяется вектором разметки (вектором значений числа фишек в позиции с данным номером). Например, q1 = (0,1,0,0,0,1,1); q2 = (1,1,1,0,0,0,1). Собственно сети Петри удобнее использовать, чем конечные автоматы в тех случаях, когда надо отобразить одно состояние подсистемы в виде набора атомарных состояний (ее элементов) и иметь возможность быстро менять (через топологию связей) логику работы (что в случае КА сложнее).

Допустим, что некоторая подсистема (ее модель) представлена такой сетью Петри. Используем сеть в качестве модели, определяющей логику переходов из одного состояния подсистемы (q1) в другое (q2). Состояние подсистемы складывается из набора состояний ее элементов (в данном примере их 7). Закон перехода из состояния в состояние опосредованно представлен топологией сети (дуги, соединяющие позиции с переходами).

Пример: некая активность (процесс, задача, поток -- неважно) имеет десять датчиков-состояний (комбинации значений которых и описывают однозначно состояние этой активности, которое интересует диспетчера активностей). Есть 1000 активностей, разбитых на группы (по 5-20 активностей в группе, т.е. 50-200 групп). Связи устанавливаются не абы как. Для групп существуют готовые схемы комбинирования активностей (логики взаимодействия) через эти состояния (в том смысле, что с чем "вязать" -- отлажено на уровне схем связей). И это пример очень небольшого масштаба. Разумеется, можно использовать иерархические сети -- но это отдельный разговор.

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

Ответ на »сообщение 2562« (Руслан Богатырев)
___________________________
Вы никогда не пробовали графически формировать топологию сети Петри с 10 тыс. позиций ?
Ни только никогда не пробовал, но и не думал, что в этом может быть какая-нибудь польза.
Можно примерчик, когда нужна такая сеть?

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

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

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

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



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

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

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

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

Конечно же модели должны быть во главе угла и тут визуальные методы рулят.

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

В статье "Золотой треугольник Паскаля" (http://www.europrog.ru/paper/triangle.pdf) я попробовал изложить на примере конкретной (хорошо известной) задачи подход на основе моделирования и конструирования (попутно проиллюстрировав другие вещи).