OberonCore

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

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

Но с другой стороны, это действенная альтернатива динамической типизации в Python (что до этого также помогло мне уменьшить объем кода для решения задач со сложными структурами данных и их обработкой), вопрос типизации переносится в compile time.

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

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

Не пора ли в BlackBox ввести шаблоны классов и процедур, чтобы получить возможность аналога STL?

Шаблоны в BlackBox, а, точнее, в Component Pascal, никто добавлять не станет. Большей части наиболее активных его пользователей они не особо нужны.

Со своего опыта могу сказать, что для таких структур данных, как списки и ассоциативные массивы шаблоны точно являются излишеством и ручное написание может занимать действительно много времени только в том случае, если в своё время в школе этому не обучили, зато вместо этого выработана стойкая привычка работы с теми же шаблонами или динамической типизацией. Динамическая типизация имеет недостатки в поиске ошибок, а работе с шаблонами тоже надо учиться. Мне приходилось сталкиваться со случаями, когда из-за неочевидных деталей задействование шаблонов в С++ потребовало больше времени, чем создание самопальных структур, в которых всё перед глазами.

Если хочется использовать готовые структуры на все случае жизни, проще всего соорудить генераторы кода в КП.

У каждого свой путь, и если всё же шаблоны воспринимаются как что-то необходимое, то лучше перестать мучать себя КП и использовать то, что Вам лучше подходит.

А поиск по задаваемому позже критерию тоже руками предлагаете городить?

Генератор текста - это и есть реализация шаблонов. Только стоит еще добавить некоторые проверки.

Работа с шаблонами в том же С++ подразумевает доступность используемых алгоритмов в виде исходного кода. При наличии исходного кода добавить нужный критерий не составляет существенной проблемы. Тут принципиальный вопрос лишь в форме работы с исходным кодом. Если же критерий объёмный, или скорость некритична, то он вполне может быть закодирован в ООП стиле. Если скорость критична, то альтернативы собственной реализации, учитывающей все ограничения задачи, нет

Да, но с точностью до наоборот - шаблоны - это частный случай генерации кода. В общем случае генерация кода может быть мощней.

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

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

Опять какие-то странные, хм, эмоции.

Напишите поиск с критерием в виде процедурной переменной -- и на здоровье передавайте её потом поиску.

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

Шаблоны - это похоже совсем не гуд, используйте нормально методы работы с абстрактными приемами, POINTER TO ANYREC и т.п. при написании универсальных алгоритмов. У Петра было точно несколько примеров работы с универсальными сортировщиками. Поглядите подсистему Lists, кажется.

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

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

А Вы встречали более-менее полное описание этих проблем? Мне это интересно.