Day One: Ruby Studio

It first started out as a book, then a publishing company, and now they offer courses. The book was The Pragmatic Programmer written by Dave Thomas and Andy Hunt. The publishing company is called Pragmatic Programmers (or pragprog for short). The teaching arm is called Pragmatic Studio.

I decided to sign up for the inaugural (I didn't know it was inaugural until today) Ruby Studio. I had expected turnout to be somewhat low, but these things are tough to estimate. Although PragProg is tiny by most publishing standards, it's well known about by software developers that there might be 1000 eyes or more for each person who decides to attend.

The reason I thought it might not be SO well-attended is that it's an introductory course in Ruby, and most software developers would consider themselves savvy enough to teach themselves how to program a new language. Now, if this course were substantively cheaper and offered throughout the country, then maybe it'd drum up more interest, but then maybe not.

As it turns out, the class is reasonably full, at around 30-40 people attending it. The demographics are interesting. The class is almost 100% white (as far as I can tell). I'm the only Asian. There are no African Americans, nor other Asians. No Chinese, no Indians, no Koreans. To be fair, Asians make only 1-3% of the American populace, but also make a much larger percentage of the IT industry.

I'd say women make 10% of the attendees, which means there are 3-5 women, which, given Ruby/Rails is a bit higher than expected, but a pleasant turn out.

Dave started by asking the crowd where they came from, and what you see is a large (from my perspective) number of Web developers doing PHP, looking to switch, some QA and sysadmin types that don't code much, but want to use Ruby in their day-to-day work. Also, to my surprise, is the number of people who work on Rails that want to learn Ruby.

This feels like, to me, a J2EE person who wants to take a Java course to learn more Java. It almost sounds silly, since you'd expect any J2EE person to be proficient in Java in order to do basics. Having said that, maybe Rails is so easy to use, so easy to follow simple examples, that you can get by without knowing much Ruby.

Ruby is a funny contrast. On the one hand, given the number of non-developers (which is not to say non-programmers), people must perceive Ruby to be easy enough to use. And yet, folks like DHH do so much metaprogramming magic that most of the attendees (me included) would be shocked at how much you can do in Ruby that is dumbfoundingly difficult.

I won't get too much into the details of what we're doing. There's nothing especially magic about what we're doing, but one issue of interest is how do you teach a language to a wide variety of people? The second is, given that you have to teach uniform content (that is, you don't intend to specialize to each student), what do you teach?

Ruby Studio lasts 3 days, and intro courses are notoriously difficult to teach, because you have a lot of ground to cover. For example, we talked about gems, which is Ruby's way of installing libraries from RubyForge. These aren't official libraries like Java libraries but community donated libraries.

As a teacher of programming, issues like installation is always problematic because you'd want it to be as effortless as possible. One idea, problematic as it is, is to go to a webpage, and edit there. Everyone would use one official compiler, and the same development environment, no installation would be required, and so forth. Anytime, you have to start talking about installation, then you have to go into "Why do I have to install it?".

For example, when I taught "C", I didn't tell people to download "C", untar, and make it. Instead, students were given special accounts that already had "C" installed. I know. It's the nature of languages that they run locally on the machine, and that some installation has to be done, and there are distributions that are practically a double-click from installation away. I'm not saying it shouldn't be taught, because as much as it distracts from the purity of programming, it's also the current real world when it comes to programming.

Oh, wait, let me get to me, to be narcissistic for a moment. Why am I taking this course?

I've heard of Ruby for years now. Years. I knew about Ruby before RoR was even a glimmer in DHH's head. I have (or used to have) the original Pickaxe book (well, the First Edition, in any case). I had the rather excellent Learn Ruby in 21 Days. I would say I've heard of Ruby since 2001, shortly after books became available, and I'm sure I've heard of the language even before that.

Long ago, I had this idea in my head that I should learn a scripting language. But with a plethora of them out there, what do I pick? csh? bash? tcsh? Then, I realized scripting languages fall into two categories.

The original scripting languages were basically simple control flow on top of the native operating system commands. Thus, you had variables, if-then, loops, and functions built on top of calling OS calls like "ls" and "cd". This was all fine and dandy, but you couldn't do computer science kinds of things. Linked lists and trees? Hah!

In Windows-world, these are called batch files.

The problem with these scripting languages, other than syntax that is painful, is that they aren't particularly portable. For example, there are many variants of UNIX, and not all of them have the same options for "cp". So you write a script that uses some switch like "R", and it works on one UNIX setup, but not another. How annoying!

Perl came up with a weirdish idea. What if they reimplemented basic functions like directory movement, file manipulation, etc. as Perl functions? Then, they'd figure out how to port it everywhere, and remove some of the nasty variations from UNIX and Windows installation.

Despite its hideous syntax, Perl allowed you to code real data structures, and was a level beyond what most scripting languages. One could argue easily if there were no Perl, there might not be any Python or Ruby. Indeed, Matz was inspired to write Ruby because of Perl. One might also argue that were Perl not so hideous, there wouldn't be the comparatively niceness of Ruby/Python.

One could also argue that Perl didn't convince computer science types that it was a real language. Its nearly immediate embrace by UNIX sysadmin types, who many programmers oddly consider a subform of developer (to be fair, they aren't really developers, but usually, their knowledge of the system is amazing) put it in some enclave, and people didn't seriously think of Perl as a language people could learn for real. So, in a sense, Perl also retarded the acceptance of scripting languages as being acceptable for programmers.

Having said that, despite its horridness, people who didn't consider themselves programmers found themselves programming in Perl, and because people talk about Python and Ruby as better Perls, people who would otherwise find C# and Java completely intimidating, seem less averse to learning Ruby.

Anyway, back to me. I tried writing a little code in Perl, but to be honest, its weird treatment of arrays and scalars and hashes made it really painful to understand. The books weren't that much better, because Larry Wall tended to assume you groked his view of the world and that it was all easy, when it wasn't.

So I stopped learning Perl. Then, I started collecting books on Python, and books on Ruby. I'm a guy who's great in getting ready to do something, but not so great in doing it. I get books because I expect them to tell me the One True Way (TM) of doing coding. And, almost always, they disappoint greatly.

Part of the issue is avoiding the issue of editing, which I've decided is critical to learning any language.

Honestly, I don't like teaching myself to do much, even if it's the only pragmatic way to program. You can't find experts who want to explain how to code stuff up and let you pepper them with questions. I mean, I can do it, but most books aren't really prepared to teach you programming in this haphazard manner.

I find when I come home, I'm not in the mood to learn to program, then program.

The other problem I have, and it's one I've had forever, is that I want to know that I'm doing something in the "right way". I don't want to do it otherwise, if I'm not. That may seem unusual, but it's far more common than you'd imagine, and it's the one thing that a good programmer should never feel.

I used to teach programming, and you'd find more than one student who want to confirm everything they did was "right". Why? First, they didn't want to feel stupid. Second, they didn't want to "break" anything. Third, they didn't want to waste time. They didn't want to sit there, spend hours doing something, only to realize, they had it wrong! They feel embarrassed, and won't learn anymore.

Let's take this idea out of the realm of programming. Suppose I were to teach you tennis. Maybe you're reluctant. You're not good at sports. You aren't athletic. Already, you've completely psyched yourself out. You won't try particularly hard. If something goes wrong, you're ready to bail. This makes it very difficult to teach someone tennis when they feel they need to be successful right away.

In a sense, I'm that way when it comes to programming. Actually, let me explain this with another anecdote. I knew this guy who, in his mid 20s, decided to pick up tennis. He tried to learn it the best he could. Textbook strokes and so forth. He took lessons. He practiced. He had taken martial arts when he was young, so was sure there was a good way, if not One True Way.

Personally, I'm more of this mindset. I want to learn to program Ruby properly, and that seems difficult. To me, that means getting decent at the editor. I wanted to make an analogy with playing a musical instrument, but that's not quite right. When you play a musical instrument, it's important the notes be played correctly, with the correct pitch and tempo. I suppose a better analogy might be to write music down.

One person composing music might labor greatly trying to write down notes. But, perhaps if they tried some other way, they would get better results, with far less effort. Perhaps there's a device that would let you play chords on a piano, and it would translate that to notes on a page. That would make it far less tedious than, say, writing it on paper.

I don't know that the course will really cover that. Editing, as I said, is far too underrated a skill in programming.

So anyway, I thought about signing up back in December, because I figured, after years, I was still not making that much progress, and I really wanted to be taught in a classroom environment, which is the best kind of way of learning for me, because teachers have pre-digested the material. The way people teach a class is not the way they'd write a book (mostly due to the fact that many people want a book to eventually be a reference book).

A classroom setting has to hit the highlights, focus on important stuff. And for a three day course, they have to cover lots of ground.

The real problem, as I mentioned earlier, is that you can't be all things to all people. Since you can teach a course on an IDE, without learning about a programming language (an indication how complex IDEs have become), most courses like this spend very little time talking about editing.

Even if the course won't cover that (in favor of other topics), I think it's a win for me because it's making me do stuff I haven't done otherwise. I realize, for many people, it's that initial hump that's the toughest. It's like deciding to go dieting that first time. It's hard!

So even though I could buy a computer for the cost of this trip, or some other nice gadget, given my personality, this isn't such a bad way to get me to do things. Ideally, I would prefer someone teach it to me for free, but seems like no one ever wants to do that. So if you have to pay, it doesn't hurt to have guys who are pretty famous for doing that.

Let's see how tomorrow goes.