Здравствуйте, lomeo, Вы писали:

L>Здравствуйте, VladD2, Вы писали:

VD>>В грануляности. Нет экземлпяров.

L>Увы! Модули — это не аналог классов, это аналог пакетов.

VD>>Спроектировать большую систему в терминах модулей просто невозможно. В терминах функций можно, но очень сложно.

L>А в терминах групп функций? Разумеется поименованных. Экземпляры есть.


Насколько я понимаю весь вопрос в храненении состояний, можно рассмотреть несколько примеров:
1) "Моя первая программа на паскале" — состояние хранится просто — в виде глобальных переменных.
2) "Струкутрнуе программирование по уму" — все переменные объявлены внутри каких-то процедур, которые вызывают другие процедуры
(я намеренно не использую слово "функция"), использование глоабальных переменных не приветствуется. Сразу возникает вопрос как передавать
эти переменные при вызове, единственный разумный вариант — в виде структуры. Но структуры — это первый шаг к ООП. При построение
большого приложения, возможно потребуется подменить что-то не исправляя кода, а заодно привязать те или иные процедуры к строго определенному
контексту.
3) "ООП" — позволяет хранить состояние в виде переменных членов и набор ассоциированных с ними функций в виде методов.

VladD2 совершенно справедливо заметил, что такой способ хорошо подходит для описание систем на макро уровне, например:
public class JobSystem и сразу понятно что если нужно взаимодействие с шедулером то нужно смотреть список его методов, в нем
же хранится текущее состоние (в виде конфига и запихнутого внутрь кварца(которй уже со своими потрохами)), там же лежат
методы для управления подсистемой в целом (start/shutdown).
А вот при описании этого же в термених ФП мы вернемся к пункту 2, отчего несколько десятилетий назад наооборот пытались уйти.

Глупый вопрос к VladD2: а что дают макросы? Они позволяет встроить кодогенерацю внутрь программы и управлять ей из нее же?
Вещь конечно заманчивая, но не возникнет ли бардака?

P.S. В процессе заигрывания со скалой заметил один неприятный момент, язык поощраяет написание большого кол-ва анонимных
функций (а иначе получается не так уж компактно) — в этом на мой взгляд главный недостаток чрезмерного засахарения,
но в целом он мне понравился, добивает только отсутствие документации (ScalaByExample и пр. не в счет) и отсутствие
поддержки со стороны netbeans.