DRAKON.SU

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

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

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

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

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

Я пришел к тому же выводу: алгоритма без исполнителя - не существует.
То, что мы сейчас обычно называем алгоритмом - это на самом деле ПРОГРАММА для некоторого исполнителя, записанная в терминах его системы команд.
Невозможно объяснить разницу: вот это алгоритм, а это - программа.
И универсального исполнителя - тоже не существует.

Отсюда же, между прочим, и несистемность "бизнес-процессов"... поотому, что имеются в виду как исполнители системы с "жёсткими связями для алгопроцессов техопераций"... тогда как уже у Усова система с мягкими связями: viewtopic.php?p=77646#p77646 ... что позволяет её представить, например, так: viewtopic.php?p=74506#p74506.

И вот у Закревского вроде связи... жёсткие.

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

Да, читал с начала. И сейчас еще раз просмотрел. Мне очень понравилось. Очень серьезная заявка. Очень серьезная аргументация. Очень серьезная и аргументированная дискуссия.

Эта дискуссия может служить образцом для подражания.

Вот если бы у нас все дискуссии на форуме проходили в таком ключе, было бы просто отличнно.

Огромное спасибо Вам, Алексей Николаевич, за то, что Вы открыли эту замечательную тему.

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

ВЫВОД

Прекрасная тема. Прекрасная и глубокая дискуссия.
Спасибо Алексею Донскому.

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

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

Что-то мне подсказывает, что при разработке Бурана ДРАКОН использовался как средство общения между программистами и железячниками, причем направление потоков было двусторонним. Конструкторы говорили: "Сделайте так". Программисты, помучившись, предлагали что-то изменить. Конструкторы рассматривали...

В общем, итерационный процесс уточнений. У каждого участника было свое игровое поле, а ДРАКОН являлся площадкой для общих встреч. Это как игра в футбол: политики против журналистов.

Не сможет ДРАКОН стать универсальным для всех. Это как с любым инструментом. Имеются асы, виртуозы, а есть простые исполнители, которых подавляющее большинство.

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

Именно... Как и другим служащим "Министерства Правды" (коему паттерну хотя бы время от времени и здесь следуют те или иные ), Резуну делать рекламу не стремлюсь... но что ж делать, если под его псевдонимом публиковались и талантливые литобработки примеров из реальной оргдеятельности, подобных которым найти где-то ещё трудно...

Конкретно - в "Аквариуме" читали, как добывающие находят новые темы для работы?.. Каждый обязан не реже установленного предлагать уже разработанную, причём в свободное время от исполнения техопераций по уже принятым в работу темам (как своим, так и чужим)... Вот тут как раз видно, как работает "поисковый техпроцесс"... тот, который время от времени заканчивается обращением к Навигатору (Младшему Лидеру), чтобы "рассказать ему о...". Причём работает в общем случае не над одной идеей темы... и по целесообразности вместе с техоперационными (добываешь/обеспечиваешь где-то - заодно примечаешь на перспективу etc)... И понятно, что за этой совокупностью процессов стоит ещё координационный...

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

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

1. Согласен, вчера это было именно так.

2. Сегодня ситуация изменилась. Возникла настоятельная необходимость четко разграничить два понятия: 1) алгоритм, 2) программа.

3. Такое разграничение можно рассматривать как новую постановку проблемы.

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

5. Язык Дракон намечает путь к решению этой проблемы.

6. Геннадий Тышов разработал инструментальную систему ИС Дракон и указал двухэтапный метод разработки, при котором на первом этапе создается алгоритм, а на втором — программа. Это означает, что уже имеется практический (и хорошо опробованный) задел для решения проблемы.

7. Назовем эту проблему "проблемой разграничения".

8. Прошу критиковать постановку проблемы (проблемы разграничения).

9. Прошу предлагать решение проблемы (проблемы разграничения).

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

Не согласен.
В любой программе присутствуют
1) простые исполняемые (исполнителем) действия;
2) управляющие (исполняемые исполнителем же, но влияющие на его собственную работу) действия

И то, и другое присутствует в диаграммах Дракона.
Дракон - это средство представления для человека.
Можно представить ту же схему закодированной в виде последовательности восьмеричных команд Минска-22
Вопрос в исполнителе.
Вполне можно написать интерпретатор, который будет интерпретировать схему Дракона. И это будет программа для этого исполнителя.
Вспомните РТК-комплекс!
Не говоря уж о том, что схему может непосредственно интерпретировать человек.

Поскольку по существу это есть одно и то же, то постановка вопроса бессмысленна, и даже вредна.

ДРАКОН, как язык, более всего подходит для исполнителя "человек", как выше справедливо отметил Валерий Лаптев.

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

С другой же стороны, этот алгоритмический слой, на мой взгляд, не может претендовать на монополию названия "алгоритм". Потому что:

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

2) В императивной парадигме любая программа представляет собой алгоритм.

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

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

4) Любой алгоритм (программу) можно показать в РАЗНЫХ представлениях, и с разной степенью детализации.

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

6) Отвлекаясь от программирования, заметим, что функциональная деятельность ЧЕЛОВЕКА алгоритмизуется достаточно хорошо, и это прекрасная ниша для упражнений с ДРАКОНом. Тем не менее, программой этот алгоритм быть не перестаёт (ибо есть одно из возможных представлений, скажем, должностных инструкций - для исполнителя "человек").

Выводы:

- искусственное разделение понятий "программа" и "алгоритм" нецелесообразно ни со стороны программной инженерии, ни со стороны "инженерии социальной";

- естественнонаучное различе их заключается в том, что алгоритм есть частный случай, одно из возможных представлений программы;

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

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

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

Уважаемые коллеги!

1. В литературе я НИ РАЗУ не встречал утверждение, что алгоритм и программа — это одно и то же. Что эти понятия тождественны. Никогда и нигде я такого чуда природы не видел.

2. Если кто-либо располагает такой информацией, просьба выложить точную цитату.

3. Я предполагаю, что такая цитата вряд ли существует в природе.
Но если я ошибаюсь, что ж всяко бывает — будем читать и думать.

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

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

6. Не исключено, что дело обстоит гораздо хуже. Вполне возможно, что данная проблема в науке серьезно еще воообще не обсуждалась. Я не знаю.

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

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

Ещё раз. Они не тождественны.

"Понятие алгоритма относится к первоначальным, основным, базисным понятиям математики." - сказано в Википедии.
И это правильно.

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

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

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

И да, я продолжаю настаивать, что программа (не компьютерная программа, а программа вообще, в т.ч. программа деятельности человека) есть более общее понятие. Тогда как алгоритм может составлять часть программы, описывая деятельность в императивной форме.

Дмитрий Владимирович, мне понравились Ваши слова.
Вы написали кратко, но, как мне кажется, копнули очень глубоко.

Я понял Вашу мысль так:


Правильно ли я понял Вашу мысль? Если нет, подскажите, как надо исправить, чтобы было правильно.

Ну эти правила можно отнести и к программе тоже.
И понимаемость крайне желательна для любого документа - иначе он просто становится бессмысленным.

Конечно, и у программы действий может быть читатель.
Читатель - посторонний человек, пришел - прочитал - ушел.

Я бы сформулировал так:

Алгоритм - последовательность действий.

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

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

Не могу согласиться. Автор алгоритма (и программы) — это читатель. Причем читатель номер 1. Это ключевая фигура.
Неправильно автора считать посторонним человеком.

================================

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

Примерно так кончил жизнь Луций Анней Сенека.
Хотя Сенека, конечно, (во всех остальных случаях) дураком не был.

2 Алексей Донской:

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

2 Валерий Лаптев:

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