Quickies of the day

Not much time for interesting posts of my own these days, busy
studying history for my final oral exam on Wednesday. Meanwhile,
here’s what interested me in the blogosphere today.

  • Interesting
    blog entry
    from Frederik Lundh on the role of Trackers in the
    Widget Construction Set
    for Python. I might need to write some GUI code soon, maybe this would
    be the way to go.
  • Aaron Wormus worries
    about the embedded database SQLite and bad security practises (Hint:
    Keep the SQLite database file OUT of the web root)
  • Brad Adams posts slides
    and demos
    from his BorCon presentation. I
    think Borland might have a winner on its hand with the next version of
    Delphi, since it seems it will allow both classic Win32 programming
    and .Net programming, filling the niche that VB left with
    VB.Net. There’s a lot of people that wants to write code that runs on
    machines without the .Net runtime, and currently the only Microsoft
    option for that is C++. At the same time, people want to have the
    opportunity to do .Net development as well. Delphi’s might be the best
    option for these people.
  • Sam Ruby notices some character set mismatch in a blog post from
    , and dissects it in great detail. Almost as required a
    reading as Joel Spolsky’s much linked developers
    guide to Unicode
  • David Warnock suggests
    that python is a good language for teaching kids how to code. I’m
    wondering how good Squeak
    works for this, seemingly as it’s designed for this and similar
  • Edward W. Felten suggests,
    like Lessig
    a few weeks ago, that online porn shold be labeled with an
    ”adultsonly” or ”porn” tag. I said
    it then, and I’ll say it again: Take a look at PICS, the w3c standard that’s
    designed precisely for this and similar problems. Maybe the problem is
    that there is no ”standard” rating vocabulary with
    definitions for ”porn” or ”adultsonly”. Or maybe it’s the fact that
    only XML standard geeks can understand that last document. I think
    PICS need an evangelist quick, or others will reimplement it,

Smalltalk and Seaside for web applications

So, after debating at length with Göran about pros and cons of Smalltalk as a platform for real world development, I came to the conclusion that Smalltalk was worth looking into in greater detail, and since I’ve been wanting to write my own blog/wiki hybrid, it was suggested that I check out Seaside, a Smalltalk-based framework for web development comparable to ASP.NET or Java Server Faces.

At first look, Seaside doesn’t look much different than ASP.NET. It’s all about modelling your application’s interface in terms of objects and methods (”messages” for you Smalltalkers). Pages are built up of components, inheriting from System.Web.UI.Control (ASP.Net) or WAComponent (Seaside) that can include other components. When the user does things with any component, it results in events being fired (ASP.NET) or messages being sent (Seaside). Both frameworks seem to strive to abstract away the request/response nature of the web, and to allow the programmer to use a more event-driven approach to developement. In addition, seaside uses at it uses continuations to make it possible to, for example, ask the user something (similar to how a modal dialog would do it in a normal GUI enviroment), and then do something with the provided answer — all within the context of a

The main difference is that programming in the Seaside framework results in a lot less housekeeping code. The object is really a ordinary object, except that it’s executed through the web. The difference didn’t really dawn on me before I tried to recreate WACounter as a ASP.Net Server component — it did involve a whole lot of code to handle events, manage viewstate and so on.

From a security perspective, Seaside has problems with the fact that the session id is present in the URL, and it seems harder to make applications RESTful, but apart from those issues, Seaside is definitly a framework worth looking closer at. From my own perspective, I hope that the ASP.NET developers do 🙂

Unfortunately, things elsewhere has been chaotic (and not in a good way), so I have not had any further time for experimentation with Seaside. As always, further progress will be reported here.

Update: This is a much better explaination of what continuation-based, or synchronous, web programming is.

State of alternative languages on the CLR?

A big selling point in the initial marketing of the .Net platform was that it was supposed to enable code written in different language to interoperate smoothly. I always looked at that claim with a fair amount of suspicion, probably since I remember what it was like to develop classic ASP with Perl. If you remember, ASP was supposed to be usable with any language that supported Active Scripting, and ActiveState brought out a Win32 version of Perl that did. However, I never got it to run as smoothly as with VBScript (If I recall correctly, I had the most problems with getting ADO calls to work right), and since it was a ”unsupported” language, I couldn’t find much help on the net. I was hoping that this time around, Microsoft would try harder to make programming in third-party languages a reality.

Now, while the CLR is designed to run IL code which is language-agnostic in theory, it’s seems obvious to me that the CTS was designed for imperative, object oriented language with strong(-ish) typing, and in particular the C# language. It do not lend itself readily to typeless,dynamic, functional and/or logical languages. Articles like Dynamic languages and virtual machines by Jon Udell and ”Ignoring the Scripts” by Larry O’Brien state that noone is using dynamic languages on the .Net platform to any large degree.

However, while I was researching Smalltalk for the IDG.se column, I stumbled across #Smalltalk that seem to be a fairly useful Smalltalk implementation that compiles to IL code. Also of interest is S#.Net, a dialect of Smalltalk-98 that also runs on the CLR.

Some of the other languages that have been made to run on the CLR are:

All these languages are pretty far from being strongly-typed imperative languages, so it seems that it is indeed possible to use more dynamic languages on the .Net platform. Indeed, Jim Hugunin, the author of IronPython (and Jython, the Python-on-JVM implementation) notes that while his initial intention was to write an article titled ”Why .NET is a terrible platform for dynamic languages”, he ended up with the conclusion that the CLR is indeed a good platform for dynamic languages. My question is: Is anyone using these languages on the .Net platform in real projects? I’d be very interested to hear any success stories.

Smalltalk, risk and success stories

In the comments section to an earlier post  Göran Krampe brought up some excellent points, backed by experience, on my remark that more dynamic languages increases risk in projects, especially if all developers in the project are not on the same level. Here are some of my comments on those, but please do read Göran’s entire comment for more context. Since I find the discussion to be very interesting, I thought I’d bring it up as a new article.

Just read your article at IDG regarding Alan Kay/Smalltalk – and it was good. For once not a single glaring misconception regarding Smalltalk 🙂 – I am a bit jaded by all people throwing around ”truths” about Smalltalk without having actual experience themselves. So kudos for that. 🙂

Thank you! However, I must confess that my Smalltalk experience is limited to playing around with Squeak in my spare time, so I have never used it in a large project. Bear this in mind when you read my response…

Above though it sounds like you are saying that Java would mean a lower risk than Smalltalk for larger projects or projects in which the developers are of ”average” or ”mixed” level. That I definitely do NO agree with on the other hand. 😉


So my experience is the exact opposite. I claim that less experienced developers can more easily be made productive in Smalltalk than in Java. I have repeatedly taught OO *and* the basics of Smalltalk in a single day including practice and then had these pupils find bugs and complement a working small system the next day.

I suspected that a smalltalker might not agree with that 🙂 Please not that I’m only talking about risk, not programmer effiency. Risk isn’t inherently bad, since it usually goes hand in hand with opportunity. Your points about new programmers learning Smalltalk quicker than Java is obviously backed up by experience, but a little beside the point.

The reason that I feel projects done in more dynamic environments (I’m going to lump Smalltalk, Python and Lisp together here, which might not be entirely fair) to have a higher level of risk is that the dynamic properties of the language will allow your system to take on aspects of a domain specific language, especially if some members of your team understands the Zen of Smalltalk/Lisp/Python. For example, in both Lisp and Smalltalk you can essentially redefine parts of the syntax, like the if/then/else statements, and if it makes sense in your design, you might very well want to do that. But if another programmer, who has yet to be enlightened (sticking with the Zen theme) on the expects the syntax to work like default, this might trip him up (Operator overloading in C++ and .Net gives us essentially the same problem). This risk increases if the programmer has been taught more traditional imperative programming in the style of Java/C# and have not been given a good introduction to Smalltalk.

Things like tail recursion, higher order functions, metaclasses and even polymorphism cam be difficult to wrap your head around, especially since you can get a lot of stuff done without them, and in not-so-dynamic environments, you usually do.

Or to put it more soundbite-friendy way: The more dynamic and open-ended a language is, the more choices you have at any given time. Every choice introduces opportunity — and risk.

However, since I haven’t done any large projects in either Smalltalk or Lisp (I did a elevator control system in Scheme in school, though :-)), maybe my opionions should be taken with a grain of salt. I’d be happy to hear your opinions on why the things I’ve mentioned above aren’t such big risk factors after all.

Also, the idea that there is something inherent in Smalltalk making it unsuitable for large scale development is simply not true either. And there is ample evidence for that.

There are very large systems having been built in Smalltalk with great success over a long period of time. And I mean *large*. 14000 classes, 65 developers/staff, 500 users etc, see for example the ”Kapital” system at JP Morgan Bank, https://secure.cwheroes.org/briefingroom_2004/pdf_frame/index.asp?id=4909)

I don’t think I’ve implied anything like that. It is interesting to hear about these big successful projects, but I keep wondering why we don’t hear more about them. Paul Graham published an essay about how good Lisp was for building ViaWeb, and most people that are familiar with XP has at least heard about the C3 project, but there must be more stories, right?

The point of my column that started the debate was that while many of the inventions and discoveries that come from the Smalltalk community are now used everywhere (MVC, JIT, design patterns…, XP), the language itself isn’t. I don’t believe it’s as simple as Sun and Microsoft having a larger marketing budget, but I’m very interested in a discussion of what the real reason could be, as I still think there are more that the general programmer community could learn from Smalltalk.

This month’s IDG.se column: Giving props to Smalltalk

Alan Kay recently won the Turing award for his work on Smalltalk and subsequent projects. I spent some time with the free smalltalk implementation Squeak this weekend, and was particularly impressed with the very dynamic nature of things — being able to modify the actual root Object is not something that’s common in more mainstream environments. Felt very much like a Lisp environment like Emacs, but object oriented. Anyway, it all led to me writing a column on Smalltalk and it’s impact for IDG.se. As usual, in Swedish.

Update: Oh, look, it made the frontpage