История о взрыве Ариан - неверна. Программное обеспечение там ни при чём; проблема в том, что было использовано (верное) программное обеспечение от старой модели, которое в новых условиях повело себя совершенно определённым образом, адекватным в случае старой ракеты, но неподходящим для новой. То есть виноваты не программисты, а постановщики технического задания.

Пассаж о весе программы, разработанной на языке C++ - вообще какой-то бред. У С++ много недостатков, но излишний тоннаж объектного кода в их число не входит.

>...виноваты не программисты, а постановщики технического задания.

Отсюда мой известный вывод: программисты не нужны. От них ошибки одни, а отвечать ни за что не хотят.


Пассаж о весе -- шутка.

{+}

А что великий теоретик Вирт создал столь же широко применяемого, как тот же C/C++?

А что, Паскаль и вся последующая ветка это языки узкого применения?

По сравнению с Си-подобными языками - разумеется. Узкое исключительно прикладное применение.

Сравнивать 3GL с макроассемблером как-то некорректно, а? В вот то что С используется (использовался долгие годы) повсеместно для разработки прикладного софта, так это натуральный misuse и использовать "широкоприменимость" С опять некорректно.

Да, а что имеется ввиду под "Си-подобными языками"?

Да хотя бы та же java. Это, конечно, уже не C-подобный, а C++ подобный язык, и с существенно разной моделью, но всё же это явно наследник С, а не Паскаля.

Ну да и много их, у которых из C ноги торчат, чего уж там.

Назовите мне какую-нибудь большую систему, разработанную на Паскале. Ещё лучше - на "языках последующей ветки" - кроме Object Pascal. Заодно станет ясно, что это за перспективная ветка. Да, назовите мне что-нибудь большое и популярное на Modula-2, скажем.

Ну или Open Source проект на Pascal приведите востребованный. А я потом на C/C++ приведу парочку. Парочку тысяч.

>Да хотя бы та же java. Это, конечно, уже не C-подобный, а C++ подобный язык, и с существенно разной моделью, но всё же это явно наследник С, а не Паскаля.

Что паскаль, что ц++, что java и с# -- одни яйца только сбоку, принципиальных отличий нет.

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

>Ну или Open Source проект на Pascal приведите востребованный. А я потом на C/C++ приведу парочку. Парочку тысяч.

За что воюете?

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

Я, кстати, считаю это большой бедой отечественной школы. Ну ладно в англоязычных странах - им, может, и удобнее читать begin и end вместо { и }. Но наших-то студентов зачем мучать? Единственная сложность при изучении плюсов - через указатели продраться, но это в любом случае придётся делать, и чем раньше, тем лучше.

Идиотская традиция начинать обучение с Паскаля, потом переучиваться тяжело и неприятно.

> За что воюете?

За то, что уже, собственно, много лет как ясно, кто в борьбе победил - путь Вирта или путь Страуструпа.

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

>За то, что уже, собственно, много лет как ясно, кто в борьбе победил - путь Вирта или путь Страуструпа.

Пиррова победа, увы. Что С, что паскаль и аналогичные -- одинаковая императивная гадость с которой торчат мохнатые уши ФонНеймана. И начинать обучение с любого из них одинаково плохо, imho.

Это уже другой разговор, повышение уровня абстракции и выход из логики обсуждения :)

Потому что ЭВМ устроены, как ФонНейман прописал. Императивно.

1. Не ФонНейманом единым...
2. Ничто не мешает строить поверх "более другие" (читай более высокоуровневые) модели, а не экспозить потроха железки. Подтверждение чему наличие лиспа, пролога и прочих хаскелов.

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

{+}

>Ну ладно в англоязычных странах - им, может, и удобнее читать begin и end вместо { и }.

Мне, например, совершенно пофиг, одинаково перевариваю begin/end и
{}. Однако наезды сишников на begin/end паскаля всегда веселили. Не подскажете, почему в языке с таким чудным синтаксисом нужны круглые скобки в if-выражении?
Кроме того, в Обероне (а может уже и Модуле, не уверен) необходимость писать begin/end сведена почти на нет, что есть очень неплохо.

