"If you care a lot about the future, it shows that you believe in what you're doing now and you think it's worthwhile enough to have some lasting impact." – Syd Mead

Menu

Month: October 2006

I had been researching some books on Squeak in September and I found a couple by Mark Guzdial, a professor in the College of Computing at the Georgia Institute of Technology. In his bio. it notes that he is “the inventor of the Media Computation approach to learning introductory computing, which uses contextualized computing education to attract and retain students.”

A topic he’s talked about a couple of times covers why students are turned off to programming. This is an important topic, because there’s been a noted decline in the number of skilled developers in the U.S. If you were to ask most people in the field why there’s been such a drop off, the first response you’re likely to get is “economics”, and “companies are sending those jobs off to India. Why would anyone enter this field now?” For years now, since the bottom dropped out of IT spending in 2001, there’s been a contingent of people in the technology community who have actively discouraged people from entering the programming field. They think they’re doing others a favor. They’re convinced that like farming and manufacturing, Americans just don’t code anymore. There’s no future in it, and it’s going overseas.

Guzdial has a different observation: A significant number of Americans are afraid of programming, or are just not interested. They have an aversion to it. His thinking is they perceive it as being too hard. He talks about his direct first-hand experience with this in two posts: The most recent, “Preparing Students for Java: A Rational Model for K-14 CS”, and one from September called, “Students find programming distasteful” (Update 5-24-2013: These two were from Mark’s Amazon blog, which has since disappeared. He set up a new blog on WordPress, though I don’t think any old posts were brought over.)

“Brin’s argument echoes one that Eric Roberts of Stanford has been making for awhile: That we’ve made the intro languages so hard that students can’t just simply explore algorithmic thinking anymore.”

He goes on to suggest what he thinks is a more rational approach.

In his post from September, he talks about his experience with students trying to drop his class once they find out there’s programming involved, and the similar experience that other professors in other disciplines have when programming is introduced:

“Mike is running a trial section of 140 students. The day that he introduced the programming aspect, a dozen students applied to drop the course. Note that: nearly 10% of the enrollment. They had to talk to Mike to drop, because of the trial nature of the section, and the common reason was that they didn’t want to do any programming in Physics.

Now, I can understand the students who wanted to drop Computational Freakonomics. Students have different expectations of a study abroad course than they do of an on-campus course, and programming clearly wasn’t part of those expectations. But Introductory Physics is a required course for nearly everyone at Georgia Tech. If the trial goes well, they will use this approach for all sections of Physics at Georgia Tech. Students dislike programming so much that they are dropping a required course – I guess in the hope that the trial goes badly and that there’s some future chance of taking physics without a programming component.

Where does this dislike of programming come from? This isn’t about not liking programming as a job choice –this isn’t about avoiding facing a cubicle engaged in long, asocial hours hacking. This is about using programming as a useful tool in a non-CS course. It’s unlikely that most of the students in the Physics class have even had any programming, and yet they’re willing to drop a required course to avoid it.”

Guzdial’s own course, “Computational Freakonomics”, featured programming, but students were disallowed from dropping it, due to how the course was classified. Nevertheless a significant number of students tried to do so when they found out programming was involved. He asked for feedback from the students when the course was done. He said, “the feedback was strongly positive–even on the programming.” The difference was the experience of programming. In the past Guzdial has talked about using the Python language in his courses, so I suspect he used it here. The language was probably a significant factor in the positive experiences of his students. He doesn’t say that. It’s just my guess.

I was a little surprised to hear about this myself. When I was a student in the public schools, there was a push for what was called at the time “computer literacy”. In the late 1970s and very early 1980s, computer programming was considered a part of the literacy curriculum. Schools were buying computers, and so were parents for their children. Every computer came with a programming language, typically BASIC. The Apple II computer even had a “machine monitor” where you could drop down to programming it directly in machine code (hexadecimal) if you wanted to. Every computer had some sort of “introduction to programming” instructional material included with them as well, giving a tutorial on BASIC. The schools I went to had programming courses in BASIC and LOGO.

One of my first experiences with a computer was an Atari 400 that was available for public use at my local library, back in 1981. I was interested in learning how to program, mainly because I saw what other people were programming. It was neat stuff. The library had a software package I could check out, published by Atari, that ran an automated BASIC tutorial. So one day I checked it out, plopped the tape in the tape drive, typed a command on the computer, and off it went. It had an automatic visual display and a voice track, explaining a bit about how the computer worked, and then how to get started programming. I can’t remember exactly, but it probably took 2 or 3 hours to get all the way through it (I may be way off). That alone didn’t help me learn it. I read through a book they had on Atari BASIC, and I got some help from others who stopped in to use other computers there. It took a few months of just slogging away at it before I felt like I really got it.

