Rys Sommefeldt

Performance versus ease of development

While learning Ruby recently, I kept reading about certain design choices in the language being made to aid ease of development, with the tradeoff being performance. I’ve never understood why that has to be the case.

The biggest barrier to performance in any piece of software is the cost of creating, mutating and deleting data, structured or otherwise, and there’s very little inherent to any programming language, high level or not, that should help or hinder that.

At some point in the life of any program you’re going to want to do something interesting with data, and that’s where your performance is going to go. If the language’s convenient features for manipulating data cost you performance, the language is broken.

Immutability or extensive mutability, copies, allocs and deallocs, the type system, object model, inheritance, dispatch, polymorphism….none of it has to cost performance in any significantly measurable way.

If it does, the tradeoff isn’t your productivity or ease of development; it’s the language implementer’s.