OberonCore

Не знаю, что наворотили в Windows, но тот простой, что Вы имеете ввиду, является ещё и примером недостаточности некоторой простоты для того чтобы собрать всё, что потребуется. Поэтому, к примеру в GNU/Linux есть ещё SELinux и AppArmor. Является ли это в сумме более простым по сравнению с Windows?

Вот она, дилемма Оберона Либо мы сокращаем ошибки на входе, контролируя разнообразие. Либо же отпускаем вожжи на входе и получаем бесконечное разнообразие на выходе.
А чтобы справиться с бесконечным разнообразием, нужна бесконечная энергия. Где ж её взять?

Не могли бы вы указать на код, абстракции я не нашёл. Как минимум каждой сортировки реализовано, по 2 раза. Для списка и массива.



Чем шаблоны не библиотека? Статически линкуемая библиотека, можно так сказать. Вот оно расширение через библиотеки.

Вот смотрите, берём язык с шаблонами и без. Почему в обероне преобладает односвязный список? Правильно, просто проще написать. Идём дальше.

Нужен чуть сложнее список, к примеру с добавлением в конец. Что для этого нужно. Как минимум создать переменную, которая будет указывать на последний элемент. Глобальная переменная вроде как не хорошо. Значит, нужно создать структуру список, в которой будут поля, первый, последний и следующий, а возможно ещё и предыдущий и указатель на данные.

Теперь просто добавить элемент не получиться. Нужно создавать 2 записи, для списка. плюс ко всему для каждого типа нужно повторить действия. Чем здесь помогает минимализм оберона не понятно. Я уже не говорю о функциях для списка, таких как добавить в конкретный узел и т.д Одна рутина.

Та же очередь. Можно создать через список или массив. Или список массивов. В языке с шаблонами можно написать все 3 реализации, с одним интерфейсом и в нужном случае использовать ту реализацию, которая будет больше подходит под задачу. Шаблоны помогут избежать рутины.

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

И полно других, разных структур данных которые не так просты в реализации. И мне непонятно, как кп или оберон поможет мне не дублировать код. Как избежать выше изложенной рутины при программировании кп?

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

Если сравнивать по возможности. Оберон это кирпичи и мастерок. Более нафичёванные языки, это панели из которых строят дома. Пока на обероне ваяют на кирпичах, на других языках уже собирают 2 этаж.

Вообще, практика показывает следующее:

- для задач "бизнес-типа" (БД, GUI и т.п.) структуры будут из динамических объектов. И вполне достаточно набора контейнеров для ANYPTR. Какого набора контейнеров достаточно такому прикладнику - практика же, опять же, показывает, что JSON/JavaScript-подобного (map + vector).
Никаких шаблонов для набора ANYPTR-контейнеров не нужно.

- для вычислительных и системных задач настолько сильна специфика задачи, что лучше "велосипедный список" на конкретный случай.
Кроме того, сегодня для уймы задач становится достаточно разных линейно-списковых структур (где раньше нужны были, допустим, деревья).
В лекциях эксперта по СУБД из Яндекса Ильи Тетерина справедливо замечено, что сегодня что-то сложнее связного списка и skip-list-а вообще часто нет смысла использовать.

Нужна железобетонная типизация.



Для нынешних процессоров, список это тормоз, так как чтение из памяти дорого. Лучше массив или список массивов.

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

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

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

А вы попробуйте что-нибудь полезное изобразить на Обероне или КП. Ну, реально полезное. Не надо рассуждать впустую, сделайте что-то РЕАЛЬНОЕ, что работает и приносит пользу. И вот когда это ваше изделие заработает, вы придёте на форум и скажете, например, так: коллеги, я потратил кучу энергии, а с дженериками мог бы в десять раз меньше. Или так: коллеги, дженерики важны, но не настолько, чтоб это можно было всерьёз обсуждать.

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

С освоением всё более сложных структур данных и алгоритмов. Прихожу ко мнении, что STL не панацея.

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