Yet another lurker here.<div><br></div><div>While I'm not at all qualified to speak for the seasoned Squeaker communities, I am qualified to comment on the issues I've found attempting to implement some sample applications for contract bids on top of Squeak. I've also tracked the progress of Pharo with great anticipation, and have spent a lot of time pondering what needs to change to make it useful for my production work.</div>
<div><br></div><div>Here's a few thoughts, inspired by Dan Ingalls's famous 1981 Byte article on the principles of Smalltalk.</div><div><br></div><div>Principle 9:</div><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;">
<span class="Apple-style-span" style="font-family: Times; font-size: 16px; "><b>Modularity:</b><i> No component in a complex system should depend on the internal details of any other component.</i> </span></blockquote><div>
<div><br></div><div>Well if you look in the latest Pharo image, you'll find there's around 38 methods of the Object class that amount to:</div><div><br></div><div>isFoo</div></div><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;">
^ false<br><br></blockquote><div><div>Each of these methods violate this principle, not only in spirit but also in practice. While this has been common practice for ages, it means that building downloadable modules that can be easily merged with any given image is practically impossible. As soon as you have two packages that define their own class that wants to use</div>
<div>the same name, and register its own methods in a "base object", you both violate the principle of modularity AND break other packages.</div><div><br></div><div>Principle 12:</div></div><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;">
<span class="Apple-style-span" style="font-family: Times; font-size: 16px; "><b>Factoring:</b> <i>Each independent component in a system would appear in only one place.</i></span></blockquote><div><div><br></div><div>This is probably the single greatest reason for moving towards Traits across the board. But look at this concept in the context of two seemingly entirely different methods:</div>
<div><br></div></div><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;">Object acceptDroppingMorph: transferMorph event: evt inMorph: dstListMorph<br><br>Object hasLiteralSuchThat: testBlock<br>
<br></blockquote><div><div>If you look at both of these methods, you'll quickly realize that they are in fact the exact same method! This is because they have the exact same bytecode representation. These two methods are also exactly the same as the 38 isFoo methods I mentioned above. The only different is the semantics as viewed by the programmer, but the reality is none of these methods should be necessary, and should be factored out. These methods only exist due to a flaw in the design of the API and its semantics. This brings up the issue of</div>
<div><br></div><div>Principle 2:</div></div><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;"><span class="Apple-style-span" style="font-family: Times; font-size: 16px; "><b>Good Design:</b><span style="font: 13.0px Courier New"> </span><i>A system should be built with a minimum set of unchangeable parts; those parts should be as general as possible; and all parts of the system should be held in a uniform framework.</i></span></blockquote>
<div><div><br></div><div>If you look at the problems of creating packages (see principle 9 above) or the excessive verbosity which leads to inordinate redundancy (see principle 12), these ultimately stem from lapses in principle 2. Over the years, cruft has accumulated, people's code has become fragile and dependent on that cruft (remember message passing's and modularity's purpose is to reduce fragility), and result in an inertia against fixing the fundamental design flaws. We end up with arguments over Squeak vs. Pharo vs. Etoys because the design of the core system has lapsed into disrepair, much like the US's infrastructure. A serious effort to address this short coming,</div>
<div>and re-examine old design decisions to improve the core infrastructure would dramatically impact the future of all of these projects (as they all inherit the same problems).</div><div><br></div><div>Principle 17:</div>
</div><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;"><span class="Apple-style-span" style="font-family: Times; font-size: 16px; "><b>Natural Selection:</b><i> Languages and systems that are of sound design will persist, to be supplanted only by better ones.</i></span></blockquote>
<div><div><br></div><div>The concept of forking the language, fixing core issues, and addressing design flaws is a core principle of Smalltalk. Maybe it is time for a better one.</div><div><br></div><div>Just my two cents,</div>
<div><br></div><div>Dave</div><div><br></div><div>-- </div><div>-=-=-=-=-=-=-=-=-=-=- <a href="http://blog.dloh.org/">http://blog.dloh.org/</a><br>
</div></div>