OberonCore

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

Спасибо за беспокойство... Работ по гносеологии я прочитал достаточно... чтобы понять современное состояние этой "науки". Не впечатлило...
PS. Но мне бы хотелось еще раз попросить, обсуждать здесь те вопросы, которые подняты в теме, а не мои взаимоотношения с официальной "наукой".

А что .NET...
Как единая исполняющая платформа для ЯВУ "Эльбрус" был 40 лет назад - и гораздо продуманнее и сильнее.
Хотя бы потому, что изначально думали о поддержке классических языков разных парадигм (Алгол, потом Модула; Симула-Смоллток; функциональные и строковые типа СНОБОЛОВ). Ну и поддержка оборудованием, конечно.
См. Пентковского и Сафонова - занимательное чтение для инженера, как будто попадаешь в ближнее будущее, а не в прошлое. http://oberoncore.ru/library/start

Споры не всегда вызваны амбициями. Например, К.Томпсон придает большое значение нисходящему/восходящему стилю программирования.

Ну дык. Нисходящее мышление должно сходится с восходящим. Подбираем снизу средства для приближения на шаг "выше" к цели.

Это не вопрос стиля. Проектирование системы начинается не с выбора языка, но с архитектуры системы. Глядя на Оберон, например, я бы не взялся "увидеть" систему, сделанную на его основе (тем более, учитывая, что разных(!) систем... более одной).
Затруднения автора вполне понятны. Попробуйте "увидеть" болт через описания атомов, образующих кристаллическую решетку...

Одновременный анализ и синтез; индуктивный и дедуктивный способы мышления?

Ну, а по-другому, по хорошему, и не получится.

Без опоры на ноги (низ) не пойдёшь, но если не согласовываешь каждый очередной шаг с целью (верх), то не никуда не дойдёшь...

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

Если мы понимаем, что архитектура первична, то...
Ранее я уже говорил, что любые творения (программы и программные системы, в том числе) проходят пять стадий:
1. Анализ и моделирование;
2. Проектирование;
3. Планирование;
4. Реализация;
5. Использование.
Модель системы (эскизная, отвечающая требованиям, сформированным при анализе) создается на первой стадии. А подбор ресурсов (людских, денежных, материальных, программных) и планирование их использования (когда они необходимы, в каком объеме/количестве, на какое время и пр.) происходит на третьей стадии. Средства - это не цель... не средства определяют цель, но цель - средства. К средствам разработки, это относится в полной мере.

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

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

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

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

Вопросы технологичности выпуска серии продуктов тоже очень важны, для очередного проекта они могут многое диктовать "снизу" ещё до диктовки "сверху".

Если мы говорим о проектировании, то для создания больших систем, особенно динамичных (изменяемых во времени) одинаково плохо подходят оба метода: проектирование сверху-вниз (waterfall) и снизу-вверх (экстремальное программирование). Первый метод работает плохо потому, что для большой системы цикл проектирования является весьма продолжительным. Может статься, что требования к проекту изменятся раньше, чем закончится проектирование, и многое придется сделать заново... это снова большие затраты времени, а требования норовят снова измениться... Проектирование зацикливается, даже не доходя до кодирования... Это является серьезным препятствием (более подробно проблемы waterfall можно посмотреть в известной книге Ф. Брукса "Мифический человеко-месяц...").
Сторонники экстремального программирования заявляют: "Не надо проектировать вообще!". Они берут первую задачу и быстро реализуют ее. Заказчик доволен, команда разработчиков радостно потирает руки... Но... появляется вторая задача, в чем-то она соприкасается/пересекается с первой задачей. "Ерунда!", - говорят экстремалы - "сейчас мы сделаем рефакторинг и... обе задачи будут реализованы!". И, правда, обе задачи вполне успешно работают. Но задач в большой системе, не две, даже не два десятка, и даже не две сотни. А когда реализовано 10-20 задач, то рефакторинг длится неделями. Но подходе к сотне задач, на рефакторинг требуются человеко-годы... И проект снова начинает жить где-то внутри команды, так и не добравшись до пользователей.
Подход с середины, ничего позитивного в эту картину не вносит. Чтобы подняться на уровень вверх, надо его спроектировать, что значительно затратнее по времени, чем проектирование текущего уровня. Однако после окончания проектирования нам придется внести изменения и в реализацию текущего уровня, что тоже требует времени... При переходе к следующему уровню затраты (сил, времени, денег) возрастут на порядки.

Подумайте над тем, что Вы написали... Вы, ведь, говорите о том, что изменилась цель! И то, что раньше было целью, стало средством. Почему бы и нет... Но какое это имеет отношение к тому, что было сказано мной. Фраза, IMHO, остается справедливой и в этих условиях. Для того, кто создает средства разработки, эти средства - цель, для того, кто их применяет, - средство. Еще основоположники марксизма говорили о "производстве средств производства"...

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

Разумеется. И фраза остаётся справедливой.

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

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

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

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

Зависит от исполнителя.

Хотя в большинстве случаев пародия, нарисованная alexus'ом, наверняка и есть реальность, из общих (приматологических) соображений.

---
Кстати, я не поблагодарил за описание уровней.