[squeak-dev] A Sad Day

Marcel Taeumel marcel.taeumel at hpi.de
Thu Aug 13 07:59:34 UTC 2020


Hi Trygve.

> Class MorphicEventDispatcher has 4 methods in 3.10.2 and 16 methods in 5.3.

Finally, we managed to improve modularity of Squeak's event handling by assembling -- once scattered -- methods and logic in a place where it can be found and understood. Of course, the number of methods in a class can go up in the process. What you describe as "additional bloat" is clearly a revelation of already existing complexity.

Since the plain number of methods is rather unhelpful to assess code readability, I wonder whether there are better names we can use to guide programmers when exploring MorphicEventDispatcher, its protocols, and methods.

> Class MyMorph>> processEvent: anEvent using: anIgnoredDispatcher is a regular event handler in 3.10.2. In 5.3, it is a filter, and its execution never stops.

That's just not true. The dispatcher is still dispatching as it was in Squeak 3.10.2. Event filters were added as a mechanism to tackle the existing mis-use of event listeners. The filter mechanism uses patterns that are already existing in the Squeak system. Yes, there is still room for improvement regarding its modularity.

***

We need better ways to assess the image quality. Phrases such as "unbelievable image bloat", "many thousands of classes", etc. are not helpful at all. Such a perspective ignores incidental vs. accidental complexity. It also ignores the role of tools in such a live and exploratory programming system.

We need better ways to look beyond the source code. Of course, we strive for a clean, compact, understandable system. However, that goal must not only focus on lines of code, number of methods/classes/packages. Programmers do not just read code to gather understanding. They execute code, play around with objects ---> use tools. Those tools show us the names and relationships of all kinds of software artifacts. Those tools enable very concise, task-specific views on rather complex systems. Those tools can help find redundancy, clarify meaning.

Don't get me wrong. I am always in favor of removing a class or concept if that is not necessary. I do think twice before adding a new class or extending the inheritance tree.

However, just counting the number of code artifacts is not a helpful metric to move forward. It can only be a first step in a more throrough exploration process.

Don't give up. Happy Squeaking! :-)

Best,
Marcel
Am 13.08.2020 09:34:39 schrieb Trygve Reenskaug <trygver at ifi.uio.no>:

Dear All,
Imagine that you bought an iPhone 20 years ago. Over the years, you have filled it with pictures, contacts, and other personal data. You now want to upgrade to iPhone SE and find that all your personal data are lost because there is no way to transfer your data. Very sad.

The same has happened to me with Squeak. The Squeak programs I have written over the past 20 years are effectively lost because I can’t port them to a current version of Squeak. Very sad.

The essence of object orientation is that objects collaborate to achieve a goal. I retired 20 years ago and made it my task to create DCI (Data-Context-Interaction), a programming paradigm that merges the concepts of class and collaboration. BabyIDE is a non-intrusive Squeak program that includes a model of DCI as well as tools for programming within the paradigm. BabyIDE is a kind of Dynabook, a personal computer for experts in all domains. Its target group could be department managers in business and industry; they are experts in running their department in collaboration with other managers. Another target group could be farmers; they are experts in taking care of their animals. A third target group could be homeowners; they build expertise in controlling their smart home.

Squeak is more than a programming language; it is a live universe of collaborating objects. The shared objects on the web is also a universe of collaborating objects that Kevin Kelly called a single, global machine. BabyIDE extends the Squeak image into this global machine, making all the combined objects available for personal programming as illustrated below:




BabyIDE is now running in Squeak 3.10.2, together with a new Squeak Reverse Engineering tool. I want to port my programs to Squeak 3.5 to benefit from its improved internet communication facilities. This port has been pestering me since April, but the overwhelming complexity of 3.5 has forced me to accept defeat. I can’t avoid speculating about the nature of Squeak’s current target group. It used to be “children of all ages.” Today, it neither includes children nor old Smalltalk hands like me (I wrote my first Smalltalk program in 1978). Stephen Pope, another veteran who also bemoans what is happening to Squeak, wrote in a blog:


“The most popular systems (Squeak and Pharo) both suffer from unbelievable image bloat, with many thousands of classes, hundreds of root classes, class hierarchies with many instance variables in the high-level (abstract) classes, and too many packages with cute but meaningless (to a new-comer) names.”
https://smalltalk.tech.blog/2020/08/10/smalltalks-successor/ [https://smalltalk.tech.blog/2020/08/10/smalltalks-successor/]

I couldn’t agree more. A few examples:


1.   Class Object defines 485 methods. This means that every Squeak object understands at least 485 messages. Most of them are irrelevant to the problem at hand, but all of them can be part of unexpected behavior. 

2.   The state of every Morph object is held in its regular instance variables PLUS any number of undeclared and undocumented variables in its extension, a Dictionary that may include another dictionary inside it. The Morph class comment: “MorphExtension Allows extra properties to be stored without adding a storage burden to all morphs.” I’m more concerned about the burden put upon the code reader.

3.   For me, the final straw was the new filtering phase added to Squeak’s already complex event handling mechanism. Squeak 3.5 has 208 new methods with ‘filter’ in their name, but there is no indication as to what they are for and when to use them. The abstract concepts of event filtering are documented, but there is no documentation on their reification into concrete code. The complexity of a basically simple mechanism has reached a new high far beyond the capabilities of my brain.

4.   Class MorphicEventDispatcher has 4 methods in 3.10.2 and 16 methods in 5.3.

5.   Class MyMorph>> processEvent: anEvent using: anIgnoredDispatcher
is a regular event handler in 3.10.2. In 5.3, it is a filter, and its execution never stops.


After 60 years in programming, 42 of them in Smalltalk, and the last 20 in Squeak, I have reached the end of my patience and reluctantly have to quit Squeak programming. It is truly a sad day.

Have fun and Goodbye,
--Trygve


--

The essence of object orientation is that objects collaborate  to achieve a goal.
Trygve Reenskaug      mailto: trygver at ifi.uio.no [mailto:%20trygver at ifi.uio.no]
Morgedalsvn. 5A       http://folk.uio.no/trygver/ [http://folk.uio.no/trygver/]
N-0378 Oslo             http://fullOO.info [http://fullOO.info]
Norway                     Tel: (+47) 468 58 625
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200813/be42432f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hikoacdgfinifkep.png
Type: image/png
Size: 85882 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200813/be42432f/attachment-0001.png>


More information about the Squeak-dev mailing list