Morning: The Evolution of Programming
Afternoon: Introduction to AI
AI and Programming
(Do ask questions)
...
Tomorrow: XForms Hands-On
I went to the
same school as Stephen Hawking.
He was born in Oxford, went to school in St Albans, and came back to Oxford to study.
I didn't know him, but a class mate of mine went on to do his PhD with him,
and is now the Hawking Professor of Fundamental Physics at Texas A&M
University.
Even
though this masterclass is being held in a very old institution, that school is
even older: it was founded in 948!
Even so, this still only makes it the 12th oldest school in the UK.
My
university tutor was Richard
Grimsdale, who built the first ever transistorised computer
Grimsdale's tutor was Alan Turing. (Making me a grand-tutee of Turing).
Turing is considered the father of AI. In his 1950 paper "Computing Machinery and Intelligence", he starts with
"I propose to consider the question, 'Can machines think?'",
and introduces what is now called the Turing Test of machine intelligence.
I (coincidentally) went on to
work in the department in Manchester where Turing worked and wrote that paper;
I worked on the 5th computer in the line of computers Turing also worked on,
the MU5.
Later I was university lecturer in Brighton
Moving to The
Netherlands, I co-designed the programming language that Python is based on.
I wrote a part of gcc
That programming language was a research project to design a programming language more aligned with the programmer's needs.
For instance no (built-in) limits.
Many modern-day encryption algorithms were designed using ABC for that reason.
We designed it using what you would now recognise as User Interface principles:
Guido van Rossum moved on to an operating system project, and needed a systems programming language for it, so built on what we had learned.
I was the first user of the open internet in
Europe, in November 1988.
CWI set up the first European internet node (64Kbps!), and then two spin-offs to build the internet out in Europe and the Netherlands.
Since 1988, the internet connection in Amsterdam has nearly doubled per year, and is currently the fastest internet switch in the world, peaking at nearly 13Tbps.
In the
late eighties, I co-designed a system that looks like a browser:
I
organised workshops at the first Web conference at CERN in 1994
I was chair of the HTML, XHTML, and XForms Working groups at W3C.
I co-designed HTML, CSS, XHTML, XForms, RDFa, and several others.
I still chair XForms and ixml.
Thirty six years ago, the open internet started in Europe.
I would contend that we still consider the internet as something new.
But on that day in 1988, public computing was also only just over thirty years old.
The first computer so cheap that they gave it away on the cover of a magazine
The Elliot ran for about a decade, 24 hours a day.
How long do you think it would take the Raspberry Pi Zero to duplicate that amount of computing?
The Elliot ran for about a decade, 24 hours a day.
How long do you think it would take the Raspberry Pi Zero to duplicate that amount of computing?
The Raspberry Pi is about one million times faster...
The Raspberry Pi is not only one million times faster. It is also one millionth the price.
A factor of a million million times better.
A terabyte is a million million bytes: nowadays we talk in terms of very large numbers.
Want to guess how long a million million seconds is?
The Raspberry Pi is not only one million times faster. It is also one millionth the price.
A factor of a million million times better.
A terabyte is a million million bytes: nowadays we talk in terms of very large numbers.
Want to guess how long a million million seconds is?
A really big number...
In fact a million million times improvement is about what you would expect from Moore's Law over 58 years.
Except: the Raspberry Pi is two million times smaller as well, so it is much better than even that.
This probably has to do with how early computers were priced.
When Edison introduced electric light in the home, he charged not what it cost to produce the electricity, but what it would cost you to produce the same light without electricity, but now with extra advantages, such as instant-on, and less danger.
Similarly, the first computers were not priced on how much they cost to produce, but on how much you would have to pay to do the same work without computers.
In 1965 Gordon Moore proposed that the number of 'components' on a chip would double per year at constant price (and size).
In 1975, he adjusted it to 18 months.
In 2015 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 in 2015, which caused a wag to tweet:
"The number of press articles speculating the end of Moore's Law doubles every eighteen months."
An article by a journalist who had been mourning Moore's Law for a decade, and realised he was wrong.
Often people don't understand the true effects of exponential growth.
A BBC reporter: "Your current PC is more powerful than the computer they had on board the first flight to the moon". True, but oh so wrong.
Take a piece of paper, divide it in two, and write this year's date in one half:
Divide the other half in two vertically; write the date 18 months ago in half:
Divide the remains in half, and write the date 18 months earlier, i.e 3 years earlier than today:
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 ever had put together (and way more powerful than the computer they had on board the first moonshot).
In the 50's, computers were so expensive that 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.
Compared to the cost of a computer, a programmer was almost free.
In the 50's the
computer's time was expensive. A programmer would:
Why? Because it was much cheaper to let 3 people check it, than to let the computer discover the errors.
The first programming languages were designed in the 50s:
Cobol, Fortran, Algol, Lisp.
They were designed with that economic relationship of computer and programmer in mind.
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.
A short ten years later, there was already talk of a software crisis.
Programs being written that weren't functional, and/or weren't delivered on time, and/or on budget.
It happened slowly, almost unnoticed, but nowadays we have the exact opposite position:
Compared to the cost of a programmer, a computer is almost free.
I call this Moore's Switch.
Relative costs of computers and programmers, 1957-now
But, we are still programming in programming languages that are direct descendants of the languages designed in the 1950s!
We are still telling the computers what to do.
A new way of programming: declarative programming.
This describes what you want to achieve, but not how to achieve it.
Let me give some examples.
Declarative approaches describe the solution space.
A classic example is when you learn in school that
The square root of a number is a number that multiplied by itself gives the original number.
This doesn't tell you how to calculate the square root; but no problem, because we have machines to do that for us.
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'
}
This is why documentation is so essential in procedural programming.
1000 lines, almost all of it administrative. Only 2 or 3 lines have anything to do with 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
XForms is an XML-based declarative system for defining applications. 
It is a W3C standard, and in worldwide use.
A certain company makes one-off 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.
[Two days later]
Programmer: I'll need 30 days to work out how long it will take.
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.
[Two days later]
Programmer: I'll need 30 days to work out how long it will take.
XFormser: It's already running!
The British National Health Service started a project for a health records system.
The British National Health Service started a project for a health records system.
One person then created a system using XForms.
XForms 1.0 was designed for online Forms.
After some experience it was realised that the design had followed HTML too slavishly, and with some slight generalisation, it could be more useful.
So was born XForms 1.1, a Turing-complete declarative programming language.
Implementations from Belgium, France, Germany, NL, UK, USA.
XForms 2.0 is in preparation.
XForms was originally for forms. It is now much more general.
"The term form refers to the work's style, techniques and media used, and how the elements of design are implemented.
Content, on the other hand, refers to a work's essence, or what is being depicted."
This is a nearly-perfect description of XForms.
XForms applications have two parts:
XForms is all about state. (Which means it meshes well with REST - Representational State Transfer, which the Web uses).
Initially the system is in a state of stasis.
When a value changes, by whatever means, the system updates related values to bring it back to stasis.
This is like spreadsheets, but much more general.
The result is: programming is much easier, since the system does all the administrative work for you.
I've got a position in the world as x and y coordinates, and I want to display the map tile of that location at a certain zoom.
My data:
x, y, zoom
Openstreetmap has a REST interface for getting such a thing:
http://openstreetmap.org/<zoom>/<x>/<y>.png
However, the Openstreetmap coordinate system changes at each level of zoom.
As you zoom out, there are in each axis half as many tiles, so there are ¼ as many tiles. And the interface indexes tiles, not locations.
So to get a tile:
The data: x, y, zoom
scale = 226 - zoom
tilex = floor(x/scale)
tiley = floor(y/scale)
url = concat("http://tile.openstreetmap.org/", zoom, "/", tilex, "/", tiley, ".png")
That is really all that is needed (modulo syntax, which looks like this:)
<bind ref="tilex" calculate="floor(../x div ../scale)"/>
That's the form. Now the content:
<input ref="zoom" label="zoom"/> <input ref="x" label="x"/> <input ref="y" label="y"/> <output ref="url" mediatype="image/*"/>
and the tile will be updated each time any of the values change.
For historical reasons, present programming languages are at the wrong level of abstraction: they don't describe the problem, but only one particular solution.
Declarative programming allows programmers to be at least ten times more productive: what you now write in a week, would take a morning; what now takes a month would take a couple of days.
Once project managers realise they can save 90% on programming costs, they will switch to declarative programming.
I believe that eventually everyone will program declaratively: fewer errors, more time, more productivity.
Separation of data from UI, similar to separation of style from content with CSS, with similar advantages.
Instances of data + properties.
<instance resource="sale.xml"/> <bind ref="something" property="something"/>
Properties include:
As you saw above in the map example, whenever a value changes, the related values are automatically updated, in spread-sheet style.
<bind ref="address/state"
required="../country = 'USA'"
label="State"/>
This means that state is only required for the USA. The field
will always be visible.
<bind ref="address/state"
relevant="../country = 'USA'"
required="true()"
label="State"/>
This means that state will only be visible for the USA, but
once visible will be required.
Controls in the UI then bind to data nodes, inheriting their properties.
<input ref="address/state"/>
Similarly, the billing address is only relevant if it is different from the delivery address:
<bind ref="address[@type='Billing']"
relevant="../@different=true()"/>
Typically XForms works automatically.
You can hook into the processing model to respond in special ways.
Events announce changes in the state;
actions effect changes to the state.
E.g. xforms-ready announces that the system has initialised (and is at stasis). You could respond to this by recording today's date and time:
<action ev:event="xforms-ready"> <setvalue ref="today" value="now()"/> </action>
Other events announce when a value changes, or when it changes validity, relevance, etc., or when a button gets pushed.
Other useful actions include inserting and deleting elements and attributes in data.
For instance, the way to get a button to do something is to listen for the activation event, and then respond with an action.
<trigger label="Restart">
<action ev:event="DOMActivate">
<setvalue ref="score" value="0"/>
</action>
</trigger>
The user-facing part is done with controls.
Controls are declarative too: they are designed to be device and modality independent;
Controls describe what they do, but not how they do it, nor how they look.
For instance, the select1 control selects a value from a list
of values. It can be implemented visually as a menu, or as radio buttons, and
it can be implemented in other modalities as necessary.
<select1 ref="colour"> <label>Colour:</label> <item><label>Red</label><value>red</value></item> <item><label>Yellow</label><value>yellow</value></item> <item><label>Green</label><value>lime</value></item> <item><label>Cyan</label><value>aqua</value></item> <item><label>Blue</label><value>blue</value></item> <item><label>Magenta</label><value>fuchsia</value></item> <item><label>Black</label><value>black</value></item> <item><label>White</label><value>white</value></item> </select1>
For instance these three are just different visual representations of this control:
Controls don't have to be hard-wired like this, but can also get their values from data:
<select1 ref="colour">
<label>Colour:</label>
<itemset ref="instance('colours')/colour">
<label ref="."/>
<value ref="."/>
</itemset>
</select1>
There is an online hands-on XForms tutorial which we will be doing tomorrow.