The literacy curriculum started to change by the mid-1980s when I entered high school. At that point it emphasized how to use a word processor, spreadsheet, and perhaps a database. Programming classes still existed in the schools, but there was less of a feeling of urgency to take them. Programming classes are still taught in public schools today, though I can’t say how popular they are.

When the phenomenon of “programming as literacy” was taking root, people took up programming with enthusiasm. There were several computer magazines that one could find at grocery and book stores that contained what were called “type-in programs”. The complete source code for a project was printed in the magazine, again, typically in BASIC, along with an article explaining what it was. You typed in the code, tried to run it, realized you had made typing mistakes, tried to find your bugs, and correct them. It was very educational. Eventually you hoped that you could get it to work, and enjoy it. Sometimes the program was a game. Sometimes it was a useful application or utility program that you might use many times to make the computing experience easier. This coexisted with commercial software that people could buy. The type-ins were usually simple programs, not commercial quality. They weren’t quite as exciting, had fewer features, and were not as easy to use. The magazines were cheap, though, compared to commercial software: $4 per issue vs. $40 for one piece of low-end commercial software. Each issue contained several type-in programs. For me there was a sense of accomplishment. I learned a bit about each program as I typed it in. It added to my own education on how to program.

It seems to me that back then, people were not afraid of programming. People embraced it as a constructive, perhaps even advantageous learning activity. It was definitely new, and people felt that it was “the wave of the future”, so “don’t get left behind”.

Movies and TV shows even got in on the game. Some talked about hacking a computer at some level. Usually the hacking was “magical”. They didn’t show you a thing about how it was done. It had the feel of someone casting a spell, something mysterious goes on, and then the right thing happens. They didn’t show anyone programming, but there was definitely a sense you got of the characters knowing the machine, and getting it to do what they wanted, which was pretty much what programming was about then. Two movies come to mind that had this as a significant theme: “Tron”, and “Wargames”. There were other movies that had scenes where this came into play, but they were gags. The TV shows that had this that I can think of were “Automan”, “Whiz Kids”, and…well…I guess “Knight Rider”, though that’s a bit of a stretch, I admit. There were a couple movies I remember that tried to make nerdiness look cool: “Real Genius”, and “Weird Science”, though the 2nd one was just hokey.

There were shows galore about computers and programming on PBS then. The ones I can think of are “Computer Chronicles”, and a computer feature series produced by the BBC, and an instructional series produced by the Annenburg/CPB Project (I can’t remember their names). The one by Annenburg went into some depth into how computers operated, and how to actually program them. In the late 80s, a mini-series was produced and shown on PBS, called “The Machine That Changed The World” that talked about computer history.

The enthusiasm waned in the late 1980s. Magazines that used to offer type-ins either changed their format, taking the type-ins out, or eventually went under, as most of them did in the early 1990s.

So what changed? Is it the languages that are being used now? Guzdial suggests that the CS educational system, perhaps as early as middle and high school, is hitting students too hard, too fast. I don’t know quite what he’s talking about. He suggests that Java would be appropriate as an AP course in high school, as opposed to introducing it to students earlier. That makes sense to me, but in my state, Colorado, that’s what we’re doing, last I heard. Maybe other school systems are introducing it sooner?

The conventional wisdom for years in the IT business community has been that students avoid programming because they think it’s uncool. They have a negative perception of nerds, and they don’t want to become one of them. But Guzdial contradicts this notion. It’s not that they’re afraid they’ll become antisocial people sitting in front of a computer all day. They’re just afraid of programming, period. He also points out the irony that there are many in non-CS fields who are learning to program once they get out in the work world (though what he describes them doing sounds more like script programming), in order to automate repetitive tasks. So what’s going on? Anyone have any ideas?

Here, he talks about how to configure Apache to work with Seaside. Then we got into deployment issues: how to run Squeak in “headless” mode (where no GUI appears), and how to disable the “halos” in your Seaside application. From what I’ve been reading recently on the Seaside mailing list, the solution David gives for this may also disable the “development toolbar” that shows up in your app. during development. This is what I wanted, since in many apps it’s not appropriate to allow users access to the Code Browser, the CSS for the page, and whatnot. We also talk about how to terminate a process in Squeak, or terminate Squeak itself, in case of an infinite loop or some other lock-up.