(уныло) Ну и где эти Оберон с Модулой, кроме как в учебниках?

>(уныло) Ну и где эти Оберон с Модулой, кроме как в учебниках?

В жопе. Что и огорчает глядя на прикладной софт созданный с помощью Цэ.

Кесарю - кесарево. Прикладному программированию - дельфи да яву.

На спутниках, например. Ну и в ядерной энергетике.

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

Интересно, а на чем они пишут. Я слышал, что в Австралии, Великобритании, Канаде во всех системах имеющих отношение к ядерной энергетике разрешено использовать только Аду и Модулу-2.

> Спорить с тем что проектов на С на
> порядки больше я не собираюсь, это
> очевидно.

Я, собственно, хотел подвести к тому, что если Паскаль такой охеренный и понятный язык, то почему на нём никто не пишет?

Я лет 6 на Delphi работал, несколько довольно крупных учётных систем построил и внедрил. Для такого класса задач Delphi вне конкуренции. Просмотрите job-сайты по ключу delphi. Не в первых рядах, но и не в последних.

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

Как-то непонятно было утверждение что "никто не пишет". Ну да ладно, консенсус вроде.

Аминь.

TeX?

Про TeX не знал, но вполне верю. То есть один. Там ниже ещё один назвали. Два. :)

На Modula-2 написан cvsup - популярный инструмент для синхронизации файловых систем адаптированный к синхронизации CVS-рапозитариев.

Интересно, спасибо. Почитаю подробнее.

"Си-подобные языки"! Так и ещё несколько! Какой ужас!

Крику сейчас будет!

А я, кажется, начал понимать, зачем Вам Паскаль. Дело в высокой стоимости ошибки. Сейчас программистская мода тихонько ползет в противоположную сторону - не планировать заранее и не бояться ошибок (agile methodologies), но ясно, что в Вашей области это неприемлемо.

Когда ДПЛА улетает за горизонт, ему никто не скажет, что делать, кроме программы. Поэтому ошибки в программе СОВЕРШЕННО недопустимы.
Спасибо, что Вы мне самому объяснили, зачем мне Паскаль! Я не шучу. Я понимал, конечно, но не мог сформулировать это так кристально.

{+}

Главное не перепутать С и С++ :)
С вполне прозрачен, так что ошибки только рукотворные, да и код на нём получается вполне компактный качественный. На ассемблере конечно же будет ещё компактнее, но таких богатырей ещё поискать надо, чтобы они большую систему на ассемблере хорошо написали, не наделав ошибок.

Правда?

Тогда для Вас - Haskell. Написать на нем программу с ошибкой очень тяжело - 99% реально отлавливаются компилятором.
Правда и безошибочную программу написать без некоторой привычки непросто :-)).

Спасибо! Люди -- это такие придурки, что ошибки делают всегда. Особенно программисты:).

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

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

На том же Object Pascal / Delphi я писал суперэффективные поиски по хитрым алгоритмам в memory-mapped файлах. Есть ВСЁ: указатели, кастуемые из int-ов, инкремент-декремент, сравнения...

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

Бедный yurri@lj выше заявляет, что-де всё на Си. Тот же МС офис -- явно половина всего на Бейсике писано. А, скажем, в мин.обороны США станарт -- Ада, тяжёлый, но крайне надёжный язык. А ещё, скажем, есть SAP/R3 -- а те на своём АБАПе пишут. Конкуренты САПа, Конкорд, оболочку (вроде сишную) имеют, но на внутреннем Фокспро-подобном языке пишут.

А, скажем, Веб-приложения (в США составляют больше половины всех программ, думаю) -- однозначно не Сишная область. Несмотря на templates (кстати в новой "пятой" Яве нечто подобное наконец-то появилось). Кошмар Си компиляции и включаемых файлов вообще не способствует.

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

Скажем так - реальной эффективности. Средтва 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++ невыделение затребованной памяти должно приводить к окончанию работы программы. Обычно это не реализуется.

