Reasons for rejecting Lisp (was Re: Newbie questions [Followup to comp.lang.lisp]) 
Author Message
 Reasons for rejecting Lisp (was Re: Newbie questions [Followup to comp.lang.lisp])

Quote:

> I don't share your believe in the power of the market to lead us to
> paradise. If the market had this power would Lisp be the fringe
> language it is? Would Microsoft be the most successful software
> company?

*IT IS BECAUSE THE MARKET HAS THIS POWER* that Microsoft is the most
"successful" software company.  It is the direct consequence of the
fact that most participants in the shrink-wrapped software market
don't really care about quality, safety, ease-of-use and TCO, their
whining not-withstanding.  Free markets work like democracies: Given
responsible, ethical and intelligent customers / citizens, they can
create paradise.  Of course, in most mass markets / communities, those
customers / citizens are in a stark minority, and thus paradise is
unatainable[1].

Back to Common Lisp:

If Lisp is about anything, it's about doing the right thing, or at
least trying very very hard to do so, and recognizing that to achieve
this, you have to move very carefully, yet move nonetheless.  There
has gone much thought, and philosophical analysis, into nearly all of
the features you'll find in the current ANSI CL spec, and I expect the
same to happen with any other new ingredient that might be added to
that self-same standard in the future.

That high standard of doing the right thing, is the single most
outstanding reason that I'm working with CL.  It is not the dynamism,
the machismo or the nice parenthesis.  It is that I care about doing
the right thing, it is that my customers expect this of me (or else
they will not be my customers), and I trust Common Lisp to help me
achieve this.

So before we added some kind of (mandatory) compile-time type-checking
to Lisp, I'd want to be very sure that we are doing the right thing
here, that we've understood the issues at hand, the limitations,
the user's expectations, and the ability of implementations to
successfully implement this reliably.

Well, and C++/Java-style "type-checking" strikes me as being most
obviously not the right thing.

IMNSHO, IF C++ or Java programmers *really* cared about type-checking
at compile-time, they wouldn't be using those languages in the first
place.  To care about type-checking, you'd want to have a sensible and
expressive type-system to start with.  So you'd want at least something
like Ada, which also has bounds checking and a lot of other stuff you'd
want, or much better yet, you'd want something like the current crop of
typed pure functional languages, like Haskell or OPAL, etc., which not
only have expressive type-systems, and compile-time type-checking but
also type-inference, and at least in the case of OPAL, an algebraic
property language, which allows you to specify further properties of
your defined operations, to be checked at compile-time where possible.

That would be the course of action for C++ programmers that *really*
cared about compile-time type-checking.

Since the above mentioned languages don't have huge amounts of new
recruits either, it seems to me that most C++ programmers care about
compile-time type-checking like they care about OOP, or speed, or
portability, or most other things for that matter: It is a
must-have-it-and-exactly-this-way feature, yet they don't really know
what it is, or care about the underlying semantics or problems.  As
long as the compiler acts like it's doing something, everything's just
fine.  The sayings "Lisp programmers know the value of everything and
the cost of nothing" vs. "C++ programmers know the cost of everything,
yet the value of nothing" come to mind.  And since the time of this
saying, I think CL programmers at least have gotten a long way to
knowing the cost of things, yet I still see no movement in the C++
community of starting to care about the value of things.

Since I've heard in this discussion that C++-style type-checking is
mostly helpful in uncovering simple mistakes in argument order, etc.,
(which strikes me as being as mostly unrelated to type-checking), I'd
suggest using environments that reduce the likelyhood of MAKING those
mistakes.  Although I've not been prone to making those mistakes even
in languages like C++, in my Lisp environment, not only have I got the
arglist and documentation of every Lisp operator -- whether built-in or
user-defined -- at my finger-tips, but also the complete Hyperspec, all
just a keypress away.  So if I'm only a tiny bit in doubt about
argument order, or semantics, I look them up.  And guess what, I'm
quite a bit better at doing that kind of checking, than any compiler
I've yet seen (besides the SSC of course ;).

Of course I'd still be very willing to listen to the ideas and designs
of someone who *REALLY* cares about type-checking at compile-time.  But
I fear that since the type systems of modern pure functional languages
are still a much researched area, meaningfully type checking a language
like CL seems to me to be worthy of a number of PhDs before the design
space is clearly understood.

Of course, a much more "simplistic" kind of type-checking can be
attained with CMU CL today... Not that I see most former C++ users
flocking to CMU CL instead of other CL implementations though...

Regs, Pierre.

Footnotes:
[1]  Note that these ideas are over 2000 years old...

[2]  In reality of course, it's the languages' communities that care,
and not the language itself ;)

--

  "One smaller motivation which, in part, stems from altruism is Microsoft-
   bashing." [Microsoft memo, see http://www.*-*-*.com/ ]



Tue, 23 Oct 2001 03:00:00 GMT  
 Reasons for rejecting Lisp (was Re: Newbie questions [Followup to comp.lang.lisp])

| There is a lot of research going on in the area of virtual types and
| genericity.  Don't be surprised to see a revision of C++ templates in the
| future, or the emergence of a new language.  In fact, the discussion
| about adding genericity to Java has prompted a lot of activity in this
| area of research.  The point with all this is that languages that are
| alive tend to learn from experience and improve over time.

  I tend to think of this in terms of young people who learn something that
  older people have known for decades.  the world is getting increasingly
  complex, so the effort needed to get up to speed also increases and young
  people need to work harder to catch up.  and when they do, they have a
  steeper "gradient" than the older people they catch up with, so it is
  only natural that they want to continue with their catch-up speed and go
  on to do new stuff at a higher pace than they think the old people do.
  that's why you find new languages picking up a lot of _experimental_
  stuff that is "new" in some sense of the word, but which older people
  know to be junk, because it's something they discarded long ago, and
  people who catch up don't see where people retracked after going wrong,
  only where they went and decided to proceed.  similarly, new languages
  will do a lot of "research" and get a lot of funding for concepts and
  ideas that have previously been discarded.  however, to make this fly,
  they have to call it something else, the same way people who want to
  "circumvent" patents have to do _something_ clever on their own that lets
  them use somebody else's inventions.  except that regurgitated research
  uses somebody else's money by fooling people who don't know that it
  didn't work the last time around.

  and with all these new languages and regurgitated research, progress is
  _actually_ moving a lot slower than it would have if people could just
  stick to using other people's inventions instead of optimizing for their
  own degrees and for funding fun research and publicity hunters.

| I don't share your believe in the power of the market to lead us to
| paradise.  If the market had this power would Lisp be the fringe language
| it is?  Would Microsoft be the most successful software company?

  this is so mind-bogglingly over-simplified an attitude that I can't begin
  to answer it, but Microsoft has succeeded because it moved technical
  issues into _irrelevant_ positions.  people do _not_ buy Microsoft's
  shitware because they want quality, robustness, investment protection, or
  the like, they buy it out of fear of not being able to keep up with the
  competitors for their manpower and with companies they exchange files
  with.  Microsoft did, however, offer something of relevance a good number
  of years ago: they gave the suits a computer on their own desk that the
  computer people didn't control.  _that_ was the relevant criterion that
  propelled Microsoft into their leading role in the minds of the people
  who decide life or death in business: the suits.  like evolution, any
  irrelevant property can mutate without control, and some day it might
  prove to be relevant once sufficiently advanced.

  I read Kent Pitman's incessant argumentation for the "market" to be a
  strong voice to let the vendors know that certain issues are _relevant_
  to their customers, because the market only decides what's relevant, the
  irrelevant is taken for granted, and can be _anything_ that doesn't get
  relevant one way or another.  Kent's trying to influence that, and lots
  of people are trying to let people know what kind of irrelevant issues
  caused them to purchase virus distribution vehicles and security holes
  from Microsoft along with the relevant ego-stroking abilities for suits.

#:Erik



Tue, 23 Oct 2001 03:00:00 GMT  
 Newbie questions [Followup to comp.lang.lisp]

Quote:

> There has gone much thought, and philosophical analysis, into nearly
> all of the features you'll find in the current ANSI CL spec, and I
> expect the same to happen with any other new ingredient that might
> be added to that self-same standard in the future... So before we
> added some kind of (mandatory) compile-time type-checking to Lisp,
> I'd want to be very sure that we are doing the right thing here

If you read the discussion in this thread carefully you will find that
not everybody, and certainly not me, was asking for a language
change. The suggestion was for implementations to make use of the type
information that can already be specified using existing language
features. I am referring here to types specified using the declare
form, type specifiers of slots, argument types in generic functions,
and perhaps other things I can't think of at the moment.

Especially in the CLOS area, where the language already requires a lot
more type checking than in other parts of CL, I find the behaviour of
the commercial implementation I'm using rather puzzling. Take this
example:

(defclass foo () ())
(defgeneric bla ((self foo) (num integer)))
(defmethod bla ((self foo) arg2 arg3))

The last call raises an error because the method bla doesn't conform
to the generic function's signature. Good.

But when I do this:

(defun bob () (bla (make-instance 'foo) 1 2))

which includes an incorrect call to the same generic function there is
no error and no warning. The environment clearly has the information
to warn me about this error here and now, but it doesn't. Instead, I
or the QA department get an exception when (bob) is called at runtime.

So, I'm not asking for any deep change in Lisp, the language, just
some early warnings from the implementation's compiler about my
frequent blunders :-(

Quote:
> Well, and C++/Java-style "type-checking" strikes me as being most
> obviously not the right thing.

Well, there is room for improvement, but I wouldn't discount it as
harshly as you do.

Quote:
> you'd want something like the current crop of typed pure functional
> languages, like Haskell or OPAL, etc.,

You may want to add Cecil and Idea to this list.

Quote:
> That would be the course of action for C++ programmers that *really*
> cared about compile-time type-checking.

C++ has changed a lot over time because the community was not afraid
to learn from others. If this tradition continues you can expect the
result of research on these languages to make its way into C++ at some
point. In contrast, the Lisp community, if this newsgroup is any
indication, seems to totally discount the value of static typing. This
can mean a number of things, of course, including the possibility that
I'm totally off-base. :-)

Quote:
> The sayings "Lisp programmers know the value of everything and the
> cost of nothing" vs. "C++ programmers know the cost of everything,
> yet the value of nothing" come to mind.

You may also want to consider Guy Steele's statement suggesting that
programming language design is an evolutionary process.

Quote:
> Since I've heard in this discussion that C++-style type-checking is
> mostly helpful in uncovering simple mistakes in argument order, etc.,
> (which strikes me as being as mostly unrelated to type-checking), I'd
> suggest using environments that reduce the likelyhood of MAKING those
> mistakes.  Although I've not been prone to making those mistakes even
> in languages like C++, in my Lisp environment, not only have I got the
> arglist and documentation of every Lisp operator -- whether built-in or
> user-defined -- at my finger-tips, but also the complete Hyperspec, all
> just a keypress away.  So if I'm only a tiny bit in doubt about
> argument order, or semantics, I look them up.

This is a misunderstanding of what I was trying to express by the term
'simple error'. When referring to simple mistakes I am talking
precisely about situations when I have absolutely NO DOUBT about
what I'm doing, but get it wrong anyway, like forgetting an argument
in a call, accidentally passing the wrong variable, etc. etc.

Quote:
> Of course, a much more "simplistic" kind of type-checking can be
> attained with CMU CL today... Not that I see most former C++ users
> flocking to CMU CL instead of other CL implementations though...

Others have mentioned CMU CL as well, I'll take a look at this.
Unfortunately, it won't help in my current situation where we depend
on third-party packages which are not available for CMU CL, not to
mention a heavy investment in our own existing code.

Joachim

--




Tue, 23 Oct 2001 03:00:00 GMT  
 Newbie questions [Followup to comp.lang.lisp]

| CMUCL alows you to specify types, and I imagine that the commercial
| compilers do as well.  Just because it is not specified in ANSI does not
| mean that it does not exist in most implementations... but it would be
| nice if it were specified.

  could you give some examples of the types that CMUCL allows that are not
  the ANSI standard?

#:Erik



Tue, 23 Oct 2001 03:00:00 GMT  
 Newbie questions [Followup to comp.lang.lisp]

| In contrast, the Lisp community, if this newsgroup is any indication,
| seems to totally discount the value of static typing.

  that's funny -- I read it exactly that opposite way.  Lispers care about
  typing, including static type information, and because they care, they
  know what kind of costs are involved in them relative to the benefits and
  why the C++ model is so fundamentally braindamaged as to become totally
  unpalatable and useless.  _because_ we value static type information, but
  also know the costs, we have decided against anal-retentive tools, but
  would use tools that can utilize such information productively.  however,
  the kinds of mistakes that you seem to think are so important do not in
  fact occur often enough to be a significant problem, so the value would
  lie in optimization across function calls.  this is dangerous territory
  in an environment where you can change function definitions dynamically.

#:Erik



Tue, 23 Oct 2001 03:00:00 GMT  
 Newbie questions [Followup to comp.lang.lisp]
On Fri, 07 May 1999 01:00:48 GMT, Joachim Achtzehnter

Quote:

>Others have mentioned CMU CL as well, I'll take a look at this.
>Unfortunately, it won't help in my current situation where we depend
>on third-party packages which are not available for CMU CL, not to
>mention a heavy investment in our own existing code.

>Joachim

As far as I could tell by looking at CMUCL documentation, CMUCL is for
UNIX only.  Is there a Windows version?

Joshua Scholar



Tue, 23 Oct 2001 03:00:00 GMT  
 Newbie questions [Followup to comp.lang.lisp]

Quote:

> As far as I could tell by looking at CMUCL documentation, CMUCL is for
> UNIX only.  Is there a Windows version?

Nope. (Someone once mentioned a few of the cmucl-imp people are
interested in one.)

Try:
http://www.franz.com
http://www.harlequin.com
http://www.corman.net (Free with source-code + 30-day shareware IDE).
http://clisp.cons.org (GNU GPL)

Or my personal recommendation:
http://www.debian.org (get _real_ OS)

then visit franz.com to get the Linux Trial Edition and also grab the
Debian CMU CL packages. If you like visual IDEs there is also
Harlequin's new Linux Personal Edition.

Christopher



Tue, 23 Oct 2001 03:00:00 GMT  
 Newbie questions [Followup to comp.lang.lisp]

Quote:


> | CMUCL alows you to specify types, and I imagine that the commercial
> | compilers do as well.  Just because it is not specified in ANSI does not
> | mean that it does not exist in most implementations... but it would be
> | nice if it were specified.

>   could you give some examples of the types that CMUCL allows that are not
>   the ANSI standard?

I haven't used CMUCL, but from what I've heard about it, I'm guessing
he means it hyperoptimizes what type info you give.  My impression is
that most compilers don't go to the same intense effort, but could.
The cool thing about CMUCL is supposed to be exactly the fact that its
many interesting optimizations didn't require language changes to do
in a conforming implementation.


Tue, 23 Oct 2001 03:00:00 GMT  
 Newbie questions [Followup to comp.lang.lisp]

Quote:



> >The overwhelmingly
> >most common reason is the perception that Lisp is a
> >special purpose language for academic projects where
> >efficiency doesn't matter.
> So I'd think a better question than why people who don't know anything
> about modern Lisp systems don't use them would be, what do Lisp
> systems need in order to be useful to everyone who does know about
> them.

I think its the usual circular reinforcement problem, the reputation of
LISP attracts people writing acandemic projects where efficiency doesn't
matter, and thus LISP conforms ever more to those people, which
increases its reputation in that department.

Of course, efficiency is no longer an issue with LISP, the dynamic
comiler technology keeps up well enough with C++ or whatever.

More important issues are things like packaging; many lisp environment
do not compile executables, and many of the ones that do still dont
provide full functionality of the interpreter for the environment, and
so your generated program can lack the features you typically desire
from a LISP program, like the ability to dynamically self-modify, or
allow the user to type in custom algorithms.  This basically means that
a lot of useful programs are undeliverable without including the lisp
environment itself.

Other places where lisp falls severely short currently is the areas that
interest mainstream programmers the most: database access, sockets,
threading, IPC, and 3d graphics.  None of these interfaces are
standardised or even discussed, and while most implementations now have
some or all of these facilities, they are not cohesive in their
interface, and are sometimes poorly documented and incomplete to boot.

Some LISP implementations still do not interface well with other
languages, while "popular" languages (C/C++/Objective-C, Java, Ada,
Pascal) generally have a relatively safe way of communiating between
languages (although the interface definitions in Ada can be fairly
arduous).

LISP's object-oriented paradigm is powerful and yet... It's essentially
dynamic operator overloading, which is about as interesting to an object
modeller as a stack of bricks.  Although this is certainly only an
opinion and perhaps a trend, object orientation is centered on message
passing, while LISP's object orientation is based on function calls
(still).  I won't say its not USEFUL, but its not attractive, and its
not a step forward unless you are writing "toy" applications.

This is only the beginning of a long list of language weaknesses on
LISP.  Its important to realise that each language has its own use, and
LISP as it stands is great for writing small tests of algorithms before
porting them to a real language.

CU
Dobes



Tue, 23 Oct 2001 03:00:00 GMT  
 Newbie questions [Followup to comp.lang.lisp]

Quote:

> many lisp environment
> do not compile executables, and many of the ones that do still dont
> provide full functionality of the interpreter for the environment, and
> so your generated program can lack the features you typically desire
> from a LISP program, like the ability to dynamically self-modify, or
> allow the user to type in custom algorithms.  This basically means that
> a lot of useful programs are undeliverable without including the lisp
> environment itself.

So the reasoning would run "I'd like to use feature X in Lisp, but
can't without delivering a whole Lisp system, therefore I'll instead
write in a language which lacks X"?  Are you /sure/ people think
this way?  Sounds weird to me.

Quote:
> Other places where lisp falls severely short currently is the areas that
> interest mainstream programmers the most: database access, sockets,
> threading, IPC, and 3d graphics.  None of these interfaces are
> standardised or even discussed, and while most implementations now have
> some or all of these facilities, they are not cohesive in their
> interface, and are sometimes poorly documented and incomplete to boot.

Compared to, say, ISO C which includes all the things you mention
in the standard.  No?  Well, maybe C++?  No?  Pascal?  fortran?

Quote:
> Some LISP implementations still do not interface well with other
> languages, while "popular" languages (C/C++/Objective-C, Java, Ada,
> Pascal) generally have a relatively safe way of communiating between
> languages (although the interface definitions in Ada can be fairly
> arduous).

You ever tried passing an Ada function as a Motif callback?
Or a Java method?  I think you mean "most systems have some
limited way of talking to C, and sometimes C will answer".

Quote:
> LISP's object-oriented paradigm is powerful and yet... It's essentially
> dynamic operator overloading, which is about as interesting to an object
> modeller as a stack of bricks.  Although this is certainly only an
> opinion and perhaps a trend, object orientation is centered on message
> passing, while LISP's object orientation is based on function calls
> (still).  I won't say its not USEFUL, but its not attractive, and its
> not a step forward unless you are writing "toy" applications.

If you carefully restrict yourself to dispatching only on a single
parameter, the only difference I can see is that the verb comes before
the first argument, rather than after.  Is this /really/ enough to
demolish your "object modeller"'s world view?


Tue, 23 Oct 2001 03:00:00 GMT  
 Newbie questions [Followup to comp.lang.lisp]

Quote:

> > Some LISP implementations still do not interface well with other
> > languages, while "popular" languages (C/C++/Objective-C, Java, Ada,
> > Pascal) generally have a relatively safe way of communiating between
> > languages (although the interface definitions in Ada can be fairly
> > arduous).

> You ever tried passing an Ada function as a Motif callback?
> Or a Java method?  I think you mean "most systems have some
> limited way of talking to C, and sometimes C will answer".

JNI is not for the faint of heart.

Quote:
> > LISP's object-oriented paradigm is powerful and yet... It's essentially
> > dynamic operator overloading, which is about as interesting to an object
> > modeller as a stack of bricks.  Although this is certainly only an
> > opinion and perhaps a trend, object orientation is centered on message
> > passing, while LISP's object orientation is based on function calls
> > (still).  I won't say its not USEFUL, but its not attractive, and its
> > not a step forward unless you are writing "toy" applications.

> If you carefully restrict yourself to dispatching only on a single
> parameter, the only difference I can see is that the verb comes before
> the first argument, rather than after.  Is this /really/ enough to
> demolish your "object modeller"'s world view?

I might be very stupid.  But I am doing the following.

I have a hierachy of classes where I implement some manipulation
methods.

Then I have a separate hierarchy which implements some operation to be
dispatched in terms of the first one.

I can't escape doing the following

class Clazz
{
        type_t do_something(A a);
        type_t do_something(B b);
        type_t do_something(C c);
        type_t do_something(D d);
        ...
        // You get the idea...
        // Suppose you also have A -> B -> C-> D -> as your hierarchy.

        void do_something_appropriate(A a)
          {
                do_something(a);
          }

Quote:
}

Now, suppose you have code like

{
        Clazz clazz = new Clazz();
        B myB = new B();

        clazz.do_something_appropriate(myB);

Quote:
}

This is Java like. In C++ you have extra messiness due to 'virtual'
and pointer/references.

Now, what do you expect gets printed?

In Common Lisp it is exactly what you'd expect.

Cheers

--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa



Tue, 23 Oct 2001 03:00:00 GMT  
 
 [ 350 post ]  Go to page: [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24]

 Relevant Pages 
 

 
Powered by phpBB® Forum Software