Features Download
From: Jack Harper <jharper <at> frobenius.com>
Subject: Re[2]: (Lisp-HUG) Push Button Background Color...
Newsgroups: gmane.lisp.lispworks.general
Date: Thursday 14th January 2010 15:32:38 UTC (over 8 years ago)
At 10:46 AM 1/12/2010, Art wrote:

>Hello Jack,
> > Please see http://www.secureoutcomes.net/livescan-products.html
> > the embedded system - written completely in LW Common Lisp (along
> > with CLOS, CAPI & Friends).
>Can you make a brief summary and post it here on why you use CL in
>your products, why a (the :) commercial version of CL and how you came
>to CL in your company? I'm asking this because it is hard to find
>real-world up-to-date examples of use of CL for commercial applications;
>and because as I see it there is a notion among some lispers that current
>free implementations of CL are somewhat "better" than commercial ones.
>  Art

Art --

We use Common Lisp to implement commercial products here at Secure 
Outcomes for the following reasons:

(a) Very fast development that is enabled by CL (e.g., *everything* 
from hash tables to string-operators to memory management is 
automatically included - there is nothing that is not included).

(b) Excellent programming environments - e.g., parentheses-savvy editor.

(c) Excellent compiler, especially with declarations, enables very fast

(d) Excellent system stability with no random crashes at all. The 
base code for the CL system is something like 25-years old and it 
simply works.  This stability was of tremendous importance to me - 
Last thing that I would want in a high-pressure startup development 
environment would be random system crashes. I tested this single 
attribute the most before I committed to LW CL.

...and, of course, (e) Macros and all that.

There is, of course, nothing above that is new (e.g., see Paul 
Graham's interesting write-ups on mixing Lisp and startups :)   I 
don't think that Graham mentions (d) though ---- to me, (d) is fundamental.

If you couple the above with, for example, the techniques of the new 
book "Let Over Lambda" 

(which is really quite scary to read - I can't say that I understand 
100% of it - maybe 60% and I am very happy with that level of 
comprehension) -- you end up with an enormously powerful set of 
programming tools unlike anything else out there.

The ancient arguments against Lisp simply don't apply anymore - e.g., 
"It's humongous". It is becoming difficult to get RAM memory below 
1GB these days in our target embedded hardware - our delivered 
executable application, that consists of about 30,000 lines of CL 
source, is less than 50mb which fits in memory 20-times with no 
problems.  Twenty years ago, 50mb was a lot and, in an embedded 
application, a real show-stopper - no longer.

Other arguments: "It's slow because of type checking" - really good 
compiler technology eliminated that.  In fact, both arguments against 
CL went away at least a decade ago.

The remaining Big Argument against: "It spends all of its time GCing" 
- again, the compiler with simple declarations and paying at least 
some attention so that you allocate things on the stack minimizes the 
GC issue (an interesting thing: it required about a second of CPU 
time to GC 32K words of IBM 7090 memory on the original McCarthy Lisp 
1.5 back in 1959 - GC time these days with a gigabyte? - about the same :)

Committing to Common Lisp was, of course, a Big Step for us and we 
did not take it lightly. I strongly believe that the benefits greatly 
outweighed the deficits.

Deficits?  The biggest problem, I think, will be to find really good 
Lisp programmers as we staff-up - but the Internet certainly helps 
with that and so that is not such a large problem either.

I started programming in LISP way back in 1971 on a Univac 1108 
mainframe and also implemented a 68000-based Lisp system (~50K lines 
of real-time assembly) for mobile-robotics use in 1983 - and so know 
my way around the language. However, I have never before built a 
commercial product with Lisp and so there was certainly some risk 
involved - mostly with "unknown unknowns".  The Good News is that, at 
least with this project, the "unknown unknowns" have been minimal - 
there were certainly "known unknowns" (e.g., talking direct to 
real-time hardware from within Lisp) but those were overcome.

The biggest and meanest learning curve for me was, of course, CAPI in 
all of its wretched glory (our product is driven by an embedded 
touchscreen and is graphics heavy). To me, the multi-threaded aspects 
of CAPI are the most obscure but, once you begin to get the hang of 
it, it begins to make sense. However, mp:process-run-function over a 
#'lambda simply to update a button or whatever seems a bit extreme - 
someone really should put together some sort of high-level wrapper 
(all that macro capability!) to submerge that sort of thing from the 
conscienceness.  A non-elementary "CAPI for Dummies" would be a 
welcome addition rather than the "Hey, look at the example source 
code" (commentless, of course :)   An exercise for the student...

I chose to use a commercial CL (LW) for exactly one reason: I believe 
that you get what you pay for - and support (Hello Martin! 
:)  especially in the early days of the project was invaluable. I am 
simply more comfortable depending on a commercial CL environment 
rather than a "freebie". I spent quite a bit of time inside Spice 
Lisp back in the late 1980s and so was/am familiar with that 
environment -- however, I must say that I know very little about the 
modern freebie Lisps. My knowledge is 25-years out of date, but it 
doesn't matter - I believe that vibrant commercial CLs competing in 
the marketplace can only be a Good Thing, regardless of what Messrs 
Stallman and others say :)

I chose LW for two reasons: The lack of runtime royalties and the 
fact that I met Martin some years ago at a conference.

To me, the greatest positive attribute of the freebies would be the 
availability of source code - I would very much like to have access 
to the CAPI source code so that I could understand better (especially 
if I had the time) what goes on there (e.g., obviously, I *still* do 
not really understand exactly how the multi-threading works - best 
that I can tell, something like capi:apply-in-pane-process simply 
schedules an event but does not trigger an event - it is still hazy 
to me - but it begins to make sense now that I have made at least 
(hopefully) 80% of all possible errors...

I hope that the above makes sense and is useful.

Regards to the List -

Jack Harper
Secure Outcomes Inc.
CD: 3ms