Effectiveness, not efficiency
Where to go
When making the distinction between effectiveness and efficiency i like to think of transport.
Efficiency is going fast, like an airplane is much more efficient than a car and that is more so than walking.
Effectiveness on the other hand is how straight your route is. Say you're in Hamburg and want to go to Berlin, then it is not effective to go to Rome first.
Ruby, like python and mother smalltalk, let us be more effective at programming. We accept that they are not efficient, but i think that can be changed.
But even while ruby has blossomed we have seen noticeable increase in effectiveness with so called dsl's and what is generally called meta-programming.
But meta-programming is just a way to say that we manipulate the program just as we manipulate data. Off course! But to do that effectively we need a better model of what an object oriented program actually is.
The way i see it is that it is the understandibility that makes ruby or python more effective. As we read much more code than write (even it's our own), focusing on descriptive programs helps.
But you only have to look at even rubies basic blocks, to see how misleadingly language is used. We use Strings to represent words and text, while we store data in Arrays or Hashes. If you look these up in a dictionary you may find: a thread used for tying, a military force, or a dish of diced meat and vegetables. So we have a way to go there.
But even more disconcerting is that we have no model of how an object oriented system actually works. We know what it does off course, as we programm using it all the time. But how it does it is not clear.
At least not clear in the sense that i could go and read it's code. Ruby like python are written in c and that just is not easily understandable code.
When programming, we fly blind. We have no visual idea of what the system that we write will do and the only way to get feedback is to have the final version run. Bret Victor has put this into words well.
So when we program, it's actually mostly in our head. By playing computer, ie simulating in the head what the computer will do when it runs the programm.
And so what we consider good programmers, are people who are good at playing computer in their head.
But off course we have the computer right there before us. Really the computr should do it rather than us having to simulate it.
What will come out of that line when we actually manage to put it into practise is unclear, though it is certain it will be easier to do and result in hugely more powerful programs
Yet to get there we need better tools. Better tools that let us understand what we are doing better. Better models of what we call programming, and by better i mean easier to understand by normal people (not the computer simluators).