62 lines
3.3 KiB
Plaintext
62 lines
3.3 KiB
Plaintext
|
\---
|
||
|
|
layout: project
|
||
|
|
title: Effectiveness, not efficiency
|
||
|
|
sub-title: By way of a new look at programming.
|
||
|
|
\---
|
||
|
|
.row
|
||
|
|
.tripple
|
||
|
|
%h2.center Where to go
|
||
|
|
%p
|
||
|
|
When making the distinction between effectiveness and efficiency i like to think of transport.
|
||
|
|
%p
|
||
|
|
Efficiency is going fast, like an airplane is much more efficient than a car and that is more so than walking.
|
||
|
|
%p
|
||
|
|
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.
|
||
|
|
%p
|
||
|
|
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.
|
||
|
|
%p
|
||
|
|
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.
|
||
|
|
%p
|
||
|
|
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.
|
||
|
|
.tripple
|
||
|
|
%h2.center Understandability
|
||
|
|
%p
|
||
|
|
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.
|
||
|
|
%p
|
||
|
|
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.
|
||
|
|
%p
|
||
|
|
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.
|
||
|
|
%p
|
||
|
|
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.
|
||
|
|
.tripple
|
||
|
|
%h2.center Playing computer
|
||
|
|
%p
|
||
|
|
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
|
||
|
|
= succeed "." do
|
||
|
|
%a{:href => "http://vimeo.com/36579366"} into words well
|
||
|
|
%p
|
||
|
|
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.
|
||
|
|
%p
|
||
|
|
And so what we consider good programmers, are people who are good at playing computer in their head.
|
||
|
|
%p
|
||
|
|
But off course we have the computer right there before us. Really the computr should do it rather than
|
||
|
|
us having to simulate it.
|
||
|
|
%p
|
||
|
|
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
|
||
|
|
%p
|
||
|
|
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).
|