То есть когда это уже последний шаг, то да, имеет смысл NamedTuple заменить на структуру.

А в разработке NamedTuple немного удобней.

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

Ах да, если захочется потом поменять какое-то из «глобальных» значений, то тогда удобно Setfield.jl пользоваться

myopts = @set opts.M = 10
f(opts = myopts)

То есть unpack + setfield + NamedTuple это очень мощный способ писать код, который выглядит как если бы использовались глобальные переменные, но без глобальных переменных.

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

Студентам объяснять надо про зоны ответственности и про виды зависимостей в коде.

А что значит «та же проблема, если все тащить в аргументы функции»? Видимо мы разные проблемы имеем в виду, потому что с моей точки зрения основные проблемы глобальных переменных это
1. Контекстная зависимость функций (с одним и тем же наборов аргументов будете получать разные ответы в зависимости от значения глобальных переменных)
2. Как следствие первого пункта фактический не thread safe , то есть код невозможно паралеллизовать
3. Сложность для анализа кода, так как чтобы понять, что он делает нужно по всему коду прыгать и ловить кто и в какой момент устанавливает и меняет глобальные переменные
4. Сложность тестирования таких функций.

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

К чистым функциям студентов ещё надо приучить. Как и выделять переменные там, где они нужны. Мои студенты, например, на запрет использования for (в Ruby) начинают использовать map! и очень возмущаются, что заставляю переделывать. Стандартный ответ:  “ну работает же….”

Я бы еще добавил пункт 5 (связанный с пунктом1): Функции с глобальными переменными нельзя поместить в библиотеку функций для повторного использования, в родственных, может быть, но других программах.

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

Потому что в 99% случаях это будет трактоваться так: есть способ с глобальными переменными, простой и понятный, а есть другой, более хороший и сложный. Но я слишком ленивый/глупый/занятой, чтобы его изучать. Поэтому буду пользоваться тем, что понял «ведь работает же и вы сами на лекциях показывали»

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

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

2. Это не свойство глобальности/локальности, а изменяемости, т.к. параллелизовать можно любые immutable структуры.

3. Зависит от количества глобальных переменных и насколько понятно они названы. Локальные переменные тоже можно наплодить так, что код будет нечитаем. "ловить кто и в какой момент устанавливает и меняет" - какая тогда разница, что глобальные переменные обернуты в NamedTuple, если вы все равно используете их где угодно внутри функций и меняете с помощью @setfield?

4. Это не всегда так. Это зависит от гранулярности тестов и много чего еще. Кто мешает тестировать модули, в которых уже определены глобальные переменные?

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

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

Ну а для студента проще объяснить "не используй вообще"

:+1:

Говоря о функции со многими параметрами, как можно её broadcast по одному из аргументов? Я придумал только завернуть в лямбду и потом в map. Есть более правильный способ?

Ref

Это вроде даже официальный способ

То есть все аргументы, которые не надо броадкастить (а они хотят) надо в Ref заворачивать