The end of RDMBS is near! This isn’t another ORM rant, but let me be honest: I don’t like relational databases and I can’t wait for the day when I don’t have to read another query. RDBMS don’t fit our model of computing.

Working with the object oriented paradigm you quickly realize that your objects don’t fit in relational databases—they’re square pegs and your database is a round hole. RDBMS came before object oriented programming, before the web; our requirements have changed since the 70’s. So we’ve invented pretty toys like Active Record and NHibernate to fit our square pegs into databases but in the end they’re kludges, elegant kludges because we’re still stuck with RDBMS.

In 2008, how do we use databases? I bet most of us use them to only store data? For many of our applications we need key lookups, easy scalability, ability to store massive amounts of data and none of the other overhead that is associated with administration. Enter Document Oriented Databases– Imagine giant hash tables floating in the sky, no schemas or tables. No fixed data types, just keys and data. CouchDB and Amazon’s SimpleDB are two such database systems, which happen to be built in Erlang. You can read more about CouchDB, but the important thing to know is that it’s a distributed database system which works well for semi-structured data.

Now imagine this Reduce(Map(F(CouchDB)) and Bam! If you think I’m doing a lot of hand waving here, I am, but look at Google, what makes their infrastructure so scalable? How does Google achieve their massive scalability? BigTable and Map/Reduce! Document oriented Databases and Map/Reduce are changing the way we look at scaling and Map/Reduce is quickly becoming the essence of scalable high-performance computing (and the end to RDMBSs).

There’s a lot more to this, where it’s headed I’m not sure, but it’s making my spidey sense tingle. There are other closely related topics that should be explored, column oriented database and Hadoop, but that’s for later, I need to breathe.

If you’ve talked computers with me you know of my extreme fondness for Ruby, so you should be surprised to know that I’m trying to learn Erlang! I want to use Ruby as my full-time programming language but my job requires that I program in C# or C/AL; I don’t see any Ruby (sans Rails) opportunities in the near future, plus, I can’t find a good programming book on Ruby locally, so I decided to give Ruby a break and just have fun with a new language.

While I’ve done some Lisp programming in school but I’ve always felt that I was missing out by not knowing any functional languages. I considered F# briefly but it didn’t excite me at all, beyond the functional paradigm F# doesn’t add anything new, it doesn’t make it easier to solve another class of problems.

Why Erlang?  Erlang lets me solve problems differently. It has concurrency built into its DNA—it’s ideal for building fault-tolerant systems, it also supports hot swappable code and it’s functional programming language.

I wish I had it 6 years ago.  The old system I worked on was a built on C/C++; if you’ve done worked with pthreads you know how painful it can be to debug a multi-threaded program. Creating a performant and fault-tolerant system is immensely challenging and I was constantly fighting the language, not to mention that I had to come in to work at 5:30 AM to update the system with the latest code. If I could go back in time I would build the server layer in Erlang.

I’ve spent 3 weeks trying to learn Erlang and it has been really fun, functional programming is completely new to me and I feel extremely uncomfortable doing it, but when I look at what I’ve done and realize that it only took half the lines it would normally take to solve the problem I can’t help but laugh.