are <Proponent@gmx.net> wrote:
+---------------
| I have looked at Scheme and really liked it.  I wish I had been
| introduced to programming via Scheme.  But for my purposes, I find
| there are two major drawbacks:
| 
|   1.  The formally defined language lacks some things I'd really like
| to have, like OO.  Of course you can roll your own, but that's not
| where I want to be spending my time.
+---------------

Ditto, which is one of the reasons I switched from Scheme to CL.

+---------------
| Or you can use a proprietary extension, like that in MzScheme,
| but I don't want to be locked into a single supplier.
+---------------

After trying several other flavors, I *had* actually "settled on"
using MzScheme, mainly for it's performance [compared to the other
Scheme's I'd tried] and its clean FFI [MzScheme calls external
C code with a Tcl-like/shell-like "int argc, Scheme_Object **argv"
calling sequence] and support for runtime DSO lining. I had no
particular concerns myself about being "locked" to a "supplier",
since the code is in C and builds from scratch fairly easily.
I used MzScheme quite happily for a number of years.  [But...]

+---------------
|   2.  From what I've seen Scheme is too slow, even if I'm not
| worried about factors of two in execution time.
+---------------

MzScheme now comes with a compiler to C, "mzc", that speeds things
up somewhat. But the speed of compiled CL is certainly one of the
reasons I eventually "turned to the dark side" and embraced CL.

That, and getting tired of reinventing stuff all the time.

[And having a major app that I'd written in MzScheme v.50 break
horribly by a major change in internals that occurred circa
MzScheme v.103...]

Even with CL, you will probably find yourself "settling into"
a specific implementation of CL for most of your work. [I use
and like CMUCL. YMMV.] Don't worry about it.  The good news
is that if you *do* have to change implementations later, that
rather large portion of your code which was written to conform
to the ANSI Standard (a.k.a. CLHS) will probably "just work";
only the implementation-specific extension bits will have to change.
[And you kept those factored aside anyway... DIDN'T YOU?!?  ;-} ]


-Rob

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607