Since I’m only averaging about 500 hits per day, shared hosting should theoretically be sufficient for my purposes. Alas, Mephisto continually dies on Dreamhost, and since I couldn’t get my kludgery to work (mostly because I can’t seem to install the mysql gem on my local setup), I gave up completely and found a host that actually supports Rails.

Migrating was not exactly pain free, but hopefully my domain name will propagate completely by tomorrow or the next day. I’m not sure why Mephisto started failing to run on Dreamhost. My logs were not at all helpful.

Whatever. Hopefully, I’ll get a decent job starting this summer, and the webhosting fees will stop feeling so significant. Either that, or I’ve got to start using Adsense. And maybe I’ll end up migrating all my sites away from Dreamhost at this rate.

So I can’t seem to log-in to my blog currently. What I ended up doing was trying something that may have untoward side-effects. (Which reminds me, I should probably backup my database.)

What my local setup is: Mac Mini 1.25 GHz PPC (G4) with 1 GB RAM running Mac OS X 10.4 (Tiger). I’m using the pre-installed version of Ruby (1.8.2) I then installed Mongrel (1.1.3)

1. Checkout a fresh new copy of mephisto trunk (currently revision 3091 at this writing) to my hard drive:

   svn co http://svn.techno-weenie.net/projects/mephisto/trunk mephisto

2. Freeze Rails to current release (2.0.2 at this writing)

   rake rails:freeze:edge TAG=rel_2-0-2

3. Edit database.yml so that it matches my blog database on Dreamhost.

4. Start mongrel:

   mongrel_rails start -d -e production -B

5. Login at http://localhost:3000/admin

6. Blog away.

7. Cross my fingers that it doesn’t nuke my database, and that Mephisto is actually working on the remote side.

From Zed Shaw’s rant as to why the Ruby on Rails community sucks:

This is exactly what makes Rails a ghetto. A bunch of half-trained former PHP morons who never bother to sit down and really learn the computer science they were too good to study in college.

With Rails I get scrawny cock suckers with carpal tunnel syndrome talking to me like they’re gonna eat my young. Their feeble PHP infected minds can’t grasp advanced shit like objects or closures. When you combine stupid businesses with stupid people using a stupid framework based on a big fat fucking lie on a shitty platform you get the perfect storm of dumbfuck.

More quotes collated on [Tech Crunch][2]

[2]: http://www.techcrunch.com/2008/01/01/zed-shaw-puts-the-smack-down-on-the-rails-community/ “Zed Shaw Puts the Smack Down on the Rails Community

Steve Yegge’s rants about programming are always really interesting. I’m all about the big picture, and I like how he can properly abstract his arguments so that it makes sense to a non-specialist. Very few technically competent people (whatever the field) are actually able to do this, and if they could, it would certainly make cross-discipline interaction a lot easier.

His latest diatribe is essentially about the unmaintainability of massive amounts of code that has low semantic expressivity.

Several commenters seem to miss the point completely and start arguing about Lines of Code™ and how all projects are doomed to massiveness, and clearly, these people have never worked with languages such as Perl, Ruby, or Lisp.

But as other commenters have pointed out, what Yegge is actually talking about is the concept-to-code ratio. To put it another way, how many keywords does it take to spell out a particular concept?

This is intimately related to a notion in sociolinguistics that is commonly referred to as context which has a specifically narrow connotation in this field. From the rudimentary linguistics class I took as an undergrad, the most vivid example I remember is the contrast between Mandarin Chinese and English. Mandarin is generally classified as a high-context language (or, perhaps, high-context-dependence) whereas English is a generally classified as a low-context language (low-context-dependence). What this means is that if I were to say something in Mandarin, in theory, I could say it in far fewer words than its English counterpart, mostly because you have all the necessary cultural context to understand what it is I’m trying to say.

But this isn’t the only axis by which semantic expressivity can be judged. While Mandarin can be semantically compact, it is probably on the more difficult end of the spectrum of languages to learn and highly dependent on familiarity with Chinese culture. In contrast, English—which is more semantically expansive—makes for a wonderful lingua franca.

How does this apply to programming languages?

Java is a relatively low-context-dependent language. You have to spell out a lot of things. You have to specify type, class, etc., etc. Sure, it’s far fewer things than you would have to spell out in C, or God help you, x86 assembly, but when you compare it to languages like Perl and Ruby, it’s a lot of stuff. This surely contributes to the code bloat issue.

Java’s low-context-dependence is probably what makes it such a widely used language, though.

Ruby, however, seems to be a high-context-dependent language. I say this mostly because of my exposure to Rails. Code targeted to Rails is compact and semantically dense but you may have no idea how things are being implemented. The details have been abstractified and hidden, and it is well known that you can write a fully-functional Rails app without really knowing much Ruby at all.

But the difference between Ruby and Mandarin Chinese is that I feel that Ruby is far more transparent and easy to understand for the non-native.

A little personal background: I got my first computer—a Commodore 64—when I was 8 years old. I learned how to program in BASIC, 6502 Assembly, and Logo (which, if you strip away the turtle graphics, is apparently highly reminiscent of Lisp.) I got my first x86 machine when I was 13, and learned how to program in Pascal. (When I was in high school, the Advanced Placement Computer Science course was based on Pascal. I never actually took the course but managed to get a 4 out 5 on the AP test.) In college I dabbled a little in C and C++ and in grad school, I learned Perl.

In all that time, I never really wrote a complete app, unless you count the extraordinarily rudimentary patient database system I wrote in Turbo Pascal 5.0 for my dad, or the hacked-together Visual Basic program I set up to help me keep track of medical billing when I used to work for this solo family practitioner. The most complicated thing I ever wrote in Perl is a CGI script that transliterates Roman characters to Alibata.

As you can see, I’m not a professional coder.

But I am an enthusiastic hobbyist linguist. And I’m more than a little intrigued by artificial intelligence. One of the things that I used to try and implement (in BASIC, of all languages!) was a programming language based on natural language. At the time, speech-to-text seemed to be an impossible, highly futuristic idea, but I figured that if they ever figure out how to turn speech into text, they’d still need an engine to parse it into actual commands. (These were the ideas I woudl get whenever I would hear Jean Luc Picard ask the ship’s computer to do something.)

In retrospect, this was probably a little too over the head of the average 10 year old, and at the time, I definitely couldn’t figure out how to get from here to there.

What I discovered, instead, were text adventure games.

The prototype for this genre is Colossal Cave Adventure, or more commonly, just Adventure. In modern parlance, they are sometimes known as interactive fiction. The variant/descendant that I was first exposed to was Zork. This was my first encounter with Infocom and their pioneering text parsing engine.

For the longest time, I had sought to implement my own text parsing engine, but to no avail. Interestingly, of all the languages that I had access to at the time, it seemed most intuitive to implement a text parsing engine in Logo.

But back to the modern-era of computer programming.

One can look at the divide between C/C++/Java/C# and Perl/Python/Ruby/Javascript as merely a generational-gap. The old school programmers tend to use the former. The newbies use the latter.

But I think there is another distinction to be made: the former group of languages tend to be compiled down into machine code or byte code fairly straightforwardly. The higher-level concepts, procedures, functions, objects, etc. are all representations of actual low-level entities. What the former group of languages allows one to do is control the machine with almost as much precision as one could with writing in straight-up machine language. The higher level language exists mostly so that a coder can actually read what’s going on, and so that they don’t have to look at the minutiae involved with saving registers and stacks and what-not every time they call a procedure.

The syntax and the implementation are tightly coupled—simple high-level concepts get translatetd to simple machine code and complex high-level concepts get translated to complex machine code—and sometimes this means that making the code easy-to-read and easy-to-maintain is diametrically opposed to keeping performance bearable and keeping memory usage sane.

The latter group of languages all started out as scripting languages, and it used to be that the main purpose of a scripting language was to automate various higher level tasks. I would hazard to guess that Larry Wall didn’t really intend people to build huge, monstrous piles of code to completely power multimillion dollar enterprises almost entirely in Perl, but what’s done is done, and here we are.

Part of the rationale for something like Perl is to make the invocation of certain tasks easier, in the sense that you can use somewhat more natural language to make a computer do something. Hence, Perl’s mantra of TMTOWTDI—There’s more than one way to do it. The syntax of the command may have no bearing whatsoever on how the actual task is implemented. A single line of Perl can get expanded into a humongous pile of complicated machine code, but the average coder need not know anything about the underying complexity. They can just get stuff done. In the era of 640K of RAM and 80 MB hard drives, this was not all that tenable. Coders needed to count every single byte and every single processor cycle.

But now we have machines that have gigabytes of RAM and terabytes of hard drive space, so this type of obsessive-compulsive fastidiousness is not as necessary. We can let the computer do even more of the grunt-work.

So the most intriguing part of modern languages like Ruby is the idea of self-reflection. This really gets the AI otaku in me excited. One way to look at it less sensationally, though, is to think of self-reflection as a way to make invoking certain tasks more like asking for things in natural language.

Rails is the perhaps the prototype in this regard. While MVC paradigms have existed for a while, the one thing that makes Rails stand out is the idea of convention over configuration. Configuration is the old school way to do things: control ever part of the system and tell the computer exactly how to do it, just shy of coding in pure machine language. Convention takes advantage of sociolinguistic context.

And with the pairing of convention over configuration (sociolinguistic context) with self-reflection, you’ve just come that much closer to implementing AI.

I don’t know why, but suddenly I had the urge to try yet another blog engine, even though I haven’t really hacked into SimpleLog’s internals and given customization a chance, which was the whole point of using it.

The first thing I did was search through freshmeat. I found a few blog engines that hit all the right buzzwords for me, and which sound intriguing. One of the cleaner looking ones is Bloo—it’s new, it looks simple, and it’s based on a PHP framework(!) which is object-oriented. The other one that sounded interesting is minb, which does not need a db, and uses XML as its storage model.

The thing that made me hesitate—a lot—was that they’re both written in PHP.

PHP is a kludge

Don’t get me wrong. I admire a good kludge when I see one. And PHP is certainly one of the biggest, most successful kludges out in the world today. (Although, granted, it is certainly cleaner than Perl/CGI, but that’s another rant entirely.)

But I’m a guy who does other things than code. Kludgery is always good for the one-off. But it’s terrible for maintenance, and it’s terrible when you want to actually learn how to code properly.

I don’t have anything against PHP necessarily. It’s just that my first direct interaction with the stuff was a Bad Experience™.

Wordpress gives me the heebie-jeebies

Now granted, Wordpress is good at what it does. It is the most widely deployed Open Source blog engine, and in 2007, it seems to be more ubiquitous than even Blogger and Movable Type.

But if you ever want to get Wordpress to do something a little different than usual, beware.

I used Wordpress from February 2006 to June 2007, having moved from Blosxom. But what made me jump ship was my problems with themes.

Frankly, most of the Wordpress themes look extremely crappy. I can’t believe that, in this day and age, people are still doing fixed-width designs. (I guess I should be happy they’re no longer using tables.) Or the designs are too noisy, too crowded. Three columns, with more of the look of a web forum or a Slashdot-clone, than that of a personal journal. And the ones that look good and are innovative (the Hemingway theme comes to mind) are mindlessly copied ad infinitum.

Which in itself is not a problem. Nothing that a good text editor and some XHTML/CSS can’t fix.

But then I found myself wading through hundreds of lines of PHP embedded within the themes. Maybe this was just an abberation. But I looked and looked, and found that Wordpress seems to be anti-encapsulation. A theme developer is forced to put business-logic in their theme.

I Can’t Help It, I’m an Artist

Now I don’t know why I’m so against nested angle-brackets. I get the shivers whenever I see a bit of code like:

<a href="<?php displaylink[x]; ?>" title="<?php displaylink_desc[x]; ?>"> <?php displaylinklabel[x]; ?></a>

Now maybe I just need to configure my copy of Emacs better, but it sometimes drives me nuts when I’m missing a closing angle-bracket, because Emacs doesn’t care about tags that are embedded in quotes.

But nested angle-brackets seem to be a characteristic of PHP, and try as I might with assigning commonly used functions to variables, I couldn’t eliminate every instance of code sitting inside the design.

I gave up.

OOP. Bright and Shiny.

Now I realize that Wordpress is just badly coded. Sure, it does what it’s supposed to do (most of the time), but trying to change anything is an exercise in frustration. There are redundant sets of functions (one for display, and one for assigning to a variable), the code is pretty much spaghetti, and a lot of things just don’t make a hell of a lot of sense. I realize that the spaghettification of Wordpress has a lot to do with it inheriting a really old codebase, which was written in a now-deprecated (although still widespread) version of PHP.

At the same time, I was learning about the new darling of the Open Source world: Ruby (not to be confused with its even more popular framework, Rails)

I’ve always been intrigued by object-oriented code. I like the idea of mapping code to real world objects and processes. I suspect that true AI systems will require an object-oriented implementation, because human brains seem to function in an object-oriented manner. (Don’t ask me for evidence on this one. It’s just my intuition from studying both neuroscience and computer programming.)

My interest in OOP also lies in the fact that I’ve been running Mac OS X for the past few years and the entire system is based on OOP (Objective C, to be precise.) The most interesting thing that Objective C and Ruby have in common is that they both borrow from Smalltalk, the language developed by Xerox, which is the company that spawned the whole GUI revolution. (OOP and GUIs seem to go together so naturally, its amazing that there are actually few instances where the two are intertwined.)

Smalltalk seems like a cool idea that was just too ahead of its time, and even Xerox didn’t have hardware that could run it at a usable speed.

Long story short, I ended up jumping on the Rails bandwagon. I’ve tried Typo, I’ve tried Mephisto, and now I’m using Simplelog.

“Slow and Easy” beats “Fast but Arrogant”

The thing with Ruby (without and with Rails) is that “I just get it.” Like I said, I’m not a professional code monkey. I just do this for fun, even though I’ve been screwing around with computers for more than 20 years now. I found C difficult. I found C++ more bearable because at least it had the C++ standard library, although ironically I never got the hang of the object-oriented side of things. I found Perl and specifically TMTOWTDI refreshing, and for the longest time, I didn’t use anything else.

But, while it’s really easy to write one-offs in Perl, it isn’t always the easiest to comprehend.

This is what makes Ruby different.

I can look at a piece of code and figure it out just by looking at it, fast. It’s such a different experience than when I’ve used other languages. For me, it’s like the difference between moving my lips while reading and sounding things out phonetically, and comprehending entire words and sentences at once.

And while a lot of this magic is Rails itself, it seems to pervade the entire language. Because Rails doesn’t just hide the messy internals from the naive programmer. If you really wanted to, you could look at the Rails code itself, and you could probably figure out what it does just as quickly.

Grrr.

Which leads me to this entertaining reactionary rant from a PHP guru directed against Rails fanboys that I found on Google while trying to look for more blog engines.

Now, maybe the underlying tone is purposefully, ironically, full of piss and vinegar, to match the caustic feel of the “Fuck You” slide from the Rails talk that he cites. Still, it sounds a lot like some wimpy Asian geek who just managed to pwn you on Counterstrike and who keeps rubbing it in, talking shit.

And I totally understand the reaction to abject fanboyism. Back in the day in the late ‘90’s, I had it in for the Mac fanboys (despite eventually converting to Mac fanboyism in 2002.) But at the same time, I can’t stand Microsoft butt boys, and the Rails fanboyism can be cloying.

And Chay’s rant stinks of PHP fanboyism.

I recognize that PHP runs a lot of the web (which is what Perl used to do back in Web 1.0) But the fact that the most popular sites, and the biggest site in the world—Yahoo—runs PHP is mere accident of time and implementation. If Yahoo (and the Web) had been built earlier, it might have been scripted in Lisp or even Smalltalk for all we know. If it was just being written now, maybe Haskell or Erlang might be the magic language. (I mean, just think how fast Yahoo would be if it were fully parallelized in Erlang?)

And the idea of not using frameworks sounds ludicrous. While we may have hit the quantum mechanical wall when it comes to CPUs, there is still a lot of optimization possible with memory buses, with storage media, with network switches, with data transmission technology. Some day the performance optimization you did in PHP will not matter a damn, and the time lost trying to decipher your kludge is going to cost a lot.

Not using a framework is like coding in C++ without using the standard library, or coding machine language by hand instead of using an assembler. Maybe it executes faster. Maybe it performs better. But there’s a terrible cost in maintainability.

The Road to the Future has a lot of speedbumps

I know first hand what a pain in the ass Rails. Even though my blog has like one reader, it used to crash and give 500 errors quite regularly. Some of this, though, is the fact that my webhost isn’t really optimized for Rails.

And without caching, it’s slower than molasses. It might take a full minute to render a page, which is rather pathetic.

But the quickness by which I can comprehend the code and customize it to my liking is worth it. Someday, it will not be slow, without me changing or optimizing a damn thing.

Sure, there is indeed merit in living in the present, and dealing practically with problems. Sometimes all you need is a piece of duct tape, and PHP is a lot like duct tape. If your paycheck is entirely dependent on your coding skills, and you know PHP like the back of your hand, of course it makes sense to deploy it. Your employers are paying you to fix problems, not to create aesthetically pleasing pieces of code.

But to ignore the future is slitting your own throat. Someday, the 9 year old script kiddie who is screwing around with [Scratch][14] today is going to be kicking your ass around the block with apps written in two or three lines of code in the Next Generation Programming Language, built on top of the Next Generation Framework, and it’ll perform just as well or better than any soon-to-be obsolescent PHP kludgery you’ve written today and have tons of new features.

I agree that Ruby and Rails is not the end-all-be-all of Web 2.0. In the end, it’s going to be a stepping stone to Web 3.0. But I guarantee that five years from now, the paradigm represented by PHP is going to be long-dead, and if you don’t move on to Bigger and Brighter Things™, you’re going to find yourself unemployed.

This is just a quick outline of the steps I took, which I hope to fill in as time goes on.

This route is really circuitous, mostly because the migration script included with Typo is apparently very CPU/memory-intensive, and Dreamhost’s sentinel processes always ended up reaping it before it could even import a couple of blog posts. It also requires the installation of random pieces of software you probably won’t normally use on your local machine. Be forewarned.

NOTE: My desktop computer is a Mac Mini PowerPC G4 running at 1.25 GHz with 1 GB of RAM installed, running Mac OS X 10.4 Tiger. These instructions should be equivalent for an Intel-based Mac, and should be reasonably adaptable for Linux, BSD, or other UNIX/UNIX-like systems. Unfortunately, I haven’t run Windows since 1999, so I can’t really help you there.

1. Export your Wordpress database using whatever method is most comfortable to you. I used myPHPadmin which is available by default on Dreamhost. Transfer the resulting flatfile to your local machine.
2. Make sure you have MySQL running on your local machine. Of interest, MySQL is installed by default in the Server version of Tiger, although turned off by default. It should be pretty easy to install MySQL on any respectable Linux distribution. On the Client version of Tiger, while you can build mysql using Fink or MacPorts, the easiest thing (read: the thing that involved the least amount of thinking and/or compiling) was to just download the binary distribution from mysql.com. The stable version as of this writing is 5.0.
3. Install CocoaMySQL. Obviously, if you’re quite familiar with dealing with MySQL on the command-line, there’s no need to do this, but since I’m not, this was the easiest thing to do.
4. Import your database from Dreamhost into your local copy of MySQL
5. Make sure you have a functioning copy of Ruby installed. Tiger comes with an old version of Ruby installed, so I tried compiling the newest release with Fink. Unfortunately, there are still some issues with compiling Ruby using gcc 4. While it will build without problems, Ruby will segfault randomly when run. Since I didn’t really want to screw around with compiling with gcc 3.3 and making sure all the relevant dependencies would play nice, I ended up installing Locomotive, which lets you run Ruby on Rails applications in a sandboxed environment.
6. Install Rails. Again, Locomotive will take care of this for you, but if you’re running Linux, or you manage to get ruby correctly compiled on Mac OS X, you can just install the gem like so: gem install rails --include-dependencies
7. Make sure you have svn installed. Subversion, a version control system, is readily available on all respectable Linux distributions and can be compiled without incident on Mac OS X via Fink or MacPorts or even just from source.
8. Download typo via svn. You can pretty much install Typo anywhere you like. Once you’re in the directory (folder) of your choice, type: svn checkout http://svn.typosphere.org/typo/trunk typo (see the Typo Trac for more info about grabbing the trunk versus the 4.1 branch.)
9. Create a new database for use with Typo.
10. Configure Typo to use the new database Edit config/database.yml (relative to the directory you downloaded Typo to) so that it’s pointing to your new database.
11. Format the new database with Typo’s schema. I used rake db:migrate Other ways (not sure if this is up to date) are described on the Typo Trac. These should work just as well on your local machine as it does on Dreamhost’s servers.
12. Run the Wordpress 2 → Typo 4 converter script. (If you’re using Locomotive, at this point you’ll need to create a new project and point it to where Typo is living, and start it.) Type db/converters/wordpress2.rb --help for help with the syntax with converter.
13. Export the Typo database on your local machine.
14. Create a new database on Dreamhost for Typo.
15. Import the flatfile from your local machine into the database on Dreamhost.
16. Install and configure Typo on Dreamhost exactly as above. From what I can tell, Dreamhost now has a current enough version of Ruby (1.8.5) and Rails (1.2.3) to run Typo properly, but if you must have the newest versions of everything, you can build it all in your home directory.

At this point, you should be able to point your browser to your site and create an admin account. All your Wordpress posts will be there, although the converter script turns all your entries and all your pictures into separate blog posts.

Right now, I’m running Typo out of the box without having to put in the hackery used to avoid getting 500 errors. Compared to a year ago when I tried Typo out, it feels a lot faster and more responsive, although it is still kind of slow. We’ll see how it goes.

One thing that I found irksome, and for which I couldn’t find an easy solution to on Google, is that Typo’s permalinks are formatted like so: http://domain.name/articles/yyyy/mm/dd/slug In contrast, Wordpress’s permalinks are http://domain.name/yyyy/mm/dd/slug. Personally, I feel that articles is unnecessarily crufty, but I couldn’t figure out an easy way to get rid of it. I couldn’t get Apache’s mod_rewrite to work with Typo either. So this is what I ended up having to do to at least keep my Wordpress permalinks alive. (Derived from WordPress to Typo Migration, Part II.)

In config/routes.rb, add this:

  map.connect ':year/:month/:day/:title',
      :controller => 'wordpress_url', :action => 'redirect',
      :requirements => {:year => /\d{4}/, :month => /\d{1,2}/, :day => /\d{1,2}/}
  

This will require you to create a new file in app/controllers/ called wordpressurlcontroller.rb

app/controllers/wordpressurlcontroller.rb contains the following:

  class WordpressUrlController < ApplicationController
     def redirect
        year = params[:year]
        month = params[:month]
        day = params[:day]
        title = params[:title]
        url = "/articles/#{year}/#{month}/#{day}/#{title}/"
        redirect_permanently url
     end

    def redirect_permanently url
      headers["Status"] = "301 Moved Permanently"
      redirect_to url
    end

 
    private :redirect_permanently
  end

Now, I’m a Ruby/Rails newbie, so if there is a cleaner way to do this, or if there is a way to get rid of articles from the permalink, suggestions would be appreciated.