Ah, now I see the confusion.  Part of the reason my messages get so
long is I try to clarify things as much as I can to avoid confusion,
but here I see I didn't explain what I meant by "programming
visually".

I meant what I'm doing now, dropping components onto a form to build
the view of an application.  When no component exists that does what I
want, I subclass something as close as I can find, add the behaviors
it needs then move back to the designer and drop the new component
onto the form.  Of course the view only generates events or method
calls, one has to write code to actually do something with it.

And I think this is how most what I have been calling "graphical
developing systems" have worked (including Squeak-Morphic, even if it
has proven the most difficult to get started in), but what has been
missing in all the systems I had previously looked at was this ability
for these components to be extendable and first class.  Creating a
semi-complex layout for a form, then "inheriting" that form to create
other forms and factor the common behavior into the base forms.  I.e.,
OO programming but in the graphical designer as well as the
programming language.

(comments below)

On Jan 24, 2008 2:09 AM, Juan Vuletich <juan at jvuletich.org> wrote:
>
> 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.

Ah ok.  In that case I would agree.  As Paul Graham said "a lot of the
best ones were languages designed for their own authors to use, and a
lot of the worst ones were designed for other people to use." [1].
And this idea holds for designing systems as well no doubt.  My point
was just that one also must balance this with practicality.  Make it
for yourself, but make it so *you* can do real world common things
with it as well as anything your mind can imagine.

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

"killer feature".  Can't believe I typoed that. :)

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

Well, my presumption here was that the piano and the chart were
already created as separate components (as appears to be the case in
Morphic).  If so, it would indeed be trivial to add them to a form and
slap together those menus.  Of course you have to write the code that
wires it together, and C# isn't a concise language, but I would expect
it to be none-the-less straight forward once one has those two complex
components.

> Anyway, I might be wrong. If C# is so good, then
> why not use it?

Simple:  Smalltalk is a superior language and superior environment.
It is only this one aspect that is currently more intuitive in C# and
that is fixable.  What I'm trying to understand is how big is the gap.

>If its GUI framework and tools are that good, why not
> port them to Squeak?

I suspect I will port certain features of it, though Smalltalk being a
truly live environment removes the need for some of C#s more
innovative features.

> It also has actual envelopes you can grab with the mouse to modify the
> sound.

But the chart-like morph is a stand alone morph that views on an
envelope using a variation of the standard MVC, no?  In this case, I
would expect it to behave exactly the same, though it will obviously
be more lines of code in C#.  But the hard part is in defining the
Envelope viewer, not in putting it on the form or wiring it up.

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

I don't actually have much hope on "visual programming" as in "build
everything graphically and write no code what so ever".

A picture is worth a thousand words, but the book is always better
then the movie.  I see programming more like a book/movie then a
static picture.  But I also am a strong believer in DSLs, and for me a
graphical designer is the DSL if you will for low level uninteresting
details about how components are laid out on a display.  So I want to
do with my "graphical" DSL what I can do with my "textual" DSL:
extend it to be more powerful and factor common patterns into the DSL.

> I say this idea
> failed, because (almost) nobody uses it, and tool vendors don't sell it
> as the future anymore.

Now that I know what you mean, I agree. :)

[1] http://www.paulgraham.com/langdes.html  (2. Design for Yourself
and Your Friends.)