>> и сборке мусора (имея в виду, видимо, иммутабельные String-и).
> Я в целом имел в виду мою возможность анализировать поведение получившейся конструкции
> и понимать что в какой момент времени она делает и является
> ли фактический результат работы тем чем было задумано в изначальной логики
> оной, что в криптографии важно. Чем сложнее конструкция, тем сложнее ее
> анализировать.

Анализу помогают модульные и другие виды тестов. В C/C++ это на зачаточном уровне (лишь недавно во FreeBSD добавили test framework базовой системы, что говорит о печальной ситуации с покрытием тестами и автоматизацией тестирования системного кода!).

> Поэтому в жабе неизбежно будут кучи багов. И в реализациях
> SSL. Они просто навороченные до ж...ы.

Микропроцессоры с каждым годом становятся всё сложнее и сложнее, однако старые программы спонтанно не вылетают, хотя по твоей идее о сложности ДОЛЖНЫ!

> Так что кучи багов там обеспечены, независимо от ЯП.

В любой программе, сложнее "Hello World", есть баги.

> Некоторые баги будут проблемами безопасности.

Так в C/C++ они расставлены на уровне ДНК ЯП, а не программиста.

> Так что в этом плане мне очень нравится тезис Берштейна: меньше кода - меньше багов.

Про это ещё Вирт писал, я помню: http://www.osp.ru/os/1996/06/179017/

Оттуда ещё:
///---
Методологии, связанные с языками программирования, до сих пор являются предметом дискуссий. В 1970-х было принято верить, что проектирование программ должно опираться на хорошо структурированные методы и слои абстракции с четко определенными спецификациями. Лучше всего эта мысль выразилась в концепции абстрактного типа данных, которая и нашла свое воплощение в новых тогда языках, прежде всего в Modula-2 и Ada. Сегодня программисты оставляют хорошо структурированные языки и мигрируют, в основном, к Си. Язык Си не позволяет компилятору даже выполнять контроль безопасности типов, а ведь именно эта функция в наибольшей степени полезна при разработке программ для локализации концептуальных ошибок уже на ранней стадии. Без контроля типов само понятие абстракции в языках программирования становится пустым и имеющим чисто академический интерес. Абстракция может работать только в языках, постулирующих строгий статический типовой контроль для каждой переменной и функции. В этом отношении Си несостоятелен и, в сущности, подобен ассемблерному коду, где, правда, "все работает".
Весьма примечательно, что абстрактный тип данных через 25 лет после своего изобретения появился вновь под названием "объектно-ориентированный". По своей сути этот современный концепт (принимаемый многими как панацея) более всего связан с построением иерархий классов или типов. Более старое понятие не было, в сущности, понято, пока не появился новый ярлык "объектно-ориентированный"; теперь же программисты признали присущую абстрактному типу данных мощь и обратились, наконец, к нему. Однако, чтобы об объектно-ориентированных языках можно было говорить всерьез, в них должна быть реализована строгая статическая типизация, которую нельзя было бы нарушить; это дало бы возможность программисту полагаться на компилятор в деле идентификации разного рода несогласованностей. К сожалению, наиболее популярный язык, С++, неудовлетворителен в этом отношении, потому что было изначально декларировано, что он должен быть совместим со своим предком - языком Си. Широкое принятие С++ подтверждает следующие "законы":
* прогресс приемлем, только если он совместим с текущим состоянием;
* приверженность стандарту - всегда безопаснее, чем даже мотивированный отход от него.
Принимая эту ситуацию как данную свыше, программисты вступают в борьбу с языком, который не поощряет структурное мышление и дисциплинированное построение программ, отрицая базовую поддержку компилятора. Они также прибегают к инструментам-паллиативам, которые еще более способствуют разрастанию размеров программ.
---///

> Проблема лишь в том что софт который ничего не умеет - никому и даром не сдался... :)

Проблема не в софте, а в программистах, которые ничего не ели слаще пареной репы.