Or should that be NoVaRug?
Anyone paying attention (or not, as the case may be) may have found my entries a bit sparse, partly because I haven't advanced that far since Rubyconf. I took the next step which was to attend the monthly meeting of NOVARug, or Northern Virginia Ruby Users Group for short.
At first, I thought maybe 10-20 people would show up, but it was probably closer to 30.
The talk was divided into two parts. The first was on agile methodology. A local startup company called RideCharge wanted to adopt agile methodology roughly based on Scrum, with user stories, etc. Although many companies attempt to do this from scratch, reading books, and guessing how they should proceed, this company has apparently done a better job than most.
It goes to show that a lot of the Ruby community has embraced agile methodology. There didn't seem to be any sense that Keith Forsythe, the project manager for the company, felt it was a bad idea, having spent many years in more traditional companies doing more traditional waterfall development.
The second talk was on Liquid, which is apparently a way you can limit what kind of Ruby code you can inject into webpages to prevent people from either maliciously destroying things they shouldn't or by accident.
I wasn't sure what to expect when I went there. The funny thing was that I met a former student, and the guy who gave the Liquid talk (Patrick Joyce) was also a former student. He looked vaguely familiar but the name didn't really ring a bell. He said he was nervous giving the talk in front of a former instructor, but I thought he did a pretty good job.
I pitched a pretty simple idea to them, though I have to wait to see if I can get anything out of it. Like most Rails developers, Patrick and his fellow developer use TextMate on Macs, and wouldn't you know it, I also have both. As mentioned in my rantfest of a previous post, I'm beginning to believe that knowing your editor is pretty important, and so I want to see what these guys have to say about developing in TextMate.
One suggestion they made was to look at RailsCast which I assume is a broadcast of Rails development. Apparently, they tell you what keystrokes they use as they are editing, so you can follow along as well.
I'll have to look into that, and see what I can make of it.
The event, by the way, was held in FGM, which looks pretty snazzy, at least, the parts I saw of it. They had some lolcat poster saying something like "I has no cheezburger", a plea to get people to give to the needy.
It's nice when a software company is able to use geek humor as a way to appeal to its fanbase.
Wednesday, November 28, 2007
Sunday, November 11, 2007
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.
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.
Sunday, November 4, 2007
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.
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.
Subscribe to:
Posts (Atom)