Learning a language vs. learning a culture

[This post is partly recycled from my recent not-really-on-topic entry on the Index Data blog.  Apologies to anyone who’s seen the earlier version.  If that’s you, skip down to ScottKit — my first non-trivial Ruby program, just after the sushi: it’s all  new material from there on.]

Out with the old, in with the new

A month or so ago, it suddenly struck me that I am writing most of my programs in the same language (Perl) that I was using a decade ago. Sure, I’ve learned and used some other languages since then, notably Java and JavaScript, but neither of those has wired itself into my hindbrain the way C did in 1986 and Perl in 2000, so that they spring unbidden to my fingertips when I open a fresh emacs buffer to start a new program. Ten years is a long time to ride the same horse, especially when programming environments are moving so fast, so I decided to make a conscious effort to learn something new. Partly just to keep myself sharp; partly because learning a new language is learning a new way of thinking, which is useful when programming in an old language, too; and partly in the hope that I might find something that is just plain Better than Perl.

The main cast of Buffy

Main cast of Buffy the Vampire Slayer, season 2.  Left to right: Willow, Oz (seated), Giles, Cordelia, Xander, Buffy, Angel, Spike (seated), Drusilla.  I admit this is not realated to my subject, but it does add visual interest.  They say that’s important.

Don’t get me wrong — I like Perl. Obviously I do, or I wouldn’t have been using it as my Language Of Choice for a decade. I like it, but I can’t love it: it’s a language that was not so much designed as congealed, and consequently it encompasses a huge variety of ideas from a huge variety of sources, going back as far as COBOL. The various ideas don’t always sit comfortably on the same conceptual sofa, and there is a certain amount of pushing and shoving. All in all, it’s not a language that you would want to introduce to your mother. Still, these are easy flaws to forgive, because Perl is just so darned useful. I’ve hardly written C at all in those ten years, because Perl is capable enough (and fast enough) to let me do almost everything I used C for in the 1990s. (The last exception was a year or two back when I needed a program that would call setrlimit() to establish a desired environment, then execute a named program. I couldn’t do that in Perl because it seems to have no API to the setrlimit() system call, so I had a nice excuse to write some C.)

Choosing a new language

So I was looking for a new language to learn. Because I wanted something that was fun to work with, bondage-and-discipline languages with masses of compile-time checking were off the agenda; and because I wanted something with a sufficiently well established ecosystem that I could use it for Real Work right off the bat, novelties like Google’s Go were also not the way to go. For well established, widely used dynamic languages, the choice basically came down to Python or Ruby, which now have selections of packaged libraries on a par with Perl’s CPAN.

Both of those were appealing, and I nearly went with Python; but in the end it felt just a bit too familiar — a bit too much like cleaned-up Perl — whereas Ruby felt more like an adventure. So that’s what I went with, and a few weeks on it’s a decision I am really happy about.

How to learn a language? The obvious way these days, I guess, is from online tutorials and videos. But I am a bit old-school in these matters, and I’ve always found that the most effective way for me to learn a totally new technology is from a book — something I can take away from the screen, snuggle under a duvet near an open fire, with a glass of cheap port and a slice of mature cheddar at my side, and read without being continually tempted to Just Check My Mail. Luckily I have an old university friend (Steve Sykes) who is a big Ruby fan, so from him I was able to get a recommendation for what book to buy. Turns out that, just as The Book for C is Kernighan and Ritchie, so there is a The Book for Ruby: Programming Ruby: The Pragmatic Programmer’s Guide (amazon.com, amazon.co.uk), by Dave Thomas. (I went with the version that describes the new 1.9 release of Ruby, which handles character sets correctly, rather than the older and more widespread 1.8).

While Ruby is an imperative object-oriented language, it also uses a lot of functional ideas — in fact Paul Graham has described it as “a dialect of Lisp with syntax”. One of the really neat things about it, which turns out to be trivial but has huge ramifications, is its syntax for closures (or blocks, as they are known in Ruby), which has finally won me over to how great closures are.


Delicious sushi — it’s a feast for ALL the senses.  Er, except hearing.

