Pat Maddox a “Beach bum yuppy programmer” and “Ruby dude” is giving a talk entitled Takin’ the railway down to the seaside at the the upcoming Ruby|Web conference. Recently Pat Eyler, interviewed Pat giving us a preview of his talk:

Okay as for what’s so interesting to me about Seaside… it’s 50% the framework and 50% the Pharo environment. Seaside itself represents a step forward in web development similar to how Rails did.  Rails takes care of a lot of the plumbing for you – you don’t have to parse query params, set up response headers, manage the session (unless you want to of course).  Seaside does all that of course but also manages application state for you.  So you don’t have to worry about putting stuff into a database, then pulling it back out and operating on it.

Photo by http://www.flickr.com/photos/ankor2/4820229669/ / CC BY-NC 2.0

This year’s ESUG conference will host the 6th annual Innovation Technology Awards. The top 3 teams with the most innovative software will receive, respectively, €500, €300 and €200 during an awards ceremony at the conference. Developers of any Smalltalk-based software are welcome to compete, and, for the first time, this year entrants are asked to provide a 3-5min video explaining each entry.

There are lots of interesting projects up for the competition, based on Squeak, Pharo, VisualWorks, and Smalltalk/X.  You can find out more about the competition at http://www.esug.org/Conferences/2010/Innovation+Technology+Awards, and of course, you’ll be able to see them for yourself at the conference. See you there!

An excellent article by Hannes Hirzel. Quoted with permission.

I would like to comment on the trigger word “competition” which Pavel has brought up in connection with Squeak / Etoys / Pharo and Cuis. Andreas is advocating a discussion which actually promotes the work and I support this.

1) There is competition – sure – but as a whole it is just a sign of a healthy eco-system to have Squeak / Etoys / Scratch / Pharo and Cuis around. I have written this earlier this year when we were asked to fill in a questionnaire. In fact as a user of a Squeak based Smalltalk “distribution” or “fork” I am happy that there are alternatives. The use of these alternatives may vary though.

2) It is probably more precise to speak of coopetition.

Coopetition or Co-opetition (sometimes spelled “coopertition” or “co-opertition”) is a neologism coined to describe cooperative competition. Coopetition occurs when companies work together for parts of their business where they do not believe they have competitive advantage and where they believe they can share common costs.

Or maybe we should speak of a ‘distributed’ development approach or just having different distributions which share ideas / concepts / strategies / code snippets and packages. This is reuse on all levels (analysis, design, implementation, package, methods). A recent example is the WebClient and the release announcment of Pharo 1.1 for example states (http://www.pharo-project.org/pharo-download/release-1-1).

StandardFilestream now performs read-buffering, dramatically speeding up some operations like “Object compileAll” (2x improvement) as well as various other operations (scanning change lists etc). This change was taken from Squeak.

and further down

A new general cleanup protocol has been added. The cleanUp protocol takes an optional argument to indicate whether we’re doing an aggressive cleanup (which involves deleting projects, change sets, and possibly other destructive actions) or a more gentle cleanup that’s only supposed to clean out transient caches. This change was taken from Squeak.

3) Squeak, Etoys, Pharo, Scratch and Cuis have different “missions” so to say. Or we could say “different customer groups”.

As a reminder for the goals of Squeak I would like to mention the article “Personal Dynamic Media” written in 1977 which is to be found on http://www.scribd.com/doc/454106/Personal-Dynamic-Media. It is amazing what was there at that time.

The problem in the past was that Squeak development did not scale in terms of developers working together and going for forks was the only reasonable thing to do at that time. But this does not mean that new approaches are not feasible. Scratch so to say was ‘silent’ fork. And at the same time a very successful one. It did not create much noise on this list. Maybe we should call it an application. In the area of Squeak these borders are blurred (intentionally) and this might be part of the causes for these kinds of discussions.

4) Going for a minimal kernel with loadable packages maintained by various people is actually meant to stimulate “competition”. People will be encouraged to take the minimal kernel and load all kinds of things on it and distribute the result and create communities around it.

5) For this to work the kernel has to be minimal in a sense that it can be managed by a small team. This is the aspect Cuis strongly promotes and we want to adapt for Squeak. Actually this is not new at all. It has been a long standing goal. But for many reasons about which we have pondered many times it had not been achieved so far. Juan has given the real-life proof that it is possible to maintain his own fork as a single person while at the same time adapting important changes from elsewhere. In addition he has contributed back to the main-line Squeak development. From this point of view we should really de-emphasise the negative aspects of competition.

6) This time we have Andreas, Pavel and Juan for the core, Eliot on the VM side and Bert for the Etoys link working together. Others are working on various aspects improving the system. I think this is an opportunity and there is a real chance of success.

7) As an illustration I did a sketch. (see attached PNG file). I think the overlap of the distributions is considerable. As a follow up it would be nice to have some simple statistics like no. of classes per distribution. Number of classes with identical names across distributions. As the picture is very rough somebody might post a more accurate one.

