Re[2]: (Lisp-HUG) Push Button Background Color...
At 10:46 AM 1/12/2010, Art wrote: >Hello Jack, > > > Please see http://www.secureoutcomes.net/livescan-products.html for > > 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. > >Best, > 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 code. (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" http://www.amazon.com/Let-Over-Lambda-Doug-Hoyte/dp/1435712757/ref=sr_1_1?ie=UTF8&s=books&qid=1263429170&sr=1-1 (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.