Re: Industry versus academia

[Sundar Narasimhan <address@hidden>]

   > But my bird's eye view is that forth is one of the few non gc'ed
   > languages wherein you can define user-definable functions (words) at
   > run time. I know gc is considered a win on this list, so no flames
   > re. that please :)

   In the absence of Patrick O' Donnell: I presume you wanted a non gc'ed
   language for performance reasons, right?!
Yes.

   > The reason we wrote those layers I imagine (some of it was before my
   > time) is to allow us to develop such code to connect to databases and
   > to throw up user interfaces from Lisp machines and we were not
   > satisfied with CLX/CLIM or ODBC type stuff. 

   Not satisfied?
Yes, back at the time this was written, we were not satisfied with the
performance that even CLOS provided and hence wrote our own version of
Flavors (which we sped up by assuming that certain modifications to classes
would not occur at run time). I think AFL (Ascent Flavors) was written
by Ed Barton who's now at i2. 

The critical thing that database layers such as ODBC lacked, was
really a tight coupling w/ our development and runtime
environments. This is no small requirement. Consider the foll. usage
scenarios: 
- a developer sets a break point in some piece of code that is within
a locked portion of code or within a transaction. He/she then goes to
lunch, his machine crashes, he contrl-c's gdb etc. In such cases I've
had databases lock up -- and if you were doing this on a production db
(to debug problems it is sometimes, rarely, necessary to hook up your
dev. environment to the database), much heartache can result. Of
course Oracle 8 and subsequent versions fixed some of these cases
when it would simply "hang", but what we wanted was a clean way we
could integrate things like unwind-protect with the transaction
semantics of the underlying db code, so that the appropriate
rollback() etc. would happen. 

- in a production environment the db code gets an error and throws to
the debugger. If you use Lisp, you can identify the problem, download
a patch that fixes it (redefining functions/words etc.), move down the
stack and "restart" and voila everything comes back up. I don't know
of very many other solutions (languages/environments) that can provide
such a capability -- not Java, not C/C++, not Smalltalk (although my
memory wrt. the last is hazy).

I suspect our CLX/CLIM experience was similar.. but I don't want to go
into that since debates about UI libraries in lisp pretty soon devolve
to religion (esp. among certain Lisp hackers :)

   > Forth makes it easy to connect to C code for X11 and OCI (Oracle),
   > Sybase etc. and provides a way for Lisp to connect to it and define
   > new transactions.. our programming is done entirely in Lisp, and the
   > forth layer is somewhat hidden (except on rare occasions when you need
   > it). 

   Probably most people would have picked C, apart from the run time words?!
   What made run time words so important for that layer?

Exactly.. and don't get me wrong -- our forth actually talks to C
layers in X11 libraries from various vendors and OCI libraries from
Oracle (so we do use C.. and in fact our base Forth words are compiled
to C :). I hope the need for new words becomes clear from my
description above - most every db transaction that has "bind"
variables, or calls that require arguments can be pushed into the PAS
layer and run as a function/word for performance :) I was/am told that
Forte's function shipping worked in a similar fashion, so someone who
knows about their "partitioning" architecture could post about that (I
don't know too much about it beyond a few conversations w/ friends).

And yes, we probably could have made it all work on top of a Saber-C
like solution -- but I suspect the forth layer made the job of
providing a binding layer in Lisp easier.. we have Lisp macros that do
things like define those Forth words for transactions and they allow
evaluations in both contexts.