Squeak-dev December 2006

squeak-dev@lists.squeakfoundation.org

112 participants
144 discussions

veryDeepCopy, ImageSegments, and actionMaps
by Ned Konz 17 Aug '23

17 Aug '23

Any Object can have dependents whether or not it has an instance variable to keep track of them (these are kept in the DependentsFields class variable of Object). The only class that keeps its own dependents is Model. Any Object can have an actionMap. These are supplied by EventManager class by default, and are stored in the ActionMaps class variable of EventManager. The only class that keeps its own action maps is Morph. When we veryDeepCopy an object we also copy the global dependents (see DeepCopier>>fixDependents). However, we don't copy the actionMap in those cases where it's held by the EventManager class. When we file out an object that uses DependentsFields out into an ImageSegment, we also file out the dependents (see ImageSegment>>dependentsSave:) if it's in a project. We do this by adding a project parameter called #GlobalDependentsInProject. However, we don't file out the actionMap in those cases where it's held by the EventManager class. My question is this: should we fix these behaviors (copying and serialization) to include these "global action maps" just like we already include the "global dependents"? Or should we discourage the use of the "global action maps"? -- Ned Konz http://bike-nomad.com GPG key ID: BEEA7EFE

3 2

Trying to build SerialPlugin for IrDA under MPW (MacOS 8.6)
by Hans-Martin Mosner 24 May '12

24 May '12

Hi, I recently got a serial IrDA adapter and wanted to play around with it under Squeak. This adapter has a baudrate switching mechanism which depends on toggling the DTR and RTS lines in the correct sequence. To support this, I wanted to build a new SerialPlugin with an additional primitive. However, the plugin as built with MPW does not seem to be accepted by the VM, which still uses the internal plugin in all cases. I've tried placing the plugin in a 'Plugins' subfolder of the VM's folder, and then directly into the VM folder, without any success. I have considered placing debug outputs in appropriate places in the VM, but building a complete VM with MPW is not easy - I would have to create an MPW makefile for the whole shebang, which is more work than I can invest at the moment. Does any of you Mac aficionados have an idea where the problem could be? I have appended the plugin and corresponding source files in a ZIP file (it's not big) so if you want to try it out you could do it right now :-) BTW, would it make sense to incorporate support for switching serial port parameters of an open port into the standard plugin? Closing and opening a port just to change the baud rate seems a little overkill... Cheers, Hans-Martin

6 14

Squeak download stats?
by Thomas A Petersen 27 Feb '11

27 Feb '11

Greetings, FWIW, I download beta/gamma versions about once a month to test. Those that prove stable get my influx of current work for day to day use. I download the official version and move to it if it proves stable for my uses until about the middle of the next beta cycle. I also have a couple of friends that I pass the stable specialized images on to about once a year. A couple of other people I know pull the distribution for Windows and/or Linux when I let them know there is an official upgrade. Thanks again for a great place to think and learn, tap

6 5

TextMorph behavior
by Marcus Pedersén 18 Jan '11

18 Jan '11

Hi! I have been trying class TextMorph out for making an editable textfield for my GUI. One thing I can't figure out is how to make the text "grow" horisontaly when you write instead of verticaly. I am after the behavior similar to the spotlight search text field in mac. If you write loads of text the oldest text "dissapear" (visualy) on the left hand. I have tried autoFit: false and wrapFlag: false without any desired results. Doesn't TextMorph contain this functionality from start? Do I need to subclass and write the function from scratch? Many thanks in advance! Marcus

5 5

Loading the OpenGL package (was: Games with Squeak)
by Diego Fernandez 17 Apr '09

17 Apr '09

On 10/13/06, Andreas Raab <andreas.raab(a)gmx.de> wrote: > Edgar J. De Cleene wrote: > > Andreas, as you see no package said " OpenGL" in the provided link. > > I think you should learn a little about using Squeaksource: "Versions" Ouch! I missed the package too, because in www.squeaksource.com usually there is one MC package per "Project". Anyway, I'm trying to load OpenGL-ar.36.mcz in Squeak 3.9 but I get: Syntax Error: glBindBufferARB(target, buffer) "This method was generated by OGLExtManager" <Argument expected ->apicall: void 'glBindBufferARB' (long ulong)> Any clue on how to solve this error? (It looks that it's created with a "special" compiler) And another question... As I wrote in the previous mail I've started to do some SDL bindings. But I think that maybe it's a waste of time, since today nearly all machines have OpenGL, and Squeak already has objects to deal with sound and joysticks.... so instead of using SDL for 2D graphics is better to use OpenGL for the same thing, what do yo thing about that? Cheers, Diego

