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.
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 the first style and internationalization workshops at W3C.
Chaired HTML WG for the best part of a decade.
Co-author of HTML4, CSS, XHTML, XML Events, XForms, RDFa, etc
Currently Forms co-chair at W3C
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 computers, nearly everyone leased them.
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 what to do, in its terms, not what you want to achieve in yours.
Moore's Law is 50 years old.
Or less prosaically: Moore's Law is 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 this 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 this 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!
Often people don't understand the true effects of exponential growth.
A BBC reporter recently: "Your current PC is more powerful than the computer they had on board the first flight to the moon". Right, but oh so wrong (Closer to the truth: your current computer is several times more powerful than all the computers they used to land a man on the moon put together.)
Take a piece of paper, divide it in two, and write this year's date in one half:
Now divide the other half in two vertically, and write the date 18 months ago in one half:
Now divide the remaining space in half, and write the date 18 months earlier (or in other words 3 years ago) in one half:
Repeat until your pen is thicker than the space you have to divide in two:
This demonstrates that your current computer is more powerful than all other computers you have had put together.
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.
Since the 1950's computers have become more than 11 trillion times faster. (That's 350,000 years in seconds).
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?
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.
How much shorter?
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.
Experience with projects defined with XForms has shown:
Around a ten-times saving in costs, compared with traditional methods.
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)
It is widely used. For instance:
Many companies use XForms either internally or externally, and have their own implementations, either for internal use or for licensing. For instance:
XForms is a flexible solution for forms and related applications.
Above all it is concise.
It is an open standard.
Its use saves a lot of money.
A tutorial: http://www.w3.org/MarkUp/Forms/2010/xforms11-for-html-authors/
For an overview of all features, elements and attributes of XForms 1.1, see the XForms 1.1 Quick Reference.
It's not easy reading, but the final arbiter in questions of doubt is the XForms 1.1 Specification.
Living XForms 2.0 Draft: http://www.w3.org/MarkUp/Forms/wiki/XForms_2.0
The implementation used for the examples in this talk is XSLTForms.