Message from discussion Newbie questions [Followup to comp.lang.lisp]
From: Raymond Toy <t...@rtp.ericsson.se>
Subject: Re: Newbie questions [Followup to comp.lang.lisp]
References: <FB0o5H.8HM@news2.new-york.net> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com>
Content-Type: text/plain; charset=US-ASCII
Organization: Ericsson Inc., RTP, NC
Mime-Version: 1.0 (generated by tm-edit 7.108)
>>>>> "Joachim" == Joachim Achtzehnter <joac...@kraut.bc.ca> writes:
Joachim> persists in practise. I agree strongly with Joshua that lack of static
Joachim> type checking is one on the main disadvantages of (at least) the
Joachim> commercial Common Lisp implementation I am familiar with.
Get another implementation? I'm not that familiar with commercial
implementations on this topic, but certainly CMUCL can do a lot of
static type checking, roughly equivalent to any C/C++ compiler, and,
in some ways, a lot more.
Joachim> Well, I tend to disagree. Adding static type checking (optional of
Joachim> course) would go a long way towards convincing experienced C++/Java
Joachim> programmers to take another look at Lisp. Of course, I can be certain
Joachim> only about my own opinion, others may disagree. I have heard a
I always thought C++/Java programmers were turned off by the syntax,
not the lack of type checking. As a C/C++ programmer, I rather enjoy
not having to type everything when writing in Lisp.
Joachim> arguments, passing a wrong argument, etc. With existing Lisp
Joachim> implementations many such errors are detected only at runtime even
Joachim> when declarations are used. This is less problematic with mainline
Get a better implementation?
Joachim> you're lucky. Yes, you should test all your code, but the kind of bug
Joachim> we're talking about is often introduced by changes that are so
Joachim> 'obvious' that many developers don't imagine a bug may have been
I would say your software engineering process is broken in this case,
and no language will protect you from this kind of problem.