Traits or not Traits that is the question

Igor-

Your sweeping generalization about my character and quarter-century of
software development experience aside, (*) :-) where does that leave us?

One the one hand, we have an example of a $250K spent on a paper design
study where the consultants "hadn't understood the requirements".

On the other hand, when I suggest there are *bugs* in *some* of the Squeak
values and implicit requirements (personal emphasis vs. group emphasis,
reaching out to the rest of the world like with a conventional ASCII assign
statement), the Squeak community process (licensing, loss of good code,
retention of problem code), and implementation (GUI, modularity) I get no
less that three people making variations of ad-hominem and straw-man attacks
(some nicer than others).
 http://www.nizkor.org/features/fallacies/

I'm being critical here of Squeak, so I can accept some criticism back (the
point of bringing these issues up in the general list). And people are going
to take some of this personally, so, OK, I can let the personal comments
about me mostly slide as part of the cost of trying to bring up difficult
issues in response to Stef saying stuff like : "frankly I do not have the
energy anymore .. . I'm not part of this community for this kind of
attitude." :-)

But, again, what is the alternative? Just ignore IMHO crucial bugs in Squeak
(the artifact, the community, and the underlying values)? And I do mean
"bugs", as in, 90% to 99% of all that is Squeak works amazingly well, but
somewhere between 1% and 10% of Squeak has somehow gone off the "rails".
(Pun intended :-)
 "JRuby on Rails: The power of Java, the simplicity of Ruby on Rails"
 http://www.javaworld.com/javaworld/jw-02-2007/jw-02-jruby.html
 "Sun Acquires JRuby Project"
 http://www.javalobby.org/java/forums/t78292.html

What Ron's example ("they hadn't understood the requirements") says to me is
that people who go off on their own for a few months (or years) and then
drop the result on the community's doorstep are much less likely to have
success than people who bring up issues into the community and get some
feedback during an ongoing process.

Is seems to me what you are implicitly advocating, probably unintentionally,
is, "go away and don't come back until you make your suggestion of Squeak on
the JVM work". For me, that implies a lack of design. A lack of discussion.
A lack of learning (on my part, from the community). And without design and
discussion and learning, even just within one person, I don't think an
implementation of anything is likely to be of any value. Now, I don't expect
you really believe all those negatives; that's just how your words come
across to me.

If you follow the thread, I've pointed to person months of implementation. I
included a Java code snippet at the start of a working proof-of-concept
program (which was not trivial to design, even if it was short). I also
pointed to other relevant resources I made (including a Smalltalk-ish parser
that runs on the JVM).

I'd suggest a better adage is "moderation in all things, including
moderation". Some designing, some discussing, and some implementing -- all
co-evolving. I've discussed some. I've designed some. I've implemented some.
I've even critiqued some -- and I can be a lot more self-critical about my
own work than about others' work: :-)
 http://patapata.sourceforge.net/critique.html
I brought this issue up (improving on Squeak, like being on the JVM) to make
a suggestions and to learn from feedback. If you don't want to read what I
write or take part in the discussion (for whatever reasons, including lack
of brevity, sorry) that is your choice, and my loss,  :-( as I feel you have
many good ideas, like your outline of a system which would support
simultaneously loading incompatible versions of modules.

So, what are the requirements theses days for a successor to Squeak? I've
outlined some here and there in my replies and links to previous comments.
Essentially, a focus on being part of a free software ecosystem where "the
network is the computer" and "the programmer is the community", as well as a
focus on taming internal complexity of the core and pushing contentious (but
perhaps awesome) issues like "traits" to optional edges, and all ideally
without losing the interactivity and introspectiveness and malleability and
cross-platform support which Squeak provides so well already.

Squeak can improve, especially as the software world changes around it or in
reaction to it. Or as the world adopts Smalltalk ideals bit by bit, like
Java's improvement over C++ by adopting Smalltalk ideas like adopting
garbage collection, exposing objects instead of memory pointers, maintaining
a cross-platform vm, supporting reflection, and using hotspot compiling.
I'm quite willing to say Squeak is amazing, and Squeak gets a lot of things
right which other languages don't even conceive of as possible (like coding
in the debugger). But that does not means Squeak is perfect, either the
code, the community process, or the values. What seems important to me is to
figure out what, say, 1% or even 10% of those aspects is proving most
problematical and improving on them, while preserving the rest. For just one
example, the licensing of the Squeak core is problematical still (and
probably always will be IMHO if Disney does not sign off on it). So if I
replaced it with the core from GNU/Smalltalk, and ported the rest, and used
the JVM for much of the VM and related services (so that VM code could be
tossed too, at first), maybe that would make one legal "bug" go away, or at
least, be pushed to the edges of the community instead of the core (e.g.
having a browser module or a morphic module)?

