I agree, this code is horrendous! It is like trying to read one of those code golf answers. Author seems to pride themselves on a proficiency for packing as much as possible in to one line, which is not a good thing in my opinion. I do think it was reasonably well commented though compared to code that I am used to working on (in games). At least they expressed basically what they were trying to do before each block of code, with references to specific algorithm names etc. The single letter variables didn't bother me as much in this context since a lot of those seemed to be loop indices which are only used in a small scope, or mathematical quantities that you would be familiar with from reading some algorithms standard description but they don't have an easy way to express in English. Definitely agree with you about all the regex nonsense though. To me that has no place in a math related library
As an aside: I knew a maths major student who would keep his entire year of handwritten lecture notes on a single A4 page of paper. It always fit! The Ganja.js coding style reminds me of that guy.
On a more serious note, GA computing has several orthogonal aspects to it, some of which have very different programming requirements:
* Converting GA expressions, e.g.: "x ^ e_o times y ^ e_1" into a single expression.
* The above requires either an expression parser, or an AST accessible from code, or both.
* A general multivector type at compile time to compute the results of those expressions. This one doesn't require any special optimisation.
* An expression simplification library, like a mini computer algebra system (CAS) to simplify the resulting elements after all of the high-level geometric products are carried out. This is important to eliminate a bunch of multiplications by zero, double negation, etc...
* A code-generation module to produce the final, optimised library for the runtime. This has to have a bunch of features to be competitive with Vector algebra 3D libraries. Many of these features are output language dependent. For example, it makes sense to have packed multi-vectors, sparse multivectors, a native array-of-multivectors type, etc...
In my mind, there are two main types of code in such a library: The first is the pure functional maths stuff, which is mostly the computation of some lookup tables and lists of lists of things. This is mostly static and needs standardisation. The second type of code is typically impure and needs to have a clean API to make it extensible/pluggable: parsing, code-gen, SIMD, optimisation, etc... E.g.: SIMD changes over time, there may need to be multiple optimisation passes, you may want to interact with an imperative compiler interface like LLVM or Roslyn, etc...
One of the issues I have with Ganja.js (that isn't about syntax formatting) is that is interleaves these largely orthogonal concepts. The strings from the parser flow through much of the code, making the entire thing a stringly-typed mess.
Enki Mute is clearly a mathematician, not a software developer. I can tell he's never had to write code intended to be used by others.
While these disciplines have a lot of overlap, CS is mostly about cooperating successfully with other humans. Mathematics is mostly about correctness... and that's about it. You can publish whatever you want, it doesn't have to have doc-comments, it doesn't need to be modular, or reusable, or anything other than not wrong and maybe interesting.