ScottKit — my first non-trivial Ruby program

By the time I’d read through Programming Ruby, and done a few simple exercises, I had a decent feeling for the language; but of course you never really learn a language until you write a non-trivial program in it.  So I set out to build something tractable but fun, and I came up with ScottKit.  It’s a toolkit for messing with Scott Adams format Adventure games — simple two-word-parser interactive fiction of the kind that was popular in the 1980s and which, for me at least, has never lost its charm.  (Part of the reason for that is that I made and sold such games myself as a young teenager — it was a major rite of passage for me.)

ScottKit was a neat exercise for several reasons:

  • It deals with an existing format, defined and documented, for representing games.
  • It could be built in stages: first, a decompiler for existing games; then a system for playing such games; then a compiler for building games from a source format of my own devising.  Each stage was worthwhile in its own right, so I didn’t have to slog through lots of work before I saw any results.
  • There are quite a few existing games out there, free to download, which it can play and decompile: decompiling is great when you get stuck, because you can see what the rooms and items are and what the actions do.  You can also decompile a game, tweak the source, and recompile the modified version.
  • Games are fun!

So how did the experiment go?

Well, the actual programming was a joy.  Ruby is — I’ve thought about it, and this is the best word — fun.  Of all the languages I’ve ever used, it’s the one that gets in your way least, that allows you to spend the greatest proportion of your time actually solving your problem rather trying to remember whether you need an InstanceFactoryBuilder or an EntityBuilderFactory, or how many $s and @s to use.  (“Never write $a[$i] when you mean ${$a[$i]} or @$a[$i] when you mean @{$a[$i]}.  Those won’t work at all” — the Perl Data Structures Cookbook.)  I don’t see myself writing a lot of Perl in the future, except where mandated by external forces.

Learning the culture

But of course the actual language is only the tip of the iceberg (and finally we come to the actual point of this blog post): where you really face a steep learning curve is, well, everywhere else.  Learning a language is a great start, but to be productive in any meaningful sense you also have to learn the libraries, the testing frameworks, the packaging systems, the build tools, the inline documentation systems, the code-hosting services, the documentation-hosting services, and no doubt a bunch of other stuff that I’ve not got around to yet.  Let’s look at those in turn, and see how they are panning out for Ruby.


One of the nice things about Ruby is that the supplied standard libraries are pretty extensive and cover a lot of the kinds of things you want to do, so you don’t for example have to go and evaluate half a dozen candidate XML libraries before you can start messing with angle-brackets: the no-brainer answer is to use REXML, which comes with the interpreter.  This contrasts nicely with Perl, where the 19,742 modules downloadable from CPAN include FIVE HUNDRED with XML somewhere in their title.  It’s nice not to have to make those choices.

That said, those supplied libraries and built-in classes give you plenty to learn.  I can do basic string processing in Ruby, but the String class has 145 methods — 145!  The Array class has 121.  The Class class has 77.  I doubt anyone ever fully learns these classes, but good Ruby programmers will have the main methods at their fingertips, and it’s a little intimidating to think how it might be before I qualify as a “good Ruby programmer” by that metric.

Ruby comes with a nice packaging system, rubygems, that makes installation of libraries rather easier than in Perl.  It seems to combine features of CPAN, Debian’s dpkg system and apt-get.  So far I am pretty happy with it.  (More on rubygems below.)

Testing frameworks

In the old days, the way to do unit-testing in Ruby was with Test::Unit, which succeeded Lapidary.  In recent years, though, a bunch of alternatives have sprung up, including but not limited to Minitest::Unit, Rspec and Shoulda.  Test::Unit itself seems to be phasing out, but Minitest::Unit includes an emulation for it, and that’s what I went with just because it seems to be the baseline.  It seems to be possible to mix Rspec and Shoulda tests in with (real or emulated) Test::Unit later, if I should need to.

Packaging systems

This, happily, is a decision made long ago: if you want to distribute Ruby code, you do it as a gem.  You just do.  No-one distributes tarballs of Ruby code.  If you want to be part of the community, you have to distribute your code as a gem, too, otherwise people will just shrug and assume you’re some kind of crazy sicko.

