A revolutionary OS/Programming Idea

[Lynn H. Maxson]

Alaric B. Snell wrote:
"...He's not saying that what you do in LISP can't be done 
graphically; just that the graphical editors for LISP never 
really made it in the big time. ..."

I think you've given an excellent brief overview of LISP for 
John Newman's consideration.  He needs to understand that 
LISP and its more modern derivatives stand at the forefront of 
modern software development.  I have a deep appreciation for 
LISP's endurance over the years.

LISP along with APL and REXX employ dynamic typing.  I 
always enjoy it when people treat the inability to do 
something as a "feature", in this instance to declare a variable 
explicitly by type.  While I far prefer "fixed bin (31)" to "int" 
because it also allows me to have "fixed dec (7)" or "fixed bin 
(24, 6)", dynamic typing has an impact on documentation in 
that it introduces homonyms (same name, different referent) 
unnecessarily in a program.  This means in documentation that 
one name has to indicate multiple "meanings".

This is not a crime in english for verbs, the programming 
equivalent of operator overloading, but it rivals multiple 
names for the same person so common in russian novels.

So it is something you can do, but for purposes of clarity 
probably should not.  It doesn't detract from dynamic typing, 
though you might explain to me how you can express variable 
precision, fixed-point binary arithmetic in LISP.

For my purposes in the specification language I propose the 
only thing interesting in LISP is the list aggregate itself along 
with the possibility of an empty list.  This allows for returning 
0, 1, or more values as a result of function evaluation.  In logic 
programming where a result is either false (0 entries) or true 
(1 or more entries) the list aggegrate is indispensable.  
Whereas the remainder of LISP, specifically its syntax, is not.

However, LISP does provide ample opportunity to familiarize 
oneself with this aspect of lists.

I also do think much of the fact the program is a list capable 
of being processed as input and thus dynamically changed as 
part of that process.  Forth has a similar characteristic which 
seems to fascinate some.  

I will not say it does not have some value.  However, I will say 
that it's sheer imagination to take the next leap of faith that 
any program can modify itself in other than some 
predetermined manner: it remains rule-based on rules 
established externally which can never be internalized.  It 
means that "thinking machines" per se can never occur on von 
Neuman architecture or Turing machines.

We know only that we think.  We know nothing (we are 
ignorant) of what allows us to think.  This suggests that we 
ground ourselves firmly in pragmatics and absent ourselves of 
esoterics in programming.  We cannot make a program do in a 
rule-based system where we don't know the rules ourselves.