C++ и Ada: вынужденный пост

Собирался уже написать очередной пост, как пришел такой комментарий:

OCTAGRAM комментирует...

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

(Это был мой текст)

Ну так сравните сложность C++ и сложность Ады.

Э-э-э... А зачем? Я разве что-то говорил про то, что какой-то язык сложнее, а какой-то проще? Не дождетесь. :-) Во всяком случае, ничего дурного про Аду у меня не было,- скорее уж, над C++ и над его автором иронизировал...

Но уж если Вы хотите (а Вы хотите: и тон, и содержание Вашего комментария это ясно показывают) сравнения, то вот Вам мой ответ: оба хуже.

На C++ я немного уже потоптался, вот вам про Аду.

В C++ мы должны не забывать ставить проверки.

В Аде мы проверки опционально снимаем.

А кто мешает assert'ов понаставить куда надо? Они, вроде, тоже по предопределенному макросу включаются/отключаются?

Тяжелее, согласен, и программу загромождает. Зато все явно выписано, и не надо помнить, как в Аде, какие именно проверки делаются, и где, а где не делаются...

В C++, чтобы сделать объект некопируемым, мы переопределяем operator= и конструктор копирования в приватной части.

В Аде мы пишем limited.

Замечательно! Красивое служебное слово, все наглядно.

Только вот в плюсах действует общий механизм задания собственных версий для всех операций, включая присваивание, и общие для всех правила управления доступом. А в Аде присваивание и операцией-то не считается, и, стало быть, пришлось для него отдельный limited-механизм вводить. Что лучше: набор различных средств для, в общем-то, одного и того же или единые (и вполне, кстати, ясные) правила для всех операций?..

В C++, чтобы определить метод как виртуальный, мы пишем =0 после прототипа.

В Аде мы пишем is abstract.

Согласен. Красиво и ясно. Страуструп служебные слова экономил, на мелочи их не тратил...

В C++ тела настраиваемых методов должны быть в ашниках, а ненастраиваемых — в цппшниках.

В Аде все (видимые снаружи, я имею в виду) определения в .ads, все тела в .adb.

Да никто и не спорит, что в Аде модульность лучше. (Только вот .ads и .adb - это не в Аде, а в GNATе. В стандарте на этот счет ничего нет.) В плюсах этот архаичный механизм заголовочных файлов целиком остался от предшественника, ничего не поделаешь, если надо было обеспечить совместимость.

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

В C++ нельзя подключить пространство имён в ашнике. (точнее, можно, но по головке за такое не погладят)

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

В Аде ... ну, ясен пень, такая тупость только в C++ может быть, в Аде всё в порядке.

Ваш тон, простите, много о Вас рассказывает. Можно и не отвечать дальше...

Почитайте внимательно правила использования with/use в Аде, правила, связанные с областями действия имен и видимости идентификаторов. Уверяю Вас, они ничуть не проще и не яснее плюсовых. Опытные Ада-программисты с трудом разбираются...

В C++ простые аргументы нужно передавать по значению, а большие — по ссылке, иначе они полностью копируются.

Ну, так и передавайте по ссылке, трудно, что ли? Можете слово const добавить, если модифицировать не собираетесь. Все нагляднее, чем про in по умолчанию помнить.

В Аде входные параметры (с модификатором in по умолчанию) доступны только для чтения, поэтому копировать их не нужно. А уж как их передать на машинном уровне — это дело компилятора.

Так и в плюсах стандарт явно отдает механизм передачи параметров по ссылке на откуп компилятору. В чем преимущество-то, не пойму. Функционально эквивалентные механизмы.

В C++, чтобы настроить шаблон дробным числом, необходимо настроить его ссылкой на это дробное число.

Ну и настройте ссылкой!

(Уж молчу о том, кому и зачем может такое понадобиться...)

В Аде ... ну, ясен пень, такая тупость только в C++ может быть, в Аде всё в порядке.

Опять... Как же это часто встречается - эта великолепная уверенность в собственном праве припечатывать ярлыки куда и кому угодно! Невзирая, так сказать, на лица. "Тупость"... Не знаю, видели ли Вы один старый фильм, в нем герой говорит примерно следующее:

- То и дело слышишь: Тургенев не разобрался, Толстой недопонял... Как будто в истории орудовала банда двоечников!

В C++ namespace может быть одним, имя цппшника/ашника другим, а объектный файл, который нужно не забыть подключить — третьим.

В Аде между всеми тремя несложное соответствие. Да и то, реально знать нужно только namespace.

Это, уважаемый, вы что-то не то сказали, воля Ваша. С стандарте нет ни слова об именах файлов-носителей Ада-программ и, тем более, о каких-то "соответствиях" между ними и именами в программе. Это все заморочки GNAT'а, и явно не самые удачные. По-моему опыту, требование называть файл с Ада-пакетом именем самого пакета - ужасная нелепость и неудобство. Семантически, файл как контейнер, и единица компиляции как его содержимое - совершенно различные сущности, и любые правила их "совместного" именования,- ничем не оправданы. Да, компилятору и линкеру можно не быть слишком умными (программист должен сам позаботиться, чтобы назвать файлы так, как им, а не ему, удобно). Но еще хуже, что одно неудачное проектное решение тянет за собой другие, вынужденные. Скажем, наличие ограничения "8+3" на имена файлов в некоторых ОС автоматически приводит к необходимости некоего соглашения: как надо сократить-искорежить имя Ада-единицы, чтобы полученным словом-уродцем поименовать файл, ее содержащий... А тут еще и дочерние единицы появились, с составными именами! Их-то как корежить, по новым каким правилам?

Это лишь несколько примеров к слову об адекватности сложности C++,

Так вот в чем дело, оказывается! Вы читаете между строк!

Вам показалось, что смысл моего поста был в том, чтобы заявить об адекватности C++ уровню сложности современных задач? И где именно Вы это увидели?..

Писал же (уж яснее, казалось бы, некуда) о C++ и Обероне как о двух крайних подходах к преодолению объективной сложности. Скепсис выражал и о том, и о другом. Критиканствовал даже. И на тебе - увидели апологетику C++...

Что ж... я уже не раз сталкивался с подобным эффектом: в самых невинных, самых прямых и бесхитростных моих словах ищут и находят какой-то второй смысл, неясные намеки и т.д. Так вот, во избежание подобных казусов в будущем, хочу заявить: в моих текстах никаких намеков, подтекстов, вторых планов и прочей литературщины нет. То, что написано (и только это), я и хотел сказать. Можете считать, что я слишком глуп, чтобы делать тонкие намеки, организовывать подтексты и выстраивать вторые планы...

которой здесь было посвящено столько воды.

Неужто много воды? Дык... Это все-таки блог, а не статья в журнал. Жанр другой. Свободный, так сказать, полет мысли. Извините, что отнял у Вас время. Однако, хочу честно предупредить, что и впредь намерен продолжать в том же духе. :-) Так что придется Вам теперь что-то другое читать, где воды поменьше... Найдете, поделитесь ссылочкой, please.

Ну, и в заключение:

А про Оберон (про первый) ещё Жан Ичбиа, создатель Ады говорил :
"There are times when Wirth believes in small solutions for big problems. I don't believe in that sort of miracle. Big problems need big solutions!"

Ну так и весь мой предыдущий пост про то же! - почти теми же словами...

Что Вам не понравилось-то, не пойму?

Что я Аду не похвалил? :-)

P.S. Написал все это и подумал: какие-то все замечания мелкие. Ерунда, в общем. Придирки... Почему было не взять что-то очевидное, чтобы никто был не в силах возразить? Cравнить, скажем, модульность (аккуратно проработанную в Аде и попросту отсутствующую в плюсах)? упомянуть механизм подтипов - простой, но удивительно полезный в умелых руках, аналогов которому нет, кажется, больше нигде? Да и многозадачность - непростую в освоении, но надежную и полностью встроенную в язык?..

P.P.S. Не хотел, честное слово... Обещал же себе не участвовать в религиозных войнах. Последний пост такой. Больше не будет.