Monday, May 28, 2007

Seaside's "Marketing Problem"

Shh! Don't Digg this post. This is a secret post.

Build something in Seaside. Something as idiotic and simple as a table in HTML. It's fun.

Rails has hit the point where you can make crazy money. Yay Rails. That's awesome. I'm happy for Rails.

But if you play with Seaside, even just for a few hours, you quickly realize that Seaside is to Rails what Rails is to J2EE.

The logo on the shirts at RailsConf was an exponential growth curve. Because Rails has one. Why doesn't Seaside have that kind of adoption curve?

Because Rails runs on Unix servers, and Seaside runs on Squeak VMs. Rails runs on Subversion, and Seaside runs on Monticello. Seaside runs on a dialect of Smalltalk that the industry has already reached an opinion about, and Rails runs on a dialect of Smalltalk which looks more like a cross between Perl and Python.

From one perspective, Seaside has a marketing problem. If your goal is to find a job writing Seaside, then Seaside definitely has a marketing problem. But if your goal is to find a secret weapon, Seaside doesn't have a marketing problem - Rails has a marketing problem. There's nothing secret about that weapon.

I loved Ayn Rand books when I was a teenager; these days I'm embarassed to admit I even read them at all. But there's a scene in Atlas Shrugged where the heroine walks into a diner and finds the greatest composer on the face of the planet working there, flipping burgers. Sometimes Seaside feels like that. How dumb must the tech industry be, overlooking something like this? Is it run by monkeys? What the hell is going on?


  1. You are the big monkey man! You post are so funny.........

  2. So have you built anything non trivial in it yet?

  3. A good question! The answer's no. Ever since I got to Los Angeles the siren song of showbiz has been luring me away from programming. Pretty much all the free time I was spending on programming I'm now spending on acting classes.

    I was fiddling with it last night and trying to think of something interesting to build. I definitely need a better blogging system than Blogger, and a better portfolio site than my current one, so a combined blog/portfolio site might be a good thing, but that's not really nontrivial. Honestly I haven't had any interesting Web app ideas recently. I am working on adapting Kirk Haines' CSS DSL for Rails, but that's about it at the moment.

    I had a mental note to build a spellchecker with Seaside, I think I'll give that a go.

  4. I don't think it's a marketing problem, as much as an engineering problem. I've taken a look at Seaside (although admittedly not a long enough look), and Smalltalk, and Lisp -- but there's something missing in these environments that is overwhelmingly evident in Rails, or pieces of J2EE.

    It's the practical side. Here's how you write the code. Here's where the stuff lives in your file system. Here's how you source control it, deploy it, upgrade versions of the framework, upgrade deployed versions of your code, connect it to an existing database, add security, integrate with other stuff, etc.

    Rails is a reaction to real-world problems, whereas some of the more sophisticated solutions out there have extremely elegant science, but inconvenient engineering.

    I agree that marketing is a big part of Rails, but it had to impress and conquer a lot of minds before the concept of marketing was even relevant.

    Maybe Seaside can still get over that hump -- I'm going to take another look at it.

  5. Actually Seaside has solutions for these things as well, I think GemStone will even make load-balancing Seaside effortless, but the information is difficult to obtain, and on Unix, you know where to find all this stuff, and in many cases already know it (Subversion, for instance). This is what I mean by a marketing problem. It takes time to find out what version control you should use with Seaside, for instance. And if you can't find it, despite its existence, that's where the conclusion of an engineering problem comes from. Seaside has those solutions - they're just not easy to find. Findability is a very important part of marketing.

  6. The 'secretiveness' of seaside is one of the most compelling parts of it.

  7. So what will you use your secret weapon for? Maybe to build the next web 2.0 application that will put you on google's radar. It may worked for, but for everything else the obscurity of the technology is just holding us back.

    A lot of bright minds and bright ideas will never come to the platform. I do believe using smalltalk will make me a better programmer, but believe more in pair programming and I cant find anyone to pair program in smalltalk/seaside with me.

  8. Personally I don't know how RoR managed to pull it off. It still hasn't hit the big time in adoption, but everybody at least knows it exists now. It's got conferences built around it. There are books on Ruby and Rails, and I'm sure that helps a lot.

    I agree Seaside has a marketing problem. It has part of the problem solved in the sense that there are books you can find online (free ones) on the Smalltalk language itself. There are books on Squeak you can find at Amazon. A few, at least, will teach you about most of the development tools you can use within it. There are NO books on Seaside. I think that would be a good start. One reason I found out about it is there are some demo videos of it on Google Video.

    One of the problems with Squeak is it's been going into a "divergence" phase. It was originally written by Alan Kay and his compatriots as an educational tool for school kids, and it's been kinda successful at that. It is used in some school systems around the world (and it's in the OLPC). I heard just recently that a North Carolina school district is going to start using Squeak soon. Most of the literature out there on it is focused on education. The most recent one, which you can find at the major booksellers is "Squeak: Programming With Robots", by Stephane Ducasse. So there's energy behind that.

    There's developer energy behind Seaside, but there's hardly any support. To find out about it you have to "pay attention" to the Seaside mailing list, and any blogs that talk about it, like Ramon's, or Lukas Renggli's. Otherwise, there is always the source code...

    It's an adjustment all around to use Squeak/Seaside. You have to think about the development process in its entirety in a different way. Some/most developers don't like that. They like the fact that you can use any editor you want with Ruby, and you can save code in files. That's at least familiar to them. One of the objections is they see Squeak as forcing them to use one code editor (there's more than one, BTW). It seems to me, though, that programmers are willing to put up with a lot just to get this. In Ruby you basically have a line debugger. I don't know if there's even a full screen debugger for it. At least you get this in Squeak, and you get the ability to correct code while the app. is running, just like in Ruby. Apparently there's a way to get Emacs to work with Squeak, if that's really your cup of tea.

    The "conclusion" the industry has come to about Smalltalk may be that it chose Unix/Linux as their development environment rather than the "one GUI to unite them all" approach of Smalltalk.

    Smalltalk, like Lisp, became somewhat popular in the 1980s. From what I remember, in terms of finding work, Smalltalk was more popular than RoR is today. Lisp may have been at the level Ruby is now. They both flamed out in the early 90s. The reason is still kind of a mystery to me. I've heard a couple people blame Java, that it sucked the oxygen out of the Smalltalk community, but I don't understand why. Maybe it was the draw of the web, and the Smalltalk and Lisp communities were behind the curve on it. The internet changed a lot of things in the technology world back then. This is just a guess, but I think it killed Commodore and Atari (the computer makers) as well. Amigas did fine on the "text internet", but the web was another matter. The ST had absolutely no internet connectivity back then (unless you count logging in to a terminal server, which I don't), because Atari flat out didn't anticipate it.

  9. Posted confusingly:

    "It seems to me, though, that programmers are willing to put up with a lot just to get this. In Ruby you basically have a line debugger."

    Meant to say:

    It seems to me, though, that programmers are willing to put up with a lot just to get the ability to save to files and use their own editor.

  10. I'm too using RoR for my early-afternoon-to-late-night work. ;-)

    I started with Smalltalk few days ago and been reading a lot about Seaside and Aida/Web (written by Janko Mivsek). It seems to me, both can run fastest circles side by side around today's web frameworks. Even RoR.

    I have no real hands-on expirience with either of them (yet), but from what I've seen so far, choosing either Seaside or Aida/Web for web development is a step in the right direction. At least for some types of web applications.

    Of course, if one plans a web app with few 10.000 concurrent users, there are other tools available. ;-)

  11. You're on the right track Giles, but I think the problem is engineering as well as marketing. I agree with Matthew that there are some practical considerations as well.

    Coincidentally, only last night I was watching the ec3 presentation on Seaside and while it seems very interesting for the project I have in mind, my first thought was, "how am I going to deploy this?"

    The Seaside page doesn't have a whole lot of deployment info out there. Even dabble-db deployment info is hard to find. Ruby and Rails build on familiar terrain for most people One can get a host, or even get EC2 for scaled deployment.

    How do I deploy squeak/seaside on a linux box? I just haven't been very lucky in finding that information readily (maybe it's out there?) I guess it could be done via X somehow, but that information is not out there readily available.

    Thanks for a thought provoking article, maybe you should do one on Seaside deployment options. Before one can get to source control, one has to have the confidence that their legwork done on a macbook will be easily transportable to a deployable form if/when that time comes.



  12. @Mark Miller
    There are a whole lot of Squeak forks:
    - SmallLand
    - SqueakLand
    - OLPC
    - Croquet
    - Sophie
    - Scratch
    The problem is there aren't any resources maintaining it they all flow into one of the forks. Just look at Monticello, because it is basically not maintained everyone runs his own fork.
    I/O: Everyone knows I/O sucks in Squeak, nobody does anything against it.
    The VW: don't even get me started. Officially everything is fine and perfect. Behind the scenes already ten years ago they talked about the new and cool VM/JIT/GC they'd have today. Today we still have the one of ten years ago. Just for fun: There are even class comments outlining what they'd do differently.
    Tools: The code browsers don't support multi selection (eg. drag multiple classes), noone cares. Have you recently used the Refactoring Browser in Squeak and noticed how many refactorings don't work? Noone cares. Serious tool support for traits anyone?
    Mophic (the GUI framework): seriously?
    And then there's what Alan said about Squeak and EToys at the London meeting with Shuttleworth (the stuff that was not published). There are so many design decisions in there that'd made sense in the 70ties that don't make sense on a machine with 1GB of RAM.

    Here's how you write the code: code browser (standard, rb, omni, whatever)
    Here's where the stuff lives in your file system: not at all
    Here's how you source control it, deploy it, upgrade versions of the framework, upgrade deployed versions of your code: Monticello (in Squeak)
    add security: do it yourself
    connect it to an existing database: depends on database :( (in Squeak)
    integrate with other stuff: libraries

    Seaside is just a web framework it does not persistence at all.

  13. Seaside is pretty cool, but I didn't keep using it because I hate that my files aren't files, and thus can't be edited with vim, or whatever else I want. The version control is sketchy, or maybe it was just a lack of understanding but a) it seemed like i was version controlling the whole damn image and b) it *was* an image. The other problem being that nobody offers seaside hosting. No, you have to pay for a box entirely for you, which I'll do for a commercial app with a real future but for something, like seaside, to really catch on people have to be able to put up apps that exist for fun, learning, or to scratch a personal itch not profit. *If* those apps go over well then maybe they'll invest the time in writing a commercial one.

  14. @masukomi
    There is free non-commercial available at Seaside-Hosting. This is done by the current core developer of Seaside so these guys know what they're doing. The reason they don't offer commercial hosting is because they can't offer it at a price that competes with a virtual or even full root server rental. If you're willing to pay this premium write them a mail, they work for money too.

    There is also commercial hosting available at Seaside Parasol but I know nobody who uses it so I can't tell you about the quality of it.

  15. It's true, Seaside has lots of obstacles to adoption. I don't know about the problems with Squeak but I've heard some of those things before, so I'm inclined to believe it.

    Maybe that's the answer to the question in my post - without serious chops in an obscure language, you don't even know where to begin. It still doesn't really explain why people with options don't choose Seaside. For instance, virtual hosting, with virtually every other system you have a whole marketplace, with Seaside you only have a few options - but if you're in a large corporation you can set up internal Seaside aps with commodity hardware.

    Obviously the first question in this post's comments is whether or not I've built anything serious with it, and I have to admit the answer's no, but I've been spending a lot of time on my acting classes, and I've definitely explored Seaside's libraries and learned enough about it to enjoy it a lot.

    Actually, wait.

    I know exactly the answer to this question.

    There's very interesting research in online music demonstrating that the difference between excellent material which becomes a hit and excellent material which does reasonably well is essentially random. What's remarkable isn't that Seaside is excellent but obscure; that's totally logical. What's remarkable is that Rails is a hit. Looking at Seaside and comparing it to Rails just creates unreasonable expectations.

    It's like asking why Happs isn't exploding when it hasn't even hit version 1.0 yet.

  16. The problem with seaside and squeak is its too different from what people are used to. Its beautiful technology, but you have to do too much learning and change all your workflow to use it.

    I'm playing with it for months but I never had enough time to use it for real projects.

    The good stuff about platforms like Python, and Unix in general, is that you can learn and add new tools and technologies to your workflow as you need them - you don't have to switch everything at once.

    Secret weapon is great, but when its too secret, there are not enough developers, and then the technology does not advance fast enough. A healthy technology can not be too secret.

  17. Just had a brainfart... why not have a "Scratch like" interface to seaside?

    Scratch has a widget set for simple programming constructs. Take that same approach with Seaside, build a widget set for web programming and hook those up to seaside on the back.

    have two modes: Visual mode i.e., Designer Mode and Expert Mode which basically shows the class browser and friends if you feel like going further than this "scaffolding" of sorts.

    This will give corporate tinkerers a quick OOTB option to create one off apps which a Desktop type machine would be more than happy to handle.

    I'm not a smalltalk expert, but wondering how hard it would be to build a scratch-like widget set to get people started.

    Right now, the examples and screencasts are for web developers, to get the general public interested the above mentioned out of the box experience would be sure to create a lot of converts.

  18. Actually I'm talking about something like Peter Howell's Hands On environment done in Squeak.

    In my opinion, that should be the next logical step for Seaside (but I'm just a lay person when it comes to web development)

    I would really love to see something like that though.. that would be awesome!

    Unfortunately the thesis website has gone off the air. I can't find any mirrors anywhere. It was a great idea though.

  19. @Anonymous:

    Re: How am I going to deploy this?

    Someone else (perhaps you?--another anonymous) posted about two sites that host Seaside. I know that's paltry. RoR hosting sites are a dime a dozen. One of the major obstacles to Squeak hosting at this point is neither of these hosters hosts a database, at least the last time I checked.

    At this point Seaside is basically for those who can self-host. You can use the Seaside-Hosting service (previously mentioned and linked here) for the fun, creative projects. They host for free.

    As for self-hosting, check out Ramon Leon's blog. He has a couple posts on how to host and scale Seaside, both on Windows Server and Linux. It turns out the scaling solution is not that different from how you'd scale RoR.

    As for version control, use Monticello. Again, it works differently than you'd expect. This is a challenge that everyone ends up going through when they're first learning this stuff. You have to almost blank out all of the idiosyncratic stuff you've learned over the years about how computing is supposed to work, and just think, "How would this be done more intuitively?" One of the previous (anonymous) posts is right. You essentially do not save code into files. You can, but that's not the normal mode of operation in Squeak. Instead everything lives in an image, in memory or serialized to a file. The analogy I'd make to how it works is putting a Windows PC into hibernation, and then waking it up again. That's essentially what's going on when you start or quit the Squeak environment, except most everything lives in memory, not files.

    There is a text backup of every source code change you make, in what's called the "changes" file, which accompanies the image. If you make a change that was a mistake, you can revert to a previous version of what you changed. It's built in to the system. When you want to look up a class or a method, there are helpers for finding what you're looking for. Just look it up by name, not by file. If it's in the image, it will find it for you, or give you a selection of possible matches.

    Code is categorized, by package names and then categories. These distinctions are non-binding, meaning that a class A in one category is not considered distinct from a class A in another category. It's just a way for you to find the class in the system. Methods are also grouped by categories (within classes).

    Monticello works on this principle. Rather than version controlling the whole image (which you can do, but is pretty wasteful), you can version control packages, and method categories with Monticello. When you bring it up, it shows you a listing of all of the packages and method categories, and their repositories (versioning files). You can add new repositories for packages/method categories you create. I've just started using it myself, so I'm no expert yet. There's a tutorial on it here. It uses "red click", "yellow click", and "blue click" as mouse clicking terms. It defines them though. Squeak is based on the Smalltalk-80 system, which used 3-button mice. Each mouse button was a different color. Even if you don't have a 3-button mouse, you can get to the correct menu by going through a hoop or two.

    If you want to save source code to individual files, you can do so. It's called "filing out". You can select a class, or a category, right-click on it, and select "fileout". Squeak will ask you for the filename you want. It will save the source to [name].st. This is viewable in a text editor. You'll notice that there's some extra mark-up in the file. This is metadata, which makes it possible to "filein" the file. If you bring up the File List (an app. in Squeak--like Windows Explorer), right-click on the [name].st file, and select "filein", it will load the file's classes and methods into the image.

    The fundamental concept of Squeak that is different from almost anything else out there, is that you are extending the system itself. It's like in Unix if you create a new utility. You can use it in conjunction with other utilities that are already part of the system. It's the same way with classes in Squeak. Any classes you create become part of the system and can be used in conjunction with the classes that are already there. You can have application-specific classes. Those are necessary for specific apps you create. I find it's easier to create reusable code in this system, because all of my classes are globally accessible.

    There is an extension to Squeak called "Tweak" which adds the concept of "islands", which I believe are analogous to namespaces in more traditional languages. You can define classes in an "island", and it will be considered different from another class by the same name on a different "island". I think that's how it works.

    Re: Squeak forks

    Anonymous (whoever you are), you forgot Seaside and Tweak.

    I think of the forks as different versions of Windows, or Unix, or Linux, etc. They each have their unique features and different ways of operating. Some OSes fork less than others. It's a matter of taste. The way Squeak has been developed is a lot like the way Linux has been developed, if you look at the community models. From what I've heard Linux development has been just as chaotic. The chaos is smoothed out by the commercial distros, but each is its own fork.

    It's possible to have multiple images around, if you want. When you start Squeak up, it'll ask you which one you want to load (or I've seen demos where you can drag and drop the image onto the VM to start it up). I keep a baseline image around that's unmodified just in case I don't want to deal with the modifications I made in a different project.

    Re: Seaside is just a web framework. It persists nothing at all

    I beg to disagree. It persists session state better than anything else out there. True, it does not persist using a database. It uses Squeak's own facilities to persist state between round trips to the server. The great thing about it is you hardly have to worry at all about session state. Seaside does it for you. If you want to scale Seaside you need to use "sticky" sessions.

    As for the VM being old, I found a blog post last year by someone who had done some benchmark tests between Squeak, Ruby, Python, and Io (Self?). Squeak beat Ruby in performance. Maybe you still don't consider that fast, but even though Ruby has a lot more support, and is updated more often, it's still a laggard when it comes to performance.

    Re: Scratch-like interface, or "scaffolds" for Seaside

    There was a template system added to Seaside in one of its early versions, but it was later taken out. This was the most jarring difference between Seaside and the other web frameworks I had used. In Seaside you write your HTML in Smalltalk code, and it's quite easy to do. As for fashioning the end user interface, Seaside developers recommend you use CSS for that. It turns out that the lack of a templating system tends to make your apps. more scalable. Seaside uses a component model of web page development. So the page is made up of component "pieces" that are aggregated together when the page is rendered. Think of partials in RoR or user controls in .Net, except that's the whole model. This way if you need to reuse a component in another page it's no problem. You don't have to copy template markup from one page and paste it into another, along with its code. You just re-use the component in the other page's code.

    Whew! Was that enough info. for y'all?

  20. Seaside killed by Squeak.

    In any other language you start with a blank page in your favorite editor.

    When you start in Squeak you have all thouse tons of things on screen loaded. Fun to play, terrible to understand.

    It is a main reason why i abadoned learning SmallTalk.

    What Squeak needs is a desktop preconfigured for PROGRAMMING. Not for amazinization with bells and whistles. Only workspace, inspector, browser and tip how to start. AND NOTHING ELSE.

  21. "In any other language you start with a blank page in your favorite editor."

    Which is what's wrong with all those other languages. Seriously, how do you expect technology to ever advance if you can't let go how things "are usually done".

    Yes, if you want to use Smalltalk you have to learn a new way of doing things. What everyone seems to miss is that the Smalltalk way of doing things is freaking simpler that what you do now.

    Let go of your files, you don't need them, they're holding you back. Source control in Smalltalk is better than your file based source control. The Smalltalk IDE and environment are better than your text editor. It doesn't matter whether you believe it or not, it's true.

    If you think Squeak looks silly, stop downloading the public image meant for kids and go get a developer image from Damien or me.

    The hardest thing about learning Smalltalk and using Seaside is forgetting all that crap you've learned over the years that you don't need anymore.

    Smalltalk, Squeak, and Seaside aren't hard to learn at all. It's forgetting all the stuff you already know long enough to see that things can be done differently, and with much less effort that is the hard part.

    Between the Seaside mailing list and a few blogs here and there, you have everything you need to learn and get answers easily. Just ask questions, someone will answer.

    Smalltalk is possibly, still too far ahead of its time. Take 70% of Smalltalk, slap a Python/JavaScript'ish syntax on it, put it in files, and call it Ruby and suddenly everyone goes gaga over it.

    It doesn't say a lot about developers being open minded folk. No wonder Alan Kay always looks so frustrated. It's 2007 and the mainstream world still hasn't caught up to 1980!

  22. @ivan - I have a Squeak image exactly like what you describe. I use it as the starting point when I tinker with Seaside. I can make it available, although my schedule's kinda crazy for the next few days. but I think you're right - just as Rails has scaffolding, generators, etc., Seaside should have a "Start Here" image. Damien Cassou has one but it's still just a bit compicated.

    Really, the only question I have is how do you export an image for other people to download, and how do you include the background image when you do so? (Might as well add some marketing dazzle.)

  23. Session: GLASS: GemStone, Linux, Apache, Seaside, and Smalltalk
    Detailed Session Information
    Seminar # S312
    Day Wednesday,' May 02, 2007
    Time 11:00 am-11:50 am
    Title GLASS: GemStone, Linux, Apache, Seaside, and Smalltalk
    Speaker(s) Dale Henrichs , James Foster
    Abstract The Seaside framework provides a layered set of abstractions over HTTP and HTML that can be used for developing sophisticated web applications in Smalltalk. Seaside was developed in Squeak and ports are available for VisualWorks and for Dolphin. While the Seaside framework elegantly addresses HTML generation and application flow-of-control issues, it still leaves a few challenges for the developer�including persistence and multi-user coorrdination. In this seminar we will demonstrate a port of Seaside to a new dialect: GemStone/S. As a multi-user, persistent Smalltalk implementation that has no native user interface, GemStone/S provides an excellent environment for serving HTML and keeping

    Dale Henrichs's Bio
    Dale Henrichs has been working in computers since 1975. He has been working on and in Smalltalk nearly fulltime since 1985 and has worked for Tektronix, Digitalk, Parc-Place/Digitalk and Gemstone. Currently Dale is a Principal Engineer on the Gemstone/S server team at Gemstone.

    James Foster's Bio
    James Foster has been working with computers since Fortran programs were submitted on punch cards and �core� was a fine mesh of wires with tiny magnetic rings (1971). He has been programming in Smalltalk since 1993 and has developed applications with VisualSmalltalk, VisualAge, VisualWorks, Dolphin, and GemStone/S. James is currently QA Lead on the

  24. Well, that was kind of weird. A little context would have been nice!

    Here's a little context for the link - it's a presentation on Seaside and GemStone from IT 360, earlier this month.

  25. I mean, for the comment, not for the link.

  26. @Giles

    To share your image, just put the .image and .changes on a server. That's it. If you've set a kickass background, it comes along for free.

    Some people use Squeak as a presentation vehicle with all kinds of crazy background images going on in multiple projects. All they share is the image and changes.

  27. @Ramon:

    As you can tell I agree with you. :) And as Alan Kay has said sometimes, "Forget the adults." They're hopeless. I read a blog post a couple days ago that was called something like "Why I took the kids off of Python". He said that he introduced his kids to Python to learn programming, doing turtle graphics, but the whole thing with switching window focus between the editor and the runtime environment, and managing files made his kids spend most of their time figuring out how to manage the system rather than programming. So he had them use Squeak instead with Ducasse's book, and they loved it. It just made sense to them.

    It's so ironic it's funny. Squeak is great for total beginners who have no context on what programming is about, but it's not so hot for experts, who are already so used to a different system that they find no benefit in it at all.

    When I talk to people about Squeak and how to use it I try to use analogies to what they already know. Usually they're analogies to OS features.

    I read a conversation recently between Alan Kay and some folks on the Squeak developer list. They were discussing operating systems, and Kay said something like, "The operating system is what's left out of the programming language.", and most OSes do only a fair job of bringing the two parts together into a functioning executable program. Smalltalk was originally the operating system of the computer it ran on. Today, not so much, but it still "thinks" it's an OS all the same.

    I've been reading some of the trackbacks to Giles's post. Some of the people who've commented in these places have pointed to just what Giles talked about: Most smalltalkers don't want the community to grow, or want it to grow at a slow pace. They're happy that it's a "secret sauce" that's not handed to people on a silver platter. I don't agree with the attitude, as I imagine you don't either.

    As is pretty clear, the key to higher adoption is clear documentation. Until that comes along, most people are going to turn their nose up at it.

  28. The downside to the obscurity is that if you want to say "No more Rails! It's Seaside for me!" then you kind of have a more tightly constrained set of job options.

    I'm actually OK with the obscurity on every other front, certainly the huge popularity of Rails makes crufty Rails apps an inevitability for the near future, whereas the upside to the obscurity is nobody will ever curse under their breath about having to maintain this frustrating, crufty legacy app in Seaside.

    But the obscurity isn't actually what bothers me. What bothers me is that the obscurity doesn't make sense for business reasons. It seems as if Seaside's strengths are known, and known to be significant. It would seem there's clear evidence that the effort pays off if you take it, and once you get past the hump of total unfamiliarity, it's also fun.

    Maybe it's just that there aren't more programmers who make decisions for business reasons, or business people who understand this sort of information, that mystifies me. You could say Seaside's a terrible business decision, because there's no market, or you could say it's an incredible business decision, because it's pure blue ocean strategy; the tech is gold and there's nobody else in the market. I don't know.

  29. @david - thanks!

    I'm going to see about putting together a real basic "getting started" image then.

  30. @Giles:

    Come to think of it I don't remember (and I'm not going to take the time to look now) whether these commenters elsewhere were speaking in the present tense or past tense. They may have been talking about why Smalltalk flamed out in the early 1990s. To clarify, what they were saying is that most Smalltalkers like (or liked) the "secret sauce" quality of it, because they feel it gives them a competitive advantage in the business sense. It's like what Paul Graham talked about with ViaWeb. He kept his use of Lisp a secret. He was afraid if word got out then his competitors would start using it. I don't know how real that fear was. It sounds to me like he discounted the fact that Lisp wasn't a popular language with developers in the first place. Even if competitors wanted to use it they'd be hard pressed to find programmers who were proficient at it.

    I think a different mindset is emerging. At least I hope it is. Squeak has an open source license of a sort. I can't remember, but I don't think it's GPL. It encourages contributions to the community somehow. The software that comes with it encourages it as well. The entire system's source code is available right in the system, and with Monticello it's easy to share what you've written with others, using as a repository (the Squeak equivalent of SourceForge). Seaside, Magritte, Glorp, Pier, etc. are good frameworks that solve business problems, and are completely open source. So it seems like now more sharing is going on than maybe there used to be.

    On the Lisp front there's Peter Siebel's "Practical Common Lisp", which talks about how to solve business problems with it.

    I like the idea of popularizing both Squeak and Lisp, because it will ultimately advance the state of the art. It does only a few people any good if it's kept secret. The wider society doesn't benefit at all. More money and wasted energy gets flushed down the drain on failed projects than is really justified in our industry, partly because we're using languages that aren't that powerful. For complex projects, the more code you have to write, the more the project gets away from you. You have less control over it.

    Even if Smalltalk and Lisp were to become popular and, as you predict, the code gets messier, and the competitive advantage goes away, the state of the art in programming can and should still advance. There's Self, the prototype-based language. There's Erlang, etc. In years to come there will be even better ones. As Alan Kay said a few years ago, even though Lisp and Smalltalk still look good, compared to what's out there now, "they're really quite obsolete", and, "Smalltalk is like an ancient Greek play that was just better than what most other cultures had come up with." I think he also compared it to the development of the arch for building, as opposed to making buildings out of blocks and huge sculpted rocks, like the Egyptians did. We've got a long way to go before building software becomes like building the Empire State Building, which took a few hundred builders less than a year to construct, as opposed to tens of thousands of builders taking 20 years to build a pyramid.

    Oh, and I found the link to "Why we took the kids off of Python". I'm not trying to bash Python as a language. I was using this article to make a different point.

  31. Maybe it's just that there aren't more programmers who make decisions for business reasons, or business people who understand this sort of information, that mystifies me.

    There are a LOT of programmers who make decisions for non-business reasons. It's my theory that most programmers don't understand business. I'll speak for myself. I only understand it a little. When I paid more attention to business computing I used to hear ALL the time programmers groan on and on about how the business managers were making stupid IT decisions. And a lot of times they were right. You've talked about this some yourself. Most programmers couldn't run a successful business if their lives depended on it. They have their favorite technology and they want so badly for that to be the only thing that matters, but it doesn't. You still have to convince people to use what you've created, but that means distilling the whole thing down to where it's useful for them. Whether it's fun or interesting to you does not matter. You know all this, of course.

    The main obstacle to dynamic languages becoming popular is unfamiliarity, but this is kind of a chicken and egg problem. Up until recently it wasn't too practical to use dynamic languages, except on high-end systems, because otherwise they ran too slowly. The hardware wasn't designed to run this stuff, and still isn't, but now it's fast enough that it runs at a decent speed. These languages are viable now. So I think people are beginning to understand the advantages of them. You see that with Ruby and Python.

    What I've been able to glean from this discussion is that Ruby and Python take what people are already familiar with and extend it. They're file-based, and Perl programmers will find some things that are familiar. Perl has its own history. Perl became popular in the 90s as a way of building web sites (in conjunction with C++). My own theory is Perl became popular for that because that's what Unix system administrators used before the web became popular. They used it as a more powerful shell scripting language for managing processes. It's natural to assume that Unix system administrators became webmasters when that came along, and probably set the standard for what languages would be used.

    As you've seen in this discussion, Smalltalk is unlike anything else out there. It really is like learning a new operating system. A lot of people who would be interested in it are already steeped in the way Unix does things and they like it. They've always frowned on GUI-intensive interfaces anyway.

    I think the people who would be more amenable to Squeak are people like you, me, and Ramon: Windows and Mac users/developers. We're already familiar with working with a GUI environment. We work in it and we like it, but we also have experience developing for the web. The thing is, Squeak has an image problem. People who like GUIs appreciate aesthetics (alright, Ramon, I think I've figured this out now...). Most newbies to Squeak get the standard version which screams "KID'S TOY" to them. I've kind of been at fault for this in my own small way, because when I blogged about where to get it, I directed people to the standard version. It doesn't make a good first impression--except to kids. The reason I got interested in it at all is I was introduced to the Smalltalk language 16 years ago in college, and I really liked it then. I learned the history of it more recently. The Smalltalk system invented at Xerox PARC was a HUGE inspiration for Apple to create the Lisa and the Macintosh. All of this has spurred me on to learn it more, even when I'd get discouraged with it. You kind of have to fall in love with what Squeak is, rather than how it looks in order to appreciate it. Most people go by first impressions, which is natural.

    Every once in a while, like you've seen in these comments, I see Smalltalk programmers who like a more refined interface, and they go with the commercial Smalltalk implementations. So if people diss Squeak, it doesn't mean they don't like the fundamentals of it. They just like a nicer package, and Seaside will run on a couple of them.


Note: Only a member of this blog may post a comment.