Did you take a look at http://pypysqueak.blogspot.com/?


On Feb 8, 2008 12:37 PM, Paul D. Fernhout <pdfernhout at kurtz-fernhout.com>
wrote:

> 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@python.org/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<http://gagne.homedns.org/%7Etgagne/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 <Ron at usmedrec.com> 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!
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080208/8259ddbb/attachment.htm