On Smalltalk

I've hopped around all the different platforms, I definitely prefer stuff with Unix foundations, once you get into shell scripting it's really easy to have a machine customized to your own workflow or personal style very very quickly. In addition to my blogs I have a personal journal on my home machine; each day is its own file, e.g., 031107.txt. I have a Ruby script which creates the filename based on the date and a shell script alias which pipes the output of that script to TextMate, so I can start a new journal file, or re-open an existing one, by typing one character and hitting Return. Once you get hooked on this way of working it's very, very addictive.

Oh I'm already hooked because of the ease of automation. Setting up services is a breeze using daemontools and becomes a simple matter of copying files and a run script into a service directory. Way easier than on Windows.

Cloning a working config to a new server is going to be easy in comparison to Windows Server 2k3. Linux has QWAN, like Smalltalk, because everything is a file and everything works together in a way Windows servers never have and likely never will.

Emacs is my next adventure, just because I want to find a way to squeeze Lisp into my daily work environment and I'll soon have a few Linux servers that'll need maintaining.

Excellent article - yes it is amazing what just an ordinary user (like myself) was missing out when I was running M$ windows - the world of Linux is fabulous! Thank you Linux for liberating me. I hope many follow your steps!

I was also one of the "both-platforms" group. But what caused me to switch completely was the day our intranet became almost unworkable because of worms, virus, and nigerian email scams.

It was also a realization that you cannot depend on one single platform, one company to deliver all.

I. PS. A comment to the comment by Ramon: Emacs rules :)

My knee froze in mid-jerk: I was looking for more "why programming sucks" rants so I could post a link to my making fun of them, and almost pounced when I found "Visual Basic" on this page... and it's somebody who Gets It! Someone who actually got claustrophobic in VB and wanted out! Standing down...

Congratulations on losing your cherry. And now you want to dive into Emacs and Lisp... of which I can say: (a) Learn Emacs a piece at a time, and keep a 'cheat sheet' of key-commands on a piece of paper somewhere. (b) Lisp is so different from every other programming language, you literally have to free your mind from all previous ideas about programming and be a blank slate. Uncarved block and all that. I recommend 'The Tao of Pooh' for leisure reading during your Lisp phase.

But really, it's OK to slow down. You just learned to drive this week, and now you want to race the Indy 500.

LOL, I lost my language cherry a long time ago, I'm just recounting the story now. It's only Linux that I've recently come to appreciate. As for Lisp, it's no great mystery to me, though Emacs is. I just figure it's about time to add it to the tool box because it'll give me more reason to actually use Lisp daily.

emacs????? Go with VI - it's designed so you don't have to move your hands from the homerow.

And remember you don't want to be a WIMP - Windows Icons Menus Panels...

Great post, I enjoyed reading it. One alternative to Cygwin you might want to check out if you haven't already is Cooperative Linux (http://www.colinux.org/). I ditched Cygwin for colinux since the latter gives me most all of the functionality I was getting from Cygwin and I can use Debian/Ubuntu and apt-get, and not have to learn all of Cygwin's quirks (I administer several Debian systems at work). I recommend it...

Hey, if you want to learn Lisp you'll want the classic "Wizard book" text: http://mitpress.mit.edu/sicp/ It can be read on-line but you'll want a copy if you really decide to use it.

Don't forget to write yourself comments in your Linux configuration files so you can tell 2 years from now why you did something.

@Darren, no go with vi, since the using Lisp is the reason I want to use emacs in the first place.

@George I'll check out colinux, looks cool.

@Karl, you'll note the wizard book is already in my book list, but thanks for the recommendation.

I'm a longtime vim user that's learning emacs for lisp and all the other goodies it has, but I refuse to give up the vim keyboard commands (I can feel all those c- sequences in my wrists after a very short time). I'm finding viper-mode to be pretty good so far. I get enough of the familiar vim commands to be functional right away.

Ramon-

I kind of did the reverse of what you're doing, though I'm finding my way back. Years ago I started out on DOS, hated it, then moved to Unix. Unix is what I was trained on in college. I stayed in the Unix world for a few years, and got tired of that. I actually moved from there to Windows. This was mainly because of the work I was doing. I always like efficiency of operation. I was involved in software projects that used databases. I did a lot of C/R/U/D work. I was using command line tools all the time, though I was using vi and uEmacs (think of it as Emacs-lite), and I was programming in C and Embedded SQL. Any time I wanted to produce a build I had to write a shell/awk script, and create make files. Anytime I wanted to distribute something I had to use a script to create a tar file and generate a manifest for it. My development work felt harder than it should be. I was using dbx as a line debugger. Not what I'd call fun.