Вам нужно Forth (http://www.forth.org/successes.html) использовать!

Кстати да. Для программирования роботов и прочего движущегося железа - вполне подходящий язык. Был придуман для управления телескопами. Машины, с помощью которых нашли останки "Титаника" были запрограммированы на Форте. По "понятности" и "ошибкоустойчивости" для непрограммистов скорее ближе к Паскалю, чем к С.

Соглашусь с Вами. Но поскольку я всю жизнь пишу на Паскале, то от добра-то чего добро искать...
Я сейчас Обероном интересуюсь. Хочется быть посовременней:)

{+}

а со мной значит не согласны?
понятно.

Я по Вашей ссылке почитал про Форт. Очень интересно и практично. Однако, я уже пользуюсь Паскалем, наработал свой инструментарий. К тому же, всё уже написано и просто модернизируется и развивается.

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

Ещё вопрос: а Вы мирными технологиями тоже занимаетесь? НАПРИМЕР (http://www.towerhobbies.com/rcweb.html) или ещё ССЫЛКА (http://www.rcuniverse.com/index.cfm).

Мирными технологиями не занимаемся. Скучно. Но активно используем их достижения и комплектующие изделия.

Всё уже написано.

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

1000 na C++ i 200 na Jave ?
Pri tom, chto Java fakticheski
obrezannyj C++ ?
Bred sivoj kobyly.

Special'no dlja specialistov:
ne v jazyke delo, a v tom, kto na nem govorit ili pishet.
Oshibki ne v kompiljatore a v DNK.

то пишите нормальными буквами.

1000 на С++ и 200 на Яве ?
При том, что Ява фактически
обрезанный С++ ?
Бред сивой кобылы.

Специально для специалистов:
не в языке дело, а в том, кто на нем говорит или пишет.
Ошибки не в компиляторе а в ДНК.

Язык имеет огромное значение, так как дисциплинирует программиста.

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

Я даже не останавливаюсь на такой очевидной вещи, что на "мощном" языке программирования можно сделать очень неочевидные ошибки. Помните, наверное, всякие "зависания" и пр., так присущие программам, написанным на "Си".

{+}

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

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

А вот тут вы написали, извините, полную бредятину.

//======
Кроме того не надо забывать второе, обычно игнорируемое назначение программы для ЭВМ. Это -- документирование алгоритма для человека, который может обратиться к программному тексту через многие годы, когда никого из авторов программы уже не будет. Поэтому очень важна минимальность и ограниченность выразительных средств языка.
//======
Самый простой язык - ассемблер.
В нем можно наворотить намного больше чем на Си.
А самое главное, с алгоритмом фиг разберешься.
Вы пробовали ?

Хорошо, Ассемблер - язык низкого уровня.
Как насчет бейсика ? Он еше проще чем Си,
но программа на нем совершенно не понятна,
(в смысле алгоритма) и наворотить можно ну никак не меньше.
По сравнению с Си/Си ++ - мрак кромешный.

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

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

То, что Паскаль Вам помог, это хорошо.

Ассемблер на самом деле прост.
Сколько там команд , несколько сотен ?
( На самом деле зависит от типа процессора.
Я знаю как минимум один ассемблер где команд меньше 100)
И это всяко меньше, чем количество стандартных функций в Си.
То, что не просто - это периферия, которую он обслуживает,
прерывания например - но к собственно языку они не имеют ни малейшего отношения.
Ассемблер как язык - прост.
Писать на нем сложно.

Впрочем на эту тему можно разговаривать еще долго.
Как насчет примера с бейсиком ?
Минимальное количество выразительных средств.
Написать программу с количеством строчек кода больше
20000 почти невозможно.

Так что бредятина осталась бредятиной.
Не в количестве выразительных средств дело,
а в их использовании.
См выше пример с молотком.

Странно. Описание синтаксиса, скажем, в BNF у C/C++/Java будет раза в два длиннее, чем для Pascal. Никак не больше.