On Jan 23, 2008 12:42 AM, Juan Vuletich <juan at jvuletich.org> wrote:
>
> This sounds like advertising talk. I don't think there is well defined
> meaning for such words as "average programmer", "real world",
> "academic", "state-of-the-art", "best", etc. I prefer talking about
> actual ideas. I try to do that when I write.

You're the one who said Morphic isn't for the "average programmer". :)
 As you may have noticed from the list, I like to talk about ideas
myself.  But just because an idea exists, doesn't mean it's good or
effectively applied, so these things still have to be looked into.

> Well, many, including me, have written quite a bit on that. A lot has
> been talked at this list about the pink plane vs. blue plane tension,
> etc. You can start at
> http://www.jvuletich.org/Squeak/IntroductionToMorphic/Morphic.html .

Best link I've seen yet.  Thanks, I'm going through it.

But the information is somewhat dated though.  For example, in the C#
system (sorry to harp on it, but this is the one I'm currently most
familiar with) you program about how you have described as "Classic
morphic" (the documentation indicated that other systems just have
canned widgets to use).  That is, you go find a component close to
what you want, subclass it and specialize it.  Then it appears on the
tool box and can be applied visually.  The IDE services are totally
available to you so you can take this as far as you want.  As I
mentioned, the biggest problem I've seen is the fact that the language
still has to differentiate between "compile/design time" and "run
time".  A limitation Smalltalk doesn't have.

> 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.

> Squeak already includes a lot of morphs that
> would be really hard to write in other language / environments.
> EnvelopeEditorMorph is one of my favorites.

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 :).

> 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?  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.

> Well, I gave some pointers. Most of the stuff at
> http://www.jvuletich.org/ could be useful. Also read squeak.org, the
> wikis, use google, etc. Besides, study the system. It's all there.

Yep, thanks for those.  At one point I had read everything on your
site on the subject, but I haven't look at it in for a couple of
months.

> 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.

And I'm sure you're right that I do need to read more.  Squeak is
quite vast with a great deal to learn.