Squeak, Etroys, Pharo, Cuis

Cheers

Hannes

P.S. Please note that in the meeting report this thread is about Randal says that he wants to contact the other Squeak based projects to talk about a minimal core.

I just came back from the Scheme and Functional Programming Workshop at Montréal, hosted by Marc Feeley and an excellent organisation team. It’s been a fun couple of days putting faces to emails and IRC nicks and attending a handful of pretty interesting talks. Here’s a quick report.

My favourites were the two invited papers. The first day, Olin Shivers presented a pretty cool hack in a delicious talk consisting in actually writing the code he was explaining. Under the title Eager parsing and user interaction with call/cc, he showed us how call/cc is not just an academic toy, but can be put to good use in writing a self-correcting reader for s-expressions on top of the host scheme read (or any other parser, for that matter). He started from the very basics, explaining how input handling and buffering is usually delegated to the terminal driver, which offers a rather dumb, line-oriented service. Wouldn’t it be nice if, as soon as you typed an invalid character (say, a misplaced close paren) the reader complained, before waiting for the whole line to be submitted to read? Well, all we need to do is to implement the input driver in scheme, and he proceeded to show us how. As you know, reading s-expressions is a recursive task, meaning that when you detect invalid input in the middle of a partial s-expression, or want to delete a character, you might find yourself somewhere deep inside a stack of recursive calls and you’ll need to backtrack to a previous checkpoint. That’s an almost canonical use case for call/cc, provided you use it intelligently. Let me tell you that Olin is quite capable of using call/cc as it’s meant to be used, as he immediately demonstrated. I’m skipping the details in the hope that a paper will be available any time soon. As i mentioned, his talk was a beautiful example of live coding: he showed us the skeleton of the implementation and filled it up as he explained how it should work. Olin does know how to write good code, and it was a pleasure (and a lesson) seeing him doing just that. It was all so schemish: a terminal and emacs in the venerable twm: that’s all you need to create beauty.

The second invited talk was by Robby Findler, who gave us a tour of Racket’s contract system, how to use it and the subtleties of implementing it properly. The basic idea dates back to Meyer’s design by contract methodology of the early nineties, and was subsequently explored further by several authors, including Robby. Simple as they sound at first sight, good contracts are not trivial to implement. For instance, it’s vital to assign blame where’s blame is due, and Robby gave examples of how tricky that can get (and how Racket’s contracts do the right thing). Another subtlety arises when you try to write contracts assessing a property of an input data structure (say, you want to ensure that an argument is actually a binary search tree). The problem here is that checking the contract can alter the asymptotic complexity of the wrapped function (e.g., you can go from O(log n) to O(n) in a lookup, an exponential degradation). Racket provides an ingenious fix for that problem, by means of lazy contracts that are checked as the input is traversed by the “real” function.

There was also real-time scheme in Robby’s talk, although in a much more sophisticated way, thanks to Slideshow’s magic, which lets you embed code files and snippets in a presentation, evaluate them and show the results in the same or a new slide. Very elegant. He also used DrRacket a bit during the introductory part of his talk, and i’m starting to understand why some people are so happy with Racket’s IDE: it definitely felt, in his hands, professional and productive. And also kind of fun.

There were also lightning talks. I’m of course biased, but the one i enjoyed most was Andy Wingo’s Guile is OK!, where he showed us how Guile has overcome the problems, perceptual and real, of its first dozen years. For instance, he reminded us how Guile was traditionally a “defmacro scheme”, and he himself a “defmacro guy”… until he studied in earnest Dyvbig’s work and ported his syntax-case implementation to Guile, to become a “syntax-case man” as Guile gained full syntax-case support (i hope i’ll reach that nirvana some day; i still find syntax-case too complex and plagued by unintuitive corner cases (one of them was showed by Aaron Hsu in another lightning talk, where apparently none of us was able to correctly interpret 10 lines of scheme) that make me uneasy; but that’s surely just ignorance on my part). There are many other things that make Guile a respectable citizen of the Scheme Underground, which were also listed in Andy’s talk: i’ll ask him for a PDF, but in the meantime you can just try Guile and see :).

Although this time we didn’t have a talk by Will Clinger, to me it’s always a pleasure to listen to what he has to say, even if only as comments to other people’s talks. For instance, i enjoyed his introduction to Alex Shinn’s R7RS progress report. Will showed us three one dollar coins, of the same size and shape, but different, as he described, in almost everything else. And yet, all three were useful and recognised as (invalid) dollars by the Canadian vending machines at the entrance. He thinks that says something about standards, but he left to us to decide exactly what.

Finally, let me mention that this workshop has alleviated all my quibbles with what i’ve sometimes perceived as a fragmented, almost dysfunctional, community, made up of separate factions following their own path in relative isolation. My feeling during the workshop was nothing of the sort; rather, i’m back with the conviction that there’s much more uniting us that breaking us apart, and that there’s such a thing as a scheme underground ready to take over the world. Some day.