In this overall thread I've learned (or validated) several useful things:
* There is some small interest in a Smalltalk on the JVM, including a couple
projects still active, or about to be released.
* The software world has changed so much since the 1960s for where
innovative software only got written at big companies (Xerox) paying people
directly to do it. Now, the creativity and actual code seems mostly to come
from people writing it as a byproduct of other work or for its own sake. And
even when creative code rarely does get written as part of a job description
(still by some of the same people as in the 1960s! :-) now that creativity
often can't get out the corporate door for silly (but still important)
reasons (like naming) -- even ignoring the idea of "alienation" of the
creator from the created when the creator is paid to do create, which you
are correct to imply in your comments:
 "Creativity and intrinsic interest diminish if task is done for gain"
   http://www.gnu.org/philosophy/motivation.html
 "Five Reasons to Stop Saying "Good Job!""
   http://www.alfiekohn.org/parenting/gj.htm
* Aspects of the very discussion just shows that Squeak (as an entirety)
still has some of the same vision and process "bugs" as it had many years
ago (maybe even more as the world has continued to change faster than Squeak
has, like with the maturing of the Java/JVM ecosystem).
* Some other useful technical suggestions and links some people have made
both on-list and off-list.
So overall, for me, it's been a very educational discussion.

Here is an essay related to the Chandler project's failings which I find
instructive for all sorts of reasons, including thinking of how it applies
to Squeak and "Design" (both good and bad, both supporting and undermining
your suggestions):
 "Software Is Hard"
 http://gamearchitect.net/Articles/SoftwareIsHard.html
"""
Software is hard," reads the quote from Donald Knuth that opens Scott
Rosenberg's Dreaming in Code.  The 400 pages that follow examine why:  Why
is software in a never-ending state of crisis?  Why do most projects end up
horribly over-budget or cancelled or both?  Why can't we ship code without
bugs?  Why, everyone asks, can't we build software the same way we build
bridges?
...
Scott Rosenberg coins this as Rosenberg's Law:  Software is easy to make,
except when you want it to do something new.  The corollary is, The only
software that's worth making is software that does something new.
...
Or, as Fred Brooks writes in "No Silver Bullet":  "The hardest single part
of building a software system is deciding precisely what to build."
...
Part of the problem, clearly, is that every time we build software we're
creating something fundamentally new.  There are, Wikipedia tells me, six
main types of bridges.  Once you know how to build a bridge of a particular
type, you're just iterating on a theme.  The principles behind a suspension
bridge, for example, are well understood--if not by me, then at least by the
people who build them!  But like Rosenberg's Law says, once Epic's written
Unreal, they never have to create a first-person shooter engine again.
Instead, they just need to keep adding new features.  Day 1 may need to
write a first-person shooter engine, but only because we've never done that
before.  This is why programmers always want to rewrite everything. Most
shipping software is the equivalent of a novelist's first draft.
...
It's true, too, that construction is less predictable than many would like
to believe.  I've been a homeowner suffering from "buggy" construction
(faulty window frame installation, rotten walls).  I've watched the
resolution of the bug stretch to twice the contractor's original estimate.
Rosenberg cites the San Francisco/Oakland Bay Bridge as another construction
project that's running well over scheduled time and budget.
...
The difference is that the overruns on a physical construction project are
bounded.  You never get to the point where you have to hammer in a nail and
discover that the nail will take an estimated six months of research and
development, with a high level of uncertainty.  But software is fractal in
complexity.  If you're doing top-down design, you produce a specification
that stops at some level of granularity.  And you always risk discovering,
come implementation time, that the module or class that was the lowest level
of your specification hides untold worlds of complexity that will take as
much development effort as you'd budgeted for the rest of the project
combined.  The only way to avoid that is to have your design go all the way
down to specifying individual lines of code, in which case you aren't
designing at all, you're just programming.
...
Fred Brooks said it twenty years ago in "No Silver Bullet" better than I can
today:  "The complexity of software is an essential property, not an
accidental one. Hence, descriptions of a software entity that abstract away
its complexity often abstract away its essence."
"""

Which is all another reason why that $25OK paper study of a software
application Ron mentions got turned in a paper ball on the shelf.

Of course, as this is the Squeak-dev list, I'll say (though only
half-seriously) that we all know the biggest problem with Chandler is is
they had just built a great cross-platform Personal Information Manager on
Squeak with a few experienced Smalltalkers in a few person-years, then they
all could have declared success and gone on to even more interesting things.
:-) Python is a great languages, but it has trouble scaling for projects
involving dozens of developers and changing requirements, in part because
for a dynamic language it does not have the tools any decent Smalltalk like
VisualWorks has (coding in the debugger, live inspectors, cross-platform
widgets, extensive testing, etc., even if it has these in incomplete bits
and pieces). So really big projects tend to be harder in Python than
Smalltalk, especially a Smalltalk like, say, VisualWorks+ENVY (sigh). But I
would still suggest that much of those person-years spent with Squeak would
actually have gone into "image maintenance"  of the kind which left Stef
unhappy and which VisualWorks doesn't need (or at least, makes somebody
else's problem). :-(

So how can we get Squeak (or something like it) to the point where the
*next* Chandler-like project picks it and is a *success* in part because of
that good choice? And not by making it a free slow VisualWorks, but my
making it something awesomely better than VW (Like by leveraging on the Java
ecosystem)?

I once thought I could build such a system on Python,
 http://www.mail-archive.com/edu-sig@.../msg02025.html
but I now see that Python is the wrong level of abstraction, compared to a
statically typed language like C/C++ or Java or Scala/JVM. Also, Java and
the JVM was not "free" as in freedom when I started, but that has now
changed (the OLPC project faces the same issue, and I predict it too might
turn to Java at some point). So a Squeak that *relies* on the JVM is still
"free" in a way it could not have been a couple years ago, which is
important to me personally, see:
 "Free But Shackled - The Java Trap" -- a now outdated essay
 http://www.gnu.org/philosophy/java-trap.html

Anyway, thanks for the feedback. from you and others. One other design adage
I've picked up over the years is: "Listen to your users, but ignore what
they say". This can be interpreted as, whatever issues people bring up are
real issues to them, but their proposed solutions may be off-base. You (and
others like Keith or Göran) have a valid point (the risk of all talk but no
action), but managing that risk in a living breathing design process
spanning years (and reflected in ongoing coding) is another issue.

--Paul Fernhout
(*) Personally, I prefer these comments on my (collaborative) work: :-)
 http://www.kurtz-fernhout.com/PlantStudio/userssay.htm