As it turns out, that’s a good thing.  The gem packaging system is pretty lightweight, it imposes only a simple canonical directory structure on your code — one that make perfect sense — and leaves you free to add whatever else you might want.  And it’s really nice that anyone, anywhere in the world, who has a working Ruby installation can get ScottKit just by running “gem install scottkit”.

In fact, the gem directory-layout conventions are not quite dictatorial enough for my tastes, which is not something you’ll hear me say often.  I want to add a change-log for my project, and such files are given many different names in different cultures — Changes (Perl projects), NEWS (stuff built using GNU configure), changelog (Debian packaging), Changelog-with-a-capital-C, History, etc.  I was hoping that the standard gem layout would include such a file and mandate a well-defined format, but I wasn’t able to find any such convention.  In the absence of anything better, I picked the name Changes, which is what I use in Perl, and adopted the Perl change-log format.

Build tools

Here’s where things started to get hazy for me.  Being a traditionalist, I’ve always been quite happy with Stu Feldman’s baby, make, and not seen the need for ant and suchlike.  (It’s like a Makefile — but it’s in XML!  So it’s Better!).  I was a bit surprised to find that in the Ruby world it’s much more common to use rake (It’s like make — but it’s written in Ruby!  So it’s Better!)  I strenuously dislike this sort of cultural imperialism in a language — it’s dangerously close to the classic Java-world attitude of flat-out rejecting anything that’s not written in Java.

But I’ve warmed to rake.  Unlike ant, whose whole selling point seems to be that it’s written in Java (a horrible language) and configured in XML (a horrible metalanguage), the point of rake is that the Rakefile is itself a Ruby program — Ruby’s economical and flexible syntax makes this much less intrusive than you might expect.  And this of course means that you have the full power of Ruby to hand in expressing your rules: no need to call out to the shell, quote your quotes and backslash-end your continued lines as we’ve all been doing with make for years.  So far I’ve not really exploited rake beyond the simplest cookie-cutter uses, but it’ll be interesting to see how it bears up as I start to do so.

In Ruby-world, the build tool interacts with how you do packaging, because rake is so darned configurable that people can’t resist extending it with special kinds of tasks that know how to build gems.   And that means you have more choices to make.

The basic approach to building your gem is to write a projectName.gemspec file, which specifies stuff like the name and version of your package, your own name and email address, which files are to be included, and so on.  (The gemspec is itself, naturally, a little Ruby program.)  Then you can run “gem build projectName.gemspec” and if all is well, then projectNameversion.gem will be generated and dumped in the working directory.

But various people have thought that maintaining the gemspec file by hand is too hard, so they’ve made rake extensions that do it for you.  One such is jeweler, which pretty much leaves you to put the gemspec in your Rakefile, embedded in a Jeweler::Tasks block, and fills in some of the fields for you, like the date of release.  To be honest, I am not wholly sure that this gets you a great deal, but that’s what I’m using right now basically because it’s what a friend uses.  Jeweler does other objectionable things, too, like assuming your project is at the top level of its own git module and blowing up if that’s not true (unless you take special precautions).

So I might switch to hoe, yet another rake-extension-that-makes-gemfiles: I’ve only just glanced at it, but it makes a much shorter Rakefile with a much simpler rule, which I think harvests the relevant metadata from the README.txt, Manifest.txt, etc., to make the gemfile.  Looks neater than Jeweler, and also, I notice, expects to see a file History.txt, which looks like it’s my change-log at long last.

Jeweler and hoe are not the only games in town, by the way.  There are plenty of other Grand Unified schemes that various people have come up with, and choosing between them seem pretty much roulette.

Inline documentation systems

Ruby classes and functions can be annotated by special comments which are extracted by rdoc to make automatic documentation, just like javadoc does for Java.  Rdoc seems to have superseded an earlier attempts called rd, and — I thought — had complete control of the Ruby inline documentation ecosystem.  Nuh-uh.  Seems that the world is now moving towards using YARD instead, which is kind of similar in spirit, but more complex (and harder to find documentation for).  Ugh.

