Нубское мнение: для работы в команде хотелось бы указания полей в абстрактных типах. А то "договариваться" приходится внешними средствами..

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

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

Да это было бы интересно! Я больше про то, что те, кто привык к java в которой довольно легко работать в команде ,т.к. ,к примеру, реализацию абстрактного класса практически невозможно сделать "не так", с ужасом смотрят на необходимость прописывать в документации  спецификацию типов. Особенно если автор это не сделал, то поди знай что должно быть внутри структуры, что бы все работало как надо.

По уму если есть завязка на какие-то поля абстрактного класса, то они должны быть оформлены геттерами/сеттерами. В принципе можно и getproperty перегружать но это менее очевидно выглядит. Т.е. если предполагается что у абстрактного класса AbsA есть поле a, то это оформляется через get_a(::AbsA), set_a!(::AbsA, value). Это развязывает руки конкретным релаизациям, т.е. например get_a(obj::A1) = obj.a         get_a(obj::A2) = obj.b+obj.c - obj.e

Это если все знаю что так надо делать :) я не знаю - есть ли какой-нибудь копоративный стандарт разработки на julia?

А в Яве нет в бест практиках использования геттеров/сеттеров вместо прямого обращения к полям?

Оно по-моему вообще везде в общих рекомндациях 🙂 Ровно потому что прямое обращение извне к внутренностям класса/структуры создает слишком жесткую связь

Прямой доступ к полям объекта - это прямой запрет ООП. Другое дело, что явно прописывать getter/setter на надо. В Java есть Lombok. А, начиная с Java14, появились Java Records

Есть вот такое: https://github.com/invenia/BlueStyle

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

Vladimir а если не секрет, где потребовался корпоративный стандарт джулии и идет разработка командой? 🙂

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

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

Да про стабилити речь была скорее)

Хм, мне это немного напоминает недавний тред на дискурсе, где люди обсуждали, что Джулия им не подходит потому что нет модулей как в питоне (ну или что-то типа такого). И прямо такие ужасы рассказывали, какая у них жуткая нагрузка на мозг идёт, из-за того, что приходится думать как по файлам программу раскидать, что прямо хоть ложись и помирай.

По моим ощущениям проблема структурирования программы по файлам составляет меньше 1% от всей разработки, поэтому такого сорта утверждения достаточно странно выглядят (ну то есть если бы была идеальная система, то это сэкономило бы 1% сил, что фактически никак не отразится на конечном времени разработки).

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

Да не, какой там... Но конечно хотелось бы на такие проекты посмотреть... Вот Pumas, к примеру... явно же у них есть какой-то свой кодекс.

да уж, здоровенный тред там получился :)
вообще иногда хочется чего-то "между" просто файлами и отдельными пакетами, с модулями внутри пакета не всегда удобно работать
но это мелочи, можно обойти конечно

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