I can't resist adding my pennyworth to this discussion. The ST vision
was to empower "children of all ages" to master their own programs.
This gives me an imperative discriminator for all my work: Am I making
the programs more readable? If not, don't do it.
I have been programming Smalltalk since 1978 starting with ST76, ST78,
ST80, and VisualWorks. VW evolved steadily into greater complexity, thus
moving away from the goal. Squeak emerged as a new beginning, but I am
much afraid that I again see a steady movement away from the goal
towards increasing complexity. I regret it, because I believe the
original goal is well worth pursuing. (I'll soon be transferring to
Pharo, hoping I'll find what I'm looking for there).
Example: The first thing I have always done when moving to a new ST
dialect is to modify SystemWindow. The system default has been to open a
new window with default size and more or less random position. My
personal preference is to retain control and open it in /Rectangle
fromUser/. This has always been very easy to achieve with a small
modification of a SystemWindow class method. I am now in the process of
moving from Squeak 3.10 to 4.5. I have spent several unsuccessful hours
trying to add my fix. I find a new layer of runtime Spec code between me
and the SystemWindow. I fail to see how this can make the code easier to
master. I think I have read somewhere that this automatically generated
code is not even intended for human consumption.
This seems to me to be a great pity and an opportunity lost. Much of the
Morphic complexity may be essential because it is caused by its great
power and flexibility, but user/programmers need to be protected from
this complexity. Not by hiding Morphic, but by helping the
user/programmer create code for it. Wouldn't it be great if something
like Spec were an IDE that generated exemplary Morphic code? Leverage
implies rigidity, so there would be different Specs for different
purposes. One for property sheets, one for tables, etc. I currently
need to create a property sheet but am not looking forward to the
Morphic chore. I know that the resulting code should be simple, but I
also know that it will take me a very long time to find it. Wouldn't it
be nice if I could create my property sheet through a simple Spect tool.
Afterwards, I could read the generated Morphic code and say: Aha! So
that's how I should have done it.
Just a dream.
--Trygve
On 20.12.2014 14:08, Esteban Lorenzano wrote:
On 20 Dec 2014, at 13:44, Sean P. DeNigris <s...@clipperadams.com> wrote:
kilon.alios wrote
even if continue to use Spec I will stiil have to rely on Morphic
since custom GUIs is really important for me.
Yes, that's why they can not be compared:
Morphic = make and understand any UI
Spec = make common business UIs easily (on top of a general framework like
Morphic)
but that’s not completely true because in that case Morphic should be just the
“graphic atoms” while spec should provide a set of widgets (made with those
atoms), when what actually happens is that Morphic is everything: the atoms,
the widgets, layers ever those widgets and even theming, etc. So… is not
correctly designed. Or better said: it has evolved in a way that now needs a
massive reengineering to make it right.
And Spec, instead being a set of widgets with a declarative way to compose
them, is yet another layer on top of other layers.
cheers,
Esteban