Here are David’s responses to my questions:

Hi Mark,

Mark Miller wrote:

I found your tutorial, and it’s been helpful in answering some questions, but I have some others. They have to do with administration, which I noticed you have a slot for in your tutorial, but no link.

I’ve been approached to do a web project for a potential customer and I’m interested in doing it in Seaside. The way my projects typically work is that once I’m done with development, I deploy it to a customer’s system or a third party ISP, and they manage the web server while it’s in production. What concerns me some is it appears that in order for the Seaside app. to run, the web server must run inside the Squeak environment. I understand that of course the Seaside app. has to run in Squeak. When I first approached this I hoped that it would be possible to run the Squeak app. from something like Apache, through a plug-in runtime, so that all the administrator would have to worry about is doing some setup with Apache, or perhaps run something from the operating system command line. Is there a way to do this? The only web server I’ve read about so far for Seaside is Comanche. My concern is that the administrator will not know about operating in the Squeak/Comanche environment and will be resistant to taking the time to learn it.

You can have Apache proxy to the squeak server, no “plug-in” needed (well, mod_proxy has to be installed). I do this on several production servers. It has the advantage of allowing you to use fancy rewrite rules to load balance your requests across several squeak images/machines. For example, on an apache server you can specify:

You can run squeak with the “-headless” option or “-vm-display-none” (I’m not sure about this last one) from a script and it won’t even raise a GUI. I prefer to have the UI available for debugging purposes but there is no reason you can’t do things just the way you described. I even wrote a little Seaside app that let’s me upload and run scripts on the server. There’s also an app that someone wrote (Goran? Avi?) that starts up a Squeak-based VNC server on a headless squeak image so you can interact with it “on demand”. Scan the mailling list archives for VNC and you’ll find some comments on this approach and probably some help getting started. My servers are all Linux-based and I keep a (unix) VNC session with my Squeak images open (head-full) so I can deal with problems without having to start up the Squeak VNC server.

One word of warning…Kom’s keep alive is buggy when working through a proxy. Disable it with:

(HttpService serviceNamed: ‘httpd’) keepAlive: false

Goran might have fixed that but it has bitten me enough times that I just disable it.

I’ve seen demos of the “halos” around elements on a web page, and the web-based code editing environment. These look great for doing my development work, but is it possible to restrict access to these features? I don’t like the idea of just any user being able to enter the code editing environment and change code in the app.

On the config page set “deployment mode” to true. This is per application so once you’ve disabled halos noone using the app will see them. I’m not familiar with a way to do this per-session.

In a different tutorial it talked about setting up a username and password when the Comanche server components are first installed. What features does this restrict access to?

Never heard of it. Kom is a pretty plugable server, there is a ModAuth which allows you to specify an “authentication DB”. This would only be useful if you were serving more than just Seaside from Kom. I let Apache serve all of my static content so my production servers don’t even have ModFile in their Kom stacks (basically the config you get with “WAKom startOn: 8888”). You can study your Kom config by using exploring:

HttpService serviceNamed: ‘httpd’

look at “plug” and work your way down. Be ready for a mess though.

Lastly, in case something happens, like some sort of lock-up or infinite loop (an error on my part) in a Seaside app., is there a way to terminate a process? I’m not real familiar with Squeak at this point, so perhaps this is an elementary question.

You can

1) Terminate the squeak VM from the UNIX command line or from the windows task manager
2) Terminate a process from within Squeak using the Process Browser (ProcessBrowser open)
3) Hit alt-. in Squeak if it becomes unresponsive due to an infinite loop in a process

There is also a process which can be activated (via preferences, I think) which watches for CPU hogs and gives you the option to terminate. I do not recommend this on a server though. Maybe you can study the code and come up with something similar but more tunable…the existing one kicks in too soon. As I said, I don’t use it right now so I can’t really give you specifics.

Deploying your first Seaside app generally takes a little more reading than deploying, say, a PHP or perl app but once you’ve got a working configuration you’ll find it to be simpler to manage than either of those two.

Good luck and let me know if you have any more questions…

David

Ramon Leon of On Smalltalk put up a post recently that also talks about how to configure Apache so it works with Seaside and IIS!

