>"Какой ширины int", а точнее, о размерности и точности вычислений, понимать
>полезно всегда.

Здесь я предпочту остаться при своем мнении. Если я "мыслю объектами", внутреннее представление числовых данных меня заботить не должно. Мне даже не нужно беспокоиться какого они типа - int, float, или что-то еще, как, например, в том же Lua, где для всех числовых данных есть один тип number.

>Разумный человек никогда не будет
>работать с фиксированными и неавтоматическими буферами в высокоуровневых
>участках кода.

В высокоуровневых языках человек работает с _данными_, а не с какими-то буферами. Высокоуровневые языки для того и существуют, чтобы максимально абстрагировать программу от ее внутреннего представления в компьютере, и максимально приблизить ее к идее, которая у программиста в голове. Если я добавляю свои объекты в хеш-таблицу или дерево, зачем мне знать какие при этом буферы памяти выделяются и как они потом будут утилизированы?

>Вообще-то boost как таковой - это область бета-тестирования библиотек, которые
>претендуют на переезд в состав STL. И нередко там оказываются явно конкурирующие
>
>друг с другом модули, которые все разом заведомо никогда не попадут в
>стандарт.
>
>Поэтому если при разработке программы требуется некий примитив, сперва следует
>смотреть в STL, и только затем, если ничего подходящего там нет -
>в boost.

Ну вот. То вы называете Буст "правоверным", то теперь оказывается, что это - лишь некая "область бета-тестирования библиотек, которые претендуют на переезд в состав STL". Кстати, и STL не многим лучше. Это ведь библиотека, а не часть языка, тут от наследия Си никуда не денешься. А следовательно, и работает она не так эффективно, как если бы все эти абстракции поддерживались бы самим компилятором. Соответственно и без зоопарка итераторов обойтись было нельзя...

>
>В языке, похожем на естественный, операции должны определяться словами, а не набором
>
>мусорных символов :)
>

А разве в естественном языке вы никогда не используете "мусорные" слова? Или, по крайней мере, выразительные идиомы? :)

>А жёсткий и подробный синтаксис был бы полезен в Perl для того,
>чтобы упростить
>чтение чужого кода. Perl часто применяется при автоматизации задач администрирования,
>и понимать кракозябры, набросанные впопыхах очередным гениальным админом, бывает
>крайне утомительно. Никакой обфускатор часто не требуется :)

Ну, с этим, может быть, можно и согласиться :)