On Mon, Mar 17, 2008 at 07:58:27PM -0700, Bob La Quey wrote:
The problem I have with most of the sorts of things
you are talking about is that they impose "glass
ceilings" because the particular level of abstraction
that they have decided to focus on is often not
appropriate to the next level of the problem. I get
stuck with the level I started with often becuase the
syntax is just so messy as to hide what is going on.
I've kind of concluded that although Forth makes a valiant attempt to do
this, it fails miserably. The problem is that it just doesn't give you the
ability to get away from the details. The basics of _how_ arguments are
passed around still sticks out, like a sore thumb.
I think Lisp approaches what you're looking for a lot better. There are a
couple of reasons:
- The abstraction base is higher. This makes lisp less appropriate for
small embedded systems, but provides automatic memory management of
typed data to start with. This is a critical abstraction for most
non-trivial problems.
- The parens. Yes, the parens are largely what make Lisp better. They
allow it to keep a very simple syntax (nearly as simple as Forth), but
do so in a way that allows more to be explicitly managed, since the
grouping becomes visible. RPN with a stack hides away the data passing
which makes non-trivial code very difficult to read.
- Lexical scoping with closures. Many abstractions can be built around
lexcial capture.
The rest comes from ideas similar to forth, including macros (immediate
words), an extensible parser, and so on.
David
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
