You can't edit it with vi or emacs; you don't do source control with svn; everything's weird and new.

Kurt says most people never get past this hump. He says the few who do see the light; they return to other languages certain they've glimpsed a new world, a plane beyond. I agree with him there.

But I have to disagree with Kurt's claim that Seaside doesn't have a marketing problem. I don't think anything he said was wrong. I just want a broader use of the term "marketing."

The entire Ruby on Rails phenomenon constitues a powerful and compelling argument that building low barriers to adoption into a system is a very effective marketing move.

I recently tried to get the Rails core team to switch the for loops in the scaffolding templates to iterators, on the grounds that this would encourage new Rails programmers to use iterators instead of repeating their bad old habits with for loops. I failed completely. Josh Susser said that replacing for loops with iterators would set up a barrier to adoption for new Rails programmers, and that was that. The idea didn't fly for a second.

Low barriers to adoption are an explicit strategy in Rails, and part of the reason for its success. This strategy is a marketing strategy. Realistically, if you're doing trivial tasks in Ruby, the difference between a for loop and an iterator is very slight. There is no technological benefit or loss here; it's purely a question of how people feel about it. A PHP programmer sees a for loop, they feel comfortable; they see an iterator, they're puzzled. A tiny difference, but that's the decision the team made. The scaffolding templates use for loops for purposes of marketing. It's a move designed to expand the user base.

Seaside has a marketing problem, because Smalltalk has a marketing problem. It's a marketing problem built into the technology. This is why Avi Bryant's idea of a GemStone Ruby VM offering persistence for Web apps is a good idea. With Ruby you've basically got people programming in Smalltalk already.

6 comments:

I think the same could've been said for Lisp, except that Slava Akhmechet broke through the understanding barrier last year. I think XML has turned what always was a marketing problem for Lisp into marketing potential, if the Lisp community would just take advantage of it (and that's a big if).

As for Ruby programmers programming in Smalltalk already, that's roughly correct. If only Seaside were ported to it, though. I've been hearing conflicting reports about continuations being removed from Ruby. Some people say that decision has been made, but I talked to a guy who's been working with Ruby for a while, about a month ago, and he said continuations are still there. So I suppose there might still be hope.

Ruby has continuations, but Ruby isn't turtles all the way down, so you can't rewrite Ruby's continuations the way you can rewrite Squeak's continuations. That much I know; after that I'm fuzzy. If I recall correctly, the precise nature of the problem is that Ruby continuations can't be made serializable, and the change to continuations in Seaside is that they are serialized.

Of course it's pretty easy to review the source, and I just did, and it does appear that Seaside's writing and reading its continuations to and from streams, so I probably remembered correctly.

As far as I know, the work to make Ruby continuations serializable would be more substantive than the work to make Squeak continuations serializable. You'd have to drop down to the C of the interpreter, and further you'd have to fork Ruby.

However, there's a lot more to Seaside than continuations, and certainly if you were to use component objects in Ruby with rendering methods and which used Markaby in those methods, instead of templates, you'd have a similar experience, but you wouldn't have the all-in-one niftiness, or the built-in Web-based IDE, or really much of anything except for components and Markaby. OK, forget this paragraph, that was useless.

OK wait no. You'd also have a nice degree of reconfigurable flexibility, and that's something, at least.

I was up @ 5am and this comment isn't going to get any more coherent, but could become less so, so I'm gonna quit while I'm ahead. (Although I realize I'm not that far ahead.)

I have been at the WTF stage when I fired up squeak for the first time :)

I don't agree that the interface is so sophisticated that most mere mortals just are not ready for it. I think the initial "WTF" impressions are a result of design decisions which didn't really take beginners into account (despite vociferous claims to the contrary)

What makes me such an expert at being new? precisely that: Being New! :)

There is something to be learned from the fact that most of the times the people who make others understand a technology are actually outsiders, or at the periphery.

Say what you will of COBOL, but it was Grace Hopper who did it. Chuck Moore is a brilliant guy, but if you ever read his explanations of Forth code or listened to his fireside chats, you would know immediately that he is not the guy to who should be evangalizing that marvelous language. It was Leo Brodie, a technical writer by trade, who wrote two of the classics of Forth and computer science for that matter (IMO at least.)

It was not Matz who made ruby insanely popular, it was an MIS student, initially on the outside of the language who did it! (DHH).

It would seem that people who are closest to the technology are somehow paralyzed by the very affinity and their minute understanding of it.

Even though Smalltalk in general and Squeak (and Seaside) in particular maybe "superior" technologies, the interface seems to reflect a mindset which is not necessarily welcoming to the non-initiates. Even though, at the face of things, Squeak is meant for kids (of all categories of learners).

Scratch is built on top of Squeak and is lightyears ahead of it in terms of interface design. So, it is definitely possible to do it, right there in squeak. I still stand by my suggestion of a "Scratch like" interface to seaside. I didn't really mean a templating system for seaside by that, but a set of constraints and two modes: visual (scratchy widghets) and expert (teh old class browser). Problem domain being Web Application programming.

That is what scratch does, it imposes constraints by making available only things which apply to the domain at hand. I happen to think the same can be done for Seaside.

cheers.

P.S. If this comment turns out to be a rambling rant in the morning, I blame it at posting at such a late hour in a sleep deprived state.

