axiom-developer
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Axiom musings...


From: Tim Daly
Subject: Axiom musings...
Date: Mon, 28 Sep 2020 03:03:20 -0400

(https://groups.google.com/g/fricas-devel/c/lF4w9MduSVg)

-- <rant> There is quality called "cohesion" or "conceptual
-- integrity" meaning that parts of system follow common
-- design and compose into coherent whole. I could list
-- rather long list of design choices made in Axiom time
-- that I am not happy about. But I keep most of them,
-- because current choices play together reasonably well.
-- Change which improves one aspect can make other things
-- worse and balance may be negative. There is also
-- reality factor: some changes need a lot of work to
-- implement correctly and partial, incomplete change can
-- make things worse. Due to modularity of Spad incompatible
-- changes can coexist in different packages, but this is
-- suboptimal situation, leading to duplicate developement
-- effort and user confusion.
-- </rant>

-- 
-- Waldek Hebisch

<rant in reply>

Scratchpad was developed from software that was just a few
years away from the suggestion that GOTO was considered
harmful and "structured programming" was still discussed.

Scratchpad pushed the state of the art, based on CLU (Liskov)
with features such as (to quote Wikipedia)  "abstract data types,
call-by-sharing, iterators, multiple return values (a form of
parallel assignment), type-safe parameterized types, and
type-safe variant types. It is also notable for its use of
classes with constructors and methods, but without inheritance."
Scratchpad pushed the state of the art by basing on group theory,
not rewrite rules (e.g.MMA).

The Scratchpad project was a RESEARCH project. For a while
I had to replace the parser every week with the new, new,
new, new. new parser. Everyone had a suggestion for
some new feature or some different output or some
strange syntax. "Which new parser?" was a running gag
in the group. Bill Burge was very busy making new ones,
exploiting his own research interest (zipper parsing).

I sent magnetic tapes to people who wanted copies of
the software (including source code). There was no plan
to release the code as a product. Each of us had our own
idea of what was important. Mine was to rewrite the system
so it ran on "common lisp", but common lisp was still just
an X3J13 proposal that was being reviewed (I still have my
review copies that I marked up) so the language was not
stable. We had a contract with William Schelter to create a
version of common lisp, which was also changed weekly.
Scratchpad ran on 12 different "common lisps", all from the
same source tree.

We were told that Scratchpad was going to be shut down.
We asked to have it made into a product, which involved
working with Sales and Marketing. Sales, insisting that there
were a dozen "required" manuals (e.g. User, Installation,
Internals, etc.), all of which had documentation standards.

Furthermore, all of the manuals had to be written to the 8th
grade level (about a 13 year old child). Somehow we didn't
think that we could write about differential equations that
could pass that criteria (which was enfored by software
that Sales used to ensure we didn't use big words). All
we had time for was a single book.

You've had the system for 12 years and are just now
trying to recover a book that took us a couple months to
write. You have almost no new documentation. I don't
understand how you expect the system to survive the
day you stop working on it, given that "lisp code" seems
to be too hard to read and only about 3 people speak
"boot code".

I got Scratchpad running on a laptop running DOS, which
was the state of the art at the time for personal computers.
Otherwise it had to run on "workstations" (multi-thousand
dollar computers), like a Symbolics machine or RS6000.

We had no warning that Scratchpad would be stopped
and we were trying very hard to turn research software
into something that "just worked" for anyone when, at
times, it barely worked for us due to the latest hack.

So ranting about how bad it is, or poorly designed, or
how it could be so much better just missed the fact that
an astonishing amount of effort went into cleaning it up
and selling it at the very last moment. We all wanted
more and IBM forced us to stop working on it.

Of course Axiom could be so much better. That's what
the new SANE effort is working on. Categories are first
class objects, able to be created and used at run time,
for example. The internals are strongly typed using the
latest dependent type theory. The design allows proofs
and specifications to accompany algorithms. The internals
and externals are designed to be trusted "down to the metal".
Coercions are true functors (in the category theory sense).

The Groebner basis proof was done years ago in Coq
(https://www.ricam.oeaw.ac.at/specsem/srs/groeb/download/coq-linz.pdf)
(https://hal.inria.fr/inria-00504727/document)

This work existed in 2008, well over a decade old,
near the time of the great fork. Surely your "new, improved"
system would be able to incorporate this proof by now and
be able to manipulate it, right? It's been available for
12 years and you have a whole team.

Rewriting pieces of the interpreter or compiler happened
every week. I don't understand why this is considered hard.

You're still using "compress.daase" which I wrote so I could
put Scratchpad on floppy disks. It has no use now other than
wasting CPU, I/O, and disk space. Removing it takes an hour
or two.

In fact, the whole 'daase' idea needs to disappear. It was written
to optimize random access to hard drives, something that is
meaningless on SSDs. In fact, the databases are so small
they should be "in core" at all times. Removing this should
also take an hour or two, again saving CPU and I/O time.

I optimized the whole database access code into a single
(documented) function so the rewrite would be completely
local and transparent (gosh, it might be a rare bit of
"conceptual integrity"?)

In 40 years software development has changed a lot.
Complaining about "poor" design of software from the
last century ignores that these ideas didn't even exist
at the time Scratchpad was written.

It seems to me to be the height of arrogance to complain
that software from the 1980s, saved from near death 3
times (sale to NAG, rebuild into free (2000), and surviving
a fork (2007)), is a source of complaint about its design.
If Scratchpad had been worked on by the original group
until now it would be much better.

You have had the source code for 12 years, which is
longer than the Scratchpad project existed. You could
have rewritten it completely by now...
but compress.daase still exists.

</rant>

Tim



reply via email to

[Prev in Thread] Current Thread [Next in Thread]