Monthly Archives: February 2011

Why I love Ruby (Part 1)

So, it occurred to me that so far, my posts (both of them) have been pretty negative. So I thought today, instead of ranting about something I detest, I’d rave about something I love. And that something is Ruby. I looooove Ruby. I got into Ruby because of the Rails web application framework, but my love of Ruby goes so far beyond Rails. Let’s start with a quote from Yukihiro Matsumoto (Matz), the creator of Ruby:

For me, the purpose of life is, at least partly, to have joy. Programmers often feel joy when they can concentrate on the creative side of programming, so Ruby is designed to make programmers happy.

Ruby definitely brings the joy. Oh, does it ever bring joy. Have you ever coded in something like PHP or C++, and felt like you were fighting the language to accomplish your task? This common phenomenon is absolutely absurd. Tools should make the job easier. This bears repeating:

TOOLS SHOULD MAKE THE JOB EASIER!!!

I like tools that make the job easier. This is why I only use Unix-like operating systems, because they have many small, convenient tools that make life infinitely easier. I’ve never understood how people could assert that Unix (or Linux, etc.) isn’t user-friendly. It’s the most user-friendly OS that has ever existed… it’s just selective about who its friends are. But, back to Ruby.

Ruby knows exactly who its friends are: programmers. It’s the most programmer-friendly language I’ve ever worked with. It’s designed from the ground up to operate on the Principle of Least Surprise. What this means is that the irritating gap between what you want the computer to do and what you actually told it to do becomes a lot narrower.

Ruby was also developed slowly, and thoughtfully, from the ground up, using the best-of-the-best from multiple programming paradigms, and from the best-of-breed languages from each of those paradigms:

  • Smalltalk: Smalltalk was the first object-oriented programming language, invented by Alan Kay at Xerox PARC in the late ’70’s and early ’80’s. Ruby draws its pure-OO object model from the language that started it all, and this adds to the joy of object-oriented programmers.
  • Lisp: Probably the first full-fledged functional programming language, Lisp has a storied history of use in academia and the AI community. From Lisp, Ruby inherits its concepts of closures, lambda functions, and tail call optimization, which make it possible to do very function-oriented things in this pure-OO language… I won’t go into the guts of why tail-recursive functions are a Good Thing, or why closures add to programmer joy… but the guy who said “Ruby is like Lisp, but with syntax” wasn’t wrong.
  • Perl: Ruby has less of the Perl-paradigm than it has of the paradigms of Smalltalk and Lisp, but it shares much of the Perl-nature. Ruby has powerful text-processing and regex capabilities which were non-existent before Perl (don’t even bring up sed and awk). It also borrows some rather random things from Perl; Gems follow the CPAN paradigm to a degree, Ruby can handle shell one-liners much like Perl, and Ruby is actually great at most of the system administration tasks that Perl started to make easier in the late ’80’s. Procedural Ruby scripts even tend to look a bit like Perl scripts, but maybe that’s just because so many of them are written by old Perl hackers.

So, Ruby took the best concepts from the best of the best, and worked them into a masterpiece of language design. Compare the evolution of something awful like, oh, I don’t know, PHP.  Jeff Atwood of Coding Horror and Stack Overflow fame puts it rather well:

From what I’ve seen of it, PHP isn’t so much a language as a random collection of arbitrary stuff, a virtual explosion at the keyword and function factory. Bear in mind this is coming from a guy who was weaned on BASIC, a language that gets about as much respect as Rodney Dangerfield. So I am not unfamiliar with the genre.

PHP first emerged as a subset of Perl for embedding code inside of HTML, mostly. Think about that for a minute. Now think about Unobtrusive JavaScript, and the whole thrust of behavioral separation, getting the code OUT of the markup. Surely, we now realize that PHP was misguided from its inception? But this is beside the point. What PHP should demonstrate is that a programming language should evolve programmatically, not organically. PHP was never planned, it was just vomited upon the world as a mass of kludges and spaghetti code.

The development of Ruby was the polar opposite of this. Ruby was planned, designed for the sake of programmer joy. And programmer joy is, IMHO, derived from a few core experiences. I don’t claim this to be a comprehensive list, but some of those include:

  • Not having to re-invent the wheel every damn day: Ruby makes it a breeze to write re-usable code. If you find yourself violating the DRY principle while coding in Ruby, you’re doin’ it wrong.
  • Avoiding repetitive, unnecessary keystrokes: repetitive-stress injuries are an occupational hazard. If a language reduces the number of keystrokes you’re having to enter by an order of magnitude, that’s a Good Thing.
  • Principle of Least Surprise: I mentioned this earlier. Ruby’s core libraries follow class and method naming conventions fairly rigidly, so you know that a method anding in ? is going to return a boolean, and a method ending in ! is going to modify the object in-place. And this principle has been followed quite closely by gem (library) authors. So I know if I call @variable.foo?, it’s going to return true, false, or possibly nil, but not a String or Float or anything else.

This post has outgrown my intentions for it, and there are so many more resons to love Ruby, that I’m going to have to continue this later… look for Part Two soon.

    Advertisements

    Of Kids and Computers

    Something I was reading tonight reminded me of my experiences of what has come to be called “educational technology,” or, basically, computers in schools.

    I was educated in the glorious Baltimore County Public Schools, and computers were a major part of my academic career from the beginning. I think it was in the third grade, when I started getting called to the office on a weekly basis… not because I was in trouble, but because the office LaserWriter was damaged (well, was succumbing to luser error) and no one actually employed by the school could “fix” it.

    My mother was a teacher in the glorious BCPS, so I had more direct involvement with their EdTech department than most students. I knew the admin passwords for most of the software and the “AtEase” interface for Macintosh computers that kept kids out of the OS internals.

    One of the most telling moments came in the 8th grade. I was in the library working on an assignment, and was moving my print jobs to the front of the queue, as was my wont. This involved no passwords or privilege escalation, it was available to any competent user. A new librarian came over and scolded me, saying that the Mac Print Manager was “not for you to use.” I glared, and instantly told the head librarian, also one of the school’s EdTech liaisons… she gave the new librarian quite the dressing-down, right in front of me, telling her basically, “let him do what he likes, or he won’t fix our computers and we’ll have to wait three weeks for someone from the Board of Ed.”

    This was my first experience with the idea that being a geek was something powerful. Sure, I knew I could create new worlds and new vistas of experience through programming but this… I had an ability that other people both valued, and kinda feared. This was power.

    But want I want to get at, is that much like the beancounters who are allowed to make technical decisions in most businesses, most of the people who make technical decisions in education are retarded monkeys. Case in point:

    Toward the end of my K-12 academic career, the glorious BCPS made the shift from Macintosh computers to Windows boxen. I will point out that this was roughly around 2000. Why is this significant? Because up until 2000, the Macintosh was useless to anyone who really wanted to understand anything about computers. At least with a PC, you could drop down to a DOS shell and do something relevant. The Mac had no CLI. But then, there was hope. Apple, fighting for its life, brought back Steve Jobs, the Golden Boy, and bought NeXT, with its UNIX OS, and used NeXTStep as the basis of Macintosh OS X. Now, I’d been using Linux since about 1995 or 1996. This was great news. I thought that now, kids everywhere would be learning how to use a POSIX-compliant OS. Then my mother, the teacher, told me she had bought herself a Dell because they were moving everything to Windows XP boxen.

    FACEPALM.

    Apparently, Apple’s financial troubles, and the pressures of parents who wanted their kids to learn ‘real-world’ computers, had created a new customer base for Microsoft: our local school system. It didn’t matter that this was as retarded as fuck, or that the cracks in Microsoft’s ’emperor’s new clothes’ pseudo-superiority had begun to show… no, some beancounters had made a technical decisions again. And down that road lies madness.

    This isn’t really a rant; just a story. Perhaps a morality play. Beancounters should be allowed to make technical decisions when hell freezes the fuck over. And on that note, one of the best sources of catharsis for harried techies:  The Bastard Operator From Hell Archive


    XML Sucks

    So, since the professed goal of this blog is to talk about software, coding, and related geeky things (I do reserve the right to be completely erratic and off-topic, however), I thought I’d start with a few of the things I’m most opinionated about… starting with something I hate: XML.

    Don’t get me wrong. XML has made it possible for clever people to do some very, very clever things that were much more difficult beforehand. I think the problem is developers who, having become comfortable with their XML hammer, decide that EVERY task involving serialization, data transfer, configuration, etc. is a shiny nail waiting to be beat into submission.

    It’s not.

    If you’ve ever had to support a legacy, vendor-supplied “solution” that has minimal, useless documentation, and found that the only place you can learn anything about what’s happening is by poring through megabytes of XML files that reference other XML files, that reference undocumented crap that was designed by a retarded monkey who learned XML only because he wanted to be employable after the Y2K COBOL rush… yes, this actually happened to me.

    I’m still in counseling.

    Now you’re probably about to comment, “Jason, don’t blame the tool for the incompetence of the one using it.”

    You’re partially right. But I can blame the tool for encouraging the attitude that leads to such incompetence. “XML is eXtensible! We can use it for anything! And why bother validating it, our code parses it just fine.”

    You validate it because several years down the road another coder is going to have to go through it by hand because it won’t parse on anything standards-based. You aren’t a sadist, are you? I mean, you’re obviously a masochist, you voluntarily work with COBOL and XML. But be nice to other programmers, at least. Where’s the solidarity?

    But, I digress.

    Maybe there was a time when alternatives to XML were far and few between. But that time is not now. Now we have YAML, JSON, and many other perfectly good formats for data serialization and configuration. Take the time to make life easier. Ask yourself, what is the simplest thing I can use to get the job done?

    Sometimes, you’ll have to use XML. That’s okay. Sometimes a hammer is the right tool.

    The rest of the time, you look like an idiot, sitting there banging away on screws.


    Hello, World!

    So, I decided it’s time to do a new blog. I haven’t been keeping one up for a couple of years, but now that I’m doing neat things that I want to blog about, I’m starting again. As you may (or may not, if you’re not a Rubyist) have guessed from the blog’s title, this new one is going to be fairly coding-centric, but I’ll probably throw random stuff in here too.

    duck punch game

     

    So anyway… Duck Punching!