Вот тут читаю про Active Oberon и про его вшитые в язык примитивы синхронизации.

А чем они лучше, чем вызовы соответствующих примитивов ОС? Портабельность нужна? Ну дык заверни в макросы.

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

Тут язык приспосабливается ко мне, а не я к языку.

Польза — не приходится тратить время на решение ненавистных мне "проблем инструмента", когда что-то не работает потому, что, казалось бы, ясно описанное поведение тула имеет какие-то побочные эффекты, или что-то не работает точно так, как надо, или откуда-то летят непонятные exceptions... проблемы мерзки, потому что не имеют отношения ни к творчеству, ни к архитектуре, ни к чистоте кода, ни к следованию парадигмам, ни к достижению результата.

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

Потому я пользуюсь языком Си, как тулом, который не создает проблем.

Сидели как-то с товарищем (вместе работали несколько лет) на Платформе-06 на одном из семинаров. Там зашла речь о каких-то дополнительных тулах для Джавы и Шарпа, причем чуть ли не о тулах для просто тупого чтения кода . Я товарищу — "вот обрати внимание. Джавиаторы и шарпники говорят — о тулах. Уже полчаса — о тулах. О том, как побороть ту или иную кривизну в этом туле или в том. А где их реальные задачи? если у них такие сложные тулы, что решение проблем с тулами занимает столько времени — то когда у них остается время на решение реальных задач?". При этом мы оба имеем немалый опыт программирования на Си++ и ATL, с вручную написанными IDL файлами (их поддерживать проще). Эти тулы не создавали нам проблем — при разумном паттерне использования и в проектах, где цена баги невысока. Время, затраченное на изучение ATL — единицы дней. Дальше — берешь и юзаешь, благо исходник есть. Если надо — copy-paste одного из тамошних классов, отпатчил под себя и вперед.

Тул не создает проблем. Тул не имеет ограничений.

Не зря, видимо, ни один кернел (то, где реально нужна многонитевость) не написан на Active Oberon, зато аж три из известных написаны на Си.

Все то же самое относится к Си++ RTTI. MFCшный макрос DECLARE_DYNAMIC лучше.

Все то же самое относится и к attributed C++. Что мешает написать IDL файл руками, чем потом разбираться, а что это там нагенерила эта микрософтная поделка, у которой к тому же есть limitations?

Все то же самое относится и к OpenMP. Зачем мне объявление лока через #pragma, когда я могу явно лок объявить и его захватывать? Скажете, меньше кодировать? ага, зато потом при отладке утонешь в дедлоках, и — увы и ах — при отладке неизбежно придется смотреть на ассемблер, сгенеренный компилятором ради реализации OpenMPшных прагм.

Зачем это все? Чтобы самоудовлетворить авторов? К чему это "повышение уровня абстракции", если потом все равно придется лезть вниз under the hood?

Может, стоит какой-то оптимальный для себя уровень абстракции выработать?

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