10 19

What is the proper way to get the Refactoring Browser in 3.9
by Hilaire Fernandes 07 Dec '07

07 Dec '07

I have installed RB and AST from SqueakMap for 3.9, but I have many random problem swith features not working as hierarchy browsing, simple editing in the browser, refactoring tools as renaming methods. These problems happen more or less randomly. Hilaire

4 13

SqF feedback
by stéphane ducasse 21 Jul '07

21 Jul '07

Hi I'm reposting this email since I have the impression that the point was lost in its original thread. ... - Normally after election, politicians do not really listen anymore and I would like to do the inverse. I would really like to know what you expect or would like to see put in place. We have some ideas (bounty system, better process) and I will really listen what the new boarders want to do (I'm even eager to see that :)). We do not have the monopole of good ideas, so if you have some points that you would like to see happening please mention it. Stef

9 10

hash method
by Houssam Fakih 31 Jan '07

31 Jan '07

Hi, When I redefine the = operation for a class I should redefine its hash method. My question is about the definition of the hash method. I read that the method must return a SmallInteger whose value is related to the receiver. I would like to know if there is a general pattern adopted in Squeak for that. I get a look in the Squeak classes but it doesnt help. Thanks, Houssam ____ "Le paradis touche les pieds des mères..." >>> http://csl.ensm-douai.fr/fakih

4 4

Re: heading = forwardDirection + rotationDegrees (was Re: How can we deal with Message rot?)
by Jerome Peace 08 Jan '07

08 Jan '07

heading = forwardDirection + rotationDegrees (was Re: How can we deal with Message rot?) Hi Bert, Thanks for your thought on this. >Bert Freudenberg bert at freudenbergs.de >Wed Dec 27 14:14:12 UTC 2006 wrote: > >On Dec 27, 2006, at 6:36 , Jerome Peace wrote: >> more details of the heading etc. confusion >> can be found mantis >> >> http://bugs.impara.de/view.php?id=5674 >> >> 0005674: Why doesn't heading = forwardDirection + >> rotationDegrees for all morphs all the time? > >As far as I know, rotation and animation (that is, LOGO-style turtle >semantics) is only seriously used in Etoys. I think it only seems this way. First, I am making the assumption that by eToys you are refering to programming with tiles, Players etc. The larger realm of eToys also consists of morphs and their behavior (particular behavior in response to halo handles). So what affects programming with tiles spills over into morph considerations. >For most other UI users >it's merely a gimmick, so you would not need to worry about backwards >compatibility too much. Ok. thanx. >Etoys uses a very small set of messages >(manifest in the Player class). As long as you ensure this small >protocol does not break, Etoys should be fine. > >Now, Player is very careful to always figure out the "right" morph to >apply rotations to, depending on whether it wants to be "flexed" (in >a TransformMorph) or if it handles rotation itself etc. Etoys player would benifit greatly from knowing less about how a morph carries out its tilting responsibilities. That means establishing a consistent language and having all classes (and their programmers and maintainers) stick to it. This is the task of an oft promised but long overdue refactoring of morphic stuff. I haven't worked out the details but the notion I have is that it should be possible to say "player assuredFlexibleCostume heading: aHeading " and have the right thing happen. And maybe later "player assuredSimplestCostume" which would remove redundant renderers. >This is why >you see inconsistent behavior in the individual morph classes. But it shouldn't be that way. The responsibilities can be clearly defined and every morph would benifit. Many of the deep bugs I run into have the TransformationMorph decorator as their root. Lots of the gribble leaving problems come from a mismatch of assumptions between TfMorph ( which believes you can translate the origin into the 3rd quadrant) while every body else believes that truncate is the same as floor because all points are in the 1st quadrant. Clipping boxes get calculated wrong and are often of by one just when you need them not to be. Results: screen gribbles abound. >- inEtoys they are not used directly, but through the Player, and this is >why your equation does not hold for each individual morph. I think >you would have to eliminate TransformMorph completely, which might >complicate other Morphs - until now, that "ugly" transformation stuff >was factored out. As I look at the code I see constant attempts to worry about which morph is actually being talked to renderer or renderee. The code practically begs to be refactored. Its just a big job at the moment. I await enlightenment and inspiration. Meanwhile I am trying refactorings that lay the ground work for the simplification of the Tf mess. Yours in service, --Jerome Peace __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

