What?

I just came up with this blog after attending Rubyconf 2007. I have no idea whether anything will come of this.

I suppose, as a first blog entry, I should say what this is all about.

For quite a few years, I've known about Ruby, but haven't done a whole lot about it, except I went to Railsconf this year (pricey) and Rubyconf (less pricey). By listening to folks, I get a broad sense of what is going on.

I first heard about Ruby, hmm, when? I don't even know. I heard about Python first, sometime in the 90s, and even tried it out a little. I read about Ruby certainly before Rails came out. But then, I've heard lots of languages. I heard about Haskell in the early 90s, and it's making some kind of comeback.

I've heard of Lua, Python, Ruby, Perl, PL/1, Ada, Fortran, Lisp, Java, C#, Javascript, VB, Oberon, Modula 2, Pascal, Eiffel, Smalltalk, ML, O'Caml, Erlang, Clean, Miranda, C, C++, D, Objective C, Rexx, Postscript, Simula, and there are some Turing complete languages that are pretty useless to code in.

The point of the blog, should I take this mission, is to document what I do about Ruby.

At one point, I wanted to learn a bit about scripting languages. I discovered that these languages were split into two categories. There are those that are basically a thin veneer over UNIX commands, basically control flow plus UNIX. Those would be csh, sh, tcsh, bash, zsh, ksh, and a bunch of variants.

perl started to create a platform independent language, and one that had a few more features than the average scripting language, and when sysadmins adopted it, it became the standard language of admin types.

perl also pushed the definition of a scripting language into something a bit more powerful, and possibly respectable, even as many people find perl impossible to read. Even so, without perl, there would not likely be Ruby.

The scripting languages that are perl's closest relatives are Ruby, Python, and Tcl, though Tcl is considered quite a bit less powerful than Ruby or Python. Right now, Python and Ruby vie for which is more popular, though a few years ago, you had to say Python. Ruby really got its big push from Rails.

The perception of Python and Ruby have changed over the years. Most scripting languages aren't strongly typed. Variables have a type, but it can change depending on what it's assigned to. Many people, probably those from Smalltalk backgrounds, really, really like this. They find types too hard to think about, and prefer things to be more dynamic.

But here's the issue. Languages only form one part of learning a language. While most people talk about syntax and basic programs, you still have to write code, which means you need to know an editor, and given that Ruby/Python tend to be interpreted, there's an interpreter, which means you need to learn that too.

And the choice of editor is a bit of a cultural thing. For example, a lot of people in the Ruby community use Macs, and a lot of them use a Mac-only editor, called Textmate. Textmate appears to be the new emacs. Someone is writing a Windows version modeled on it.

This cultural thing is much like using vi (now vim) or emacs in the UNIX world. Even if these editors are ages old, so many people in UNIX use it, and build tools that use the keystrokes from these two editors.

But here's where it gets more interesting. Most Rubyists, as Ruby folks like to be called, are into agile development. You see, once you lose strong typing, then you start to get concerned that you are passing the right types as arguments, because the runtime system isn't flagging every single problem to you, and thus bugs might be hard to find.

Thus, unit tests are big. Indeed, the new "unit tests" is RSpec, which is a way of writing specs using code that looks like it "should allow users to take a role" or some such. Underneath the hood, it's a unit test, but it reads like a spec, and it can be run, so you can see whether it passes or not.

But this test-first attitude, while common in the agile community, seems really heavily wedded to Ruby. Ruby folks just do it. And this can be at complete odds with teachers of languages.

Because you know what? If Ruby is really to gain traction, new folks have to learn it. OK, so the software industry jumped on the C++ bandwagon, and they had spent years doing it before universities felt the need to teach it. But some academics hated C++ because it seemed really complex. Then, Java arrived, and several universities loved it, at least, compared to C++.

But eventually, the real kicker was the AP exam adopted Java a few years ago, and that meant high school students and college students learn Java, and now, all of a sudden, there's a huge wave of Java programmers, even as some people still want folks to code in C++.

But you can't understate how important having Java in the schools keeps Java going.

But if Python and Ruby are so powerful, why don't people change to these languages?

Part of it is history. People think of scripting languages as trivial, mostly because they haven't paid much attention. After all, people consider VB something of a scripting language, and no serious university teaches Visual Basic, at least, to computer science majors.

Part of it is having to learn yet another language. Part of it is not knowing the Ruby (or Python) culture, so you teach the language the way people use it.

So part of me not learning Ruby is the daunting task of learning TextMate, and of course, trying to decide whether I should do Rails first or not.

Ultimately, I think the way we teach programming needs to change. We need to peek over the shoulders of how people code, and capture that in video, and eventually peek over the shoulders of many more people.

And the problem? Editors.

Yeah, editors. If we would all agree on the one true editor, we'd be done. We could focus on programming. We'd talk about the editor, how to move around in it, how to maximize its use, and then we'd code.

But there are tons of editors out there, and no two act close enough to each other to matter. So, no one wants to write a book on Textmate for Ruby, say, because you can't get Textmate for free. And so people feel guilty recommending it, and the solution may be that someone will eventually implement something close to it, and it will be free and awesome, and then someone won't feel guilty about it.

Look at most books on programming languages. They hardly ever talk about the editor. Because there's one way to really reduce the number of people that want to read your book and that's to pick an editor. And an editor needs time to explain, and you want to see someone who's good show you the way, using the features you want to use, and get you into the mindset of using that editor.

And most of that has nothing to do with the language for which there are typically plenty of good books.

But those books often cover syntax and examples because that's easy to write about. It's harder to talk about how to write code, how to design code, and so forth. And Ruby, as I mentioned earlier, has taken this to the next step, which is that it marries itself to TDD, which is test-driven development. There's nothing about Ruby that forces development to occur this way, but it seems really effective, and so it suggests that a new Ruby learner needs to learn this way too.

So I suppose the first thing I'll have to do is learn how to use Textmate. We'll see how that works out. I'm certainly happy if someone can suggest a roadmap for how to use Textmate specifically for Ruby (not Rails for now).

Anyway, that's why I'm writing this blog, from the perspective of the ordinary coder, not the extraordinary.