This question was asked recently on The Weekly Squeak blog. They asked, “Is it a toy or an instrument?” This was inspired by a discussion on the Squeak developers mailing list. The discussion got started when someone posted their concern that Squeak is perceived too much us a toy, in a derogatory sense. People take one look at it, and it looks like something a kid could play with, but no serious developer would consider.

It’s a fact of life. Image can create prejudice against a perfectly good technology. It’s happened to the best of them. Apple Computer went through this. Even though it was going gangbusters in the late 1970s, it hadn’t really managed to penetrate business. Companies just didn’t trust Apple. When IBM came out with its PC, businesses took a second look at microcomputers, and Apple sales actually went up as a result. The carefully crafted image of IBM helped legitimize the microcomputer platform in general.

Atari and Commodore, who used to be in the microcomputer business, were perceived by their more popular offerings. Atari was big in video games. Commodore was big in cheap microcomputers that a lot of people played games on. When they came out with more powerful machines: the Atari ST, and the Commodore Amiga, they were generally perceived as game machines. I can remember that even Consumer Reports called them that. As machines they were much more capable than the IBM PC or Apple II (though the IIGS caught up on many fronts). The Apple Macintosh, released one year before the ST and Amiga, was also very capable, more so than a PC, but lacked a color display at the time.

The Mac found a niche with graphics artists and publishers. They liked its expressiveness and its graphical capabilities. The Atari ST managed to find a niche with musical artists, because of its best-in-class MIDI capabilities and supporting software. The Commodore Amiga found its calling in multimedia, media production, and video editing.

The niche that Smalltalk seems to have found (I’m basing this on people’s comments in discussion forums) is in very high-end applications, and specificly financial analysis.

Getting back to the discussion, some said, “Yes, it’s a toy,” in a non-derogatory sense. They like that it’s fun and encourages experimentation, like a toy does. Alan Kay chimed in, saying it was more like an instrument: one can “mess around” with it, or get into the realm of art and produce serious work. He said this was the intent that went into designing Squeak.

This is an interesting point. Many developers think like artists. I count myself as one of them. So an “instrument” is appealing. Depending on the user, they may like the idea of using an instrument, or not. A lot of home and educational users would probably like the idea, so long as the instrument is not too complicated. A lot of business users, however, think of technology as a machine, almost in the industrial sense (think masculine): something that does useful work, can handle massive amounts of “material” (data) efficiently. It can store massive amounts of it, “slice it and dice it”, and produce tables and charts. An “instrument” to them is fragile, and would be unable to handle “the load”.

It doesn’t matter if this doesn’t match reality. Perception matters.

In the discussion some complained that Squeak needed a “decent interface”, and that outsiders have been turned off by Squeak’s UI, which is unlike Windows or Mac OS X. Some follow-on messages got into the perception of Squeak. This is only important if anyone is interested in Squeak being adopted more. I certainly am.

A good point made by one respondant was that if you’re interested in making Squeak look like a more popular UI, people should check out wxSqueak, which interfaces it with the open source, multi-platform wxWidget library. It provides a more native UI look and feel to Squeak programs, depending on what platform (Windows, OS X, or Linux(?)) it’s running on.

This is a definite possibility. I was wondering recently about how to create Smalltalk programs in Squeak that would reach a wider audience of non-Squeakers. This is one solution. Another is one I pointed out earlier, the Squeak-.Net bridge. Just presenting all of the options. If you’re looking for a cross-platform OS-native UI solution, wxSqueak would seem to be the way to go.

Some said Squeak is a development platform: a VM, a set of APIs, an IDE, etc.

As for me, I think Squeak is a universal platform. It can be your desktop environment, complete with multimedia features, if you want it to be. It can be a web application server. It can be a behind-the-scenes VM for running desktop applications on another operating system. To say it’s just an environment in which one can experiment, or a VM, or a set of APIs and IDE, etc. is too limiting. It’s all these of things and more.

In homage to the idea that it’s an instrument, I give you this 😀 (Yeah, I’m a cat person. No I did not make this video. Just found it.):

Avi Bryant’s blog, named “HREF Considered Harmful”, is a play on the title of a famous computer science paper. What was the name of that paper, and who wrote it? Hint: this relates to an earlier blog post I wrote.

This is a joyous ride, and I’m still on it! I’ve been rediscovering my “roots”, and moving forward. It’s ironic that technologies that are now decades old hold keys to the future. As I’ve written about previously, I rediscovered Lisp earlier this year. I’ve put that on the shelf for a while, but I intend to get back to it.

