[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Axiom-developer] RE: Boot vs. Lisp
From: |
Bob McElrath |
Subject: |
Re: [Axiom-developer] RE: Boot vs. Lisp |
Date: |
Mon, 31 Oct 2005 22:15:37 -0800 |
User-agent: |
Mutt/1.5.11 |
C Y address@hidden wrote:
> > I agree that using *both* Lisp and BOOT is probably more
> > complicated than it needs to be. But my solution to this
> > would be precisely opposite the solution proposed by Tim.
> > What I would greatly prefer is to replace the Lisp in
> > Axiom with BOOT, where possible. I think the only place
> > where Lisp is required is in the bootstrap for the BOOT
> > compiler itself. And even there, BOOT could be weened from
> > it's mother Lisp and live on it's own like ML, Aldor, and
> > some other languages that started out in Lisp - but I am
> > not really advocating that in the short term.
>
> In doing so we basically commit to writing our own development
> environments and tools, as well as leaving a language that has an
> established ANSI standard. That may be worth it, but I'm going to be a
> hard sell. ;-)
Having worked on a couple projects which involved some form of custom
language...
It is far, far more important to have a system which people can jump
into quickly than it is to have a system that is complete, thorough, and
consistent. If it is easy to get into, it will become complete,
thorough, and consistent eventually.
By writing in a language no one has ever heard of, the project will be
doomed to those that already know it, and those that have a lot of time
on their hands. Open source development is "itch scratching" and if it
takes a month to figure out how to scratch the itch, most people won't
do it.
Complexity of software scales as exp(size). Doubling the size
(maintaining a compiler too) means far more than double the work, and
will require far more than double the coders.
I don't really care what language is used. I've used around 40 in my
life and can learn another. But Axiom will die if it is necessary to
maintain a compiler also, and it will die if other people can't pick it
up quickly and contribute. KISS.
I agree wholeheartedly with Tim on much of this:
root address@hidden wrote:
> 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. You have to be careful in boot. It is case sensitive so APPEND
> is not the same as append. It is often not clear what a construct
> will translate to and you end up reading the lisp to learn.
> A single, misplaced space will change the meaning of the code.
>
> POINT 4: Boot SERIOUSLY complicates the Axiom system. For instance:
>
> 1) Bootstrapping boot
>
> The boot compiler is written in boot and needs to be compiled
> using itself. If you have a running Axiom system this is not a
> problem. However if you start from a clean lisp system it is a
> big problem. I cheesed up a way to do this but it is fragile and
> ugly. But given that we build from scratch there is no other way.
>
> 2) Makefiles come in multiple stages
>
> Boot forces Axiom to be built in stages. Thus Axiom cannot use modern
> tools like ASDF. A pure common lisp Axiom interpreter can be built
> and loaded directly into a lisp image, interpreted or compiled.
>
> Lisp, BOOTSYS, DEPSYS, INTERPSYS, AXIOMSYS. These can all be
> collapsed if Boot disappears.
>
> 3) lsp, lisp, clisp, ${LISP}
>
> All of these exist because boot exists. For example, .clisp is a
> translated boot file whereas a lisp file is hand coded. ${LISP}
> exists to smooth over this bump. I won't go into the historical
> reasons why these came about but they exist as a side-effect of boot.
>
> 4) The interpreter has a boot compiler built in
>
> There are complications to the interpreter to handle boot-related
> development from the command line which no-one is ever likely to
> do again. This code could disappear and, having gone away, simplify
> the interpreter
>
> POINT 5: The boot language is undocumented
>
> It is likely to remain so as one of the authors is dead and the other
> one might be. There are no primary sources of documentation.
>
> POINT 8: Tools don't support boot
>
> Emacs balances lisp parens. It lets me do lisp function lookups. It
> understands the lisp syntax including escape chars. SLIME lives in
> emacs and provides support. Code walkers walk lisp code. Pretty
> printers understand lisp. Debuggers understand lisp (I want to fix
> it in the language I broke it in). ASDF can manipulate lisp. Programmers
> speak lisp. Blank spaces don't break lisp.
>
> Boot is unsupported anywhere by anything.
>
> POINT 9: Where are the programmers?
>
> Who will write in boot? 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. Even if people code in boot
> to maintain the interpreter how often will they do that? How will
> they maintain their skill at writing boot? I've written many, many
> thousands of lines of lisp and use it continuously. Who are the
> programmers who will do that in boot?
>
> POINT 12: Future directions assume lisp
>
> Notice that one of the near future goals is to connect Axiom and
> ACL2. ACL2 understands lisp-ish kind of languages, not boot.
--
Cheers,
Bob McElrath [Univ. of California at Davis, Department of Physics]
"In science, 'fact' can only mean 'confirmed to such a degree that it would
be perverse to withhold provisional assent.' I suppose that apples might
start to rise tomorrow, but the possibility does not merit equal time in
physics classrooms." -- Stephen Jay Gould (1941 - 2002)
signature.asc
Description: Digital signature
- Re: [Axiom-developer] RE: Boot vs. Lisp,
Bob McElrath <=
- RE: [Axiom-developer] RE: Boot vs. Lisp, Bill Page, 2005/11/01
- RE: [Axiom-developer] RE: Boot vs. Lisp, C Y, 2005/11/01
- [Axiom-developer] RE: Boot vs. Lisp - various, Bill Page, 2005/11/01
- [Axiom-developer] RE: Boot vs. Lisp - various, C Y, 2005/11/02
- Re: [Axiom-developer] was: Boot vs. Lisp / a smaller project, Martin Rubey, 2005/11/02
- [Axiom-developer] StepThrough, C Y, 2005/11/02
- RE: [Axiom-developer] StepThrough, Bill Page, 2005/11/02
- RE: [Axiom-developer] StepThrough, C Y, 2005/11/02
- Re: [Axiom-developer] StepThrough, Martin Rubey, 2005/11/03
- RE: [Axiom-developer] StepThrough, Bill Page, 2005/11/04