"Oops..." an article needing a reply?

Kendall Shaw queshaw at pacbell.net
Wed Mar 15 00:32:10 UTC 2006


Blake wrote:
> On Mon, 13 Mar 2006 10:49:38 -0800, Craig Latta <craig at netjam.org> wrote: 
>>
>>     Yet another fluff piece from O'Reilly. Wow, what a surprise.
> 
> I don't think I'd describe it as "fluff", exactly. A fluff piece usually 
> just repeats some conventional wisdom and is harmless. Though perhaps 
> that's what he IS doing, and I'm simply not aware of the conventions the 
> wisdom is coming from.<s>

I feel like I haven't really gotten a foothold in thinking about OO yet, 
but my take on the article was that the author was actually arguing 
against OO as a sort of procedural programming in a special syntax 
together with inheritance, rather than actual object orientation. The 
Mr. Kay email earlier in this thread didn't seem to me to contradict 
what the author of the article was saying in substance.

The teetering towers of fragile class trees idea, if I have the 
terminology right, is something I continue to read about and it's right 
at the center of where I lack confidence in my understanding of OO.

My impression is that that problem is not well understood by people that 
implement software that many of us have to use. So, I would read into 
that a concern about the state of OOP in practice.

I remember reading a posting earlier about some object, Morph I think, 
that I remember has a comment saying please don't override certain 
methods here because it will break things. So, apparently it's an issue 
of some concern in squeak as well.

It's uninteresting if the author was saying oop is good or oop is bad, 
the substance of his argument is more interesting.

> The second half, I couldn't follow at all. It wasn't clear to me that 
> what he was proposing was any different from what we already have--a 
> kind of chaotic mixture of expedient solutions.

I didn't take him to be saying that XML syntax and javascript and web 
this and web that are the answer. He talks about the separation of 
intention and syntax. I think that is interesting.

As a novice, a problem I continue to have sporadically looking at 
smalltalk is that it seems like a rather small isolated place in which 
you have to talk. The environment seems very isolating, and it seems to 
me like a problem of being bound to a syntax.

Maybe that's a way to avoid having to be corrupted by the view of the 
world as being made up of procedures operating on data, when you 
interact with the world and it's other programmers. But I want to 
interact with the world.

So, I think it might be necessary to find some way to not be bound by 
syntax in order to interact with the world, that doesn't require you 
think in terms of "remote procedure calls" as that Mr. Kay email says.

These days I've been studying graphics. An approach I could take is to 
pick a syntax, e.g. morphic or opengl etc., and learn little bits of 
math together with the specifics of how to use an API.

It's very different to approach graphics using SVG as a study aid while 
learning about graphics, because SVG is declarative. There is less of 
the notion that you have procedures operating on data.

Or XSL-FO might be a better example of this idea, with respect to 
typesetting/(voicesetting?). XSL-FO doesn't so much describe an API as a 
model of pages and speech that can be used. XSL suggests approaching FO 
production as developing transformation specifications that are 
descriptions of a resulting document.

XML/SGML and Lisp seem to me to suggest this same idea.

This isn't expressing the idea that "the world is made of of streams and 
transformations". It's not saying let's all put everything in XML and 
use a transformation language, or let's use lisp.

If I read the author correctly, he was expressing the same notion of 
using representations of systems as cooperating objects, that Mr. Kay 
seemed to be talking about. He was then elaborating on developing 
systems in terms of abstractions beyond APIs and language syntax.




More information about the Squeak-dev mailing list