Back in August, I dug out some old Smalltalk code I had written for a couple assignments while I was getting my Bachelor’s in computer science, back in the early 1990s. I have fond memories of working with this language. Up to this point I haven’t had a chance to use it in my work, unfortunately. While I was finding videos for my “Great moments in modern computer history” post, I happened upon some videos of Alan Kay dispensing his wisdom, and demonstrating what he had been working on since about the late 90s: Squeak and Croquet. I talked about this a bit in my post, and gave a link to where you could watch one of his presentations. Here are most of the others.

What first interested me in Squeak was its multimedia features. In the online videos of his presentations, Kay used Squeak to create his presentation slides. They look like they might’ve be done in Powerpoint, but they were not. They had integrated video and EToys demonstrations. I liked his demonstrations of what children could do with EToys, where they could draw their own graphical objects, and manipulate them with a little bit of script, or just using their “halos.” Halos are a Squeak concept. Since everything in Squeak is an object, even fundamental graphical elements like menus and windows, they can all be manipulated by the user in standard ways. They can be rotated and moved, made to disappear, etc., just by using the mouse. The same can be done with graphics that a user draws.

As I said before, Kay is worth listening to, even without the cool graphics. One speech to note is the one he gave for his Turing Award, which he received in 2003. I like the title of it: Alan Kay gave a speech when he won his Turing Award in 2003 entitled “The Computer Revolution Hasn’t Happened Yet.” Amen! The Turing Award is like a “lifetime achievement” award in the computer science community. Only people who have made significant contributions to the discipline are awarded it. There’s a list of previous Turing Award winners here. If you’ve gotten an education in computer science you will have seen at least a few of these names.

Croquet is the more recent project he’s worked on. It’s like something I imagined would come along one day: a 3D user interface. Croquet is an expansion of the idea of Smalltalk. The intent is to create a collaborative environment. It uses elements that are already part of MMPGs (Massively Multi-player Games). Each user has an “avatar” in the environment, though you typically have a first-person POV. The team behind Croquet purposely made networking and collaborative computing easy. Like Smalltalk, Croquet is designed to encourage experimentation, and appears to be ideally suited for creating 3D simulations. It’s in beta at this point. While it looks neat, it’s not something I’m particularly interested in, but perhaps one day I’ll get into it. It couldn’t have come at a better time, since people have just been introduced to collaborative computing over the last several years, though as with everything else, what people usually see is a web interface. Croquet is more along the lines of the classical GUI, but upgraded.

Squeak is something I can relate to. It’s a free, open source implementation of the Smalltalk system. It’s the canonical object-oriented programming environment. Every object-oriented language shares many of its features, though the more popular ones lack some of them.

From what I can surmise, Squeak is a lot like the original Smalltalk system developed at Xerox PARC more than 30 years ago, though it’s gotten some updates. It has color, for one thing. 😉 It’s practically its own operating system, though it runs in Windows, Mac, Linux, etc. as an application. The interface is like the desktop-style UI we’re all used to by now (though I’ve heard it’s possible to run it in a “headless” mode, where you can just start it from a command line with no GUI). All code and data are stored as objects in an image file, not unlike the virtualization images used with bona fide operating systems in Virtual PC or VMWare. In reality, it’s probably more like Common Lisp, which also can create image files. Squeak allows users and developers to do unlimited undos to changes to its system. You can in effect “go back in time” to an earlier system state. Conceivably users could even use this feature to go back to an earlier version of Squeak than the one they have (not recommended–it’s better to just download an earlier release of Squeak if that’s what you’re after). It’s a bit like System Restore in Windows XP, and I’m sure Mac OS X has a similar system-wide feature.

Developmer Tools

Edit 10/12/06:

This slipped my mind when I first wrote this post. Squeak comes with its own developer tools that you can select from a sidebar-type menu within the Squeak interface. There’s a lot to get used to with Squeak. Even though it has a desktop-style interface, it doesn’t operate like Windows or the Mac. A difference I noticed right off the bat is you do not double-click on icons to get a GUI program started. Rather you click and drag. Doing this starts the tool right up. Things are not where a newbie Squeaker expects them to be, so you have to have some patience and search for them. After a while you’ll get used to it.

It has an IDE, called a “Browser,” that allows you to see all the classes in the system, plus any that you create. It has its own code editor and debugger.

