Hi Jason,
Jason Johnson wrote:
On Jan 23, 2008 12:42 AM, Juan Vuletich juan@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