DRAKON.SU

Текущее время: Четверг, 27 Февраль, 2020 07:00

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 114 ]  На страницу Пред.  1, 2, 3, 4, 5, 6  След.
Автор Сообщение
 Заголовок сообщения: Re: ЯВУ, ассемблер и Дракон...
СообщениеДобавлено: Вторник, 22 Апрель, 2008 05:35 

Зарегистрирован: Вторник, 29 Ноябрь, 2005 21:41
Сообщения: 53
Alexey_Donskoy писал(а):
Теперь вспомним, что в топике у нас Дракон. Похоже изображение цикла на эти модели? Совсем даже нет.
Может ли оно служить прообразом этих моделей? Как первоначальный вариант вполне.
Сергей Прохоренко писал(а):
Вы имеете в виду инструментальную часть ОС "Роса", визуальную надстройку к "Блэк-Боксу", новый редактор "Дракона" или что-то другое?
Визуальную подсистему.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 22 Апрель, 2008 09:43 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 82
Откуда: Москва
Илья Ермаков писал(а):
Так у Паронджанова в книжке циклы обрамляются подсветкой (в случае вложенных циклов - чередование светлых и серых прямоугольников).


Это хорошо. Значит, всех тянет в одном и том же направлении.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ЯВУ, ассемблер и Дракон...
СообщениеДобавлено: Вторник, 22 Апрель, 2008 09:49 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 82
Откуда: Москва
GUEST писал(а):
Сергей Прохоренко писал(а):
Вы имеете в виду инструментальную часть ОС "Роса", визуальную надстройку к "Блэк-Боксу", новый редактор "Дракона" или что-то другое?
Визуальную подсистему.


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

GUEST, Вы тоже что-то создаете? Вместе или порознь? Это визуальная подсистема чего?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ЯВУ, ассемблер и Дракон...
СообщениеДобавлено: Вторник, 22 Апрель, 2008 10:23 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1061
Откуда: Россия, Чебоксары
Сергей Прохоренко писал(а):
Ну, вообще-то я спросил Алексея Донского - это он взялся что-то создавать, засучив рукава.

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

На самом деле много конкртеных задач есть и на основной работе. Например, сейчас мы рассматриваем вопрос - стоит ли покупать CoDeSys. Или продолжать развивать собственное CASE-средство (пока имеем FBD, идеально подходящий для предметной области, а вот вопросы кодогенерации проработаны пока только под одну целевую платформу... чего явно недостаточно). Драконом тоже заинтересовал своих ребят... Думаем пока что...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ЯВУ, ассемблер и Дракон...
СообщениеДобавлено: Вторник, 22 Апрель, 2008 17:18 

Зарегистрирован: Вторник, 29 Ноябрь, 2005 21:41
Сообщения: 53
Сергей Прохоренко писал(а):
GUEST писал(а):
Сергей Прохоренко писал(а):
Вы имеете в виду инструментальную часть ОС "Роса", визуальную надстройку к "Блэк-Боксу", новый редактор "Дракона" или что-то другое?
Визуальную подсистему.
Ну, вообще-то я спросил Алексея Донского - это он взялся что-то создавать, засучив рукава.
Отвечу немного ниже.
Сергей Прохоренко писал(а):
GUEST, Вы тоже что-то создаете? Вместе или порознь? Это визуальная подсистема чего?
Это то, что я имел в виду, когда увидел Ваш вопрос. Подсистема для вмещающей её инструментальной системы. Более определенно можно будеть сказать когда интерес к ней наберет критическую массу. А почему это Вас интересует?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ЯВУ, ассемблер и Дракон...
СообщениеДобавлено: Вторник, 22 Апрель, 2008 20:25 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 82
Откуда: Москва
Сергей Прохоренко писал(а):
GUEST, Вы тоже что-то создаете? Вместе или порознь? Это визуальная подсистема чего?
Это то, что я имел в виду, когда увидел Ваш вопрос. Подсистема для вмещающей её инструментальной системы. Более определенно можно будеть сказать когда интерес к ней наберет критическую массу. А почему это Вас интересует?[/quote]

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ЯВУ, ассемблер и Дракон...
СообщениеДобавлено: Среда, 23 Апрель, 2008 10:19 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 82
Откуда: Москва
Хочу добавить, что гибрид из блок-схемы, сплющенной в один столбец, и программного кода неоднороден. Из некоторых блоков (ветвление, цикл, переключатель) управление передается на следующий после блока оператор. А из других блоков (модуль, процедура) управление передается обратно в точку вызова. Было бы целесообразно нижнюю границу блоков второго типа делать сплошной или, например, такой:
Вложение:
Line3.PNG
Line3.PNG [ 518 байт | Просмотров: 4969 ]

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ЯВУ, ассемблер и Дракон...
СообщениеДобавлено: Среда, 23 Апрель, 2008 12:18 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 4628
Откуда: Москва
Уважаемый Сергей Прохоренко!

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

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


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 23 Апрель, 2008 12:30 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 631
Откуда: Россия, Орёл
Сергей, да нет как таковых никаких "блок-схем"... Что это такое, опишите внятно? Максимум, к чему придёте - это к тому, что задано некоторым стандартом ГОСТ-ISO.

