As one who knows all the sides and all the players only too well, I'll =
add a bit of humor to the discussion...

They say that Lisp programmers know the value of everything, and the =
cost of nothing... Quite true, in fact. Our data structures are rich =
beyond measure. CLOS multiple dispatch, generic functions, hash tables, =
and on and on. But these objects are extremely costly in terms of =
runtime and memory use.

I think of Forth programmers as scrappy street fighters brandishing =
knives... they can work wonders with minimal resources. Put on the =
bit-gloves and massage each bit as it moves through the I/O ports. =
Amazing! Inject some in-line Assembly on the spot to whip the answer out =
in a few nanoseconds. Truly awesome!

But when faced with a big problem, like a human-computer interface where =
user input can be arbitrary numbers (integers, floats, complex), lists =
of items, multidimensional arrays, all ephemeral (and very costly in =
memory and speed), a Lisp programmer will pull a Clint Eastwood on the =
spot, hauling out his 44-Magnum and blow away the scrappy street =
fighters. ... Never bring a knife to a gunfight....

I downloaded the code mentioned in a previous post -- the Lexgen and the =
Gray5 parser generators. Very ambitious and heroic efforts on the part =
of some dedicated Forth'ers. I notice that they had to resort to a kind =
of "object oriented" approach in many places. Truly amazing code. =
Perhaps with those as starting points, you could do a relatively quick =
job on a modest language design... but, that code was written back =
around 1990. What if it has bit-rot? Where will you look to find and fix =
problems that may arise? I shudder to think about all of the complexity =
and low-level details with which you will need have intimate knowledge.

I used to say give me a Forth and I can do anything... And that is still =
true... but life is getting shorter with each passing day. I now say =
that about Lisp.

I have lived through many many projects. In almost every one of them, we =
were ambitious and fast. But over time the code base grew to such an =
extent that it became crippled by its own mass. Bit-rot consumed most of =
our formerly productive work hours.

With Forth, that limit came for me around 1985 when we reached a =
compiled mass of code amounting to around 32 KWords on a Nova-800. Maybe =
several hundred "blocks" of code on disk. Just too many details to keep =
track of beyond that size.

Then came C... that allowed us to reach several MB of compiled code, or =
around 100 KLOC. At 300-400 KLOC the burden was horrible. I tried for =
nearly 10 years to develop a high-performance, vectorized, math modeling =
and data analysis language.=20

In 1999 I discovered SML, Haskell, and OCaml -- settled on OCaml, and =
within 6 months had a finished version occupying about 15 KLOC of code, =
compared with more than 100 KLOC of repeated failed attempts in C and =
C++. But OCaml is brutal. It is a royal pain in the A** to write code. =
It won't compile unless the compiler can prove that you are behaving =
correctly with respect to operations and operands. However, once you =
reach the light at the end of the tunnel, you have code that is pretty =
darn rock solid. Instead of spending 50% of your time (or more) =
debugging code, you spend typically less than 5% -- and that has mostly =
to do with having chosen incorrect data structures to support what you =
were attempting. That code has run perfectly for more than a decade now, =
with no maintenance, no bit-rot whatsoever.

Lisp is in between OCaml and Forth. Much more like Forth in letting you =
do whatever you want (including hanging yourself). But more like OCaml =
in terms of the richness of inherent data structures, and the robustness =
of code that you develop. No maintenance needed for more than 20 years =
on some of the old code I wrote back then, and still actively use today. =
No bit-rot. Abstract enough to dispel all those low-level details that =
consume you with Forth. But now I know the value of everything, and the =
cost of nothing...

- DM=
----------------------------------------------------------------------
sftalk_at_forth.com The SwiftForth programming discussion email list
To unsubscribe, send subject "unsubscribe" to sftalk-request_at_forth.com
For list command help, send subject "help" to sftalk-request_at_forth.com
Message archives are located at http://www.forth.com/archive/sftalk
----------------------------------------------------------------------
This list is a forum for SwiftForth users. For product support and
bug reports, please send email to support_at_forth.com
----------------------------------------------------------------------
Received on Sat Jan 30 2010 - 22:08:52 PST