Hi Jason,

Jason Johnson wrote:
> On Jan 23, 2008 12:42 AM, Juan Vuletich <juan at jvuletich.org> wrote:
>   
>
> You're the one who said Morphic isn't for the "average programmer". :)
>   
Well, I said "I'm not doing Morphic 3 to suit the average programmer 
needs". That doesn't mean that Morphic isn't for the average programmer. 
It means that my objectives are not finding out what are the needs of 
the average programmer. I really don't know what they are. And I don't 
care too much.
>
>> http://www.jvuletich.org/Squeak/IntroductionToMorphic/Morphic.html .
>>     
>
> Best link I've seen yet.  Thanks, I'm going through it.
>   
Thanks!
>   
>> Then pay more attention.
>>     
>
> Oh I do.  I read every message I see about Morphic on the list, trying
> to see what it's "kill feature" is.
>
>   
Quoted alone, my phrase sounds rude. I apologize. I meant that Squeak 
itself is a great place to study and learn. I don't think the point is 
about a "kill feature". I think it is about flexibility and openness. 
I've never used C#, or anything but Smalltalk in the last 10 years, but 
I don't believe something like EnvelopeEditorMorph could be done with so 
little and simple code. Anyway, I might be wrong. If C# is so good, then 
why not use it? If its GUI framework and tools are that good, why not 
port them to Squeak?
> I looked at that class and I saw a Morph containing a piano, a view on
> a musical scale and a few menus. If I get time I may take a crack at
> it in the C# or Dolphin environment because it seemed pretty straight
> forward (and one always learns why it isn't in implementation :).
>   
It also has actual envelopes you can grab with the mouse to modify the 
sound. If you can do something like that in C# or Dolphin, with as 
little code as in Morphic, please tell me, and let me see the code.
>   
>> Well, I helped write an application that way in 1997 using VisualAge
>> Smalltalk (now VA Smalltalk). Also VisualWorks and Visual Smalltalk
>> supported or still support that way of programming. In my experience,
>> and that of many others, code is much better at tackling real complex
>> applications and at building a mainteinable system.
>>     
>
> Well, is that because it is the best way to do it, or because the
> tools don't help us constructing the interfaces enough? 
I don't know, but if you have hope on "visual programming" I suggest 
using Parts in VisualWorks, or the VisualBuilder in VisualAge, write an 
application (without code, only arrows connecting objects), maintain it 
(i.e. modify it and keep it working) and find out for yourself if a 
better tool could make that way of programming useful.
> Of course
> building applications via code must be supported, but in a system
> built in itself like Smalltalk, of course it will be.  I watched the
> Self video and they seemed to be building some pretty interesting and
> complicated things in a largely graphical way.
>
>   
>> I believe the whole
>> "visual programming" idea failed for professional developers.
>>     
>
> That's a rather bold statement.  It depends again on how you're going
> to define "professional developers" but if you define them as people
> who get paid to program then I suspect that the vast majority of all
> developers writing native GUIs are doing so in a mostly graphical
> manner and have been for decades.
>   
Decades? The first visual programming tools commercially available are 
about 15 years old. And most people build guis with gui builders, but 
almost nobody use visual programming tools. May be we are not speaking 
about the same, visual programming means defining the application 
behavior without code (not only the GUI, the model too). I say this idea 
failed, because (almost) nobody uses it, and tool vendors don't sell it 
as the future anymore.
>
>   
>> I don't think why would you think that. I really believe you need more
>> reading and studying Squeak.
>>     
>
> Mainly because having read the tutorials and papers on Self and
> Morphic from Sun's research web site, it seemed that Morphic gained a
> lot of power from the object instance modification capabilities.
> Since Smalltalk is a class based system you lose much of that (e.g.
> adding a method ad-hoc to a morph you're working on).  The way one has
> to do it in Smalltalk is by programatically generating classes, which
> I dislike.  In Etoys, one programs at a higher level so it doesn't
> matter so much how things are implemented at the lower levels you
> don't see, but at the Smalltalk level it doesn't strike me as very
> elegant.
>   
I see. However, I don't agree. I think programming in Smalltalk by 
defining classes is both powerful and elegant.
> And I'm sure you're right that I do need to read more.  Squeak is
> quite vast with a great deal to learn.
>
>   
:)

Cheers,
Juan Vuletich