especially this one: "The interface is good, you've obviously put a lot of
time and thought into it (even the pop-up help screens are good), the
program does what it claims very well, and the bottom line for me is that
it's immediately fun to play in and gives me all kinds of new ideas and
possibilities (it's that "oh, wow, this is neat-- hey, I could try this-- I
wonder what happens when I do this-- you could do a bunch of these and
combine them and then...." factor, and two hours later you're still messing
around and getting ideas -- instead of "now what, so what, this is really
awkward, this doesn't go anywhere".""

Compare that feedback with what many newbies say about Squeak :-( (even
friendly ones who stick around because they see the potential, like Sean):
"In fact, I've only started Squeak a few times, poked around, and closed it
in disgust and/or utter-confusion after a time due to the overwhelming
complexity (and, IMO, ugliness) of the UI that hits like a brick to the face
when first starting an image. "

I might point out that hundreds of person-hours of dicsussions, perhaps
thousands if I include the predecessor to that projects, were involved for
that project I was on, including sometimes putting ideas on paper first,
beyond actual coding.

And if you look back at the original creation and evolution of Smalltalk at
Xerox PARC, I would expect that too involved thousands of person-hours of
discussion, even if the original first mathematical description of Smalltalk
(then implemented in BASIC) as a first cut fit on a sheet of paper.
 http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html

I'll concede that email isn't the ideal way to have long design discussions,
and what we really need is an easy-to-use collaborative Squeak-powered
design tool
 (Perhaps something that builds on and expands on "OpenAugment": ?)
 http://www.openaugment.org/
which includes a way to have such discussions tightly linked to code
examples and other documents (and is more compelling than email, which is
hard because email is so important and ubiquitous and multi-platform and
easy to use, so it's hard to get better than it).

Of course, that perhaps brings us back to the first problem of a better
Squeak beyond something which "hits like a brick to the face". :-)

Igor Stasenko wrote:
> So, you proposing surrender to Paul's ways and for the rest of your
> life keep making things which is then turn into a pile of paper, and
> didn't thrown away,  just because it costs too much money to produce?
> :)
>
> On 07/02/2008, Ron Teitelbaum <[hidden email]> wrote:
>> I can't resist a story.  The company I worked for a long time ago, before
>> they hired me, hired a consulting company and spent over 1/4 million on a
>> system design.  When I started working I asked what that big ball of paper
>> was on the shelf.  They said it was a $250,000 basket ball.  (It was just
>> about the size of a basket ball).  It turned out that after months of work
>> the company delivered a huge stack of completely useless paper that very
>> clearly showed they hadn't understood the requirements.  I said so why did
>> you mash it up into a ball and put it on the shelf.  They said well at least
>> that was fun, and it cost so much it was a shame to throw it away!

...

As I see it, you could look at the ubiquitousness of the JVM one of two ways
(or both at the same time :-). Either Smalltalk failed, because most people
are not using a pure Smalltalk VM. Or, on the other hand, Smalltalk
succeeded enormously because just about everyone now programs with most of
the ideas you and Alan (and others) got going in a big way in the
1960s/1970s -- objects, garbage collection, a cross-platform virtual
machine, fancy IDEs like Eclipse, and so on, even to the point where a major
technology company changes its stock ticker symbol to be the name of an
object-oriented virtual machine (JAVA). Maybe the the JVM and the world is
still not Smalltalk-ish 100%, and maybe there has been a lot of needless
suffering along the way, but as I've heard, "first they ignore you, then
they laugh at you, then they fight you, and then you win." :-)

But in general, when you go from Smalltalk to a static language you get a
speed boost at the cost of reflection and dynamic debuggability. You shift
from using full featured objects (with reflective introspective abilities)
and using full featured stack frame entries (garbage collectible to support
full blocks) to using only limited objects which just do exactly what you
specify and using only a stack which is linear (not fractal, like Smalltalk)
and so can be optimized to use the stack of the real machine (or virtual
machine) more easily.

Michael van der Gulik wrote:
> What is a fractal stack?

What I mean by that is, since full blocks may contain a reference to their
environment on the stack, as long as the block is around, that part of the
stack is around (including an ability to unwind it). This is different from
other languages like C or Java which do not allow blocks, so the stack is
always linear (though you may have a few in parallel, one for each thread).
Perhaps I should have used "tree like"?  Consider that each block in turn
might hold onto processes or other stack frames, and so on -- so in theory
it might even become a random network of references, so "Tree like" and
"Fractal" might both be wrong, since they imply hierarchy (though a
hierarchy of stack frames is typical in practice).