4 3

Design Principles Behind Smalltalk, Revisited
by Paul D. Fernhout 04 Jan '07

04 Jan '07

When I was looking at GST vs. Ruby benchmarks today, http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=gst&lang2… I came across a link at the bottom to the original "Design Principles Behind Smalltalk" paper by Dan Ingalls, see: http://users.ipa.net/~dwighth/smalltalk/byte_augc81/design_principles_behin… This essay attempts to look at Dan's 1981 essay and move beyond it, especially by considering supporting creativity by a group instead of creativity by an isolated individual, and also by calling into question "objects" as a sole major metaphor for a system supporting creativity. Some of this thinking about "objects" is informed by the late William Kent's work, especiallyKent's book "Data & Reality": http://www.bkent.net/ http://www.bkent.net/Doc/darxrp.htm Presumably the original paper reflects not just Dan's work and thinking, but that of Alan Kay and the larger Learning Research Group at Xerox Parc at the time, but I will refer to it as Dan's writing, because his is the only name on it. Mainly I will consider the first half of the paper. This essay is perhaps a little in the spirit of 'The Rise of "Worse is Better"', http://www.ai.mit.edu/docs/articles/good-news/subsection3.2.1.html and is intended to help in understanding why, say, Python has been so successful in capturing the hearts and minds of the last decade of development, running core systems from Google to NASA, whereas Squeak Smalltalk has remained a niche project during that time. And this is true even though we all know that Squeak is better than Python in oh so many ways (with a more expandable and more self-documenting syntax using key:words: instead of functions, better transparency from top to bottom of the system, better core graphics engine, better community in terms of very bright people capable of handling a high level of abstraction, better core tools, more consistent language model, better streams and number classes, more portable VM, better dynamic development where you can code in the debugger and restart a method instead of an application, and so on). Still, for all those Squeak advantages, I think, the same applies for Squeak Smalltalk as Richard Gabriel of 'The Rise of "Worse is Better"' says of Lisp, "... one can conclude only that the Lisp community needs to seriously rethink its position on Lisp design." That "Worse is Better" paper probably has had little effect on changing Lisp the language, and I doubt this note will have much effect on Squeak the system. :-) Ultimately languages (and the mailing lists that support them) are somewhat self-selecting -- if you have major problems with the language or paradigm, you probably are not using Squeak or on the Squeak development list. Still, I found it of value to me to write up these issues, in terms of thinking of the next generation of tools and users, and I hope some Squeakers out there find it of value to read. First off, I agree with Dan's stated goal of a quarter century back: "The purpose of the Smalltalk project is to provide computer support for the creative spirit in everyone." So, overall, there is no difference in goal when broadly construed. This essay will outline some points of disagreement with how to best support that goal. Some of this disagreement will be from a coming at the notion of how to support creativity different perspective, especially given how the computing landscape has changed due to the very success of the object-oriented and networked GUI paradigms which Smalltalk (and the Alto it was developed on) pioneered. As Steve Jobs said: http://americanhistory.si.edu/collections/comphist/sj1.html "SJ: ... I saw their early computer called the Alto which was a phenomenal computer and they actually showed me three things there that they had working in 1976. I saw them in 1979. Things that took really until a few years ago for us to fully recreate, for the industry to fully recreate in this case with NeXTStep. However, I didn't see all three of those things. I only saw the first one which was so incredible to me that it saturated me. It blinded me to see the other two. It took me years to recreate them and rediscover them and incorporate them back into the model but they were very far ahead in their thinking. They didn't have it totally right, but they had the germ of the idea of all three things. And the three things were graphical user interfaces, object oriented computing and networking." === creativity by an individual versus creativity by a group === Dan wrote in the paper: "If a system is to serve the creative spirit, it must be entirely comprehensible to a single individual." I strongly disagree with this, as much as I still agree with his later statement of: "Any barrier that exists between the user and some part of the system will eventually be a barrier to creative expression." The disagreement comes from considering the idea of creativity of a community involving building on the work of others (where such work you use may be beyond your ability to either fully comprehend or modify). Or, is what is best for the individual in conflict with what is best for the group? And if so, which should win? While ideally, any system should have no barriers to the individual user, in practice, it may, and yet may still support a large amount of creativity by the group, sometimes directly because of those barriers. Another way to think of a barrier is an "interface" or a "firewall", and those have some positive connotations. Even Smalltalk's very success is due in part to creating a strong barrier at run-time between the user image of objects and the VM which supports it; this is a barrier which people have complained about, with the phrase "if you can't crash it, you're not doing the driving. " :-) Consider, for example, the success of Python, which is a mostly object-oriented language core written in C, where lots of other libraries have been bolted on to it by the community. It is this widespread availability of useful libraries which drives Python adoption more than any other thing. (Same with Perl adoption.) Python has other ideas which proves popular, like its use of significant white space like Occam used, having dictionaries built in and easy to use, and looking a lot like C, but it is the libraries and the related modularity which is one of the biggest wins for Python. Well, and that you can write a program in a few lines in a text editor that use those great libraries, making it easy to build small things with little learning. I think this sentiment of focusing on empowering the individual primarily, indirectly at the expense of empowering the community, was why Squeak Smalltalk has suffered from poor modularity so often and why, for example, it took so long to get namespaces and such into the mainstream, and also why it has struggled to have as many libraries as Python offers. So while I think Dan's original goal is a nice ideal, in practice it is not needed in the extreme, since the creativity of a group sharing, say, a community mailing list, will still move beyond the creativity of any individual in the group. So, it is *more* important in the internet age to have techniques for supporting group creativity, including modularity, than it is for the system to not have any barriers. That is probably one reason a system like Python is actually used in practice by more people to do creative things than Smalltalk. Python makes it easy for many individuals to do small things. While Python as a language and as an environment in practice does not scale as well as Smalltalk, the aggregate amount of all those individuals doing small things overwhelms what any one Smalltalker can do (or even a small group of them stepping on each others' toes and watching their contributions suffer from "bit rot"). Another issue here is that Dan was writing 25 years ago in the context of a *proprietary* system. So, availability of all the code within that system to the user was essential for creativity, even if the code was controlled by someone else, since otherwise the individual had no access to the code ever. But, when working with open systems based on free software, the code and tools to work with it are accessible to anyone, even if they are in other languages or supported by other communities, say, GCC community, than the community one is currently working in (say, GNU Smalltalk). Again, to contrast with Python, Squeak wants to run the show, but Python plays nice with all the other free tools of the GNU/Linux ecosystem. When you use Python, your environment is not just Python; it is really more like GNU/Linux. So, free (as in "freedom") software -- with accompanying free licenses like the GPL that work as de-facto constitutions for collaborative communities -- has shifted the landscape, and the development ideals may need to shift with it. This is another reason why Python, which has always been free and had a core community with those values, has been able to succeed so quickly over the past decade, whereas Smalltalk, which was originally proprietary, has struggled, even though a free-ish Smalltalk like Squeak is much more accessible to easier modification in many ways than Python. === technical versus conceptual barriers ==== Another issue here is that Dan is talking about "technical" barriers, which are not the only, or even the biggest, barriers to creativity. There often exist "conceptual" barriers. It is in the "failure of the imagination" that we face our biggest hurdles. Imagination is indeed "the ultimate resource". For example, the code to generate the VM in Squeak needs a certain mindset to understand; one has to think about the domain of bit manipulations. Even though the syntax looks like Smalltalk, the domain is very different from your run-of-the-mill GUI application or eToy. While it is indeed an innovation to use Smalltalk syntax in an uncommon domain, and indeed Smalltalk's syntax is a marvel which can make unnecessary many "domain specific languages", one can not get around the conceptual barrier of a programmer understanding a new domain, as much as a familiar syntax might help with the task. Thus, barriers will always exist in any programming system, since all interesting programs probably address new domains (or old domains in new ways). So, again, while the goal Dan defined twenty five years ago is "ideal", it is an ideal that can never be reached because of conceptual barriers encountered when working in multiple domains, even in a pure Smalltalk system which minimizes arbitrary technical barriers like differing syntax. Forcing everyone to work in Smalltalk using Smalltalk tools, as good as they are, means that other innovations developed in other languages with other tools, for example, Java, are lost to the Squeak community. Yes, in theory, anything is possible, especially with Squeaks interface to loadable modules; I am speaking more of tone and emphasis and culture here. And, if it is so often the conceptual barrier that is the ultimate hurdle, then are technical barriers of different syntax and different tools really so big? Many humans become fluent in multiple human languages and their accompanying cultures, which is typically a harder thing than learning new computer languages. If one needs to switch mental gears conceptually to work on the VM, then is it *really* so bad if the VM is written directly in C like GNU Smalltalk does? Now, I know a lot of positive arguments can be made for the utility and convenience of the Squeak VM written in Smalltalk (especially given C's quirks as a not-quite-cross-platform language), but in the end, my point is, keeping everything in one syntax may not really save that much time for the community, all things considered. Even when the syntax is the same, the underlying domain semantics may be very different, and those semantics, or meaning of all the objects, are what take the time to learn. To build a new VM, one still needs to spend a long time understanding what a VM is and how it could work, and no choice of familiar tools or use of one single syntax will make that extremely easier (a little easier, yes). A better choice of abstraction perhaps might make maintain a VM easier for those who get the abstraction, but not a choice of language by itself all other things being equal. Were the Squeak VM coded in some other portable language (like Java or Free Pascal or OCaml) then it might not take very much more trouble to maintain -- and such a VM might even be easier to develop, as one could use the complete tool set of that other system to debug the VM in the language it was maintained in, rather than facing a technical barrier :-) of seeing C code for the VM in the debugger instead of the original Smalltalk source which was translated from. Granted, if the Squeak VM was coded in, say, OCaml, one would have a barrier to an VM maintainer of learning that language and its paradigms, but I would argue that the barrier would remain more conceptual than technical, and the syntax problem would be the lesser issue. Right now, I think Squeak on the JVM, like Talks2 is a step towards, could be a really big win for the Squeak community, and translating the VM from an abstract representation (in Smalltalk) to a specific language is a big win there. Still, the VM could have been in any translatable abstraction (XML, Lisp, ANTLR parse tree from a VM-specific language, Parrot, etc.) and generating Java would still be easily doable (though of course Smalltalk encoding is preferable for Smalltalkers). Also it is not clear even if this is a big win, if it is a big enough win to justify other aspects making VMs harder to debug and maintain by having an intermediate translation step, compared to just working in a language that is more cross-platform by design than C, where somebody else does the hard work of maintaining that other platform. Again, here is the issue of community support versus individual support, and related assumptions. === Language versus "group computation" ===== I really like the "Figure 1" diagram in the original paper. And it remains a useful illumination of the problem area. Still, the bold statement "Purpose of Language: To provide a framework for communication" may not be the entire picture. What if one drops the big idea of "Language" entirely and focuses instead on "computation"? Consider if two or more people are not so much engaging in "language" as they talk, but instead are engaging in a "group computation", where utterances between group members plays a facilitating role. So, from this point of view, the major goal has to be allowing the group to compute effectively, whatever that takes. Language is one aspect of this. But the, so are licenses. So are communications channels. So are formal and informal community processes. And so on to all of sociology and politics. In a way, by elevating "language" as a paradigm, many of these other aspects could be missed. Squeak the community has certainly suffered on some of these issues at various times (though recent efforts, especially on relicensing even it just had PR value, are hopeful sign). Also, consider, the latest thinking on cognitive psychology and AI includes that the human brain simultaneously thinks about problems in multiple representations, and chooses second-by-second the representation that pays off the most in making progress towards goals. So for example, we may look out the window at a rainy day with a goal of going to the store by car, and we may simultaneously imagine becoming wet as a sort of 3D world simulation of rain falling on our heads as we venture to the car in our imagination, engage in formal logic based on linguistic experience ("if rain, then take umbrella"), use neural net pattern matching to get the most common behavior in the gestalt of the situation (it just feels right to reach for the umbrella based on the gestalt of the situation), plus we be mentally making a two-D map of a route an areas with obstacles (rain between self and car) and considering ways to make progress through the 2D representation of a rain obstacle. So here we might have four different representations we might be using simultaneously, which each have parsed the world differently, perhaps into "objects" of various sorts or perhaps not. One or more of them may prove most useful and drive our behavior for that moment. Language is only playing a direct role in one of those representations in this case, the formal symbolic-logical process. Language may play a role in the others representations as well as we internally reflect with language (generating internal questions like "why do I feel like reaching for the umbrella?" Or, "How can I overcome the rain barrier?" etc.). However the other representational schemes may also be applied to the formal linguistic-symbolic representation or to each other. In short, we now know that viewing the mind as solely about "language" is an overly simplistic way of thinking about it. And if the paradigm has grown, then so too should our computer support systems, in order to honor the insight in the original paper of: "The mechanisms of human thought and communication have been engineered for millions of years, and we should respect them as being of sound design. Moreover, since we must work with this design for the next million years, it will save time if we make our computer models compatible with the mind, rather that the other way around." One of those forces shaping the mechanisms of human thought has been how it is the *group* which survives in the wilderness; the lone *individual* is rapidly picked off by accidents (say, a broken leg) or runs into trouble (say, a pack of coyotes) beyond his or her individual ability to cope. (That's one reason it's foolish to think you can survive an apocalyptic disaster long term by running away to the wilderness on your own.) When a village defends itself against a large pack of coyotes, even with verbal shouts and grunts to the coyotes or between villagers, what is going on is in some ways is primarily a coyote defense "computation" involving all the villagers and all their thinking (which may be operating lots of simultaneous decision making models), not just a "discussion" among villagers about coyotes, as useful as language may be in helping that larger group computation to come to a successful conclusion. So in a tool to enhance group creativity, we must consider all the ways to enhance these creative group computations, and those go beyond just supporting a common language. == objects are an illusions, but useful ones === In my undergraduate work in psychology I wrote a senior paper in 1985 entitled: "Why intelligence: Object, Evolution, Stability, and Model" where I argued the impression of a world of well-defined objects is an illusion, but a useful one. Considered in the context of the section above, we can also see that how you parse the world into objects may depend on the particular goal you have (reaching your car without being wet) or the particular approach you are taking to reaching the goal (either the strategy, walking outside, or any helping tool used, like a neural net or 2D map). Yet, the world is the same, even as what we consider to be an "object" may vary from time to time; in one situation "rain" might be an object, in another a "rain drop" might be an object, in another the weather might be of little interest. So objects are a *convenience* to reaching goals (in terms of internal states), not reality (which our best physics says is more continuous than anything else in terms of quantum probabilities, or at best, more conventionally a particle-wave duality). So objects, as tools of thought, then have no meaning apart from the context in which we create them -- and the contexts include our viewpoints, our goals, our tools, or history, or relations to the community, and so on. Consider Dan's statement of "A computer language should support the concept of "object" and provide a uniform means for referring to the objects in its universe." That appears to me to have made a classical mistake of thinking the universe has only one parsing into one object hierarchy and that the objects exist in some sort of Platonic ideal. See Plato's "Allegory of the Cave" for the best example of the mistaken notion of only one true parsing, even though as the social commentary it may still be accurate: :-). http://faculty.washington.edu/smcohen/320/cave.htm http://www.ship.edu/~cgboeree/platoscave.html As discussed above, the world does not have just one unique parsing into objects. Or, to bend Plato's allegory, that we sometimes find apparently discrete "shadows" useful to perceive and think about as "objects" does not mean there really are discrete ideal things out there casting those shadows, with any sort of one-to-one correspondence. Again, this is not to say objects are not useful, just that they are a tool. To use an example from the paper, when Dan wrote: "Every time you want to talk about "that chair over there", you must repeat the entire processes of distinguishing that chair. This is where the act of reference comes in: we can associate a unique identifier with an object, and, from that time on, only the mention of that identifier is necessary to refer to the original object." That sounds really nice on the surface. But consider, what if the "chair" is glued to the floor? You think it is an "object" but there is no clear real boundary between it and the floor. And when you attempt to move it, what if the floor boards come up with it? You now have an entity you are manipulating which is not quite a "chair" and not quite a "floor" -- what is it? There is no neat "class" to put it in. Clearly you, the reader, can think about this entity so the human brain supports this fluidity in changing our definitions of objects and not requiring a one-to-one mapping to ideal classes to think about them, but a computer language like Smalltalk would have many problems representing this. William Kent, in the book _Data & Reality_ discusses these sorts of problems at length. Sure, you could make a new object for the combined entity, but what if then you decided to take apart the chair into cushions, legs (with floor boards still glued on), a back, and lots of bolts? Now you have lots of new objects? Sure, but then how do you reference about all the objects and all their relations in all possible permutations consistently? Your mind can do it easily; a Smalltalk class hierarchy and related application would struggle to do it, at best. Sure there are design patterns for some of these things (like "Facade") but they are not completely reflected in a system which has an overly static notion of "object". Smalltalk has some ways to deal with these things, like "becomes:", but that is not dealing with this problem in all its generality. You can simultaneously think about an original chair, a chair with floor boards stuck on it, and a chair taken apart -- so your mind is capable of much more imaginative representational power than a simple notion of "objects". Again, discrete objects are a useful tool to think with, but they are not the only tool, and they are not as stable a tool as one might think at first glance. Objects are useful within contexts. Yet, Smalltalk lacks a formal notion of an object having a context (or imaginative world) which defines its meaning. When people (including Alan Kay) talk about Smalltalk they often say to the effect that objects are self-contained. But clearly they are not. Their meaning emerges out of their interactions with a world of other objects. Yet modern Smalltalk have not formalized the notion of a world of objects beyond a very coarse-grained kitchen-sink "image". It would seem one needs finer-grained contexts, be they "worlds", "modules", or some other thing. ==== talking to an object vs. manipulating it ==== Consider this statement from the paper: "Computing should be viewed as an intrinsic capability of objects that can be uniformly invoked by sending messages." It sounds uniform (from an implementation point of view), yet it violates the human notion of how most of our time is spent actually interacting with "objects". When we use language, we are generally talking to ourself or other people; most items in the world don't respond directly to language. We use our hands or feet or whatever to manipulate them -- to move them or change their internal configuration. Not every object in the real world has a name or knows what the best inspector is for it; in fact, very few of them do, except perhaps people. When we pick up a rock, we try different tools on it if we want to observe it. We classify it ourselves; we don't ask it its class. We may stick a label on it and put it in a museum, but that is an active effort of categorization. And we may later change our minds about how to label it. Or we may break it into two parts (plus some rock fragments), and grind one of the parts up into rock dust and put some of the dust through various chemical processes over a period of years (say, if it was originally a "moon rock"). A moon rock does not know how to perform chemical analysis on itself or even split itself in two, yet Smalltalk philosophy encourages making models of reality as if a moon rock did. I think the issue shows why languages like Lisp or Python (a Lisp derivative in some ways) or even C++ have hung on so well, both as philosophies and communities. In those languages you often have data structures which are operated on externally by large subroutines. And people who like these languages claim they like to sometimes do OO when they want it (OO meaning behavior emerges from a lot of interacting objects), or at other times to do these sorts of external manipulations on sets of inert objects using complex routines. Manipulating otherwise inert-seeming objects according to our fancy of the moment is something that people are comfortable with, and likely a big part of our mind is structured to do that well. Yes, we do talk to people or certain animals (or now certain devices). But we also do a lot of manipulation by hand (or foot etc.) and classification by eye (or ear or touch). So, this suggests perhaps it is a mistake to have an object hierarchy where at the top everything knows its name or how to put data into its own slots. What's wrong with, say, asking the VM to put data into an objects slots? Or asking the VM for the ID of an object? Why should objects be expected to be so smart when we programmers are surrounded in the real world with objects which are usually quite dumb? This a violation of the good principles that Dan starts out the paper with -- to make a system which maps well onto how humans think. Humans both talk and manipulate, so it would seem a system should support both styles of interaction. Granted, it is almost trivial in Smalltalk to reach into other objects and manipulate them, but my point is that Smalltalk is not presented that way, and such interactions are generally discouraged as bad practice. Somehow I feel this issue needs to be revisited. Among newer GUI interfaces, like Morphic, there is an emphasis on direct manipulation. Yet, somehow, this notion is discouraged in programming. There is a paradigm conflict here which needs to be addressed. == summing up== I don't have time or energy right now to go into the rest of this excellent paper in detail; much is either on the value of modularity, which I agree with (even as Squeak Smalltalk may not have enough of it in practice), or implementation strategy or GUI (which is a whole other can of worms). But let me say these criticisms are made with (perhaps) 20/20 hindsight a quarter century later. Dan himself may have come to these insights or better ones by now; no doubt like many people when contemplating their earlier work of decades gone by, they can be both proud of it and embarrassed by it at the same time (I know I am). As Dan said insightfully in the conclusion: "There are clearly other aspects to human thought that have not been addressed in this paper. These must be identified as metaphors that can complement the existing models of the language." This essay is intended along those very lines Dan mapped out so long ago. For its time, the original paper is a remarkable achievement, as is Smalltalk-80. It is only because of such great work that we can think about moving forward onto even greater projects. But what I find most illuminating stumbling across this paper again (I probably read it in Byte way back when) is that now, in retrospect, it seems to explain both the ways Smalltalk would *succeed* spectacularly in the goal of making (*some*) individuals more creative (though, contrast with Howard Gardener's theory of *multiple intelligences* including non-language ones, see the list here:) http://www.infed.org/thinkers/gardner.htm and also the ways Smalltalk would *fail* (somewhat) in making groups more creative (which it was not designed to do), compared to, say, Python (which is not as scalable for individual user's creative projects, but has other advantages in a group context). Subconsciously it may be these sorts of issues that motivate would-be Squeakers to have an interest in, say, Python. And these sorts of issues may be implicitly behind some of the specific issues Squeak has wrestled with both as an implementation and as a community. Obviously, the Squeak community, especially with, say, Monticello or Croquet, is trying to bridge this gap to support group creativity. OpenAugment, based on Squeak, is indirectly another such project. http://www.openaugment.org/ So it is not like there are no attempts to recognize some of these issues and move forward. But perhaps the original "Design Principles Behind Smalltalk" paper (as it unconsciously resonates about in the Smalltalk community, and even in the minds of core Squeakers) now holds Smalltalk (and Squeak) back, as much as that paper propelled Smalltalk forward for a quarter century. --Paul Fernhout (I hearby place this essay under the GPL, version 2 or later; and also the GFDL with no invariant sections).

20 66

Jump to page: