niko.schwarz at gmx.net
Mon Feb 3 21:11:09 UTC 2003
-----BEGIN PGP SIGNED MESSAGE-----
Am Montag, 3. Februar 2003 15:59 schrieb goran.hultgren at 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
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
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.
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
-- Marshall Brickman, Playboy, April, 1973
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the Squeak-dev