Code-hosting services

If you’re getting tired of my listing bunches of alternatives under every heading, you’re not alone.  I will try to be quick, so we can get to the punchline.

When you build a gem, the gem software complains if you’ve not defined a rubyforge_project metadata element — in other words, it just assumes you’re hosting your project on one particular site, which seems extremely presumptuous (I am trying to be polite here).  When you use jeweler to set up a project, it requires that you tell it your username on github.  Which is also, let us say, not the kind of behaviour we like to see.  The upshot is that, because I had my own hosting arrangements already in place, I got whined at by two separate pieces of software that I wasn’t doing it the way they wanted.  Rude, rude, rude.

As it happens, I have — for now at least — moved my git repository onto github.  I’m not sure how that’s working out, for reasons that will become clear in the next (and last!) subsection; I might try moving to rubyforge after all.  There’s also Sourceforge, of course, and Google Code; but they don’t seem to have been taken to hearts of Rubyites in the same way as github has.

Documentation-hosting services

If you look at the home page for, say, Ruby-ZOOM, you’ll see that it has all its rdoc documentation right there on the rugyforge-hosted site.  Very useful.  I’d assumed, or at least hoped, that github would do the same, but it seems that it doesn’t.  (This is the main reason I am thinking of moving to rubyforge.)  I guess this is because github supports projects in any language whereas rubyforge is Ruby-specific.  [Addendum: turns out I was mistaken — rubyforge doesn’t do this for you.  The Ruby-ZOOM authors made their own arrangements to upload the formatted documentation.  Rats.]

There’s a solution, sort of, at http://rdoc.info/ — a site that knows how to pull projects from github, assemble their inline documentation and publish it.  Better still, github can be set up, pretty easily, to tell rdoc.info automatically whenever you push a new commit of your project, and it arranges to have the documentation updated.  It happens quickly, too.  Great, eh?  Well, nearly.  Sadly, rdoc.info has a couple of issues:

  • There doesn’t seem to be a permalink to the pages documenting any of the classes: frames are used, and the URLs of the frames when you manage to get hold of them turns out to have the git commit’s SHA1 hash in them which means they are (A) ugly and (B) not up to date.
  • Worse, despite the domain name, rdoc.info does not use rdoc!  It uses YARD, and that is causing me problems, not just because I’d already set my source up to use rdoc comments, but also because YARD seems to have religious convictions that I am not happy about, such as a commitment that you have to document all your private methods.

I’ve made some steps towards YARDifying the ScottKit source, but I’m currently thinking that’s the wrong thing — I need to find a rdoc.info-like site that really does use rdoc.  Failing that, I’ll have to make my own documentation-build-and-install scripts that push it to a ScottKit area on http://miketaylor.org.uk/, but I really don’t want to go that route.

Veronica Mars, played by Kristin Bell, and her screen father Keith, played by Enrico Colantoni.

What it all means

None of this the fault of Ruby; all the same issues exist for other languages.  I’m gradually coming to the conclusion that they are sort of irreducible: they come with the territory.  For Real Work (as opposed to solving interesting puzzles with Prolog or APL), you need a language that has developed a rich culture over time.  That’s what enables the language to make all the connections it needs to make in order to do the kinds of things we need to do these days.  What it needs, in short, is an ecosystem.  And ecosystems are complicated things.  They are hard to learn.

Could the Ruby culture be simplified?  Well, maybe by fiat.  Maybe Matz could decree that all projects must be generated by jeweler, hosted on github, documented in YARD, and must have unit-test using Shoulda.  It would, in a way, be nice to have those decisions made for me.  But even if the community accepted these diktats, which they wouldn’t, it’s not really what we want.  Languages that grow and develop and succeed are those with rich, competitive ecosystems; constrain it too much and it becomes sterile.  I’m guessing that in three years, some of the issues I’ve had to make decisions about will be much easier: Darwin will take care of the weaker approaches, and the stronger will survive.  That’s how we got the point of Ruby being as good as it is, after all — and by “good” I don’t just mean “elegant” or “fun to use”, but “capable of doing large-scale stuff using many different libraries available from and documented on well-known community sites”.

