Picasso is a graphical user interface development environment based on CLOS
and CLX:
http://s2k-ftp.cs.berkeley.edu:8000/picasso/
It was developed in the early 1990s as a research project at UCB. This
paper:
Developing a GUIDE Using Object-Oriented Programming
http://s2k-ftp.cs.berkeley.edu:8000/picasso/Picasso-papers/oopsla91.ps.Z
discusses, among other things, the drawbacks of CLOS development in
Picasso. In short (see section "5. Discussion" of the paper for details),
the drawbacks mentioned by the authors are:
- CLOS complicated the system and made it harder for new developers to make
major changes
- multiple inheritance required most classes to be designed to share
superclass responsibilities
- the CLOS model of inheritance does not support or encourage encapsulation
- class inheritance order with multiple inheritance
- method combination made the system harder to understand
- most changes to a base class required extensive rewriting in subclasses
- performance (the authors, however, acknowledge that this was being
addressed by vendors, and things were already improving)
Do these drawbacks match your experience in developing large systems?
Paolo
--
Paolo Amoroso <·······@mclink.it>
Paolo Amoroso <·······@mclink.it> writes:
> Picasso is a graphical user interface development environment based on CLOS
> and CLX:
>
> http://s2k-ftp.cs.berkeley.edu:8000/picasso/
>
> It was developed in the early 1990s as a research project at UCB. This
> paper:
>
> Developing a GUIDE Using Object-Oriented Programming
> http://s2k-ftp.cs.berkeley.edu:8000/picasso/Picasso-papers/oopsla91.ps.Z
>
> discusses, among other things, the drawbacks of CLOS development in
> Picasso. In short (see section "5. Discussion" of the paper for details),
> the drawbacks mentioned by the authors are:
This looks to me like a classic problem that academics run into --
they're smart enough to make a bad design work well. Mostly what I
wanted to say has already been said. But:
> - the CLOS model of inheritance does not support or encourage encapsulation
It looks like they put everything in one package. No logical layers,
enforced by the package system, or just respected. Of course making
every interface completely not thought out and ad-hoc is a recipe for
pain.
> - method combination made the system harder to understand
This one runs completely counter to my experience. Mostly, I've seen
method combinations make a system easier. You can modify something
without having to understand all of what's going on, just a subset.
It seems like Picasso requires you to understand a complicated
interaction of all the methods, before you add or modify any. It's
not that I've never seen that before -- just, it's been pretty rare.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Paolo Amoroso wrote:
> Picasso is a graphical user interface development environment based on CLOS
> and CLX:
>
> http://s2k-ftp.cs.berkeley.edu:8000/picasso/
>
> It was developed in the early 1990s as a research project at UCB. This
> paper:
>
> Developing a GUIDE Using Object-Oriented Programming
> http://s2k-ftp.cs.berkeley.edu:8000/picasso/Picasso-papers/oopsla91.ps.Z
I have not figured out how to open that bad boy from win32 yet so I
cannot say anything about /that/ or Picasso or Picassoniks, but
addressing your list in the abstract:
> - CLOS complicated the system and made it harder for new developers to make
> major changes
This is the conclusion, I guess, nothing to respond to. as for the
details...
> - multiple inheritance required most classes to be designed to share
> superclass responsibilities
That's just "operator error". m/i does not misdesign class hierarchies,
people misdesign class hierarchies.
> - the CLOS model of inheritance does not support or encourage encapsulation
This should say "compiler-enforced encapsulation", and then it just says
CLOS is not C++. We Lispniks are kinda clear on that choice. We'd rather
work fast than in a strait jacket just to get some errors caught at
compile time.
> - class inheritance order with multiple inheritance
ha-ha-ha, this old oddity. I am still waiting for a real-world case
where this creates a problem, and when it arises I guarantee refactoring
will both eliminate the CPL problem /and/ be recognized as superior for
other reasons.
> - method combination made the system harder to understand
Did they mean non-standard combo, or the whole :around-:before-:after
thang? If the first, hell, I barely use it, when I do it's a joy. If the
latter, may I recommend TRACE? I detect a Barbie situation.
> - most changes to a base class required extensive rewriting in subclasses
No doubt, if as stated above they put superclass support into all the
subclasses. Operator error.
> Do these drawbacks match your experience in developing large systems?
No.
What I found was that I had to formulate a rule of thumb about multiple
inheritance. That took a while, and more than one massive redesign as
different possible rules proved unworthy. I also had to decide about the
model-view thing. tried it a couple of ways, settled on the one that was
simplest/easiest to live with. Subsections of the class hierarchy can
still get out of control, then I refactor. As for adding something to
every subclass to make a superclass work, Just Say No. Rethink.
CLOS and OO in general do not design our class hierarchies for us, just
as Lisp and HHLs in general do not write our algorithms for us. The list
above blames the tool for its misuse. Look at all the whining about m/i.
if m/i is so bad, why are they using it? think about that for a second.
I have seen "structured programming" code that was not structured
programming, and I have seen "relational database" schemas that were not
relational. In fact, I do both all the time. Then I fix them. Most
people, in my experience, do not. When problems arise they do not
revisit earlier design decisions--those somehow get cast in stone once
hit upon--instead they kludge up a workaround. And often these are
superbright people who can think up a kludge and get it working in a few
minutes. That is /so/ much easier and faster than refactoring.
Unfortunately kludges increase complexity exponentially, slowly at first
until they have reached a density at which they overlap.
Then yer dead, and it's time to write a paper on how OO sucks. Now let
me see if Mac OSX can open that paper. I have to check out the Apple
music store anyway...
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
In article <····························@4ax.com>,
Paolo Amoroso <·······@mclink.it> wrote:
> - CLOS complicated the system and made it harder for new developers to make
> major changes
> - multiple inheritance required most classes to be designed to share
> superclass responsibilities
> - the CLOS model of inheritance does not support or encourage encapsulation
> - class inheritance order with multiple inheritance
> - method combination made the system harder to understand
> - most changes to a base class required extensive rewriting in subclasses
> - performance (the authors, however, acknowledge that this was being
> addressed by vendors, and things were already improving)
>
> Do these drawbacks match your experience in developing large systems?
I can't comment on the details of this paper because I don't have enough
experience with CLOS. However, please note that the problems with
changes to base classes is a general issue in object-oriented
programming languages, not just with CLOS, and not just with multiple
inheritance.
Clemens Szyperski gives an example in his book on component software for
a single inheritance language. (I don't have the book at hand so I can't
give the exact page numbers at the moment.) I have also given an example
for Java in http://www.cs.uni-bonn.de/~costanza/vanishing_aspects.pdf
Pascal
Paolo Amoroso wrote:
>
> ...
> It was developed in the early 1990s as a research project at UCB. This
> paper:
>
> Developing a GUIDE Using Object-Oriented Programming
> http://s2k-ftp.cs.berkeley.edu:8000/picasso/Picasso-papers/oopsla91.ps.Z
>
> discusses, among other things, the drawbacks of CLOS development in
> Picasso. In short (see section "5. Discussion" of the paper for details),
> the drawbacks mentioned by the authors are:
>
> - CLOS complicated the system and made it harder for new developers to make
> major changes
> - multiple inheritance required most classes to be designed to share
> superclass responsibilities
i was surprised by this objection. in their discussion of this issue, they
described how their implementation evolved, and how they came to understand
that they needed to combine methods in a manner other than that which is
effected automatically by the standard method combination. yet, having
evidently understood in detail the behaviour of an alternative method
combination, they did not implement it and instead ascribed the problem to
multiple inheritance.
> - the CLOS model of inheritance does not support or encourage encapsulation
the clos model for inheritance concern encapsulation. on the other hand, the
claim that it does not "support" it is a misstatement. it may not include
forms to express complex scope restrictions. it does not need to. there are
features in the base language - in particular, packages and macros - which
make it possible to implement more sophisticated scoping rules given clos'
instance/class identifier scope.
> - class inheritance order with multiple inheritance
yes, the effect of multiple inheritance on order of applicable
multiple-dispatch methods can require careful consideration in order to
achieve the intended effect. as they noted, it may be advisable to formulate
purpose-specific method combinations to support their implementation in such cases
> - method combination made the system harder to understand
yes, a system which permits one to do more than invoke super.<x> has more to understand.
they said nothing about the complexity of a equivalent system written without
the method combinations.
> - most changes to a base class required extensive rewriting in subclasses
without reference to particular examples, they did mention a number of
factors. clos was the third. they did say that the problem arose "particularly
when changes involved adding or removing slots and methods". where these kinds
of changes require subclass changes, the other two factors are (generically
speaking) more likely causes: "poor object-oriented design", as in designing
subclasses to depend on superclass implementation, that is slots, and
"unavoidable given the nature of the changes", as in changing the interface
which corresponds to the methods. were there any specific descriptions in the
paper which represented issues with clos itself?
> - performance (the authors, however, acknowledge that this was being
> addressed by vendors, and things were already improving)
in order to lend any weight to their observations, they would have to have
comapred the performance of multimethods with the equivalent implementation as
multi-level functions. they mention that they were aware of the option. but
gave no comparisons between equivalent implementations.
...
On 8367 day of my life james anderson wrote:
>> - the CLOS model of inheritance does not support or encourage encapsulation
>
> the clos model for inheritance concern encapsulation. on the other hand, the
> claim that it does not "support" it is a misstatement. it may not include
> forms to express complex scope restrictions. it does not need to. there are
> features in the base language - in particular, packages and macros - which
> make it possible to implement more sophisticated scoping rules given clos'
> instance/class identifier scope.
Can you, please, give me example/reference/whatever?
--
Ivan Boldyrev
Onions has layers. Unix has layers too.
Ivan Boldyrev <···············@cgitftp.uiggm.nsc.ru> writes:
> On 8367 day of my life james anderson wrote:
> >> - the CLOS model of inheritance does not support or encourage encapsulation
> >
> > the clos model for inheritance concern encapsulation. on the other hand, the
> > claim that it does not "support" it is a misstatement. it may not include
> > forms to express complex scope restrictions. it does not need to. there are
> > features in the base language - in particular, packages and macros - which
> > make it possible to implement more sophisticated scoping rules given clos'
> > instance/class identifier scope.
>
> Can you, please, give me example/reference/whatever?
I think the simplest example of encapsulation with packages is
something like:
(in-package "FOO")
(defclass alpha ()
((this) (that) (the-other)))
(export '(this that))
(in-package "BAR")
(defclass beta ()
((one) (two) (three)))
(export '(one two))
(defpackage "BAZ"
(:use "CL" "FOO" "BAR"))
(defpackage "QUUX"
(:use "CL"))
Code in BAZ can refer to slots THIS, THAT, ONE, and TWO easily. Code
in QUUX can refer to them as FOO:THIS, FOO:THAT, BAR:ONE, and BAR:TWO.
It's *possible* to write FOO::THE-OTHER -- but anyone who does that
know's they're messing with the internals, with the literally
unexported interface. And in CLs with package locks, this would even
be an error.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Ivan Boldyrev wrote:
>
> On 8367 day of my life james anderson wrote:
> >> - the CLOS model of inheritance does not support or encourage encapsulation
> >
> > the clos model for inheritance [does not] concern encapsulation.
taken loosely, encapsulation refers to techniques for isolating particular
data structures and the procedures which operate on them from other aspects of
a program.
this may be realized as a language restriction that all instance variables
and all methods for a given class must be defined in the same source file, or
even within a single expression.
> > on the other hand, the
> > claim that it does not "support" it is a misstatement. it may not include
> > forms to express complex scope restrictions. it does not need to. there are
> > features in the base language - in particular, packages and macros - which
> > make it possible to implement more sophisticated scoping rules given clos'
> > instance/class identifier scope.
>
> Can you, please, give me example/reference/whatever?
it would be difficult to define multi-methods under strict encapsulation
constraints, but should one decide that such constraints are the right thing
for the problem, one could do something on the order of the illustrations in
http://home.arcor.de/james_anderson/mcl/encapsulate.lisp.
the first macro illustrates rather extreme encapsulation. the second
illustrates private/protected/public instance variable/method scope in terms
of symbol accessibility and class-specific packages.
...
Paolo Amoroso wrote:
> Picasso is a graphical user interface development environment based on CLOS
> and CLX:
>
> http://s2k-ftp.cs.berkeley.edu:8000/picasso/
>
> It was developed in the early 1990s as a research project at UCB. This
> paper:
>
> Developing a GUIDE Using Object-Oriented Programming
> http://s2k-ftp.cs.berkeley.edu:8000/picasso/Picasso-papers/oopsla91.ps.Z
>
> discusses, among other things, the drawbacks of CLOS development in
> Picasso. In short (see section "5. Discussion" of the paper for details),
> the drawbacks mentioned by the authors are:
>
> - CLOS complicated the system and made it harder for new developers to make
> major changes
> - multiple inheritance required most classes to be designed to share
> superclass responsibilities
> - the CLOS model of inheritance does not support or encourage encapsulation
> - class inheritance order with multiple inheritance
> - method combination made the system harder to understand
> - most changes to a base class required extensive rewriting in subclasses
> - performance (the authors, however, acknowledge that this was being
> addressed by vendors, and things were already improving)
>
OK, I managed to get the paper open and skimmed it. Gotta run, but it
seems a little schizo. They love CLOS, they hate CLOS. CLOS was a big
help, CLOS made things really hard. Even a specific feature like m/i
gets panned and praised.
The bottom line is that they love CLOS, probably misdesigned themselves
into a few corners, and pretty much just wanted to write an interesting
paper so they bit the hand that fed them a few times.
More after I read it more carefully. But I did see that they used the
classic contrived case to point out a "problem" with CLOS's calculation
of the CPL. Spare me. :)
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
In article <················@nyc.rr.com>,
Kenny Tilton <·······@nyc.rr.com> wrote:
> OK, I managed to get the paper open and skimmed it. Gotta run, but it
> seems a little schizo. They love CLOS, they hate CLOS. CLOS was a big
> help, CLOS made things really hard. Even a specific feature like m/i
> gets panned and praised.
I have also only skimmed the paper. Another problem I see with it is
that it doesn't seem to have any comparisons to other languages. The
reference section only lists one paper about Smalltalk and that's it, as
far as I can see.
So it doesn't seem to be clear at all whether the problems they mention
arise from the use of CLOS (or from their use of OOP), or if they are
inherent in the problem domain.
The only thing that the paper seems to prove is that programming large
systems is hard. ;)
Pascal
Kenny Tilton wrote:
>
>
> Paolo Amoroso wrote:
>
>> Picasso is a graphical user interface development environment based on
>> CLOS
>> and CLX:
>>
>> http://s2k-ftp.cs.berkeley.edu:8000/picasso/
>>
>> It was developed in the early 1990s as a research project at UCB. This
>> paper:
>>
>> Developing a GUIDE Using Object-Oriented Programming
>>
>> http://s2k-ftp.cs.berkeley.edu:8000/picasso/Picasso-papers/oopsla91.ps.Z
>>
>> discusses, among other things, the drawbacks of CLOS development in
>> Picasso. In short (see section "5. Discussion" of the paper for details),
>> the drawbacks mentioned by the authors are:
>>
>> - CLOS complicated the system and made it harder for new developers to
>> make
>> major changes
>> - multiple inheritance required most classes to be designed to share
>> superclass responsibilities
>> - the CLOS model of inheritance does not support or encourage
>> encapsulation
>> - class inheritance order with multiple inheritance
>> - method combination made the system harder to understand
>> - most changes to a base class required extensive rewriting in subclasses
>> - performance (the authors, however, acknowledge that this was being
>> addressed by vendors, and things were already improving)
>>
>
But they also say:
"CLOS made developing PICASSO fast and easy. ...We estimate that writing
the framework and tool-kit without CLOS, just in Common Lisp, would
require twice as many lines of code. The CLOS features discussed
in this paper (i.e., multiple inheritance, instance methods, and method
combinations) have saved 5000 to 10,000 lines of code and their use
resulted in a cleaner implementation.
"For the most part, CLOS has also been a great benefit when adding new
features and prototyping changes. Method combinations have made it easy
to experiment with new ideas. Multiple inheritance allowed us to
implement widgets such as radio-button groups in under
100 lines of code.
"With all this saved code and the benefit of the class
abstraction, you might infer that CLOS made PICAS-SO�s
implementation easier to understand. In fact, the
opposite was more often the case. CLOS complicated
the system and made it harder for new researchers to
make major changes."
CLOS complicated the system? Bad CLOS! Bad! :)
They then go into a very weird riff on how call-next-method (in primary
methods) sucks if you have two superclasses each of which provide the
same method and you want them both to run. Sounds like method combo
PROGN to me. But overall I think this is more like a review of a good
movie or book -- they had to find something to whine about.
Later they come clean:
"Most changes to a base class required rewriting
code in subclasses that inherited from the class
being changed particularly when the changes involved
adding or removing slots and methods. This effect is
partly a product of poor object-oriented design, partly
unavoidable given the nature of the changes, but partly
attributable to CLOS."
They are blaming CLOS for not having strait jackets, allowing them to
write bad code. At least they fess up to bad design and that this kind
of thing happens when you refactor.
Anyway, Paolo just asked if the negatives had been other folks'
experience...
nope. when I use m/i, the multiple superclasses provide different
functionality, so the whole call-next-method thing just seems bizarre to
me. i think they must have use m/i to inherit from muliple classes
offering the /same/ category of functionality and gotten into trouble
that way.
i basically identify narrower domains (input, output, focus management)
within the larger domain (GUI) and attack those with a
single-inheritance tree of classes never intended to be instantiated
standalone, then create real-world instantiable classes with one from
column A, one from column B. no overlap, no conflict. life is good.
and I /never/ use call-next-method in primary methods, not for religious
reasons, but because it just never comes up. before, after, around work
for me. the one time I needed it I looked again and realized I finally
had found a use for a different method combo, in this case, progn.
but they did like CLOS and they did credit it with making development
easier. the complaints (whosever fault) were real, but they worked
around them and wrote a paper for OOPSLA commenting on perceived
limitations of CLOS. They concluded:
"Using CLOS to develop the PICASSO GUIDE resulted in faster development,
easier prototyping, and more modular and compact code. Taking advantage
of CLOS features created complex interactions among classes and methods
that makes it hard for a new developer to learn the PICASSO
implementation and makes certain modifications difficult."
So overall even they found CLOS to be a net win. For me, CLOS never
presents a problem, but that might be because when I have a problem I
change the way I do things until the problem goes away. I don't fight
the tool (tho with Lisp I might extend it <g>).
I think they ploughed ahead stubbornly with practices inconsistent with
the way CLOS works, so of course they had a bad time.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
Kenny Tilton <·······@nyc.rr.com> writes:
> Kenny Tilton wrote:
>
> "With all this saved code and the benefit of the class
> abstraction, you might infer that CLOS made PICAS-SO�s
> implementation easier to understand. In fact, the
> opposite was more often the case. CLOS complicated
> the system and made it harder for new researchers to
> make major changes."
>
> CLOS complicated the system? Bad CLOS! Bad! :)
Well, I skimmed through the source code, and most of what was said in
this thread seems confirmed. The code is pretty thick, and there's
very little comments and no other documentation (most of the files
aren't even labeled with their purpose). That's probably the real
reason why it was hard for people new to the project to make major
changes.
Also, something you might be interested in is that Picasso comes with
a simple one-way lazy-evaluation constraint solver for CLOS slots.
Vladimir
Vladimir S. wrote:
> Also, something you might be interested in is that Picasso comes with
> a simple one-way lazy-evaluation constraint solver for CLOS slots.
Yeah, I got a kick out of that. They either loved it in Garnet and
recreated it, or they too developed it independently just because Cool
Hacks tend to spring from the fertile soil of Lisp. I wonder which.
You know, half-way thru my denunciation of the paper I remembered that
OO is a lot easier when one can associate rules with slots instead of
literals. I wonder if I would be so high on OO without Cells (which got
developed at the same time I was doing my first OO project, so I have
never done OO without them). But even if not, it would be OO in general
I would slam, not CLOS.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
"Paolo Amoroso" <·······@mclink.it> wrote in message
·································@4ax.com...
> Picasso is a graphical user interface development environment based on
CLOS
> and CLX:
>
> http://s2k-ftp.cs.berkeley.edu:8000/picasso/
>
> It was developed in the early 1990s as a research project at UCB. This
> paper:
>
> Developing a GUIDE Using Object-Oriented Programming
> http://s2k-ftp.cs.berkeley.edu:8000/picasso/Picasso-papers/oopsla91.ps.Z
>
> discusses, among other things, the drawbacks of CLOS development in
> Picasso. In short (see section "5. Discussion" of the paper for details),
> the drawbacks mentioned by the authors are:
>
> - CLOS complicated the system and made it harder for new developers to
make
> major changes
I didn't read the paper. No comment.
> - multiple inheritance required most classes to be designed to share
> superclass responsibilities
Using multiple inheritance "safely" is hard. Over the years, I have come
to regard multiple inheritance as a way to provide alternate implementations
to sets of abstract base classes. That is, I only use them as mix-ins.
> - the CLOS model of inheritance does not support or encourage
encapsulation
In Lisp, you use packages for encapsulation, not classes.
> - class inheritance order with multiple inheritance
Yup, MI is tricky.
> - method combination made the system harder to understand
I happen to agree with this. I tend to avoid complex method combination
these days, and typically break things into "before", "after", "around"
by adding explicit functions. This forces you to think harder about
exactly what is required, generally resulting in better design. Dylan
forced me to do this, which is what made me think harder about
the problem.
> - most changes to a base class required extensive rewriting in subclasses
In that case, they did a poor job figuring out where the abstractions
were and where divisions of responsibility lay. This is admittedly
hard to do, and requires careful thought.
> - performance (the authors, however, acknowledge that this was being
> addressed by vendors, and things were already improving)
>
> Do these drawbacks match your experience in developing large systems?
>
>
> Paolo
> --
> Paolo Amoroso <·······@mclink.it>
In article <······················@sccrnsc02>,
"Scott McKay" <···@attbi.com> wrote:
> > - method combination made the system harder to understand
>
> I happen to agree with this. I tend to avoid complex method combination
> these days, and typically break things into "before", "after", "around"
> by adding explicit functions.
What do you mean by "explicit funcions"? Do you mean explicit function
calls?
Pascal
"Pascal Costanza" <········@web.de> wrote in message
···································@news.netcologne.de...
> In article <······················@sccrnsc02>,
> "Scott McKay" <···@attbi.com> wrote:
>
> > > - method combination made the system harder to understand
> >
> > I happen to agree with this. I tend to avoid complex method combination
> > these days, and typically break things into "before", "after", "around"
> > by adding explicit functions.
>
> What do you mean by "explicit funcions"? Do you mean explicit function
> calls?
>
It means I add functions called something like 'post-draw-line'
or something, and ensure there is an explicit call in the protocol.
It sounds crazy, I know, but it means that you have to explicitly
enumerate all the little bits of a protocol *by name*. Yeah,
things like :before/:after/:around are great, but in the long run,
I decided that their convenience was also a source of trouble.
Scott McKay wrote:
>
> "Pascal Costanza" <········@web.de> wrote in message
> ···································@news.netcologne.de...
> > In article <······················@sccrnsc02>,
> > "Scott McKay" <···@attbi.com> wrote:
> >
> > > > - method combination made the system harder to understand
> > >
> > > I happen to agree with this. I tend to avoid complex method combination
> > > these days, and typically break things into "before", "after", "around"
> > > by adding explicit functions.
> >
> > What do you mean by "explicit funcions"? Do you mean explicit function
> > calls?
> >
>
> It means I add functions called something like 'post-draw-line'
> or something, and ensure there is an explicit call in the protocol.
>
> It sounds crazy, I know, but it means that you have to explicitly
> enumerate all the little bits of a protocol *by name*. Yeah,
> things like :before/:after/:around are great, but in the long run,
> I decided that their convenience was also a source of trouble.
this warrants further explanation. what kind of trouble?
how does a draw-line function with a method combination which includes a post
method necessarily differ from adding "functions called something like 'post-draw-line'"?
was it that the implicit control structure in :before/:after methods was not adequate?
was it that you needed an alternative specialization taxonomy in the
'post-draw-line' kind of functions?
...
"james anderson" <··············@setf.de> wrote in message
······················@setf.de...
> Scott McKay wrote:
> >
> > "Pascal Costanza" <········@web.de> wrote in message
> > ···································@news.netcologne.de...
> > > In article <······················@sccrnsc02>,
> > > "Scott McKay" <···@attbi.com> wrote:
> > >
> > > > > - method combination made the system harder to understand
> > > >
> > > > I happen to agree with this. I tend to avoid complex method
combination
> > > > these days, and typically break things into "before", "after",
"around"
> > > > by adding explicit functions.
> > >
> > > What do you mean by "explicit funcions"? Do you mean explicit function
> > > calls?
> > >
> >
> > It means I add functions called something like 'post-draw-line'
> > or something, and ensure there is an explicit call in the protocol.
> >
> > It sounds crazy, I know, but it means that you have to explicitly
> > enumerate all the little bits of a protocol *by name*. Yeah,
> > things like :before/:after/:around are great, but in the long run,
> > I decided that their convenience was also a source of trouble.
>
> this warrants further explanation. what kind of trouble?
>
> how does a draw-line function with a method combination which includes a
post
> method necessarily differ from adding "functions called something like
'post-draw-line'"?
Perhaps it is just the fact that you can see the 'post-draw-line' call in
the source code. I have experienced a little trouble as well with a large
use of before, after, around methods. I happen to think these are a
fabulous tool and would not give them up for anything, but, depending on
effectiveness of design, documentation and organization of source code it
can begin to fell like spahgetti! Anyway, rope, hanging and all that...
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
"Coby Beck" <·····@mercury.bc.ca> wrote in message
··················@otis.netspace.net.au...
>
> "james anderson" <··············@setf.de> wrote in message
> ······················@setf.de...
> > Scott McKay wrote:
> > >
> >
> > this warrants further explanation. what kind of trouble?
> >
> > how does a draw-line function with a method combination which includes a
> post
> > method necessarily differ from adding "functions called something like
> 'post-draw-line'"?
>
> Perhaps it is just the fact that you can see the 'post-draw-line' call in
> the source code. I have experienced a little trouble as well with a large
> use of before, after, around methods. I happen to think these are a
> fabulous tool and would not give them up for anything, but, depending on
> effectiveness of design, documentation and organization of source code it
> can begin to fell like spahgetti! Anyway, rope, hanging and all that...
>
Exactly -- it's easier to document the protocol when all the
participants have names. The more complex the system, the
more of an issue it becomes.
I am just related my experience. When I moved from Lisp to
Dylan, I initially thought that the simpler method-combination
model would be unduly difficult. After using it for a few years,
I concluded that the restrictive model forced me to come up
with better designs. Now that I am using Lisp again, I find
myself applying the Dylan model because the documentation
and design notes are simpler.
"Scott McKay" <···@attbi.com> writes:
> "Coby Beck" <·····@mercury.bc.ca> wrote in message
> ··················@otis.netspace.net.au...
> >
> > "james anderson" <··············@setf.de> wrote in message
> > ······················@setf.de...
> > > Scott McKay wrote:
> > > >
>
> > >
> > > this warrants further explanation. what kind of trouble?
> > >
> > > how does a draw-line function with a method combination which includes a
> > post
> > > method necessarily differ from adding "functions called something like
> > 'post-draw-line'"?
> >
> > Perhaps it is just the fact that you can see the 'post-draw-line' call in
> > the source code. I have experienced a little trouble as well with a large
> > use of before, after, around methods. I happen to think these are a
> > fabulous tool and would not give them up for anything, but, depending on
> > effectiveness of design, documentation and organization of source code it
> > can begin to fell like spahgetti! Anyway, rope, hanging and all that...
> >
>
> Exactly -- it's easier to document the protocol when all the
> participants have names. The more complex the system, the
> more of an issue it becomes.
I agree. But you have to come up with some way of naming methods one
way or another, if you want to name methods of GFs. So,
(FOO (T T THING)), for example. Or (FOO :AROUND).
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Scott McKay wrote:
> "Coby Beck" <·····@mercury.bc.ca> wrote in message
> ··················@otis.netspace.net.au...
>>Perhaps it is just the fact that you can see the 'post-draw-line' call in
>>the source code. I have experienced a little trouble as well with a large
>>use of before, after, around methods. I happen to think these are a
>>fabulous tool and would not give them up for anything, but, depending on
>>effectiveness of design, documentation and organization of source code it
>>can begin to fell like spahgetti! Anyway, rope, hanging and all that...
>>
>
>
> Exactly -- it's easier to document the protocol when all the
> participants have names. The more complex the system, the
> more of an issue it becomes.
<tee-hee> youse guys are going to hate Cello; you can't see anything,
it's all declarative. How are mouse-ups handled?:
(setf (mouseUp *system*) <mouse-up event>)
Wanna know what happens next? You can't! But then that's the declarative
game. You cannot look at a cell in a VisiCalc speadsheet and know what
else will change when it changes. The good news is that you just have to
write your formulas correctly, then the Right Thing Just Happens.
Likewise with CLOS and before, after, and around.
The nice thing about Lisp is that there are so many ways to find out
what is going on (trace, print statements, assertions) and they can be
turned on and off programmatically or during breaks etc etc etc.
You know, speaking of knowing what the hell is going on, the OOPLA91
paper /did/ say one thing needed was CLOS browsers and other IDE tools
(show all methods for a GF comes to mind). The IDEs I use (MCL and ACL)
have offered those, maybe twelve years later the picassoniks would write
a different paper.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
Scott McKay wrote:
>
> "Coby Beck" <·····@mercury.bc.ca> wrote in message
> ··················@otis.netspace.net.au...
> >
> > "james anderson" <··············@setf.de> wrote in message
> > ······················@setf.de...
> > > Scott McKay wrote:
> > > >
>
> > >
> > > this warrants further explanation. what kind of trouble?
> > >
> > > how does a draw-line function with a method combination which includes a
> > post
> > > method necessarily differ from adding "functions called something like
> > 'post-draw-line'"?
> >
> > Perhaps it is just the fact that you can see the 'post-draw-line' call in
> > the source code. I have experienced a little trouble as well with a large
> > use of before, after, around methods. I happen to think these are a
> > fabulous tool and would not give them up for anything, but, depending on
> > effectiveness of design, documentation and organization of source code it
> > can begin to fell like spahgetti! Anyway, rope, hanging and all that...
> >
>
> Exactly -- it's easier to document the protocol when all the
> participants have names. The more complex the system, the
> more of an issue it becomes.
>
i remain uncertain about the nature of this problem, as described.
is it that one would need more specific static names? to debug? to document?
in which case why is (draw-line :after) any less adequate than post-draw-line?
how does it differ from (setf xyz)? was it that the tools did not support
source code management in those terms?
is it that one would need more effective dynamic navigation tools? something
which would make clear the constitution of the effective method given a
particular dynamic/stack state? if the particular debugger did not provide
these, what was it about the introspective navigation/presentation
requirements which led one to redesign the software rather than design the
requisite analysis tools?
> I am just related my experience. When I moved from Lisp to
> Dylan, I initially thought that the simpler method-combination
> model would be unduly difficult. After using it for a few years,
> I concluded that the restrictive model forced me to come up
> with better designs. Now that I am using Lisp again, I find
> myself applying the Dylan model because the documentation
> and design notes are simpler.
i spent years writing object-lisp before clos. i still do specialize some
methods on one parameter only. and some functions have primary methods only.
if that's the way the problem factors.
...
Hi Paolo Amoroso,
> Picasso is a graphical user interface development environment based on
> CLOS and CLX:
>
> http://s2k-ftp.cs.berkeley.edu:8000/picasso/
Interesting discussion Paolo. Perhaps a better reason people were not
enthusiastic to learn to extend it is that it is proprietary software with
no right to deploy it commercially. From the COPYRIGHT file:
PICASSO Graphical User Interface Development System
Copyright (c) 1990,1991 Regents of the University of California
Permission to use, copy, modify, and distribute this software and its
documentation for educational, research, and non-profit purposes and
without fee is hereby granted, provided that the above copyright
notice appear in all copies and that both that copyright notice and
this permission notice appear in supporting documentation, and that
the name of the University of California not be used in advertising
or publicity pertaining to distribution of the software without
specific, written prior permission. Permission to incorporate this
software into commercial products can be obtained from the Campus
Software Office, 295 Evans Hall, University of California, Berkeley,
Ca., 94720. The University of California makes no representations
about the suitability of this software for any purpose. It is
provided "as is" without express or implied warranty.
"CLOS complicated the system and made it harder for new researchers to
make major changes." New researchers would simply look over their shoulder
at how the Regents of the University of California licensed BSD and think
"Forget this. I'm off to learn something I can commercialise."
Regards,
Adam
Paolo Amoroso <·······@mclink.it> writes:
> Picasso is a graphical user interface development environment based on CLOS
> and CLX:
>
> http://s2k-ftp.cs.berkeley.edu:8000/picasso/
>
> It was developed in the early 1990s as a research project at UCB. This
> paper:
>
> Developing a GUIDE Using Object-Oriented Programming
> http://s2k-ftp.cs.berkeley.edu:8000/picasso/Picasso-papers/oopsla91.ps.Z
>
> discusses, among other things, the drawbacks of CLOS development in
> Picasso. In short (see section "5. Discussion" of the paper for details),
> the drawbacks mentioned by the authors are:
>
> - CLOS complicated the system and made it harder for new developers to make
> major changes
Most of what makes systems hard to understand falls outside of the
source code implementation itself.
a) What is the system modeling? For really important systems, this is
your biggest hurdle to getting up to speed. Getting people
comfortable with workflow in a wafer fab or the concerns of
space-based observatory are by far the biggest cost of getting
programmers up to speed.
b) How are certain aspects of the world embedded in the system?
Figuring out the mapping of the domain into the system can be hard.
Commonly, there are painful nomenclature issues that make it hard to
figure out what the code is saying relative to the domain. Sometimes
this is because the domain has inconsistent nomenclature that the
program has to disambiguate. Other times the domain nomenclature is
overly complex or misleading and so the program uses simpler or
clearer terms.
c) What are the architecture, design and programming conventions? For
a complex or novel application, usually, this needs to be described
and understood independently of the any particular piece of
application code. This can also be hard because much of this
information is only available via lore out of other people's heads.
Experts forget what they know and how they learned it, so often they
aren't too helpful in instructing the newcomer.
If you have significant lack in a, b or c, understanding the code is
going to be painful if the design and implementation are excellent.
Once you have a grip on these factors, I don't think the language per
se is much of a factor. At that point, what makes the program easy or
hard is good judgment and good style--things that don't come easy.
I disagree with the paper's criticism of the linguistic aspects of
CLOS for the above reasons. However, there is a social factor lurking
in the spaces of the argument. Many programmers simply aren't
motivated to master language features, particularly subtle ones.
People don't like to think hard and often can't be bothered to do
anything but brute force a solution in terms of what they know
presently. For this reason, I think there are plenty of contexts in
which it makes sense to present a conservative set of legal mechanisms
to the application programmer. But arguing that a language might be
better because you can do less with it is silly of course. It's a
technical solution to a social problem. Convention and infrastructure
are better vehicles. (This is somewhat afield of the papers content,
but related).
I think having got to heart of the issues raised, one finds them
operative no matter what set of language features you have to work
with.
--
John Michael Adams
·······@stsci.edu (John M. Adams) writes:
> If you have significant lack in a, b or c, understanding the code is
> going to be painful if the design and implementation are excellent.
Oops. In the previous note I meant EVEN if the design and
implementation are excellent.
--
John Michael Adams
John M. Adams wrote:
> Many programmers simply aren't
> motivated to master language features, particularly subtle ones.
> People don't like to think hard and often can't be bothered to do
> anything but brute force a solution in terms of what they know
> presently. For this reason, I think there are plenty of contexts in
> which it makes sense to present a conservative set of legal mechanisms
> to the application programmer.
Here is the flaw I see in that attractive argument: what does this
crappy programmer do with their crappy language when confonted by a
problem that cries out for the more powerful tool? They do /not/ build
an elegant substitute mechanism out of the conservative set of more
primitive mechanisms.They just start hacking randomly and create vastly
more unmaintainable code even harder for new team members to grok.
If lame tools also magically made hard problems go away... now yer talkin!
You know, Lisp is pretty powerful. How about a tool to parse code when
it gets checked back in? If Billy Bob defines a new class with multiple
superclasses and he has not been certified for multiple inheritance, the
check-in fails. he has to call a manager over with a key to...
:)
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
Kenny Tilton <·······@nyc.rr.com> writes:
> John M. Adams wrote:
> > Many programmers simply aren't
> > motivated to master language features, particularly subtle ones.
> > People don't like to think hard and often can't be bothered to do
> > anything but brute force a solution in terms of what they know
> > presently. For this reason, I think there are plenty of contexts in
> > which it makes sense to present a conservative set of legal mechanisms
> > to the application programmer.
>
> Here is the flaw I see in that attractive argument: what does this
> crappy programmer do with their crappy language when confonted by a
> problem that cries out for the more powerful tool? They do /not/ build
> an elegant substitute mechanism out of the conservative set of more
> primitive mechanisms.They just start hacking randomly and create
> vastly more unmaintainable code even harder for new team members to
> grok.
>
>
> If lame tools also magically made hard problems go away... now yer talkin!
>
> You know, Lisp is pretty powerful. How about a tool to parse code when
> it gets checked back in? If Billy Bob defines a new class with
> multiple superclasses and he has not been certified for multiple
> inheritance, the check-in fails. he has to call a manager over with a
> key to...
I more or less agree with your sentiments. I don't think our views
are incompatible. To `present a conservative set of legal mechanisms
to the application programmer' doesn't imply crappy programmers or
crappy languages or lame tools. It could just mean architectural
doctrine or libraries or a set of ready-made idioms (like COSI, for
example which is Lisp code and hopefully not lame).
--
John Michael Adams