Всё равно нулём
Вы будете прокляты великим Турбо Паскалем! 
Предлагаю(опять) реализовать директиву компилятора, либо настройку компилятора, либо параметр консольного компилятора, отключающую привязку к стандартным модулям, таким как PABCSystem.pcu, PABCExtensions.pcu и __RedirectIOMode.pcu.
Вот как раз в старых то Паскалях без динамических массивов забивать всё нулями было дико. А уж нейросеть со случайными значениями каких-нибудь неинициализированных переменных только душевнее, непредсказуемее будет работать. 
зачем?
Кстати, Free Pascal инициализацию при описании не выполняет. Довольно занятно смотреть, как “школота” пытается понять, почему не работает в fpc программа, которою они в школе отладили на PascalABC.NET (программируя на нем, как на Турбо Паскале, потому что за 20 лет преподавания в школе учительница информатики еще не успела освоить что-то иное).
Ну так это лишь аргумент в мою пользу. То, что КУМИР хуже других языков не означает, что эти самые языки хорошие. Просто из двух зол выбирают меньшее.
Об это уже давно говорят, причём не только я. Не думаю, что такая возможность останется без внимания. Чистым должен быть не только исходный, но и MSIL код.
Кстати, стандартная проблема при переходе между разными версиями. Вообще, если человек сам пишет программу, он по идее не должен лезть за значением туда, куда ничего до этого не положил. То что в .NET решили всё это пресечь на корню, так зато получается, что порой инициализация памяти занимает O(n) вместо O(1).
Это безобразие пресекли еще задолго до .NET. Память в нормальных языках должна нулиться.
1 лайк
Причем тут чистота. Паскаль не может работать без системного модуля. Как и .NET без FCL.
Согласен.
Программирование очень часто связано с математикой(не обязательно сложной), где новые переменные ВСЕГДА равны 0. Это нормально, естественно для самого разработчика. Непонятно, почему, например, Borland не додумалась автоматически обнулять переменные, а уж C++… Не было бы стольких споров…
Ну ведь не весь модуль критичен? Там есть хоть пара процедур, которые можно стереть?
Вы ещё скажите что странно что в C++ не проверяются границы массивов))) В C++ разработчик следит за всем, это сложно но даёт возможности оптимизации. Но вот студия, к примеру, не даёт читать не инициализированную переменную, так что проблем с этим быть не должно.
Кто то не использует сеты, а кто то не использует статические массивы. Вы не используете ничего, а кто то может и использовать все самые кривые фичи паскаля. По сути если эту ситуация как то улучшать - надо улучшать оптимизацию, чтоб выкидывало неиспользуемые подпрограммы и типы.
Директиву я предлагал, но с ней вот проблема - она будет отключать сразу всё, но такое надо очень ограниченному числу людей.
Это как раз очень хорошо, но сделано некрасиво.
Да, но про оптимизацию разработчики уже ясно сказали, что заниматься этим не могут. Слишком сложно. К тому же, я не предлагаю тупо удалить модуль, я предлагаю просто дать возможность его отключить. Например, разрабатывать программу на Паскале гораздо проще, чем на C#. Начинающие могут сначала написать код на Паскале, проверить его, а затем перевести на C#. Вполне понятно, что использовать при этом что-либо из Паскаля нельзя. Вот Вам и пример. А главная фича паскаля-его понятный и лаконичный синтаксис, так было с самого его создания, и отключать это уж точно никто не захочет!
Вот тут посмотрел свою программу: NET версия TRAC занимает 70кб, Delphi6/Turbo Delphi Win32 - 120кб, последняя Delphi 10.2.3 - 1Мб, Lazarus Win64 450кб, Lazarus linux64 -1.5Мб. Честно говоря, когда я увидел, какая маленькая NET, было даже обидно, столько сил положено. Вы что, ещё меньше хотите?
1 лайк
Вот как раз из математики и пришли O(n) и O(1) о которых я писал как об аргументе не инициализировать. А новых (и старых) переменных в математике что-то я не видел нигде. Хороший “математический” подход к программированию можно найти где нибудь в AXIOM CAS. А нули для всех типов - это обычное “разгильдяйство” в стиле С.
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021