In short: when you learn a programming language — a real, grown-up one rather than a novelty — you have to learn the culture that goes with it.  You just do.  And it’s time-consuming and frustrating and feels like a waste of time, and yields up very few of those satisfying Aha! moments.  It’s only gradually, having waded through these fertile but sometime smelly swamps for a few weeks’ evenings, that its all starting to swim into focus and make some kind of sense.  I think I am getting there with Ruby culture; hopefully ScottKit will be properly published and available soon, and I’ll have found a combination of test frameworks, inline documentation conventions and so on that works for me.

Ask me again in a few weeks, and I’ll tell you how it went.

And ask me in twenty years and I’ll let you know whether I’ve made an progress in penetrating Java culture.


By the way, ScottKit is not really ready to use yet, even though I released it as a gem already.  (That was mostly so that I could easily install it on the boys’ computer upstairs and they could get going building their own games.)  The big gap is the documentation for the source language — it doesn’t really exist.  I’ll try to fix that in the next day or so; I’ll post about ScottKit when it’s ready for the attention.

34 responses to “Learning a language vs. learning a culture

  1. Interesting.. You need to build a ruby GLK library to bind to scottkit! Boo for chosing TRS80 format (ok ok I did the TI99 interp/decompiler/new compiler)… so I like TI99 format over TRS80 format (multiple try blocks!).

    I don’t recall buckaroo banzai being buggy like you say it is but its been a while.

    Glad you like the ruby ecosystem, I have not converted over to 1.9 yet (I’m in the process).

    I mostly hear people wish rubygems was more like CPAN (which I dont particuarly like myself).

  2. Hi, Stu, good to hear from you. I’d not heard of Glk before, but it looks like a useful thing to do — instructive, too, since it’ll be my first project to make a Ruby extension in C. As it happens, I’d been intending to abstract ScottKit’s game-playing I/O into a “driver” obejct, then make a Dumb Terminal driver that behaves like the current version, a Curses driver that behaves more like ScottKit, and maybe some kind of X11 driver (hadn’t thought about which toolkit to use yet). But if I can use some existing generic Glk server instead, that will be much better. So thanks for the pointer!

    The most recent version of GLKX I’ve been able to find is 0.4.11, which seems to be eleven years old — am I missing something obvious?

    I’ve never seen or used the TI99 format, but have a long history with the TRS-80 format — seethe Games::ScottAdams Perl module — so I didn’t give alternative formats any thought. Maybe I should have done. What’s a “try block” in the context of a Scott Adams game?

    Buckaroo Banzai: I’ve not tried playing it, so I don’t know what other bugs it harbours, but when loading it in order to play or decompile, I found that an item location is out of range. Maybe not a big deal if all you want to do is play the game; but if you decompile, you need to make up a name for the non-existent room.

    I’m actually finding it a bit awkward to use Ruby 1.9, not because of anything wrong with the language but because I have to remember to keep typing ruby1.9, rake1.9, gem1.9, etc. Seems there’s no update-alternatives ruby (at least, not on Ubuntu 8.10).

  3. Aaah I didn’t realise you wrote the old perl module, which makes sense you stuck with the TRS80 format.

    Here is an example of TI99 scott adams source

    I ported the classic lost dutchmans mine to it. You can grab the bunyon interp from the if archve and the ti99 format scott games to decompile them if you like and compare it vs the trs80 format.

    If you understand the TRS80 command format you will immediately recognise the TI99 format.

    GLK has been around since about 98? and has not changed, so the X implementation is fine last I checked,. You might be more interested in GTK GLK, but last I looked it needed a couple of tweaks to run.

    If you want, send me an email and I can send you the buckaroo banzai TI99 source file (decompiled) and you can compare against the TRS80 version and see if the same item is in the same room.

    if you get my bunyon interp from the ifarchive it has games 1-12 source in it. I have the last 4 games not in the archive tho (hulk, spidermane, claymorgue, buckaroo… fantastic four never made it to the TI99 format).

    As for ruby19, gem19 etc yeah its a pain, I build my own 1.9 interp into /opt and run it alongside the default 1.8 install on ubuntu. Any time I install gems, I have to edit the gem script to point to ruby19 otherwise it points to ruby which run sdefault 1.8 which is a pain. I find it easer to do this tho than try and setup alternatives.

  4. You mentioned fun.

    I think you forget one other reason:

    Ruby is beautiful.

    For me, after 6 years, this is still the reason I use ruby. It’s really strange!

  5. Wait, is that TI99 format the game’s object-code, that the interpreter runs? Or is it source-code that you compile into something for the interpreter? Because if it’s the object-code, then that’s one high-level object-code, and I can see why you prefer it to the horrible TRS-80 format! (It’s also frighteningly similar to ScottKit’s source format, but I suppose there are only so many ways you can do these things.)

    GTK GLK might be a better bet — so long as it runs on both Ubuntu GNU/Linux and MacOS.

    I’ve never seen Fantastic Four in any format — if you know where it’s to be had, do let me know!

  6. Hi Mike, no thats the TI99 scott adams compiler source. Its runtime is pure binary bytecodes as opposed to the TRS80 text format.

    I have fantastic four in its original SAGA interpreter for dos (

    c64 version of FF here http://www.c64gg.com/Adams_Scott_DL.html

    run it in vice.

  7. I’ve been nibbling around learning Ruby/Python myself so I got to this article.

    As for packaging issues, have you run into any problems with Monkey Patching/Duck Punching?


  8. I’ve not yet used Ruby enough to have built up a sense of how problematic duck-punch abuse is; but I’ve used similar techniques myself in Perl (for example, to add a new capability to a set of tree-node classes) and I know it can be done cleanly and well. Which is why I say that duck-punch abuse rather than duck-punching per se is the problem. (The same is true of many other techniques, of course.)

    I think the key observation in the article that you linked is: “This is just going to get worse if we don’t do something about it. And the “something” is going to have to be a cultural shift, not a technical fix,” Spot on. Maybe duck-punching is too new a technique to have evolved a set of best practices yet, however informally, and it might take a while before that happens.

    I’ll offer one (rather obvious) candidate guideline: when writing an application, feel free to duck-punch; when writing a library for the use of others, be more cautious.

    And here is another, even more obvious: when duck-punching a library, add new functionality in new methods rather than modifying the behaviour of existing methods.

  9. Pingback: Whatever happened to programming, redux: it may not be as bad as all that « The Reinvigorated Programmer

  10. “so you don’t for example have to go and evaluate half a dozen candidate XML libraries before you can start messing with angle-brackets: the no-brainer answer is to use REXML,”

    While in general I think your point is true, this is a funny example because it’s so NOT true. REXML is known to be kind of truly awful in the performance department, and nobody should use it. Instead you have your choice of about a half dozen XML parsing frameworks, oops.

  11. Er, yes — rats, would it be cheating if I went back and changed the article now? :-)

  12. “Which is why I say that duck-punch abuse rather than duck-punching per se is the problem. ”

    Sure, as he pointed out Emacs has the same capability without the abuse but I believe that was a different (more homogeneous) World than now.

    It’s an old enough article I wonder if there’s been any observable progress (good or bad) since then.

  13. Should have gone with Python! :D

  14. Adam Ingram-Goble

    I’m really enjoying this series of articles you’re writing recently. I’m a game designer/computer & learning scientist, and the recent explosion of discussions like this is really great to see. My direct focus is on building programming learning platforms that broaden the participation of youth in programming and design culture, so this post was a great example, in my mind, of convergence of the world of practice and academic thinking in learning. Thanks!

    Just a quick comment. Rather than using OS packaged rubies, you might want to look into using just using the os base install to install rvm, and then have access to a compiled from source, easily switched set of ruby interpreters. http://rvm.beginrescueend.com/ This can make playing with things like 1.8 vs. 1.9 vs. jruby vs. rubinius much more pleasant.

  15. @Mike awesome article. You’ve made it through a book that I’m currently in the middle of (and I’ve been using Ruby and Rails for nearly two years now!)

    @Stu & Mike +1 to Adam regarding RVM. It’s an awesome tool and is the way I’m working on switching from 1.8 to 1.9 easily myself. I highly recommend it.

  16. PS – Welcome to the Ruby community. I’ve found it’s by far the nicest group of developers I’ve come across in the different ecosystems I’ve been in (the opposite of you it seems, I come from the improperly self-taught Perl/PHP/Python side of things). Ruby and Rails are where I have finally started to learn some proper coding techniques and best-practices (probably in part due to how opinionated Rails can be about the “right” way – mostly going away in Rails 3.0 FYI).

  17. Enjoyed “Whatever Happened,” then came back to here. I just wrote a mini-Make in Python for no good reason two days ago, it’s funny you mention both starting from scratch in the next post and Stu Feldman and good old Make in this one.


    I just… included the source code inline in the web page, I hope you wont “just shrug and assume [I’m] some kind of crazy sicko.” Actually I’m transitioning from learning Python to learning the culture, thanks for giving a name to that.

  18. Xiong Chiamiov

    I find that http://www.ruby-toolbox.com/ is useful when I’m looking to determine what library to use for something, for instance, xml parsing.

  19. Hey Mike, great article, thanks. Regarding your problem with having to remember to type ‘ruby1.9’ I recommend that you install RVM, which manages multiple Ruby installations for you. The nice thing about it you can invoke RVM to select 1.8 in one shell, and use 1.9 in another. It manages all your Ruby binaries and gem repos for you, so you no longer have to remember to type in ‘gem1.9’, ‘ruby1.9’ et al.

    ‘gem install rvm’ – go do it now! :)


  20. Thanks, Jacques — you are the third person to independently recommend RVM, and that is the recommendation threshhold. I’ll get right onto it :-)

  21. Pingback: Closer To The Ideal » Blog Archive » Learning a language means learning the culture

  22. Pingback: What is “simplicity” in programming?, redux « The Reinvigorated Programmer

  23. Pingback: Early experiments with JRuby « The Reinvigorated Programmer

  24. Pingback: Frameworks and leaky abstractions « The Reinvigorated Programmer

  25. +1 for a more consistent name for the change log file. There’s way too many. Luckily Debian enforces it’s own standard (Debian.changelog.gz), and GNOME recommends both NEWS and ChangeLog.

  26. Congrats on learning a new language. Sharpening the saw. Hope you learn some new tricks and viewpoints.

    Your intro-to-ruby project was reimplementing a perl project you last updated in late 2006. One would hope that reimplementing in a new language would lead to improvements — second system effect, you’re a more mature programmer, etc.

    Do you have an example of something you’ve written freshly in ruby that you can try rewriting in perl ( maybe in the “modern perl” dialect the kids are all talking about these days ). Would you find it fun and elegant or still just a “capable enough and fast enough” replacement for C?

    ps. If you come across another need to setrlimit in perl, you may find the BSD::Resource module handy, depending on your needs.

    pps. re CPAN, personally I love that I can read the documentation, browse the code and see the unit tests all before I download. Code browsing! And we really don’t care where you develop your code, I like to use github for RCS and Dist::Zilla as my packager, but there’s more than one way to do it.


  27. Yes, CPAN is outstanding, and RubyForge is not as convenient to use. I tend to use my own git repo rather than one of the public ones, but there is not compelling reason for that beyond habit.

  28. Nobody uses rubyforge anymore, the ruby community has largely moved to github.

  29. Right, but that same applies — it’s nowhere near as nice to browse as http://search.cpan.org/ — positively hostile, in fact.

  30. Well, the searching stuff is done through gemcutter, right? Still not quite as extensive as CPAN, but better than searching all sorts of stuff on Github.

  31. Pingback: My plan for 2012: do things that children do | The Reinvigorated Programmer

  32. Pingback: Random thoughts on programming, culture and such | Scali's OpenBlog™

  33. Luiz Felipe

    I like sushi sound when I squish it.

  34. Pingback: Scottkit is born! Only seven and a half years late! | The Reinvigorated Programmer

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.