OberonCore

"Состояние" вызываемой процедуры должно храниться в вызывающей процедуре. При очередном вызове процедуры ей передается ее текущее "состояние", а затем в вызывающую процедуру возвращается обновленное "состояние" вызываемой процедуры.

Очень хотелось бы когда-нибудь попробовать в процедурном языке построить каркас без глобальных переменных, чтобы практически оценить пользу/вред от такого решения.

Ваш совет, кажется, тоже не лишён недостатков. Модуль Random должен быть один, иначе последовательность генерируемых значений для разных клиентов будет одинакова. Два разработчика пишут модули А и Б, используя Random. Значит они должны хранить у себя его состояние. А следовательно, передавать и своё состояние на уровень выше. Бррр...Просто мрак сплошных иерархических передач состояний получается.

Erlang произвел на меня неизгладимое впечатление, хотя недостатки тоже бросаются в глаза. Я решил добавить некоторые его черты в PureBuilder:



Насчет способа реализации обмена сообщениями пока раздумываю.

Но это же противоречит природе взаимодействия с компом: редактор должен помнить уже набитый текст

А что мешает редактору помнить уже набитый текст?

Если бы ПО взаимодействовало с пользователем так же, как функциональная парадигма вынуждает жить разработчика, то пользователь нажимал бы клавишу, получал на флешку текст с добавленным символом, потом опять открывал бы его с флешки, одновременно нажимая на клавишу

Но флешка-то -- это типичная глобальная переменная

Природу не обманешь

Не стоит путать внешние ресурсы (файлы, базы данных, каналы и т.п.) и глобальные переменные, являющиеся внутренними объектами программы. Функциональная парадигма не распространяется на долгоживущие и имеющие состояние (в отличие от функций) внешние ресурсы, поскольку это невозможно. В функциональных языках для ввода/вывода есть специальные средства, не укладывающиеся в функциональную парадигму. При этом функциональные языки неплохо обходятся без глобальных переменных.

Текст засовывается внутрь объекта "Редактор". Объект "Редактор" засовывается по указателю внутрь объекта "Редакторы". Указатель на объект "Редакторы" якорится в локальных переменных процедуры c главным циклом приложения (например в процедуре main). Таким образом статических переменных нет.

Запрет статических переменных, кстати, чуток облегчает выгрузку модулей, так как не надо чистить сектор data (его просто нет).

Лично я препочитаю не кидаться из одной крайности (императивной) в другую (функциональную). Думаю что будущее (а местами уже и настоящее ) за симбиозом этих двух парадигм.

А разве тут кто-то с этим не согласен? Внутри прицедуры (на нижнем уровне) императивная парадигма. Связи между процедурами (на среднем уровне) - функциональная парадигма. На верхнем уровне - модульная парадигма. Главное - не смешивать.

Полный отказ от глобальных переменных, на мой взгляд, выглядит несколько экстремистским.
Коллеги здесь пытались намекнуть, что есть задачи, когда такой подход является противоестественным.

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

Переменная -- это ячейка памяти

Просто некоторые можно втыкать-вытыкать, а другие нельзя

Точнее, переменная - это именованная ячейка памяти

И имя переменной - тоже ячейка...

Точнее, имя переменной - это её "высокоуровневый адрес ячейки"

... а в конечном счете всё - электрические импульсы. И что нам это дает? Вот сделать разделение между глобальными переменными (устраняемыми) и внешними ресурсами (принципиально неустранимыми) - это дает повышение надежности ПО, как например, строгая типизация переменных. А слова, что любая переменная - всего лишь ячейка, конечно, справедливы, но бесполезны.

Причём тут "электрические импульсы"? А вот переменные ещё как "причём". Переменные позволяют абстрагироваться от машинной памяти и от машинных адресов, помогают выразить решение задачи в терминах предметной области, а не в машинных терминах. Глобальные переменные хранят глобальное состояние программы. Чем они Вам не угодили?

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

Коллеги не поняли, что Александр Шостак под глобальными переменными имел ввиду статические переменные. Отказ от статических переменных совершенно не означает отказа от глобальных переменных, которые просто переезжают из статического размещения в поля объекта-модуля указатель на который передаётся всем заинтересованным лицам.

Для обращения к глобальной статической переменной надо написать Module1.Variable1 (здесь Module1 - имя модуля), то же самое можно сделать не используя статического размещения: module1.Variable1, здесь module1 - указатель на объект-модуль. При этом упрощается процедура выгрузки более ненужных модулей - она делается автоматически сборщиком мусора.