Oberon space

1. Следование концепции неймановской архитектуре ДО САМОГО КОНЦА в языке программирования неизбежно приводят к динамическому формированию программы и ее выполнению... То есть как ни крути, а все равно Лисп получается...
Но в императивных языках этого как раз нет. А должно быть, если следовать принципу обобщения...
Но реально-то есть либо указатели на функции, либо некая сущность исполняемого типа. Например, процедурные переменные. Но с ОЧЕНЬ ограниченной функциональностью. 
2. В одну строку писать и не надо. Надо писать структурно. Здесь редактор автоматом и обеспечит нужный уровень читабельности.
Если вдумаетесь, то лаконичность написания ( в ущерб читабельности) возникла именно как необходимость набирать ручками каждый символ.
Если редактор берет на себя рутину представления, то и нафига лаконичность?

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

Вот тут большой вопрос.
ак и самолеты, языки бывают разными. Летчиков учат на учебных спмолетах, хотя принципы полета - одинаковые. И только опытные летчики летают на больших Боингах и/или боевых истребителях.
Поэтому использовать один и тот же "самолет" для школьников и для профи - БОЛЬШАЯ ошибка.

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

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

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

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

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

Там самое интересное не инструментарий, а процесс

1. Продукт хорош настолько, насколько хорош план для него.

В бортовой группе шаттла, около трети процесса по написанию ПО происходит до того, как кто-либо напишет хоть одну строку кода. НАСА и группа из Локхид Мартин достигают соглашения в самых подробных описаниях, касательно всего, что новый код должен будет делать – и затем они фиксируют достигнутые договоренности на бумаге с такой скрупулезностью и точностью, которую обычно можно наблюдать при ксерокопировании. Ничто в спецификациях не может быть изменено без согласия и полного понимания с обеих сторон. И никто не изменит ни одной сроки кода без спецификации, подробно описывающей это изменение.

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

А почему ссылка не открывается?

Цитировать

Я не понимаю что значит "ничего". Вот у меня 8ми битная переменная. Значение у нее текущее 255, я инкрементирую её на единицу -- что значит "ничего"? То есть 255 и останется? Ибо если оно вдруг обнулится, это будет очень даже чего.

Пример был на oberoncore.ru. Сейчас уже не найду. Происходит, естественно, переполнение в 0.

Вот это как раз НЕ естественно. Вообще, если исходить из того, что описание языка - это есть спецификация некоторой виртуальной машины (а по Вирту вроде именно так и есть), то спецификация должна описывать ВСЕ.В том числе и все операции в деталях.
Либо должно быть явное указание на то, что данная операция отображается на реальную операцию "железа".
Ведь с памяться в описании КП написано совершенно явно - должна быть сборка мусора, иначе это - не КП.
При сертификации компиляторов Ады поступили так же: компилятор ДОЛЖЕН удовлетворять определеннным свойствам-качествам, иначе это - не компилятор Ады.