Скажем так - реальной эффективности. Средтва C++ позволяют писать обобщенные эффективные алгоритмы, которые потом специализируются конкретным представлением данных. Что бы написать эти же алгоритмы на обычных языках (типа Oberon) надо делать очень много писанины, что вызывает желание сократить код в ущерб эффективности. И желание совершенно справедливое - большой код сложно отлаживать.
Но разработка и эффективная реализация обобщенных алгоритмов доступна не многим.

То что C++ сейчас пихают везде, где непоподя - истинная правда. Даже обвязки на бейсике особой роли не играют - ядра большенства продуктов все равно пишутся на C++ (а они составляют значительную часть бюджета). Но замена ему не виртовские поделья. Есть, например, язык OCaml, который лучше бы подошел для 90% все плюсовых программ. Но он, к сожалению, не подходит для real time. Для реального времени еще не разработано удачного языка, поэтому использование Pascal или Oberon оправданно. Но кричать что виртовские языки - панацея для индустрии ПО по меньшей мере неправильно.

Но языки Вирта удобные и ясные.

По мне так синтаксис чистого C (не C++) более понятен - из-за его компактности.
Есть очень экзотические языки - например в K функция умножения матриц выглядит так { +/'' x *\:/: y }. Для неподготовленного человека выглядит совершенно непонятно, но для привыкшему к этому языку понять ее легче, чем разобраться в эквивалентных 5-6 строчках любого процедурного языка.

Конечно, компактный синтаксис C облегчает написание нечитабельных программ, но ни кто не заставляет этой возможностью пользоваться. Для того, что бы она не реализовалась случайно разрабатываются различные style guide, в которых описывается как писать читабельные в определенном кругу программы. И этот подход весьма эффективен - благодоря четко определенному стилю исходники ядра FreeBSD читаются очень легко.

Нравится так нравится. А я Си терпеть не могу. И не могу понять, зачем мне им пользоваться. Уверяю, что я бы не пользовался и языком К.

Пропогандировать C я не буду (ибо действительно специально переходить на него смысла нет). Но на счет языков типа K (на самом деле происходящих от APL) Вы зря отказываетесь. Чем меньше код программы, тем меньше возможность там сделать ошибку. Особенно это актуально станет, если потребуется перепрограммировать ДПЛА в полевых условиях (ведь всего заранее не предусмотришь).

>...Чем меньше код программы, тем меньше возможность там сделать ошибку

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

В традиционных языках большой объем кода возникает не из-за избыточности (замени где-нибудь + на -, ни кто и не заметит), а из-за излишней детализации. Так при программировании циклов по массиву очень легко ошибиться на границе (не обработать последний элемент или выйти на пределы выдегенного массива). А поддержка работы с массивом целиком в языке не просто сокращает объем кода, но и уменьшает возможность сделат ошибку. Но не все сводится к обработке массивов. То есть язык должен содержать средства разработки обобщенных механизмов. C++, в отличии от языков Вирта, такие средства содержит, хотя и реализованны они до предела криво.

>...не обработать последний элемент или выйти на пределы выделенного массива

Для этого надо быть ИДИОТОМ.
Паскаль на них не рассчитан. Это непредсказуемо.

{+}

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

Оберон защищает. Прогресс идёт.

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

Процедуры. Или уже неловко пользоваться такой элементарщиной?

:)

Языки APL, K, Haskell, Ocaml, Cyclone - чем не другие пути?

Прочитал введение в язык J от dr_klm@lj.

Что я могу сказать. Лаконичность впечатляет, конечно.

Но по-моему, над этим подходом ещё работать и работать напильником :) А так заманчиво, не спорю, - программу на одном экране иметь. Напоминает китайское иероглифическое письмо.

Настораживает то, что алфавитное посильнее оказалось. Ну да это в "естественных" языках, где смысл текстов похитрее устроен. Может с языками программирования выйдет иначе. Надо копать.

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

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

Касаемо паскаля -- он (в отличие от си) отнюдь не везде последователен именно в своей основе.
Например, почему в нём сосуществуют два разных подхода к блокам операторов? Один представлен конструкциями repeat-until или case-else-end, а второй if-then-begin-end-else-begin-end или for-to-do-begin-end. То, что я пометил курсивом, в принципе можно было бы и выбросить
Другой пример -- определение записи (record) с вариантами. После простоты аналогичных сишных конструкций паскалевский вариант показался странной пляской с бубном вокруг неизвестно чего.
Третий пример -- вывернутое на изнанку условие выхода из цикла repeat-until, эта конструкция всякий раз заставляет немного больше задуматься.

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

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

Все остальные различия -- дело вкуса, о котором не спорят и привычки. Вам не нравятся все эти скобки { } и всякие ++= ? Но согласитесь, среднестатистический бухгалтер, имеющий дело в основном с суммами и дробями (обозначениями для него привычными), придёт в ужас раскрыв на середине какой нибудь учебник высшей математики. Однако это не делает язык математиков (все эти интегралы-дифференциалы, пределы-матрицы) плохим.

На сколько я могу судить по дискуссии, Вы защищаете свою личную привычку к паскалю, не более. но делаете из неё далеко идущие выводы. Ну да был прав тот, кто сказал, что: "Человек есть мера всех вещей" (Кажется Протагор)

