Морально устаревшие элементы языков высокого уровня

Языки высокого уровня были задуманы, чтобы облегчить программирование по сравнению с ассемблером и машинным кодом. В этом они достигли достаточно больших успехов. Но для их использования существовало еще одно ограничение – скорость компиляции кода. Поэтому в языках высокого уровня остались элементы, которые нужны только компилятору, но не нужны человеку.
Однако сейчас производительность обработки текста программы (компиляции) уже не имеет решающего значения, а каждый введенный программистом символ, наоборот, стоит все дороже и дороже. Поэтому некоторые элементы оформления кода можно считать морально устаревшими.
Объявление библиотек и структуры объектов
В целях повторного использования кода программа делится на модули или классы.
Чтобы собрать эти объекты вместе, нужно указать компилятору, где их искать.
Самый логичный с точки зрения программиста вариант – указать, где расположена библиотека ядра, несколько личных библиотек, причем все это указывать в проекте.
В самой программе достаточно указать только имя класса. Библиотеки должны быть проиндексированы, чтобы по имени класса определить, есть ли он в библиотеке и должна ли подключаться библиотека. В любом случае имя класса уникально.
Однако что мы видим на практике?
В Паскале, в Си++ и в Java программист должен явно указывать, какие библиотеки использовать (uses, include и import соответственно).
Особенно страшно дело выглядит в Си++ - программист должен указывать еще и заголовочные файлы (с расширением H), следить, чтобы заголовочные файлы не включались дважды. Одно это отталкивает от Си++, несмотря на все преимущества ООП.
В Java можно включать библиотеки верхнего уровня, при этом подбиблиотеки включаются автоматически – по сути, подключаются лишние библиотеки ради упрощения написания кода. Подход хороший, но не идеальный. Идеально было бы определять библиотеки автоматом, по составу классов.
Конечно, использование IDE немного нивелирует эти проблемы, но IDE все равно не решает всех проблем, в любом случае человек видит этот лишний, по сути, мусорный код, и тратит на него свое внимание. Программа в любом случае может лучше человека определить, какие модули нужны.
Поэтому нужно запретить явное указание библиотек человеком для улучшения читаемости и скорости ввода программ.
Объявление интерфейса вместе с реализацией
Если объявлять интерфейс класса отдельно от реализации, как это принято в Си++ и Паскаль, код программы увеличивается и по сути, дублируется. Ничто не мешает компилятору собрать объявление из реализации класса. В Java это поняли и поэтому код стал лаконичнее и прозрачнее. В Си и Паскале при изменении интерфейса приходится менять еще и реализацию, т.е. делать никому не нужную, излишнюю работу.
Объявление переменных
В этом плане отстает только Паскаль. Только в угоду компилятору локальные переменные можно объявлять только в начале процедуры, хотя ничто не мешает определить, сколько локальных переменных используется в процедуре и отвести под них необходимое место.