Идеальная система модулей в языке программирования

В Go идеальная система модулей

Что в ней идеального?

Да где ж там сложность-то

В использовании, чтении и поддержке функторов.

Может это дженерики - ненадёждый и уродливый костыль для тех «современных» языков, создатели которых не осилили понять функторы.

Нет. Функторы - нежизнеспособная фича. И ход эволюции ЯП это показал.

Тред глазами пробежал и не вчитывался, но самая интересная по моему мнению система модулей в Go. Возможно она наиболее близка к идеальной. Имхо конечно.

самая интересная по моему мнению система модулей в Go. Возможно она наиболее близка к идеальной

Это там экспортируемость имени определяется кейсом его первой буквы?

Но в файле может быть несколько подмодулей

А какая в этом практическая польза?

Во-первых, могут быть несколько мелких модулей, которые в одном файле наглядней.

Во-вторых, тесты удобно делать подмодулем и держать в том же файле (так как писать их надо параллельно с кодом).

Не является ли такое желание признаком того, что модуль стоит разделить на несколько?

Не всегда. Например:

export foo

foo()
{
   ....
   ....
   bar();
   ....
}

bar()
{
   ...
   ...
   baz()
   ...
}

baz()
{
   ...
   ...
   if(...) foo();
   ...
}

как делить будешь? Можно сделать параметрические модули (в Racket это называется Unit), но тогда использовать становится намного менее удобно.

Возможно, все таки нужен какой-то конфиг для пакеты/сборки.

А что там должно быть написано?

самая интересная по моему мнению система модулей в Go

Что в ней интересного?

Возможно она наиболее близка к идеальной

Почему?

А что там должно быть написано?

Ну что-то вроде этого(и ниже) https://packaging.python.org/en/latest/distributing/#name Если я правильно понял вашу дискуссию

Зависимости так же иногда лучше прописать явно. ИМХО.

https://ru.wikipedia.org/wiki/Язык_модулей_ML

Почему же оно не взлетело?

Rust и Cargo же.

Rust и Cargo же.

Судя по https://github.com/servo/servo/blob/master/components/layout/flex.rs чересчур многословно

...
use flow;
use flow::INLINE_POSITION_IS_STATIC;
use flow::IS_ABSOLUTELY_POSITIONED;
use flow::ImmutableFlowUtils;
use flow::mut_base;
use flow::{Flow, FlowClass, OpaqueFlow};
use flow::{HAS_LEFT_FLOATED_DESCENDANTS, HAS_RIGHT_FLOATED_DESCENDANTS};
...

и писали бы на красивых и мощных функциональных языках.

Часто слышно об этом. Но я вот моде поддался, изучил функциональщину(haskell, ocaml, erlang, scala из гибридов), но честно говоря разочарован... Ничего тут особо хорошего нет. И на ОО-языках можно встретить красивые с инженерной точки зрения системы. И в функциональщину ничего особенного нет.

в нашем мире идеал типичного современного «программиста»

Ну расскажи про идеал старорежимного Программиста (с придыханием). Це, паскаль, фортран? Там то конечно лямбд полные штаны, да?

Ну расскажи про идеал старорежимного Программиста (с придыханием). Це, паскаль, фортран? Там то конечно лямбд полные штаны, да?

Лисп, очевидно. С 1984 года.

А лисп тогда использовали? Просто сейчас как-то не очень.

но самая интересная по моему мнению система модулей в Go

А что именно вызвало интерес?

Это там экспортируемость имени определяется кейсом его первой буквы?

Странное решение.

Во-первых, могут быть несколько мелких модулей, которые в одном файле наглядней.

Может быть не модулей, а пространств имен?

тесты удобно делать подмодулем и держать в том же файле (так как писать их надо параллельно с кодом).

Мне удобно писать в отдельном файле. Хотя бы потому, что переключаться между файлами и смотреть их вместе проще, чем скакать с места на место в одном большом. Да и код не захламляется.

как делить будешь?

А надо ли делить? Если у нас модуль настолько большой, что его хочется разнести по многим файлам, то вряд ли там прямо все так сильно переплетено. Это уже похоже на ошибку дизайна. Мне кажется, что система модулей не должна такое поощрять

А что там должно быть написано?

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

А лисп тогда использовали?

Использовали.

Были лисп-машины: https://en.wikipedia.org/wiki/AI_winter#The_collapse_of_the_Lisp_machine_mark...

Потом ещё некоторое время был просто лисп, но разработку AI свернули, а с ней и лисп.

Судя по https://github.com/servo/servo/blob/master/components/layout/flex.rs чересчур многословно

А мне кажется, что там:

При импорте имена можно добавлять как есть (все; списком; все, кроме списка), добавлять с явным префиксом, добавлять с переименованием отдельных имён.

Может быть не модулей, а пространств имен?

Модулей. У них есть экспорт и импорт.

Это уже похоже на ошибку дизайна.

Не всегда. Например, есть окно, а у него есть меню. В меню есть пункт «новое окно», которые создаёт новое такое же окно. Как разделить меню и окно? А кода описания у обоих может быть достаточно много.

