Needs a timeframe and context. Back in the, say, 1990s or maybe even early 2000s, when the modern world was just forming and the only languages students would work in were C and C++, maybe with some Bash and Perl on the side, 25k lines is a reasonable estimate for a brand new symbolic engine- a thing that in imperative languages didn't exist- with some element of typical PhD edge case over-engineering.
25k lines in fact could be considered small for that sort of C++ engine.
But it would have been reasonable at the time to explore the type system around such a thing and produce a PhD (or a couple of PhDs) from it over a period of a few years.
Of course even at that time there was prior art in the Lisp world, but after the AI winter 1980s no students were going to work in Lisp. C++ was where the jobs were going to be.
>Needs a timeframe and context. Back in the, say, 1990s or maybe even early 2000s, when the modern world was just forming and the only languages students would work in were C and C++, maybe with some Bash and Perl on the side, 25k lines is a reasonable estimate for a brand new symbolic engine- a thing that in imperative languages didn't exist- with some element of typical PhD edge case over-engineering.
The modern world was very much formed by the 90s. Mathematica, Axiom, Maple, etc were all mature software written a decade or more ago. What people were doing wasn't writing a CAS from scratch but writing one that could slot into whatever program they needed at the time, e.g. chaotic simulation of the solar system: https://en.wikipedia.org/wiki/Structure_and_Interpretation_o...
Mathematica is a comprehensive symbolic manipulation engine and functional programming language written by a physicist starting in the late 70s. It has been used to solve various real world physics problems since the early 80s. It has been commercially available since 1988.
Norvig's Paradigms of Artificial Intelligence Programming has a nice little Common Lisp program that parses word problems and converts them to a system of equations which it proceeds to solve.
It's got numerous limitations but it is definitely a small program.
>Where do you even begin decompressing a claim like this?
Start writing the code and see where it takes you. Having done that type of work in grad school I moved from C++ to Guile for exploratory work for that very reason.
I then rewrote the slow bits in C as custom functions much like how you would in Python.
This has been my experience with music programming as well, music (not audio - music) being a highly symbolic domain. The past-me that had not experienced first class symbolic programming support would not have believed how much easier it is in a symbolic language (in my case Scheme). The size of my music code in Scheme compared to C/C++ or Python is an order of magnitude smaller.
Check out the course outline as well as the links on “Lectures with drawings”, “Vocabulary” and “Directory for Program Files”. There are also some links to Clojure resources in there that may be useful as well as some study guides and questions.
I might just try to work through the PDF, looks like a pretty interesting course.
• Ordinary programming: 5 person-years by two PhD students; 25,000 lines of C++.
• Symbolic Programming: 200 lines, a few days.
Where do you even begin decompressing a claim like this?