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 <sean@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