Tell us a bit about you: what’s your background, how did you started programming, what are you doing today?

I taught myself programming when I was 9. By the time I was 15, I was
teaching programming from the front of the room to my classmates, and writing
contract code on the weekends for real money.

I worked for three different companies for a total of eight years, before
starting Stonehenge in 1985. Stonehenge has grown over the years: we’ve
can count 17 of the Fortune 100 Companies as our clients.

I spend a lot of my time lecturing and writing these days, but I also still
design, create, and review code as well. I answer questions for free for
about an hour or two each day on the dozens of mailing lists and blogs and web
communities I frequent.

You are extremely famous in the Perl community, but now you are
strongly advocating Smalltalk/Seaside. What did change? When did you
start using Smalltalk?

I started using Smalltalk before Perl was even invented, back in 1982. I’ve
already written that story up at my blog.

What are Smalltalk advantages over other traditional languages like Perl,
Ruby or Python, for example?

Smalltalk has a very simple syntax: I can teach the entire syntax in about 20
minutes, and include it as part of my talk introducing people to Seaside.
The major Smalltalk implementations (except GNU Smalltalk) also
have a mature IDE, allowing easy exploration of code relationships, and to
learn the libraries as needed by looking at both the implementation and the
uses.

And that’s a bonus as well: we have two commercial smalltalks (Cincom and
GemStone/S) as well as two open smalltalks (Squeak and GNU Smalltalk) all
supporting Seaside. This allows a nervous manager who might be hesitant at
selecting a strictly “volunteer-based” language to also have two commercial
vendors to pick up support. Options are good!

Do you believe Smalltalk will finally reach mainstream status?

Well, it *had* mainstream status in the mid 90s, just before Java entered, at
least with large Wall Street firms and other institutions who wanted rapid GUI
development to stay ahead.

But yes, I believe Smalltalk is positioned today to reenter as a major
player. For details, see my “Year of Smalltalk” post.

Also, your talk was entitled, “Seaside: Your Next Web Framework”.
What is really interesting about Seaside?

I like how Seaside can abstract both control flow (along one axis) and
representation (along the other axis) with relative ease. Seaside seems to
put the right related things near each other. I also like the “debug the
broken webhit within the webhit”: when something blows up, I can explore in
the standard debugger, fix what’s broken, patch up any mess, and then continue
within the same web hit, as if nothing broke.

Also, the traditional Rails persistence is provided with Active Record, which
requires objects to go through an object-relational mapper to drive SQL
queries. Seaside can do the same thing (via GLORP), but a better solution is
to avoid the mapping entirely, using things like the open source Magma
solution, or the commercial GemStone/S Virtual Machine. When you can get rid
of the ORM layer, you get a lot of speed back, and a much easier programming
environment.

What do you see in Seaside’s future, and how does it compare to the
future of the other frameworks?

The Seaside team is currently refactoring and repackaging Seaside so that
portability will be easier to manage and so that you can pull in just
the parts that you need. I also see a lot of bolt-ons being created, like
the Pier CMS and adaptors for various APIs such as Google Graphs.

Do you think the market is ready for Seaside?

Yes. Ruby on Rails reopened the discussions about what to do in a post-Java
world, by going back to the late-binding languages like Perl and Python and
Smalltalk. And Seaside is a mature framework, being even older than Rails,
but just not as well known. I’m hoping to change that.

Have you deployed anything using Seaside? If so, what were the
challenges?

I’m working on a few projects now, but nothing is public yet. The initial
challenge was the relative lack of documentation, so I spent the better part
of two days going through every posting to the Seaside mailing list. I feel
much better informed now, but my eyes were pretty bleary. I hope to repackage
the knowledge I gained into postings to my blog as well as helping to answer
questions on the IRC channel and mailing list.

You are now part of the Squeak Foundation Board. What are your
plans for the Foundation?

My primary concerns are licensing issues, release management, and proper
publicity. All of these issues are being addressed, but of course, we’re all
volunteers and always looking for more qualified volunteers to help.

Are there any Squeak Foundation plans for Seaside?

Nothing formal that I’m aware of. However, Squeak is the primary development
platform for Seaside, so we’re sure that Squeak will remain an essential
component.

What are the most promising developments in the Smalltalk/Seaside
world currently?

Well, what got me involved is GLASS, the GemStone/Linux/Apache/Seaside/Squeak
solution to get people up and running with Seaside quickly. This also
entailed the GemStone management creating a zero-cost commercial license for a
fully functional (but limited) version of GemStone/S. With this free version
of GemStone/S, you can build a business, and when your business exceeds the
capabilities, there are strategies about migrating to larger licenses that are
reasonable. It’s a great solution for getting a rock-solid
commercially-supported Smalltalk VM with persistence and clustering into your
plans.

What about next year’s FISL. How did you manage to get three entire
days for Smalltalk?

As I said, “it all started over a couple of Caipirinhas…”

What are your plans for those three days? Do you plan to bring
other Smalltalkers?

I will be working with the FISL organizers and the various vendors and groups
of the Smalltalk community to produce a full mini-conference. I hope to have
both beginning and advanced Smalltalk training, as well as various Seaside
tutorials. I expect this conference will attract a significant number of
Smalltalk developers to FISL for the first time, as well as expose Smalltalk
to the remainder of FISL, so it’s a win for everybody.

To those curious about the way Seaside applications are structured or just looking for a simple example to see how they differ from the other more usual Web frameworks, I’m making available the code of a simple experiment of mine: a small system to keep information about the books I’m reading, have read or intend to read.

For the remote possibility somebody asks about this, the system is inspired and modeled after Caffo‘s bookshelf. Of course, his system is prettier–and faster too, at the moment.

Some caveats about the code:

It’s running on a very old and underpowered server.

This is an alpha version so don’t expect subtleties in the code. I’m still learning Seaside, and migrating from 2.6 to 2.8 proved an interesting exercise.

The application depends on an instance of [GOODS]. The connection data for the instance can be configured in the application settings.

The login is a beautiful example of how things should not be done. I started with a normal login system, got lazy in the process, and adapted it to allow just one user to log. The user can be configured in the application settings as well.

I’m not using any deployment optimizations. Everything is in memory, and thumbnails are generated on the fly.

The code is Squeak-specific.

That said, the system shows how a Seaside application runs, and how Magritte can be used to model data. It’s enough to show how Seaside is different from any other of the usual Web frameworks in use today.

While the code will run in any Squeak 3.9 image, I recommend Damien Cassou’s Squeak-Web image. With his latest image, it’s just a matter of loading GOODS and the code to begin development. GOODS configuration, of course, is left as an exercise to the reader.