Very bad about Squeak in blogosfere

> Another "modest proposal" [see link for satire
> http://en.wikipedia.org/wiki/Modest_Proposal].
>
> Perhaps we could include a/the suggestions/bug-fix database as default
> in the code browser itself, by default. Hence, everyone with a browser
> could be updated the moment the twinkling of an idea appears for the
> class one is currently browsing.
>
> However, actual discussions would be linked to appropriate websites
> from the code browser for discussions to be handled there. In this
> manner, the code browser would be the common, universal forum for
> directions and ideas as one is coding in the classes which would be
> the ones potentially influenced/changed by such ideas. Perhaps
> distracting, but until such a form of social programming is tried, we
> don't know if it would be distracting or not to have such things
> represented in a button or highlighted tab away.
>
> Ideally, I'd rather look over coder's avatars shoulders in Croquet to
> look into their "intentions" for "social programming", but Croquet's
> not standard yet nor universally runnable on all graphics cards.
>
> Perhaps, in an effort to leapfrog over "language innovations" for
> other programming languages, we could create a Croquet room where such
> alternative suggested fixes and directions can be showcased, like a
> portrait gallery of code. In this manner, the geographical placing of
> the suggested code changes indicates which part of the
> code-base/class-library would be affected.
>
> Indeed, like Alan Kay suggested many years ago... Smalltalk should
> have eaten its children by now. Maybe social programming (like other
> social web sites) is the way forward. We already agree it's OK to
> scratch ones own itch. Maybe the social mores need to change so it's
> OK to do so publicly, in the code browser.
>
> Darius
>
>

> I'm already start thinking about implementing some simple protocol for
> interacting with public server. A message protocol can be very dumb
> and straightforward, like:
>
> - list class log entries (class, start date , end date).
> - list package log entries (package, start date , end date).
> - fetch entry by id.
> - add class log entry (date, author, type, contents)
> - add package log entry(date, author, type, contents)
>
> a basic entry types can be:
> - create topic
> - add comment to specific topic
> - add new delta (also creates topic)
> - vote for entry (accept/reject) (you can vote , giving your approval
> for some delta, or for someone's point of view).
>
> A voting is good to collect information about what people think of
> given update. Then  admin/GOD/package maintainer can simply click
> 'Approve' or 'Reject' a change. And all users will have a single
> button 'Download approved changes'.

> -----Original Message-----
> From: Jason Johnson [mailto:[hidden email]]
> Sent: Monday, August 13, 2007 11:25 PM
> To: [hidden email]; The general-purpose Squeak developers list
> Subject: Re: An idea, crazy or not? (Re: Very bad about Squeak in
> blogosfere)
>
> On 8/14/07, Ron Teitelbaum <[hidden email]> wrote:
> > Hi Brad,
> >
> > The issue with too much freedom is that anyone is allowed to break
> things.
> > We have enough trouble as it is with class clutter.  Even I tried
> > (unsuccessfully) to add to Collection.
>
> What changes did you make? (if you just want to point me to the thread
> about it, that's cool as well)
>
> Thanks,
> Jason

> Colin Putney wrote:
> > It's stated a bit harshly, but yeah, that sounds basically accurate. The
> > amazing thing is that, in spite of all that, Squeak is still such a
> > wonderful platform to work with. I do use Squeak in production, and
> > there are very few things I would trade it for.
>
> Well, yes, but you can't deny that the guy's got a point. The
> frustration he's expressing is something that everyone has felt over the
> years. And while there are various plain invalid points in his post
> (like the fact that Squeak has bugs - I'm *shocked* to hear that of
> course and would have never started three products if I'd known that ;-)
> the main emerging point is valid: The lack of quality and maintenance.
> The problems he cites are all known, some of them even have fixes but
> there isn't enough traction in the community to make this all come
> together. And of course the forks don't exactly help because we still
> haven't figured out how to share code across the forks and consequently
> we have left numerous folks behind in the last versions (3.7: all those
> people who don't want m17n; 3.8: all those people who don't want traits)
> and absolutely no way (and interest) in re-integrating those forks.