From: Raymond Toy <t...@rtp.ericsson.se>
Subject: Re: Newbie questions [Followup to comp.lang.lisp]
Date: 1999/05/05
Message-ID: <4nk8unb0hc.fsf@rtp.ericsson.se>#1/1
X-Deja-AN: 474511365
References: <FB0o5H.8HM@news2.new-york.net> <sfw1zh126oy.fsf@world.std.com> <87btg5pb1y.fsf@2xtreme.net> <372dc20d.11142383@news.select.net> <m33e1g25u9.fsf@localhost.localdomain> <37326ec5.11965212@news.select.net> <87g15ee8ss.fsf@foobar.orion.no> <372e265f.2137369@news.select.net> <87d80hdy1t.fsf@foobar.orion.no> <372fb91b.39706364@news.select.net> <87aevldw62.fsf@foobar.orion.no> <7gnhjt$p9q$1@nnrp1.dejanews.com> <4ogk0a72c.fsf@beta.franz.com> <37326dd3.5537740@news.select.net> <sfwso9cxt0s.fsf@world.std.com> <ucvhe7l8td.fsf@soft.mercury.bc.ca>
Content-Type: text/plain; charset=US-ASCII
Organization: Ericsson Inc., RTP, NC
Mime-Version: 1.0 (generated by tm-edit 7.108)
Newsgroups: comp.lang.lisp

>>>>> "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
    Joachim> introduced.

I would say your software engineering process is broken in this case,
and no language will protect you from this kind of problem.

Ray