Developers can create GUI projects (analogous to an application) that run inside Squeak, using a GUI framework called Morphic.

Squeak has its own components for creating presentations as well. They’re fairly easy to set up and get going.

Squeak in education

Alan Kay has long focused on education. His Squeak/EToys demos are targeted at those interested in using technology in education. Squeak used to contain many working multimedia features, and that’s what they were targeted at. I talk about this more below. The educational site for Squeak is here.

Smalltalk

Smalltalk was designed to be a fundamental technology upon which greater technologies could be constructed. For example Croquet is written in Squeak (Smalltalk). The Smalltalk programming language is powerful. Programmers can get things done in fewer lines of code than they could in most other languages. Some of the reasons are it’s a dynamically typed language, it implements method calls as parameterized messages that are passed to objects, it implements closures, and has support for continuations. Lisp shares all of these features except for the object-oriented message passing (though CLOS may have them. I don’t know). Closures are chunks of code that can be passed around between objects, but which maintain enough of the context from where they were created to execute them successfully when the referencing objects choose to run them. An analogy to closures would be anonymous methods in .Net and Java. Below are a couple of examples.

|x|
x := 0.
#(5 4 3) do: [:a | x := x + a].
Transcript show: x.

‘x’ is a temporary variable. The array #(5 4 3), in this case an array literal, has a method called “do:” that takes a closure. The code in between the []’s is the closure. The part you see inside, between the ‘[‘ and the ‘|’ is where parameters for the closure go. The part after the ‘|’ is the logic of the closure. The array’s “do:” method iterates over itself, passing each element into the given closure, using the ‘:a’ parameter. The logic inside the closure adds each element to x, which functions as an accumulator. Transcript outputs the result, which is 12. Note that even though the closure is passed to an object, the local variable ‘x’ functions as though the code in the closure was running in the local scope.

To show the power of Smalltalk, I can shorten this into one line by using another method of the array class:

