Enormous thanks to Andreas Raab for that lovely intellectual stink-bomb.

As a learner who has coded for years and has spent the last two months
learning Squeak/Smalltalk, his comments were a breath of fresh air.

In particular...the salient points, again:

>>any attempt to "clean up" Morphic is doomed to fail if it does
not address the "usability issues" for the programmer. The best you can hope
for is a temporary effect but any newbie can (and therefore will!) write
code that breaks the framework. Some of this code will either be cool or
needed enough so that someone else is going to use it and you'll end up
exactly where we are right now.

Documentation, tests, etc. will (while being useful) not solve this problem.
After all, we *want* people to play with this stuff, don't we? And if we
want people to play with it then it should be easy to use in "the right
way".

----

That's the meat of his contention and I agree with it.  It's about
"usability issues" for programmers.  Many of you have programmed in this
for so long that you do what would not be obvious to others
coming from other programming backgrounds.

My hope is that today's high level code will be tomorrow's assembly
language,
and that something like Smalltalk will underlay a rich, helpful IDE, where
"programmers" can state their intentions in general, not always "perfect
syntax" ways, while be taught and coached and constantly rewarded by the
real-time IDE -- much as a good video game unfolds to show "what controls
do what" as the gamer is constantly rewarded in gameplay.

For now, we should discuss what Andreas wrote: How to build the right
"fences" into the framework, and how to address other usability issues.

As a starter, I'd love to see much more from Andreas on this subject.

Doug