It's not that the interface is so sophisticated that most mere mortals are not ready for it. It's that most programmers already have a strong sense of context of what programming and computing is, that when they come upon Squeak, they go "WTF??", because it's so different. I mean, take a look at why Rails has been taking off. It's not as popular as, say, Java, not by a longshot, but there's still buzz about it, and interest is growing. It has nothing like a Scratch interface. It doesn't even have a page designer tool. You write the mark-up for your views in a text/code editor. It's popular with people who already understand how to build web apps. with a database back end. It caters to them. It says, "Hey, look. You can define tables in the database, and they'll show up instantly in your web interface. And you can customize the web interface thusly." It has an "instant gratification" factor for them. You do something in the database, it shows up in your browser with little work on your part. Giles is right. It is marketing, but it's targeted at a certain audience. Would kids who know nothing about programming at the start find it interesting and fun? I doubt it.

I've seen some people in the Seaside mailing list suggest creating an ActiveRecord-like framework for Seaside. People turned up their nose at it, seeing that approach as unsophisticated. Ramon Leon took a crack at it several months ago. If you look at his blog there's more where that came from.

I misspoke a bit in the comments on Giles's last post on this, when I said that Squeak in conjunction with "Programming With Robots" (Ducasse's book) was so easy for beginners. It turns out the reason is that the book has kids using a customized image, which likely has some things already laid out and configured, so there are fewer mysterious things to deal with.

The way I really got my start with Squeak was to get a book on it. I got "Squeak: Object-Oriented Design with Multimedia Applications", by Mark Guzdial. You can get it at Amazon. It's an old book (from 2000) that's out of print, but you can still get copies. The material in there is still relevant in terms of getting the basics. I'll warn you that not everything in the book works with the modern Squeak versions. I've occasionally had to fall back on the version of Squeak that comes on CD with the book, Version 2.7. It's real important to do the exercises. Otherwise you won't get much out of it. Once you get the basics, the Smalltalk language and Seaside become more understandable.

I guess there's less irony to this than I thought. When I thought about one of my other comments on this, I realized that kids do get a nice introduction to Squeak, because of eToys, whose interface is built right into the standard version. Squeak makes it easy to get started with putting stuff on the screen and manipulating it. Seaside is not nearly as approachable. You have to access it through Squeak's programming tools, and the class library. You have to read some instructional blogs on it if you want any direction about where to start. You have to really want to learn it to have the motivation to do so.

I see what you mean now about a Scratch-like interface. I've taken a look at Scratch and while it seems like a neat introduction to programming for kids, I didn't find it that interesting for someone like myself. What you're suggesting is something like an ASP.Net design interface, where you can drag and drop controls onto a design surface, tweak settings in a GUI, and then run the app. I can understand the appeal of that approach for simple apps. I know from working in ASP.Net that even though the design-surface interface is nice, there were always times when I was dealing with a complex interface where I had to drop down into the template mark-up code. In the case of Seaside, that would mean opening a code browser on the selected component so you could view/edit the Smalltalk code that generates the display. So while it would be a nice introduction, it likely would not satisfy more knowledgeable developers. The web does not lend itself well to that kind of graphical design environment. That's the reason really good web page design tools are few and expensive, IMO.

Come to think of it, this would be an interesting design challenge. The design surface would, I imagine, have to be a cross between an HTML/CSS renderer and a native GUI, that's capable of reacting to events and generating code.

I imagine one reason this hasn't happened is because the infrastructure is not there yet. All you have to do is look at Scamper, which is Squeak's web browser app., to see that it doesn't render web pages well. Not to say that it can't do it at all, but the software hasn't been developed. I think the main reason a beginner's interface for Seaside hasn't been done is because the people who learned it all had the same motivations: to learn it, finally fall in love with it, and then use it. None of them thought, "Gosh, how would a beginner approach this? We need to create a beginner's interface." By the time they've learned it, they think, "This is great!" and they go on to use it in projects. They don't have the inclination or the time to create that interface. The people who would be interested in doing this are educators, but if they use Squeak at all they're more interested in eToys and such.

The ideal would be a couple different web app. design strategies brought to reality that run on top of Seaside. One would be as you suggest, a beginner's interface that emphasizes what the developer can see (the web UI), and the other would be more of a data-centric strategy that emphasizes rendering what's in a database, or some other data store. Ramon's at least started that effort.

Another way of saying it is "Taking the Red Pill". :) That thought came into my head several months ago. It's this feeling that you've caught a glimpse of what programming can be like, and it's so good you don't want to go back. Though when I've thought about job prospects, I have sometimes felt like that back-stabber in The Matrix who thought, kicking himself, "Why didn't I take the Blue Pill??" It's that part of me that's shaking my head at myself, saying, "Mark, Mark, Mark...(sigh) WTF are you doing with your life?" It's the part of me that wants to ensure my survival, and cautions me against making dumb mistakes. But then I think, "If it feels so good, it can't be a dumb mistake, can it?" I think my worst nightmare with this is, yes, you can learn something that's obscure and "insanely great", but it's just going to lead you down a rathole in terms of your physical existence. Better to just join the herd and at least earn enough money to sustain yourself, and put away some savings for retirement. Ugh!! I hate thinking like this, but it does come up.

Re: Seaside having a marketing problem

I've heard some Seaside evangelists say (myself included) that RoR is "the gateway drug to Seaside". Maybe we're just dreaming. In my case that's the way it worked out. I went to Ruby first, explored that for a month or two, and then discovered Squeak and Seaside and thought it was great. Ruby helps bridge that barrier of understanding that would stump most people.