I consider myself to be lucky to have been introduced to computers at a young age. I forget now exactly when it was, but I certainly remember the first "taste" I had for computers and programming. It involved a Hewlett-Packard 85 and Hewlett Packard Series 80 BASIC. I was hooked, and pretty-much remained so indefinitely, although technology, has, of course, moved on substantially since then.

Recently, for various reasons, I've experienced a resurgence in my interest for programming, fueled by a joy similar to that experienced in those early days. It's a sort of excitement and wonder, happiness, I think ... linked to the freedom that comes with being able to make ones thoughts reality - the joy of the creator, I guess.

With "coder's flow" (something akin to writer's flow), there are inevitable periods of coder's block. Perhaps that isn't quite the right term, but it's that ugh.. feeling when things just aren't "jelling", typically characterised by a lot of typing and editing without a corresponding sense of achievement. Distilling the circumstances that tend to surround such times:

• The language seems inconsistent, difficult-to-remember and unintuitive (AutoHotkey script, anyone?);
• Becoming familiar with edge-cases in the language and/or tool-chain is a laborious process; in this case, having to "break out" to a Google search, as uncannily clever as Google has become, is still on the uncomfortable side of the latency spectrum for me;
• Really good parts of a tool-chain (I'm thinking JetBrains Resharper in the .NET ecosystem now) tend to keep you chained (if you'll excuse the pun) to the ecosystem, even if the language has a relatively large amount of attendant ceremony (C#, yes, even the latest version).
• An area of an ecosystem where there either:
  • Is poor support (either native, or through third-party libaries) for an infrastructural necessity (e.g., object-relational mapping);
  • The support is there, but the learning curve is orthogonal, at least if one wants to understand things beyond the superficial (EF, Hibernate).

In my case, the project I've been tinkering on requires persistence of data in some structured form, so the last item applies. In decades gone by, the conclusion would be "use a (relational) database" without any possibility of there being an alternative, despite the significant ceremony involved in getting the simplest thing to work with ye classic imperative programming language. Tooling was a lot less mature then, but even now, that seems to be the goto "means of persisting structured data", despite the availability of many NoSQL options. I guess what's familiar gets the most attention, right? In any case, it's still a pain ... and I don't want to have to spend weeks learning a framework, thank you.

This brings me back to an Ask HN item I read recently, that is: What books had the greatest effect on how you structure your code?, and an answer that lead me to Ruby's Matz's overriding programmer's mantra, namely: ".. a language should be designed to make programmers happy ..". With the amount of "grind work" I've been experiencing in merely getting a couple of tables populated and extracting data from them (no, I don't wish to use Entity Framework), being "made happy" by a language/tool-chain is an overpowering temptation, despite the implications of having to shed the incumbent ecosystem.

Some years ago I dabbled with Ruby and was delighted by the combination of simplicity, power and familiarity provided (familiar since many idioms have been borrowed from Perl, Awk and the Unix command-line, all-of-which I've loved in the past).

My interests would appear to be best served then by pursuing that which has a solid ideological foundation in harmony with my own belief system as opposed to "chasing the wind" with the immediate (but, ultimately unsatisfying) returns of a polished commercial tool. Ruby Koans, here I come.