Transcript show: (#(5 4 3) inject: 0 into: [:a :c | a + c]).

Before I go further I should explain that it’s possible to combine messages for a single method. The above code is an example of this. There is an inherited method available to the array class, called inject:into:. It’s two messages for one method, each message carrying a parameter It’s a method that takes two parameters.

What this does is “inject” 0 into the ‘:a’ parameter when the closure is executed the first time by the array. Thereafter the ‘:a’ parameter functions as a persistent variable inside the closure. The method iterates over the array, passing each element into the closure. The ‘:c’ parameter receives each element of the array. The logic is subtle. Each time the closure is called, what happens in effect is: a := a + c, and the end result of ‘a’ is the result of the method call. This gets passed into Transcript, which outputs the result.

Seaside – the Squeak Enterprise Aubergines Server and IDE

What made me pay more attention to Squeak is a web framework written for it called Seaside. One of the goals of Seaside was to make web programming simple. Avi Bryant, one of the creators of Seaside, has said that he tried to make it as simple as programming a thick client application. To do that, he used continuations. Seaside saves the stack state of the web application for each client session between round trips to the server, automatically. There is no session state to deal with! Secondly, you can have it detect backtracks by the user. An example Avi has used is an airline reservation system, where the user may want to try out a bunch of different itineraries. After going part way through Itinerary A, the user may backtrack either part way or all the way to the beginning of the reservation process, using the Back button on the browser, and pursue alternate itineraries. In the end, the user may want to go back to Itinerary A, and then want to check out. With some web application systems, if the reservation system is written badly, it might try to bill the customer for the last itinerary they tried, like Itinerary C.

The developer can configure Seaside to detect these backtracks, and respond accordingly, so that the customer is always getting what they would expect from the application. Further, there are some powerful packages written for Seaside. There’s Mewa, and Magritte, two meta-language packages. There’s also Scriptaculous, an increasingly popular AJAX package that’s being ported to multiple languages. Meta-languages allow the developer to define forms and reports without getting into the nitty-gritty of HTML markup, and you can use them to automate form validation. Seaside has good support for AJAX. You can put asynchronous controls in your application without writing a line of Javascript.

Web developers will notice that something is missing from Seaside: support for page templates. Other web frameworks allow a developer to mix special tags in with a static HTML page, which gets processed by the framework on the server side and is converted into standard HTML when it’s sent to the client. All dynamic pages must be written in Smalltalk. It’s possible to inject Javascript and CSS into a dynamic page, using Seaside’s functions, but it can’t be laid out by a designer onto a template page. They must be set up as strings within your Smalltalk code, as part of the whole Seaside application. Of course, static pages can be set up as such without the need to use the Seaside framework.

This was disconcerting to me at first. As I read about packages like Mewa and Magritte, though, I realized that they do the job that I used to do in page templates. Where this way of doing things could conflict with project operations is if you normally have a page designer set up this sort of stuff.

Edit: I had just barely gotten this posted when Ramon Leon of On Smalltalk pointed out that I was not entirely clear in explaining myself! It is possible to do CSS programatically in Seaside, as he explains here.

Development Tools

Edit 10/12/06:

Forgot to mention, you can use Squeak’s class browser and debugger to write your Seaside code.

Seaside is written in the spirit of Squeak. It implements “halos” like the Squeak UI does. You can turn them on inside your web browser while running your Seaside project, and do some manipulations of things onscreen. You can take a visual element in the browser window and have it bring up a web version of the Squeak class browser in another instance of your web browser, so that you can examine and change the code, without having to stop the application. Class browser, web browser… I know! The terms can get confusing! Smalltalk had the term “browser” first. It wasn’t meant to confuse people. The point is you don’t have to have access to the Squeak GUI to make minor changes to the application.

From what I understand these development features can be turned off when you deploy your app.

Logistical considerations

Hosting: Hardly any ISPs offer hosting for Seaside. I found one solitary Seaside host on the web at http://www.seasidehosting.st/. To boot they do not host commercial sites, or databases. So if you’re wanting to set up a business app., or one that requires quick lookup of lots of data, your only option may be to either work with a hosting company that’s flexible, that will allow you administrative latitude, since they probably don’t know about Seaside, or host the site yourself.

What about using a database? Squeak can interface with external resources, and this goes for databases as well. There are MySQL and PostgreSQL drivers that run in Squeak and interface with those database systems. There are several drivers for object oriented database systems, though the databases run outside of Squeak. There’s even an object-oriented database written entirely in Smalltalk, called MinneStore, so you can run it inside of Squeak.

(Update 9/23/08: Ramon Leon has written his own persistence framework in Squeak called SandstoneDB. He wrote it as a way of advancing the state of the art in web site development. He found some things about object databases wanting.)

How does a web server interface with Seaside? I’ll put up a separate post about this later. After doing some searching on the web I found one guy who was trying to get IIS to work with it. I think he managed to do it.

There are some hurdles to overcome, but from what I hear, the rewards are worth it. I’ve only read about it at this point.

Made here, used in Europe

This is going to sound like trivia, but it was striking to me. Squeak was written in the U.S., perhaps with contributions from abroad, and Seaside was written by a Canadian (apparently–Avi’s site is in Canada). Just about everyone I’ve seen who’s using these technologies are European, though I have found some American Squeak/Smalltalk bloggers. Most of the major sites are hosted in Europe (I’ll explain more about them below):

Squeak.org, the official site for Squeak, is hosted in Germany

Squeakland.org, an educational site for Squeak, is hosted in Germany

Seaside.st, the official site for Seaside, is hosted in Switzerland

lists.squeakfoundation.org, the Squeak/Seaside mailing lists, are hosted in Germany

smalltalk.org, a Smalltalk evangelism site, is hosted in Canada

The SqueakMap site is hosted in Germany

SeasideHosting.st, the one public hosting service for Seaside, is based in Switzerland

I’m not saying there should be no participation in Europe. I just think it’s striking that there doesn’t seem to be that much use of this technology in the U.S.

In contrast, all the major Ruby on Rails sites are U.S.-based.

Flies in the ointment

I can’t give you an honest assessment of Squeak and Seaside without also talking about its weaknesses.

A glaring weakness, IMO, is how disorganized the Squeak/Seaside community is, in terms of web presence. There are a few Squeak/Smalltalk/Seaside “central” sites that seem to be the “places to go” to start finding out about it, but they’ve got broken links all over the place. Just the other day I checked THE central site for Squeak, http://www.squeak.org, and it was down. The main Squeak sites were down just a week ago, before they were brought back up again.

There are also Squeak developers and users who are up in arms over how its continued development is being handled. I talked to the author of a book on Squeak’s architecture and multimedia features recently, and he said he had given up on it. Apparently the multimedia features have been getting broken by the modifications the Squeak development team has been making to it. He recommended if people are going to use EToys or Squeak’s other multimedia features that they get Squeak Version 3.2 and stick with that. That’s the last version where all of these features worked.

Seaside apparently works fine with Version 3.8, the latest release marked “stable” as of this writing.

Apparently what the development team is trying to do is modularize Squeak, so that developers can downsize it if there are features they don’t need. I understand the impulse to do this, but I wonder if it was designed the way it is on purpose, and that perhaps something is getting lost by trying to split it up. You know, techies complain about how everything is integrated in Microsoft Windows, and they wish it was more modular, but integration creates certain advantages and disadvantages. People should do a cost/benefit analysis on it before dismissing this model. It may have been better to start from scratch than to try to make Squeak something it’s not.

Resources

The Squeak system itself has pretty good documentary support. There were a few books written on Squeak specifically several years ago. You can find them at Amazon.com. There’s only one that’s been written recently, targeted at programming for children, called “Squeak: Learn Programming With Robots”. It’s not about using Squeak to program real robots, just virtual, graphical “robots” inside the Squeak environment. It’s more akin to turtle graphics in the Logo language. In addition, there are several free online books on the Smalltalk language.

I was kind of amazed to find this, but apparently there’s a Squeak-.Net Bridge package you can get.

Some words of advice:

Don’t get discouraged by broken external links. You’re going to run into a lot of them on Squeak-related sites. Even if they appear broken now, they may come back to life later. The same goes for the links on this blog post (though I can’t vouche for the links on the pages I refer to). Last I checked, all of my links worked.

Some features you may see demonstrated in the videos may no longer exist. One screencast on Google Video featured page templates in Seaside. Yes, they once existed, but they were taken out later.

Sometimes the main Squeak sites, like squeak.org, go down. It’s been happening some lately. If they are down, don’t worry. They will be back up again eventually.

Online resources for Squeak and Seaside, in no particular order:

Squeak.org – This is the official Squeak site. You can read a little about it here, and download official releases.

Squeakland.org – This is the educational site for Squeak. There are some online Squeak demos you can try out. You’ll need to install an ActiveX control, or perhaps a plug-in for your browser, since they run inside of a web page. I haven’t found this add-on yet, but I hear it’s available for download on this site.

Seaside – This is the official Seaside site. If you click on the “Download” navigation link there, you’ll get access to Squeak image files that have everything you need to get started with Seaside (so you don’t have to put together the needed components yourself), plus a little instruction on how to get the Comanche web server (a component called WAKom, written in Smalltalk) started.

Learning Seaside – A blog written by Ian Prince on his experiences in learning Seaside, among other things.

The terse guide to Squeak – This is similar to Quick Reference for Squeak, except it’s an HTML page. It briefly documents the standard Smalltalk types and how to use them.

The Seaside mailing list – Hang out where the knowledgeable people are. Discuss/ask questions about Seaside. You’ll need to subscribe first. Posted messages are sent to your e-mail address.

The Squeak Beginners mailing list – New to Squeak? Ask your questions here. It was pointed out by gcorriga of The Weekly Squeak that you can subscribe to this list and receive messages posted by others in your e-mail, or you can just e-mail your questions to the list, without subscribing, but your messages will be run through a moderator (to get their approval) before they are posted for everyone else to see.

Smalltalk.org: the learning page – This is an evangelism site. It talks about all things Smalltalk. I’m directing you to the learning page here. It has a bunch of links to some good resources. Check out some of the navigation links to other parts of the site. I found the “Articles” page particularly interesting.

SqueakMap – Once you get familiar with the Squeak environment, check out this site. It’s a comprehensive database of Squeak packages and projects. Some of them are the ones I’ve mentioned in this article. Apparently SqueakMap is similar to the Gems utility/service in Ruby. I’ve used the site, but you’re supposed to be able to use it inside of Squeak as well, to easily download and install packages, and updates to ones you already have.

Other Smalltalk Implementations

One last note. Just today I found Cincom Smalltalk. It’s a commercial development environment, but they have a free developer’s license. Like Squeak, it’s cross-platform compatible. It works on Windows, Mac OS, Unix, etc. It has .Net, COM, and C integration packages. You can use it to develop GUI and web applications, and web services. Pretty neat! You may see sites or people refer to VisualWorks. They were bought by Cincom, and the VisualWorks product has been integrated into Cincom Smalltalk.

There are many other Smalltalk implementations out there, amazingly enough. It seems to be a relatively small community. I think there are about 8 different implementations.