[squeak-dev] Future of Squeak, and outsider's view

Igor Stasenko siguctua at gmail.com
Mon Jun 29 17:18:28 UTC 2009


2009/6/29 David Goehrig <dave at nexttolast.com>:
> Yet another lurker here.
> 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.
> Here's a few thoughts, inspired by Dan Ingalls's famous 1981 Byte article on
> the principles of Smalltalk.
> Principle 9:
>
> Modularity: No component in a complex system should depend on the internal
> details of any other component.
>
> Well if you look in the latest Pharo image, you'll find there's around 38
> methods of the Object class that amount to:
> isFoo
>
> ^ false
>

I feel uneasy each time, when adding own isXXX methods to Object.
But i don't know another plausible way how to make a difference
between an objects which having a certain capability vs rest of
objects in a universe.

Here the code snippets of CVLambda class ( a quick & dirty lambda
calculus implementation, which i using in own project).
This class represents a lambda-message-send, i.e. it keeps all what a
message send needs:
receiver, selector, arguments.
any of its slots can be a free variable or, in own turn, be another
lambda and so on, without any limitations.

I need to compare, if two lambdas are equivalent:

= aLambda

	^ aLambda isCVLambda and: [ aLambda isCVLambdaSlot not and: [ self
size = aLambda size and: [ self do: [:i :obj | obj = (aLambda at: i)
ifFalse: [
			^ false ]]. true ]]]


Sometimes i need to not reduce the lambdas immediately (because some
of them could have a side effects), but keep them for a while as a
message send, not yet performed , even if there is no free variables
left, but i want to test, if it can be reduced:

hasSlots
	self do: [:i :obj |
		( obj isCVLambda and: [ obj hasSlots ]) ifTrue: [ ^ true ] ].
	^ false

Sometimes i need to walk over all lambdas (contained in a topmost one):

lambdasDo: aBlock
	| copy |
	copy := self class basicNew: self size.
	self do: [:i :obj | copy at: i put: (obj isCVLambda ifTrue:[aBlock
value: obj] ifFalse:[obj]) ].
	^ copy

so, here the question, can i implement the same behavior w/o using
#isCVLambda , and
without putting any additional methods to Object class?

Maybe the design is plainly wrong! Maybe i don't need any of the above
behavior in correctly designed class.
I don't know.


> 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
> the same name, and register its own methods in a "base object", you both
> violate the principle of modularity AND break other packages.
> Principle 12:
>
> Factoring: Each independent component in a system would appear in only one
> place.
>
> 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:
>
> Object acceptDroppingMorph: transferMorph event: evt inMorph: dstListMorph
>
> Object hasLiteralSuchThat: testBlock
>
> 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
> Principle 2:
>
> Good Design: 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.
>
> 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,
> 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).
> Principle 17:
>
> Natural Selection: Languages and systems that are of sound design will
> persist, to be supplanted only by better ones.
>
> 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.
> Just my two cents,
> Dave
> --
> -=-=-=-=-=-=-=-=-=-=- http://blog.dloh.org/
>
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list