When I moved over to Windows things felt a lot easier. I could do the same sort of work (write C/C++ apps. for databases) much more efficiently, and I got to get into something I really liked--user interactivity. Connecting to and using databases was more efficient. Creating build environments was a snap. No more messing with scripts and make files. Debugging was much easier. Then I discovered .Net, and I said, "To heck with C++. This is the bomb!" I got into ASP.Net and realized what a hairball you can get yourself into with that using Microsoft's tools. It seemed good for a while, but once the app. got complicated the tools were no help at all.

Then by chance I rediscovered the works of Dr. Edsgar Dijkstra, discovered Paul Graham and was inspired by his story of ViaWeb, I dabbled in RoR for a bit, and later through Google Video, I discovered what Alan Kay has been up to all these years. I rediscovered Smalltalk (Squeak), and it was more than I ever expected. When I learned Smalltalk in college we used GNU Smalltalk which was just a command line compiler and a runtime interpreter. When I saw eToys I was blown away. I fell in love. Out of curiousity I searched for a web framework for Squeak and was delighted to find Seaside.

I've recently been considering upgrading my laptop and for the first time in years I had the thought that maybe I should consider a non-Windows computer. I'm not there yet, but thinking about it. Reading your post here has made me think on this again.

@Mark, interesting story. The windows GUI is nice, and does "seem" easier when doing lot's of things, but what makes it suck is that you can't really automate a window in Windows. The tasks never get any easier, you can't build the OS up to suit you like you can in Linux.

There's also the matter of configuration, in windows every program does it differently. I'll continue to use windows for my desktop, but for servers, it's Linux all the way. I'll take configuration files in /etc over some custom UI and the windows registry any day. .Net apps are moving to xml .config files in the apps directory, which seems like even Microsoft is starting to grok the power of plain text.

Interestingly, Mac users may have the best of both worlds, a real Unix with a slick GUI.

In the end, one OS is built for users by marketers, the other is built for programmers by programmers. Linux isn't as pretty as Windows, probably never will be, but pretty isn't what I care about anymore. Linux is logical, it makes sense, it's organized better than Windows and really setup for multiple users. Windows on the other hand, feels like most things were put in as an afterthought, it's not as logical.

There's an old saying "Unix makes the easy things hard and the hard things possible."

Most of the Cygwin tools lists above have native win32 ports under the GnuWin32 project. http://gnuwin32.sourceforge.net/packages.html

MS has also released "Windows Services for UNIX" http://www.microsoft.com/technet/interopmigration/unix/sfu/default.mspx

I've never tried Smalltalk, but Python has win32 builds that I am using.

I like to always say "develop and test on Windows, deploy on Linux." It's the path of least resistance for the desktop IMHO.

@Ramon:

I think OSS has come a long way from when I was first using it in the 1990s. I used to use GNU tools quite a bit on Unix. I'd use BASH, GCC, Flex, Bison, etc. There were other GNU tools at the time that I didn't get into, like Ghostscript for dealing with Postscript. It was neat stuff up to a point. It looks primitive by today's standards, even in OSS. Now with RoR and Squeak, plus MySQL and PostgreSQL it takes things up to a whole new level. You can get stuff done in a reasonable amount of time and have the tools you need, but most of all you get the power of these environments.

What I've realized recently is that .Net has its pluses and minuses. On the plus side I think it's been a good environment for desktop apps. I haven't been so impressed with it for web apps. Like I was saying, at first it seemed easy. It was only later that I realized the reason it seemed easy was due to the toolset I was using. Once you get beyond its capabilities you can keep going with .Net, but you're on your own. And that's when it got hard. I realized that a lot of professional .Net developers compensated for the weak toolset by buying third-party code generators. They'd essentially get to what you get with RoR or Squeak, but use XML for it. I've heard that Java developers have done the same.

RoR and Squeak helped me realize it doesn't have to be this way. If you program in a strong language, you don't have to depend on the toolset so much to accomplish what you want.

It's not an OSS vs. closed source thing with me. If Microsoft offered the same power in the language as what I've been using, I would've still been excited about Squeak and stuff, but I would've basically stuck with .Net.

It seems like .Net and Java are moving in the direction of these languages, and I'll keep an eye on them, but I'm not patient enough to see what I've seen, just settle, and wait for them to catch up.

.Net can't catch up, ever. You can't survive in the .Net world without buying lots of third party components, and facing barrier after barrier whenever you try anything cool.

They'd have to open the class libraries to extentions (C# 3.0 will allow this).

Add support for continuations (not going to happen).

Make the VM support dyanmic languages much better than it does now (implementers have to jump through many hoops to write a dynamic language on a VM meant for a static one).

Lose the page templates, they really are a hindrance to good development. This means changing the mindset that thinks templates are a good idea... ouch...

Dump the XML mini language voodoo that is currently so trendy, and used to fake things that are done naturally in a dynamic language.

Lose the viewstate model and abandon the push for so much statelessness that makes the current model so difficult to work with. Request/Response must be abstracted away, this isn't optional.

Oh, and after fixing all that, give the new product away, with source code, for free. Yea, I can see it happening now... lol.

At this point in time, when it comes to web apps, I just don't see anything touching the tool set that is (Squeak, Seaside, Magritte, Glorp | Ruby on Rails), PostgreSQL, Apache, and HAProxy running on Linux. OSS is just the best solution right now, and for the foreseeable future.

The simple truth is, .Net and Java are mainstream languages, and by definition, anything mainstream is already outdated by the stuff on the bleeding edge. Seaside is the raw bloody edge, Rails is half way mainstream and still using older more accepted techniques.

Seaside may be the wrong direction, I don't think so, but it's a possibility, but at least it's new and different. Seaside's like crack, after using it, I just can't touch anything else without thinking how painful it is not using Seaside, even Rails.

People want to complain about scalability and speed and how using sessions and dynamic languages doesn't scale or is too slow, but I can pull 25 pages a second with a 100 concurrent user load with each user hitting a page every 3 to 9 seconds on a 3ghz hyper-threaded 1 gig ram workstation running at about 85% load. That's not blazing fast, but that's more than fast enough for me, and a couple of real servers could easily out do my little workstation.

Linux of course, is the perfect OS regardless of the framework you choose. After 3 solid days of experimenting with it to host Seaside, I'm convinced of one thing, Windows blows and Debian fucking rocks.

Hmm. Tried posting this before, but it timed out. Trying again...

Ramon-

Re: continuations

When I was thinking of Seaside I forgot about that, but yeah, that definitely is cool! One of the things I really didn't like but learned to live with in ASP.Net was storing values I needed persisted in session state. Somehow that always rubbed me the wrong way. I thought the way that state was just a given in desktop apps. (caveat with multithreading) was...well...a given. A darn good idea. I thought, "Why the hell are they breaking this??" I think the way they did it was better than some other solutions that were out there (they made it simple), but again when the app. starts getting complicated, you can easily overwrite session state you didn't mean to, by accident.

Re: Scaling

This is kind of going back to your previous post on scaling Seaside (hope you don't mind), but in your experience is there a rationale for the approach that the mainstream web frameworks have taken of making it possible to switch servers midstream through an application's run for a particular client session? Is there a disadvantage to using sticky sessions? It seems to me there wouldn't be, so long as any CPU-intensive work could be distributed to non-web-serving machines, thereby getting rid of some unpredictable spikes in activity.

ASP.net rubs me the wrong way constantly. I'm used to it.

Anyway, state is a fact of life, you either automate it, or do it by hand. Most frameworks have chosen to do it by hand via manually built URL. Whether the URLs are pretty or not isn't even relevant, it's that they're manually built. I also don't think they really chose to do this so much as this was the first solution invented, and it's just been accepted as the way to do things and not really re-examined.

Most web frameworks do provide sessions, but they're only used lightly, for data that programmers put in them. Given this, it's easy to want to farm that out to a database or an in memory server like memcached so you can run stateless and any request can hit any server. But the real question is why.

Back in the day, load balancing was done via round robin dns, so this made sense. But it doesn't really make a site more scalable, only more fault tolerant. 5000 users randomly spread over 10 servers persistently is just as scalable as the same 5000 users requests randomly spread over the same 10 servers for the most part. Few web apps are cpu intensive anyway, mostly they're just shells over a database, so spikes aren't really the issue people think they are.

So it's not about scalability, it's about fault tolerance in case of a server crash and it's about tradition; it's just how things have always been done. Yes, stateless apps can not skip a beat and just pop onto another server. Stateful apps like Seaside will force all those users to lose their sessions and start over on another server. That is a downside for Seaside.

But there are trade-offs you make by going stateless. You lose some speed because the state must be moved out of process and reloaded on each hit, and "what" can be put into state becomes limited to things that are serializable. This makes state only a data store. Seaside uses state to store much more than just simple data.

A session in Seaside isn't just a data store, it's more like an instance of the application running on the server for that user. That instance stores live objects, not just data, but UI objects, controls, widgets, continuations, callbacks, etc. There are many objects in an application that aren't persistable.

In essence, Seaside isn't really a web application, it's a client server application where the client is actually running on the server and the view rendering is simply carried out via http. The things Seaside puts into the Session aren't so easily serializable.

This gives Seaside a strong focus on building "applications" and not just websites. Seaside is far more suited for business applications than other frameworks, but it's not very well suited to building websites, especially mostly static ones. Seaside trades a little fault tolerance for the ability to do things that can't be done otherwise. The reality is, having a user lose a session on the rare occasion of a server crash, just isn't the big scary monster people make it out to be. Keeping state in process so greatly simplifies things, and gives you abilities so far above and beyond those offered by statelessness, that it's not something to give up lightly. Rather, you need to have both options available. Sometimes you want a stateful framework, sometimes you want a stateless framework.

I think Rails and Seaside are actually a pretty good pair. Rails for web sites and simple web apps and Seaside for really complex web apps. In a sense, you could do most work in Rails, which is more traditional and stateless, and hand off to Seaside for only the most fancy parts where the complexity makes Seaside a better solution. They could be used together in one app seamlessly.

Considering how easily Rails can expose its data model via restful URLs as XML, and considering that Seaside is really only a view layer anyway, I'd bet it wouldn't be that difficult to use Seaside on top of Rails while still using Rails for the bulk of the database stuff.

It's something I'm going to be looking at for sure because there's a great deal of awesome stuff that's already been done in Rails and finding a way to inter-operate with it could greatly help the Seaside community. No need to reinvent the wheel if we can find a way to use Seaside as the view layer.

Re: Seaside on top of RoR

Hmm! Yeah. That would be interesting! It would certainly help with people wondering what they should use. They could start simple with RoR and work their way up to Seaside, if that feels more comfortable. It could be a part of the whole "RoR is the gateway drug to Seaside" thing. :)

I'm sure other programmers will relate, but for the rest of us, we're left behind.

I use both Linux and Windows, and I count my blessings every day I use Windows. I like Linux, too, don't get me wrong. But for GUI tasks, Windows just seems to work better. Linux will get there someday but it's not there yet.

This article was written by a programmer. I can see where a programmer would prefer Linux or even Mac OS to Windows. But Windows isn't aimed at programmers, it's aimed at users. Since I'm more of a user than a programmer, it's mainly why I use it.

Linux has its plusses, though, but it seems like it's newer to the GUI stuff than Windows.

Linux Companies.

http://lxer.com/module/forums/t/23168/

The linux route is definately an interesting one. I was a Windows user for years, and I have come to love many things about my Linux box and it is definately a good change for me. The one thing I could never miss enough from XP though is the ability to never use the mouse, even in a windowed-environment. Masochist? Maybe. Fun? Definately.

Hi Ramon,

It is interesting to see the process that how you learn to use the Unix tools before adopting a pure Unix-like system. I remembered 14 years ago when I was in a group in Taiwan trying to promoting Unix-like systems for scientific researchers, we had a discussion about Richard M. Stallman's approach in creating GNU operating system. The conclusion we reached is that Unix system tools is the spirit of Unix system and not the kernel, the kernel is just a program to facilitate simplified programming for those tools and RMS is very smart to work on those tools first in GNU and expanded steadily though slowing the user bases by encouraging adopting of those tools in DOS, OS/2, Classic Mac OS and Windows. RMS put the priority of GNU kernel at lowest and in fact using Linux as the temporary kernel at the moment. I am just happy to find the processing you experienced is what we thought long time ago.

I agree completely, it was the tools that got me hooked. I find myself more and more in the command line for admin purposes and debugging purposes. Logs have become much more useful with grep/sed/sort/uniq.

Unix rocks

Adi Azar

The tasks never get any easier, you can't build the OS up to suit you like you can in Linux.

I ditched Cygwin for colinux since the latter gives me most all of the functionality I was getting from Cygwin and I can use Debian/Ubuntu and apt-get.

Hmm. For the designer - Windows. For the programmer - Linux, it is claer. :)

"Hmm. For the designer - Windows. For the programmer - Linux, it is claer. :)"

For the designer, definitely MacosX. For the programmer - definitely MacosX, it is clear. MacosX has the best of both worlds: a beautiful GUI (no bland colors and ugly jagged fonts thanks to Display Postcript), rock-solid memory (BSD), great developer tools, no drive name restrictions (C:, D:, etc.) and plug-and-play. It also runs many Unix applications via the X11 application. Last but not least, the hardware is beautiful.

great article! Windows is definitely aimed at users