[personal profile] tara_hanoi
(My first attempt at actually writing anything in this blog that is in any way related to the reason I set up this thing in the first place - this is also my first ever attempt at a review of a resource, so some feedback on style would be appreciated)

Because it's been on my ToDo list for a while, I decided to try learning Ruby. Having learnt python from a fabulous publication called Dive Into Python, I realised that when learning a language, I want to learn the feel of the language and not just the bare syntax of it.

To me, learning the language's style is a must; there's a nice satisfying mental click when you get how things are phrased in the language. You suddenly see the strengths and weaknesses. Given as I prefer to use the language as it's intended from the outset, I like learning the language's idioms from the outset.

For the non-techies, it's the difference between human languages. For instance, how do you introduce yourself. In English, I'll go with one of a few options: "I'm [personal profile] tara_hanoi", or "My name is [personal profile] tara_hanoi". In French, you don't apply the concept in that way. Instead you say, "I name/call myself [personal profile] tara_hanoi". In Irish, you say, "[personal profile] tara_hanoi is the name for me". Sure, technically, you could mangle the English way of expressing what your name is and force the entire construct into the language and make yourself vaguely understood, but if you REALLY want to speak like a native, you need to use the shape of the language to your advantage.

I also realised I like introductions targeted at people who already understand programming. Things like if/then/else logic and loops are pretty standard fare for anyone who spends their time telling a computer what to do; you need to know how they work in any non-trivial language, and I don't need it all explained again. What I do need explained is the syntax and any associated caveats.

Beyond syntax, I also need to know what idioms are used and why. In python you have list comprehensions, which reduces trivial loops to one-liners in a readable fashion; if you try to write python the way you'd write some beautiful C code, and without grokking The Zen Of Python, you'll end up with a horrible half-formed mess as you try to marry 2 different cultures of elegance, breaking the rules of each in order to satisfy the other. If that style of program could speak, it would look up with doleful, rolling eyes and whisper, in a hoarse, scratch voice, "Kill me". The saddest thing is, unless you know the culture of the language you're learning, you won't even realise you've created such an ill-fated monster. Furthermore, despite not recognising the ugliness of your code, you'll probably fail to feel any serious attachment to the language and walk away.

I wanted to learn Ruby in a way that would put Ruby's features to good use, and I wouldn't try to use it like Java or C or even python. Sure, knowledge of how things are done in each of those languages help, but if you're always hacking a ruby program in the way you'd use C, why not just use C all the time?

By sheer chance, I happened upon Ruby Koans - a test-driven way of getting you into the Ruby Mindset. The idea of Koans appealed to me; I was fortunate enough in my upbringing that my dad told me early on what a Koan was. To me, a koan (although I've looked it up on wikipedia, and what it explains is different to what I understood) is a mental focus used for meditation. It helps jolt your mind with a paradox so that you slip into understanding the infinitesimal space between binary answers to an apparently either/or question. "If a tree falls in the forest, and there's no-one around to hear it, does it make a sound?", that sort of thing.

Following that idea, I liked the idea of some basic exercises that kickstarted you into the Ruby headspace. I also liked the idea that it was test-driven. I've been getting into test-driven development, or at least making sure I have a bunch of unit tests for my programs (they might not be written first). I'm also a Quality Engineer by trade, so I know how tests should work; tests should be clear, unambiguous and target one specific area as precisely as possible. (That's the theory anyway, there are always problems achieving that mystical goal)

I sat down and ran the tests. It is nice to have a directed, hands-on guide through the language, and it mostly delivered. You get a nice output with the failure, and the expected output. It's a nice little output, although, sometimes you really get the answer that you should be filling in from that. It's hard not to rely on those outputs in order to just fill in the answer that's expected without thinking about it. As a result, to improve my learning experience, I had to deliberately tune out those outputs telling me what I'd expect to see in order to make the test work.

It's stated on the page that the expected way you work through the tests is: See the test break, Fix the tests, Refactor/Meditate. Unfortunately, there wasn't a lot of refactoring/meditation to be done, and by the time you do get to the point that you have to start meditating on the experience, you're so out of practice with it, that you probably won't.

Overall, the Koans gave me a whirlwind tour of the language, but I'm not sure I know it well enough to program in it, despite having hands-on experience. For the most part the tests involved modifying implementing a one-line fix in a test. Sometimes there were projects where you'd write some code and, at the time, I felt competent doing so. But about 2 weeks on, I haven't heard some voice in my head saying, "I could express that Ruby-style".

It did do a solid job of expressing one ruby-ism, which was its peculiar in-line block style. For a small while, I got how it separated out concerns. However, I don't think I'd be able to write something in/for that style in any way competently.

Part of this whistle-stop tour of Ruby involved a deep-dive into some of Ruby's special innards. As a first-time learner, using the Koans as a tool, I was a little perturbed by this. Specifically, it played with the idea of send() and some method_missing function; that's great, but is this something where I'm expected to know what it is, just in case I see it, or is it something that's almost expected of the user to use? Were I to change the way Ruby Koans was organised, I'd probably introduce the concept of a scenario file. I'd have at least 2 scenarios, one for first-timers, and one for people who want the deep-dive.

At this point in the deep-dive, I started getting worried. There were comments like "This object can use send() and __send__() what do you think the difference is". Great, if I google that, the first hits are probably folks who are asking exactly the same thing because they were working through the Koans. It would be nice to have a little explanation, or some resource where they think it's actually well-explained.

Some other bits seemed woefully lacking. Sure, I knew how to use loops... sorta. But I realised I had major gaps in my knowledge when I tried to refactor a project I was working on. For all the shiny things the Koans taught me about loops and control flow, I found myself wondering that the basic syntax was for looping with an index ("run over the numbers from 1 to 6 and put it in a variable called i for me")? I looked back and found nothing on that subject (although from other aborted attempts to learn the language, I knew it existed). In the end, for the project I was working on, I just googled the Array class, and worked out a way to initialise a random array (if you do the Koans, you'll probably see what I'm talking about). I still don't know if I really did it the Ruby way or not, or if the way I was thinking of was a good way to do it.

So my final thoughts?

Would I give it to a day-0 programmer - Dear lord, no. But that wasn't what I was looking for.
Was it condescending? - Thankfully, no.
Would I recommend it as a ruby primer for folks that already know how to program? - Maybe. Depends on their mindset. I'm not sure I was of the correct mindset, but I think there were some gaps as well. It also mixes in some Deep Magic without any way to not dive into that stuff, and without pointers as to where to find out more.
Would I feel equipped enough to understand the framework code after working through the Koans? - Um, no. I've just looked again, and it's still Dark Magic.
Do I feel it's good for a ruby expert who wants to check if they know their stuff - Probably.

Basically, would I recommend it to others? Probably not.

However, the caveat is that I started with some clear idea of what I wanted, and hoped the Koans would live up to that. So that failure is with me. Maybe later on, when I finally grok the language, the Koans will be handy in solidifying my knowledge, but right now I feel I'm probably best off unlearning what I have learned (not hard) and try to find another resource geared towards programmers.

Date: 2011-04-28 08:43 pm (UTC)
chebe: (ThoughtFractal)
From: [personal profile] chebe
\o/ Congrats! And thank you, I enjoyed reading this :) Your style is 'grab a cup of tea' enjoyable. And I've totally grabbed that Python book (one language at a time), thanks again!



September 2015


Most Popular Tags

Page Summary

Style Credit

Expand Cut Tags

No cut tags
Page generated Sep. 21st, 2017 03:29 am
Powered by Dreamwidth Studios