Сидя в раздумьях, пришел к интересным мыслям:

1. С++ — это на самом деле не столько язык, сколько инструмент для создания ваших собственных языков. Его элегантность заключается отнюдь не в простоте (слова С++ и простота режут слух своим явным противоречием), а в его потенциальных возможностях. За каждой уродливой проблемой прячется какая-нибудь умная идиома, изящный языковой финт, благодаря которому проблема тает прямо на глазах. Проблема решается так же элегантно, как это сделал бы настоящий язык типа Smalltalk или Lisp, но при этом ваш процессор не дымится от напряжения, а на Уолл-Стрит не растут акции производителей чипов памяти. С++ — вообще не язык. Это мировоззрение или наркотик, меняющий способ мышления.

2. Ревнители частоты языка часто нападают на С++. Они полагают, что высшее достижение современной цивилизации — язык, построенный исключительно из атомов и скобок. По мнению этих террористов от синтаксиса, если простую переменную с первого взгляда невозможно отличить от вызова функции или макроса — это вообще не язык, а шарлатанство для развлечения праздной толпы. К сожалению, теория расходится с практикой. В реальной жизни толпа платит лишь за то, чтобы видеть языки, в которых разные идеи выглядят по-разному. «Простые и последовательные» языки никогда не пользовались особым успехом за стенками академий, а языки с блочной структурой овладели массами. Стоит ли этому удивляться? Ведь компьютерные языки приходится изучать и запоминать, а для этого используется то же серое вещество, с помощью которого мы изучаем и запоминаем естественные языки. Попробуйте-ка назвать хотя бы один естественный язык без существительных, глаголов и скобок! Я бы не рискнул. Все наши познания в лингвистике говорят о том, что эти «плохие» особенности только ускоряют изучение компьютерного языка и делают его более понятным. i++ во всех отношениях действительно понятнее, чем i:=i+1, а x=17+29 читается лучше, нежели (setq x(+17, 29)). Речь идет не о строении компьютерного языка, а скорее о нашем собственном строении. Все уродства С++ — это в основном наши уродства. Когда вы научитесь понимать и любить его странности, когда перестанете беспокоиться о математической стройности, будет сделан ваш первый шаг к достижению элегантности в С++.

Тут некто Alv высказался, что в его любимом C++ ручное управление памятью, что есть для него неоспоримое преимущество.

На этот вопрос у меня нет 100% твердой точки зрения, так как я и сам недавно был сторонником ручного управления. Посему вопрос в следующем:

Представим себе компьютер с большим объёмом оперативной памяти. Существует ли какой-нибудь класс прикладных (не системных!) задач, для которых ручное управление памятью было бы существенным для быстродействия? Пусть по другую сторону у нас есть GC, который работает любым удобным для этой задачи способом (из более-менее известных и популярных). Т.е. программист волен написать свой GC, если надо и язык позволяет.

А то ведь эти любители ручного управления памятью сами городят в каждом проекте свои смартпоинтеры с подсчетом ссылок и аллокаторы и уверены, что это якобы лучше, чем GC или обычный malloc/free

По данным сайта lisp.ru, утверждение, что лисп является медленным ЯП, относится скорее к мифам. Приведу цитату из статьи про Common Lisp (http://lisp.ru/page.php?id=4):

5. Лисп работает очень медленно. Честно говоря, я тоже так думал. Но еще лет десять назад, под влиянием нескольких публикаций о реализации Лиспа на Бейсике, я написал небольшой (но полностью функциональный и расширяемый) интерпретатор Лиспа на языке Паскаль для ДВК-3. И что вы думаете? Мой доморощенный Лисп работал на вычислительных задачах быстрее, чем родной Бейсик фирмы DEC!

Рекорд бейсика по производительности побит. И это при отсутствии компилятора для лиспа:

6. Для Лиспа нет компилятора. Вообще то, это так, поскольку для серьезных Лисп-программ полная компиляция противопоказана - ведь в этом языке единство кода и данных поддерживается на все 100% и зачастую программа синтезируется непосредственно во время выполнения. Но что касается использования компилятора для генерирования промежуточного кода, ускоряющего последующую загрузку и выполнение программ, а также защиту исходного кода программ, то такие решения есть, и входят в состав стандартных дистрибутивов (вернее сказать, встроены в саму среду Лиспа).

Синтезируем и выполняем программу в рантайме, господа! Причем, скорее всего, непосредственно у себя в голове.

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