На самом деле, есть разные пути обхода. Можно так: https://docs.racket-lang.org/guide/Linking_Units.html. Можно передавать нужную функцию параметром: make_main_menu(&make_main_window). Можно на уровне языка разрешить циклы в зависимостях (тогда цикл компилируется всегда как одна единица компиляции). Ну или разрешить вставлять через include.

Название, описание, версия, зависимости

Понял. Согласен. В Racket есть https://docs.racket-lang.org/pkg/metadata.html . Зависимости там не между модулями, а от других пакетов (что надо скачать и установить, чтобы пакет установился).

А мне кажется, что там

Если судить по документации, то должно быть годно. Разве что разделение на extern crate и use непонятно зачем.

как делить будешь?

Я об этом спрашивал в одной из прошлых тем и я даже знаю, как это делается в жизни: в интерфейс выносится достаточно функций, чтобы цикл разорвался, а дальше делается взаимная зависимость реализации модулей от интерфейса каждого из них. В С и Паскале это делается элементарно и используется постоянно, но меня попросили привести примеры и в итоге никто меня не понял. Правда, я ошибочно называл это «циклической зависимостью реализаций», но могли бы и догадаться :)

Проблема здесь состоит в том, что разбивать модуль - это довольно большая работа. Неплохо бы иметь инструмент, который это автоматизирует. Относится ли эта поддержка этой задачи к системе модулей?

А надо ли делить? Если у нас модуль настолько большой, что его хочется разнести по многим файлам, то вряд ли там прямо все так сильно переплетено. Это уже похоже на ошибку дизайна. Мне кажется, что система модулей не должна такое поощрять

Вот мы опять наблюдаем ту же безграмотность. Начитались люди книжек, а жизни не знают.

Мне вот интересно, если можно добавлять имена с переименовыванием, то есть ли там поиск по файлам. Уже само наличие пространств имён сильно затрудняет поиск. Виртуальные функции ещё затрудняют. Если ещё ввести переименовывание, то как вообще можно изучать код? Хотелось бы услышать об этом от тех, кто практически применяет это переименовывание.

А мне кажется, что там: ... можно добавлять как есть (все; списком; все, кроме списка),

«всё, кроме списка» там нет. Есть только всё и «в списке». Вот поэтому и многословно. Там где в Racket я просто напишу (requre foo (except-in bar foobar)) в Rust придётся явно указывать все символы, импортированные из foo и bar, если есть хоть одно пересечение.

Если ещё ввести переименовывание, то как вообще можно изучать код? Хотелось бы услышать об этом от тех, кто практически применяет это переименовывание.

Применяю в Racket сплошь и рядом. Стандартная IDE DrRacket позволяет перейти к модулю или определению символа (а также документации по ним) вне зависимости от используемого имени.

Не всегда. Например, есть окно, а у него есть меню. В меню есть пункт «новое окно», которые создаёт новое такое же окно.

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

Вообще, если есть такой цикл, то это или сильное сцепление и два модуля по факту должны быть одним, или косяк проектирования.

Я спрашиваю про поиск использований.

В реальных гуйнях, меню ничего не знает про создание окна и это делается в третьем прикладном модуле (в собственно приложении)

Так я про кусок в приложении, описывающий меню (все действия по пунктам меню и его структуру) + кусок, описывающий окно. Эти два куска нельзя вынести в модули, а желательно в одном модуле не более 1000 строк иметь.

Вообще, если есть такой цикл, то это или сильное сцепление и два модуля по факту должны быть одним, или косяк проектирования.

Сильное сцепление. Вот поэтому иногда желательны методы разбиения такого мега-модуля на файлы: Идеальная система модулей в языке программирования (комментарий)

поиск использований

Внутри одного модуля — тривиально (все переименования вверху). В каталоге — никогда не было нужно, если честно. В принципе, можно написать (загрузка через racket синтаксического дерева + сравнение по идентификатору)

Я всё больше подозреваю, что я с другой планеты. Мне это всегда нужно. Поиск вхождений - это одна из наиболее нужных и часто используемых мной «процедур» по ходу разработки-переработки. Что я делаю не так?

а желательно в одном модуле не более 1000 строк иметь.

Бизнес логика должна быть не в этом модуле. У тебя опять ошибка проектирования.

Лисп, очевидно.

Нет уж, лисп такой же академический, как и всякие MLи, и мерилом сферического программиста эпохи быть не может. На самом деле функциональщины, так воспеваемой илиткой, в современных быдлоязычках куда больше. И любая веб-макака сейчас использует более мощные абстракции и пишет изящнее, чем яйцеголовые умники прошлого века.

Бизнес логика должна быть не в этом модуле.

При чём тут бизнес логика?

Общее количество пунктов меню — около 300, описание каждого — 2-3 строки, даже без тела обработчика.

Общее количество элементов в главном окне тоже около 100. Чистого описания минимум строк на 500.

По-отдельности терпимо, вместе — перебор. А если обработчики пунктов меню ещё и должны взаимодействовать с областями главного окна, а не просто выполнять действия и отображать результат (в виде нового объекта), то всё становится совсем грустно.