Многоеиз тОго, что Вы отметили, учтено в Обероне. А "++" всё равно маразматичны. И язык высшей математики здесь ни при чём.

> Что бы написать эти же алгоритмы на обычных языках (типа Oberon) надо делать очень много писанины

Гм. Что Вы имеете в виду?
Шаблоны по типу есть в КЛУ, в Аде. Не вижу проблем. (Модулы, к сожалению, не знаю.)

> реального времени еще не разработано удачного языка

В Аде есть встроенные конструкции реального времени. Я прикидывал, как похожее на Яве сделать -- кое-что довольно трудно.

> виртовские языки - панацея для индустрии ПО по меньшей мере неправильно

Есть ли она, единая "индустрия ПО"? 8-)))
Я всё-таки думаю, что "виртовские" языки были бы панацеей. Ну, до уровня ориентированных на отрасль языков. Если у Вас есть другое мнение, мне было бы очень интересно выслушать. Что именно в них не так.

В Винде-Линуксе-Маке и т.д. слишком много багов. Думаю, несколько процентов вносит и язык.

Шаблоны по типу есть в КЛУ, в Аде.
В Аде есть, но Вирт критиковал Аду за ее грамозкость. Кроме того там эти средства развиты слабее, чем в C++ (если не ошибаюсь, там нет специализации - очень важный инструмерт в метапрограммировании).
Вирт в свои языки принципиально не вводит шаблоны, считая их не нужным усложнением.

В Аде есть встроенные конструкции реального времени.
Ада вообще проектировалась как язык, ориентированный на реальное время. Ява туда принципиально не подходит, хотя-бы из-за сборки мусора.

Есть ли она, единая "индустрия ПО"?
Я думаю в какой-то степени панацея - DSL. Но прогресс в этой области пока небольшой.

Вирт в свои языки принципиально не вводит шаблоны, считая их не нужным усложнением. Если это так, то это просто глупо. Отказ от повторного использования! Приведение типов спасает(ло) Яву, но вообще-то, если вдуматься, это жуткий ужасный кошмар. Ява туда принципиально не подходит, хотя-бы из-за сборки мусора.
Ну-ну-ну. 8-)))
Есть и "Real-time Java" проект. Для ЖЁСТКОГО, КРИТИЧНОГО. А уж для некритичного сам Бог велел.

Смотрел я на описание "Real-time Java". Пулы памяти, которая не управляется сборзиком муссора, да еще проверка runtime на обращение реалтаймовой нити к нереалтаймовым данным.
Не жизнеспособная штука.
Здесь интереснее подход языка Cyclone - у него проверка пула статическая. Наверно его не очень сложно допилить до поддержки real-time не теряя возможности собирать мусор в вспомогательных нитях. Но это уж больно экзотический проект.

Не жизнеспособная штука.
8-)
Категорично Вы штатовцев разделали!

Честно говоря, я не спец по системам реального времени, но три общих соображения:
1. Никто не запрещает программе на Яве сначала выделить все структуры данных и потом прекратить динамическое распределение.

Например, в нашем проекте меговые XMLи для каждого пользователя веб-приложения (а их может быть миллион) надо превращать в объекты. Народ тыкнулся -- SAX sucks (миллион строк создаётся), написали свой парсер по "голому" массиву букв. Запрос 50 мс, разбор 80 мс. Лепота!

2. Если задача требует динамического распределения памяти, то какая разница между Java аллокатором и C++ аллокатором. Всё равно объекты надо освобождать, а для C++ аллокаторов надо доказать устойчивость алгоритма по времени. Но и для Явки в таком случае можно написать свой хороший аллокатор (есть API для подключения).

3. Современные Явы уже с 1.4 позволяют контролировать время задержки на сбор. То есть для Явы тоже можно доказать устойчивость по времени. А тем более что один из режимов сбора мусора сейчас не останавливает "вселенную" (параллельное выполнение).

8-)

Вот Вы называете Яву "нежизнеспособной" из-за задержки при сборке мусора (проблемы начальных версий).

А вот я давно не глядел на новости С/С++, не подскажете, были ли решены такие проблемы:
1. Результат каждого выделения памяти может быть NULL, и это надо каждый раз проверять?
2. Если такую ссылку не проверить, то обращение к ней приводит к завершению программы? Или обычный способ -- try/catch ловит эту ситуацию?
3. Повторное освобождение памяти по освобождённой ссылке приводит к зацикливанию аллокатора или к разрушению арены?
4. Сочетание стековых буферов с отсутствием проверки выхода за граница массива даёт возможность перейти в произвольное место программы -- всё ещё не решено?

Если нет, то по-моему, С/С++ просто безумно опасный и ошибочный язык.

Да, конечно. Я же говорил что C++ годится только для пофессионалов очень высокого класса. А таковых мало. К сожалению есть еще одна особенность плюсов - когда на них начинает писать дилетант, ему начинает казаться что он становится профессионалом.
Интересная альтернатива в этом плане - Cyclone.

Кстати, проверку границ массива в C++ можно организовать статически (с помощью шаблонов) в большенстве случаев. Но программировать с помощью того, что получилось будет очень тяжело :-).

Спасибо за новости о Java. Я мало интересуюсь как RT, так и Java, так что отстал от жизни :-).

По ANSI C++ невыделение затребованной памяти должно приводить к окончанию работы программы. Обычно это не реализуется.