I was mouthing off in #erlang last night about OOP and I wanted to summarize some of the conclusions that I came too about why object orientation has become so huge while functional programming has remained relatively unused by comparison.

First, it should be noted that I am by no means an erlang expert, I just started learning, but I’ve been programming plenty long enough to understand why object orientation has become as popular as it is. In fact maybe the title should be “Concurrency Oriented Programming is harder…”, or “Why Object Oriented Programming is more popular…”.

Objects map better to real life

Joe Armstrong’s book claims something to the effect of “we live in a concurrent world”, which is true, but learning to deal with that in the context of code execution is very difficult (with varying degrees depending on the language, this is one of erlang’s obvious strengths). When you’re sitting in CS 101 and they give you the mammal, dog, cat example:

it makes a lot of sense. Both the Dog and the Cat are mammals, and all those things that ALL mammals do/have (LiveBirth, Fur) should be done/had by both a dog and a cat, right? Right. This might get tougher to keep strait when you’re working with very abstract business objects but that’s rare, and otherwise object orientation is VERY INTUITIVE.

Human beings are born with the ability to find commonality between actions/objects and it maps well for programming. It’s how you learned to talk. Your mother said the same thing 15 times while pointing to the zucchini, so you noticed that the common elements were that green thing on the counter, the noise of the word zucchini issuing from your mother’s gob, and the shapes she made with her mouth to create said noise.

In short, object orientation opened computer programming to a broader audience. It gave people confidence that, if they could just determine the objects present for a given problem, they could eventually work out how they all fit together, and get them to do the things they want.

OOP has _definable_ elegance

I will be the first to say that functional programing languages can create amazingly elegant applications. They empower you to be clever with the tools provided such that you can write very complex code with relatively little typing. Saying that OOP languages have definable elegance doesn’t mean that FP languages don’t have elegance at all.

But, I have yet to find a blog, book, or article that defines best practice for FP in the same concrete terms that you hear when someone references OOP. Even simple things like, using interfaces as contracts for what a class will be expected to do/be, and leveraging polymorphism to perform operations on objects with a common parent, represent definable ways to improve code. “Oh I don’t have to write two methods to have a collection of Cats and Dogs perform a LiveBirth because I can just treat them as mammals”.

This has two effects that I can see:

1. Teachers can point out mistakes to students, which makes teaching object orientation nice and easy.
2. People can say, look how good my code is, and we have rules by which we can all evaluate the validity of their statement.

The first could be said of functional programming to an extent. For erlang, it might sound something like, “if you use a list comprehension there, it will be one line as opposed to a whole separate function”. So you can offer ways for people to do things that will be better, possibly more elegant, but not with the same clarity as telling someone “You’ve written two classes that are nearly the same here, with a lot of code duplication, there must be some parent object from which they can both be descendants”.

I think the second is the most important though. Just as human beings are very good at finding commonality, human beings LOVE to be right. Being able to say: “I’m right because of X, Y, and Z” is a huge shot for you ego, and if getting it right just means mapping objects to code, programmers are going to be happy.

Good programmers gravitate towards FP constructs

That one might piss someone off. Let me be clear though: that doesn’t mean that people who use object oriented languages are bad programmers. Not at all. It just means that the things the FP languages have and will let you do are awesome enough include in some OOP languages.

Take Ruby for example. Ruby’s popularity has exploded because good hackers love the language and have done crazy things with it (see Rails). And some of the things that hackers love most? lambdas, blocks, multiple assignment. Even C# has jumped on the lambda boat. These things make for elegant, _concise_ code, which is pleasing to the hacker’s eye.

At this point, you might ask yourself “Then why don’t all the best hackers just work with FP languages?”, and the answer is two fold. First, as I mentioned above, mass appeal. More people can work with Rails because Ruby is object oriented, and everyone wants to be a celebrity who’s identity can be discerned from an acronym consisting of 3 letters, so they will build their framework with OOP. Second, and most importantly, because some problems sets map well to objects. A lot, maybe even most, of them do.

But some don’t, such as massively concurrent programs.

