13 December, 2007

Now, what about that smalltalk?

How to walk the (small)talk

Trying to learn programming isn't one of the easiest pursuits in the world, especially to me. In fact, I'm finding about the only real language as such that I have any proficiency in is the bash scripting language. Wonderful, that. In comparison to big brothers such as perl, ruby, or even tcl, bash doesn't have a whole lot to offer except the ability to string things together using pipes, and call external programs. It at least has arrays which is something, I suppose; I've made use of arrays in some of the bash scripts I've tailored for myself, as well as something called Indirect references (in essence, pointers, but in bash instead of C). That made my life a whole lot easier writing the programs I have, as I could simply wrap something in a mildly complicated forloop instead of hammering it all out into a temp file, then slurping in that temp file as part of the execution of the script. It's best ... avoided.

But this isn't really why I'm here. After all, I talk about smalltalk. A lot. It hasn't overtaken my life yet, though I'll bet that plenty of 'talkers could say that it has for them—it being a just-about-complete development environment in addition to being an environment for running applications. Yes, in comparison to the big IDEs (namely Visual Studio, KDevelop, Eclipse, NetBeans) the smalltalk development environment can be seen as primitive, but then so is a text editor and gcc+make, which is my normal fare. And nobody would argue that at least they get the job done. I'm sure you're mostly aware of the typical development cycle of "create, compile, test, break, fix, compile, test...", and the attempts of the big IDEs to put that all in one place; some more successfully than others.

One look for me, another look for you

In comparison to the "one window to do everything" approach of some IDEs, it seems that the smalltalk environment has one place to enter code (either of the System Browser or Debugger), a place to execute code (the Workspace), a place to view variables while the program is running (Inspector/Explorer) and yet another place to view output (the Transcript, or simply World). Sounds as inefficient as heck, and yet there's a certain sparse beauty to it. In the end, it does make sense to have various functions separated from each other. After all, you don't typically use your email client to do your budget, nor do you attempt to use your spreadsheet to send an email - there's separation of function. Otherwise we'd never get any work done.

However, in the smalltalk world, there's less separation than what I've mentioned here, as you can literally view every program's code in a smalltalk environment, all at once. If you want, you can even lock down aspects of the environment so that it acts more like a single application, rather than an environment to run a whole lot of applications. However, the normal use of smalltalk is to have everything turned on; that way you can fix something then and there if it breaks, and you happen to know how to fix it. To extend the metaphor a bit, it's a bit like having Internet Explorer being the front end to the entire source code of Microsoft Office, Windows XP/Vista, Messenger, Media Player, Outlook Express, and even IE itself. Of course this will never happen in the Microsoft world, but you get my point.

What? There are locks here?

To provide an example of locking down the Squeak environment to make it act like a single application instead, I mention a commercial offering built in Squeak: Plopp. Yes, this funny sounding name is actually an application built in squeak. And no, it's not explorable in quite the same way as a normal Smalltalk environment - it's been built to be an application, after all, and the company doesn't want just anyone browsing their crown jewels. So what's been stripped out? Most of the stuff that make Squeak what it is: an excellent development environment. The browsers have (presumably, at least) all been removed, as has the debugger, Inspector, and anything else normally associated with development. What's been left in? Great graphics (they're 3D!), and sound support, all based upon the Croquet 3D version of Squeak, an immersive world where you can spend time making drawings in 3d. The program is aimed at children, so it just has to be simple to use, that's why everything else that would get in the way of children enjoying themselves has been removed.

Je ne parlez petit parlez-pas

I came up against a small conundrum the other day. I wanted to run some code and view some variables while the code was running, but I didn't want to wreck a working codebase, which is what I had. I merely wanted to tweak, play, as it were. I couldn't find a way of doing that, without cloning the whole image and playing in that instead, with the ability of exiting without saving. It's the Smalltalk way, though I've got to still get used to that. I also couldn't start a program THEN invoke the debugger on the program, because I still don't know how to do that. The Debugger window is about the closest to what I want, yet I'm still hamstrung by what I mentioned at the beginning of this post - my lack of proficiency. And that's not just proficiency with smalltalk, or else I'd just get over it, and do the hard yards.

Instead, it's the lack of knowledge about programming in general - what works, what doesn't, how to do really really common stuff that professional programmers take for granted. Stuff like lists, sorting, filereading, and output to screen being some examples. I don't know how to do most of that in any language I know.

A useful idea I came across quite a few years ago in a related subject is the "Whole language" method of learning - in effect, chucking the subject in the deep end, and making their brain find connections for itself without the crutch of a translator to ease the process and hold back the progress. To address my attempt to learn programming, this is what I'd like to try for six months or so.

I'd like to simply boot into a Smalltalk environment, use it to run smalltalk applications, debug code, save files and so on, then get back to booting to my regular Linux. I can't quite do that with Visual Studio, although some people would say that emacs comes the closest to that under Unix-like platforms. However, there's a problem with trying to do that with Smalltalk at the moment. At this stage, I can't boot into a Smalltalk without additionally having to boot an operating system underneath to supply what the smalltalk environment doesn't. And normally, that's quite a bit.

The closest that Squeak comes (and it's not working well enough yet to be a viable alternative) is an alternative called SqueakNOS (No Operating System). In essence, what they've added to Squeak acts like the rest of the normal operating system, providing services such as reading from disk, writing to input and output ports for controlling items, and generally doing all the things we'd expect the normal operating system kernel to do. It hasn't quite got there yet, as all this code has to run through the VM, which itself sits on top of its ... yeah, well let's say it's messy. The critical thing, at least for me at the moment, is this: SqueakNOS can't write itself back to disk yet. The other point seems to be that nobody's really that interested in it at the moment, so it's not being maintained. The latest example I can get my hands on was released over three years ago, and is showing its age, compared to modern Squeak environments.

So for the moment at least, I'll just have to go with the "run Smalltalk as an application on top of the OS" and be aware that things aren't quite all there yet. Besides which, I can gain the benefit then of running multiple Smalltalk VMs side by side, and study how they differ in their implementations. Fun ones to compare for me have been Cincom VisualWorks (now up to version 8) and Smalltalk/X (now up to version 5.3.4, at least for the Windows platform), as they both present similar interfaces to the user, both of them using the underlying windowing system of the operating system to manage windows; I mentioned this in a previous post.

I believe that other Smalltalk environments (VisualAge being an example) also present themselves in a similar manner; I actually downloaded Dolphin Smalltalk to compare that. Given that it only runs under Windows, it's a somewhat unfair comparison to other smalltalks that run under multiple platforms. I've also avoided downloading anything that costs, as I can't buy it or justify the price of purchasing. Have you seen the per-seat price for Visual Age recently? Don't expect much change out of $7,500 if you want to use it in any significant capacity.

No cute dummy here - more a powerful force in its own environment

Now, into Dolphin. It's ... well, a rather well written program, and what appears to be a rather well written smalltalk. The class library is huge, even in comparison to other smalltalks I've used, and has most items that the average beginning programmer would want. I've yet to play with Dolphin some more, as I have to keep booting back into Windows to start it up.

Recent events and decisions have meant that the original authors of Dolphin have decided not to continue development on Dolphin, and as they have a serious bias against allowing the project to fall into the open source world, we aren't likely to see it made freeware any time soon unless someone does what happened to Blender (bought for $75,000). Frankly I hope that works, as I'd be VERY interested to see it tweaked even further.

This isn't a small talk, is it?

No it doesn't seem to have remained that. Frankly if I think about it, Smalltalk is chickenfeed in comparison to other languages such as Java, .NET or even C and C++. Yet Smalltalk presumably shaped the way interfaces were made, was possibly the driving force behind true object oriented programming, and hasn't gone away yet, even against the heavyweights mentioned before. It's not easy to learn, yet from learning it, there may be valuable aspects that will apply to other areas of programming. In saying that, there are apparently negative aspects to thinking Small, in that if you think in that manner, you're automatically counting out other ways of working that may actually fit the current problem better than Smalltalk. I don't know if there will be any consensus on that, given that programming can be a bit like trying to herd cats that are on fire. No further guesses from this corner, at least.

No comments: