Without further ado, here’s what we talked about:

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.

Many thanks, Mr. Schwartz, for the interview.

Arc is still a work in progress. We’ve done little more than take a snapshot of the code and put it online.

I’ve working on this for a long, long time and realized I’ll never get it done properly so I’ll release it anyway.

Why release it now? Because, as I suddenly realized a couple months ago, it’s good enough.

It’s shit but I’m famous enough that people will be talking about it for a long time. People will think it’s good even if it’s really just a bunch of macros on top of Scheme.

I worry about releasing it, because I don’t want there to be forces pushing the language to stop changing.

I’m not going to change it, but if you idiot enought to want to use it, remember that there’s not documention. In other words, don’t call me if you can understand a single line of the code.

Which is why, incidentally, Arc only supports Ascii. MzScheme, which the current version of Arc compiles to, has some more advanced plan for dealing with characters. (…) But the kind of people who would be offended by that wouldn’t like Arc anyway.

I don’t understand and don’t care for any other character set other than my precious ASCII. I learned it forty years ago and I’m not giving it up now. No way. Ah, that why Yahoo! completely rewrote the application I sold them. Bunch of losers.

Why? Because Arc is tuned for exploratory programming, and the W3C-approved way of doing things represents the opposite spirit.

Also, I don’t understand anything about new and modern standards and technologies like XHTML and CSS. And I’m not waste my precious VC time learning them. And I don’t care about you people who dare to make the Web less complicated. Did I mention why Yahoo! had to rewrite the program they bought from me?

Tables are the lists of html. The W3C doesn’t like you to use tables to do more than display tabular data because then it’s unclear what a table cell means.

I told you. I don’t understand anything about HTML.

So experience suggests we should embrace dirtiness. Or at least some forms of it; in other ways, the best quick-and-dirty programs are usually quite clean.

Look! A dumpster! Let’s have some fun!

Arc tries to be a language that’s dirty in the right ways. It tries not to forbid things, for example. (…) For now, best to say it’s a quick and dirty language for writing quick and dirty programs.

I lost so much time with this shit that the world should share my pain. Basic, watch yourself. It’s Arc time! Agora é a vez do Arc.

Most of the advice given is pretty obvious but every programmer should remind himself now and them of what’s important to his programming career. This book does exactly that.

Most of the advice provided in the book is in those areas where programmers have more trouble–like communication and dealing with managers. That’s very necessary, considering how much more integrated progamming has become today, and more so in Agile contexts where outside interaction is paramount. But there is also a lot of practical advice about the best way to prototype, how to handle the problem domain in terms of languages choice and lots of similar subjects.

Also, reading this book reminds me again of how bad Software Craftsmanship was. McBreen really sounds like he read this book, had a couple of nice insights and decided to write an entire book on what should have been an article or an essay.

Of course, two of the most interesting parts of the books are the challenges and exercises. The challenges are questions about the text just read, leading the reader to expand his comprehension and think about the way what has been just learned applies to his work. The exercises, on the other hand, are more about practicing the knowledge in code. Both are good tools to make sure the knowledge acquired in fixed into the reader’s memory.

Of course, the book is not without flaws although many of them may be attributed to the time in which it was written. For example, there is a tendency in the text to present Java and its related technologies as leading the way to the future. But those are small problems in a otherwise great book.

The ending was a little slow, as well, in face of everything that was already said but I would encourage readers to stick with the book. Even in the slow chapters there a lot of food for thought.

All in all, this is a practical and current book that will benefit every programmer reading it. Even programmers with a lot of experience will learn something or at least be reminded of things they should be doing and may not be doing right now. I strongly recommend it.

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.

The code can be found below:

• Base code
• Magritte adaptations (personal taste)

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.

I confess I’m still trying to decide whether people are voting for Obama because although black he’s still a man. I’m not naïve enough to presume all voters are choosing him because he’s more qualified, especially considering the Latino population–at least here in Brazil–has always been strongly sexist where woman in leadership positions are concerned.

Of course, part of this will be tested when Obama–as it seems likely now–goes against the Republican candidate in November. Considering the way the Republican nomination is going, and that many Republicans are actually voting for Obama, the outcome of the election will demonstrate how ready the American people is ready for a president unlike any other in history.

I’m hoping that Obama wins. Not because Hillary is a woman but because I dislike the way she abides to the old school of politics. America needs a new face and Obama would clearly resonate a lot better with the rest of the world.

The theme is indeed interesting, but I was surprised to see how badly the book is written. McBreen, granted, does a decent job of presenting the main arguments for both sides–which is more than you would expect from a proponent of a specific approach–but he also repeats those same arguments endlessly. I don’t know how an editor managed to let something like that happen, but if the incessant repetition were to be eliminated the book would lose at least three quarters of its almost three hundred pages.

McBreen’s argument is simple: Software engineering is appropriate only for huge projects (those is the 100 developer-years and above). For simple projects, needing faster development and no critical hardware infrastructure, the old concept of craftsmanship is much more interesting: a master craftsman running a team of journeyman and apprentices.

I agree with the arguments and many of the other conclusions presented my McBreen. In fact, to the extent I’m concerned, that’s exactly the way I’ve been running my own small company. The results, so far, have been excellent.

Mane people reading the book, however, will quickly give up after reading two or three entire chapters essentially saying the same thing. They won’t look kindly also, to statements like the one below:

Software craftsmanship is the new imperative because many members of the software development community are stating to chase technology for its own sake, forgetting what is important.

The fact that the second part of that sentence is painfully obvious and that the relationship between the first and second part is clearly a non-sequitur doesn’t seem to bother McBreen, tough.

Nevertheless, much of what McBreen is talking about is valid and necessary, as when he describes how good enough software is not really good to users or the industry. Some of this analysis of the prevalent (and wrong) metaphors–like car building versus car design–were interesting enough to motivate me to finish the book.

Ultimately, the book is necessary and part of one of the most important debates taking place today in the industry. I’m afraid, however, that many readers will abandon the book after a couple chapters after being put off by McBreen’s redundant style. More’s the pity because a good editor would made the book the new Peopleware.

Very few people have “voted” using the site so far but it’s interesting to see that Democrats seems to be more likely to engage in such experiments and it’s also interesting to note the Barack Obama almost doesn’t have votes in the “Anybody But” category.

The Democratic nomination being about people rejecting a candidate and not about people choosing one, it will be fascinating to follow the site and see the nascent trends.

God said, “Cancel Program GENESIS.” The universe ceased to exist.

— Arthur C. Clarke

The Universe as a virtual machine or a simulation is a very old idea. Even outside of science, many culture have thought of the material existence as the dream of a god.

Christianity has always dealt introspectively with questions about the relationship of God and the Universe. For example, if only God existed before time and space, where is the Universe in relation to God, and whether the Divinity had to limit Himself when He created the Universe.

More recently, with the rise of favorable conditions, many people have started to devote more time to this kind of exploration–which is a very natural curiosity I may add, considering we all want to know how and why we are here, in this particular time and state.

So it’s no surprise that a recent article, The Physical World as a Virtual Reality, attempts to frame the virtual reality question in light of modern physics. The article is the result of a scientist’s exploration about the implications of a virtual Universe within our current physics framework.

It’s a fascinating reading although no conclusion is given, and no attempt is made to create any mathematical models around the questions present–something I doubt is possible now, and which, in fact, may not be ever possible. Of course, if we were able to prove that the Universe is a simulation, the implications would be civilization-changing (Simulacron-3 / The 13th Floor are very good fictional explorations of those themes).

But more interesting than that would be attempts to hack the code of the Universe, changing and introducing new laws. One could imagine an infinite series of Universes, each running their own giant simulations and experiments.

Of course, that begs the ultimate questions: if we are in a simulation, which form do take blue screens of death?

Regardless of Gladwell’s conclusions, I decided to try and hear a bit of Kenna’s music–and I was floored. Kenna’s music is unclassifiable. It’s a powerful mix of many styles, so well matched that one can’t help but listen endlessly to the variations just one song can provide.

I’ve been listening to the songs of the Make Sure They See My Hands, and the variation is unbelievable. Daylight, the album’s first song, for example, opens with a very New Age intro, evolves to a mix of soul and eletronica, and finally becomes an operatic rock song. Be Still, on the other hand, has the melodic roots of a traditional rock son but also includes a soft blend of synth pop that makes it unforgettable.

All other music share this kind of diversity, using a mix of hip hop, house, synth pop, eletronica, soul, rock, and many other styles that will probably satisfy even the most demanding music lover. The U2 influence is evident in many songs (Sun Red, Sky Blue could have been a U2 song) and I liked that aspect of Kenna’s music as well.

In short, a very worth addition to my music library.

The historic of the field is abysmal. We are now forty years into a period of very few changes in the conceptual basis of software development. For twenty years we have been using basically the same tools, practicing the same moves, and not moving are all. The industry remains bound to the minefield of object oriented programming, relational databases, and bottom-up design.

With regards to Web development, for example, although innovative in many ways, Rails and Django share two flaws that will make them obsolete as quickly as the other many frameworks that have graced the field in the last decade.

The first flaw is conceptual fragmentation. In an attempt to make Web development “painless”, those two frameworks and their descendants have diluted the way the application domain is considered in the application. It’s a more manageable–dumbed-down, if you will, way to develop application but the disconnection between code and domain is fairly evident.

The second flaw is the fixation of opinionated solutions. The use of REST by Rails is a good example of this kind of fixation. REST is a very useful concept, even necessary for some applications, but Rails half-baked external solution, full of accessory tricks, is sub-optimal. But Rails developers are sticking to it without questioning what it represents for their applications because Rails is opinionated software.

In fact, many of those so-called modern frameworks are just pretending complexity does not exist or that they can be easily managed by the use of small methods and a couple of tests.

Test-driven development is now being considered a silver bullet. New developers are using it as a panacea–as a way to guide design as if it would be possible to analyze the problem domain of the application by peering at the small window offered by TDD. The enormous amount of examples showing how to test what has been already tested is quite insane.

Seaside, which I tend to defend as a next step in Web development because of its innovative application of old concepts and its refusal to submit to the common solutions, is not the full solution though. Is great, it’s necessary, but it is still a step below what we really need.

Hopefully, the interest in concepts like language oriented programming will invite attempts to solve the Web development problem is new ways that will transform the field until the next revolution is needed.

Maybe we need a way to generate executable specifications that will really a way to build applications, and not a inferior way to model the expected behavior of an application. Maybe that can be a New-Year resolution: to think of a way to connect the dots, to join the loose treads created in the past twenty years. Is anybody up to it?