Если же ограничения на разбивку по файлам нет, то можно вполне разумно разбить по темам.

И любая веб-макака сейчас использует более мощные абстракции и пишет изящнее, чем яйцеголовые умники прошлого века.

JavaScript? Соглашусь.

Поиск вхождений - это одна из наиболее нужных и часто используемых мной «процедур» по ходу разработки-переработки. Что я делаю не так?

Можешь рассказать, для чего это используешь? Мне разумной причины искать все использования в каталоге какой-либо функции в голову не приходит.

Мне разумной причины искать все использования в каталоге какой-либо функции в голову не приходит.

Вспомнил единственный пример: у какой-то функции не очень понял зачем она нужна по описанию в документации, и так как встроенная, то исходника нет.

Но там искал просто по имени, так как библиотечные редко переименовывают.

В теории неплохи модули в SML. На практике - в Python.

Я всё больше подозреваю, что я с другой планеты. Мне это всегда нужно. Поиск вхождений - это одна из наиболее нужных и часто используемых мной «процедур» по ходу разработки-переработки. Что я делаю не так?

Искать по связыванию (free-identifier=?), как выше monk сказал. Но придется написать специальный костыль для иде, т.к. дефолтно его нет.

И, собственно, в каком контексте тебе приходится искать вхождения? Зачем?

Можешь рассказать, для чего это используешь?

Неужели тебя никогда не интересует вопрос, где используется твоя функция? Я просто не могу это уложить в голове.

1. Хочу переименовать.

2. Предполагаю, что ф-я устарела и хочу узнать, не используется ли она где-нибудь.

(free-identifier=?), как выше monk сказал

Где он так сказал?

1. Хочу переименовать.

2. Предполагаю, что ф-я устарела и хочу узнать, не используется ли она где-нибудь.

Я просто убираю из экспорта, делаю make и смотрю, где ругаться начало. Так быстрее, чем делать поиск. Кстати, даже без переименования, какой regexp искать, чтобы найти, где используется идентификатор «a» я тоже с трудом представляю.

Где он так сказал?

Идеальная система модулей в языке программирования (комментарий)

Я просто убираю из экспорта, делаю make и смотрю, где ругаться начало

Тебе повезло с компилятором.

1. А если у тебя много проектов?

2. А если позднее связывание (например, tcl, sql, apply, пользовательские скрипты, конфиг.файлы)?

3. А если медленный компилятор?

4. А если компилятор покажет 2-3 ошибки и запнётся, а вхождений 100, ты так и будешь 30-50 раз запускать сборку? Неужели 1 раз найти это дольше чем 30 раз запустить сборку?

какой regexp искать, чтобы найти, где используется идентификатор «a» я тоже с трудом представляю.

regexp-ы Бог послал людям за съеденный плод, помимо терний и прочих неприятностей. «Поиск по словам».

А у меня в clcon есть «поиск лиспового идентификатора», который учитывает специфику синтаксиса лиспа. Правда, не будет работать для эскейпенных идентификаторов.

1. А если у тебя много проектов?

Поиск по многим каталогам ничем не отличается от make по тем же каталогам

2. А если позднее связывание (например, tcl, sql, apply, пользовательские скрипты, конфиг.файлы)?

Так проверка по символам, а не по их значениям. Символ либо определён в данном контексте (через define или let) либо импортирован. Если ни того ни другого нет, значит неизвестен. Или ты про eval?

3. А если медленный компилятор?

Перекомпилруются только те модули у которых изменённый прописан в зависимостях (импорте). Синтаксический анализ — самая быстрая часть компиляции (по сути это команда read-syntax). Если идентификатор не найден, то на этом компиляция заканчивается.

4. А если компилятор покажет 2-3 ошибки и запнётся, а вхождений 100, ты так и будешь 30-50 раз запускать сборку

Если я уже открыл модуль, то я могу переименовать символ при импорте или переименовать его по всему модулю. DrRacket имеет стандартную функцию. Причём переименование нормальное. То есть

(require (only-in foo x))

(displayln x)
(myfunc x)
(let ([x 2])
  (myfunc x))

(define (bar x) (+ x 1))

При переименовании x -> y (того, который в displayln) превратится в

(require (only-in foo y))

(displayln y)
(myfunc y)
(let ([x 2])
  (myfunc x))

(define (bar x) (+ x 1))

Там где «сравнение по идентификатору».

Или ты про eval?

Да, про него, родимого.

Бизнес логика притом что я насмотрелся джанговских моделек на 2к строк. Никогда никакого смысла в этом не было.

А в твоем случае прям все-все сцеплено? Не верю. В любом случае мультифайловые модули проблему не решат. Вместо одной большой кучи будет такая же, только с несколькими названиями. А поощрение только усугубит ситуацию.

А в твоем случае прям все-все сцеплено? Не верю.

Почему всё-всё? Всего лишь одна ссылка из меню на окно и одна из окна на меню. Этого уже достаточно, чтобы эти два блока пришлось писать в одном модуле.