I am giving a very short presentation (15 min.) + handouts based on
Object Oriented Programming: The CLOS Perspective, chapter 7 CLOS and C++,
pages 157-180. MIT Press, 1993, chapter author Linda G DeMichiel.
I have LW(Personal) running on my laptop and was thinking about
using it to give a demonstration.
Aside from multiple dispatch, any ideas of quick code to show
off CLOS and Lisp to a heathen flock that is trained in Java?
(not to mention being taught that Lisp is simply a functional language)
It's a programming languages course, there's been a massive editing of
the information being passed to make points about the differences
between the paradigms without pointing out the some languages refuse
to be classified so easily.
--
Geoff
Geoffrey Summerhayes wrote:
>
> ...
>
> Aside from multiple dispatch, any ideas of quick code to show
> off CLOS and Lisp to a heathen flock that is trained in Java?
> (not to mention being taught that Lisp is simply a functional language)
>
in general, introduce some of what one can do with first-class functions. eg,
- using method combinations to implement things like aspect-oriented
programming, thread synchronization, introspective instance cloning and navigation.
(look around in http://www.setf.de/library/de/setf/utility/{clos,graph}/ for examples)
- introspective dynamic programming using no-applicable-method
james anderson wrote:
>
> Geoffrey Summerhayes wrote:
>
>>...
>>
>>Aside from multiple dispatch, any ideas of quick code to show
>>off CLOS and Lisp to a heathen flock that is trained in Java?
>>(not to mention being taught that Lisp is simply a functional language)
>>
>
>
> in general, introduce some of what one can do with first-class functions. eg,
>
> - using method combinations to implement things like aspect-oriented
> programming, thread synchronization, introspective instance cloning and navigation.
It has been five years since I ported Cells to Java, but I seem to
recall, oh my, a Reflection package? Anyway, I seem to recall pretty
decent introspective capabilities.
Mind you, I am a little confuse dby the OP as to whether Java or C++ are
being compared.
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton wrote:
>
>
> james anderson wrote:
>
>>
>> Geoffrey Summerhayes wrote:
>>
>>> ...
>>>
>>> Aside from multiple dispatch, any ideas of quick code to show
>>> off CLOS and Lisp to a heathen flock that is trained in Java?
>>> (not to mention being taught that Lisp is simply a functional language)
>>>
>>
>>
>> in general, introduce some of what one can do with first-class
>> functions. eg,
>>
>> - using method combinations to implement things like aspect-oriented
>> programming, thread synchronization, introspective instance cloning
>> and navigation.
>
>
> It has been five years since I ported Cells to Java, but I seem to
> recall, oh my, a Reflection package? Anyway, I seem to recall pretty
> decent introspective capabilities.
>
> Mind you, I am a little confuse dby the OP as to whether Java or C++ are
> being compared.
Oh, OK, just noticed the subject. :)
>
> kt
>
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
How about multi-inheritance and before/after methods?
------------------------+-----------------------------------------------------
Christian Lynbech | christian ··@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
Christian Lynbech <·················@ericsson.com> wrote in message news:<··············@dhcp229.ted.dk.eu.ericsson.se>...
> How about multi-inheritance and before/after methods?
I would also demo these things:
- dispatch on EQL identity: being able to specialize a method to a symbol,
integer value or some object instance rather than just a class!
- encapsulation: how it works in CLOS; and how the responsibility for
encapsulation is divided between the package system and accessors.
- indirection upon generic functions: compare to the weakness and
inflexibility of ``pointer to member'' in C++. E.g.
;; dynamically dispatched for each object!
(mapc #'my-generic-function my-list-of-clos-objects)
Indirection on generic functions implements the ``Visitor Pattern''
right in the language.
- multiple inheritance hygiene: how CLOS doesn't have the stupid clash
problems because its package system is based on symbols rather than
conflated into the class system!
C++:
// Oops, both bases have a virtual function void Draw()!
// But you want to override their behaviors in Game!
// Clumsy workarounds.
class Game : public GraphicalObject, public Lottery { ... };
Lisp:
;; no problem; GRAPHICAL-PACKAGE::DRAW and LOTTERY-PACKAGE::DRAW are
;; completely different symbols, naming distinct generic functions.
;; Conflicts occur, and can be are resolved, when both
;; packages are used, which is completely independent of programming
;; language semantics such as class inheritance or whatever.
;; Package system lets programmer choose, in a given package,
;; which "DRAW" symbol to use by its short name and which will
;; have to be qualified.
(defclass game (graphical-package::object lottery-package::lottery) ...)
> It's a programming languages course, there's been a massive editing of
> the information being passed to make points about the differences
> between the paradigms without pointing out the some languages refuse
> to be classified so easily.
If you get the chance before the presentation, skim through Andrei
Alexandrescu's "Modern C++ Design." There are lots of template-based
design patterns in there that are much nicer in a CLOS-like language.
In particular, look at the stuff about abstract factories and the
visitor pattern.
"Geoffrey Summerhayes" <·············@hotmail.com> writes:
> Aside from multiple dispatch, any ideas of quick code to show
> off CLOS and Lisp to a heathen flock that is trained in Java?
> (not to mention being taught that Lisp is simply a functional language)
How about runtime-redefinition of classes and
UPDATE-INSTANCE-FOR-REDEFINED-CLASS?
Henrik Motakef wrote:
> "Geoffrey Summerhayes" <·············@hotmail.com> writes:
>
>
>>Aside from multiple dispatch, any ideas of quick code to show
>>off CLOS and Lisp to a heathen flock that is trained in Java?
>>(not to mention being taught that Lisp is simply a functional language)
>
>
> How about runtime-redefinition of classes and
> UPDATE-INSTANCE-FOR-REDEFINED-CLASS?
Or some CHANGE-CLASS magic?
Cheers
--
Marco
In article <··············@pokey.internal.henrik-motakef.de>,
Henrik Motakef <············@henrik-motakef.de> wrote:
>"Geoffrey Summerhayes" <·············@hotmail.com> writes:
>
>> Aside from multiple dispatch, any ideas of quick code to show
>> off CLOS and Lisp to a heathen flock that is trained in Java?
>> (not to mention being taught that Lisp is simply a functional language)
>
>How about runtime-redefinition of classes and
>UPDATE-INSTANCE-FOR-REDEFINED-CLASS?
I wouldn't recommend that in a quick intro like this. It's an arcane
feature that should be relatively rarely used.
--
Barry Margolin, ······@alum.mit.edu
Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin <······@alum.mit.edu> wrote in message news:<··············@news.level3.com>...
> In article <··············@pokey.internal.henrik-motakef.de>,
> Henrik Motakef <············@henrik-motakef.de> wrote:
> >"Geoffrey Summerhayes" <·············@hotmail.com> writes:
> >
> >> Aside from multiple dispatch, any ideas of quick code to show
> >> off CLOS and Lisp to a heathen flock that is trained in Java?
> >> (not to mention being taught that Lisp is simply a functional language)
> >
> >How about runtime-redefinition of classes and
> >UPDATE-INSTANCE-FOR-REDEFINED-CLASS?
>
> I wouldn't recommend that in a quick intro like this. It's an arcane
> feature that should be relatively rarely used.
I was going to suggest runtime redefinition of classes, too; Henrik
beat me to it. I would agree that it should be rare in actual use,
but if you want to wow a group of people coming from mostly C++/Java
backgrounds, it seems like a good possible choice. To do the same
thing in C++ you'd need to just about rewrite the class system (or, at
least, your use of it), I would think. Right tool for the job and all
that: C++ has certain strenghts; so does Lisp, run-time dynamicism
being one of them.
-- Larry
In article <····························@posting.google.com>,
Larry Clapp <······@theclapp.org> wrote:
>I was going to suggest runtime redefinition of classes, too; Henrik
>beat me to it. I would agree that it should be rare in actual use,
>but if you want to wow a group of people coming from mostly C++/Java
>backgrounds, it seems like a good possible choice. To do the same
>thing in C++ you'd need to just about rewrite the class system (or, at
>least, your use of it), I would think. Right tool for the job and all
>that: C++ has certain strenghts; so does Lisp, run-time dynamicism
>being one of them.
The only time I remember seeing it being used, the developers eventually
rewrote it to abandon the practice. It was Symbolics's hash table
mechanism. Since different hash table implementations are appropriate
depending on the size and attributes of the table, they represented these
as different classes, and as a hash table grew or shrunk it could morph
into a different class as necessary. I think the problem they ran into was
that this could happen while it was deep inside a combined method, and
after the change-class they'd no longer be in the appropriate method.
They redesigned it to use a single main HASH-TABLE class and various
representation classes, and the representation object would be contained in
a slot of the HASH-TABLE object. To change the representation you created
a new representation of the appropriate type and copied the contents from
the old one to the new one. Since this always happened in a method
specialized on the HASH-TABLE class, there was no problem.
And if you were doing it in C++, I expect you'd adopt something like the
latter approach. The ability to change the class of an object directly
seems like a useful thing, but in practice I expect it raises many thorny
issues. And it's easy to use other mechanisms to solve the problem you
thought needed CHANGE-CLASS and avoid these issues when doing so.
--
Barry Margolin, ······@alum.mit.edu
Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin <······@alum.mit.edu> writes:
> The ability to change the class of an object directly seems
> like a useful thing, but in practice I expect it raises many
> thorny issues. And it's easy to use other mechanisms to solve
> the problem you thought needed CHANGE-CLASS and avoid these
> issues when doing so.
I once implemented a stateful message handler like this:
(defmethod handle ((foo state-1) (msg message-1))
...)
(defmethod handle ((foo state-1) (msg message-2))
...)
(defmethod handle ((foo state-2) (msg message-1))
...)
and for state transitions, I'd use CHANGE-CLASS with initargs for
data that is only available in certain states. Works nicely...
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID #xD26EF2A0
Barry Margolin wrote:
>
> In article <··············@pokey.internal.henrik-motakef.de>,
> Henrik Motakef <············@henrik-motakef.de> wrote:
> >"Geoffrey Summerhayes" <·············@hotmail.com> writes:
> >
> >> Aside from multiple dispatch, any ideas of quick code to show
> >> off CLOS and Lisp to a heathen flock that is trained in Java?
> >> (not to mention being taught that Lisp is simply a functional language)
> >
> >How about runtime-redefinition of classes and
> >UPDATE-INSTANCE-FOR-REDEFINED-CLASS?
>
> I wouldn't recommend that in a quick intro like this. It's an arcane
> feature that should be relatively rarely used.
what of the practice of using initialize-instance for specific classes rather
than make-instance for specific metaclasses to perform a task which java/c++
programmers would recognize as a "factory". in the metaclass case one does not
change-class, which seems safer. in the instance case, one would change-class
and then restart the initialization process. i observe that this functions in
practice, but i would wonder about the interaction with
update-instance-for-difference-class / shared-initialize.
...
"james anderson" <··············@setf.de> wrote in message
······················@setf.de...
>
> what of the practice of using initialize-instance for specific classes
rather
> than make-instance for specific metaclasses to perform a task which
java/c++
> programmers would recognize as a "factory". in the metaclass case one does
not
> change-class, which seems safer. in the instance case, one would
change-class
> and then restart the initialization process. i observe that this functions
in
> practice, but i would wonder about the interaction with
> update-instance-for-difference-class / shared-initialize.
>
> ...
Good ideas all.
Ok, no, I am missing something. Why would one choose initialize-instance
over
make-instance for a factory? It seems that mak-instance would be the better
choice. Not that I have used either, but I will be playing around with them
over the next few days to see if I can come up with something simple enough
to get the point across.
Maybe I'll dust off my copy of Design Patterns while I'm at it, and look for
some examples of C++ there to rewrite in Lisp...
--
Geoff
Geoffrey Summerhayes wrote:
>
> "james anderson" <··············@setf.de> wrote in message
> ······················@setf.de...
> >
> > what of the practice of using initialize-instance for specific classes
> rather
> > than make-instance for specific metaclasses to perform a task which
> java/c++
> > programmers would recognize as a "factory". in the metaclass case one does
> not
> > change-class, which seems safer. in the instance case, one would
> change-class
> > and then restart the initialization process. i observe that this functions
> in
> > practice, but i would wonder about the interaction with
> > update-instance-for-difference-class / shared-initialize.
> >
> > ...
>
> Good ideas all.
>
> Ok, no, I am missing something. Why would one choose initialize-instance
> over make-instance for a factory?
when you are not in a position to expect that the audience understands metaclasses.
> It seems that make-instance would be the better
> choice.
in general, agreed. but that means that there is a 1-1 correspondence between
metaclass instance and "factory". and, since there is likely to be an abstract
class in addition, that introduces some redundancy. if done at the class
level, one needs the abstract class only and it serves as the factory directly.
plus: if one shoehorns the logic into the class level, then one need presume
only that the audience understand the notion of "abstract class", rather than
"metaclass", which is an easier step for java/c++.
...
Geoffrey Summerhayes writes:
> Maybe I'll dust off my copy of Design Patterns while I'm at it, and look for
> some examples of C++ there to rewrite in Lisp...
Norvig did something similar in a talk he gave some time ago. The
PowerPoint slides are available at his site.
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Geoffrey Summerhayes wrote:
> I am giving a very short presentation (15 min.) + handouts based on
> Object Oriented Programming: The CLOS Perspective, chapter 7 CLOS and C++,
> pages 157-180. MIT Press, 1993, chapter author Linda G DeMichiel.
> I have LW(Personal) running on my laptop and was thinking about
> using it to give a demonstration.
>
> Aside from multiple dispatch, any ideas of quick code to show
> off CLOS and Lisp to a heathen flock that is trained in Java?
> (not to mention being taught that Lisp is simply a functional language)
I like the decoupling of Gfs from class definitions, and that a dispatch
ing argument can be just a number (and a method specialized on that) or
a whole frickin CLOS instance that gets all complicated over the
behavior based on what the CLOS instance has to say.
And what about the flexibility of specifying interesting initforms or
default-initargs? especially with the initform, I look at a slot
definition and I see the whole story (the default initarg won't be far
away). Speaking of the slot def deing more self-documenting this way,
how about the :documentation option?
You can beat the dynamic language dead horse by redefining a class on
the fly, ie, actually providing a method for
update-instance-for-redefined-class is pretty rare, but fixing a class
definition and then continuing from a backtrace is not. Similarly, I
think Erann has a show-stopper demo in which a widget on the screen
picks up new behavior because he shifts to the listener and redefines
the class.
I agree with those who argue that change-class and u-i-f-redefined-c are
obscure, but in a way they are germaine for what they say about the
whole introspection and dynamism thang.
Don't forget to mention Cells, either (or COSI or KR (tho that is not
CLOS)). :)
kt
>
> It's a programming languages course, there's been a massive editing of
> the information being passed to make points about the differences
> between the paradigms without pointing out the some languages refuse
> to be classified so easily.
>
> --
> Geoff
>
>
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
"Kenny Tilton" <·······@nyc.rr.com> wrote in message
·····························@twister.nyc.rr.com...
>
> Don't forget to mention Cells, either (or COSI or KR (tho that is not
> CLOS)). :)
>
Damn, I just KNEW when I started this thread that Kenny would bring up
Cells. :-)
--
Geoff
Geoffrey Summerhayes wrote:
> "Kenny Tilton" <·······@nyc.rr.com> wrote in message
> ·····························@twister.nyc.rr.com...
>
>>Don't forget to mention Cells, either (or COSI or KR (tho that is not
>>CLOS)). :)
>>
>
>
> Damn, I just KNEW when I started this thread that Kenny would bring up
> Cells. :-)
Yeah, sorry, that was spam: I also did a C++ port of Cells, and it turns
out the advertisement (for Lisp) is about macros (hiding necessary
plumbing) and anonymous functions, not CLOS.
Actually, it might be funny to keep slipping into non-CLOS stuff. just
as they are thinking something is incredibly cool you say, ok, sorry
that's off topic, can't talk about that. do that about five times and
then just snap and say, damn! it is so hard isolating CLOS per se, all
these cool things about Lisp work together so cleanly...
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
> Actually, it might be funny to keep slipping into non-CLOS
> stuff. just as they are thinking something is incredibly cool you
> say, ok, sorry that's off topic, can't talk about that. do that
> about five times and then just snap and say, damn! it is so hard
> isolating CLOS per se, all these cool things about Lisp work
> together so cleanly...
Great idea! I'll try it out on my coworkers.
Patrick
------------------------------------------------------------------------
S P Engineering, Inc. | The experts in large scale distributed OO
| systems design and implementation.
···@spe.com | (C++, Java, ObjectStore, Oracle, CORBA, UML)
"Kenny Tilton" <·······@nyc.rr.com> wrote in message
·····························@twister.nyc.rr.com...
>
>
> Actually, it might be funny to keep slipping into non-CLOS stuff. just
> as they are thinking something is incredibly cool you say, ok, sorry
> that's off topic, can't talk about that. do that about five times and
> then just snap and say, damn! it is so hard isolating CLOS per se, all
> these cool things about Lisp work together so cleanly...
>
Yep, I've been thinking about that. Earlier in the class the instructor
was asked why someone would choose a functional language over an imperative
or object oriented one. Needless to say he turned to me and said "Geoff, you
prefer using Lisp (unavailable at school, the closest language on the system
is Guile, after that it's C++,Java,various scripting languages, and Prolog)
could you field this one?"
For once, I was speechless, (never correct the teacher, sooner or later
he'll
get his revenge) my reasons for using Lisp have little to do with the fact
that I can program functionally and more to do with the number types, REPL,
and
the sheer wealth of constructs and functions in the language.
I'm just trying to figure out how to cover a basic outline of CLOS, and
sneak
in smart editors, Lisp-N, dynamic and lexical scoping, iteration constructs,
SETF, closures, etc. using LW to show it all at work. In 15 minutes.
I might have to run a little long... ;-)
--
Geoff
Geoffrey Summerhayes writes:
> Yep, I've been thinking about that. Earlier in the class the instructor
> was asked why someone would choose a functional language over an imperative
> or object oriented one. Needless to say he turned to me and said "Geoff, you
> prefer using Lisp (unavailable at school, the closest language on the system
> is Guile, after that it's C++,Java,various scripting languages, and Prolog)
> could you field this one?"
>
> For once, I was speechless, (never correct the teacher, sooner or later
> he'll
> get his revenge) my reasons for using Lisp have little to do with the fact
Prepare for a little gag. Get one of those accordion-like, multiple
credit card containers that are sometimes seen in comic
movies. Instead of the credit cards, put cards with the names of
programming paradigms supported by Lisp. Next time, tell the
instructor "You asked about functional programming? I have it!" and
prominently open the container in front of the audience.
> I'm just trying to figure out how to cover a basic outline of CLOS, and
> sneak
> in smart editors, Lisp-N, dynamic and lexical scoping, iteration constructs,
> SETF, closures, etc. using LW to show it all at work. In 15 minutes.
Preface your talk with the statement that giving an outline of
CLOS/Lisp in 15 minutes is as tough as giving an outline of
differential equations to junior-high school students, and assure the
audience that you are available for more in depth discussions.
If you have a class mate who is a video junkie, let him shoot some
footage showing you at your keyboard, cranking Lisp forms end
explaining what you are doing. Then distribute some copies of the
video at the talk. You may check Rainer Joswig's LispM videos for
inspiration.
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
"Geoffrey Summerhayes" <·············@hotmail.com> writes:
> "Kenny Tilton" <·······@nyc.rr.com> wrote in message
> ·····························@twister.nyc.rr.com...
>>
>> Don't forget to mention Cells, either (or COSI or KR (tho that is not
>> CLOS)). :)
>>
>
> Damn, I just KNEW when I started this thread that Kenny would bring up
> Cells. :-)
Didn't John McCarthy once use Cells?
Kenny Tilton <·······@nyc.rr.com> writes:
> Geoffrey Summerhayes wrote:
> > Aside from multiple dispatch, any ideas of quick code to show off
> > CLOS and Lisp to a heathen flock that is trained in Java? (not to
> > mention being taught that Lisp is simply a functional language)
>
> I like the decoupling of Gfs from class definitions, and that a
> dispatch ing argument can be just a number (and a method specialized
> on that) or a whole frickin CLOS instance that gets all complicated
> over the behavior based on what the CLOS instance has to say.
In my limited experience trying to get Java and C++ programmers
to consider the benefits of Lisp, this is a hard sell. The idea that
methods are owned by a class is deeply ingrained in those language
cultures. It's very easy to go off into an argument about
encapsulation that ultimately distracts the audience completely from
the core message.
Demonstrating the benefits of multimethods might help. Most C++
programmers have at least heard of double dispatch, but it isn't used
that often because of the coding overhead involved. C++ and Java
don't encourage consideration of solutions that involve such
techniques.
I'm certainly not saying that generic functions shouldn't be
discussed; they must be. I do recommend being prepared for when
someone raises the encapsulation and related arguments, though.
Good luck,
Patrick
------------------------------------------------------------------------
S P Engineering, Inc. | The experts in large scale distributed OO
| systems design and implementation.
···@spe.com | (C++, Java, ObjectStore, Oracle, CORBA, UML)
Patrick May <···@spe.com> writes:
> Kenny Tilton <·······@nyc.rr.com> writes:
> > Geoffrey Summerhayes wrote:
> > > Aside from multiple dispatch, any ideas of quick code to show off
> > > CLOS and Lisp to a heathen flock that is trained in Java? (not to
> > > mention being taught that Lisp is simply a functional language)
> >
> > I like the decoupling of Gfs from class definitions, and that a
> > dispatch ing argument can be just a number (and a method specialized
> > on that) or a whole frickin CLOS instance that gets all complicated
> > over the behavior based on what the CLOS instance has to say.
>
> In my limited experience trying to get Java and C++ programmers
> to consider the benefits of Lisp, this is a hard sell. The idea that
> methods are owned by a class is deeply ingrained in those language
> cultures. It's very easy to go off into an argument about
> encapsulation that ultimately distracts the audience completely from
> the core message.
If this happens, Scott Meyer's discussion how non-member functions
increase encapsulation might be handy:
http://www.cuj.com/documents/s=8042/cuj0002meyers/
Matthias <··@spam.pls> writes:
> If this happens, Scott Meyer's discussion how non-member functions
> increase encapsulation might be handy:
But Scott Meyers is not advocating making all class member variables
public or exposing them all to arbitrary mutation as CLOS does.
Most of my experience with classes comes from C++, and I still find
the CLOS exposure unsettling. I think Peter Norvig has a few
paragraphs in PAIP about how CLOS more or less punts on data
encapsulation. (Is it his bank account example, where there's no way
to prevent a user from arbitrarily changing the balance not respecting
the proper deposit or withdraw functions?)
He points out that one can't restrict the :reader or mutable half of
an :accessor to access within a set of methods, so data is either
immutable (public const static or member variables or const member
functions in C++) or freely mutable (public static or member variables
in C++). What's missing is an analog to private member variables in
C++ and the accessibility relationship they share with member
functions. The separation Scott Meyers advocates does not forgo this
last relationship; it only recognizes where it is non-essential.
--
Steven E. Harris :: ········@raytheon.com
Raytheon :: http://www.raytheon.com
> But Scott Meyers is not advocating making all class member variables
> public or exposing them all to arbitrary mutation as CLOS does.
I think the reasoning is that in Lisp/CLOS encapsulation is orthogonal
to the class mechanism. If you want to prevent a client from changing
a class's internal members, put it in a seperate package and don't
export the setter methods for that member. You can get the equivilent
of a C++ class with public interfaces and private members by making a
seperate package for the class, and only exporting the public
functions.
·······@mindspring.com (Rayiner Hashem) writes:
> I think the reasoning is that in Lisp/CLOS encapsulation is
> orthogonal to the class mechanism. If you want to prevent a client
> from changing a class's internal members, put it in a seperate
> package and don't export the setter methods for that member.
Ah, I had not thought of that. At the time I was reading the
aforementioned Norvig book, I didn't understand CL packages, but
thinking about it today I can see your point.
> You can get the equivilent of a C++ class with public interfaces and
> private members by making a seperate package for the class, and only
> exporting the public functions.
Unfortunately, I haven't seen this advice elsewhere. A person coming
from a background in C++ or Java would want to hear advice like this
for reassurance that access control can be layered over CLOS, whether
or not it's idiomatic to do so.
--
Steven E. Harris :: ········@raytheon.com
Raytheon :: http://www.raytheon.com
"Steven E. Harris" <········@raytheon.com> wrote in message
····················@raytheon.com...
> ·······@mindspring.com (Rayiner Hashem) writes:
>
> > I think the reasoning is that in Lisp/CLOS encapsulation is
> > orthogonal to the class mechanism. If you want to prevent a client
> > from changing a class's internal members, put it in a seperate
> > package and don't export the setter methods for that member.
>
> Ah, I had not thought of that. At the time I was reading the
> aforementioned Norvig book, I didn't understand CL packages, but
> thinking about it today I can see your point.
>
> > You can get the equivilent of a C++ class with public interfaces and
> > private members by making a seperate package for the class, and only
> > exporting the public functions.
>
> Unfortunately, I haven't seen this advice elsewhere. A person coming
> from a background in C++ or Java would want to hear advice like this
> for reassurance that access control can be layered over CLOS, whether
> or not it's idiomatic to do so.
I think this will be a fairly easy sell, but I'm going to have a tougher
time with the lack of destructors. My basic line on this will be:
1-reclamation of memory is handled automatically by the GC
2-reclamation of other system resources is problematic in a GC'd
language and best handled with other methods
Any additional thoughts?
--
Geoff
"Geoffrey Summerhayes" <·············@hotmail.com> writes:
> "Steven E. Harris" <········@raytheon.com> wrote in message
> ····················@raytheon.com...
> > ·······@mindspring.com (Rayiner Hashem) writes:
> >
> > > I think the reasoning is that in Lisp/CLOS encapsulation is
> > > orthogonal to the class mechanism. If you want to prevent a client
> > > from changing a class's internal members, put it in a seperate
> > > package and don't export the setter methods for that member.
> >
> > Ah, I had not thought of that. At the time I was reading the
> > aforementioned Norvig book, I didn't understand CL packages, but
> > thinking about it today I can see your point.
> >
> > > You can get the equivilent of a C++ class with public interfaces and
> > > private members by making a seperate package for the class, and only
> > > exporting the public functions.
> >
> > Unfortunately, I haven't seen this advice elsewhere. A person coming
> > from a background in C++ or Java would want to hear advice like this
> > for reassurance that access control can be layered over CLOS, whether
> > or not it's idiomatic to do so.
>
> I think this will be a fairly easy sell, but I'm going to have a tougher
> time with the lack of destructors. My basic line on this will be:
>
> 1-reclamation of memory is handled automatically by the GC
> 2-reclamation of other system resources is problematic in a GC'd
> language and best handled with other methods
>
> Any additional thoughts?
Constructs like WITH-OPEN-FILE also handle many of the cases that
destructors are used for--to guarantee that certain resources such as
file handles are released before the exit of a block. And since they
are syntactically obvious they are arguably a much better way to
express what is really going on.
Also, as part of 2 you can point out that Java has no destructors. Of
course you might need to be prepared to field questions about the Lisp
equivalent of finalization (a bad idea as anything more than a backup
and actually implemented in a pretty busted way in Java) and (if your
audience is full of real Java weenies) the Reference classes which are
the new version of finalization that actually work. I'm not sure what
the Lispy equivalents are; certainly they are implementation
dependent.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
"Geoffrey Summerhayes" <·············@hotmail.com> writes:
> I think this will be a fairly easy sell, but I'm going to have a tougher
> time with the lack of destructors. My basic line on this will be:
>
> 1-reclamation of memory is handled automatically by the GC
> 2-reclamation of other system resources is problematic in a GC'd
> language and best handled with other methods
The Lisp idiom for automatic resource cleanup is using a
with-<something> macro, e.g.
(with-open-file (s file-name)
(do-something-with-file))
guarantees that file will be closed when form evaluation terminates
(either normally or abnormally). Similar macros can be written for
other entities; generic with-new-instance macro can be written to get
behaviour of C++ automatic objects (given that some convention for
destructors is used, like destroy generic function).
--
With regards, Roman.
Standard disclaimer: I work for them, but I don't speak for them.
Geoffrey Summerhayes wrote:
>
> "Steven E. Harris" <········@raytheon.com> wrote in message
> ····················@raytheon.com...
> > ·······@mindspring.com (Rayiner Hashem) writes:
> >
> > > I think the reasoning is that in Lisp/CLOS encapsulation is
> > > orthogonal to the class mechanism. If you want to prevent a client
> > > from changing a class's internal members, put it in a seperate
> > > package and don't export the setter methods for that member.
> >
> > Ah, I had not thought of that. At the time I was reading the
> > aforementioned Norvig book, I didn't understand CL packages, but
> > thinking about it today I can see your point.
> >
> > > You can get the equivilent of a C++ class with public interfaces and
> > > private members by making a seperate package for the class, and only
> > > exporting the public functions.
> >
> > Unfortunately, I haven't seen this advice elsewhere. A person coming
> > from a background in C++ or Java would want to hear advice like this
> > for reassurance that access control can be layered over CLOS, whether
> > or not it's idiomatic to do so.
one can implement access control both "layered over" and independent of clos.
where an access protocol is implemented in terms of package operations and
names, it would be more accurate to describe it as "under clos" than "layered
over". it is also possible to implement access controls "on top of clos",
which would mean in terms of the dynamic behaviour of methods, and objects,
but that would be in addition to and/or independent of a protocol implemented
in terms of names.
>
> I think this will be a fairly easy sell, but I'm going to have a tougher
> time with the lack of destructors. My basic line on this will be:
>
> 1-reclamation of memory is handled automatically by the GC
> 2-reclamation of other system resources is problematic in a GC'd
> language and best handled with other methods
much of the ontology of data in lisp can be understood in terms of the
different kinds of "reference" [1] for which the language provides immediate
constructs and in terms of the life-cycles which can be implemented by various
combinations of unwind-protect and resourced data[2]. examples of the latter include
- with-open-file, whereby unwind-protect is used to ensure that the extent of
the resource corresponds to the extent of the reference. no finalization required;
- the management of of data as mediated by a gui
-- eg, mcl's window class hierarchy, whereby the instance's life cycle is
structured such that the requisite stages of os resource management correspond
to state transitions. no finalization required;
-- eg, mcl's toolbox interface, which mediates access to things like os
polygon representations through a combination of window-relative resourcing
when things succeed, and dynamic-extent enforcement when they don't. no
finalization required.
- process/task specific resourced data[2] in data prccessing applications -
http servers[3], database interfaces, parsers - where pooled data is
apportioned to a task and returned upon its completion. again no finalization required.
...
[1] http://oopweb.com/LISP/Documents/cltl/Volume/clm/node43.html#SECTION00700000000000000000
[2] http://www-2.cs.cmu.edu/afs/cs/project/ai-repository/ai//areas/kr/systems/rhet/cl_lib/
(the file resource.lisp)
[3] http://cl-http.ai.mit.edu
james anderson <··············@setf.de> writes:
> one can implement access control both "layered over" and independent
> of clos. where an access protocol is implemented in terms of
> package operations and names, it would be more accurate to describe
> it as "under clos" than "layered over".
That's really what I meant. I only used "over" to mean layered in time
of presentation. People looking for features from the C++ or Java
class system will ask about facilities seemingly absent from the
Common Lisp system.
First you teach them about CLOS, then about how the "absent" methods
are out in generic functions, and then about how the "absent" access
control is taken care of through the package system. They may not care
about access control until they realize that the methods are not
wrapped up in the class. At least, that's the order in which I started
bickering with CLOS.
--
Steven E. Harris :: ········@raytheon.com
Raytheon :: http://www.raytheon.com
In article <···············@raytheon.com>, Steven E. Harris wrote:
> Matthias <··@spam.pls> writes:
>> If this happens, Scott Meyer's discussion how non-member functions
>> increase encapsulation might be handy:
>
> But Scott Meyers is not advocating making all class member variables
> public or exposing them all to arbitrary mutation as CLOS does.
>
> Most of my experience with classes comes from C++, and I still find
> the CLOS exposure unsettling. I think Peter Norvig has a few
> paragraphs in PAIP about how CLOS more or less punts on data
> encapsulation. (Is it his bank account example, where there's no way
> to prevent a user from arbitrarily changing the balance not
> respecting the proper deposit or withdraw functions?)
>
> He points out that one can't restrict the :reader or mutable half of
> an :accessor to access within a set of methods, so data is either
> immutable (public const static or member variables or const member
> functions in C++) or freely mutable (public static or member
> variables in C++). What's missing is an analog to private member
> variables in C++ and the accessibility relationship they share with
> member functions.
I've wondered about this, too.
I guess you could write a macro that throws a LET around the defclass
for private :allocation :class variables, and then processes the slot
definition code to define reader and writer generic functions, and
maybe something similar for MAKE-INSTANCE for private member
variables:
(defclass-with-privates foo ()
((n :initform (bar)
:allocation-type :static ; class allocation, but private
:reader foo-n :writer set-n)
(j :initform (baz)
:allocation-type :private ; instance allocation, but private
:reader (foo-j (1- j)) ; guarantee some arbitrary perturbation
; of j when read
:writer (set-j val (1+ val)))))
; guarantee some arbitrary perturbation
; of j when written
=>
(let ((n (bar)))
(defclass foo () ())
(defmethod foo-n ((this foo))
n)
(defmethod set-n (val (this foo))
(setf n val))
(defmethod make-instance :around ((class (eql 'foo)) &key &allow-other-keys)
(let ((j (baz))
(instance (call-next-method)))
(defmethod foo-j ((this (eql instance)))
(1- j))
(defmethod set-j (val (this (eql instance)))
(setf j (1+ val)))
instance)))
... but this wouldn't work with derived classes, and probably has
other flaws. I haven't read AMOP, but I bet someone that has could
get this working a lot easier.
Any comments from the experts on how you'd do this correctly? ("Read
AMOP"? :)
-- Larry
Patrick May wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>>Geoffrey Summerhayes wrote:
>>
>>>Aside from multiple dispatch, any ideas of quick code to show off
>>>CLOS and Lisp to a heathen flock that is trained in Java? (not to
>>>mention being taught that Lisp is simply a functional language)
>>
>>I like the decoupling of Gfs from class definitions, and that a
>>dispatch ing argument can be just a number (and a method specialized
>>on that) or a whole frickin CLOS instance that gets all complicated
>>over the behavior based on what the CLOS instance has to say.
>
>
> In my limited experience trying to get Java and C++ programmers
> to consider the benefits of Lisp, this is a hard sell. The idea that
> methods are owned by a class is deeply ingrained in those language
> cultures. It's very easy to go off into an argument about
> encapsulation that ultimately distracts the audience completely from
> the core message.
(1) I would deflate any such resistance by pointing out that the idea is
simply to describe objectively the CLOS/C++ diffs/similarities. Knock
down any comment like that with, oh, that's undecidable flame war stuff,
let's just look for objective differences, y'all can decide for
yourselves which you prefer once you have the facts.
(2) Then you can point out that OO is widely agreed to have failed
miserably at delivering on it's raison d'etre, viz. object re-use. It's
still cool for maintenance and its ability to structure an application
source in clean ways (smae thing, I guess) but re-use? Fuggedabout it.
Why? Because of the idea of giving objects "behavior". Ha! That's code!
And that means to get different "behavior" you need a new
subclass--kablam! asta la vista re-use. A class owning its methods means
a class behavior is hard-coded.
So embarrass them into not evangelizing, then sell! sell! cell!
Is there any way to drag the horrors of templates into this
presentation, or is that unrelated?
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
> (2) Then you can point out that OO is widely agreed to have failed
> miserably at delivering on it's raison d'etre, viz. object re-use.
> It's still cool for maintenance and its ability to structure an
> application source in clean ways (smae thing, I guess) but re-use?
> Fuggedabout it. Why? Because of the idea of giving objects "behavior".
> Ha! That's code! And that means to get different "behavior" you need a
> new subclass--kablam! asta la vista re-use. A class owning its methods
> means a class behavior is hard-coded.
Hmmm. I think the Java programmers are going to disagree that OO has
"failed miserably at delivering on ... re-use". They use 3rd-party
Java libraries *all the time*. Most Java programmers probably do
nothing but stitch together existing libraries and frameworks. I think
C++ failed miserably but that was an implementation issue. Java, with
its interfaces, package system, and runtime linking actually made
object re-use work.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel <·····@javamonkey.com> writes:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> > (2) Then you can point out that OO is widely agreed to have failed
> > miserably at delivering on it's raison d'etre, viz. object re-use.
> > It's still cool for maintenance and its ability to structure an
> > application source in clean ways (smae thing, I guess) but re-use?
> > Fuggedabout it. Why? Because of the idea of giving objects "behavior".
> > Ha! That's code! And that means to get different "behavior" you need a
> > new subclass--kablam! asta la vista re-use. A class owning its methods
> > means a class behavior is hard-coded.
>
> Hmmm. I think the Java programmers are going to disagree that OO has
> "failed miserably at delivering on ... re-use". They use 3rd-party
> Java libraries *all the time*. Most Java programmers probably do
> nothing but stitch together existing libraries and frameworks. I think
> C++ failed miserably but that was an implementation issue. Java, with
> its interfaces, package system, and runtime linking actually made
> object re-use work.
But when Java programmers say "object reuse," they're just talking
about good old-fashioned libraries. Not the revolutionary reuse that
was hyped by the OOP boosters in the early 90's.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@fallingrocks.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Peter Seibel <·····@javamonkey.com> writes:
>
> > Kenny Tilton <·······@nyc.rr.com> writes:
> >
> > > (2) Then you can point out that OO is widely agreed to have failed
> > > miserably at delivering on it's raison d'etre, viz. object re-use.
> > > It's still cool for maintenance and its ability to structure an
> > > application source in clean ways (smae thing, I guess) but re-use?
> > > Fuggedabout it. Why? Because of the idea of giving objects "behavior".
> > > Ha! That's code! And that means to get different "behavior" you need a
> > > new subclass--kablam! asta la vista re-use. A class owning its methods
> > > means a class behavior is hard-coded.
> >
> > Hmmm. I think the Java programmers are going to disagree that OO has
> > "failed miserably at delivering on ... re-use". They use 3rd-party
> > Java libraries *all the time*. Most Java programmers probably do
> > nothing but stitch together existing libraries and frameworks. I think
> > C++ failed miserably but that was an implementation issue. Java, with
> > its interfaces, package system, and runtime linking actually made
> > object re-use work.
>
> But when Java programmers say "object reuse," they're just talking
> about good old-fashioned libraries. Not the revolutionary reuse that
> was hyped by the OOP boosters in the early 90's.
Not really. Anyone who's ever written a servlet has created a subclass
of javax.servlet.Servlet (or whatever it is) which allows their code
to fit into the framework provided by the app server. That's more than
just library use, in my mind.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel wrote:
> ···@fallingrocks.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
>
>>Peter Seibel <·····@javamonkey.com> writes:
>>
>>
>>>Kenny Tilton <·······@nyc.rr.com> writes:
>>>
>>>
>>>>(2) Then you can point out that OO is widely agreed to have failed
>>>>miserably at delivering on it's raison d'etre, viz. object re-use.
>>>>It's still cool for maintenance and its ability to structure an
>>>>application source in clean ways (smae thing, I guess) but re-use?
>>>>Fuggedabout it. Why? Because of the idea of giving objects "behavior".
>>>>Ha! That's code! And that means to get different "behavior" you need a
>>>>new subclass--kablam! asta la vista re-use. A class owning its methods
>>>>means a class behavior is hard-coded.
>>>
>>>Hmmm. I think the Java programmers are going to disagree that OO has
>>>"failed miserably at delivering on ... re-use". They use 3rd-party
>>>Java libraries *all the time*. Most Java programmers probably do
>>>nothing but stitch together existing libraries and frameworks. I think
>>>C++ failed miserably but that was an implementation issue. Java, with
>>>its interfaces, package system, and runtime linking actually made
>>>object re-use work.
>>
>>But when Java programmers say "object reuse," they're just talking
>>about good old-fashioned libraries. Not the revolutionary reuse that
>>was hyped by the OOP boosters in the early 90's.
>
>
> Not really. Anyone who's ever written a servlet has created a subclass
> of javax.servlet.Servlet (or whatever it is) which allows their code
> to fit into the framework provided by the app server. That's more than
> just library use, in my mind.
No, that is just library use. Let me know when they have a Servlet class
that works with any app server. That is the re-use once dreamed of, that
we would all be using the same Servlet class, albeit thru some
reasonably small number of levels of inheritance.
The problem is that when classes include the application code (behavior,
schmehavior!) the only paramterization is thru literal values supplied
for parametric slots, such as a 'justification' slot which supports
VC_JUSTIFY_LEFT, VC_JUSTIFY_RIGHT, etc. And those have to match the
values expected by the application code of the class. Unfortunately, no
one has found the universal application code (and if they did it could
just as well be a library, but i digress). So the only way to get the
behavior you want is to subclass and subclass again. No re-use.
Now of course I can /use/ Servlet because there is a real good chance it
does exactly what I want: make the AppServer class happy.
Btw, don't get me wrong. The value of Servlet to people who need to make
servlets for /that/ AppServer is tremendous. But that is about toeing
the line, not being able to use the class in places its author never
imagined. That is the re-use OO failed at.
Until Cells. :)
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
> Peter Seibel wrote:
> > ···@fallingrocks.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> >
> >>Peter Seibel <·····@javamonkey.com> writes:
> >>
> >>
> >>>Kenny Tilton <·······@nyc.rr.com> writes:
> >>>
> >>>
> >>>>(2) Then you can point out that OO is widely agreed to have failed
> >>>>miserably at delivering on it's raison d'etre, viz. object re-use.
> >>>>It's still cool for maintenance and its ability to structure an
> >>>>application source in clean ways (smae thing, I guess) but re-use?
> >>>>Fuggedabout it. Why? Because of the idea of giving objects "behavior".
> >>>>Ha! That's code! And that means to get different "behavior" you need a
> >>>>new subclass--kablam! asta la vista re-use. A class owning its methods
> >>>>means a class behavior is hard-coded.
> >>>
> >>>Hmmm. I think the Java programmers are going to disagree that OO has
> >>>"failed miserably at delivering on ... re-use". They use 3rd-party
> >>>Java libraries *all the time*. Most Java programmers probably do
> >>>nothing but stitch together existing libraries and frameworks. I think
> >>>C++ failed miserably but that was an implementation issue. Java, with
> >>>its interfaces, package system, and runtime linking actually made
> >>>object re-use work.
> >>
> >>But when Java programmers say "object reuse," they're just talking
> >>about good old-fashioned libraries. Not the revolutionary reuse that
> >>was hyped by the OOP boosters in the early 90's.
> > Not really. Anyone who's ever written a servlet has created a
> > subclass
> > of javax.servlet.Servlet (or whatever it is) which allows their code
> > to fit into the framework provided by the app server. That's more than
> > just library use, in my mind.
>
> No, that is just library use. Let me know when they have a Servlet
> class that works with any app server. That is the re-use once
> dreamed of, that we would all be using the same Servlet class,
> albeit thru some reasonably small number of levels of inheritance.
Huh. Most app servers that support the Servlet API do so correctly as
far as I know. That's *the point*. I *can* take my servlet and deploy
it in any compliant app server. I'm not saying that's a huge miracle.
But it works.
> The problem is that when classes include the application code
> (behavior, schmehavior!) the only paramterization is thru literal
> values supplied for parametric slots, such as a 'justification' slot
> which supports VC_JUSTIFY_LEFT, VC_JUSTIFY_RIGHT, etc. And those
> have to match the values expected by the application code of the
> class. Unfortunately, no one has found the universal application
> code (and if they did it could just as well be a library, but i
> digress). So the only way to get the behavior you want is to
> subclass and subclass again. No re-use.
Uh, what? I'm not sure what you think you were promised--one class
that would do everything you ever wanted, no programming required?
> Now of course I can /use/ Servlet because there is a real good chance
> it does exactly what I want: make the AppServer class happy.
And, when you *use* the Servlet code that was already written and
*used* by me, aren't you also *reusing* it?
> Btw, don't get me wrong. The value of Servlet to people who need to
> make servlets for /that/ AppServer is tremendous. But that is about
> toeing the line, not being able to use the class in places its
> author never imagined. That is the re-use OO failed at.
Hmmm. Maybe I missed the hype memo, but I never understand reuse to
mean that any class could be used in any abritrary way totally
unrelated to it's intended purpose and just work.
The promise, as I understand it, was that I could write a class (or
set of classes) and publish and API and other people could take those
classes and write code that uses that API and *that* would work. A
particular test of whether something is reusable is whether I can
reuse thing A while also reusing thing B that was developed
independently.
This happens all the time in Java, e.g. using an XML parsing library
from Apache with networking libraries provided by some company along
with GUI widgets that are part of the JDK. I understand it happens
less often in C++ because the mechanics of making C++ code
interoperate are too tricky (and because there aren't standard ways of
representing ubiquitous things like strings). You could also argue
that tons of C++ code is reused in the form of COM components.
> Until Cells. :)
Based on the little I know about Cells it seems that the same effect
could be achieved (albeit with endless amounts of pain and drudgery)
by building Java objects that fire and recieve events pretty much
whenever anything happens to them. Thus objects would thereby provide
a much more "hookable" API than your average Java object and so could
be reused in more situations than say, Servlet. But that's just a
question of providing an API that does a lot of things in a general
way compared to a small number of things in specific. That Lisp makes
it so easy for you to write code that makes it so easy for me to write
code that provides such APIs is indeed a testament to Lisp's power but
I'd be interested to see a concrete example of how it supports reuse
in ways that couldn't be achieved in Java. (Remember I'm a Lisp fan--I
*know* it's a billion times *better* and less painful to do it in
Lisp; I'm just saying that I'd be surprised to see a completely new
kind of reuse.[1])
-Peter
[1] Well, since Lisp can provide a kind of abstractions unavailable in
Java, namely macros, it is the case that there's another axis for
possible reuse--I can provide a reusable set of syntactic macros. No
equivalent for that in Java short of distributing a preprocessor. And
that would fall apart on the reuse front because there'd likely be no
way to combine two independently developed preprocessors.
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
( Aarg, this thread got active while I was gone. I'll just pick this
post to pick on, and quote random chunks. My response is really to
the discussion so far. )
Peter Seibel <·····@javamonkey.com> writes:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> > No, that is just library use.
Peter, every counterexample you've come up with falls under this.
Don't get me wrong, OOP (with an appropriately large standard library)
*does* make library use easier. But this isn't what we were promised,
this is just what we had before, but a little better. And in the case
of Java, where classes are gigantic, I think it's mostly due to the
fact that the language provides enough of a common library, and a
standard system construction and distribution framework. The amount
of sharing by Java users versus their peers is impressive, but.
> Uh, what? I'm not sure what you think you were promised--one class
> that would do everything you ever wanted, no programming required?
[ silly aside: ]
Now *that*'s a Java mindset! The marketing-department-written copy told
use we'd get one heirarchy of very small classes: you'd just find the
one you wanted, subclass, and you're done.
[ Obviously, no one reasonable belived this ]
> Hmmm. Maybe I missed the hype memo,
Memo!!! I've moved a dozen times in the last decade, so I don't have
any copies of the old hype, but someone should dig some of it up for
Peter, I think he spent too much time using an OOP language for
engineers (eg, I'm sure that Java folk use the old OOP-hype words with
newer, more useful meanings). Back in the days of "use Smalltalk!
Refactor! Objects are Alive!", they said you would work on developing
your application; you'd do this by writing new methods, subclassing,
etc. When you were done, you'd extended the language (remember, this
is Smalltalk). The next app you wrote would use a fair amount of the
code from the last app, *without* *effort*. Not, "you can factor out
a FOO class library more easily, because in writing the unfactored
version, you already did some of the work of making it a library".
The idea was that this new methodology would make reusing code
effortless: your new methods (on old classes) and new classes are
still in the image, all you have to do is use them.
OOP, as hyped in the early 90's was a great big failure. It turns out
that it had plenty of other benefits, which explains all the happy
Smalltalkers.
(Somebody should dig up some of the old hype and bring it to the next
BA Lispniks meeting)
> (Remember I'm a Lisp fan--I
> *know* it's a billion times *better* and less painful to do it in
> Lisp; I'm just saying that I'd be surprised to see a completely new
> kind of reuse.[1])
Yeah, I was pretty excited about it, personally. Older, wiser, more
cynical now :-)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> ( Aarg, this thread got active while I was gone. I'll just pick this
> post to pick on, and quote random chunks. My response is really to
> the discussion so far. )
>
> Peter Seibel <·····@javamonkey.com> writes:
>
> > Kenny Tilton <·······@nyc.rr.com> writes:
> >
> > > No, that is just library use.
>
> Peter, every counterexample you've come up with falls under this.
> Don't get me wrong, OOP (with an appropriately large standard library)
> *does* make library use easier. But this isn't what we were promised,
> this is just what we had before, but a little better. And in the case
> of Java, where classes are gigantic, I think it's mostly due to the
> fact that the language provides enough of a common library, and a
> standard system construction and distribution framework. The amount
> of sharing by Java users versus their peers is impressive, but.
So can you give me an idea what kind of reuse was promised and that
you're still waiting for? Or that is delivered by other styles of
languages?
If all you're saying is, "We were promised things by the OO
hypemeisters that have never been delivered and probably never will be
because they are impossible" then you'll get no argument from me.I'm
also quite willing to agree that the specific use of inheritance was
(and continues to be) oversold, even by engineers.
But I'd also expect that us Lispniks would realize the dangers of
dismissing technology simply because it didn't live up to the hype
dished out by its most zealous partisans when they thought they were
hot on the trail of a big pile of bucks. Since the original context
was tips for someone who's going to be presenting CLOS to C++/Java
programmers, I stand by my claim that if you tell Java programmers
(and especially anyone who went from C++ *to* Java) that OO has
completely failed to deliver on its promise of code reuse, they'll
assume you're just another bitter Lispnik, because they *do* reuse
code. (Look at it this way, if you're getting this much flak from me
and I'm already *deeply invested* in Lisp, imagine how this argument
is going to go with someone who's just looking for an excuse to
dismiss Lisp. Of course maybe you can never win those people over. But
it's worth a shot.)
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel <·····@javamonkey.com> writes:
> ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > ( Aarg, this thread got active while I was gone. I'll just pick this
> > post to pick on, and quote random chunks. My response is really to
> > the discussion so far. )
> >
> > Peter Seibel <·····@javamonkey.com> writes:
> >
> > > Kenny Tilton <·······@nyc.rr.com> writes:
> > >
> > > > No, that is just library use.
> >
> > Peter, every counterexample you've come up with falls under this.
> > Don't get me wrong, OOP (with an appropriately large standard library)
> > *does* make library use easier. But this isn't what we were promised,
> > this is just what we had before, but a little better. And in the case
> > of Java, where classes are gigantic, I think it's mostly due to the
> > fact that the language provides enough of a common library, and a
> > standard system construction and distribution framework. The amount
> > of sharing by Java users versus their peers is impressive, but.
>
> So can you give me an idea what kind of reuse was promised and that
> you're still waiting for? Or that is delivered by other styles of
> languages?
>
> If all you're saying is, "We were promised things by the OO
> hypemeisters that have never been delivered and probably never will be
> because they are impossible" then you'll get no argument from me. I'm
> also quite willing to agree that the specific use of inheritance was
> (and continues to be) oversold, even by engineers.
I'm sure the greatest promises were based on reality. Having now used
it, at its best, Smalltalk is really impressive. The combination of
OO, a dynamic language/environment, and image-based development, can
really be amazing. The best "I wrote it, and it's still here, and I
can effortlessly adapt it to the task at hand" hype comes true
occasionally. But mostly, I think it's impossible. That's all kind
of mixed up with the continuing overhype of inheritance, though.
I *am* still waiting on a higher level of resuse. I don't have it yet
with Lisp, but I've glimpsed it. I have the dynamicity, I have
arbitrary program transformations (macros, Lisp's best feature :), and
I have CLOS, the best production quality object system I've come
across. I kind of have constraints+prototypes, in the form of KR, and
I kind of have them in the form of Cells. The former are painful to
combine with CLOS, and almost no one uses them; the latter are just
barely coming into public availability[*] (and prototypes depend on my
personal hack, which I should review and release). I *don't* have
image-based development, not like Smalltalk, not even close. I don't
have the concept of modules or development worlds to go along with
image-based development. I have this suspicion that if/when I get all
of these together, I'll get the crazy-productive promises from the
early OOP hype, to a reasonable extent at least.
[*] And they're definately not a Knowledge Representation system.
This might actually be a good thing, though, ask me again in a year.
> But I'd also expect that us Lispniks would realize the dangers of
> dismissing technology simply because it didn't live up to the hype
> dished out by its most zealous partisans when they thought they were
> hot on the trail of a big pile of bucks. Since the original context
> was tips for someone who's going to be presenting CLOS to C++/Java
> programmers, I stand by my claim that if you tell Java programmers
> (and especially anyone who went from C++ *to* Java) that OO has
> completely failed to deliver on its promise of code reuse, they'll
> assume you're just another bitter Lispnik, because they *do* reuse
> code. (Look at it this way, if you're getting this much flak from me
> and I'm already *deeply invested* in Lisp, imagine how this argument
> is going to go with someone who's just looking for an excuse to
> dismiss Lisp. Of course maybe you can never win those people over. But
> it's worth a shot.)
Oh yeah, the Subject line, that. Forgot about that. Uh, yeah,
probably a bad idea to bring up the whole "OOP failed" thing in that
context .. I mean, if that can turn the discussion into something
resembling Peter-verus-Lisp, I can only imagine what would happen with
a room full of Java advocates :-)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Thomas F. Burdick writes:
> personal hack, which I should review and release). I *don't* have
> image-based development, not like Smalltalk, not even close. I don't
Could you elaborate on what you mean by "image-based development"? I
probably confuse this with the concept of Lisp images/worlds.
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Paolo Amoroso <·······@mclink.it> writes:
> Thomas F. Burdick writes:
>
> > personal hack, which I should review and release). I *don't* have
> > image-based development, not like Smalltalk, not even close. I don't
>
> Could you elaborate on what you mean by "image-based development"? I
> probably confuse this with the concept of Lisp images/worlds.
We do have images, but our development tends to be file-based. The
traditional way of working in Smalltalk is to start up your image,
then start editing. Not files, but the image itself. In addition to
the class heirarchy, classes and methods can be grouped into
categories. So, you make a new category for your application. You
pull up the class browser, and start making changes; you make some new
classes, you add some methods to existing classes. You test things
out in a toplevel window, and you define things there too. You bring
your application into being. When you're done for the day, you save
the image, and pull it up tomorrow in the same state. When you're
ready to share your app, you tell the system to dump out the
change-set associated with your application's category; that's a file
(or files) that contains everything needed to recreate whatever's in
your application. That's the only time you touch a file, and even
then you get to use a 10-foot pole :-)
If you're curious, check out Squeak, and walk through a tutorial.
Learning a little ST is really easy, and Squeak is optimized for easy
usability over everything else.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Thomas F. Burdick writes:
> We do have images, but our development tends to be file-based. The
> traditional way of working in Smalltalk is to start up your image,
> then start editing. Not files, but the image itself. In addition to
[...]
> your application into being. When you're done for the day, you save
> the image, and pull it up tomorrow in the same state. When you're
[...]
> If you're curious, check out Squeak, and walk through a tutorial.
Yes, I do have some Squeak experience, but I had almost forgotten the
Smalltalk way. Thanks for the reminder,
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Thomas F. Burdick wrote:
> [*] [Cells are} definately not a Knowledge Representation system.
Could be a fun exercise, tho, in the spirit of "OO in fifty lines of
code". Certainly the forward chaining thing is a done deal.
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> I *don't* have image-based development, not like Smalltalk, not even
> close. I don't have the concept of modules or development worlds to
> go along with image-based development.
would you mind explaining, in Smalltalk-ignoramus-friendly terms,
what do you mean when you say "image-based development"?
thanks,
--m
--
A CONS is an object which cares.
-- Bernie Greenberg.
From: Basile STARYNKEVITCH
Subject: Re: image-based development (was: Re: CLOS and C++)
Date:
Message-ID: <q5rfzggk10b.fsf@hector.lesours>
>>>>> "Michael" == Michael Livshin <······@cmm.kakpryg.net> writes:
Michael> ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
Thomas>> I *don't* have image-based development, not like
Thomas>> Smalltalk, not even close. I don't have the concept of
Thomas>> modules or development worlds to go along with
Thomas>> image-based development.
Michael> would you mind explaining, in Smalltalk-ignoramus-
Michael> friendly terms, what do you mean when you say
Michael> "image-based development"?
Maybe for the OP (Thomas) the image-based development means that, as
some Smalltalk (eg Squeak, but also old Smalltalk machines...) or old
Lisp (eg Lisp machines) or SML/NJ (thru its export primitive...) the
whole process state is persisted (ie saved) to disk storage, and can
be restarted.
I do agree that persistence of the whole process is not very
convenient w.r.t. modularity, but I still believe it is not fully
incompatible with it.
However, I don't have practical experient of image-based
development. In addition, it probably has changed (in practical terms)
since its glorious period (1980s language based machines) because
today huge disks can contain dozens (or hundreds) of full process
images. This probably was not true for original Lisp machines, where
the (virtual) storage size of the whole machine was a big fraction of
the typical disk space.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net
aliases: basile<at>tunes<dot>org = bstarynk<at>nerim<dot>net
8, rue de la Fa�encerie, 92340 Bourg La Reine, France
Peter Seibel wrote:
> If all you're saying is, "We were promised things by the OO
> hypemeisters that have never been delivered and probably never will be
> because they are impossible"
Oh, good, now we can return to the original point: marrying code to
classes made reuse impossible. It is not that reuse is impossible, it
was asking too much of classes.
With Cells a class still defines structure, slots are either ephemeral
or they are not, classes can supply useful defaults for slots, and the
echo of a slot is determined by the class, not the Cell, but that is
all. Tremendous flexibility is available in re deriving slot values, and
of course GFs give the class user a lot of flexibility in how classes
are put to use.
That means there is a much greater chance that a given class that offers
some of what I need can be subclassed to do exactly what I need.
That is not what happens in the real world.
Your examples are about classes being used as they were intended.
Surprise, surprise. My guess is that what happened is that everyone
started running around saying "reuse" the way some people yell "AI" when
there is nothing of the sort going on, just because the word has become
a plaything for ad men. You are right, the lecture audience may have
fallen for that as have you. But it's no good appeasing adspeak, not in
a programming language class.
But me, I have this huge app over here and after about a third of the
way through, without intending it, I simply stopped defining new
classes. I could get new requirement after new requirement out of my
existing class hierarchy. Hellasweet. No bugs, either, because the same
code is getting used all the time.
Those who remember what "reuse" means talk about a need for formal
methods and advanced mathematical modelling to come up with classes with
the abstractions necessary to make classes reusable for unanticipated
requirements. They talk that way because the classes they are thinking
about are cast in cement, bound forever to the code. Me, I got reuse in
part from GFs, in part from putting a lot of semantics in Cell rules,
which can vary from instance to instance of the same class.
Getting back to the talk, this is the answer to anyone upset by GFs
habit of decoupling code from class.
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> wrote in message news:<························@twister.nyc.rr.com>...
> Oh, good, now we can return to the original point: marrying code to
> classes made reuse impossible. It is not that reuse is impossible, it
> was asking too much of classes.
I recall hearing the point of view that it's not the objects that are
particularly reusable, but instead the code that uses them. When you
write code that takes advantage of something having a protocol, you
have the chance of writing interfaces for other objects to follow that
protocol.
So protocols make outside code more reusable.
Of course, OOP in most languages conflate syntactic and data
abstraction, so you see a lot of weird code that really "shouldn't" be
objects, but a way to get around syntax. Maybe that's a possible
example for the original poster: If there's a C++ idiom that only
uses OOP for syntactic abstraction, the CLOS counterpart is...
nonexistent. ;)
>
> Based on the little I know about Cells it seems that the same effect
> could be achieved (albeit with endless amounts of pain and drudgery)
> by building Java objects that fire and recieve events pretty much
> whenever anything happens to them.
Well, that'd be JavaBeans. That's what the JavaBean PropertyChangeEvents are
for. Since the JavaBeans component* pattern is standard in java, all the
big Java IDEs I know can set it up automatically, so the pain and drudgery
isn't all that huge- but the underlying code is of course icky (though not
as horrible as the butchery of C++ that is MSVC++ "wizard" generated code
or anything, just boring ordinary Java code, usually with lots of inner
classes for EventListeners.)
Cells is much more declarative, and thus "wins", I'd say (not having
reviewed it in detail or anything or tried to use it, my only perhaps
useful impression was that the symbols could do with being more verbose and
less cryptic to fit in with typical CL readability...)
* The bulk of "Component based programming" seems to be just making up for
where C++/Java's crippled-static-"OO" isn't really like what I originally
understood OO to mean, but hey...
David Golden wrote:
>>Based on the little I know about Cells it seems that the same effect
>>could be achieved (albeit with endless amounts of pain and drudgery)
>>by building Java objects that fire and recieve events pretty much
>>whenever anything happens to them.
>
>
> Well, that'd be JavaBeans. That's what the JavaBean PropertyChangeEvents are
> for. Since the JavaBeans component* pattern is standard in java, all the
> big Java IDEs I know can set it up automatically, so the pain and drudgery
> isn't all that huge- but the underlying code is of course icky (though not
> as horrible as the butchery of C++ that is MSVC++ "wizard" generated code
> or anything, just boring ordinary Java code, usually with lots of inner
> classes for EventListeners.)
Sure. When I talk about prior art for Cells I include not just other
explicit constraint mechanisms but also other hacks which make change
manageable. Smalltalk had some classes which I faintly recall doing
something useful along the lines of the GoF observer pattern, and I am
reminded of that by the PropertyChangeEvents name.
>
> Cells is much more declarative, and thus "wins", I'd say (not having
> reviewed it in detail or anything or tried to use it,...
Well, certainly the Cells user never writes any explicit "subscribe"
code or "notify" code or unsubscribe. That all gets done behind the
scenes when one cell reads another while computing/recomputing its
value. I don't think one gets the order of magnitude productivity boost
without automating dependency management and state propagation. Probably
helps a /lot/ though.
my only perhaps
> useful impression was that the symbols could do with being more verbose and
> less cryptic to fit in with typical CL readability...)
I must have been an APLnik in an earlier life. But there are only two
short ones, C? and CV, and the Cells reference manual I am (listlessly)
working on gives away the make-c-ruled and make-c-variable behind them.
(Probably never thought to export those, tho.)
Actually, there is not much syntax to talk about, so I am throwing in
all sorts of "the idea here is that..." stuff which crosses over into
implementation -- but I think it is stuff I would want to read as a new
user.
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Peter Seibel wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>Peter Seibel wrote:
>>
>>> Not really. Anyone who's ever written a servlet has created a
>>>subclass
>>>of javax.servlet.Servlet (or whatever it is) which allows their code
>>>to fit into the framework provided by the app server. That's more than
>>>just library use, in my mind.
>>
>>No, that is just library use. Let me know when they have a Servlet
>>class that works with any app server. That is the re-use once
>>dreamed of, that we would all be using the same Servlet class,
>>albeit thru some reasonably small number of levels of inheritance.
>
>
> Huh. Most app servers that support the Servlet API do so correctly as
> far as I know. That's *the point*. I *can* take my servlet and deploy
> it in any compliant app server.
<g> This is going to be tougher than I thought. "...that support the
Servlet API" and "any /compliant/" [emphasis added]... there is zero
generality here! Let me know when Servlet works with /every/ app server.
(Btw, if "app server" is somehow a reserved word for "Java Servlet
API", I have to find a better example.)
I'm not saying that's a huge miracle.
> But it works.
Damn well better. It's just one particular
>
>
>
> Uh, what? I'm not sure what you think you were promised--one class
> that would do everything you ever wanted, no programming required?
>
> Hmmm. Maybe I missed the hype memo,
You did. This was back when Smalltalk was the only OO game in town. The
idea was that libraries of classes would be developed that would keep
programmers from forever reinventing the same wheel over and over again.
There was going to be the ultimate DebitAccount class and the ultimate
LegalRuling class and the ultimate LabInstrument class... the Silver Bullet!
but I never understand reuse to
> mean that any class could be used in any abritrary way totally
> unrelated to it's intended purpose and just work.
Unrelated? Sorry, "in ways never imagined" was too strong. Look, this is
how it was supposed to work, according to the memo you missed: the
hardware crew I work with just invented a new lab instrument, our
company's first, so I download the National Bureau of Standards
LabInstrument class and subclass it and add a slot here and override a
method there and viola!, done before lunch, with all sorts of great
functionality already built in. We can hook up the Acme plotter and the
Justin Timer via serial ports, and it all Just Works, because they use
the NBS Plotter and Timer classes.
I think your astonishment at the idea of such a thing is a fair measure
of how badly OO failed at that. Now you are (rightly) ecstatic that OO
provides a clean way of delivering to you a template of the code needed
to create something that works with some other code instance (the Java
AppServer class or whatever it is that Java Servlet APIs deal with).
OO was supposed to change programming so we'd never have to write a
LabInstrument class or Timer class again, we would just re-use the
standard classes. Now even within an organization (never mind the NBS)
there is no sign of reuse.
>
> The promise, as I understand it, was that I could write a class (or
> set of classes) and publish and API and other people could take those
> classes and write code that uses that API and *that* would work. A
> particular test of whether something is reusable is whether I can
> reuse thing A while also reusing thing B that was developed
> independently.
You missed the memo. :) The prefix "re" is there for a reason. The sense
you are using is coverd by "use".
> Based on the little I know about Cells it seems that the same effect
> could be achieved (albeit with endless amounts of pain and drudgery)
> by building Java objects that fire and recieve events pretty much
> whenever anything happens to them.
I include things like that when I discuss prior art to Cells, because
they too address the problem of reliably propagating change throughout a
complex web of interdependent, long-lived state. The differentiation
between Cells and such schemes is precisely the "endless amounts of pain
and drudgery". The idea is to improve programmer productivity, so
hand-wiring dependencies won't cut it -- well, if it's the only game in
town, I think it is still a good idea because the pain is linear with
functional growth, whereas the complexity resolved grows exponentially.
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
> Peter Seibel wrote:
>
> > Kenny Tilton <·······@nyc.rr.com> writes:
> >
> >>Peter Seibel wrote:
> >>
>
> >>> Not really. Anyone who's ever written a servlet has created a
> >>>subclass
> >>>of javax.servlet.Servlet (or whatever it is) which allows their code
> >>>to fit into the framework provided by the app server. That's more than
> >>>just library use, in my mind.
> >>
> >>No, that is just library use. Let me know when they have a Servlet
> >>class that works with any app server. That is the re-use once
> >>dreamed of, that we would all be using the same Servlet class,
> >>albeit thru some reasonably small number of levels of inheritance.
> > Huh. Most app servers that support the Servlet API do so correctly as
> > far as I know. That's *the point*. I *can* take my servlet and deploy
> > it in any compliant app server.
>
> <g> This is going to be tougher than I thought. "...that support the
> Servlet API" and "any /compliant/" [emphasis added]... there is zero
> generality here! Let me know when Servlet works with /every/ app
> server. (Btw, if "app server" is somehow a reserved word for "Java
> Servlet API", I have to find a better example.)
Yeah, in the Java world "app server" pretty much means "a server that
support the J2EE API's of which the servelet API is one." I should
probably say Java App Server. Or J2EE-complient app server. And if it
doesn't do it right then people won't use it.
> I'm not saying that's a huge miracle.
> > But it works.
>
> Damn well better. It's just one particular
Look, if I can write a Servlet and you can write a Servlet and then
someone can deploy them in *either* Tomcat or Weblogic or Websphere,
there's a bit of generality.
> > Uh, what? I'm not sure what you think you were promised--one class
> > that would do everything you ever wanted, no programming required?
> >
>
> > Hmmm. Maybe I missed the hype memo,
>
> You did. This was back when Smalltalk was the only OO game in town.
> The idea was that libraries of classes would be developed that would
> keep programmers from forever reinventing the same wheel over and
> over again. There was going to be the ultimate DebitAccount class
> and the ultimate LegalRuling class and the ultimate LabInstrument
> class... the Silver Bullet!
Well, there's a big difference between "failed to live up to all the
hype generated by the marketing department" (c.f. the AI Boom and
Bust) and "completely failed at a technical level". There are lots of
wheels (in Java anyway) that do *not* get reinvented. From simple
things like java.lang.String (which the C++ guys never mananged to
standardize) and java.util.HashMap to complex things like database
drivers and frameworks for running user code in an application server
(Servlets, EJBs, blah blah blah.)
While folks may not have been able to agree on the ultimate
LegalRuling and LabInstrument classes, that has more to do with
politics and organizational inertia--different organizations can't
agree on what the APIs should be and it's not up to the software guys.
Or they don't *want* to agree.[1] I can tell you this: no Java
programmer bothers writing their own string or hash table classes.
Again, these aren't rocket science, but those classes do get used
*and* reused again and again. Okay, that might be more like library
reuse. But see below.
> > but I never understand reuse to mean that any class could be used
> > in any abritrary way totally unrelated to it's intended purpose
> > and just work.
>
> Unrelated? Sorry, "in ways never imagined" was too strong. Look, this
> is how it was supposed to work, according to the memo you missed: the
> hardware crew I work with just invented a new lab instrument, our
> company's first, so I download the National Bureau of Standards
> LabInstrument class and subclass it and add a slot here and override a
> method there and viola!, done before lunch, with all sorts of great
> functionality already built in. We can hook up the Acme plotter and
> the Justin Timer via serial ports, and it all Just Works, because they
> use the NBS Plotter and Timer classes.
Well, I've never used it myself but there is a java.awt.printer
package that contains a set of interfaces and classes. Looks like many
Java APIs in that there are the classes that would be implemented to
support a particular printer and the classes that application
programers use to talk to the printer. By virtue of these class
definitions the code I write in my application to work with one
printer today will work with another printer tomorrow when I install
new classes that implement the appropriate interfaces. And if your
hardware guys just built a new plotter, it's fairly obvious what you
need to do to make that plotter usable by my code (without changing my
code).
> I think your astonishment at the idea of such a thing is a fair
> measure of how badly OO failed at that. Now you are (rightly) ecstatic
> that OO provides a clean way of delivering to you a template of the
> code needed to create something that works with some other code
> instance (the Java AppServer class or whatever it is that Java Servlet
> APIs deal with).
>
> OO was supposed to change programming so we'd never have to write a
> LabInstrument class or Timer class again, we would just re-use the
> standard classes. Now even within an organization (never mind the NBS)
> there is no sign of reuse.
No sign of reuse?! Gosh, all those classes in the JDK that I used in
every Java program I ever wrote. Or the JDBC drivers that I used to
talk to my RDBMS, most of which are provided by third parties. Or
crypto libraries where different encryption schemes can be plugged
into my app without changing my code because they all implement the
appropriate APIs and SPIs.
> > The promise, as I understand it, was that I could write a class
> > (or set of classes) and publish and API and other people could
> > take those classes and write code that uses that API and *that*
> > would work. A particular test of whether something is reusable is
> > whether I can reuse thing A while also reusing thing B that was
> > developed independently.
>
> You missed the memo. :) The prefix "re" is there for a reason. The
> sense you are using is coverd by "use".
Okay, so what's "reuse"? I thought if I wrote a class and used it in
one program, then when I used it in another program that was *re*-use.
How many times do I have to use it? Speaking of reuse, I'm sensing
that you're reusing the old, "it's not AI if we know how to do it"
argument. That is, if people actually do it, it can't be reuse--it's
just "regular library code" or something.
-Peter
[1] My dad used to do some work with companies that were trying to
rationalize the data exchanged between big auto manufacturers and
their suppliers--order forms and such. But it continues to not get
rationalized because the big players like having the small players
tied to them by virtue of all the investment the small players have
made in dealing with the Ford way or the GM way. If the forms were all
the same, it would be easier for the small players to try to cut deals
with competing manufacturers. And nobody at Ford or GM wants that.
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel wrote:
> Okay, so what's "reuse"? I thought if I wrote a class and used it in
> one program, then when I used it in another program that was *re*-use.
This is a silly exchange because I am saying "reuse" is a bit of jargon
of which you are unaware for a claim you are unaware was ever made. You
just keep saying you know what the word means in English. Not that you
have that right. But it's late, time for me to reuse the door into my
local pub for a nightcap. (I'll be reusing one of their glasses.)
Have you tried Google on "OO reuse hype"?
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
> Peter Seibel wrote:
>
> > Okay, so what's "reuse"? I thought if I wrote a class and used it in
> > one program, then when I used it in another program that was *re*-use.
>
> This is a silly exchange because I am saying "reuse" is a bit of
> jargon of which you are unaware for a claim you are unaware was ever
> made. You just keep saying you know what the word means in English.
> Not that you have that right. But it's late, time for me to reuse
> the door into my local pub for a nightcap. (I'll be reusing one of
> their glasses.)
>
> Have you tried Google on "OO reuse hype"?
Okay, as long as we agree it's silly. ;-) To the extent that this is
about the failure of OO to live up to the overpowering hype of its
proponents, here's my point:: Some very good ideas have been hyped and
some very bad ideas have been hyped. Thus hype (and consequent failure
to live up to same) is not, I don't think, a very good indicator of
the *actual* worth of anything. But labeling something as over hyped
is an easy way to dismiss ideas and thus avoid the work of actually
engaging with them. Thus it rubs me the wrong way as a rhetorical
device. Certainly Lisp is often dismissed on those grounds so we
should, I imagine, be sensitive to what a bogus argument it is.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel wrote:
> I can tell you this: no Java
> programmer bothers writing their own string or hash table classes.
But the point is that no one subclasses these to add new functionality,
re-releasing them within the organization (or to the public) for further
use. That was the type of re-use people were originally talking about.
Instead, people keep writing the same wrappers around string or hash-table
to do (approximately) the same stuff.
faa
"Frank A. Adrian" <·······@ancar.org> writes:
> Peter Seibel wrote:
>
> > I can tell you this: no Java programmer bothers writing their own
> > string or hash table classes.
>
> But the point is that no one subclasses these to add new
> functionality, re-releasing them within the organization (or to the
> public) for further use. That was the type of re-use people were
> originally talking about. Instead, people keep writing the same
> wrappers around string or hash-table to do (approximately) the same
> stuff.
Okay, so why is subclassing Servlet to make a new kind of servlet not
this long-promised kind of reuse?
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel wrote:
> "Frank A. Adrian" <·······@ancar.org> writes:
>
>
>>Peter Seibel wrote:
>>
>>
>>>I can tell you this: no Java programmer bothers writing their own
>>>string or hash table classes.
>>
>>But the point is that no one subclasses these to add new
>>functionality, re-releasing them within the organization (or to the
>>public) for further use. That was the type of re-use people were
>>originally talking about. Instead, people keep writing the same
>>wrappers around string or hash-table to do (approximately) the same
>>stuff.
>
>
> Okay, so why is subclassing Servlet to make a new kind of servlet not
> this long-promised kind of reuse?
You sure got your heels dug in on this one. :)
You blew off my LabInstrument example, but that was the kind of re-use
that means "Re-use". The idea was that class designers would find
methods which would be true for all lab instruments, and write those
methods in a way that did not have built-in assumptions about lab
instruments, such that people everywhere who had to provide drivers for
lab instruments could use those classes as a starting point.
The reality was, "damn! it's perfect, but all the code assumes metric
and discrete putput values, I need English and continuous." Even if they
have access to the source, no one gets a medal for refactoring when it
slows down delivery by a week, so they just clone the code and make a
new, unrelated class,
What you are seeing in the Servlet is that one very precise target (the
Java app server) works with one very specific set of code, the shared
part of Servelt. That makes Servlet nothing more than a fancy way to
pass around templates.
If you Google on re-use, you will find a lot. One conventional wisdom is
that designing nicely abstracted classes is just as hard as designing
nicely abstracted libraries, OO or no. And that since most organizations
do not reward long-term benefit, there is never time to do it right.
Grady Booch can be found out their on the WWW talking about the need for
formal methods and some non-trivial math to get re-use, right.
Do you think Sun had to use formal methods to hard-code the Servlet
class to work with the APpServer class?
Another thing you will find if you use Google might be a piece by
Gabriel (or was that just in a book?) where he says, hey, it's just too
damn hard finding the right re-usable class, even though it is out there!
Does anyone writing a servlet for Java AppServer accidentally not notice
the Servlet class and re-invent one from scratch?
While Googling, you'll have to fend off the commercial sites of
consultants promising to help companies achieve re-use, I suppose by
re-factoring all their existing code to be a little cleaner.
But if you find one which says, "How can you quickly develop a Servlet
for the Java AppServer? Hire us and we'll tell you!", I'd love to see
the rest of the site.
With the consultants out of the way, you might find a study in which
they identified another reason for re-use: the potential re-user found
the class but did not realize it did what they needed!
I think I saw somewhere the proposal that a company have OOAs,
object-oriententation administrators ala DBAs, to serve as a coordinator
of object design and re-use, just to make it happen.
$150K OOA: "Billy Bob, use the Servlet class included with AppServe.
Whew! I need a comp day."
Billy Bob: "I looked at that, but it does not do what I need."
Close your eyes. Imagine a National Bureau of Standard Object
Repository, with classes written by people just thinking about lab
instruments and accounts payable and list widgets for GUIs, all of which
work just like your cherished Servlet class, but which do not assume
anything about your, say, lab instrument other than that it is a typical
lab instrument, which probably uses electricity, is metric or not,
determines values, has settings, whatever.
That was the dream/hype.
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
> Peter Seibel wrote:
> > "Frank A. Adrian" <·······@ancar.org> writes:
> >
> >>Peter Seibel wrote:
> >>
> >>
> >>>I can tell you this: no Java programmer bothers writing their own
> >>>string or hash table classes.
> >>
> >>But the point is that no one subclasses these to add new
> >>functionality, re-releasing them within the organization (or to the
> >>public) for further use. That was the type of re-use people were
> >>originally talking about. Instead, people keep writing the same
> >>wrappers around string or hash-table to do (approximately) the same
> >>stuff.
> > Okay, so why is subclassing Servlet to make a new kind of servlet not
> > this long-promised kind of reuse?
>
> You sure got your heels dug in on this one. :)
>
> You blew off my LabInstrument example, but that was the kind of
> re-use that means "Re-use". The idea was that class designers would
> find methods which would be true for all lab instruments, and write
> those methods in a way that did not have built-in assumptions about
> lab instruments, such that people everywhere who had to provide
> drivers for lab instruments could use those classes as a starting
> point.
Okay, so OO "totally failed" because it turns out there's no economic
incentive for the makers and users of lab instruments to invest in
standardizing an API to something as nebulous as "lab instruments". If
you feel you were promised that then I think it is not I who "fell
for" the hype. All I'm saying is that Java programmers do reuse code
in a variety of ways including writing new subclasses of classes they
didn't write.
Setting up an ill-defined abstraction like lab instrument and then
saying, see, there's no way to write a class that can simultaneously
represent every possible lab instrument *and* provide loads of useful
functionality doesn't prove anything. Again, if your point is just
that some overenthusiastic OO hypemongers implied this would happen,
fine, I agree. But there are also well-defined abstractions that do
admit class definitions that capture commonality and allow them to be
used in varying circumstances.
> The reality was, "damn! it's perfect, but all the code assumes
> metric and discrete putput values, I need English and continuous."
> Even if they have access to the source, no one gets a medal for
> refactoring when it slows down delivery by a week, so they just
> clone the code and make a new, unrelated class,
>
> What you are seeing in the Servlet is that one very precise target
> (the Java app server) works with one very specific set of code, the
> shared part of Servelt. That makes Servlet nothing more than a fancy
> way to pass around templates.
I'm not sure what you mean by "very precise target" and that implies
there is no reuse, even in the hype sense. All I know is that when you
hit a web page that is backed by a servlet you're running code from at
least three organizations--Javasoft, the app server vendor (e.g.
Weblogic, IBM, Apache/Tomcat), and the guy who wrote the servlet. That
that code all works together despite being writting by different
programmers in different organizations and that different pieces of it
are also being used in different combination on other web sites
suggests to me that something must be being reused.
But if you don't like Servlets, take JDBC drivers. Sun set the
standard, defining the base classes and interfaces that comprise a
JDBC driver. 3rd parties implement drivers that talk to different
databases in different ways (some wrap the db's C libraries, some
implement the wire protocol directly in Java, some in fact *are*
databases that run in process). And applications developers can use
the same JDBC implementation on different projects or use different
JDBC implementations within the same software. And people even do
write extensions to the JDBC classes to add new behaviors that are
needed by their apps. What other kind of reuse do you want?
> If you Google on re-use, you will find a lot. One conventional
> wisdom is that designing nicely abstracted classes is just as hard
> as designing nicely abstracted libraries, OO or no. And that since
> most organizations do not reward long-term benefit, there is never
> time to do it right.
No doubt. Again, if your point is reality is less rosy than the world
of marketing hype, you get no argument from me.
> Grady Booch can be found out their on the WWW talking about the need
> for formal methods and some non-trivial math to get re-use, right.
>
> Do you think Sun had to use formal methods to hard-code the Servlet
> class to work with the APpServer class?
No. But I think Booch is overstating the case. (And what do you mean
hard-code--you say it like its a bad thing. But obviously any class
that contains actual code is going to have some "hard-coded" code.)
> Another thing you will find if you use Google might be a piece by
> Gabriel (or was that just in a book?) where he says, hey, it's just
> too damn hard finding the right re-usable class, even though it is out
> there!
>
> Does anyone writing a servlet for Java AppServer accidentally not
> notice the Servlet class and re-invent one from scratch?
Nope. Doesn't that just prove that in certain cirumstances Gabriel is
wrong? (I really get the feeling that you are defining "re-use" as
something that can't be done. Therefore if someone actually does it
it's not reuse. Like AI.)
> Close your eyes. Imagine a National Bureau of Standard Object
> Repository, with classes written by people just thinking about lab
> instruments and accounts payable and list widgets for GUIs, all of
> which work just like your cherished Servlet class, but which do not
> assume anything about your, say, lab instrument other than that it
> is a typical lab instrument, which probably uses electricity, is
> metric or not, determines values, has settings, whatever.
>
> That was the dream/hype.
And I'm saying, for Java programmers, in certain domains, Javasoft
acts as the NBoSOR and the dream is true. Javasoft defines interfaces
and base classes that *don't* assume anything more about, say, a
RDBMS, than that someone will be able to write concrete classes that
when put together with the classes provided by Javasoft allow other
programmers to write code that talks to the RDBMS. If you tell them it
was just a dream and that they are just deluded fools, you'll just
convince them that you don't know what you're talking about. And, by
extension, that they can safely ignore when you tell them how great
Lisp is. Which was really my only point in a thread about how to
present CLOS to Lispnots.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>Peter Seibel wrote:
>>
>>>"Frank A. Adrian" <·······@ancar.org> writes:
>>>
>>>
>>>>Peter Seibel wrote:
>>>>
>>>>
>>>>
>>>>>I can tell you this: no Java programmer bothers writing their own
>>>>>string or hash table classes.
>>>>
>>>>But the point is that no one subclasses these to add new
>>>>functionality, re-releasing them within the organization (or to the
>>>>public) for further use. That was the type of re-use people were
>>>>originally talking about. Instead, people keep writing the same
>>>>wrappers around string or hash-table to do (approximately) the same
>>>>stuff.
>>>
>>>Okay, so why is subclassing Servlet to make a new kind of servlet not
>>>this long-promised kind of reuse?
>>
>>You sure got your heels dug in on this one. :)
>>
>>You blew off my LabInstrument example, but that was the kind of
>>re-use that means "Re-use". The idea was that class designers would
>>find methods which would be true for all lab instruments, and write
>>those methods in a way that did not have built-in assumptions about
>>lab instruments, such that people everywhere who had to provide
>>drivers for lab instruments could use those classes as a starting
>>point.
>
>
> Okay, so OO "totally failed"
I never said that. I said (floated, actually, the idea that) certain OO
models failed at reuse by asking too much of objects, by marrying code
to structure by making functions owned members of objects, even
pretending there was no code there, just behaviors. The context remains
possible horror at GFs not strictly belonging to a class by having only
one dispatch argument, the class.
because it turns out there's no economic
> incentive for the makers and users of lab instruments to invest in
> standardizing an API to something as nebulous as "lab instruments". If
> you feel you were promised that then I think it is not I who "fell
> for" the hype.
<sigh> I also suggested GFs and espcially Cells do better at reuse by
not asking so much of the class definition. We don't get the ideal of
tons of code off the shelf in standard objects, but we might get
standard objects offering what code can be reasonably generalized.
So no, I am not talking about falling for anything, I am desperately
trying to drag the conversation back to a possibly goofy hypothesis: is
the tight couipling of code and structure why reuse failed?
Unfortunately, I am stuck in this attempt to dress "use" up in the cloak
of "reuse".
Aside: I am surprised at your despair at the idea of a useful
LabInstrument class. I wager quite a bit can be expressed generically,
albeit with stubs to be filled in as classes get more specific. Lab
instruments are nowhere near as varied as the code written to support
them, because programmers just hack out this and that whenever faced
with a problem. So, yes, given the right amount of analysis and ongoing
refactoring as more and more lab instruments get brought on line,
significant re-use should be possible. But it is hard to fund that kind
of effort, and without the once-anticipated market for reusable objects,
nowhere to sell them if you did.
But if classes are made more reusable by decoupling code from structure,
people just might start reusing standard classes enough to draw in more
development work, aka more careful analysis and eventually end up with
quite a bit of reusable code as well as structure.
Gee, as I write this I am reminded of the XML phenomenon.
Domain-specific groups are supposed to be getting to gether to agree on
standard XML entities. I wonder how that is going.
btw, while Servlet is not an example of the hyped reusable standard
object, that does not mean I do not agree with all the advantages you
see in it. Lots of classes and even just plain old libraries are
tremendously effective at delivering a lot of builtin functionality
while allowing necessary customizabilty by filling in the blanks. And I
am a big defender of OO for what it does deliver, never mind what it did
not.
> But if you don't like Servlets, take JDBC drivers. Sun set the
> standard, defining the base classes and interfaces ...that comprise a
> JDBC driver. 3rd parties...
See? That's the only way it can work, with a single, fixed target.
>>Does anyone writing a servlet for Java AppServer accidentally not
>>notice the Servlet class and re-invent one from scratch?
>
>
> Nope. Doesn't that just prove that in certain cirumstances Gabriel is
> wrong?
Wow, you missed the joke and the idea. I imagine Servlet appears in
about the first three AppServer FAQ response. They were defined,
written, documented, sold together.
By contrast, the papers out there on the failure of reuse are--well, I
saw one where they actually set up a study with a problem specification
and some documented classes and said go at it, and sometimes the
developers did not realize the class would do what they wanted. I do not
think that was Gabriel's exact slant (faint recall is that it was more
about the digging it would take to find the right class, I suppose given
the fact that they are never actually catalogued--something like that).
(I really get the feeling that you are defining "re-use" as
> something that can't be done. Therefore if someone actually does it
> it's not reuse. Like AI.)
I am saying re-use is jargon with a very definite meaning and that it is
hype to use the word as an attempt to dress up some lesser
accomplishment. A more accurate parallel is that calling Servlet
"re-use" is like claiming "AI" for software doing nothing of the sort,
just for the glamour.
As for defining it as something which cannot be done, I guess you missed
my tentaive claim to have achieved re-use via Cells. Just as a function
which can take a function as an argument achieves a higher order of
power and flexibility, when instances of the same class can have
different functions expressing the value of the same slot, that class
likewise becomes more versatile.
It's just a little hard debating that admittedly controversial claim if
re-use no longer means what it means.
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
[snipping *and* reordering Kenny's original text]
> I am saying re-use is jargon with a very definite meaning and that
> it is hype to use the word as an attempt to dress up some lesser
> accomplishment. A more accurate parallel is that calling Servlet
> "re-use" is like claiming "AI" for software doing nothing of the
> sort, just for the glamour.
Okay, if I understand you correctly you're using "jargon" here in the
non-pejorative sense. Good. In other words "reuse" is a term of art
that I am using incorrectly, using my own naively constructed meaning
of "I use it once; I use it again; I've reused it." That fine. Maybe
I'm just dense then but I haven't been able to understand what the
"very definite meaning" of reuse as a term of art is. You say things
like this:
> >>The idea was that class designers would find methods which would
> >>be true for all lab instruments, and write those methods in a way
> >>that did not have built-in assumptions about lab instruments, such
> >>that people everywhere who had to provide drivers for lab
> >>instruments could use those classes as a starting point.
And I say, okay, I don't have LabInstrument class but I've got the
Servlet class which contains methods that don't make built-in
assumptions about *either* the servlets that will extend it or the app
server it will run in. And you say, "but a Servlet is too specific".
And I don't understand why you think Servlet is too specific but that
a generally useful LabInstrument class *wouldn't* be. Can you give a
definition of reuse rather than an example. Or even an example of
something that *does* provide what you consider reuse (preferably one
that doesn't require me downloading and completely grokking Cells).
> I never said that. I said (floated, actually, the idea that) certain
> OO models failed at reuse by asking too much of objects, by marrying
> code to structure by making functions owned members of objects, even
> pretending there was no code there, just behaviors. The context
> remains possible horror at GFs not strictly belonging to a class by
> having only one dispatch argument, the class.
That's an interesting idea. I'm not sure I buy it. Of course you
haven't convinced me that "certain OO models failed at reuse" (where
"certain models" presumably includes Java). I'd be more likely to
believe that having GFs *in addition* to single-class-based methods
allows more flexible and/or more convenient ways of reusing existing
code.
> <sigh> I also suggested GFs and espcially Cells do better at reuse by
> not asking so much of the class definition. We don't get the ideal of
> tons of code off the shelf in standard objects, but we might get
> standard objects offering what code can be reasonably generalized.
And I still don't understand why Java-style interfaces and classes
*have* to fail at providing reuse. In my experience classes that only
offer "what code can be reasonably generalized" *are* reusable (or
whatever you want to call it--I use them over and over.) Obviously
there's no magic. If there is no way to generalize something then no
language mechanism is going to make it possible. But just because
class-based OO doesn't *always* work doesn't mean it *never* works.
> So no, I am not talking about falling for anything, I am desperately
> trying to drag the conversation back to a possibly goofy hypothesis:
> is the tight couipling of code and structure why reuse failed?
I'm not convinced that "reuse failed". Of course I still don't know
what you mean be reuse?
> Aside: I am surprised at your despair at the idea of a useful
> LabInstrument class. I wager quite a bit can be expressed
> generically, albeit with stubs to be filled in as classes get more
> specific. Lab instruments are nowhere near as varied as the code
> written to support them, because programmers just hack out this and
> that whenever faced with a problem. So, yes, given the right amount
> of analysis and ongoing refactoring as more and more lab instruments
> get brought on line, significant re-use should be possible. But it
> is hard to fund that kind of effort, and without the
> once-anticipated market for reusable objects, nowhere to sell them
> if you did.
Actually I don't despair. I agree with you, I just didn't want to get
into it. I actually did a search for "java lab instrument" and found a
couple companies offering various Java APIs for doing various stuff
with lab instruments. None of it seemed quite soup enough to bother
bringing up as an example though.
> But if classes are made more reusable by decoupling code from
> structure, people just might start reusing standard classes enough to
> draw in more development work, aka more careful analysis and
> eventually end up with quite a bit of reusable code as well as
> structure.
Hmmm. So can you expand on *why* you think classes are made more
reusable by decoupling code from structure. I have a glimmer of what
you might mean but given that that's 180-degrees from OO orthodoxy I
think it's worth spelling out why you think its true.
> Gee, as I write this I am reminded of the XML phenomenon.
> Domain-specific groups are supposed to be getting to gether to agree
> on standard XML entities. I wonder how that is going.
I'm sure their failing in some areas and succeeding in others based
entirely on economical and political issues, not technical ones.
> > But if you don't like Servlets, take JDBC drivers. Sun set the
> > standard, defining the base classes and interfaces ...that
> > comprise a JDBC driver. 3rd parties...
>
> See? That's the only way it can work, with a single, fixed target.
Can you give an example of something that's not a single, fixed
target? Because I sure don't know what you mean. I feel like if I
found the class Universe that had well-abstracted methods for anything
you might want to do ever and places to hook into it, you'd say, "Yeah
but the universe in a single, fixed target. Show me real reuse."
> >>Does anyone writing a servlet for Java AppServer accidentally not
> >>notice the Servlet class and re-invent one from scratch?
> > Nope. Doesn't that just prove that in certain cirumstances Gabriel is
> > wrong?
>
> Wow, you missed the joke and the idea. I imagine Servlet appears in
> about the first three AppServer FAQ response. They were defined,
> written, documented, sold together.
Okay I'm still missing the joke and the point. Don't worry about the
joke. What is the "they" that were written, documented, and sold
together? Servlet is a class (actually a set of classes and
interfaces) defined by Javasoft. The app servers that can actually run
servlets were written independently and support running servlets
because they decided to incorporate the Javasoft framework rather than
inventing their own. And obviously the actual servlets are written by
the people running app servers.
> By contrast, the papers out there on the failure of reuse are--well,
> I saw one where they actually set up a study with a problem
> specification and some documented classes and said go at it, and
> sometimes the developers did not realize the class would do what
> they wanted. I do not think that was Gabriel's exact slant (faint
> recall is that it was more about the digging it would take to find
> the right class, I suppose given the fact that they are never
> actually catalogued--something like that).
And why do you think GF based frameworks are going to make that
problem any easier. If anything I'd expect that without specific
efforts otherwise it would be *harder* to find the code you need in a
GF framework. Not that it might not be more useful if and when you
found it. But at least class-based OO, for all its other drawbacks and
rigidity, provides a standard organizing principle. If you follow the
lead of Java and provide a standardized documentation format (Javadoc)
it becomes even easier to find what you're looking for.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel <·····@javamonkey.com> writes:
> [snipping *and* reordering Kenny's original text]
keeping in that spirit, I'm responding to the top and the bottom of
your post :)
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> > I am saying re-use is jargon with a very definite meaning and that
> > it is hype to use the word as an attempt to dress up some lesser
> > accomplishment. A more accurate parallel is that calling Servlet
> > "re-use" is like claiming "AI" for software doing nothing of the
> > sort, just for the glamour.
>
> Okay, if I understand you correctly you're using "jargon" here in the
> non-pejorative sense. Good. In other words "reuse" is a term of art
> that I am using incorrectly, using my own naively constructed meaning
> of "I use it once; I use it again; I've reused it." That fine. Maybe
> I'm just dense then but I haven't been able to understand what the
> "very definite meaning" of reuse as a term of art is. You say things
> like this:
>
> > >>The idea was that class designers would find methods which would
> > >>be true for all lab instruments, and write those methods in a way
> > >>that did not have built-in assumptions about lab instruments, such
> > >>that people everywhere who had to provide drivers for lab
> > >>instruments could use those classes as a starting point.
>
> And I say, okay, I don't have LabInstrument class but I've got the
> Servlet class which contains methods that don't make built-in
> assumptions about *either* the servlets that will extend it or the app
> server it will run in. And you say, "but a Servlet is too specific".
Parly Servlet is too specific, but mostly, Java Servlets are an
example of old-fashioned library building. The Servlet class was
carefully designed to provide a framework for constructing Java
Servlets. The hyped idea of reuse was that, as a product of normal
development, you'd end out with highly reusable classes. What you
have in Java is an environment that makes it easier to put on your
library-designer hat, but you still have to wear the hat.
> And why do you think GF based frameworks are going to make that
> problem any easier. If anything I'd expect that without specific
> efforts otherwise it would be *harder* to find the code you need in a
> GF framework. Not that it might not be more useful if and when you
> found it. But at least class-based OO, for all its other drawbacks and
> rigidity, provides a standard organizing principle. If you follow the
> lead of Java and provide a standardized documentation format (Javadoc)
> it becomes even easier to find what you're looking for.
Doesn't everybody have their own tool for digging through the code
loaded into a Lisp image? Class and method browsers, combined with
docstrings, are even easier to use than Javadoc documentation.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@fallingrocks.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Parly Servlet is too specific, but mostly, Java Servlets are an
> example of old-fashioned library building. The Servlet class was
> carefully designed to provide a framework for constructing Java
> Servlets. The hyped idea of reuse was that, as a product of normal
> development, you'd end out with highly reusable classes. What you
> have in Java is an environment that makes it easier to put on your
> library-designer hat, but you still have to wear the hat.
Okay. That makes sense. If that's what Kenny means by "reuse" then
we're all good. I agree that no language I've had experience with has
somehow made it possible for a programmer just hacking away, solving
their own immediate and specific problems to automatically produce
code that turns out to be generally useful. Writing reusable code,
whether as objects or function libraries, or macros, or whatever takes
extra effort. Some of which goes into making sure the code doesn't
have weird edge cases it handles strangly and some of which goes into
documenting the code and publicizing it so the people who *could*
reuse, er, use, it can find it.
> > And why do you think GF based frameworks are going to make that
> > problem any easier. If anything I'd expect that without specific
> > efforts otherwise it would be *harder* to find the code you need in a
> > GF framework. Not that it might not be more useful if and when you
> > found it. But at least class-based OO, for all its other drawbacks and
> > rigidity, provides a standard organizing principle. If you follow the
> > lead of Java and provide a standardized documentation format (Javadoc)
> > it becomes even easier to find what you're looking for.
>
> Doesn't everybody have their own tool for digging through the code
> loaded into a Lisp image? Class and method browsers, combined with
> docstrings, are even easier to use than Javadoc documentation.
Well, maybe I haven't built mine yet. And even if I had, when looking
for code that one might want to use it's nice to be able to just
browse to a web page and see the documentation in a format you're
already familiar with. That's what Javadoc gives me. And Javadocs also
add some additional structure, partly thanks to <shudder> static
typing. There's no in-principle reason that Lisp couldn't have such a
system and that it couldn't be even better. But at the moment I think
it's one of Java's strong suits. (I know someone is working on a
Javadoc like tool for CL, Alfred or something but I haven't looked at
it yet.)
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel <·····@javamonkey.com> writes:
> ···@fallingrocks.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > Doesn't everybody have their own tool for digging through the code
> > loaded into a Lisp image? Class and method browsers, combined with
> > docstrings, are even easier to use than Javadoc documentation.
>
> Well, maybe I haven't built mine yet. And even if I had, when looking
> for code that one might want to use it's nice to be able to just
> browse to a web page and see the documentation in a format you're
> already familiar with. That's what Javadoc gives me.
That's true, and that is an advantage.
> And Javadocs also
> add some additional structure, partly thanks to <shudder> static
> typing. There's no in-principle reason that Lisp couldn't have such a
> system and that it couldn't be even better. But at the moment I think
> it's one of Java's strong suits. (I know someone is working on a
> Javadoc like tool for CL, Alfred or something but I haven't looked at
> it yet.)
I was somewhat surprised when I learned that javadoc works on the Java
source *text*, and doesn't use their introspection API (doesn't sound
like they had much confidence in it, to me). The fact that someone's
doing the same for CL just seems crazy. Maybe I'll bite the bullet
and spruce up my personal tool so it's appropriate for general use.
And I should probably make it output HTML, though, instead of an Emacs
outline-mode file, huh?
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
"Thomas F. Burdick" wrote:
>
> Peter Seibel <·····@javamonkey.com> writes:
>
> > ···@fallingrocks.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> >
> > > Doesn't everybody have their own tool for digging through the code
> > > loaded into a Lisp image? Class and method browsers, combined with
> > > docstrings, are even easier to use than Javadoc documentation.
> >
> > Well, maybe I haven't built mine yet. And even if I had, when looking
> > for code that one might want to use it's nice to be able to just
> > browse to a web page and see the documentation in a format you're
> > already familiar with. That's what Javadoc gives me.
>
> That's true, and that is an advantage.
>
> > And Javadocs also
> > add some additional structure, partly thanks to <shudder> static
> > typing.
do java declarations provide anything which cl declarations do not?
> > There's no in-principle reason that Lisp couldn't have such a
> > system and that it couldn't be even better. But at the moment I think
> > it's one of Java's strong suits. (I know someone is working on a
> > Javadoc like tool for CL, Alfred or something but I haven't looked at
> > it yet.)
>
> I was somewhat surprised when I learned that javadoc works on the Java
> source *text*, and doesn't use their introspection API (doesn't sound
> like they had much confidence in it, to me).
javadoc predates the introspection api. one might argue that it would make
sense to switch, but there is a lot of information which a javadoc processor
extracts form the comments but would it could not derive from the data
available "introspectively".
> The fact that someone's
> doing the same for CL just seems crazy.
it's an issue of the format and the consequent accessibility. last time i
looked at it the intent was to generate docbook. why would that be crazy?
> Maybe I'll bite the bullet
> and spruce up my personal tool so it's appropriate for general use.
> And I should probably make it output HTML, though, instead of an Emacs
> outline-mode file, huh?
one could argue that html would be disadvantageous. cl-http, for example, has
"always" been able to generate it's own documentation for functions and
classes - once one got the server up. at one point i contributed code which
acted as an html-based inspector, but html is a dead end for such things.
docbook would offer the advantage that one could retarget large documents to
other than browser display, but it still does not get one to the point where
one could target standard case tools.
...
james anderson <··············@setf.de> writes:
> > Peter Seibel <·····@javamonkey.com> writes:
> >
> > > And Javadocs also
> > > add some additional structure, partly thanks to <shudder> static
> > > typing.
>
> do java declarations provide anything which cl declarations do not?
I don't think so, and I was going to make a similar comment because
type information about slots is available through the MOP. However,
due to Java's static typing, slots always have interesting types.
Some Lisp programs will have interesting types declared for their
slots (CLX comes to mind), but often, they'll just all be T.
> "Thomas F. Burdick" wrote:
> >
> > I was somewhat surprised when I learned that javadoc works on the Java
> > source *text*, and doesn't use their introspection API (doesn't sound
> > like they had much confidence in it, to me).
>
> javadoc predates the introspection api.
Okay, that makes sense, and everything else about it kind of falls out
of that.
> > The fact that someone's
> > doing the same for CL just seems crazy.
>
> it's an issue of the format and the consequent accessibility. last time i
> looked at it the intent was to generate docbook. why would that be crazy?
Huh?!?! Generating docbook is fine -- but why on earth would you need
to munge the program *text* to generate docbook? Common Lisp is not
defined on text, and it's completely pedestrian to take advantage of
that. For example, code that uses Kenny's Cells library uses its own
macro, DEFMODEL, in place of DEFCLASS, because MOP portability can be
painful. Loading code then inspecting the image, you can see the
results of that DEFMODEL, without having to understand the macro's
syntax.
Okay, so maybe not everything you want to say can fit in docstrings.
Really, who sees a problem and asks themselves WWJavaD? Sun is not
the center of the universe! Rather than munge comments, add your own
form:
(eval-when (:compile-toplevel :load-toplevel :execute)
(unless (fboundp 'docotool)
(defmacro docotool (&rest ignore)
(declare (ignore ignore))
nil)))
;; ...
(docotool #'foo "formatted text here")
> > Maybe I'll bite the bullet
> > and spruce up my personal tool so it's appropriate for general use.
> > And I should probably make it output HTML, though, instead of an Emacs
> > outline-mode file, huh?
>
> one could argue that html would be disadvantageous. cl-http, for example, has
> "always" been able to generate it's own documentation for functions and
> classes - once one got the server up. at one point i contributed code which
> acted as an html-based inspector, but html is a dead end for such things.
> docbook would offer the advantage that one could retarget large documents to
> other than browser display, but it still does not get one to the point where
> one could target standard case tools.
Well, I wasn't thinking HTML directly, so much as either docbook,
texinfo, something similar, or maybe just say f'it, and go with LaTeX.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Well, I wasn't thinking HTML directly, so much as either docbook,
> texinfo, something similar, or maybe just say f'it, and go with LaTeX.
Huh? Come on man, get with the times: cl-typesetting.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
"Thomas F. Burdick" wrote:
>
> james anderson <··············@setf.de> writes:
> > ...
> > "Thomas F. Burdick" wrote:
> > >
> > > I was somewhat surprised when I learned that javadoc works on the Java
> > > source *text*, and doesn't use their introspection API (doesn't sound
> > > like they had much confidence in it, to me).
> >
> > javadoc predates the introspection api.
>
> Okay, that makes sense, and everything else about it kind of falls out
> of that.
>
> > > The fact that someone's
> > > doing the same for CL just seems crazy.
> >
> > it's an issue of the format and the consequent accessibility. last time i
> > looked at it the intent was to generate docbook. why would that be crazy?
>
> Huh?!?! Generating docbook is fine -- but why on earth would you need
> to munge the program *text* to generate docbook?
one motivation is to implement calling analysis portably.
> Common Lisp is not
> defined on text, and it's completely pedestrian to take advantage of
> that.
i surmise from the description (sourceforge.net/projects/albert), that the
approach is to analyse the source code, but not the "text".
> For example, code that uses Kenny's Cells library uses its own
> macro, DEFMODEL, in place of DEFCLASS, because MOP portability can be
> painful. Loading code then inspecting the image, you can see the
> results of that DEFMODEL, without having to understand the macro's
> syntax.
>
> Okay, so maybe not everything you want to say can fit in docstrings.
> Really, who sees a problem and asks themselves WWJavaD? Sun is not
> the center of the universe! Rather than munge comments, add your own
> form:
>
> (eval-when (:compile-toplevel :load-toplevel :execute)
> (unless (fboundp 'docotool)
> (defmacro docotool (&rest ignore)
> (declare (ignore ignore))
> nil)))
it works better if it returns (values).
>
> ;; ...
>
> (docotool #'foo "formatted text here")
>
james anderson <··············@setf.de> writes:
> "Thomas F. Burdick" wrote:
>
> > Huh?!?! Generating docbook is fine -- but why on earth would you need
> > to munge the program *text* to generate docbook?
>
> one motivation is to implement calling analysis portably.
>
> > Common Lisp is not
> > defined on text, and it's completely pedestrian to take advantage of
> > that.
>
> i surmise from the description (sourceforge.net/projects/albert), that the
> approach is to analyse the source code, but not the "text".
Hmm, I saw it repeatedly compared to javadoc, so I didn't look very
closely at it. Personally, I think it's better to take an
inspect-the-live-image approach, but having looked over the site a
little bit, I at least understand what they were thinking.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> james anderson <··············@setf.de> writes:
>
> > "Thomas F. Burdick" wrote:
> >
> > > Huh?!?! Generating docbook is fine -- but why on earth would you need
> > > to munge the program *text* to generate docbook?
> >
> > one motivation is to implement calling analysis portably.
> >
> > > Common Lisp is not
> > > defined on text, and it's completely pedestrian to take advantage of
> > > that.
> >
> > i surmise from the description (sourceforge.net/projects/albert), that the
> > approach is to analyse the source code, but not the "text".
>
> Hmm, I saw it repeatedly compared to javadoc, so I didn't look very
> closely at it. Personally, I think it's better to take an
> inspect-the-live-image approach, but having looked over the site a
> little bit, I at least understand what they were thinking.
Seems like the best of both worlds is to provide a way to
unobtrusively annotate code with documentation that is then made
available in the image via DOCUMENTATION or DOCUMENTATION on steriods
and *also* to provide a tool that can crawl through an image and
produce static documentation in a variety of formats (one of which
almost has to be HTML these days) so you can put the docs for your
libraries up on the web in a format that folks can browse before
they've decided whether they even want to load it into their image.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel <·····@javamonkey.com> writes:
> ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > Hmm, I saw it repeatedly compared to javadoc, so I didn't look very
> > closely at it. Personally, I think it's better to take an
> > inspect-the-live-image approach, but having looked over the site a
> > little bit, I at least understand what they were thinking.
>
> Seems like the best of both worlds is to provide a way to
> unobtrusively annotate code with documentation that is then made
> available in the image via DOCUMENTATION or DOCUMENTATION on steriods
> and *also* to provide a tool that can crawl through an image and
> produce static documentation in a variety of formats (one of which
> almost has to be HTML these days) so you can put the docs for your
> libraries up on the web in a format that folks can browse before
> they've decided whether they even want to load it into their image.
Actually, that falls under the inspect-the-image approach, in my book.
I added the ability to do this kind of annotation to my personal
DocoSketch tool, which just crawls over loaded packages, and collects
what it finds (and dumps an Emacs outline-mode file, and used to be
able to also visualize the information using Garnet).
What this approach misses is "portable" call-graph analysis. Of
course, unless you specially instruct the analyzer for the code base,
it won't be able to do all that much, so I don't think this is a big
loss (and hence the scare quotes around "portable").
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
james anderson <··············@setf.de> writes:
> > (eval-when (:compile-toplevel :load-toplevel :execute)
> > (unless (fboundp 'docotool)
> > (defmacro docotool (&rest ignore)
> > (declare (ignore ignore))
> > nil)))
> it works better if it returns (values).
I can't find any information about special treatment when a macro
returns no values. (Unlike reader macros.) All I see in the CLHS
says that the macro expands to whatever form the macro returns, which
makes me believe returning (values) would either invoke unspecified
behaviour or be treated as nil.
Did I miss something?
--
Lars Brinkhoff, Services for Unix, Linux, GCC, HTTP
Brinkhoff Consulting http://www.brinkhoff.se/
Lars Brinkhoff wrote:
>
> james anderson <··············@setf.de> writes:
> > > (eval-when (:compile-toplevel :load-toplevel :execute)
> > > (unless (fboundp 'docotool)
> > > (defmacro docotool (&rest ignore)
> > > (declare (ignore ignore))
> > > nil)))
> > it works better if it returns (values).
>
> I can't find any information about special treatment when a macro
> returns no values. (Unlike reader macros.) All I see in the CLHS
> says that the macro expands to whatever form the macro returns, which
> makes me believe returning (values) would either invoke unspecified
> behaviour or be treated as nil.
>
> Did I miss something?
no, sorry. you are right. it works better as a reader macro which returns (values).
eg, http://www.setf.de/library/de/setf/xml/xml-rpc/index.{html,lisp}
(a css2-capable browser is recmmended.)
...
james anderson <··············@setf.de> writes:
> "Thomas F. Burdick" wrote:
> >
> > Peter Seibel <·····@javamonkey.com> writes:
> >
> > > ···@fallingrocks.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> > >
> > > > Doesn't everybody have their own tool for digging through the code
> > > > loaded into a Lisp image? Class and method browsers, combined with
> > > > docstrings, are even easier to use than Javadoc documentation.
> > >
> > > Well, maybe I haven't built mine yet. And even if I had, when looking
> > > for code that one might want to use it's nice to be able to just
> > > browse to a web page and see the documentation in a format you're
> > > already familiar with. That's what Javadoc gives me.
> >
> > That's true, and that is an advantage.
> >
> > > And Javadocs also
> > > add some additional structure, partly thanks to <shudder> static
> > > typing.
>
> do java declarations provide anything which cl declarations do not?
Well, the main thing is they're always there--you always know what
type of arguments a method expects and what type it returns. Also
declarations include information about what exceptions (conditions) a
method may throw.
> > > There's no in-principle reason that Lisp couldn't have such a
> > > system and that it couldn't be even better. But at the moment I think
> > > it's one of Java's strong suits. (I know someone is working on a
> > > Javadoc like tool for CL, Alfred or something but I haven't looked at
> > > it yet.)
> >
> > I was somewhat surprised when I learned that javadoc works on the Java
> > source *text*, and doesn't use their introspection API (doesn't sound
> > like they had much confidence in it, to me).
>
> javadoc predates the introspection api. one might argue that it would make
> sense to switch, but there is a lot of information which a javadoc processor
> extracts form the comments but would it could not derive from the data
> available "introspectively".
Indeed. They are called javadoc "comments" for a reason. What the
javadoc tool does is combine the comments (which have some internal
structure but are otherwise just human readable text) with the
information provided by the mandatory type declarations.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel wrote:
>
> james anderson <··············@setf.de> writes:
>
> ...
> >
> > do java declarations provide anything which cl declarations do not?
>
> Well, the main thing is they're always there--you always know what
> type of arguments a method expects and what type it returns. Also
> declarations include information about what exceptions (conditions) a
> method may throw.
>
fess up now, (and no crossing your fingers): in your expereince, what was the
relative percentage of needing to know the exceptions a given method can raise
a - in order to handle them v/s
b - in order to declare something more sensible than Throwable.
everything else is available in declarations and specializers.
[nb. the former may be another potential reason to implement documentation
generation based on source code analysis rather than introspection.]
> > > > There's no in-principle reason that Lisp couldn't have such a
> > > > system and that it couldn't be even better. But at the moment I think
> > > > it's one of Java's strong suits. (I know someone is working on a
> > > > Javadoc like tool for CL, Alfred or something but I haven't looked at
> > > > it yet.)
> > >
> > > I was somewhat surprised when I learned that javadoc works on the Java
> > > source *text*, and doesn't use their introspection API (doesn't sound
> > > like they had much confidence in it, to me).
> >
> > javadoc predates the introspection api. one might argue that it would make
> > sense to switch, but there is a lot of information which a javadoc processor
> > extracts form the comments but would it could not derive from the data
> > available "introspectively".
>
> Indeed. They are called javadoc "comments" for a reason. What the
> javadoc tool does is combine the comments (which have some internal
> structure but are otherwise just human readable text) with the
> information provided by the mandatory type declarations.
to take my original question another round, is there anything allowed by
javadoc comment which one could not determine through a combination of
introspection and declaration? wrt the core javadoc properties one would need
an additional declaration name for conditions signaled, and, should one feel
possessed to, could do so as well for author and version. given which, any
documentation text could be analysed and marked up dynamically, without the
maintenace overhead which javadoc comments entail. perhaps eclipse has
improved on visual-age, but in my memory comments were an embarassingly poor step-child.
...
james anderson <··············@setf.de> writes:
> Peter Seibel wrote:
> >
> > james anderson <··············@setf.de> writes:
> >
> > ...
> > >
> > > do java declarations provide anything which cl declarations do not?
> >
> > Well, the main thing is they're always there--you always know what
> > type of arguments a method expects and what type it returns. Also
> > declarations include information about what exceptions (conditions) a
> > method may throw.
> >
>
> fess up now, (and no crossing your fingers): in your expereince, what was the
> relative percentage of needing to know the exceptions a given method can raise
> a - in order to handle them v/s
> b - in order to declare something more sensible than Throwable.
50/50 maybe. Hard to say--is catching an exception and then rethrowing
a new exception of a different type handling it? There's a lot of that
because of the need to preserve abstraction boundaries. Exceptions are
definitely part of the public interface of any code that can throw
them, whether or not the language forces you to explicitly handle them
or not.
I much prefer CL conditions exactly because not every intermediate
layer needs to be involved in handling and/or propagating conditions.
However, it is good to have a way (and actually it seems more
important in a system where you *don't* have to do anything explicit
to pass on a condition/exception) to easily find out what conditions
can come percolating up out of the depths of your program. (Other than
inspecting all source code I mean. Especially if you're using third
party libraries.)
> > Indeed. They are called javadoc "comments" for a reason. What the
> > javadoc tool does is combine the comments (which have some
> > internal structure but are otherwise just human readable text)
> > with the information provided by the mandatory type declarations.
>
> to take my original question another round, is there anything
> allowed by javadoc comment which one could not determine through a
> combination of introspection and declaration?
If by introspection you mean the facilities currently provided by
java.lang.reflect.*, the answer is yes. The comments are human
readable text and are neither declarations and nor available via
reflection. Now, you could change the compiler to extract the text in
javadoc comments and put it into the class file and then change the
reflection classes to give you access to that information and then it
would be available via "introspection". But I don't think that's what
you meant, is it?
> wrt the core javadoc properties one would need an additional
> declaration name for conditions signaled, and, should one feel
> possessed to, could do so as well for author and version. given
> which, any documentation text could be analysed and marked up
> dynamically, without the maintenace overhead which javadoc comments
> entail. perhaps eclipse has improved on visual-age, but in my memory
> comments were an embarassingly poor step-child.
No doubt. It's definitely a tricky balancing act. One ideal is to
attach the documentation directly to the elements its documenting so
the docs stay in sync and so you don't have to duplicate information
(such as names) to establish the connections. On the other hand,
putting too much documentation in line obscures the code. Javadoc, for
instance, strikes this balance by requiring method-level comments to
be "attached" to the methods by immediately preceding them. But the
parameters to the method are documented by reference.:
/**
* Compute the factorial of n.
*
* @param n A non-negative integer.
*/
public int factorial(int n) {
if (n == 0) {
return 1;
} else {
return n * factorial(1 - n);
}
}
As opposed to say:
/**
* Compute the factorial of n.
*/
public int factorial(int n /** A non-negative integer.*/) {
if (n == 0) {
return 1;
} else {
return n * factorial(1 - n);
}
}
which saves a bit of duplication at the cost of cluttering up the
actual code. Or they could have gone the other direction and allowed
all the method-level comments to be gather up at the top of the file
like this at the cost of duplicating the whole method signature:
/**
* Compute the factorial of n.
*
* @param n A non-negative integer.
*/
public int factorial(int n);
How exactly to strike the balance depends on what kind of information
you can extract automatically from the code, the syntax of the
language, and what kind of tools folks are going to be using to edit
code.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel wrote:
>
> james anderson <··············@setf.de> writes:
>
> > ...
> >
> > fess up now, (and no crossing your fingers): in your expereince, what was the
> > relative percentage of needing to know the exceptions a given method can raise
> > a - in order to handle them v/s
> > b - in order to declare something more sensible than Throwable.
>
> 50/50 maybe. Hard to say--is catching an exception and then rethrowing
> a new exception of a different type handling it? There's a lot of that
> because of the need to preserve abstraction boundaries.
no waffling. that falls under b. if one could catch interfaces, it might be different.
> Exceptions are
> definitely part of the public interface of any code that can throw
> them, whether or not the language forces you to explicitly handle them
> or not.
>
>...
>
> > > Indeed. They are called javadoc "comments" for a reason. What the
> > > javadoc tool does is combine the comments (which have some
> > > internal structure but are otherwise just human readable text)
> > > with the information provided by the mandatory type declarations.
> >
> > to take my original question another round, is there anything
> > allowed by javadoc comment which one could not determine through a
> > combination of introspection and declaration?
>
> If by introspection you mean the facilities currently provided by
> java.lang.reflect.*, the answer is yes.
you're looking the wrong way.
> The comments are human
> readable text and are neither declarations and nor available via
> reflection. Now, you could change the compiler to extract the text in
> javadoc comments and put it into the class file and then change the
> reflection classes to give you access to that information and then it
> would be available via "introspection". But I don't think that's what
> you meant, is it?
you're right, it was not.
but for the adminstrative javadoc properties, one could match them in a cl ide
through a combination of source code inspection and introspection. as in the
following paragraph:
>
> > wrt the core javadoc properties one would need an additional
> > declaration name for conditions signaled, and, should one feel
> > possessed to, could do so as well for author and version. given
> > which, any documentation text could be analysed and marked up
> > dynamically, without the maintenace overhead which javadoc comments
> > entail. perhaps eclipse has improved on visual-age, but in my memory
> > comments were an embarassingly poor step-child.
>
> No doubt. It's definitely a tricky balancing act. One ideal is to
> attach the documentation directly to the elements its documenting so
> the docs stay in sync and so you don't have to duplicate information
> (such as names) to establish the connections. On the other hand,
> putting too much documentation in line obscures the code. Javadoc, for
> instance, strikes this balance by requiring method-level comments to
> be "attached" to the methods by immediately preceding them. But the
> parameters to the method are documented by reference.:
>
another alternative is to believe what the source says and use that to augment
what the comment says.
[ various examples ... ]
whatever variations one might propose, it remains that the javadoc process
requires the author to duplicate specifcations, despite that the redundant
information could be inferred from the source.
...
james anderson <··············@setf.de> writes:
> Peter Seibel wrote:
> >
> > james anderson <··············@setf.de> writes:
> >
> > > ...
> > >
> > > fess up now, (and no crossing your fingers): in your expereince,
> > > what was the relative percentage of needing to know the
> > > exceptions a given method can raise
> > > a - in order to handle them v/s
> > > b - in order to declare something more sensible than Throwable.
> >
> > 50/50 maybe. Hard to say--is catching an exception and then
> > rethrowing a new exception of a different type handling it?
> > There's a lot of that because of the need to preserve abstraction
> > boundaries.
>
> no waffling. that falls under b. if one could catch interfaces, it
> might be different.
Sorry man, I didn't know there was going to be a quiz. I don't have
exact statistics available. Oh, wait, here they are: 50.0000000% of
the time it was a and 50.0000000% it was b. Happy?
> but for the adminstrative javadoc properties, one could match them
> in a cl ide through a combination of source code inspection and
> introspection. as in the following paragraph:
Yes. Indeed. If you're defining "aadministrative javadoc proprerties"
to include any the things that are derived from the source code in
Java that's almost a tautology. I'm not sure what your point is.
> > > wrt the core javadoc properties one would need an additional
> > > declaration name for conditions signaled, and, should one feel
> > > possessed to, could do so as well for author and version. given
> > > which, any documentation text could be analysed and marked up
> > > dynamically, without the maintenace overhead which javadoc
> > > comments entail. perhaps eclipse has improved on visual-age, but
> > > in my memory comments were an embarassingly poor step-child.
> >
> > No doubt. It's definitely a tricky balancing act. One ideal is to
> > attach the documentation directly to the elements its documenting
> > so the docs stay in sync and so you don't have to duplicate
> > information (such as names) to establish the connections. On the
> > other hand, putting too much documentation in line obscures the
> > code. Javadoc, for instance, strikes this balance by requiring
> > method-level comments to be "attached" to the methods by
> > immediately preceding them. But the parameters to the method are
> > documented by reference.:
> >
>
> another alternative is to believe what the source says and use that
> to augment what the comment says.
>
> [ various examples ... ]
>
> whatever variations one might propose, it remains that the javadoc
> process requires the author to duplicate specifcations, despite that
> the redundant information could be inferred from the source.
Okay. So I guess I should delete the Hyperspec from my hard drive, and
burn this shelf full of Lisp books I have (to say nothing of the one
I'm *writing*) since I *already* have the source code to a Common Lisp
implementation. What do I need documentation for if I have source code
that is a much more precise specification of what really happens
anyway.
You do realize that the "doc" in Javadoc stands for *documentation*
don't you?
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel wrote:
> Okay, if I understand you correctly you're using "jargon" here in the
> non-pejorative sense.
jargon
1. [n] specialized technical terminology characteristic of a particular
subject
Good. In other words "reuse" is a term of art
> that I am using incorrectly, using my own naively constructed meaning
> of "I use it once; I use it again; I've reused it." That fine.
Check.
Maybe
> I'm just dense then but I haven't been able to understand what the
> "very definite meaning" of reuse as a term of art is.
At various points you /have/ in fact gotten it and denounced the idea of
reusable classes as "pie in the sky so forget it". So you are not dense,
you just have a short memory.
All I was doing was suggesting that reuse is not after all pie in the
sky, that it has not been achieved too date because we ask too much of
objects--implementation as well as structure--and that OO does not have
to be that way. Tis being the reponse to Javans outraged at CLOS classes
not owning member functions.
Examples of reuse with Cells? I have not been sufficiently encouraged by
your receptiveness to undertake the effort, but I could do no better
anyway than the analogy of slots as functions to arguments as functions,
which should get through to anyone who groks FIND-IF. All I will say is
that my claim of greater re-use with Cells comes after the fact: i did
not set out to achieve re-use, I just noticed it.
I noticed that I no longer define new classes to handle new requirments.
So much can be expressed in cell rules that a relatively low-level layer
of classes are sufficient to support all new requirements. Sure, for a
while new requirements demand new parameters in the form of new slots.
But the endless subclassing experienced by other OO developers does not
arise. At some point all the parameters demanded have been unearthed.
The endless variety of applications then is achieved by authoring those
slots with functional values. These functions can be arbitrary code, so
their semantics are unlimited. The only thing constrained is the
expression of those semantics, because a slot called 'frame-border'
knows what it has to do.
And it turns out (I guess!) that the hard part in reuse is not that
frame-border needs a kazillion modes of expression, rather that its
derivation cannot be reduced to a hard-coded member function over a few
literal parameters (the best standard OO can do). Functional
parameters (slots efficiently envalued by cell rules of arbitrary Lisp
code) do the trick.
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
> Peter Seibel wrote:
> > Okay, if I understand you correctly you're using "jargon" here in the
> > non-pejorative sense.
>
> jargon
> 1. [n] specialized technical terminology characteristic of a
> particular subject
>
> Good. In other words "reuse" is a term of art
> > that I am using incorrectly, using my own naively constructed meaning
> > of "I use it once; I use it again; I've reused it." That fine.
>
> Check.
>
> Maybe
> > I'm just dense then but I haven't been able to understand what the
> > "very definite meaning" of reuse as a term of art is.
>
> At various points you /have/ in fact gotten it and denounced the idea
> of reusable classes as "pie in the sky so forget it". So you are not
> dense, you just have a short memory.
Hmmm. I thought I was the one *defending* reusable classes. Maybe
we're reading too much into what each other is saying. I thought *you*
were the one holding up particular examples and saying, see this is
pie in the sky; this can never work. I was just saying, fine if you
think that's pie in the sky, here's an actual example. But then you
always told me my concrete examples weren't *really* reuse.
> All I was doing was suggesting that reuse is not after all pie in the
> sky, that it has not been achieved too date because we ask too much of
> objects--implementation as well as structure--and that OO does not
> have to be that way. Tis being the reponse to Javans outraged at CLOS
> classes not owning member functions.
And I still don't understand why you say it has not be achived to
date; why the examples I've given aren't *really* reuse. Unless you
agree with the definition Thomas gave elsewhere in this thread--that
for reuse to be real it must be purely serendipitous: i.e. I write
some classes and then discover that they are usable in new contexts
with out modification and without any previous attention paid to how
they might be reused. If that's the definition then the examples of
Servlets and JDBC fail the "reuse" test because they were actually
"designed" to be used in multiple applications. If you have some
*other* reason for disquallifying them as actual "reuse" I'm still
curious to understand it better. But I also understand if you want to
just write off this conversation as a loss--it doesn't seem that we're
getting any closer to understanding each other, let alone agreeing on
much of anything.
> Examples of reuse with Cells? I have not been sufficiently encouraged
> by your receptiveness to undertake the effort, but I could do no
> better anyway than the analogy of slots as functions to arguments as
> functions, which should get through to anyone who groks FIND-IF. All I
> will say is that my claim of greater re-use with Cells comes after the
> fact: i did not set out to achieve re-use, I just noticed it.
Is it the reuse of all of Cells the framework or is there some smaller
unit of code that you develop within the context of cells which can
then be reused.
> I noticed that I no longer define new classes to handle new
> requirments. So much can be expressed in cell rules that a
> relatively low-level layer of classes are sufficient to support all
> new requirements. Sure, for a while new requirements demand new
> parameters in the form of new slots. But the endless subclassing
> experienced by other OO developers does not arise.
Hmmm. Endless subclassing does not describe my experience of
class-based OO design done right. YMMV.
> At some point all the parameters demanded have been unearthed. The
> endless variety of applications then is achieved by authoring those
> slots with functional values. These functions can be arbitrary code,
> so their semantics are unlimited. The only thing constrained is the
> expression of those semantics, because a slot called 'frame-border'
> knows what it has to do.
>
> And it turns out (I guess!) that the hard part in reuse is not that
> frame-border needs a kazillion modes of expression, rather that its
> derivation cannot be reduced to a hard-coded member function over a
> few literal parameters (the best standard OO can do).
Again, that doesn't describe my experience with Java.
> Functional parameters (slots efficiently envalued by cell rules of
> arbitrary Lisp code) do the trick.
And in Java functional parameters are expressed using interfaces. And
objects can have fields which hold instances of some interfaces. Which
given that that's the way callbacks, etc. are implemented in Java,
seems at least analagous. Which is not to say that Cells or even plain
old Common Lisp isn't miles ahead of the best Java can offer but--and
this is the reason I've persisted in this thread for so long--I think
we'll have more success explaining to non-Lispers why Lisp rocks if we
can avoid saying things about the languages they happen to be using
that are a total mismatch to their own exprience using those
languages. Someday--maybe when I have a chance to actually look at
Cells for real--the scales will fall from my eyes and I'll realize
there are who worlds of reusability and programming flexibility that I
haven't even been able to imagine. But until then let me just note
that speaking as someone who's done a lot of real Java programming,
your explanations of what is and isn't easy or possible in Java miss
the mark and I suspect they won't play well if you try to use them to
evangelize Lisp to Javanians. Of course how you choose to evangelize
Lisp is your business; just some commentary from the peanut gallery.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel wrote:
> And I still don't understand why you say it has not be achived to
> date; why the examples I've given aren't *really* reuse. Unless you
> agree with the definition Thomas gave elsewhere ...
Sorry, yes, I would have shouted out an "Amen!" and a couple of "Tell
it, Brother!"s, or even a nicely understated "word", but I did not want
to give away that we are working in concert.
in this thread--that
> for reuse to be real it must be purely serendipitous: i.e. I write
> some classes and then discover that they are usable in new contexts
> with out modification and without any previous attention paid to how
> they might be reused. If that's the definition then the examples of
> Servlets and JDBC fail the "reuse" test because they were actually
> "designed" to be used in multiple applications.
Right, except for the "purely serendipitous" and "without
modifification" straw persons. As for the straw thing "without any
previous attention to how they might be reused", the more a model
abstractly resembles the modelled, the more likely unanticipated but
good-faith variations on the modelled will be readily modellable with
the model.
Here is a nice acid test, one which nicely brings us back into the
context of language comparison: what is it about the Java OO-model that
makes Servlet work where C++ would not work?
Here's a Sun link bragging about re-use in Java:
http://java.sun.com/features/1997/may/reuse.html
They talk about standardizing interfaces (that would work in assembly
language, yes?) and careful factoring of code to find re-useable stuff
(still works in assembly language).
Other searches on Java and re-use talk about creating repositories of
reusable classes. ie, leverage the effort of identifying clean, reusable
classes by making it possible for others to find them by a simple
keyword search. "Hey! This sounds like it does what I want!"
That Java link also talks about re-use meaning different things to
different people. Tell me about it. :) The definition Thomas and I are
talking about was the Grail: a growing, permanent asset of standard
objects which Pat Developer would assemble into some new application.
Those classes would work not because Pat was interfacing to the same
piece of software or same spec as that for which the classes were
developed, but because the domain being modelled was the same, and --
here comes the whole point -- any variations required could be achieved
by overriding or extending the details of some reusable object.
And at last we are able to get back on topic: how do different OO models
rank in re flexibility and extensibility, such that a near-miss class
can still be reused because a subclass can be more or less easily
tailored to the specifics of the current application.
Standardizing APIs, insane mathematical analysis to find abstractions,
teams working on repositories--those do not mean /OO models/ support
reuse, those are reactions to the un-reusability of OO models.
That URL above to the Sun reuse hype goes on for quite a while. I was
only skimming, but I did not see any explanation of how the Java OO
model was better at reuse. They did claim Java was better than C++, but
they did not deign to explain how.
Again, don't get me wrong: given the failure of reusable OO models
tightly bound to implementation, standardizing libraries is a good idea.
By throwing resources into building standards and supporting libraries,
they can win share by making development easier.
But the subject is programming language comparison, not Java vs .net.
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
> Peter Seibel wrote:
>
> > And I still don't understand why you say it has not be achived to
> > date; why the examples I've given aren't *really* reuse. Unless you
> > agree with the definition Thomas gave elsewhere ...
>
> Sorry, yes, I would have shouted out an "Amen!" and a couple of "Tell
> it, Brother!"s, or even a nicely understated "word", but I did not
> want to give away that we are working in concert.
Okay, cool.
> in this thread--that
> > for reuse to be real it must be purely serendipitous: i.e. I write
> > some classes and then discover that they are usable in new contexts
> > with out modification and without any previous attention paid to how
> > they might be reused. If that's the definition then the examples of
> > Servlets and JDBC fail the "reuse" test because they were actually
> > "designed" to be used in multiple applications.
>
> Right, except for the "purely serendipitous" and "without
> modifification" straw persons. As for the straw thing "without any
> previous attention to how they might be reused", the more a model
> abstractly resembles the modelled, the more likely unanticipated but
> good-faith variations on the modelled will be readily modellable with
> the model.
>
> Here is a nice acid test, one which nicely brings us back into the
> context of language comparison: what is it about the Java OO-model
> that makes Servlet work where C++ would not work?
So if that's an acid test for whether something is "reuse", does that
mean that a priori anything that can be done in C++ can't possibly
deserve the term reuse. I'm not a big C++ fan but that seems a bit
biased.
> Here's a Sun link bragging about re-use in Java:
>
> http://java.sun.com/features/1997/may/reuse.html
>
> They talk about standardizing interfaces (that would work in
> assembly language, yes?)
Well, "interfaces" means something specific in Java (as you may well
know). C++ programmers could get the benefits of interfaces using pure
virtual base classes (or whatever they're called) but interfaces,
perhaps simply because they are a different thing than classes in the
language, seem to get used more often in Java than pure virtual base
classes in C++. And that leads to more code that can potentially be
used in different contexts. Yes you *can* do it in assembly but
there's also nothing you can do in Cells that you can't do in assembly
so I'm not sure what that argument buys you.
> and careful factoring of code to find re-useable stuff (still works
> in assembly language).
Yes, but again Turing equivalence seems like a non-starter in these
kinds of discussions.
> Other searches on Java and re-use talk about creating repositories
> of reusable classes. ie, leverage the effort of identifying clean,
> reusable classes by making it possible for others to find them by a
> simple keyword search. "Hey! This sounds like it does what I want!"
>
> That Java link also talks about re-use meaning different things to
> different people. Tell me about it. :) The definition Thomas and I
> are talking about was the Grail: a growing, permanent asset of
> standard objects which Pat Developer would assemble into some new
> application.
And I'm *telling* you that Joe Java Developer does experience that--in
any given app they write, many more of the classes Joe uses will
likely be written by someone else than by Joe himself. So if you tell
Joe that "OO totally failed to deliver reuse" or whatever it was
Thomas said originally, Joe Java Developer is going to think you're a
crank.
> Those classes would work not because Pat was interfacing to the same
> piece of software or same spec as that for which the classes were
> developed, but because the domain being modelled was the same, and
> -- here comes the whole point -- any variations required could be
> achieved by overriding or extending the details of some reusable
> object.
And in certain domains that happens in Java. Not all domains. And it
does take forethought to design classes and interfaces that are usable
in many contexts but it happens. That's all I'm trying to say.
> And at last we are able to get back on topic: how do different OO
> models rank in re flexibility and extensibility, such that a
> near-miss class can still be reused because a subclass can be more
> or less easily tailored to the specifics of the current application.
>
> Standardizing APIs, insane mathematical analysis to find abstractions,
> teams working on repositories--those do not mean /OO models/ support
> reuse, those are reactions to the un-reusability of OO models.
>
> That URL above to the Sun reuse hype goes on for quite a while. I was
> only skimming, but I did not see any explanation of how the Java OO
> model was better at reuse. They did claim Java was better than C++,
> but they did not deign to explain how.
Bigger standard library. Run-time linking. Standard documentation
format. Interfaces as a primary language construct. Garbage
collection. Safer language (arrays bounds checked). All of those
things make it easier to stitch together code from diverse sources
into a single application. Of course Lisp has many of these features
too and many more besides. I'm not saying Java is better than Lisp.
I'm just saying that you underestimate how much reuse goes on in the
Java world. But I don't know how to convince you other than forcing
you to work as a Java programmer for several years and I wouldn't wish
that on anyone who could be doing Lisp instead.
> Again, don't get me wrong: given the failure of reusable OO models
> tightly bound to implementation, standardizing libraries is a good
> idea. By throwing resources into building standards and supporting
> libraries, they can win share by making development easier.
Well, the reason that interfaces (in the Java sense) are so important
is that they allow you to build models that aren't "tightly bound to
implementation".
> But the subject is programming language comparison, not Java vs .net.
Sure. And I'm just trying to provide some actual data about how Java
works that you seem to have missed. But I think we may just have to
agree to disagree on this one; I think I now understand what you mean
by reuse and I simply disagree with your contention that it never
happens in Java. And I don't even *like* Java. Jeesh.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>>Here is a nice acid test, one which nicely brings us back into the
>>context of language comparison: what is it about the Java OO-model
>>that makes Servlet work where C++ would not work?
>
>
> So if that's an acid test for whether something is "reuse", does that
> mean that a priori anything that can be done in C++ can't possibly
> deserve the term reuse. I'm not a big C++ fan but that seems a bit
> biased.
You misunderstood. That was just a "fer instance", showing how the topic
might be kept focused on language comparison and away from how much
money has been poured into developing nifty class libraries.
Let's try again. Suppose my brother the ecologist wants to develop some
software to help him analyze the wetlands projects he undertakes.
Suppose further that neither Sun nor anyone else has seen fit to pour
millions of dollars of development into building a killer core class
hierarchy dedicated to the subject.
Out on the Web he surfs, and finds open-source ecosystem software
developed by a university professor here, an EPA reseracher there, a
wetlands consultant... one in Java, one in C++, one in CLOS. Suppose
everyone did their best to design well, each wants their open-source
project to get joined by others so they made a good-faith effort at
avoiding assumptions, parameterizing wherever they thought it made
sense, and let's say they were all fairly adept at this task of making
classes reusable.
Now he sits down to study the class libraries, all of which offer about
the same amount of "free lunch", in the form of capabilities already
offered. And of course, he finds himself screwing up his forehead over
stuff that just does not make sense for his requirements, but the number
and quality of mismatches seems about even--all three miss the mark by
what feels like the same amount.
Now we can ask, is there any difference in how malleable the frameworks
will prove to be as he tries to shape his application in their form? And
is it a boon or bust that CLOS GFs do not belong to classes? Now we can
talk about GFs vs member functions, and MI vs interfaces, and now we are
talking about reuse.
As for Sun, surfing on java and reuse I found them claiming to have
achieved the Holy Grail of reuse as early as 1997. Funny, still no
mention of the features of the Java OO model which are so much better
that Java OO reuse succeeded where everyone else failed (by community
consensus if you just surf on reuse and hype.
As for an example of cells, I have a stack class which expects (in
classic OO form) justification options :left, :center, or :right. But it
first honors an instance's wishes if it specifies its horizontal
positioning. So I can have a stack where the left edge of the items
forms a sine curve with a 96 pixel amplitude:
(make-instance 'IXStack
:kids (c? (mapcar
(lambda (kid-value)
(make-instance (you-decide kid-value)
:mdvalue kid-value
:left (c? (* 96 (sin (* (kid-no self) 0.1 pi)))
(kid-values self))))
Like I said, the same benefit as (find-if (lambda (it)...) stuff)
applied to customizing instances so as to make classes more reusable.
kt
>
>
>>Here's a Sun link bragging about re-use in Java:
>>
>> http://java.sun.com/features/1997/may/reuse.html
>>
>>They talk about standardizing interfaces (that would work in
>>assembly language, yes?)
>
>
> Well, "interfaces" means something specific in Java (as you may well
> know). C++ programmers could get the benefits of interfaces using pure
> virtual base classes (or whatever they're called) but interfaces,
> perhaps simply because they are a different thing than classes in the
> language, seem to get used more often in Java than pure virtual base
> classes in C++. And that leads to more code that can potentially be
> used in different contexts. Yes you *can* do it in assembly but
> there's also nothing you can do in Cells that you can't do in assembly
> so I'm not sure what that argument buys you.
>
>
>>and careful factoring of code to find re-useable stuff (still works
>>in assembly language).
>
>
> Yes, but again Turing equivalence seems like a non-starter in these
> kinds of discussions.
>
>
>>Other searches on Java and re-use talk about creating repositories
>>of reusable classes. ie, leverage the effort of identifying clean,
>>reusable classes by making it possible for others to find them by a
>>simple keyword search. "Hey! This sounds like it does what I want!"
>>
>>That Java link also talks about re-use meaning different things to
>>different people. Tell me about it. :) The definition Thomas and I
>>are talking about was the Grail: a growing, permanent asset of
>>standard objects which Pat Developer would assemble into some new
>>application.
>
>
> And I'm *telling* you that Joe Java Developer does experience that--in
> any given app they write, many more of the classes Joe uses will
> likely be written by someone else than by Joe himself. So if you tell
> Joe that "OO totally failed to deliver reuse" or whatever it was
> Thomas said originally, Joe Java Developer is going to think you're a
> crank.
>
>
>>Those classes would work not because Pat was interfacing to the same
>>piece of software or same spec as that for which the classes were
>>developed, but because the domain being modelled was the same, and
>>-- here comes the whole point -- any variations required could be
>>achieved by overriding or extending the details of some reusable
>>object.
>
>
> And in certain domains that happens in Java. Not all domains. And it
> does take forethought to design classes and interfaces that are usable
> in many contexts but it happens. That's all I'm trying to say.
>
>
>>And at last we are able to get back on topic: how do different OO
>>models rank in re flexibility and extensibility, such that a
>>near-miss class can still be reused because a subclass can be more
>>or less easily tailored to the specifics of the current application.
>>
>>Standardizing APIs, insane mathematical analysis to find abstractions,
>>teams working on repositories--those do not mean /OO models/ support
>>reuse, those are reactions to the un-reusability of OO models.
>>
>>That URL above to the Sun reuse hype goes on for quite a while. I was
>>only skimming, but I did not see any explanation of how the Java OO
>>model was better at reuse. They did claim Java was better than C++,
>>but they did not deign to explain how.
>
>
> Bigger standard library. Run-time linking. Standard documentation
> format. Interfaces as a primary language construct. Garbage
> collection. Safer language (arrays bounds checked). All of those
> things make it easier to stitch together code from diverse sources
> into a single application. Of course Lisp has many of these features
> too and many more besides. I'm not saying Java is better than Lisp.
> I'm just saying that you underestimate how much reuse goes on in the
> Java world. But I don't know how to convince you other than forcing
> you to work as a Java programmer for several years and I wouldn't wish
> that on anyone who could be doing Lisp instead.
>
>
>>Again, don't get me wrong: given the failure of reusable OO models
>>tightly bound to implementation, standardizing libraries is a good
>>idea. By throwing resources into building standards and supporting
>>libraries, they can win share by making development easier.
>
>
> Well, the reason that interfaces (in the Java sense) are so important
> is that they allow you to build models that aren't "tightly bound to
> implementation".
>
>
>>But the subject is programming language comparison, not Java vs .net.
>
>
> Sure. And I'm just trying to provide some actual data about how Java
> works that you seem to have missed. But I think we may just have to
> agree to disagree on this one; I think I now understand what you mean
> by reuse and I simply disagree with your contention that it never
> happens in Java. And I don't even *like* Java. Jeesh.
>
> -Peter
>
>
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
> Now we can ask, is there any difference in how malleable the
> frameworks will prove to be as he tries to shape his application in
> their form? And is it a boon or bust that CLOS GFs do not belong to
> classes? Now we can talk about GFs vs member functions, and MI vs
> interfaces, and now we are talking about reuse.
Okay. I agree that's that's an interesting question. Just so long you
understand that you haven't given me (and I'm a pretty sympathetic
audience given my own interest in Lisp) any reason to belive that the
answer is a slam dunk that GF's somehow make the CLOS framework more
likely to be actually reusable than the Java framework. There may well
be reasons but you haven't articulated them in a way that makes any
sense to me. Which is, no doubt, due to my own lack of understanding
and thus my loss. My only point is you should think twice before
trying this line of argumentation on a "real" Java programmer.
> As for Sun, surfing on java and reuse I found them claiming to have
> achieved the Holy Grail of reuse as early as 1997. Funny, still no
> mention of the features of the Java OO model which are so much better
> that Java OO reuse succeeded where everyone else failed (by community
> consensus if you just surf on reuse and hype.
Gee, I thought I gave you a list last time. With the caveat that this
list only addresses Java's advantages over C++ (which is presumably
what the Sun hypesters were talking about) here it is again:
- Bigger standard library. (Than C++)
- Run-time linking.
- Standard documentation format.
- Interfaces as a primary language construct.
- Garbage collection.
- Safer language (arrays bounds checked) (again, compared to C++)
> As for an example of cells, I have a stack class which expects (in
> classic OO form) justification options :left, :center, or :right. But
> it first honors an instance's wishes if it specifies its horizontal
> positioning. So I can have a stack where the left edge of the items
> forms a sine curve with a 96 pixel amplitude:
Okay, now I'm curious--what kind of stack is this? When I hear stack I
think push/pop--presumably you're talking about something else.
> (make-instance 'IXStack
> :kids (c? (mapcar
> (lambda (kid-value)
> (make-instance (you-decide kid-value)
> :mdvalue kid-value
> :left (c? (* 96 (sin (* (kid-no self) 0.1 pi)))
> (kid-values self))))
>
> Like I said, the same benefit as (find-if (lambda (it)...) stuff)
> applied to customizing instances so as to make classes more reusable.
And the c? means, if IIRC, make a cell which is a live bit of code or
something. I'm not quite sure I understand what this code does. If you
still care, to I'd love te hear a few more words about what this
actually does. But if not, we can leave it there--I have no doubt that
having pluggable functionality is all good stuff.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>Now we can ask, is there any difference in how malleable the
>>frameworks will prove to be as he tries to shape his application in
>>their form? And is it a boon or bust that CLOS GFs do not belong to
>>classes? Now we can talk about GFs vs member functions, and MI vs
>>interfaces, and now we are talking about reuse.
>
>
> Okay. I agree that's that's an interesting question. Just so long you
> understand that you haven't given me (and I'm a pretty sympathetic
> audience given my own interest in Lisp) any reason to belive that the
> answer is a slam dunk that GF's somehow make the CLOS framework more
> likely to be actually reusable ...
Well, no, of course not, so far we have just been trying to ge clear
what we are talking about. And doing so has been much more entertaining
than discussing OO models. :)
>>As for Sun, surfing on java and reuse I found them claiming to have
>>achieved the Holy Grail of reuse as early as 1997. Funny, still no
>>mention of the features of the Java OO model which are so much better
>>that Java OO reuse succeeded where everyone else failed (by community
>>consensus if you just surf on reuse and hype.
>
>
> Gee, I thought I gave you a list last time.
Right, that's you, and those were noted. My point was that i am pointing
to a programming twist (member functions vs GFs vs Cells) in discussing
reusability. Something achieved at the language level can be expected to
scale, because Billy Bob's Ecosystem Hierarchy will be reusable if he
takes a little care with it. He won't need MegaCorp to put its stamp of
approval on it so that people simply don't use anything else and then
Eureka! It's reusable! It will just really be reusable in the Grail
sense. This Sun sense of reusability works exactly where they or some
other 600lb Gorilla decides to build a library. Useful, but not
interesting in a programming language comparison course (unless it is at
a business school).
With the caveat that this
> list only addresses Java's advantages over C++ (which is presumably
> what the Sun hypesters were talking about) here it is again:
>
> - Bigger standard library. (Than C++)
> - Run-time linking.
> - Standard documentation format.
> - Interfaces as a primary language construct.
> - Garbage collection.
> - Safer language (arrays bounds checked) (again, compared to C++)
Of course there is not much there about the pros and cons of member
functions because the two targets agree. So you think interfaces are
better than multiple inheritance?
>
>
>>As for an example of cells, I have a stack class which expects (in
>>classic OO form) justification options :left, :center, or :right. But
>>it first honors an instance's wishes if it specifies its horizontal
>>positioning. So I can have a stack where the left edge of the items
>>forms a sine curve with a 96 pixel amplitude:
>
>
> Okay, now I'm curious--what kind of stack is this? When I hear stack I
> think push/pop--presumably you're talking about something else.
yeah, sorry, view widget which takes care of positioning subviews one
below the prior, and aligning them horizontally in ordinary ways unless
a widget insists on some other horizontal position.
>
>
>>(make-instance 'IXStack
>> :kids (c? (mapcar
>> (lambda (kid-value)
>> (make-instance (you-decide kid-value)
>> :mdvalue kid-value
>> :left (c? (* 96 (sin (* (kid-no self) 0.1 pi)))
kid-no returns the zero-based position of each kid, so the left edges of
the kids will cycle over ten kids from zero to 96 and back to zero over
the course of..uh-oh, looks like an amplitude of 192 if we continue on
to twenty kids as we swing from 0 to 96 to -96 to 0 (and if the stack
widget specifies :clipped t (the default) we're in deep trouble).
>> (kid-values self))))
>>
>>Like I said, the same benefit as (find-if (lambda (it)...) stuff)
>>applied to customizing instances so as to make classes more reusable.
>
>
> And the c? means, if IIRC, make a cell which is a live bit of code or
> something. I'm not quite sure I understand what this code does. If you
> still care, to I'd love te hear a few more words about what this
> actually does.
It creates a visual
"stack
where
the
left
edge
of
the
items
forms
a
sine
curve
with
a
96
pixel
amplitude".
less concretely: the kid class is determined by the you-decide GF, and
each kid gets a different :value which can guide its construction and
behavior as other rules (based on the kid's class) look to that value
for guidance. This will include potentially different interface
structure since, as seen above, the kids slot itself can be determined
by a rule.
This made it real easy to build an object inspector in Cello, since
introspection lets me determine the slots of a class of an instance at
runtime (and the values in those slots).
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
> My point was that i am pointing to a programming twist (member
> functions vs GFs vs Cells) in discussing reusability. Something
> achieved at the language level can be expected to scale, because
> Billy Bob's Ecosystem Hierarchy will be reusable if he takes a
> little care with it. He won't need MegaCorp to put its stamp of
> approval on it so that people simply don't use anything else and
> then Eureka! It's reusable! It will just really be reusable in the
> Grail sense. This Sun sense of reusability works exactly where they
> or some other 600lb Gorilla decides to build a library.
That's where I think we fundamentally disagree. It doesn't require
MegaCorp's imprimatur. Lot's of good Java libraries come from open
source groups (e.g. Apache's Jakarta) and are developed within an
organization. Again, I'm not saying Java's particular features are the
be all and end all of resue-enabling features. But I *do* think *you*
underestimate them. I know you've mentioned trying (and succeeding?)
in porting Cells to Java. Have you used Java in anger other than that?
Just curious.
> Of course there is not much there about the pros and cons of member
> functions because the two targets agree. So you think interfaces are
> better than multiple inheritance?
Frankly, I'm not sure. I'm not a big fan of inheritance generally so I
don't get all goose-pimply at the thought of having *more* of it. But
it certainly seems that there's no harm in CL-style MI and I can see
places it can be useful. But I do miss interfaces a bit--I'm not sure
what they mean without static checking but they do provide a very good
way to *express* protocols. Or at least large parts of protocols.
Which seems to me central to making well factored code. A set of
mutually dependent GFs and default methods provide the same thing but
it's harder to figure out how the fit together. And the more flexible
(and thus reusable it is) the harder it is to find your way through
the maze. At least that's been my experience with things like the MOP.
But I suspect that's approaching the limit of protocol complexity. At
least I hope it is, or I'm too dumb for this stuff.
> >>As for an example of cells, I have a stack class which expects (in
> >>classic OO form) justification options :left, :center, or :right. But
> >>it first honors an instance's wishes if it specifies its horizontal
> >>positioning. So I can have a stack where the left edge of the items
> >>forms a sine curve with a 96 pixel amplitude:
> > Okay, now I'm curious--what kind of stack is this? When I hear stack
> > I
> > think push/pop--presumably you're talking about something else.
>
> yeah, sorry, view widget which takes care of positioning subviews
> one below the prior, and aligning them horizontally in ordinary ways
> unless a widget insists on some other horizontal position.
Okay. So Cells makes it easy for you to define the protocol between
the stack and its children by which they collectively determine where
each kid is positioned in the horizontal plane. Which seems like good
factoring given that the purpose of the stack is really to control the
vertical positioning. (I.e. if it didn't do that it wouldn't *be* a
stack at all.) So you may or may not believe me when I tell you that
Java programmers find ways to define similar protocols.
Again, I'm happy to believe that Cells (knowing only that it's based
on Common Lisp) makes it easier to define protocols and thus
encourages the development of more flexible protocols than are
typically used in Java where the sheer amount of keyboarding required
to do anything eventually breaks everyone's spirit. And I can believe
that in the end that will lead to more actual code reuse. Cool. I
never disputed that.
I am curious how you organize your Cells libraries (or whatever the
unit of distribution is) so they're easy for folks to find--suppose I
drank the kool-aid and became a full-time Cells programmer. How do I
find all this reusable code whether written by you or my buddy two
cubes down? Because I do agree with Gabriel that often *that's* the
real impediment to reuse.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel <·····@javamonkey.com> writes:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> > My point was that i am pointing to a programming twist (member
> > functions vs GFs vs Cells) in discussing reusability. Something
> > achieved at the language level can be expected to scale, because
> > Billy Bob's Ecosystem Hierarchy will be reusable if he takes a
> > little care with it. He won't need MegaCorp to put its stamp of
> > approval on it so that people simply don't use anything else and
> > then Eureka! It's reusable! It will just really be reusable in the
> > Grail sense. This Sun sense of reusability works exactly where they
> > or some other 600lb Gorilla decides to build a library.
>
> That's where I think we fundamentally disagree. It doesn't require
> MegaCorp's imprimatur. Lot's of good Java libraries come from open
> source groups (e.g. Apache's Jakarta) and are developed within an
> organization.
"Within an organization", "open source /group/", and "Billy Bob" --
one of this things is not like the other.
> Again, I'm not saying Java's particular features are the
> be all and end all of resue-enabling features. But I *do* think *you*
> underestimate them. I know you've mentioned trying (and succeeding?)
> in porting Cells to Java. Have you used Java in anger other than that?
> Just curious.
Having now done a bit of reading, and asked around a bit, it sounds
like Sun carefully got the reuse jargon out of the Java community.
Java is a great platform for exchanging carefully constructed
libraries. Reuse is something that comes about naturally as the
result of a good programmer using a certain methodology. I've made
three serious forays into Java (ouch, my hands!) and never experienced
anything close to reuse. It's great for packaging up code and sharing
it, but that's different. When I was working with Common Lisp and KR,
I felt like I was flirting with the right thing -- there were lots of
times when I discovered that just making an instance from an existing
prototype, providing a couple new o-formula slots (like Cells, their
values are calculated via arbitrary CL code). Actually, C++ with
garbage collection came close to feeling like it was on the right
path. You can *almost* make mixin classes correctly, but not quite.
So you've got these mixins that you can't quite use right, getting in
the way.
> > Of course there is not much there about the pros and cons of member
> > functions because the two targets agree. So you think interfaces are
> > better than multiple inheritance?
>
> Frankly, I'm not sure. I'm not a big fan of inheritance generally so I
> don't get all goose-pimply at the thought of having *more* of it. But
> it certainly seems that there's no harm in CL-style MI and I can see
> places it can be useful. But I do miss interfaces a bit--I'm not sure
> what they mean without static checking but they do provide a very good
> way to *express* protocols. Or at least large parts of protocols.
> Which seems to me central to making well factored code.
But what do they give you that an abstract mixin doesn't? I think I
(sometimes) use mixins the way Javains use protocols. I do something
like:
(defclass foo-abstract-mixin ...)
(defgeneric foo (... x ...))
...
(defclass foo-mixin (foo-abstract-mixin) ...)
(defmethod foo (... (x foo-mixin) ...) ; method on foo-default-mixin
If you inheit from foo-abstract-mixin, that's more or less the same
thing as a protocol. I almost always inherit from foo-mixin, though,
because it's almost never the case that the default behavior doesn't
apply at all (ie, I override all the methods).
> A set of
> mutually dependent GFs and default methods provide the same thing but
> it's harder to figure out how the fit together. And the more flexible
> (and thus reusable it is) the harder it is to find your way through
> the maze. At least that's been my experience with things like the MOP.
> But I suspect that's approaching the limit of protocol complexity. At
> least I hope it is, or I'm too dumb for this stuff.
Figuring out how they all fit together is trivial if you use the
proper browsers. Go *click*, and you're done. When things get hairy,
I'm pretty sure they'd be completely unmanageable with a
single-inheritance-with-protocols, statically typed language.
> I am curious how you organize your Cells libraries (or whatever the
> unit of distribution is) so they're easy for folks to find--suppose I
> drank the kool-aid and became a full-time Cells programmer. How do I
> find all this reusable code whether written by you or my buddy two
> cubes down? Because I do agree with Gabriel that often *that's* the
> real impediment to reuse.
Well, it's a potential impediment. "Sharing" and "reuse" are two
different things. Reuse happens within whatever community can access
the reusable code. Java is very good at sharing (as is Perl). In
some ways, Common Lisp qua language discourages sharing: as I've said
before, I'd usually rather write my own library to implement an RFC
than use a trivailly installable Perl or Java library, because the
effort to implement it in CL is about the same as to learn to use the
Perl or Java library.
Reuse-the-Grasal will only happen with both reuse *and* universal
sharing. Both quests are worthwhile, even if they never quite find
their objects.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Having now done a bit of reading, and asked around a bit, it sounds
> like Sun carefully got the reuse jargon out of the Java community.
Pretty much. Most OO programmers I've worked with have long come to
the same conclusion that procedural programmers came to long ago:
reuse doesn't happen, it has to be planned for and worked into the
objects. It's not the case that you can just write your code and
it'll be magically useful in other contexts.
> Java is a great platform for exchanging carefully constructed
> libraries.
Indeed. A lot of Java's current popularity comes from the
proliferation of frameworks, which are just libraries turned inside
out. (Instead of fitting libraries into your application, you fit
your application into the framework.) There's nothing about OO that
makes libraries or frameworks much easier to put together, but there
are a lot of things about Java that make it easier. The universal
byte-code is a good thing. Sun's willingness to standardize
interfaces for nearly anything under the sun helps. The culture of
sharing frameworks and libraries (just like Perl) means there's lots
to choose from.
But all of that was specifically designed for a wider audience.
Within a java project with lots of developers, you usually have the
same problems you have in any other language... many implementations
of the same idea, shoved in different classes all over the place,
written by different developers who may not have known of the other
implementations, or decided that the other implementations were
lacking in some way. You generally need a hawk-eyed person watching
over things to catch things that need to be factored into common
things, becuase it does not just happen.
The idea was that OO made reuse happen more naturally because objects
are a convenient place to break things up, and it would decouple
routines from implementation, but often there are places where it's
not clear where a method belongs, or whether you need another
object. Developers are often averse to the idea of adding yet
another small class to hold something, because the application
already has 958 classes... not counting everything in the frameworks
and libraries the application is using. And because there are
per-class costs (creating the file, maintaining doccumentation,
keeping the build upt to date) so there is sort of a minimum size for
a class before the costs are justified....
--
Alan Shutko <···@acm.org> - I am the rocks.
"Alan Shutko" <···@acm.org> wrote in message
···················@wesley.springies.com...
> ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> But all of that was specifically designed for a wider audience.
> Within a java project with lots of developers, you usually have the
> same problems you have in any other language... many implementations
> of the same idea, shoved in different classes all over the place,
> written by different developers who may not have known of the other
> implementations, or decided that the other implementations were
> lacking in some way. You generally need a hawk-eyed person watching
> over things to catch things that need to be factored into common
> things, becuase it does not just happen.
This is very true. With a large code base and disparate developers, lots of
bits of code end up being duplicated. Some through weaker coders that simply
cut-n-paste things, to small utility classes.
Another part that frustrates our environment is that we have, essentially, 3
blobs of code: server, common, client. If someone creates a bit in the
client area, it can be quite painful to migrate it to the common area when
dealing with package renaming and its side effects. We have a couple of
examples where the "client" version simply extends the "common" version just
so we didn't have to go through the zillion classes and JSP files that
accessed the original package.
> The idea was that OO made reuse happen more naturally because objects
> are a convenient place to break things up, and it would decouple
> routines from implementation, but often there are places where it's
> not clear where a method belongs, or whether you need another
> object. Developers are often averse to the idea of adding yet
> another small class to hold something, because the application
> already has 958 classes... not counting everything in the frameworks
> and libraries the application is using. And because there are
> per-class costs (creating the file, maintaining doccumentation,
> keeping the build upt to date) so there is sort of a minimum size for
> a class before the costs are justified....
What's interesting as a counter to this is the whole concept and practice of
refactoring, where the goal is basically to create and consolidate in new
classes shared logic. Here it takes the discipline to want to make the leap
to a new class just because you're now duplicating some other piece of code,
particularly if it seems to border on the complexity scale between
cut-n-paste and factoring it out.
Also, one reason I think I never quite grokked Smalltalk is that it is very
"cheap" on classes. It wants more and more classes. For whatever reason I
was never comfortable with that. Since classes are a wee bit more expensive
in Java, they seem to proliferate a bit less there.
I think its that more classes means more complexity, at least at a cognitive
"Follow the code" level. I think many coders, particularly when learning a
system, would find a 3 item case statement more accessbile than 3 different
classes (this being a contrived example where classes perhaps could have
been used instead of a case statement). I know in Smalltalk, I've always had
problems grasping the big picture because I'm more atuned to interpret large
files of code rather than viewing it all through the small window of the
Smalltalk browser, one method at a time.
Now, one reason for the complexity is simply that the related code is not
kept together physically. In CL, you can easily keep classes and GFs
together on a source code basis which can make understanding easier.
It's a granularity issue. While the system works in Classes, I think people
have different organizational units and like to work at higher levels.
Regards,
Will Hartung
(·····@msoft.com)
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Peter Seibel <·····@javamonkey.com> writes:
>
> > Kenny Tilton <·······@nyc.rr.com> writes:
> >
> > > My point was that i am pointing to a programming twist (member
> > > functions vs GFs vs Cells) in discussing reusability. Something
> > > achieved at the language level can be expected to scale, because
> > > Billy Bob's Ecosystem Hierarchy will be reusable if he takes a
> > > little care with it. He won't need MegaCorp to put its stamp of
> > > approval on it so that people simply don't use anything else and
> > > then Eureka! It's reusable! It will just really be reusable in
> > > the Grail sense. This Sun sense of reusability works exactly
> > > where they or some other 600lb Gorilla decides to build a
> > > library.
> >
> > That's where I think we fundamentally disagree. It doesn't require
> > MegaCorp's imprimatur. Lot's of good Java libraries come from open
> > source groups (e.g. Apache's Jakarta) and are developed within an
> > organization.
>
> "Within an organization", "open source /group/", and "Billy Bob" --
> one of this things is not like the other.
Yeah, but only, IMO, because nobody's heard of Billy Bob. But if Billy
Bob's Ecosystem Hierarchy took off and all the eco-hackers were using
it, then he'd seem like just another 600lb gorilla.
> > Frankly, I'm not sure. I'm not a big fan of inheritance generally
> > so I don't get all goose-pimply at the thought of having *more* of
> > it. But it certainly seems that there's no harm in CL-style MI and
> > I can see places it can be useful. But I do miss interfaces a
> > bit--I'm not sure what they mean without static checking but they
> > do provide a very good way to *express* protocols. Or at least
> > large parts of protocols. Which seems to me central to making well
> > factored code.
>
> But what do they give you that an abstract mixin doesn't? I think I
> (sometimes) use mixins the way Javains use protocols. I do something
> like:
Well interfaces are (obviously) quite different than mixins since
interfaces have no code in them. The point of on interface is it
provides (a significant part of) a contract--here's my code, here's
the interface I defined, if you implement this interface then your
code will fit into my code in these ways. They're the hooks. Obviously
the same thing can be done in a dynamically typed language with just
documentation (which is needed in any case with interfaces since the
contract is often more than just the method signatures--thus Javadoc).
But that's the role interfaces play. And it's nice to get some support
for that from the language--at least once it compiles you know that
you didn't just forget to implement some method that's part of the
protocol.
> > A set of mutually dependent GFs and default methods provide the
> > same thing but it's harder to figure out how the fit together. And
> > the more flexible (and thus reusable it is) the harder it is to
> > find your way through the maze. At least that's been my experience
> > with things like the MOP. But I suspect that's approaching the
> > limit of protocol complexity. At least I hope it is, or I'm too
> > dumb for this stuff.
>
> Figuring out how they all fit together is trivial if you use the
> proper browsers. Go *click*, and you're done. When things get hairy,
> I'm pretty sure they'd be completely unmanageable with a
> single-inheritance-with-protocols, statically typed language.
So what browser do use?
> > I am curious how you organize your Cells libraries (or whatever
> > the unit of distribution is) so they're easy for folks to
> > find--suppose I drank the kool-aid and became a full-time Cells
> > programmer. How do I find all this reusable code whether written
> > by you or my buddy two cubes down? Because I do agree with Gabriel
> > that often *that's* the real impediment to reuse.
>
> Well, it's a potential impediment. "Sharing" and "reuse" are two
> different things.
Good point. But you can't reuse code you can't find. And the more code
you have to potentially be reused, the harder it gets to find it.
That's Gabriel's point, as I take it. And my point is that in a
discussion of "reuse" I think it's worth considering *all* the aspects
that actually impact on how much code is actually used more than once;
I don't think it's *just* about object models.
> Reuse-the-Grasal will only happen with both reuse *and* universal
> sharing. Both quests are worthwhile, even if they never quite find
> their objects.
Yes.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel <·····@javamonkey.com> writes:
> ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > But what do they give you that an abstract mixin doesn't? I think I
> > (sometimes) use mixins the way Javains use protocols. I do something
> > like:
>
> Well interfaces are (obviously) quite different than mixins since
> interfaces have no code in them. The point of on interface is it
> provides (a significant part of) a contract--here's my code, here's
> the interface I defined, if you implement this interface then your
> code will fit into my code in these ways. They're the hooks.
That's not obvious to me at all -- who says I have to actually put any
slots into or write any methods on my mixin? I can define a
foo-interface mixin, and later expect objects that inherit from it, by
specializing on them. I don't think protocols give you anything per
se, I think it's the static checking that you like.
> > Figuring out how they all fit together is trivial if you use the
> > proper browsers. Go *click*, and you're done. When things get hairy,
> > I'm pretty sure they'd be completely unmanageable with a
> > single-inheritance-with-protocols, statically typed language.
>
> So what browser do use?
(Assuming this was supposed to be "what browser do you use?")
Since ILC, more and more the LispWorks browser. That'll probably
change this weekend when the evaluation version runs out. I've hacked
together various solutions on CMUCL, using Garnet sometimes, and Emacs
sometimes. Pretty much, you're good if you can browse the class
hierarchy, browse methods on GFs, and browse methods that apply
directly and indirectly to classes. Doesn't ACL come with something
like that?
> > Well, it's a potential impediment. "Sharing" and "reuse" are two
> > different things.
>
> Good point. But you can't reuse code you can't find. And the more code
> you have to potentially be reused, the harder it gets to find it.
> That's Gabriel's point, as I take it.
But, remembering that we're in a Lisp newsgroup, I'd be relatively
happy if I could be a little island of reuse. Sharing with the world
would be better, but if I'm a little Lisp enclave of my own, so be it :)
> And my point is that in a
> discussion of "reuse" I think it's worth considering *all* the aspects
> that actually impact on how much code is actually used more than once;
> I don't think it's *just* about object models.
Certainly.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Thomas F. Burdick wrote:
> That's not obvious to me at all -- who says I have to actually put any
> slots into or write any methods on my mixin? I can define a
> foo-interface mixin, and later expect objects that inherit from it, by
> specializing on them.
Whew! While documenting Cells, I was a little panicked when I saw
c-drifter added no slots to c-ruled. It just serves to guide GF dispatch.
That was a hell of an exercise, btw. Found all sorts of stuff in there,
including vestigial cell structure classes. Which reminds me, I need to
get WinCVS fired up and pull down the latest version so I can synch that
with all the cleanup I got motivated to undertake while writing the doc.
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Peter Seibel wrote:
>
> ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> ...
>
> > > Frankly, I'm not sure. I'm not a big fan of inheritance generally
> > > so I don't get all goose-pimply at the thought of having *more* of
> > > it. But it certainly seems that there's no harm in CL-style MI and
> > > I can see places it can be useful. But I do miss interfaces a
> > > bit--I'm not sure what they mean without static checking but they
> > > do provide a very good way to *express* protocols. Or at least
> > > large parts of protocols. Which seems to me central to making well
> > > factored code.
> >
> > But what do they give you that an abstract mixin doesn't? I think I
> > (sometimes) use mixins the way Javains use protocols. I do something
> > like:
>
> Well interfaces are (obviously) quite different than mixins since
> interfaces have no code in them.
how does that make them that "quite different" - as in disjoint? they add to
the language the ability to declare the behaviour of a class by combining the
behaviours of other classes. where they preclude implementations for their
methods, what does that change beyond that one cannot provide default method
implementations in the protocol classes? i understand why they claim it was
necessary. if you think about what the interface needs to accomplish, it was a
misguided decision. in any case, it is not sufficient to make them
"(obviously) quite different".
> The point of on interface is it
> provides (a significant part of) a contract--here's my code, here's
> the interface I defined, if you implement this interface then your
> code will fit into my code in these ways. They're the hooks. Obviously
> the same thing can be done in a dynamically typed language with just
> documentation
it can also be done in a dynamically typed language with the class and method
declarations. look at abstract-generic-function, abstract-method, and the
concrete method combination in [1]. given those declarations, were one
posessed to, one could perform a static analysis on a "compilation unit" or a
a given package, by iterating over all abstract generic functions, examining
the specializers, iterating over the respective specialized, non-abstract
classes, and asserting that there be a concrete method for the function which
is applicable given that class. that is, there is nothing unique to
"interfaces" which enables its behaviour.
> (which is needed in any case with interfaces since the
> contract is often more than just the method signatures--thus Javadoc).
i didn't realize the java compiler enforced that aspect of a the "contract".
...
[1] http://www.setf.de/library/de/setf/utility/clos/clos.lisp
Peter Seibel wrote:
> .... Again, I'm not saying Java's particular features are the
> be all and end all of resue-enabling features. But I *do* think *you*
> underestimate them.
Me? The entire community takes it as a given that the Grail reuse was
not delivered by OO. I do not see anything in Java's OO model any
different than C++ or Objective-C or Smalltalk, so your argument is not
with me, it is with an entire community that noticed that Grail reuse
never happened.
I know you've mentioned trying (and succeeding?)
Yes, but without macros... well you mentioned insane amounts of keyboarding.
> in porting Cells to Java. Have you used Java in anger other than that?
> Just curious.
No, but we are just talking about OO models here. Here's another try:
imagine a world with a C++ compiler, Smalltalk, Objective-C
preprocessor, Java byte-code compiler, and CL compilers, but no
libraries. With luck we can now keep the topic on OO models, in a way
suitable for a programming language comparison
your focus seems to be on how productive a Javan can be when using a
library written to a standard they have to write to, and not the OO
model. The only thing I have heard is that you dig interfaces and don't
like inheritance. The latter is a tip-off that you are not even close to
talking about the Grail of reuse, and that in your (and Java's?) world
that OO is just a neat way of packaging code.
In which case we are not really talking about OO. We are talking about
the ultimate logical consequence of the failure of OO, viz, that it is
now being used for the only thing it is good for: neatly organizing and
compartmentalizing (with interfaces and everything) waht used to be
undifferentiated huge wadges of code called applications.
That's a sad end for OO, when an all-objects-all-the-time language
abandons OO.
[Aside: Doh! Your handle is javamonkey! Now I know I'm in trouble. <g>]
>
>
>>I do miss interfaces a bit--
A big interfaces fan, when I asked for a clarification, did concede "We
/do/ end up duplicating a lot of code...". I'm sorry, I have that one
logged under "mortal sin". Has that changed? (The fan was an Objective-C
guy.)
> Okay. So Cells makes it easy for you to define the protocol between
> the stack and its children by which they collectively determine where
> each kid is positioned in the horizontal plane.
Protocol? The amount of agreement (protocol) required between parent and
child can be expressed in a sentence or two. The kids can say anything
they like about where they go, including nothing. That is how all my GUI
collection classes work. The only interesting thing is that /some/
collections stomp on kids choices to impose order (such as Visi-Stack),
and some demand that the kids make their own decisions as to where they
go (Visi-Shrink-Wrap might be their name). But the protocol is pretty
much documented by the name of the collection.
The Essential Point is that slots of two different instances can have
not just two different literal values, but two different functions
determining their values.
> I am curious how you organize your Cells libraries (or whatever the
> unit of distribution is) so they're easy for folks to find--suppose I
> drank the kool-aid and became a full-time Cells programmer. How do I
> find all this reusable code whether written by you or my buddy two
> cubes down? Because I do agree with Gabriel that often *that's* the
> real impediment to reuse.
Cell-based hierarchies aren't so big in number of classes or depth of
tree or inter-class protocol complexity that finding a class becomes a
problem.
It's the "reuse" thing.
:)
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
> Peter Seibel wrote:
> > .... Again, I'm not saying Java's particular features are the
> > be all and end all of resue-enabling features. But I *do* think *you*
> > underestimate them.
>
> Me? The entire community takes it as a given that the Grail reuse was
> not delivered by OO. I do not see anything in Java's OO model any
> different than C++ or Objective-C or Smalltalk, so your argument is
> not with me, it is with an entire community that noticed that Grail
> reuse never happened.
Which community is that? The Lisp community? The community of people
who understand the meaning of "reuse" in exactly the same way as
Kenny? I don't even know what OO is and I'm still fuzzy on whether
Grail reuse is supposed to refer to the pie-in-the-sky promises of the
marketing departments or some other thing. So I can't imagine that
"the community" is particularly well defined. But maybe I just don't
know the secret handshake. So be it.
> I know you've mentioned trying (and succeeding?)
>
> Yes, but without macros... well you mentioned insane amounts of keyboarding.
>
> > in porting Cells to Java. Have you used Java in anger other than that?
> > Just curious.
>
> No, but we are just talking about OO models here.
Hmmm. Maybe we disagree about that too. Because from a certain
distance Java, C++, Smalltalk, and Objective-C all provide the same
"OO model". But they are very different languages and have other
features and are used in different social and historical contexts that
support or discourage reuse. But I guess I'm the one who's off topic
because I believe Thomas said "*OO* failed" to deliver reuse. And I'm
the dummy who dragged in all the other stuff.
I'm perfectly happy to agree that the basic class-based OO model
supported by those languages is neither necessary nor sufficient to
provide reuse, "Grail" or otherwise. But whatever community "takes it
as a given that the Grail reuse was not delivered by OO" is cutting
itself off from a community (the Java community) who feels that Java
has delivered, if not the holy Grail, a lot more than, say C++.
> Here's another try: imagine a world with a C++ compiler, Smalltalk,
> Objective-C preprocessor, Java byte-code compiler, and CL compilers,
> but no libraries. With luck we can now keep the topic on OO models,
> in a way suitable for a programming language comparison
>
> your focus seems to be on how productive a Javan can be when using a
> library written to a standard they have to write to, and not the OO
> model. The only thing I have heard is that you dig interfaces and
> don't like inheritance. The latter is a tip-off that you are not even
> close to talking about the Grail of reuse, and that in your (and
> Java's?) world that OO is just a neat way of packaging code.
>
> In which case we are not really talking about OO. We are talking about
> the ultimate logical consequence of the failure of OO, viz, that it is
> now being used for the only thing it is good for: neatly organizing
> and compartmentalizing (with interfaces and everything) waht used to
> be undifferentiated huge wadges of code called applications.
>
> That's a sad end for OO, when an all-objects-all-the-time language
> abandons OO.
Whatever. I don't really care whether I'm doing "OO" or not. As
someone who did "OO" in Perl, and then "OO" and Java, and thinks
Common Lisp has as good a claim to be "OO" as any other language, I
don't get exercised anymore about what "OO" is. For purposes of this
discussion I'm happy to concede that OO is whatever you say it is,
because I don't actually care.
> [Aside: Doh! Your handle is javamonkey! Now I know I'm in trouble. <g>]
Like I said, I don't like Java. As I think I said to someone who came
here touting Java's superiority some months back, "This isn't
uninformed hatred of Java; this is very *well* informed hatred of
Java." Though hatred is too strong a term--having been away from it
for a year and being able to hack Lisp, I'm less bitter.
> >>I do miss interfaces a bit--
>
> A big interfaces fan, when I asked for a clarification, did concede
> "We /do/ end up duplicating a lot of code...". I'm sorry, I have
> that one logged under "mortal sin". Has that changed? (The fan was
> an Objective-C guy.)
Nope. It's still a mortal sin. Numero Uno probably. But I didn't find
that interfaces caused me to duplicate code. Lack of macros on the
other hand ...
> > Okay. So Cells makes it easy for you to define the protocol between
> > the stack and its children by which they collectively determine where
> > each kid is positioned in the horizontal plane.
>
> Protocol? The amount of agreement (protocol) required between parent
> and child can be expressed in a sentence or two.
I never said it had to be heavy weight. The best protocols are often
the simplest.
> The kids can say anything they like about where they go, including
> nothing. That is how all my GUI collection classes work. The only
> interesting thing is that /some/ collections stomp on kids choices
> to impose order (such as Visi-Stack), and some demand that the kids
> make their own decisions as to where they go (Visi-Shrink-Wrap might
> be their name). But the protocol is pretty much documented by the
> name of the collection.
Yup, Visi-Shrink-Wrap tells *me* everything I need to know. You're a
weird dude, Kenny.
> The Essential Point is that slots of two different instances can
> have not just two different literal values, but two different
> functions determining their values.
Yup. Just like this class:
public class Foo {
private Thingy thingy;
public Foo(Thingy thingy) { this.thingy = thingy; }
public void doStuff() {
// stuff
thing.doYourThing();
// other stuff
}
}
Again, does this require a painful amount of typing (in both senses of
the word)? Yes. Would this be less painful with true first-class
functions? Yes. But is this how many Java classes are put together
anyway (especially where Thingy is an interface)? Yes.
> > I am curious how you organize your Cells libraries (or whatever the
> > unit of distribution is) so they're easy for folks to find--suppose I
> > drank the kool-aid and became a full-time Cells programmer. How do I
> > find all this reusable code whether written by you or my buddy two
> > cubes down? Because I do agree with Gabriel that often *that's* the
> > real impediment to reuse.
>
> Cell-based hierarchies aren't so big in number of classes or depth of
> tree or inter-class protocol complexity that finding a class becomes a
> problem.
>
> It's the "reuse" thing.
Okay. Whatever.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>>Cell-based hierarchies aren't so big in number of classes or depth of
>>tree or inter-class protocol complexity that finding a class becomes a
>>problem.
>>
>>It's the "reuse" thing.
>
>
> Okay. Whatever.
Lessee, after days of exchange you ask how to find what you want in a
Cells-based hierarchy and I honestly respond "they ain't that deep
because cells make a few classes reusable", and all you can say is
"whatever"?
That point was the only reason to pursue this thread, and all you can
say is "whatever"?! I wasn't joking. I do not have very many classes
over here. I always know which of the few to subclass. Which is how I
know I am enjoying reuse where Javans are not.
Your equally serious and carefully thought-out response is "whatever"?!
Wow, twenty-thirty hours of good-faith discourse down the drain. Glub glub.
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
>>>>> "KT" == Kenny Tilton <·······@nyc.rr.com> writes:
[...]
KT> Your equally serious and carefully thought-out response is
KT> "whatever"?! Wow, twenty-thirty hours of good-faith discourse
KT> down the drain. Glub glub.
Not completely as others here got to read it too. Sometimes it is useful to
see people mis-communicate in good faith.
cheers,
BM
Kenny Tilton <·······@nyc.rr.com> writes:
> Peter Seibel wrote:
> > Kenny Tilton <·······@nyc.rr.com> writes:
>
> >>Cell-based hierarchies aren't so big in number of classes or depth of
> >>tree or inter-class protocol complexity that finding a class becomes a
> >>problem.
> >>
> >>It's the "reuse" thing.
> > Okay. Whatever.
>
> Lessee, after days of exchange you ask how to find what you want in
> a Cells-based hierarchy and I honestly respond "they ain't that deep
> because cells make a few classes reusable", and all you can say is
> "whatever"?
Sorry. I clearly don't understand Cells. You've given me the
impression (maybe mistaken) that classes don't carry as much of the
burden in Cells as they do in other styles of programming. So saying
the classes aren't hard to find doesn't tell me much. How do I find
the other stuff? Maybe there is no other stuff. Like I said, I don't
understand it. But I suspect I'm never going to understand what you're
talking about until the day when I actually look at Cells and use it
myself. At the moment all I know is you say it's the greatest thing
since sliced bread.
> That point was the only reason to pursue this thread, and all you
> can say is "whatever"?! I wasn't joking. I do not have very many
> classes over here. I always know which of the few to subclass. Which
> is how I know I am enjoying reuse where Javans are not.
And I, sorry, don't believe that you really "know" anything about how
Java programmers work. Sadly neither of us is in a good position to
make a comparison between Java and Cells since I know Java but not
Cells and you know Cells but not Java. Thus my "whatever"--this is
going nowhere because neither of us can understand the other. I'd like
to think that I am at least still open to the possibility that Cells
are as good as you claim; not having any first-hand experience, I
defer to your greater knowledge, leavened only by my native
scepticism.
> Your equally serious and carefully thought-out response is
> "whatever"?! Wow, twenty-thirty hours of good-faith discourse down
> the drain. Glub glub.
I'm sorry you're disatisfied with how things turned out. If it's any
consolation to you, I don't feel that my time has been any better
spent.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>Peter Seibel wrote:
>>
>>>Kenny Tilton <·······@nyc.rr.com> writes:
>>
>>>>Cell-based hierarchies aren't so big in number of classes or depth of
>>>>tree or inter-class protocol complexity that finding a class becomes a
>>>>problem.
>>>>
>>>>It's the "reuse" thing.
>>>
>>>Okay. Whatever.
>>
>>Lessee, after days of exchange you ask how to find what you want in
>>a Cells-based hierarchy and I honestly respond "they ain't that deep
>>because cells make a few classes reusable", and all you can say is
>>"whatever"?
>
>
> Sorry. I clearly don't understand Cells. You've given me the
> impression (maybe mistaken) that classes don't carry as much of the
> burden in Cells as they do in other styles of programming. So saying
> the classes aren't hard to find doesn't tell me much. How do I find
> the other stuff?
If I understand correctly, and taking the GUI View framework as an
example where I get tremendous reuse of a few core classes, the burden
is diffused across multiple factory GFs, each specific to some
functional requirement. So an object inspector window will at some level
call an inspector-view-contents GF to fill in a pane for each object
inspected as the developer navigates around the runtime instance
hierarchy. inspector-view-contents is specialized on the thing
inspected, and takes further guidance from the instance slot values,
which it can do precisely because it is happening dynamiclly, on-the-fly.
Cloucell, my portable object inspector, naturally offers different views
(as in a different subview structure) depending on whether one is
inspecting a list, a structure instance, a CLOS instance, etc. But if
you inspect the dynamic structure of the inspector window itself, you
won't find different views for the different types of thing. The view
gets built on the fly out of a few nicely parameterized core view classes.
I mentioned that content decides the view as well. In an extreme case,
if while inspecting you navigate into an inspection of a list containing
one thing, the list-specialized inspector-view-contents method
recursively invokes inspector-view-contents on the one thing and you end
up inspecting that.
I'll confess to one thing, tho. In cases like this, when it comes time
to change something, I usually cannot remember how the hell a window is
being assembled, and I can guess wrong a few times trying to find the
crucial GF, in this case inspector-view-contents. I usually break down
and end up in apropos, even though I know what I am looking for. A more
arduous method is to kick off the inspector, inspect the
inspector-instance-view widget, and examine the rule for its KIDS slot.
That would then be:
(c? (inspector-view-contents (md-value (window self))))
where md-value is a heavily used GUI framework slot that store the
non-view thing of most interest to the view (and in this case the
instance being inspected is of most interest to the inspector window.).
> And I, sorry, don't believe that you really "know" anything about how
> Java programmers work.
No, I don't, but others have now painted the same picture I had in mind.
Maybe I played enough with the Think Class Library and SmalltalkAgents
(and worked enough decades in tall buildings) to understand lies behind
the conventional wisdom that reuse never happened.
One thing I want to emphasize is that my perception of reuse Cells is
wholly after the fact. I did not try to make classes reusable, I just
found that I was not making very many, once the core types had been
coded up. And when I do make a new class, it is usually just my way of
bundling up a useful set of cell initializations:
(defmodel handy-view-idea (IXStack)
()
(:default-initargs
:lr (c?....)
:lb (c?....)
:layers (c?....)))
Could also just be a function, I suppose, but when doing OO, why not use
OO? Anyway, Thomas Burdick is going to save me from that with prototypes
for cells (Stem Cells, IIRC.)
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
>>>>> On Wed, 26 Nov 2003 05:56:54 GMT, Peter Seibel ("Peter") writes:
Peter> Kenny Tilton <·······@nyc.rr.com> writes:
>> Peter Seibel wrote:
>> > .... Again, I'm not saying Java's particular features are the
>> > be all and end all of resue-enabling features. But I *do* think *you*
>> > underestimate them.
>>
>> Me? The entire community takes it as a given that the Grail reuse was
>> not delivered by OO. I do not see anything in Java's OO model any
>> different than C++ or Objective-C or Smalltalk, so your argument is
>> not with me, it is with an entire community that noticed that Grail
>> reuse never happened.
Peter> Which community is that? The Lisp community? The community of people
Peter> who understand the meaning of "reuse" in exactly the same way as
Peter> Kenny?
That's his functional definition.. :)
Christopher C. Stacy wrote:
>>>>>>On Wed, 26 Nov 2003 05:56:54 GMT, Peter Seibel ("Peter") writes:
>
>
> Peter> Kenny Tilton <·······@nyc.rr.com> writes:
> >> Peter Seibel wrote:
> >> > .... Again, I'm not saying Java's particular features are the
> >> > be all and end all of resue-enabling features. But I *do* think *you*
> >> > underestimate them.
> >>
> >> Me? The entire community takes it as a given that the Grail reuse was
> >> not delivered by OO. I do not see anything in Java's OO model any
> >> different than C++ or Objective-C or Smalltalk, so your argument is
> >> not with me, it is with an entire community that noticed that Grail
> >> reuse never happened.
>
> Peter> Which community is that? The Lisp community? The community of people
> Peter> who understand the meaning of "reuse" in exactly the same way as
> Peter> Kenny?
>
> That's his functional definition.. :)
I do give the same answer every time I am asked.
:)
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
>>>>> On Wed, 26 Nov 2003 05:56:54 GMT, Peter Seibel ("Peter") writes:
Peter> Kenny Tilton <·······@nyc.rr.com> writes:
>> Peter Seibel wrote:
>> > .... Again, I'm not saying Java's particular features are the
>> > be all and end all of resue-enabling features. But I *do* think *you*
>> > underestimate them.
>>
>> Me? The entire community takes it as a given that the Grail reuse was
>> not delivered by OO. I do not see anything in Java's OO model any
>> different than C++ or Objective-C or Smalltalk, so your argument is
>> not with me, it is with an entire community that noticed that Grail
>> reuse never happened.
Peter> Which community is that? The Lisp community? The community of people
Peter> who understand the meaning of "reuse" in exactly the same way as Kenny?
That's just Kenny's strong type of definition... :)
On Sat, 22 Nov 2003, Peter Seibel wrote:
> But if you don't like Servlets, take JDBC drivers. Sun set the
> standard, defining the base classes and interfaces that comprise a
> JDBC driver.
This and most other examples sound like the main benefit is from
standardisation of APIs, which you don't need OO for. The interesting
problem is what you can do if the existing API simply can't handle a
certain thing you need it to -- to what degree can you reuse the parts of
the API implementation that do work as you want? And the answer is
probably, you can't, or if you try to the result is a fragile mess.
> Nope. Doesn't that just prove that in certain cirumstances Gabriel is
> wrong? (I really get the feeling that you are defining "re-use" as
> something that can't be done. Therefore if someone actually does it it's
> not reuse. Like AI.)
Even if that's so, multimethods and multiple inheritance can take you
further down the road to reuse than Java's idea of OO. And in my opinion
functional languages, because anonymous functions are so easy, tend to
encourage more reusable designs at low levels. What about Java's lack of
type-safe polymorphism, which makes reuse of algorithms which should be
generic a hassle?
OO is one way of stucturing programs for reuse, but it is not the only
way, nor even for many situations the best way.
Kenny Tilton writes:
> Another thing you will find if you use Google might be a piece by
> Gabriel (or was that just in a book?) where he says, hey, it's just
> too damn hard finding the right re-usable class, even though it is out
> there!
Gabriel covers the failure of OO reuse, among other things, in his
book "Patterns of Software".
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Kenny Tilton <·······@nyc.rr.com> writes about reuse.
The difficulties with reuse are not only found in OO.
For example, I recently needed to parse HTML pages.
So I searched and found Franz xmlutils "Common-Lisp" package.
Well, I spend so much time trying to make it work in the Lisp I use
(clisp), that I finally implemented my own HTML parsing, and it took
me half the time I spend on trying to make xmlutils work.
On the other hand, I suppose you could call it a great reuse success.
That is, if I had fallen to the tentation to buy Allegro Common Lisp.
--
__Pascal_Bourguignon__
http://www.informatimago.com/
Pascal Bourguignon wrote:
> Kenny Tilton <·······@nyc.rr.com> writes about reuse.
>
> The difficulties with reuse are not only found in OO.
Agreed, and my premise is that all the talk of objects having behaviors
came to nothing because the underlying implementations (the conventional
code) was no easier to get right (in re abstraction) than code living
outside the realm of OO.
And this all gets back to the original comment, that Javans would shriek
at the idea of GFs not belonging to a class. My answer would be, look,
there is no way you are going to write anything more interesting than a
String class and make everyone happy, so decouple the "behavior" of an
object from the object for a little more flexibility. ie, maybe you can
get the slots right, if not the code.
Use Cells if you want the Grail re-use we were promised (tho ya still
gotta get the slots right).
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Peter Seibel <·····@javamonkey.com> writes:
> ···@fallingrocks.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>> But when Java programmers say "object reuse," they're just talking
>> about good old-fashioned libraries. Not the revolutionary reuse that
>> was hyped by the OOP boosters in the early 90's.
>
> Not really. Anyone who's ever written a servlet has created a subclass
> of javax.servlet.Servlet (or whatever it is) which allows their code
> to fit into the framework provided by the app server. That's more than
> just library use, in my mind.
I think this is "reuse" in the same sense as Turing-equivalence is
expressive power - i.e. the ultimately quite tedious one.
Approximately the same protocol must be implemented to provide or use
the Java servlet interface as to provide or use the CGI interface.
Does that make every CGI script "Apache reuse"?
-dan
--
http://web.metacircles.com/cirCLe_CD - Free Software Lisp/Linux distro
Daniel Barlow <···@telent.net> writes:
> Peter Seibel <·····@javamonkey.com> writes:
>
> > ···@fallingrocks.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> >> But when Java programmers say "object reuse," they're just talking
> >> about good old-fashioned libraries. Not the revolutionary reuse that
> >> was hyped by the OOP boosters in the early 90's.
> >
> > Not really. Anyone who's ever written a servlet has created a subclass
> > of javax.servlet.Servlet (or whatever it is) which allows their code
> > to fit into the framework provided by the app server. That's more than
> > just library use, in my mind.
>
> I think this is "reuse" in the same sense as Turing-equivalence is
> expressive power - i.e. the ultimately quite tedious one.
What's tedious about it? I install an server that runs servlets. I
write a subclass of servlet that handles most of the low-level foo and
the lines of code I actually write are (module Java's natural
verbosity) all about the stuff that makes *this* servlet different
from all the other servlets. The servlet runs and there's several
hundreds or thousands of lines of Java code that run each time my
servlet gets hit by a browser that I didn't have to write.
I'm interested (seriously) in what "real" reuse would look like that's
different than that.
> Approximately the same protocol must be implemented to provide or use
> the Java servlet interface as to provide or use the CGI interface.
> Does that make every CGI script "Apache reuse"?
I'd say yes, CGI provides an API that allows programmers to reuse the
code in Apache. They can also reuse it by writing an Apache module.
Objects aren't the only way. In fact, I'm not even sure that it's
object per se that make possible the reuse that I see happening in
Java. Because C++ has objects but not, I don't think, as much reuse.
I'm just saying that if you (or the OP) go to a bunch of Java
programmers and say, "as we all know, object oriented languages like
Java have completely failed to support code reuse" they're going to
think you're daft because they write classes all the time that they
use and reuse in different contexts and reuse libraries of 3rd party
code from app to app.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
"Peter Seibel" <·····@javamonkey.com> wrote in message
···················@javamonkey.com...
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> Hmmm. I think the Java programmers are going to disagree that OO has
> "failed miserably at delivering on ... re-use". They use 3rd-party
> Java libraries *all the time*. Most Java programmers probably do
> nothing but stitch together existing libraries and frameworks. I think
> C++ failed miserably but that was an implementation issue. Java, with
> its interfaces, package system, and runtime linking actually made
> object re-use work.
Yes, this "stitching" is I think the core of the Java Community. It seems to
be much easier to forge these bits and components and then make them
available vs serving up monolithic applications as seems the norm for C/C++.
The classic example of course is the Jakarta Project, where they continue to
factor our common bits of their main projects and put them up for individual
use.
I think the other part is the binary compatability, making it trivial to
"link" these 3rd party libraries into you application, or to even write
simple test programs to explore the libraries.
I think a lot more Java is downloaded and used in binary than most anything
else. If you've never had the pleasure if trying to build Tomcat from
scratch, consider yourself blessed. But it can easily be downloaded in
binary and used directly, everywhere. Same goes for the plethora of other
tools.
So, to evaluate a Java library, you download the binary, run some demos,
play with some sample code and then say "Yay" or "Nay" after perhaps 30
minutes of playing with it versus fighting build issues.
I've never made the commitment to set up a Lisp environment to the point
where downloading and building and testing public code is easy, and I think
that perhaps some of the common CL lib sites should consider making
appropriate FASLs available for users so that folks can get a better "out of
the box" Lisp experience much like they can with Java.
Regards,
Will Hartung
(·····@msoft.com)
Will Hartung writes:
> I've never made the commitment to set up a Lisp environment to the
> point where downloading and building and testing public code is
> easy, and I think that perhaps some of the common CL lib sites
> should consider making appropriate FASLs available for users so that
> folks can get a better "out of the box" Lisp experience much like
> they can with Java.
I have heard a similar comment from a co-worker. He takes python as
an example, saying that he's able to install python and its associated
software with a minimum of fuss.
Recently I spent a fair amount of time figuring out how to use things
like defsystem's central repository and CMU Lisp's ability to autoload
pathname hosts from its library directory. I found it to be quite
nice. I could (require :defsystem) then (require :foo) and no matter
what directory I was in, foo would get loaded. I did this in the
context of building a web application using imho and uncommonsql.
This, along with using SLIME as my development environment, made the
whole thing more fun than it might have otherwise been (especially
considering the minimal documentation). And, by the way, the ability
to transparently redefine classes at runtime was also incredibly
helpful. I found myself doing it without thinking. Something doesn't
work; need a new slot, add it, add code, ^C^C where needed, it starts
working.
The experience is something like being a painter; paint a little, look
at it, paint some more, then eventually you're done. The other way is
more like having to ship the painting off to a paint place with
instructions, wait a week, get it back, look at it, write a new set of
instructions, ship it off, wait a week, get it back....
--
Fred Gilham ······@csl.sri.com
...Please don't assume Lisp is only useful for Animation and Graphics,
AI, Bioinformatics, B2B and E-Commerce, Data Mining, EDA/Semiconductor
applications, Expert Systems, Finance, Intelligent Agents, Knowledge
Management, Mechanical CAD, Modeling and Simulation, Natural Language,
Optimization, Research, Risk Analysis, Scheduling, Telecom, and Web
Authoring just because these are the only things they happened to
list. -- Kent Pitman
"Will Hartung" <·····@msoft.com> writes:
> I've never made the commitment to set up a Lisp environment to the point
> where downloading and building and testing public code is easy, and I think
> that perhaps some of the common CL lib sites should consider making
> appropriate FASLs available for users so that folks can get a better "out of
> the box" Lisp experience much like they can with Java.
Just install a recent SBCL. To install and begin reusing public code
like, say, CL-PPCRE, all you have to do is
* (require 'asdf-install)
* (asdf-install:install :cl-ppcre)
A command-line client is available as well.
It downloads the source using the cliki page, checks its
GPG-signature, compiles and installs it in a way that it is available
using REQUIRE. No fasls, but its already somewhat close to CPAN (the
big missing thing would be searching the available libraries, I
guess).
On Fri, 21 Nov 2003 16:07:00 GMT, Kenny Tilton <·······@nyc.rr.com> wrote:
>So embarrass them into not evangelizing, then sell! sell! cell!
>
>Is there any way to drag the horrors of templates into this
>presentation, or is that unrelated?
Good idea! It might be great to show the difference between the nightmare of
template metaprogramming and generative programming (such as in
http://urlmini.us?i=71 and http://urlmini.us?i=72 ) and Lisp macros.
However, it might be too much for a shor presentation. Perhaps you should
insist on simpler things, such as the 'interactive' way of programming in
Lisp, compared to the batch mode of C++. If their compile times are above 10
minutes (quite common for big projects) they will certainly appreciate it. If
not, they don't deserve to be saved.
PS Search for Generative Programming in cll: it give you many posts about this
C++ book and the monstruosities it describes.
Patrick May wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>>Geoffrey Summerhayes wrote:
>>
>>>Aside from multiple dispatch, any ideas of quick code to show off
>>>CLOS and Lisp to a heathen flock that is trained in Java? (not to
>>>mention being taught that Lisp is simply a functional language)
>>
>>I like the decoupling of Gfs from class definitions, and that a
>>dispatch ing argument can be just a number (and a method specialized
>>on that) or a whole frickin CLOS instance that gets all complicated
>>over the behavior based on what the CLOS instance has to say.
>
> In my limited experience trying to get Java and C++ programmers
> to consider the benefits of Lisp, this is a hard sell. The idea that
> methods are owned by a class is deeply ingrained in those language
> cultures. It's very easy to go off into an argument about
> encapsulation that ultimately distracts the audience completely from
> the core message.
>
> Demonstrating the benefits of multimethods might help. Most C++
> programmers have at least heard of double dispatch, but it isn't used
> that often because of the coding overhead involved. C++ and Java
> don't encourage consideration of solutions that involve such
> techniques.
In my experience, it's a good idea to talk about the Visitor pattern,
how it is implemented with double dispatch, and so on. Then focus on the
actual problem that the Visitor pattern tries to solve: group methods
according to the functionality they provide, and not according to the
classes to which they belong.
Then you can make them realize that you actually don't need double
dispatch anymore (so no multi-methods either) when you want to implement
the bare-bones version of the Visitor pattern. Stress and contrast this
with how complex the implementation of the Visitor pattern is in a
language that requires methods to be elements of classes.
In Common Lisp, you just copy and paste the method definitions to
reorganize them according to whatever grouping criterion, and you're
done. You only need multi-methods when you actually need it for
"functional" reasons.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
"Geoffrey Summerhayes" <·············@hotmail.com> wrote in message
····························@news20.bellglobal.com...
> I am giving a very short presentation (15 min.) + handouts based
> on Object Oriented Programming: The CLOS Perspective, chapter 7
> CLOS and C++, pages 157-180. MIT Press, 1993, chapter author Linda
> G DeMichiel. I have LW(Personal) running on my laptop and was
> thinking about using it to give a demonstration.
>
> Aside from multiple dispatch, any ideas of quick code to show
> off CLOS and Lisp to a heathen flock that is trained in Java?
> (not to mention being taught that Lisp is simply a functional
> language)
>
> It's a programming languages course, there's been a massive
> editing of the information being passed to make points about the
> differences between the paradigms without pointing out the some
> languages refuse to be classified so easily.
How about basing your presentation on Design Patterns, as in
Peter Norvig's slideshow http://norvig.com/design-patterns/ ?
It's not centered on CLOS, rather on the whole language, but
I think it can be a quite interesting for C++ programmers...
--
Matthieu Villeneuve