The Editing Process

It's been a week now since Rubyconf ended, and I feel I should write another entry before I get too lazy.

Learning a language used to focus on the syntax, even if this really only scratches the surface. The Smalltalk guys have it right. Learning a language is not simply syntax. It is learning an editor, learning the process of coding, and finally learning the syntax.

The vast majority of attendees to Rubyconf are probably already Ruby coders, and either through their own curiosity, or through pair programming at RUG, or their local RUG (Ruby User's Group), they learned how to code Ruby, and I don't mean code it casually, but code it like most Rubyists, which means they either like TDD (test driven development) or BDD (behavior driven development).

I met two students from Duke, and they were interested in getting Ruby more popular on campus. But, lest we forget, students are busy people. Unlike "real" people who can use their evenings and weekends to get things done, students have to do homework. And let's face it, occasionally they want to meet up with their friends. Furthermore, many are still learning how to learn. To expect they will learn Ruby "properly" is a stretch.

And yet I find a lack of resources to learn Ruby in this fashion. The problem is this. Most intro Ruby books are aimed at complete beginners, to people who don't even know what a class is, nor a variable, nor a loop. And even books that do a poor job explaining Ruby concepts because the author is too impatient to explain them, and wants to jump to advanced concepts right away, often fail to describe the editing process.

That's right, the editing process.

Of course, that's really only part of it. Most people know of the edit, compile, run cycle. Most of the effort in most books or tutorial isn't spent on any of these steps.

And that begs the question, why not?

For the most part, you can tell a person one compiler to use. In this case, maybe the MRI (Matz's Ruby Implementation). In any case, most compilers of a language try to compile the same language.

This means focusing on the language is the easiest part of all. It varies the least from person to person. Even if a language changes from, say, 1.8.6 to 1.9 as Ruby is about to do, it won't change drastically. A core subset is likely sufficient and pretty much stable. It won't change much for years to come.

But the editor? Go to a Rails conference or a Ruby conference, and everyone has a Mac, and the vast majority use Textmate. Have you ever noticed there are absolutely no sessions on Textmate? Why not? Is it because Textmate the editor is much easier to learn than Ruby the language? Possibly.

But why leave that part of the coding process to the user to figure out on their own?

The reason? There's no one true editor (TM).

And that's an issue, because authors who tie themselves to an editor force their readers to pick that editor. Textmate, unfortunately, does a disservice to most Ruby learners by charging a fee to use it. This means people who teach Ruby are afraid of teaching Textmate because they don't want to tell their students to spend the fifty or so dollars it takes to buy this product.

The solution is, to me, relatively simple. Teach that, and pick a reasonably Windows friendly editor, like RadRails, and use that too. And finally, do it old school. Use some silly editor, maybe a Notepad, and show how to use it to edit Ruby. Keep the section on editing moderately separated from the coverage on the language.

Textmate makes things a bit complicated. First, it relies on three symbols to stand for Option, Shift, and Control. Personally, I like the emacs way of doing things with a capital letter, such as C-a (for Control a), S-a (for shift-A, thought Shift is almost never used as a symbol) and so forth. I'm sure the first thing I have to get used to is reading these symbols, and eventually it will come naturally. But it's a pain until that moment.

Then, it introduces a bunch of new concepts: bundles, snippets, and so forth. But this is a little like introducing kitchen tools: a grater, a spatula, a potato ricer, a whisk, a garlic press. Introducing tools, and using them properly within context are two different things. The key is to cover the use in context, instead of focusing so much attention on what they are. To be fair, emacs has the same problem, but for the most part, it tends to help you format text, not to run the code itself or help in that process.

Why am I harping on this issue? Because knowing your editor well leads to a better development process, and so a book should simply risk the lower sales by delving into the editing process, especially as it applies to coding in that particular language or that particular framework (say, Rails).

So my first goal is to figure out what this editing process is, both to master how to edit in Textmate, and then also how to write code.

My feeling is that it's just going to be much easier to find someone who already knows, and ask, then to try to piece it together from webpages.

Let me digress a moment.

Many good coders have a certain kind of personality. You know what the biggest complaint most people have about software (other than it's broke). Documentation.

So how do top-notch coders deal with the fact that many things are simply poorly documented. Do they throw their arms up in the air and refuse to work? One would hope that this would be their reaction, because it might force the issue, forcing languages to die that won't properly document (and proper documentation is itself a big issue--what does that mean?).

Instead, they treat learning a language like a video game. Not a shoot-em-up video game, but a game where you hunt around and try to figure out what's going on, and try this, and try that, and so forth. Eventually, they figure out what's going on through this educated trial-and-error process, and they make great progress.

But because they find information in this fashion, they get very irritated when you ask them how to do something. In a nutshell, they don't know. It's much like a person who drives to someplace vaguely unfamiliar. They know basically where they need to go. They know a few major roads. They basically wing it. Ask them the directions, and they would get irritated, because they actually can't say how they got there. They only know vaguely how they got there.

Thus, the usual advice they give: "figure it out". They can't simply admit "I just tinker around until I figure it out, and you should too". But are people stupid for not wanting to learn stuff in this fashion? To sit around, read code, and meander until they figure it out.

I suspect this style of learning doesn't appeal to me for the same reason that video games don't appeal to me. That kind of patience to figure stuff out is not something I enjoy. I can do it, somewhat. Alas, great coders are filled with these kinds of personalities, but there are still plenty of coders that are closer to me.

And, alas, the great coders aren't willing to introspect. They are like intuitive cooks, that take a pinch of that, a touch of this, and can't really tell you a solid recipe. I have to commend Dave Thomas (or maybe his wife or Andy Hunt's wife) for realizing that experts learn or think of things differently from a novice.

I asked someone about learning Textmate, who didn't have any solid advice to offer. I suppose writing it down would have taken hours, at the least, and he had no time to do that. I would imagine that, in fact, it would take about half an hour to explain something basic, but even that was a bit too much time for him. And thus you see why people don't like to explain.

Fortunately, I do like to explain. I just don't particularly care for the process of learning a process, because in many ways, it's completely arbitrary, and rather than follow the tedious steps of a well-formulated recipe to cook something, I'll have to figure it out by trial-and-error, and I may still not end up coding like I should.

Well, at least I wrote that. Perhaps someone will feel the pain, and offer suggestions. In the meanwhile, time to read about Textmate, and play with it some.