Hi all!

Niko Schwarz niko.schwarz@gmx.net wrote:

Am Montag, 3. Februar 2003 13:28 schrieb goran.hultgren@bluefish.se:

...

Well, the image is in fact simply wonderful - a world of objects that interact with each other with full dynamics. But of course the freedom and dynamics of an image makes modules etc much more complicated. But as a Smalltalker I would never give up the image just to get "nice modules".

Hey Göran, how about self which joins code and image into the same thing. To be honest I like the idea of self that the separation of classes and objects is unnecessary, and I love the slot concept too, which draws no difference between function calls and accesses to instance variables.

I agree - both these aspects of Self are intriguing. I haven't worked in self so I can't say anything from personal experience.

I think modules should contain objects too. When you draw no difference between image and code, you need no gui-builder, cos you can simplystick together some widgets to a gui and then save it somewhere in the snapshot, and when code needs the gui, it simply loads the gui, without constructing it widget by widget. And when modules contain objects anyway -- why would we bother to separate code and object space?

Well, personally I think it comes down to a matter of how we want to think about our software artefacts. Even if Self proved that "Hey, classes are unnecessary" I don't think we would construct better and clearer software if we simply started mixing behaviour and data "as we please" and forgot about classes. I bet that Self programs *have* classes, they are just not called that.

The idea of building UIs "by hand" and then simply keeping the instances around has been tried several times and AFAIK it has been shown to have its own problems. One issue is that object structures can be quite big and complex and when you develop code that builds them it can be very easy to simply change a line and then affect the complete structure. If there was no code to change then you would need to try to change the structure "in place" instead of simply rebuilding it from scratch.

Another issue is that the objects you use in your UI may have changed (new version of the UI toolkit for example) and you need to evolve your code to fit with the new toolkit - not very easy to do either.

But anyway - the issue of focusing on "objects" instead of "source code" in the modularization effort has been discussed a lot on this list previously. IMHO I think that "simplifying" the question by saying that - hey, if we instead base the modules model on objects then "the rest will follow" simply is an oversimplification.

Anthony has been pushing this idea earlier (I think) and I don't claim to know the truth or have more knowledge than he has (I certainly don't) but I still think it is an "oversimplification".

To try one more silly analogy (I know it is limping but perhaps my point can be understood anyway):

We all know "everything" in the image are objects, much like molecules are in real life. Now, let's pretend that the image is the human body and that the different modules are the organs - the heart, brain, lungs, limbs etc.

If I told a surgeon that "Hey, if you just figure out how to keep track of the dependencies between the molecules in the body - then you will as, a sideeffect, have solved the problem of knowing the dependencies between the organs!".

I think the surgeoun would laugh at me. He would say that, "It's a bit more complex than that. You can't just figure out how the organs interact by looking how the molecules connect to each other. For example, the heart pumps blood out into the other organs. So all other organs are dependent on the heart. But many of the organs aren't even touching the heart are they?"

Whatever - I will stop my silly analogy here. ;-) Two small facts I stand by:

1. Smalltalk code is our way of capturing the dynamics of the image in a declarative way. We need declarative descriptions of our systems to be able to think about them - it's just the way we work as humans. At least until we can plug the computer directly into our brains. Simply dragging and drooling will not cut it (instance based programming á la Parts or whatever).

2. The dependencies in Smalltalk code are hard to capture and describe. It is not impossible but do not underestimate the problem. People who have tried like Joseph Pelrine and Henrik Gedenryd (two different approaches) can surely tell us more about the complexities involved. I also guess that Allen Wirfs-brock can tell us more about what is involved too. No pressure intended. ;-)

regards, Göran

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Am Montag, 3. Februar 2003 14:16 schrieb goran.hultgren@bluefish.se:

I agree - both these aspects of Self are intriguing. I haven't worked in self so I can't say anything from personal experience.

Neither have I, unfortunately, but I found the idea very tempting.

I bet that Self programs *have* classes, they are just not called that.

They have traits, and behaviour. If I understood it all correctly, the logic is this: When I want a car, why would I search for a concept for a car (the class) rather than for a car itself? So, what selfers do is write a proto-car, a fully blown car ready to rock, which you then copy if you want your "instances". objects inherit from one another (multiple ways, too. it complains when there would be two functions of that name), and it elegantly solves issues like globals: you simply inherit them from the Behaviour object, same as you find the other prototypes: they are in a tree which you can inherit, if you want it.

The idea of building UIs "by hand" and then simply keeping the instances around has been tried several times and AFAIK it has been shown to have its own problems.

[short description]

Yes, that sounds convincing. Another way would be to create a grammar that describes how the objects are organized. That would as well simplify the process of creating a UI-builder. Please don't take me too serious, I'm just thinking aloud: I suppose it is simpler to write a ui-builder that stores its information in a description format, rather than producing smalltalk code that builds this ui. (like: ud teach every morph to print itself into an xml-tag). With this approach, too, you would have an abstract ui description, which would be nice to store in the snapshot, and in your module, when you ship it.

But anyway - the issue of focusing on "objects" instead of "source code" in the modularization effort has been discussed a lot on this list previously. IMHO I think that "simplifying" the question by saying that

• hey, if we instead base the modules model on objects then "the rest

will follow" simply is an oversimplification.

I guess. But pushing whole squeak more in this direction, not just modules, might be a useful approach. Maybe we two should take a better look at self and if this whole stuff really simplifies work, there =)

We all know "everything" in the image are objects, much like molecules are in real life. Now, let's pretend that the image is the human body and that the different modules are the organs - the heart, brain, lungs, limbs etc.

If I told a surgeon that "Hey, if you just figure out how to keep track of the dependencies between the molecules in the body - then you will as, a sideeffect, have solved the problem of knowing the dependencies between the organs!".

=) Nice analogy. But I understand self much simpler. It doesnt claim that it can tell you the dependencies better, it just wants to say that splitting the body into two separate parts: organ-color and organ-form, you will not simplify the process of understanding. better would be to watch at the organs in both their aspects all the time: color and structure.

regards,

nick

- -- Your home electrical system is basically a bunch of wires that bring electricity into your home and take if back out before it has a chance to kill you. This is called a "circuit". The most common home electrical problem is when the circuit is broken by a "circuit breaker"; this causes the electricity to back up in one of the wires until it bursts out of an outlet in the form of sparks, which can damage your carpet. The best way to avoid broken circuits is to change your fuses regularly. Another common problem is that the lights flicker. This sometimes means that your electrical system is inadequate, but more often it means that your home is possessed by demons, in which case you'll need to get a caulking gun and some caulking. If you're not sure whether your house is possessed, see "The Amityville Horror", a fine documentary film based on an actual book. Or call in a licensed electrician, who is trained to spot the signs of demonic possession, such as blood coming down the stairs, enormous cats on the dinette table, etc. -- Dave Barry, "The Taming of the Screw"

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Hola,

Am Montag, 3. Februar 2003 15:59 schrieb goran.hultgren@bluefish.se:

Me too, but more from the perspective of simplification than for "making cool solutions nobody groks". :-)

=)

Yes, I have read about Self so this is in line with my limited knowledge. You instantiate by "cloning" and you do inheritance by delegation. But as you say there are so called "Behaviour objects" etc.

• in my ears this is still mimicking classes in some way.

In short - as a programmer I need to describe "types" and associate behaviour with those types of objects. We can do this using many different mechanisms (Traits, Self delegation, class inheritance etc) but in the end we are still expressing the same thing - we are describing objects with different sets of behaviours.

Of course. But after all, this would even be true for C++ and even for C with its structures: youre defining mechanisms to handle data. but maybe its the classes here mimicking the objects, separating something that doesnt need to be separated, but can instead be modularized into behaviour and data, rather than being hardsplitted. I mean: wasnt that always the strong side of smalltalk: a simple paradigm, making things simple and elegant through its flexibility?

So in the end I assume Self has similar problems with modularization as all the other OO languages, especially the dynamically typed ones. So dropping classes is no silver bullet. I assume.

=) Yes, probably. I don't even think squeak would need any "silver bullet" besides speed (morphic is just sluggish sometimes on my 800Mhz Athlon). But the logic is just too tempting: when I access the "size" attribute of my class from function rotate: why should I worry if it is an instance variable or a function call. Smalltalk clearly draws a line here where none is needed: I don't care if I "know" it or must first load 'size' from a database.

IMHO this is a very good way of doing UIs. Personally I like either coding them by hand (total power, much easier to make components and debug) or by using some form of declarative description and a builder as they did it in StableSqueak/Glade etc.

I agree. Although the ladder requires some experience in the toolkit. It's hard to explore UI creation like you can explore everything in squeak. Just my subjective impression, of course.

[stephen pair] has some really cool technology for doing remote object memories. That last part can really change a lot in the Squeak world...

Can I find out more about it?

...

Maybe we two should take a better look at self and if this whole stuff really simplifies work, there =)

I am not sure there are enough experience in the Self world to draw from. I mean - what should we look at? Perhaps I have missed something but to me Self has always seemed a bit "academic". I haven't seen any major "day to day" work being done in it. But I may be totally wrong of course.

I don't think you are. But nevertheless, that technologies didn't succeed on the market might just mean they came out before time - who would know that better than smalltalkers, who are inventing croquet nowadays =)

I like the way we approach the problem now. We do it step-by-step. First we created a simple package registration mechanism (SqueakMap). Then Ned created the SAR-format and Avi created DVS. The next logical steps are enhancing SqueakMap with information about releases enabling us to record dependencies between packages and evolving DVS into Monticello for team development. When that is in place the final step is to try to automate dependency detection and install/uninstallation to satisfy the dependencies. These two things are HARD. But if we keep them for last it doesn't matter if they take time. :-)

=) I hope it'll get to work, and that I might contribute to squeak's development at some place.

regards,

nick - -- The Soviet pre-eminence in chess can be traced to the average Russian's readiness to brood obsessively over anything, even the arrangement of some pieces of wood. Indeed, the Russians' predisposition for quiet reflection followed by sudden preventive action explains why they led the field for many years in both chess and ax murders. It is well known that as early as 1970, the U.S.S.R., aware of what a defeat at Reykjavik would do to national prestige, implemented a vigorous program of preparation and incentive. Every day for an entire year, a team of psychologists, chess analysts and coaches met with the top three Russian grand masters and threatened them with a pointy stick. That these tactics proved fruitless is now a part of chess history and a further testament to the American way, which provides that if you want something badly enough, you can always go to Iceland and get it from the Russians. -- Marshall Brickman, Playboy, April, 1973

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Am Montag, 3. Februar 2003 18:28 schrieb Brian T Rice:

It's very good for you to admire this idea, but Self never implemented anything like it. The VM and the optimized code is/was separate from the image, and was a big source of problems that way.

Are you sure that's true for the current version? I can't get to run it for some mysterious error message, I'm currently reporting to the interest group, but if I understood the tutorial correctly, it does not separate.

regards,

nick - -- WARNING TO ALL PERSONNEL:

Firings will continue until morale improves.