Moore's Switch, and the future of programming
Researcher at CWI in Amsterdam (first non-military internet site in Europe - 1988, whole of Europe connected to USA with 64kb link!)
Co-designed the programming language ABC, that was later used as the basis for Python.
Wrote part of GCC.
At the end of the 80's built a system that you would now call a browser.
Organised 2 workshops at the first Web conference in 1994.
Chaired HTML WG for the best part of a decade.
Co-author of HTML4, CSS, XHTML, XForms, RDFa, etc.
I should say, when we were developing ABC in the early 80's, we were considered crazy, because it was an interpreted language.
However, we knew about Moore's Law.
We were trying to design a programming language more based on the programmer's needs.
And despite it being interpreted, because of this sometimes it still ran faster than equivalent compiled programs.
You may have heard of this, from Nicholas Negroponte in his book "Being Digital":
Everything that used to go over cables, now goes over the air.
Everything that used to go over the air, now goes over cables.
In the 50's, computers cost in the millions. Nearly no one bought them, nearly everyone leased them.
To rent time on a computer then would cost you of the order of $1000 per hour: several times the annual salary of a programmer!
When you leased a computer in those days, you would get programmers for free to go with it. Programmers were essentially free (in comparison with the cost of the computer).
Nowadays it is exactly the reverse. Computers are essentially free. With a programmer maybe costing 100k a year, using a computer that costs €1000 spread over 3 years, it is the programmers who are expensive.
In the 50's the
computer's time was expensive.
So a programmer would write the program, copy it to special paper, give it to a typist, who would type it out, then give the result to another typist who would then type it out again to verify that it had been typed correctly the first time.
Why all this extra work? Because it was much cheaper to let 3 people do this work, than to let the computer discover the errors for you.
And so programming languages were designed around the needs of the computer, not the programmer. It was much cheaper to let the programmer spend lots of time producing a program than to let the computer do some of the work for you.
Programming languages were designed so that you tell the computer exactly what to do, in its terms, not what you want to achieve in yours.
Last year Moore's Law turned 50
years old.
Or less prosaically: Moore's Law was 33⅓ iterations of itself old.
The first time I head that Moore's Law was nearly at an end was in 1977. From no less than Grace Hopper, at Manchester University.
Since then I have heard many times that it was close to its end, or even has already ended. There was a burst of such claims last year, which caused a wag to tweet
"The number of press articles speculating the end of Moore's Law doubles every eighteen months."
As an excellent example, in February
last year, almost exactly three years after the announcement of the first
version, version 2 of the Raspberry Pi computer was announced.
Since three years is exactly two cycles of Moore's Law, does the new Raspberry Pi deliver a four-fold improvement?
So Moore's Law has been doing its work, and computers
have been getting exponentially faster.
In 1988 my laptop had a power of 800. My present one has a power of more than 25M. That is 15 doublings!
Since the 50's, computers have become incredibly cheap and powerful, and yet we are still programming them with programming languages that were designed to save the computer work.
In fact most computers spend most of their time idle. Here is my computer as I write these slides. The bump at the end is caused by taking the screen shot.
What we need to do is take the load off the programmer, and put more of it on the computer. Use some of that spare power!
By the 1970's computers had become two orders of magnitude cheaper, and programmers hadn't: the cost of software was starting to hurt. The term "software crisis" was even coined.
The American DoD did some research and discovered that 90% of the cost of software production was in debugging.
Interestingly, Fred Brookes in his book "The Mythical Man Month" reported that the number of bugs in a program is not linear with the length of a program but a power function:
b ∝ l1.5
This means if a program is ten times as long, it has 30 times as many bugs, which means it costs 30 times as much to make.
Conversely, a program that is 10 times smaller costs 3% of the larger program.
This is a graph of the relative program size (blue line) versus the relative number of bugs to be expected in a program of the size (the red line).
Alternatively, the red line represents the relative cost of producing a program of that size.
Since the 1950's computers have become more than 11 trillion times faster (11 million million).
In that time, programmers have become 10, maybe 100, times more productive.
This needs to be improved!
A program that you now would write in a week, you could write in a morning.
A program that now would take a month you could write in two days.
A program that would take a year to write, you could produce in a month.
Is this achievable? And if so, how?
We learn in school what numbers are, and how to add, subtract, multiply and divide.
However, when we get to square roots, we are only told:
The square root of a number n is the number r such that r × r = n.
This is a declarative definition. It tells you what something is, it tells you how to recognise it, but it doesn't tell you how to calculate it.
Most people know what a square root is, few people leave school knowing how to calculate one.
So take a look at a procedural definition of square root:
function f a:
{
x ← a
x' ← (a + 1) ÷ 2
eps ← 1.19209290e-07
while abs(x − x') > eps × x:
{
x ← x'
x' ← ((a ÷ x') + x') ÷ 2
}
return x'
}
| Declarative | Procedural |
| root(n)= r such that r × r = n. | function f a:
{
x ← a
x' ← (a + 1) ÷ 2
eps ← 1.19209290e-07
while abs(x − x') > eps × x:
{
x ← x'
x' ← ((a ÷ x') + x') ÷ 2
}
return x'
}
|
1000 lines, almost all of it administrative. Only 2 or 3 lines have anything to do with telling the time.
And this was the smallest example I could find. The largest was more than 4000 lines.
type clock = (h, m, s) displayed as circled(combined(hhand; mhand; shand; decor)) shand = line(slength) rotated (s × 6) mhand = line(mlength) rotated (m × 6) hhand = line(hlength) rotated (h × 30 + m ÷ 2) decor = ... slength = ... ... clock c c.s = system:seconds mod 60 c.m = (system:seconds div 60) mod 60 c.h = (system:seconds div 3600) mod 24
One technology that is going in the right direction is XForms, a W3C standard, originally only for forms (as the name suggests), but now also for more general applications.
Using it, you specify what you are trying to achieve and not how to achieve it, and so there is far less administration to worry about in programs. This means: shorter programs.
zoom: 10
x: 33530568
y: 22315225
site: "http://tile.openstreetmap.org/"
maxzoom: 18
tilesize: 8 {Tiles are 8×8}
scale: 2 ** (tilesize + maxzoom - zoom)
tilex: x ÷ scale
tiley: y ÷ scale
url: site+zoom+"/"+tilex+"/"+tiley+".png"
The rest is just detail, although you could say that the fact you have to calculate tilex and tiley yourself is a short-coming of the openstreetmap REST API.
So changing from a regular map to a cycle map for instance is just a question of changing the value of 'site'.
Experience with projects defined with XForms has shown:
Around a ten-times saving in costs, compared with traditional methods.
One correspondent in Denmark who was converting a large collections of apps for a company from Javascript to XForms reported that the XForms were about ¼ the size.
So that means we should expect the production time and cost to reduce by one eighth, about an order of magnitude. And indeed we do.
A certain company makes BIG machines (walk in): user interface is very demanding — traditionally needed 5 years, 30 people.
With XForms this became: 1 year, 10 people.
Do the sums. Assume one person costs 100k a year. Then this has gone from a 15M cost to a 1M cost. They have saved 14 million! (And 4 years)
Manager: I want you to come back to me in 2 days with estimates of how long it will take your teams to make the application.
Manager: I want you to come back to me in 2 days with estimates of how long it will take your teams to make the application.
[2 days later]
Manager: I want you to come back to me in 2 days with estimates of how long it will take your teams to make the application.
[2 days later]
Javascript man: I'll need 30 days to work out how long it will take to program it.
Manager: I want you to come back to me in 2 days with estimates of how long it will take your teams to make the application.
[2 days later]
Javascript man: I'll need 30 days to work out how long it will take to program it.
XForms man: I've already done it.
"I was working on a project with real-estate transactions that had many associated complex real-estate forms. Traditional methods required approximately 40 inserts into separate tables within a relational database. The use of XForms and eXist resulted in one line of XQuery code:
store(collection, file, data)
That was it. Simple. Elegant.
I was hooked. After spending over 20 years building applications with a variety of procedural languages I found my preferred architecture. I have seen the power of XForms and eXist and can't conceive of returning to my procedural programming ways."
XRX: Simple, Elegant, Disruptive (Dan McCreary, O'Relliynet, 2008)
For historical reasons, present programming languages are at the wrong level of abstraction: they don't describe the problem, but only one particular solution to the problem.
Once project managers realise they can save 90% on programming costs, they will switch to declarative programming.
I believe that eventually everyone will be programming declaratively: less errors, more time, more productivity.