Вам почему-то кажется, что "Дракон - это блок-схемы", на основании каких-то внутренних ассоциаций... И Вы всё время употребляете этот термин.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ЯВУ, ассемблер и Дракон...
СообщениеДобавлено: Среда, 23 Апрель, 2008 13:37 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 82
Откуда: Москва
Владимир Паронджанов писал(а):
Уважаемый Сергей Прохоренко!

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

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


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


Это не Дракон-схема.
Смотрите сообщение в этой ветке за Воскресенье, 20 Апрель, 2008 13:19
Я сторонник будущих графических систем программирования (в широком смысле, т.е. не как формы, на которую кидают контролы, и не как традиционной RAD - системы) и визуальных языков программирования (http://en.wikipedia.org/wiki/Visual_programming), но считаю устаревшими и неудобными блок-схемы, в которых может быть несколько (в высоту и в ширину) веток блоков, соединенных линиями последовательности исполнения.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 23 Апрель, 2008 14:03 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 631
Откуда: Россия, Орёл
А что взамен, в двух словах? И Вас не устраивает именно представление в виде графа или вообще как факт наличие последовательности исполнения?
Во втором случае бессмысленно говорит об "устарелости и неудобности", Вы просто затрагиваете другой уровень проектирования. Который никак не отменяет уровень графа управления. Ну а если Вы надеетесь полностью его экранировать, так, чтобы вообще не вспоминать, а создавать программные системы волшебным инструментом, в котором Вы описали только "вот хочу, чтобы было так", то это уже из области бредней ИИ...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 23 Апрель, 2008 14:23 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 82
Откуда: Москва
Илья Ермаков писал(а):
Сергей, да нет как таковых никаких "блок-схем"... Что это такое, опишите внятно? Максимум, к чему придёте - это к тому, что задано некоторым стандартом ГОСТ-ISO.

Вам почему-то кажется, что "Дракон - это блок-схемы", на основании каких-то внутренних ассоциаций... И Вы всё время употребляете этот термин.

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



Я согласен с тем, как термин "блок-схема" определен в Википедии:
http://ru.wikipedia.org/wiki/%D0%91%D0%BB%D0%BE%D0%BA-%D1%81%D1%85%D0%B5%D0%BC%D0%B0
Дракон подпадает под это определение.
Да, Дракон в сотни раз лучше, чем UML.
Да, в Драконе есть хорошее средство описания конечного автомата, чего нет в других блок-схемах.
Но от этого Дракон-схема не перестает быть блок-схемой со всеми родовыми недостатками блок-схем. Не надо держаться блок-схем. Есть гораздо более удобные средства для визуального программирования. Разумеется, средства описания конечного автомата должны стать частью будущего языка визуального программирования, например, на основе Оберона.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 23 Апрель, 2008 14:34 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 82
Откуда: Москва
Илья Ермаков писал(а):
А что взамен, в двух словах?

Смотрите сообщение в этой ветке за Воскресенье, 20 Апрель, 2008 13:19

Илья Ермаков писал(а):
И Вас не устраивает именно представление в виде графа...?

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 23 Апрель, 2008 15:22 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 631
Откуда: Россия, Орёл
Цитата:
Илья Ермаков писал(а):
А что взамен, в двух словах?

Смотрите сообщение в этой ветке за Воскресенье, 20 Апрель, 2008 13:19

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

Илья Ермаков писал(а):

Граф (мне более привычен термин "блок-схема") может быть хорош для описания микроскопических задачек

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

А способ проектирования и представления этих самых ансамблей в целом я вообще здесь не затрагиваю. Это отдельная песня...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 23 Апрель, 2008 16:46 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 82
Откуда: Москва
Илья Ермаков писал(а):
Цитата:
Илья Ермаков писал(а):
А что взамен, в двух словах?

Смотрите сообщение в этой ветке за Воскресенье, 20 Апрель, 2008 13:19

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


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

В чем достоинства?

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

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

Третье достоинство - возможность иметь блоки-таблицы, например, таблицы свойств, таблицы переходов конечного автомата и т.п.

Четвертое достоинство - текст блоков в несколько колонок. Например, колонки: идентификаторы, типы, комментарии. Работа парсера упрощается до предела (всю разбивку за него уже сделал программист). Взаимосвязи между любыми объектами (не только в смысле ООП) программы становятся доступными для автоматического анализа еще до какой-либо компиляции.

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


Илья Ермаков писал(а):

Цитата:

Граф (мне более привычен термин "блок-схема") может быть хорош для описания микроскопических задачек

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

А способ проектирования и представления этих самых ансамблей в целом я вообще здесь не затрагиваю. Это отдельная песня...


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 23 Апрель, 2008 18:06 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 631
Откуда: Россия, Орёл
Про достоинства не надо - и так ясно :-) И про упрощение трансляции, и про упрощение инструментария, если хранить исходное представление сразу в структурированном виде. Я о том, что мне уже не хочется после Дракона "загоняться" обратно в рамки линейных структурных конструкций, т.к. двумерные выигрывают по выразительности, часто - лаконичности, и, наконец, по верифицируемости (с точки зрения как раз таки структурных методов Дейкстры). Впрочем, возможно, сейчас просто нет понимания, о чём я... Собираюсь черкануть статью по этому поводу.

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

