# Bill, draft, ideas

- we have too many repositories
- a repository can contain more than one Julia package / project
- developers and users do not need/use to see the same interface
- what is ANTIC?
- there is a (small) c-library
- c-libraries attract more potential users than julia
- c is more efficient (in some cases)
- c is a black box, it becomes static contents with a slow release cycle
- additional dependency
- is Nemo part of ANTIC?
- to extend ANTIC (main cornerstone)
- include/ rebrand Hecke (Tommy?)
- carefully define/ restrict scope
- Carlos stuff, GaloisGroup require GAP, thus either Oscar or re-write groups
- modular MPoly{nf} and Poly{nf}: ANTIC? Oscar?
- Quadratic forms (Tommy): is this ANTIC? What is ANTIC?
- we are NOT Julia, we're using and contributing, but we are NOT Julia. Our needs and requirements are different, thus their development model is not ours:
- we need parents, Julia does not
- we cannot "just" use Julias LinAlg: too much becomes a float, cannot deal with empty matrices (type again)
- the distinction between constructors and functions is far less clear to us
- our type names flaunt Julia convention already
- our goal is mainly algebra (discrete, exact), not numerics (continuous, approximate)
- funding commitment (DFG (SFB), RLP) is Oscar, maybe with NFDI also data preservation, BUT the key focus is mathematics, not software engineering
- need to focus more on maths, not on technical issues
- technical issues are important, but results count
- users (my opinion) crave functionality, not style or governance
- to me: most discussions about programming style are massively off-putting, especially as the style can be automatically adjusted easily
- also off-putting: improvements that are rejected because they do not solve all problems (eg. fixing a buggy function followed by complaints that there is no doc or test, when neither was there before...)
- interfaces developed without use-case tend to be incomplete, sub-optimal at best.
- funding goals
- B1: Oscar
- B2: number theory, branded as ANTIC, but only possible in Oscar,
none of the goals can be achieved without at least Gap, thus Oscar
- B5: Singular, NOT Singular.jl (unfortunately)
- B?: Polymake, NOT Polymake.jl (...)
- B7: Gap-ish, closely linked to Oscar
Thus we can split Oscar into AA/Nemo/Lib???/.... iff it helps us at all
Questions:
- what are the advantages of independent projects AA/Nemo/...?
- possibly more collaborators interested in only one aspect
- smaller modules might be of use to more projects
- disadvantages:
- coordination: all "our" projects need to support OUR goals, hence basically need to be Oscar compatible: cool features outside our conventions (e.g. including more symbolic stuff, investing into dead-ends (general groups outside Gap, linear inequalities outside Polymake, ...) does NOT help us
- coordination: developing project A, depending on project B will require patches to project B: so far, none of our projects has a feature complete usable API. Talk again in few years, but currently not.
Thus having to align project A to the development cycle of project B, incuring administrative overhead, time delays, ... is not helpful. This will continue to drive hacks in A, rather than pull requests against B.
To argue this implies to apply for changes in human nature.
To solve this we need some of
- master against master
- mono-repo (well fewer repos)
- pay s.o. to move the A-hacks into B at a later stage, with all the fun of coordinated, staggered changes to different projects
This all contradicts the idea of independent small projects...
- coordination: upwards testing: I am only doing A, why do I need to take B into account?
- code duplication/ overhead: n endproducts require
- n independent documentation
- n independent user interfaces (possibly different)
- n independent issues/ user-groups/ styles/ ...
- n different naming/ coding/ testing conventions
- n independent marketing campaigns
-