Re: [Axiom-developer] BAD tim

[root]

> Hello everybody,

Hey, Scott! 

> 
> This is my first posting to this list. I worked at IBM Research off and on
> for 9 years. I'm the primary author/designer of the interpreter and
> HyperDoc, and I wrote the first code generator and optimizer for Aldor 
> (then called A#).
> 
> I found Tim's posting very interesting, and I just had to comment.
> 
> >>POINT 3: Boot is a dead language.
> >>
> >>   There are approximately 10 people still living who have coded in
> >>   boot and every one of them is doing something else with their
> >>   life.
> 
> 
> Being one of those 10 people, I have to agree with Tim and his opinion of
> the Boot language. Dick Jenks told me that boot was to be the first step in
> implementing the entire system in the Spad language. Once the syntax looked
> like Spad, the next step would be to convert it to real Spad. Of course 
> that never happened, so the main purpose behind Boot is gone.
> 
> In my opinion Boot can be a convenient language to code in, but it has two
> main problems. The use of indentation for grouping is just a bad idea. It
> works well for one-page programs, but with anything with reasonable
> complexity, it falls down. Just adding braces to Boot for grouping would go
> a long way to making it more usable. The other problem is the lack of a way
> to structure data. I fully agree with Tim on the problems with that
> language.

ah, right. i forgot about the "larger than one page" issue. i can count
characters by eye but i can't count whitespace. i used to convert the
whitespace to periods so i could get proper indentation in spad code.

the other "oh by the way" is that while you can seem to read boot code
without knowing lisp (a sort-of pseudocode syntax) you can't WRITE boot
code without knowing lisp. 

> 
> >>I'm the only person likely to be hacking
> >>   the interpreter for the near future, mostly because it is so big,
> >>   ugly, unstructured, and undocumented.
> 
> Ouch. The truth hurts. Believe me, when I started writing the interpreter
> some 21 years ago, I never imagined it would have such a long life. This 
> was my first major programming project out of college. After 20 years of
> experience, I would do a lot of things differently today. These days I'm too
> busy with my current job (graphics programming at Audtodesk) to be able to
> devote any time to the Axiom project.

hey, scott, that was not intended to be a flame directed at you.
you're one of the best programmers i've crossed path with in the
last 35 years. one indication is that you seem to still be programming
rather than retired into manangement.

the axiom system grew by accretion and was intended to be a research
platform rather than a product so we were all doing good-enough patch
jobs. of course in my experience most real products are just as bad
but the code never sees the light of day. i suspect that's what keeps
some products proprietary :-)

i never thought axiom would live this long either or i'd have at least 
included a docstring to give me some clue why i wrote some functions.
or taken my name out of the sources :-)

one big reason behind the literate programming push is my undying 
embarrassment over how bad my coding/nondocumenting style was 20 years ago. 
i don't write anything now unless it's in a literate style.


> 
> >>There is no reason (other than historical) why there are
> >>   a dozen entry points into the interpreter that set wierd, undocumented=
> ,
> >>   stateful flags. All that cruft must go away.
> 
> Good luck Tim. As the author of much of this cruft, I think you have your
> work cut out for you. Maintaining functionality while refactoring the code
> will be a major challenge. Your two year estimate seems about right if you
> are planning on working on this full time. If not, I think two years is
> optimistic.
> 
> I think the transition from Boot to Lisp could be done in an incremental
> way, converting modules gradually, thus maintaining the integrity of the
> system during the conversion. However, I agree that converting to Lisp
> ultimately is the right thing to do.

i am doing this in an incremental manner, actually. the lastest release
axiom--main--1--patch-46 removes two original files and adds a new
volume in the axiom book (book volume 5) which contains the actual
source code along with new documentation. each section of the book
will move some code from existing files in an incremental manner.
so the system will continue to build while slowly being converted.

the original book has been broken into 4 parts (not yet integrated):

v1 tutorial, v2 programming, v3 reference, v4 developer's guide

and the other volumes will (at least at this point in the plan) be
something like:

v5 interpreter, v6 compiler, v7 browser, v8 graphics, v9 algebra

so the whole system will be just a series of books. the focus in the
books will be toward human understanding of the code. extracting the
code for the machine is secondary but it's important that the ACTUAL
code be in the books and not some handwaving pseudocode.

eventually writing axiom code will be an "authoring" job rather than
a programming job,

> 
> I'm on the axiom-developer list now, so I can answer the occasional
> question, but I won't have much time for this project, unfortunately.

great! at least you'll find it entertaining. i'd encourage you to check
out bill page's work on page.axiom-developer.org. it's a wiki server
he is developing which allows you to type axiom inline in a page and
see the results. he's got quite a few interesting innovations there
and he's (almost) convinced me that the browser is the one-true-path
forward for the user interface.

the big struggle we've had is how to move the graphics so it runs
on linux and windows with the same code. suggestions are welcome.

Tim