Согласен.

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

Нужно. Я просто намеренно не лезу здесь в этот вопрос :-)
Ну ладно, давайте чуть-чуть полезем.
Представьте, что "блок-схема" - это описание автономно функционирующего, изолированного (software-isolated) процесса. Как в Zonnon, Singularity, Composita, Erlang - и подобных перспективных моделей параллельно-распределённого программирования. Никаких общих переменных ("влияющих и зависимых, посмотреть, с чем связан идентификатор..."). Только обмен типизированными сообщениями по протоколам. (ну ещё вызов вспомогательных алгоритмов, но не имеющих состояния (обычная процедурная декомпозициия)).

Там, на уровне архитектуры, взаимосвязей этих процессов будет то самое "что-то, что объединяло бы микрозадачи". Но на уровне этой микрозадачи, при вот таком раскладе, что ещё нужно, кроме доработанного Дракона, наполненного типизацией и семантикой по типу Оберона?
На нём даже протокол взаимодействия описывать - заглядение. Короче, на все руки представление получается...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 23 Апрель, 2008 23:22 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 82
Откуда: Москва
Илья Ермаков писал(а):
Про достоинства не надо - и так ясно :-) И про упрощение трансляции, и про упрощение инструментария, если хранить исходное представление сразу в структурированном виде. Я о том, что мне уже не хочется после Дракона "загоняться" обратно в рамки линейных структурных конструкций, т.к. двумерные выигрывают по выразительности, часто - лаконичности, и, наконец, по верифицируемости (с точки зрения как раз таки структурных методов Дейкстры). Впрочем, возможно, сейчас просто нет понимания, о чём я... Собираюсь черкануть статью по этому поводу.


