Making an engineering case for Lisp 
Author Message
 Making an engineering case for Lisp

Greetings. For the past year I have been working quietly, via various
research projects, on injecting Common Lisp into our engineering
environment. In January I will have an opportunity to make an
"engineering case" for Lisp as a vehicle to develop real product, and
would like to solicit you folks for annecdotal examples of *real* Lisp
projects and experiences.

I am especially interested in the following:

1. From a software engineering perspective, how does Lisp scale to large
projects? I don't mean performance here; rather, I'm interested in
learning how well a team of developers can build large systems that
exhibit high quality and reliability. I'd wager one of the first
concerns I hear will be from the strongly-typed-language proponents, who
will bemoan Lisp's lack of compile-time type checking. This concern is
legitimate, and I'd like to hear of your experiences in this area.

2. Common Lisp and "mainstream" applications. Most of my research has
centered around the development of knowledge-based systems; however, I'd
like Lisp to be considered a platform for developing complex
applications that don't necessarily have anything to do with AI. I'm
very interested in hearing of your experiences here. I don't need
details (proprietary information and all that), but general information
on existing and (especially) new projects will be valuable.

3. Anyone who's successfully introduced Lisp into their company. Your
guidance here would be appreciated.

I realize your responses require time and effort, but new, visible
project work in Lisp (especially at a company that doesn't officially
use it) can't be anything but good for the language. Thanks very much.

--

-----------------------------------------------------------------
David E. Young
Fujitsu Network Communications  "The fact that ... we still

                                 feeling that we no longer live nobly."
                                  -- John Updike
"Programming should be fun,
 programs should be beautiful"
  -- P. Graham



Tue, 30 Apr 2002 03:00:00 GMT  
 Making an engineering case for Lisp


Quote:
> I'd wager one of the first
> concerns I hear will be from the strongly-typed-language proponents,
who
> will bemoan Lisp's lack of compile-time type checking. This concern is
> legitimate, and I'd like to hear of your experiences in this area.
[...]
> 3. Anyone who's successfully introduced Lisp into their company. Your
> guidance here would be appreciated.

I have little experience of Lisp (see my posts here :-), but on the last
point, I was involved in trying to move from C to C++ at one company and
it was depressing.  A group of us tried developing a useful project in
our own time using the new language to demonstrate the benefits, but it
was very slow and, by the time I left, had succeeded mainly in
alienating more traditional members of the company who considered us a
clique.  If "middle management" aren't happy with changes then it's no
fun....

As for the static types - (I guess I'm about to state the obvious here)
the only argument I can see is that it is much easier to write small
test scripts in Lisp than in Java (the language I learn a living in).
The flexibility of Lisp, esp first class functions and dynamic typing,
means that you can test earlier, and test smaller components.  I use
test scripts in Lisp the same way I use the compiler in Java - to track
and fix the ripple-though effect of changes in code.  I guess you can
also use the before and after methods in Clos as some kind of invariance
checking (like Eiffel), but I haven't done so.

Good luck,
Andrew

Sent via Deja.com http://www.deja.com/
Before you buy.



Tue, 30 Apr 2002 03:00:00 GMT  
 Making an engineering case for Lisp
Check this for an example of a high profile, high tech and real-time
application of LISP.  I don't have any first hand info on the details, but I
know that LISP was used extensivily in the core of the project.

http://radarsat.space.gc.ca/

It also used blackboard technology from http://www.bbtech.com/  which is
also implemented with LISP.

The company i work for also impements a large part of its product with LISP.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Coby Beck
Software Developer
__________________________
Mercury Scheduling Systems
400 - 601 West Cordova
Vancouver, BC
ph - (604) 683-8668 ext 370
fax- (604) 688-2375
http://www.mercury.bc.ca/



Quote:
> Greetings. For the past year I have been working quietly, via various
> research projects, on injecting Common Lisp into our engineering
> environment. In January I will have an opportunity to make an
> "engineering case" for Lisp as a vehicle to develop real product, and
> would like to solicit you folks for annecdotal examples of *real* Lisp
> projects and experiences.

> I am especially interested in the following:

> 1. From a software engineering perspective, how does Lisp scale to large
> projects? I don't mean performance here; rather, I'm interested in
> learning how well a team of developers can build large systems that
> exhibit high quality and reliability. I'd wager one of the first
> concerns I hear will be from the strongly-typed-language proponents, who
> will bemoan Lisp's lack of compile-time type checking. This concern is
> legitimate, and I'd like to hear of your experiences in this area.

> 2. Common Lisp and "mainstream" applications. Most of my research has
> centered around the development of knowledge-based systems; however, I'd
> like Lisp to be considered a platform for developing complex
> applications that don't necessarily have anything to do with AI. I'm
> very interested in hearing of your experiences here. I don't need
> details (proprietary information and all that), but general information
> on existing and (especially) new projects will be valuable.

> 3. Anyone who's successfully introduced Lisp into their company. Your
> guidance here would be appreciated.

> I realize your responses require time and effort, but new, visible
> project work in Lisp (especially at a company that doesn't officially
> use it) can't be anything but good for the language. Thanks very much.

> --

> -----------------------------------------------------------------
> David E. Young
> Fujitsu Network Communications  "The fact that ... we still

>                                  feeling that we no longer live nobly."
>                                   -- John Updike
> "Programming should be fun,
>  programs should be beautiful"
>   -- P. Graham



Tue, 30 Apr 2002 03:00:00 GMT  
 Making an engineering case for Lisp

Quote:
> Greetings. For the past year I have been working quietly, via various
> research projects, on injecting Common Lisp into our engineering
> environment. In January I will have an opportunity to make an
> "engineering case" for Lisp as a vehicle to develop real product, and
> would like to solicit you folks for annecdotal examples of *real* Lisp
> projects and experiences.

> I am especially interested in the following:

> 1. From a software engineering perspective, how does Lisp scale to large
> projects? I don't mean performance here; rather, I'm interested in
> learning how well a team of developers can build large systems that

I'll address the specific point you raise; I think for general issues
of scaling and applicability, look at
e.g. http://www.elwoodcorp.com/alu/table/applications.htm or
contact a CL vendor.

Quote:
> exhibit high quality and reliability. I'd wager one of the first
> concerns I hear will be from the strongly-typed-language proponents, who
> will bemoan Lisp's lack of compile-time type checking. This concern is
> legitimate, and I'd like to hear of your experiences in this area.

Since types are not known until runtime, it would be hard to have
compile-time type checking.  However, if you insert a check-type call
wherever there might be a problem, you will have as early-as-possible
indication of a problem.  Also assert.  I find these very useful -
preemptive debugging.  It would be nice if a compiler would
automatically insert check-type for each type declaration present, say
if a certain code safety level is specified.  That way, you could
declare everything and leave the declarations in, just crank up the
safety level during debugging.  This doesn't exist in any CL I know
of.

You might point out the advantages of late binding over strong
typing, too.

--
Liam Healy



Tue, 30 Apr 2002 03:00:00 GMT  
 Making an engineering case for Lisp

Quote:

> [ ... ]

> 1. From a software engineering perspective, how does Lisp scale to large
> projects? I don't mean performance here; rather, I'm interested in
> learning how well a team of developers can build large systems that
> exhibit high quality and reliability. I'd wager one of the first
> concerns I hear will be from the strongly-typed-language proponents, who
> will bemoan Lisp's lack of compile-time type checking. This concern is
> legitimate, and I'd like to hear of your experiences in this area.

I'd say that Lisp scales better than most other languages, and this is one
of its benefits.  However, my experience suggests that you need at least
one Lisp expert as part of the team to keep the team on the right track.
Large projects built by inexperienced Lisp developers is a nightmare.

In terms of reliability, this is one of the big issues I push as
to an advantage of lisp.  Lisp applications don't spontaneously exit like
applications built in other languages seem to do all too often.  You also
can load patches into a running system, no need to bring down the system
for maintenance.

As to type checking, all the type checking doesn't seem to prevent memory
leaks in C programs, nor does it seem to prevent bad pointers from causing
the application to spontaneously exit.  People may bemoan Lisps lack of
compile time type checking, but they are attaching *way* too much importance
to this issue, and I believe this to be a non sequiter.  Type checking doesn't
help me develop C programs any faster, or better than I do in Lisp without
it.



Tue, 30 Apr 2002 03:00:00 GMT  
 Making an engineering case for Lisp

Quote:

> Greetings. For the past year I have been working quietly, via various
> research projects, on injecting Common Lisp into our engineering
> environment. In January I will have an opportunity to make an
> "engineering case" for Lisp as a vehicle to develop real product, and
> would like to solicit you folks for annecdotal examples of *real* Lisp
> projects and experiences.

> I am especially interested in the following:

> 1. From a software engineering perspective, how does Lisp scale to large
> projects? I don't mean performance here; rather, I'm interested in
> learning how well a team of developers can build large systems that
> exhibit high quality and reliability. I'd wager one of the first
> concerns I hear will be from the strongly-typed-language proponents, who
> will bemoan Lisp's lack of compile-time type checking. This concern is
> legitimate, and I'd like to hear of your experiences in this area.

Well, you don't have compile time checking in most lisps, but. I'll bet
that most of the "type errors" in C won't be a problem in lisp.  With
underclared parameters as long as the function works on the type, it's
ok.  You can check the types in function headers to turn up type
errors early in testing.  Maybe not as "good" as static checking, but
it can get you quite a lot, while maintaining the flexibility we all know
and love.

dave



Tue, 30 Apr 2002 03:00:00 GMT  
 Making an engineering case for Lisp

Quote:

> It would be nice if a compiler would
> automatically insert check-type for each type declaration present, say
> if a certain code safety level is specified.  That way, you could
> declare everything and leave the declarations in, just crank up the
> safety level during debugging.  This doesn't exist in any CL I know
> of.

That's basically what CMUCL does:

    (defun foo (x)
      (declare (type real x))
      x)

    (foo 1) -> 1

    (foo t) -> <error>

--tim



Tue, 30 Apr 2002 03:00:00 GMT  
 Making an engineering case for Lisp

Quote:

> automatically insert check-type for each type declaration present, say
> if a certain code safety level is specified.  That way, you could
> declare everything and leave the declarations in, just crank up the
> safety level during debugging.  This doesn't exist in any CL I know
> of.

CMUCL does this for compiled code:

(defun mult( x y )
    (declare (type fixnum x y))
    (* x y))
(compile 'mult)
(mult 2 2.3)
Type-error in kernel...
2.3 is not of type FIXNUM

This even works for stuff like (integer 1 10)

When you crank on optimizations, its turns the assertions
to assumptions, resulting in very fast code.

dave



Tue, 30 Apr 2002 03:00:00 GMT  
 Making an engineering case for Lisp
On Fri, 12 Nov 1999 10:14:53 -0500, "David E. Young"

Quote:

> environment. In January I will have an opportunity to make an
> "engineering case" for Lisp as a vehicle to develop real product, and
> would like to solicit you folks for annecdotal examples of *real* Lisp
> projects and experiences.

You may be interested in checking this paper by Erann Gat:

  "Lisp as an Alternative to Java"
  http://www-aig.jpl.nasa.gov/public/home/gat/lisp-study.html

Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/



Wed, 01 May 2002 03:00:00 GMT  
 Making an engineering case for Lisp

Quote:


[...]
> > exhibit high quality and reliability. I'd wager one of the first
> > concerns I hear will be from the strongly-typed-language proponents,
who
> > will bemoan Lisp's lack of compile-time type checking. This concern
is
> > legitimate, and I'd like to hear of your experiences in this area.
[...]
> As to type checking, all the type checking doesn't seem to prevent
memory
> leaks in C programs, nor does it seem to prevent bad pointers from
causing
> the application to spontaneously exit.  People may bemoan Lisps lack
of
> compile time type checking, but they are attaching *way* too much
importance
> to this issue, and I believe this to be a non sequiter.  Type checking
doesn't
> help me develop C programs any faster, or better than I do in Lisp
without
> it.

A (pedantic) aside:

First, Lisp is strongly typed, but is has strong *dynamic* typing, not
strong *static* typing.  So if the "objectors" want a strongly typed
language (one in which the type of an object is always known), then Lisp
fits the bill.  However, I assumed the original question was talking
about strong static types, which give compile time type checking (if so,
what language?  Eiffel?  Java?  You can point out Java isn't static as
you can have class cast exceptions....)

C is weakly typed, and C++ is a mess, so it's not surprising that C
programs have memory errors.  If the "objectors" are arguing for C then
the argument in favour of Lisp is clear - it is strongly typed and C is
not!

Hope that is clear.  I also hope it's right.  I didn't have a computer
science education so I've just picked up these things on the way - I
suspect most people here can correct me if I'm wrong.

Andrew

Sent via Deja.com http://www.deja.com/
Before you buy.



Wed, 01 May 2002 03:00:00 GMT  
 Making an engineering case for Lisp


Quote:



> [...]
> > > exhibit high quality and reliability. I'd wager one of the first
> > > concerns I hear will be from the strongly-typed-language
proponents,
> who
> > > will bemoan Lisp's lack of compile-time type checking. This
concern
> is
> > > legitimate, and I'd like to hear of your experiences in this area.
> [...]
> C is weakly typed, and C++ is a mess, so it's not surprising that C
> programs have memory errors.  If the "objectors" are arguing for C
then
> the argument in favour of Lisp is clear - it is strongly typed and C
is
> not!

PS I decided not to add this as it's aimed at a pretty uneducated
reader, then changed my mind after posting because it really may be
useful if you are dealing with people who have only ever used C.  It's a
survey of programing languages that probably contains some errors, but
might be useful if you are trying to sell a new language to people who
don't realise that there is a lot more than just C.  Even if the article
isn't any good, the links at the end to similar articles by others might
help.

http://www.andrewcooke.free-online.co.uk/andrew/writing/lang.html

Andrew

Sent via Deja.com http://www.deja.com/
Before you buy.



Wed, 01 May 2002 03:00:00 GMT  
 Making an engineering case for Lisp

There's a certain irony in arguing that Lisp is faulty because it
doesn't have static typing like C.  In fact, the thing to realize is
that in Lisp, variables do not have types; instead, EVERY LISP OBJECT
has a type.  This is what Lisp's tag bits are all about.  Variables
are just names for values (see `Lambda, the Ultimate Declarative' by
Guy Steele).

In other words, Lisp sacrifices a certain level of performance (a
sacrifice that can often be retrieved by careful use of declarations)
in exchange for making sure that the system knows exactly what kind of
thing every object is.  This removes the need for the programmer to
worry about telling the system something it already knows.  But, since
people are used to thinking in terms of C, they think this is a flaw,
when it is actually a programming aid, like garbage collection.

Languages like C are flawed because they don't know what the objects
they are representing actually are.  They put the onus for dealing
with this on the programmer and that leads to programming errors.

I speak as someone who has been involved in several good-sized
projects that used C.

--

The real point is how much easier it was to conceive of and design the
Lisp version.  I hadn't even realized the problem was hard until
people started to recode it in C....         --Lawrence Hunter, Ph.D.



Wed, 01 May 2002 03:00:00 GMT  
 Making an engineering case for Lisp
Hi David,

Quote:

> I'd wager one of the first
> concerns I hear will be from the strongly-typed-language proponents,
> who will bemoan Lisp's lack of compile-time type checking.

If you use generic functions, it's customary to have a fall-back method,
which only becomes the effective method when the GF is invoked with
arguments of incorrect classes.  There it's your choice if you raise an
error, or write something in an error log etc.

Alright, classes are not the same as types, but in large applications
you may need class checking for instances a lot more often than type
checking.  Also, it's possible to change the class of an instance if it
meets some criteria (e.g., if both dimensions of a rectangle are the
same length, you may upgrade it to make it a square instance with
change-class), providing you with an alternative to deftype.

If your application uses integers or rationals, this is an area where
lisp bignums and rationals are certainly safer (rationals: more
accurate) than what you can do in C.

Also, in C or C++ you would often pass around pointers.  I'm not sure if
there is a lot of type checking on the objects referred by those
pointers.

A question: do you feel that the decision-makers have experienced or
recognized some of CL's benefits already?

Robert



Wed, 01 May 2002 03:00:00 GMT  
 Making an engineering case for Lisp

Quote:
> 2. Common Lisp and "mainstream" applications. Most of my research has
> centered around the development of knowledge-based systems; however, I'd
> like Lisp to be considered a platform for developing complex
> applications that don't necessarily have anything to do with AI. I'm
> very interested in hearing of your experiences here. I don't need
> details (proprietary information and all that), but general information
> on existing and (especially) new projects will be valuable.

For some marketing talk see:

Common Lisp Language Overview
 http://www.harlequin.com/products/st/lisp/language.shtml

and especially:

Common Lisp - Myths and Legends
 http://www.harlequin.com/support/lisp-info/lisp-white.html

Rainer Joswig, ISION Internet AG, Harburger Schlossstra?e 1,
21079 Hamburg, Germany, Tel: +49 40 77175 226



Wed, 01 May 2002 03:00:00 GMT  
 Making an engineering case for Lisp

Quote:

> If you use generic functions, it's customary to have a fall-back method,
> which only becomes the effective method when the GF is invoked with
> arguments of incorrect classes.  There it's your choice if you raise an
> error, or write something in an error log etc.

There's no need for a fall-back method if you just want an error to be
signalled.  That is the default behavior.

From the Hyperspec entry for NO-APPLICABLE-METHOD:

:The generic function no-applicable-method is called when a generic
:function is invoked and no :method on that generic function is
:applicable. The default method signals an error.

Quote:
> Alright, classes are not the same as types, but in large applications
> you may need class checking for instances a lot more often than type
> checking.
> [...]

Why?

--
Samir Barjoud



Wed, 01 May 2002 03:00:00 GMT  
 
 [ 25 post ]  Go to page: [1] [2]

 Relevant Pages 

1. making LISP using LISP ?

2. Is this safe? (Making string comparisons ignore case)

3. making the Python case to my dept.

4. making the Python case to my dept

5. making a case for Fortran

6. making a case for FORTRAN

7. Upper case / Lower case I'm a lost case

8. Business Process Engineering, OO (Use Cases) and Profit Maximization

9. CASE vs case vs Case...

10. Wanted - Reverse Engineering Tools / CASE that handles Rexx

11. Need ready made Widgets for engineering stuff!

12. newbie case-sensitive switch in lisp compiler (FRANZ)

 

 
Powered by phpBB® Forum Software