When I was learning Ruby in 2006/2007, one of the books that helped me the most was Brian Marick’s Pragmatic Programmers title, “Everyday Scripting with Ruby.” Sadly, it is out of print today. You can’t even buy a digital copy, if you ever could. (I don’t know.) It would likely require a big update to get it current with the latest edition of Ruby and all the changes in the industry since then, but at the time it was a very important book for me.
Yes, I had the Pickaxe book, also, which got me started and functioned as the Bible of Ruby programming, as it does still to this day. But “Everyday Scripting” brought it all to life for this Perl programmer. It treated Ruby not as an Object Oriented language, but as a scripting language.
The example that Marick worked on throughout the book told a story, and built features. It reminded me a lot of the kind of programming I was doing at the time.
It had brief glossaries of methods available for specific data types between chapters, and it even talked about testing your code, which is something I had done absolutely zero of at the time.
While the book is mostly forgotten today, I fear, I just wanted to chime in to say that it’s one of the most memorable computer programming books I’ve ever read, and the one that taught me the most about Ruby in a useful way.
In doing some research for this post, I put two and two together: Marick went on to write a well-regarded functional programming book, “Functional Programming for the Object-Oriented Programmer”, which is available through Leanpub.
For Avdi Grimm’s 2014 talk, “MythBashers: Adventures in Overlooked Technologies.”
For Torben Hoffmann’s Erlang User Conference 2015 talk, “Using Elixir to Get the Fun Back in Lego Mindstorms”
And, finally, for Steven Proctor’s Elixir Conf 2015 talk, “BEAMing with Joy.”
In my third year of college, I took a Programming Languages course that pretty much defined my career.
The class was broken up into groups of four or five people, and each group had to pick a different programming language to study. (Presumably, we reported on that language back to the rest of the class. I don’t remember, but it’s probably what happened…)
I joined a group that would study Perl. This was 1996/1997. Perl would have been fairly popular at that point, being the tool the web ran on after basic HTML.
I fell in love with Perl. Of course, having previously studied languages like Scheme and C and Pascal, of course Perl would look and sound beautiful. It was powerful and easy to read, with lots of creative opportunities for a programmer.
For Christmas that year, I got the Perl Black Book and a CD with a Linux distribution on it. (I think it was Slackware, the world’s worst version of Linux to attempt to put on a computer for a newbie.) Even after the class was over, I could play with Perl on my own.
Years later, I found an opportunity to insert Perl into some client work I was doing and it quickly became my thing at the company.
Looking back, I don’t remember much else about that programming course, aside from the professor being a temporary prof who put all her notes on one long HTML slide that she’d share with the class… eventually. But I do remember that one of the other languages I could have chosen to study that semester had a ridiculous sounding name.
Part of me looks back now and wonders if I had chosen a different group in that class back in 1996/1997, would I have glommed onto Ruby earlier and been a Rails programmer, instead?
I don’t do any object oriented programming. Crazy, right? But I really don’t at this time.
Sure, there are some Perl modules I use that are OO, and I’ve created one or two that are OO, also, but I can’t claim that my daily duties at work consist of me figuring out whether to inject some dependency or compose some new objects.
Yet I’m fascinated by that stuff, probably because I don’t have to actually deal with it on a daily basis. Theory is easy; practice is hard.
Sandi Metz’s latest talk is awesome. If you’ve read POODR (and you should), you’ll love this. If you haven’t read POODR, you should like this, too.
Fair Warning: Pay close attention. Block off some time to pay attention to this. It’s worth it.
David Cross’ book “Data Munging With Perl” came out in 2001. It’s out of print now, and available in its original PDF form free from its author.
Check out this excerpt from the book’s preface:
Over the last five years there has been an explosion of interest in Perl. This is largely because of the huge boost that Perl received when it was adopted as the de facto language for creating content on the World Wide Web. Perl’s powerful text manipulation facilities made it an obvious choice for writing Common Gateway Interface (CGI) scripts. In the wake of the web’s popularity, Perl has become one of the hottest programming languages current in use.
Unfortunately, a side effect of this association with CGI programming has been the popular misconception that this is Perl’s sole function. Some people even believe that Perl was designed for use in CGI programming. This is clearly wrong as Perl was, in fact, written long before the design of the CGI protocol.
And then today, Justin Weiss posts the answer to the eternal question, “Can you learn Rails before learning Ruby?”
Or how about a more classic variation: Do I need to know Ruby in order to learn Ruby on Rails?
I fear Ruby is going down the Perl path already…