Владимир Паронджанов писал(а):
В книге "Как улучшить работу ума" я впервые подробно изложил идею языка ДРАКОН.
Там же я попытался объяснить, как алгоритмический язык (язык представления процедурных знаний) связан с идеей улучшения работы человеческого ума.
Поводом для этой темы послужил перепост Ильи Ирмакова из Хабра, который я цитирую ниже:
viewtopic.php?f=27&t=4278Илья Ермаков писал(а):
http://habrahabr.ru/post/170443/Цитата:
Чарльз Петцольд обратил в своей замечательной статьей внимание на то, что Visual Studio принуждает к стилю разработке снизу-вверх, что не очень вяжется с потребностями бизнеса.
Visual Studio (с инструментом повышения производительности или без) делает сложной (но не невозможной) разработку «снаружи-внутрь».
Первый раз встречаю выражение типа:
разработка
снаружи-внутрь.
Всю (сознательную) жизнь разработок в области автоматизации производства
с управлением на компьютерной основе (где-то с начала 70-х)
знал и применял направления разработок:
сверху вниз,
снизу вверх и
от середины вниз и вниз.
Выражение "от середины вниз и вверх" впервые встретил
в публикациях команды академика Глушкова В.М. в области АСУ.
С тех пор сознательно не заморачивался жестким требованием одного подхода (сверху или снизу).
Да и реально в разработках, хочешь-не-хочешь, параллельно работают все три эти подхода.
Но
ведущее направление разработок
сверху вниз:
-- как обязательное условия для изначального обеспечения системной целостности представлений;
-- как средство (одно из средств) борьбы со сложностью и т.п.
Но оно сопровождается гибким переходом на другие направления по мере необходимости.
А в изложении системного описания разработанных объектов автоматизации
уже обязательно (достаточно жестко) принимается направление сверху вниз.
Но и здесь иногда случается заглянуть вперед (вниз) - для ясности изложения.
---------------------------
Это относится (точнее относилось при коммунизме) к общим (системным) разработкам
технологических автоматизированных (и роботизированных) систем и подсистем АСУП и АСУТП.
При этом сначала стихийно, а затем сознательно пришлось осваивать
алгоритмизацию разработок:
1
Для
алгоритмического описания работы
технологических автоматизированных систем :
здесь до сих пор большие проблемы.
2
Для
алгоритмического описания программных разработок - совместно с программистами:
-- убедился, что заставить программиста писать алгоритмы - это только с ревом, со слезами,
причем "много шуму, мало шерсти", как сказал черт, пытаясь постричь кошку;
-- позднее стал понимать, что параллельно программисту должен работать специалист по программной документации
(это разные культуры - генерить исходные коды и программную документацию);
-- позднее это стало увязываться с работой
системного аналитика в автоматизации проектирования программных систем.
К сожалению, специальности системотехника и системного аналитика исчезли из обучения,
сейчас идут бакалавры (недоученные инженеры) широкого профиля,
и часть из них выходит на магистров - с защитой не проектов, а магистерских диссертаций (недоученных ученых).
Куды котимся?
-----------------------------
В разработках программных систем использовал и использую все три направления.
Не очень понятно сетование на Visual Studio типа:
Цитата:
Visual Studio принуждает к стилю разработке снизу-вверх
Для
разработок программ сверху вниз на любом уровне используются заглушки вызовов подпрограмм и любой программной единицы:
пустые подпрограммы или подпрограммы с выводом сообщения о вызове.
И в принципе можно сходу вести отладку это программной единицы.
-----------------------
Более того, от студентов, которые мне что-то там программируют,
на любом уровне требую:
1)
начинать с пустого алгоритма типа:
Ai = ()2)
с соответствующего псевдокода - под конкретный язык, типа:
alg Ai begin end
alg Ai() { }3)
с выходом на исходный код и его отладку
4)
с последующим пошаговым наполнением алгоритма и его программной реализации.
5)
И с самого начала - пошаговая визуализация алгоритма:
большая работа, но хорошая отладка, например, блок-схемы алгоритма.
Но это все - только в идеале.
Достаточно редко попадаются работящие и инициативные в этом отношении студенты.
Основная масса тянет до упора (под конец семестра) - что-то принесет и слава богу:
идет продвижение по мелочам, но по широкому фронту (в общей массе).
Все это связано с тем обстоятельством, что параллельные алгоритмы и программы
у меня пока идут вставками в разные другие другие дисциплины.
===================
Но
в личных программных разработках -
все это не так, все не по таким красивым правилам.
Такова сель-ави.
Увы мне.
Точнее так только в разработках примеров программной реализации параллельных алгоритмов
на разных языках программирования:
как примеры к структурной теории параллельных алгоритмов.
Сейчас есть личные программные разработки только по простым учебным средам
по автоматизации схемных построений алгоритмов и временных диаграмм
(и сводные комплекты примеров с динамическими мнемосхемами объектов управления):
все это делается в темпе (второпях), на колене, без проектирования.
Но очень внимательно и точно, по-возможности, комментирую исходные тексты:
не раз проверял - позднее, на доработках, когда все позабыл, это помогает разобраться и вспомнить, что хотел.
Такова реальная диалектика параллельной теории и практики
(в личных масштабах).
==================
Но концепция программирования "
снаружи внутрь" хороша.
Это не просто сверху вниз.
Здесь что-то еще теплится.