adva писал(а):
Был склонен принять точку зрения Донского, что алгоритм, это частный случай программы, но после Ваших слов, что неимперативные программы тоже можно рассматривать как разновидность алгоритма (что, думаю, вполне оправдано, там же тоже можно сказать, ПолучитьЭто, ПолучитьТо, а это уже вполне себе алгоритм), склоняюсь к тому, что эти два понятия тождественны.
Рассматривать неимперативные программы как разновидность алгоритма - как минимум, спорное предложение.
Я предлагаю идти по смыслу, а не по форме (также вниманию
albobin, который уже сказал кое-что из нижеперечисленного).
А
смысл состоит в том, что человеку нужно решить поставленную задачу.
Если для решения задачи пригоден инструмент "компьютер", хорошо. Пусть используется.
Если для решения задачи на компьютере требуется что-то новое, чего там в готовом виде нет (Ворда, или, к примеру, какого-нибудь MS Project недостаточно) - хорошо, займёмся тем, что принято называть "программированием".
При этом, как обычно, возможен вагон разных вариантов - потому что потенциальных исполнителей много, и они могут быть существенно разными. Для одного исполнителя достаточно декларативно описать существо задачи. Для другого исполнителя необходимо низкоуровневое целеуказание.
Заметим, что нигде мы ещё не дошли до такого понятия, как алгоритм. Оно слишком низкоуровневое по сравнению с процессом решения задачи в целом. И возникает необходимость в нём именно на соответствующем уровне.
Посмотрим на другие варианты человеческой деятельности.
Человеку нужно решить поставленную задачу.
Если у него есть готовые ресурсы (своё предприятие, подходящие услуги на стороне и т.п.) - хорошо.
Если нет - придётся заниматься организацией. Если невозможно делегировать организацию специалистам, придётся самому заниматься. Пусть так, хорошо.
Предположим, задача имеет свойство повторяемости. Тогда логично оптимизировать организованную структуру, сделав её устойчивой и малозависимой от внешних ресурсов (в т.ч. кадров). Для этого обычно целесообразно формализовать отношения и порядок действий в созданной системе.
Для начала возможно сделать это декларативно. Скажем, разделить зоны влияния и ответственности департаментов предприятия.
Но только внутри "департамента", аналогично рассмотренному выше примеру, уже может возникнуть необходимость применения понятий "исполнитель" и "порядок действий".
При этом одним из высокоуровневых языком формализации "порядка действий" является то, что принято называть алгоритмом. Напоминаю, что это всего лишь математическая абстракция. Абстракция, совершенно аналогичная дифференциальному уравнению какого-либо физического процесса.
Но не все физические процессы описываются дифференциальными уравнениями.
Равно как и не вся деятельность описывается алгоритмами.
Следовательно, я бы предложил такую классификацию понятий, используемых при описании деятельности:
1) задача => требуемая функциональность (инструмента) (отношение (М:М));
2) функциональность => способ её обеспечения (отношение (М:М));
3) способ => "программирование" или "организация" (отношение (1:М));
4) программирование (или организация) => декларативное, императивное (отношение (1:М));
5) императивное => алгоритм (отношение (1:М));
6) алгоритм => "низкоуровневый" исполнитель (отношение (М:М));
7) исполнитель => реализация алгоритма с нужной степенью детализации (отношение (1:М)).
"Вот так как-то!"
При этом следует учесть, что дальше п.3 обычно не продолжается - так как задача разбивается на подзадачи, которые ставятся как цели подсистемам. Происходит переход на более глубокий иерархический уровень.
И только когда дело доходит до более конкретного исполнителя (который, со своей стороны, как кирпичик, должен обеспечить функциональность организации), цепочка продолжается дальше. Причём она точно так же может иерархически углубляться дальше, рекурсивно повторяясь с п.1.
Если исходить из такого описания деятельности, то получается, что "программа" (как результат "программирования" или "организации" на уровне (4)) - более "высокоуровневое понятие", не тождественное алгоритму.
С другой стороны, программой также принято называть реализацию алгоритма (результат уровня (7)). В этом отношении алгоритм для программы выступает как математическая абстракция, как высокоуровневый язык формализации.
Возможно, для теоретических упражнений целесообразно оставить за термином "программа" только уровень (7) и применять сугубо в техническом смысле. Тогда для уровня (4) остаётся только "организация", что ли? Полагаю, что не во всех случаях этого будет достаточно.
Моё мнение таково, что не обязательно сейчас заниматься терминологическими изысками. Достаточно чётко представлять всю цепочку от 1 до 7, и действовать соответственно и целесообразно на каждом из этих уровней...
Вход
FAQ
Поиск