Я думаю, что одномерные и двумерные блок-схемы взаимно обратимы. Но для двумерных существуют всякие топологические проблемы, которые могут быть решены только дизайном вручную. Конструировать программу из блоков проще (и программисту, и системе программирования) в виде одномерной блок-схемы, не заморачиваясь взаимным расположением блоков, пересечениями линий, вылезанием за границы листа и т.п. Если же очень хочется двумерную блок-схему, то компьютер может накидать блоки, а уж потом программист будет таскать их туда-сюда, добиваясь выразительности, лаконичности и верифицируемости (последнее для меня непонятно в данном контексте - чем двумерные блок-схемы лучше для верифицируемости?). Нечто подобное уже существует в MS Access. Что касается языков - двумерных блок-схем, то они вовсе не ограничиваются Драконом, но успеха не завоевали.

Илья Ермаков писал(а):
Представьте, что "блок-схема" - это описание автономно функционирующего, изолированного (software-isolated) процесса. Как в Zonnon, Singularity, Composita, Erlang - и подобных перспективных моделей параллельно-распределённого программирования. Никаких общих переменных ("влияющих и зависимых, посмотреть, с чем связан идентификатор..."). Только обмен типизированными сообщениями по протоколам. (ну ещё вызов вспомогательных алгоритмов, но не имеющих состояния (обычная процедурная декомпозициия)).

Там, на уровне архитектуры, взаимосвязей этих процессов будет то самое "что-то, что объединяло бы микрозадачи". Но на уровне этой микрозадачи, при вот таком раскладе, что ещё нужно, кроме доработанного Дракона, наполненного типизацией и семантикой по типу Оберона?
На нём даже протокол взаимодействия описывать - заглядение. Короче, на все руки представление получается...


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

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

На возглас "заглядение" могу ответить только "любовь зла..." Ученые подтвердили, что в таком состоянии резко снижается способность к критическому восприятию действительности. Иначе бы никогда не было детей. Отрезвление приходит позже, когда уже поздно.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 24 Апрель, 2008 00:26 

Зарегистрирован: Среда, 14 Ноябрь, 2007 19:03
Сообщения: 5
Цитата:
Сергей, да нет как таковых никаких "блок-схем"... Что это такое, опишите внятно? Максимум, к чему придёте - это к тому, что задано некоторым стандартом ГОСТ-ISO.


Пазвольте... ЕСПД ГОСТ 19.002-80
Там много любопытного:Линии потока,канал связи,модификация и пуск-останов,а? какие паруса....

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


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

Цитата:
Отрезвление приходит позже, когда уже поздно.


Стал Ваня лазить
В папину кассу
Стал безобразничать
Красть денег массу!
Динь-динь-дон,динь-динь-дон,
Так звенят кандалы.
Так порой из-за баб
Погибают ослы


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 24 Апрель, 2008 10:34 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 631
Откуда: Россия, Орёл
Сергей Прохоренко писал(а):
Конечные автоматы и имитационное моделирование - это хорошо. Но это все-таки серьезное упрощение реальности, в которой состояния и время в общем случае не дискретны. Имитационные модели очень медлительны для систем реального времени. Поэтому я бы усомнился в том, что это единственно верное учение в моделировании систем и, соответственно, в программировании.

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

Кстати, автоматы не конечные. А вообще разные бывают. Физически любое вычисление = автомат (в головке машины Тьюринга). И никакого имитационного моделирования я в виду не имею, т.к. им не занимаюсь(лся).

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 25 Апрель, 2008 15:08 

Зарегистрирован: Среда, 17 Январь, 2007 03:59
Сообщения: 2
http://www.computerra.ru/blog/353727/


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 114 ]  На страницу Пред.  1, 2, 3, 4, 5, 6  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 0


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2008-2020, участники конференции «DRAKON.SU», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB