Newbie questions [Followup to comp.lang.lisp] 
Author Message
 Newbie questions [Followup to comp.lang.lisp]

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.

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

>    clazz.do_something_appropriate(myB);
> }

> 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.

Allow me to continue.

You claim that CLOS style object orientation is only for 'toy'
systems.

If you went along with my example and did some extra playing around,
you will have noticed that you soon introduce a lot of "tag"
statements (which, AFAIK Java supports much better that C++) in order
to achieve your goals.  You can always claim that I designed my
hierarchies in a poor way, but that is begging the question.

In CL you do

        (defmethod do-somethin ((c clazz) (an-a a)) ...)
        (defmethod do-somethin ((c clazz) (a-b b)) ...)
        (defmethod do-somethin ((c clazz) (a-c c)) ...)

        (defmethod do-somethin-approriate ((c clazz) (an-a a))
           (do-something c an-a))

end of story.

Now go ahead, extrapolate and maintain this and the C++ or Java
versions.  Better yet, add a new class to the a->b->c hierarchy. What
would you have to do, had you written the beast in C/C++? What do you
have to do if it was written in CL?

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.*-*-*.com/ ~marcoxa



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

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.

Calumny!

I /responded/ to the above by suggesting that carefully avoiding
interesting CLOS features allows you to emulate the "attractive"
OO style the original author prefers.

The fact that your code needs CLOS features that C++ doesn't
have just goes to show you weren't careful enough. :-)



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

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.

> Calumny!

> I /responded/ to the above by suggesting that carefully avoiding
> interesting CLOS features allows you to emulate the "attractive"
> OO style the original author prefers.

OOPS. I jumped a citation level. :{ Sorry

Quote:
> The fact that your code needs CLOS features that C++ doesn't
> have just goes to show you weren't careful enough. :-)

.. in choosing the language I suppose :)

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  
 Newbie questions [Followup to comp.lang.lisp]

[ a _lot_ of ignorant {*filter*}deleted ]

  in all my years on USENET, I have seen a lot of destructive idiots post
  their favorite drivel in the guise of facts, and some even manage to look
  like they have a clue, but I cannot recall anyone quite so destructive or
  quite so willing to lie and misrepresent as Dobes Vandermeer of the aptly
  named MINDLESS.COM.  _nothing_ he says is true or even relevant to what
  Lisp can offer today or why this offer is not widely accepted.

  Lisp does have a problem: it doesn't come with a big enough stick with
  which to hit the ignorant {*filter*}s so they get out of their retarded state.

#:Erik



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

Quote:

> This is not why most people want static type checking. The real big
> advantage of static type checking is neither a matter of enabling
> compilers to optimize code, nor to prove complete correctness, but to
> catch simple errors early. It is the difference between being told by
> the compiler that I've made a typo versus the bug blowing up in front
> of a user at runtime.

Here's a true story.  I was demonstrating a distributed application at
a `demo-days' event.  It took about 5 minutes to bring the whole
application up from scratch.

While doing it for one potential customer, I made a typo that invoked
behavior I hadn't handled.  The application went into the de{*filter*}
with a `segmentation violation' error.

Imagine what would have happened if this were a C or C++ program.  But
this was lisp.  I just made a few conciliatory noises and re-invoked
the main entry point of the application.  Total time: 10 seconds.  I'm
not even sure the person watching the demo realized it had crashed.

Note that this was a (simple) logic error that static typing would not
have caught.

The m{*filter*}is that lisp is DIFFERENT from other languages, and things
you need to give great attention to with other languages are
relatively unimportant in lisp.

Unless I'm mistaken, it's already possible to declare everything in
lisp.  It's also possible to give optimization settings that will warn
you about type problems at compile time (at least, CMUCL will do
this).  You can get run-time checks with appropriate optimization
settings, and disable them selectively if you need speed.  You can get
the best of both styles of programming.  So I don't see what the fuss
is about.

--

How many Analytic Philosophers does it take to change a light bulb?
None---it's a pseudo-problem. Light bulbs give off light (hence the
name). If the bulb was broken and wasn't giving off light, it wouldn't
be a 'light bulb' now would it? (Oh, where has rigor gone?!)



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

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.

Sorry, but this doesn't make much sense to me, I must be missing your
point. Perhaps you should explain what you mean? CLOS generic
functions offer everything that C++ virtual methods, Java methods,
Eiffel features, etc. give you. What is it that makes generic
functions less useful than their more primitive counterparts in most
other OO languages?

Is it multiple dispatch? Well, other languages are envious of this
feature, so it can hardly be a disadvantage. Stroustrup himself says
in one of his books that multiple dispatch is the one major feature he
would have liked to add to C++, if only he had found the time to
integrate it without compromising the performance of virtual function
calls.

Is it the difference in syntax? This can hardly be responsible for
limiting the usefulness to toy applications, and again there are
others who recommend to migrate to the more symmetric placement of
arguments, e.g. see Chris Date's recent book which proposes a database
language along these lines. And in case you haven't noticed: using the
STL with C++ methods would have been much less awkward if the target
argument of C++ method calls was in the natural place.

And unlike other parts of CL, CLOS even requires a fair amount of
static type checking by requiring consistent lambda lists in the
methods of a generic function, although some implementations could
provide more help with type checking than they do (at least warnings),
see my other postings on this subject.

Joachim

--




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

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.

To Joachim: which vendor poorly documents any of these interfaces?

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

Java. :-) But seriously now, for the ammount of typing time it takes
to pound out a decent Java app (typing speed seems to be the main
bottleneck with Java programming), you could have written it in Lisp
_and_ read the documentation to three different Lisp vendor's products
so that you could write your thin portable abstraction layer to all
their non-standard functionality that you're _actually_ using, not
just imagining that you'll have some need for the portability and then
using Java to write an app that you only get arround to distributing
for Windows-only customers anyways.

Christopher



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

Quote:
> To Joachim: which vendor poorly documents any of these interfaces?

That should be Dobes Vandermeer, not Joachim. Apologies to
Joachim. I'd cancel the article and post a corrected one, but it's
probably already too late (3 minutes). That'll teach me to rush in the
morning before class....

Christopher



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

Quote:

> Unless I'm mistaken, it's already possible to declare everything in
> lisp.

Yes, I have pointed this out a few times already. I am not asking for a
language change, only for implementations to make USE of this
information to warn me about problems earlier rather than later.

Quote:
> It's also possible to give optimization settings that will warn
> you about type problems at compile time (at least, CMUCL will do
> this).

CMUCL indeed provides a lot of the warnings I am looking for, I played
with it last night. Too bad that the commercial implementation I'm
stuck with for now doesn't! :-(

Quote:
> You can get run-time checks with appropriate optimization
> settings, and disable them selectively if you need speed.  You can get
> the best of both styles of programming.  So I don't see what the fuss
> is about.

Well, as you can see we are not so far apart after all. :-)  These
'appropriate optimization settings' are all I want.

Joachim

--




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

Quote:

> (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.

What's really puzzling about this particular behavior is (at least in
Allegro Common Lisp and Macintosh Common Lisp) that in the following
example with non-generic functions, the compiler does produce a warning:

USER> (defun foo (x y) (+ x y))
FOO
USER> (compile 'foo)
FOO
NIL
NIL
USER> (defun bar (x y z) (foo x y z))
BAR
USER> (compile 'bar)
; While compiling BAR:
Warning: FOO should be given exactly 2 arguments.  It was given 3 arguments.
Problem detected when processing
       (FOO X Y ...)
inside (BLOCK BAR (FOO X Y ...))
inside (PROGN (BLOCK BAR (FOO X Y ...)))

BAR
T
T

----------------------------------------

Is there something about generic functions that makes it harder to do
the same sort of argument count analysis?  

--



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