Про структурное программирование
Цитата:
Сообщение от
[/COLOR
Про объявление переменных по месту. Delphi и FreePascal уже довольно зрелые среды разработки, но ничего подобного объявлению переменных по месту в них не внедрено, хотя внедрено много чего другого. Это вопрос культуры кодинга. Список переменных одним блоком - это как бы секция данных процедуры. Помните выражение "алгоритмы и структуры данных"? Так вот, алгоритмы - то, что после BEGIN, а данные - VAR. И это здорово, что секция данных декларативна, а не размазана по исполняемому коду неизвестно как. Это дисциплинирует имхо. Учит думать более структурно, в терминах "алгоритм отдельно, данные отдельно". Ну да пусть это будет моё имхо и ничего больше.
Вопрос только - нужно ли в наше время думать структурно. Во времена создания Паскаля структурное программирование действительно было прорывом. Но с тех пор было множество других прорывов. Изменились условия и изменилась элементная база. Сейчас, за счет того, что уперлись в рост тактовой частоты и появилась ставка на параллелизм, в тренде функциональное программирование. Да, там var не в почете, но всякие val, def вовсю используются. Уже по 8 ядер даже в мобильниках, в видеокартах вообще бешенный уровень параллелизма - сейчас совершенно другие концепции, сейчас нужно не каждый такт и байт считать, сейчас чтоб не тормозило нужно как то использовать сразу все ядра, и крайне желательно без синхронизации, чтоб был параллелизм а не concurrency. В императивном программировании тоже совершенно другие концепции, которые были в 70-е годы. Не циклы со счетчиком, а итераторы, например - уже давно стандарт.
Да, для ретрокомпьютеров как функциональное программирование, так и современное императивное программирование - это не актуально совершенно. Слишком мало ресурсов, потому да, в принципе для ретрокомпьютеров у паскалеподобных языков ниша есть. В случае ретрокомпьютеров я даже понимаю возможную причину появления with оператора вместо объявления переменной - гораздо проще генерировать машинный код, а также более понятно какой машинный код мы получим.
Но для ретрокомпьютеров зачастую и структурное программирование может считаться роскошью. В условиях необходимости экономии каждого байта и такта приходится идти на различные ухищрения.
Но насколько я знаю, языки Оберон семейства претендуют на большее, чем использование в ретрокомпьютерах. И в этих условиях я ни черта не понимаю, зачем так цепляться за with. Ну можно было бы для обратной совместимости оставить секцию var. Но также внести оператор val как в scala - хуже от этого точно не будет, это прекрасная замена with. И в циклах со счетчиками тоже разрешить объявлять переменные без явной секции, например тоже как val. Варианты есть для того, чтобы сохранить обратную совместимость, но при этом язык сделать более удобным.
Я понимаю почему это все не было сделано в 70-е годы. Все таки тогда нужно было на маломощных машинах это все компилировать, и компилятор нужно было держать как можно более простым чтоб он занимал и использовал как можно меньше памяти. Но сейчас то даже для ретрокомпьютеров никто в здравом уме не будет писать непосредственно на ретрокомпьютерах, ну совершенно нет в этом необъодимости. Потому компилятор можно усложнять без проблем.
