I guess we fundamentally disagree on what the core problem is. I think that incorporating (much) mathematical knowledge in an algorithmic context, in a practical, accessible framework is the core problem.
The thought that all of mathematics would fall at your feet if you only had the right programming language has been pursued unsuccessfully for many years, going back to IBM’s Scratchpad, and even continuing to this day where Wolfram seems to think that his Language should be used for everything. I think his language is hard to read/write/understand, and is of little intrinsic interest if it didn’t have interesting symbolic / graphical / etc commands as part of the system.
As far as being a natural language for direct embedding, Julia seems to fail your core principle even on the simple example of 3/4. I am unfamiliar with other details, but I suppose you could argue on what “natural” means.
If Python and SymPy were to be made 10,000x faster, and given better numerical libraries, would Julia symbolics be unnecessary? what about 10x?
I looked at the paper to which you refer. There are far too many references to systems I am not familiar with, and my very limited acquaintance with DAE (differential algebraic equations) is many decades old.
I can say that the idea of generating numeric code from a CAS has been visited repeatedly (Google for Gentran Maxima), with the option of generating FORTRAN or C. It is also possible (without Gentran) to develop numerical code to be compiled in Lisp, but for people who have a huge investment in C or Fortran “solvers”, this Lisp mode is not appealing. Also (although not inevitably) the compiled Lisp numeric code is relatively naive with respect to multiprocessing or GPUs, and
so may be slower than (serial C) by a factor than depends on the quality of the compilers involved.
So it would seem that the big deal is that your version of Gentran-in-Julia can generate numeric-code-in-Julia rather than C or FORTRAN. (or, I suppose in Python). It is that latter prospect which gives you leave to say 10,000x faster — Python fans are generating long-running purely numerical code in an interpretive system. (could they use Cython and fix all of that?)
It seems that the right comparison for symbolics in Julia is to other packages in the business of modeling and differential equation solving, maybe electrical/mechanical computer-aided design. Not really what I study, though apparently of some significant interest. To compare it to a monster like Mathematica doesn’t make so much sense (although Mathematica fans may stray into some Modelica-in-Mathematica territory, I would not expect that to be effectively implemented totally in the “Wolfram Language”. ) If symbolics in Julia can just represent expressions on their way to being compiled for numerical evaluation, and has only rudimental facilities in core techniques (like simplification), it might be ok for your use. I would, however, suggest a look at gentran-like activities.
Good luck.
RJF