WireWorld » Hacks » Wirehead on Hacking » On screwing around with Ruby and PostgreSQL

On screwing around with Ruby and PostgreSQL

I decided lately that I needed to broaden my horizons a tad. I kept telling myself that I'd teach myself Lisp or Scheme or ML or something. But then, it's always that way, there's always something you know you should do, but don't necessarily want to do because you know that the last time you used any of the functional languages, you weren't happy.

But lately, now that I've got a Linux-based hosting system, I've been thinking that, now that I've got such an awesome server, I should do something with it.

So I've been screwing around with Ruby and PostgreSQL for a project that, if it doesn't end up sucking, I'll be blathering about further.

The way that Ruby had been presented to me, it was Python meets Perl. But, really, it's a powerful gem (heh heh) of a language on it's own merits. Sure, it has built-in support for regular expressions, but there's a lot of other stuff there, too.

One of the things that I've noticed after coding for a long while, is that a "real" programming language really needs to be a meta-language on some level or another. The Lisp gurus will tell you that C++ isn't, but it really is. It can be hacked to give you closures and functional programming and even EBNF, all within the confines of the language.

Ruby is the same sort of thing. Everything, and they mean everything, is an object, with astonishing amounts of exposed machinery to mess with. If you don't like how Ruby looks up methods and variables, say because you want to create a wrapper around a row in a database table, you can write your own lookup function. Methods themselves are objects that you can modify and sling around.

The cool part is that this simplifies the language, while adding plenty of flexibility. Stuff that's ordinarily part of the language is really part of the built-in library. So you can have an object that outwardly looks like a simple structure with a few variables attached, but inside of the object, when you write to some of the variables, it triggers a database update.

So, while it has the guise of a simple scripting language, it's really a powerful language that has all of the stuff that the lisp folks list off when they are telling you why their language is the best.

I've also been screwing around with PostgreSQL. The interesting part is that often times, it gets compared to MySQL, and then folks start making noises about how PostgreSQL is a real robust database, whereas MySQL isn't.

The thing is, PostgreSQL is more than just a real robust database, that offers you the big important features of Oracle or SQL Server or whatnot, it's a unique bit of programming on its own merits.

PostgreSQL is an Object-Relational database. This means that it mostly works like a relational database that can deal with huge datasets that are larger than memory. But that also means that you can define types and indices for those types, so you can have types like "points" or "IP addresses" and the like. Or real transparent support for unix-style encrypted passwords. It means that you can define a table as inheriting from another table (data and definition), so you can better model nodes of different types in a relational table and therefore tackle a variety of problems that are not traditionally able to work with databases.

In a sense, both PostgreSQL and Ruby are two systems in the same model. They both appear to be friendly tools of familiar vintage, but are really nice built-in front-ends over a framework for coding. Very "Pragmatic Programmer"-esque.

I've been going onto the Ruby IRC channel for help understanding the language. The channel was talking about Microsoft .NET. I mentioned the horror that is Hungarian Notation, and it was then revealed that the dude who cooked up Hungarian Notation is now working on Intentional Programming, which then lead to this gem:

eikonos: so... is there an "unintentional programming" ?
cmowire: Yeah, that's when try to code after 4 brewskies and erase the entire CVS tree.

Comments