Did you take a look at <a href="http://pypysqueak.blogspot.com/">http://pypysqueak.blogspot.com/</a>?<br><br><br><div class="gmail_quote">On Feb 8, 2008 12:37 PM, Paul D. Fernhout <<a href="mailto:pdfernhout@kurtz-fernhout.com">pdfernhout@kurtz-fernhout.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Igor-<br><br>Your sweeping generalization about my character and quarter-century of<br>software development experience aside, (*) :-) where does that leave us?<br>
<br>One the one hand, we have an example of a $250K spent on a paper design<br>study where the consultants "hadn't understood the requirements".<br><br>On the other hand, when I suggest there are *bugs* in *some* of the Squeak<br>
values and implicit requirements (personal emphasis vs. group emphasis,<br>reaching out to the rest of the world like with a conventional ASCII assign<br>statement), the Squeak community process (licensing, loss of good code,<br>
retention of problem code), and implementation (GUI, modularity) I get no<br>less that three people making variations of ad-hominem and straw-man attacks<br>(some nicer than others).<br> <a href="http://www.nizkor.org/features/fallacies/" target="_blank">http://www.nizkor.org/features/fallacies/</a><br>
<br>I'm being critical here of Squeak, so I can accept some criticism back (the<br>point of bringing these issues up in the general list). And people are going<br>to take some of this personally, so, OK, I can let the personal comments<br>
about me mostly slide as part of the cost of trying to bring up difficult<br>issues in response to Stef saying stuff like : "frankly I do not have the<br>energy anymore .. . I'm not part of this community for this kind of<br>
attitude." :-)<br><br>But, again, what is the alternative? Just ignore IMHO crucial bugs in Squeak<br>(the artifact, the community, and the underlying values)? And I do mean<br>"bugs", as in, 90% to 99% of all that is Squeak works amazingly well, but<br>
somewhere between 1% and 10% of Squeak has somehow gone off the "rails".<br>(Pun intended :-)<br> "JRuby on Rails: The power of Java, the simplicity of Ruby on Rails"<br> <a href="http://www.javaworld.com/javaworld/jw-02-2007/jw-02-jruby.html" target="_blank">http://www.javaworld.com/javaworld/jw-02-2007/jw-02-jruby.html</a><br>
"Sun Acquires JRuby Project"<br> <a href="http://www.javalobby.org/java/forums/t78292.html" target="_blank">http://www.javalobby.org/java/forums/t78292.html</a><br><br>What Ron's example ("they hadn't understood the requirements") says to me is<br>
that people who go off on their own for a few months (or years) and then<br>drop the result on the community's doorstep are much less likely to have<br>success than people who bring up issues into the community and get some<br>
feedback during an ongoing process.<br><br>Is seems to me what you are implicitly advocating, probably unintentionally,<br>is, "go away and don't come back until you make your suggestion of Squeak on<br>the JVM work". For me, that implies a lack of design. A lack of discussion.<br>
A lack of learning (on my part, from the community). And without design and<br>discussion and learning, even just within one person, I don't think an<br>implementation of anything is likely to be of any value. Now, I don't expect<br>
you really believe all those negatives; that's just how your words come<br>across to me.<br><br>If you follow the thread, I've pointed to person months of implementation. I<br>included a Java code snippet at the start of a working proof-of-concept<br>
program (which was not trivial to design, even if it was short). I also<br>pointed to other relevant resources I made (including a Smalltalk-ish parser<br>that runs on the JVM).<br><br>I'd suggest a better adage is "moderation in all things, including<br>
moderation". Some designing, some discussing, and some implementing -- all<br>co-evolving. I've discussed some. I've designed some. I've implemented some.<br>I've even critiqued some -- and I can be a lot more self-critical about my<br>
own work than about others' work: :-)<br> <a href="http://patapata.sourceforge.net/critique.html" target="_blank">http://patapata.sourceforge.net/critique.html</a><br>I brought this issue up (improving on Squeak, like being on the JVM) to make<br>
a suggestions and to learn from feedback. If you don't want to read what I<br>write or take part in the discussion (for whatever reasons, including lack<br>of brevity, sorry) that is your choice, and my loss, :-( as I feel you have<br>
many good ideas, like your outline of a system which would support<br>simultaneously loading incompatible versions of modules.<br><br>So, what are the requirements theses days for a successor to Squeak? I've<br>outlined some here and there in my replies and links to previous comments.<br>
Essentially, a focus on being part of a free software ecosystem where "the<br>network is the computer" and "the programmer is the community", as well as a<br>focus on taming internal complexity of the core and pushing contentious (but<br>
perhaps awesome) issues like "traits" to optional edges, and all ideally<br>without losing the interactivity and introspectiveness and malleability and<br>cross-platform support which Squeak provides so well already.<br>
<br>Squeak can improve, especially as the software world changes around it or in<br>reaction to it. Or as the world adopts Smalltalk ideals bit by bit, like<br>Java's improvement over C++ by adopting Smalltalk ideas like adopting<br>
garbage collection, exposing objects instead of memory pointers, maintaining<br>a cross-platform vm, supporting reflection, and using hotspot compiling.<br>I'm quite willing to say Squeak is amazing, and Squeak gets a lot of things<br>
right which other languages don't even conceive of as possible (like coding<br>in the debugger). But that does not means Squeak is perfect, either the<br>code, the community process, or the values. What seems important to me is to<br>
figure out what, say, 1% or even 10% of those aspects is proving most<br>problematical and improving on them, while preserving the rest. For just one<br>example, the licensing of the Squeak core is problematical still (and<br>
probably always will be IMHO if Disney does not sign off on it). So if I<br>replaced it with the core from GNU/Smalltalk, and ported the rest, and used<br>the JVM for much of the VM and related services (so that VM code could be<br>
tossed too, at first), maybe that would make one legal "bug" go away, or at<br>least, be pushed to the edges of the community instead of the core (e.g.<br>having a browser module or a morphic module)?<br><br>In this overall thread I've learned (or validated) several useful things:<br>
* There is some small interest in a Smalltalk on the JVM, including a couple<br>projects still active, or about to be released.<br>* The software world has changed so much since the 1960s for where<br>innovative software only got written at big companies (Xerox) paying people<br>
directly to do it. Now, the creativity and actual code seems mostly to come<br>from people writing it as a byproduct of other work or for its own sake. And<br>even when creative code rarely does get written as part of a job description<br>
(still by some of the same people as in the 1960s! :-) now that creativity<br>often can't get out the corporate door for silly (but still important)<br>reasons (like naming) -- even ignoring the idea of "alienation" of the<br>
creator from the created when the creator is paid to do create, which you<br>are correct to imply in your comments:<br> "Creativity and intrinsic interest diminish if task is done for gain"<br> <a href="http://www.gnu.org/philosophy/motivation.html" target="_blank">http://www.gnu.org/philosophy/motivation.html</a><br>
"Five Reasons to Stop Saying "Good Job!""<br> <a href="http://www.alfiekohn.org/parenting/gj.htm" target="_blank">http://www.alfiekohn.org/parenting/gj.htm</a><br>* Aspects of the very discussion just shows that Squeak (as an entirety)<br>
still has some of the same vision and process "bugs" as it had many years<br>ago (maybe even more as the world has continued to change faster than Squeak<br>has, like with the maturing of the Java/JVM ecosystem).<br>
* Some other useful technical suggestions and links some people have made<br>both on-list and off-list.<br>So overall, for me, it's been a very educational discussion.<br><br>Here is an essay related to the Chandler project's failings which I find<br>
instructive for all sorts of reasons, including thinking of how it applies<br>to Squeak and "Design" (both good and bad, both supporting and undermining<br>your suggestions):<br> "Software Is Hard"<br>
<a href="http://gamearchitect.net/Articles/SoftwareIsHard.html" target="_blank">http://gamearchitect.net/Articles/SoftwareIsHard.html</a><br>"""<br>Software is hard," reads the quote from Donald Knuth that opens Scott<br>
Rosenberg's Dreaming in Code. The 400 pages that follow examine why: Why<br>is software in a never-ending state of crisis? Why do most projects end up<br>horribly over-budget or cancelled or both? Why can't we ship code without<br>
bugs? Why, everyone asks, can't we build software the same way we build<br>bridges?<br>...<br>Scott Rosenberg coins this as Rosenberg's Law: Software is easy to make,<br>except when you want it to do something new. The corollary is, The only<br>
software that's worth making is software that does something new.<br>...<br>Or, as Fred Brooks writes in "No Silver Bullet": "The hardest single part<br>of building a software system is deciding precisely what to build."<br>
...<br>Part of the problem, clearly, is that every time we build software we're<br>creating something fundamentally new. There are, Wikipedia tells me, six<br>main types of bridges. Once you know how to build a bridge of a particular<br>
type, you're just iterating on a theme. The principles behind a suspension<br>bridge, for example, are well understood--if not by me, then at least by the<br>people who build them! But like Rosenberg's Law says, once Epic's written<br>
Unreal, they never have to create a first-person shooter engine again.<br>Instead, they just need to keep adding new features. Day 1 may need to<br>write a first-person shooter engine, but only because we've never done that<br>
before. This is why programmers always want to rewrite everything. Most<br>shipping software is the equivalent of a novelist's first draft.<br>...<br>It's true, too, that construction is less predictable than many would like<br>
to believe. I've been a homeowner suffering from "buggy" construction<br>(faulty window frame installation, rotten walls). I've watched the<br>resolution of the bug stretch to twice the contractor's original estimate.<br>
Rosenberg cites the San Francisco/Oakland Bay Bridge as another construction<br>project that's running well over scheduled time and budget.<br>...<br>The difference is that the overruns on a physical construction project are<br>
bounded. You never get to the point where you have to hammer in a nail and<br>discover that the nail will take an estimated six months of research and<br>development, with a high level of uncertainty. But software is fractal in<br>
complexity. If you're doing top-down design, you produce a specification<br>that stops at some level of granularity. And you always risk discovering,<br>come implementation time, that the module or class that was the lowest level<br>
of your specification hides untold worlds of complexity that will take as<br>much development effort as you'd budgeted for the rest of the project<br>combined. The only way to avoid that is to have your design go all the way<br>
down to specifying individual lines of code, in which case you aren't<br>designing at all, you're just programming.<br>...<br>Fred Brooks said it twenty years ago in "No Silver Bullet" better than I can<br>
today: "The complexity of software is an essential property, not an<br>accidental one. Hence, descriptions of a software entity that abstract away<br>its complexity often abstract away its essence."<br>"""<br>
<br>Which is all another reason why that $25OK paper study of a software<br>application Ron mentions got turned in a paper ball on the shelf.<br><br>Of course, as this is the Squeak-dev list, I'll say (though only<br>
half-seriously) that we all know the biggest problem with Chandler is is<br>they had just built a great cross-platform Personal Information Manager on<br>Squeak with a few experienced Smalltalkers in a few person-years, then they<br>
all could have declared success and gone on to even more interesting things.<br>:-) Python is a great languages, but it has trouble scaling for projects<br>involving dozens of developers and changing requirements, in part because<br>
for a dynamic language it does not have the tools any decent Smalltalk like<br>VisualWorks has (coding in the debugger, live inspectors, cross-platform<br>widgets, extensive testing, etc., even if it has these in incomplete bits<br>
and pieces). So really big projects tend to be harder in Python than<br>Smalltalk, especially a Smalltalk like, say, VisualWorks+ENVY (sigh). But I<br>would still suggest that much of those person-years spent with Squeak would<br>
actually have gone into "image maintenance" of the kind which left Stef<br>unhappy and which VisualWorks doesn't need (or at least, makes somebody<br>else's problem). :-(<br><br>So how can we get Squeak (or something like it) to the point where the<br>
*next* Chandler-like project picks it and is a *success* in part because of<br>that good choice? And not by making it a free slow VisualWorks, but my<br>making it something awesomely better than VW (Like by leveraging on the Java<br>
ecosystem)?<br><br>I once thought I could build such a system on Python,<br> <a href="http://www.mail-archive.com/edu-sig@python.org/msg02025.html" target="_blank">http://www.mail-archive.com/edu-sig@python.org/msg02025.html</a><br>
but I now see that Python is the wrong level of abstraction, compared to a<br>statically typed language like C/C++ or Java or Scala/JVM. Also, Java and<br>the JVM was not "free" as in freedom when I started, but that has now<br>
changed (the OLPC project faces the same issue, and I predict it too might<br>turn to Java at some point). So a Squeak that *relies* on the JVM is still<br>"free" in a way it could not have been a couple years ago, which is<br>
important to me personally, see:<br> "Free But Shackled - The Java Trap" -- a now outdated essay<br> <a href="http://www.gnu.org/philosophy/java-trap.html" target="_blank">http://www.gnu.org/philosophy/java-trap.html</a><br>
<br>Anyway, thanks for the feedback. from you and others. One other design adage<br>I've picked up over the years is: "Listen to your users, but ignore what<br>they say". This can be interpreted as, whatever issues people bring up are<br>
real issues to them, but their proposed solutions may be off-base. You (and<br>others like Keith or Göran) have a valid point (the risk of all talk but no<br>action), but managing that risk in a living breathing design process<br>
spanning years (and reflected in ongoing coding) is another issue.<br><br>--Paul Fernhout<br>(*) Personally, I prefer these comments on my (collaborative) work: :-)<br> <a href="http://www.kurtz-fernhout.com/PlantStudio/userssay.htm" target="_blank">http://www.kurtz-fernhout.com/PlantStudio/userssay.htm</a><br>
especially this one: "The interface is good, you've obviously put a lot of<br>time and thought into it (even the pop-up help screens are good), the<br>program does what it claims very well, and the bottom line for me is that<br>
it's immediately fun to play in and gives me all kinds of new ideas and<br>possibilities (it's that "oh, wow, this is neat-- hey, I could try this-- I<br>wonder what happens when I do this-- you could do a bunch of these and<br>
combine them and then...." factor, and two hours later you're still messing<br>around and getting ideas -- instead of "now what, so what, this is really<br>awkward, this doesn't go anywhere".""<br>
<br>Compare that feedback with what many newbies say about Squeak :-( (even<br>friendly ones who stick around because they see the potential, like Sean):<br>"In fact, I've only started Squeak a few times, poked around, and closed it<br>
in disgust and/or utter-confusion after a time due to the overwhelming<br>complexity (and, IMO, ugliness) of the UI that hits like a brick to the face<br>when first starting an image. "<br><br>I might point out that hundreds of person-hours of dicsussions, perhaps<br>
thousands if I include the predecessor to that projects, were involved for<br>that project I was on, including sometimes putting ideas on paper first,<br>beyond actual coding.<br><br>And if you look back at the original creation and evolution of Smalltalk at<br>
Xerox PARC, I would expect that too involved thousands of person-hours of<br>discussion, even if the original first mathematical description of Smalltalk<br>(then implemented in BASIC) as a first cut fit on a sheet of paper.<br>
<a href="http://gagne.homedns.org/%7Etgagne/contrib/EarlyHistoryST.html" target="_blank">http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html</a><br><br>I'll concede that email isn't the ideal way to have long design discussions,<br>
and what we really need is an easy-to-use collaborative Squeak-powered<br>design tool<br> (Perhaps something that builds on and expands on "OpenAugment": ?)<br> <a href="http://www.openaugment.org/" target="_blank">http://www.openaugment.org/</a><br>
which includes a way to have such discussions tightly linked to code<br>examples and other documents (and is more compelling than email, which is<br>hard because email is so important and ubiquitous and multi-platform and<br>
easy to use, so it's hard to get better than it).<br><br>Of course, that perhaps brings us back to the first problem of a better<br>Squeak beyond something which "hits like a brick to the face". :-)<br><br>Igor Stasenko wrote:<br>
> So, you proposing surrender to Paul's ways and for the rest of your<br>> life keep making things which is then turn into a pile of paper, and<br>> didn't thrown away, just because it costs too much money to produce?<br>
> :)<br>><br>> On 07/02/2008, Ron Teitelbaum <<a href="mailto:Ron@usmedrec.com">Ron@usmedrec.com</a>> wrote:<br>>> I can't resist a story. The company I worked for a long time ago, before<br>>> they hired me, hired a consulting company and spent over 1/4 million on a<br>
>> system design. When I started working I asked what that big ball of paper<br>>> was on the shelf. They said it was a $250,000 basket ball. (It was just<br>>> about the size of a basket ball). It turned out that after months of work<br>
>> the company delivered a huge stack of completely useless paper that very<br>>> clearly showed they hadn't understood the requirements. I said so why did<br>>> you mash it up into a ball and put it on the shelf. They said well at least<br>
>> that was fun, and it cost so much it was a shame to throw it away!<br><br></blockquote></div><br>