I think the claim that erlang will be the next java/c#/ruby/anything doesn’t make much sense. Not everyone can use functional programming languages, and more importantly not everyone should. It depends on what you are trying to do. Take web frameworks like erlyweb. It looks to me like erlang might not be that great for the web, and even if it is pretty awesome, you’re going to be hard pressed to find people with the ability to learn it as easily as Ruby and its stack Rails.

Let me know what you think in the comments.

This is why I love Rails:

In the commit you’ll notice that there are two files that got changed. The output for the Textile, and adding the gem to the environment.rb. Other than that all I had to do was install the gem in both dev and production, and unpack it in production.

This is certainly a short post, but I have to say that when you’ve used Rails enough to know exactly what to do in a given situation, that “todo” ends up being a very light undertaking.

Make no mistake, Rails is the framework of the future.

So I think that my event tracking system happenings is pretty nice. Nice enough that people might want to use it for their projects. The question that I’m trying to answer is: can I roll this in to a gem so I get all the package management niceness (Dependencies, etc) that goes along with gems, or do I need to create a plugin with generators and such?

From what I’ve read, views are the main sticking point. It _seems_ like I could just create my Controller and Model classes and force the user to inherit from them, but what about the Views? This sounds like a job for a generator, which I am loath to create, but laziness will be the death of this little piece of code.

Hopefully I can get off my duff and get this done. I’ll post back soon when I come to a decision.

As promised I submitted my ym4r google maps rails plugin patch. That’s pretty much the first patch I’ve ever submitted for anything, so here’s hoping they don’t come back and lambast me for my ridiculously stupid idea.

If you look at the diff its around 5 lines but I thought it was a pretty nice little extra. I just added a :function option that lets you specify a function that you can call in javascript client side to actually render the map instead of the the default window.onload or automatic. Here’s what using the option looks like

and this renders as the following in the page

Meaning you can just call it whenever you would like.

I added this in because I was loading 5 - 10 map divs per page and they were display=none, so it didn’t make sense to send the call to Google for the map unless the user wanted to view the hidden map. Here’s hoping they except the patch!

So I finally got myself into a project I couldn’t get out of and I hacked together an event tracking system I dubbed, happenings.

As it stands now its a rails project by itself, but I would like to create a gem or plugin so that the models can easily be used by others. Some of the highlights are:

• Google maps (ym4r)
• Google geocode
• Desktop calendar client events (.vcs)
• Events, Addresses, Users, and Roles as seperate Models

That will all stay there if I ever get around to making a gem out of it but for the completed project, I also worked with:

• jQuery (effects)
• Prototype (calendar select)
• restful_authentication

It has some nice animations and I’m probably going to submit a patch to ym4r to add the :function option to the map.to_html method. Basically it let me assign a function call to the map service call so I could call it only when it was unhidden by some jquery niceness:

All and all very fun things. Next step since no one ever reads this blog is to unleash my master plan of an Mnesia webservice backend and datamapper adapter. MWAAHAHA!

I’ll post the code for happenings soon.

Just picked up the beta third edition of this awesome book tonight and I was thoroughly enjoying even the beginning chapters. I really love the way these books have been written and my hat is most certainly off to the Sam, Dave, and David (we’re not on a first name basis but if you’re into rails you know who I’m talking about).

After reading the first couple of chapters, I jumped forward to migrations as I was having trouble recently when hacking about with an app that my good friend Malcolm and I have been working on together. After a page of explanation _all_ my questions had been answered.

It’s not only exciting to get this book because it’s such and awesome reference but because I have been wanting to get back to working with rails for a while now. Sorry to gush like a little school girl but you should go buy the pdf now if you are _at_all_ interested in developing with RoR.

happy hacking!

I started this project a long time ago to learn Ruby and never got around to making it really useful. Well I just resurrected it and I think it could be useful for people working with C.

Basically it just does all the dirty work of taking your C methods and making them available for Ruby via a bundle file. The next step is to build out a Ruby unit test script with stubs for each of the methods in the bundle, thus making it very easy to unit test your C code.

Check it out here.