The author

Declarative Applications

Steven Pemberton, CWI, Amsterdam

Mainframes

A room-sized computer

Room-sized, costing millions, they were shut off from the outside world. They were so expensive that most companies would lease them rather than buy them.They often came with 'free' programmers into the bargain.

The Minicomputer

Cupboard-sized machines, costing of the order of ¤100,000.

PDP 11

The disadvantage of these machines were that they were slower, and had few resources (memory, disk) than the mainframes. But the advantage was that they were cheap, and you could have them in the lab. You still had to share, but it was nearby, and you got instant turnround once you were on it.

The Workstation

SGI workstationStarting in the 70's but picking up momentum in the 80's came the Workstation, which could go on the desktop of the programmer in the office, and were known as 3M machines:

Now at last programmers had machines of their own.

The PC (and laptop)

Starting in the late 70's, came the PC, the first computer to make its way into the home (and the briefcase). It cost of the order of ¤1000.

Apple ][

Netbooks

Cost of the order of ¤100. Now everyone has (at least) one.

asus eee

1954?

1954 view of the future? No, hoax.

The power of computers

So we've seen a reduction of cost of computers of 4 orders of magnitude (from ¤1000000 to ¤100).

But those aren't equivalent computers. Computers have got faster too.

The power of computers

Here are my personal laptops (note log scale):

Power of laptops

Just in the last 20 years, my laptops have gone from power 800 to about 32,000,000 (at roughly the same price); more than 4 orders of magnitude, forty thousand times faster.

The cost of coding

When I was first a programmer I cost of the order of £1000 a year. The computer cost 1000 times more: programmers were effectively free.

Now a programmer costs of the order of ¤100,000, and computers are effectively free.

But how more efficient are you than a 1960's programmer?

My estimate: at best 2 orders more efficient than someone who programmed in assembly code. Not much more than 1 order more than someone who programmed in a high-level language.

One order of magnitude

One order of magnitude is still not bad. It means that you can program in a day what someone then would have needed two weeks for.

Programming languages were designed for computers

Even though high-level programming languages gave programmers an order-of-magnitude improvement, they were still designed to make the resulting programs as efficient as possible.

It now would be more effective to have languages that minimised the programmer's time, not the computers. (Note: not 'easier to use', just needing less of the programmer's time).

Declarative languages

You specify what you want, not how to do it.

Let the computer use some of its spare cycles to work out how to achieve it.

An example: XForms

XForms is a declarative language for the web, where data is kept up-to-date using constraints, in a similar way to how spreadsheets work.

"Declarative" means that a lot of the administration that you normally have to do when programming is done for you by the system.

As the name suggests, it was originally designed just for forms, and was that in version 1.0; but with a small amount of generalisation in version 1.1 it became an application language.

Example: to do (34 lines)

(Source)

Example: maps (37 lines of mark up)

(Source)

XForms Structure

XForms has a data model, where all data is stored, and in the body controls where data values can be input or output:

<model>
    <instance>
        <data xmlns="">
          <firstname/><surname/>
       </data>
   </instance>
</model>
 ...
<input ref="firstname"><label>First name</label></input>
 ...
<output ref="firstname"/>

Input and output

(Source)

Values can be calculated

<model>
   <instance>
       <data xmlns="">
          <height/><width/><depth/><volume/>
       </data>
   </instance>
   <bind nodeset="volume"
         calculate="../width*../height*../depth"/>
</model>

Volume example

(Source)

Controls are abstract

Here are three identical controls, just styled differently

(Source)

The control

<select1 ref="sex">
    <label>Gender</label>
    <item>
        <label>Male</label>
        <value>M</value>
    </item>
    <item>
        <label>Female</label>
        <value>F</value>
    </item>
</select1>

Data can be obtained from external sources

<model>
    <instance src="http://..."/>
</model>

And data can be written back to external sources.

<submission resource="http://..." .../>

And values can be output anywhere

<input ref="age">
    <label><output ref="age-text"/></label>
</input>

Example

(Source)

Maps

<model xmlns="http://www.w3.org/2002/xforms">
    <instance>
        <data xmlns="">
            <url>http://a.tile.openstreetmap.org/10/511/340.png</url>
        </data>
    </instance>
</model>
 ...
    <input ref="url" />
 ...
    <output ref="url" mediatype="image/*" />

Maps

Ŕ(Source)

Maps

<data xmlns="">
    <zoom>10</zoom>
    <x>511</x>
    <y>340</y>
    <url/>
</data>
 ...
<bind nodeset="url" 
  calculate="concat('http://a.tile.openstreetmap.org/',
                    ../zoom, '/' , ../x, '/', ../y, '.png')"/>
 ...
    <input ref="y" />
 ...
    <output ref="url" mediatype="image/*" />

Maps

(Source)

Maps

    <input ref="zoom" />
    <input ref="x" />
    <input ref="y" />
    <output ref="url" mediatype="image/*" />

Maps

(Source)

Maps

<data xmlns="">
   <zoom>10</zoom><x/><y/><url/>
   <posx>130980</posx><posy>87168</posy>
   <scale/><maxpos/>
</data>
 ...
    <bind nodeset="scale" calculate="power(2, 18 - ../zoom)"/>
    <bind nodeset="x" calculate="floor(../posx div ../scale)"/>
    <bind nodeset="y" calculate="floor(../posy div ../scale)"/>
 ...
    <input ref="zoom" />
    <input ref="posx" />
    <input ref="posy" />
    <output ref="x" />
    <output ref="y" />
    <output ref="url" mediatype="image/*" />

Maps

(Source)

Maps

Now we just add controls for zooming in and out, etc, and maybe add some more tiles, and we have a working map application.

(Source)

Selectors

As you have seen, most selectors ('variable names') are just simple names like

ref="x"

or the occasional

"../y"

This already hints at the fact that selectors in XForms look like directory paths (in fact they are called XPaths). So rather than Javascript

coords.x

you write

coords/x

Example: Interaction

Wikipedia example

Wikipedia

<instance id="isearch">
  <data xmlns="">
    <action>opensearch</action>
    <search/>
  </data>
</instance>

<submission resource="http://en.wikipedia.org/w/api.php"
  method="get" replace="instance" instance="suggestions"
/>
    
<instance id="suggestions"><data xmlns=""/></instance>

This generates the url:

http://en.wikipedia.org/w/api.php?action=opensearch&search=whatever

Results

Wikipedia gives you results that look like this:

<SearchSuggestion version="2.0" xmlns="http://opensearch.org/searchsuggest2">
  <Query>XML</Query>
  <Section>
    <Item>
      <Text>XML</Text>
      <Description>Extensible Markup Language (XML) is a set of rules for encoding documents in machine-readable form. </Description>
      <Url>http://en.wikipedia.org/wiki/XML</Url>
    </Item>
    <Item>
      <Text>XML Schema (W3C)</Text>
      <Description>XML Schema, published as a W3C recommendation in May 2001, is one of several XML schema languages. 
      </Description>
      <Url>http://en.wikipedia.org/wiki/XML_Schema_(W3C)</Url>
    </Item>
    ...

Controls

We bind to the search string:

<input ref="search" incremental="true" />

And then, every time the value changes we submit the data:

<send ev:event="xforms-value-changed"/>

We then display the results with:

<repeat nodeset="instance('suggestions')/Section/Item">
     <output value="Text"/>
</repeat>

XRX

"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)

Data point: Big machines

A certain company makes BIG machines (walk in): user interface is very demanding — needs 5 years, 30 people.

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)

Data point: applets

A company is producing many small applications based on previous Javascript versions.

They report that the code is less than 25% of the original size (so a tenth of the work).

"[The designers] are really happy to not have to use javascript by the way: they like that if things don't work its not their fault"

Data point: application (true story)

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.

Data point: Bank

Conclusion

The costs of computing have been plummeting for more than 50 years, and yet the relative costs of coding have been soaring.

The basic problem is (still) that programming languages are designed principally for the computer.

Declarative programming needs a new way of thinking, but once you are there, you are much more productive.

More information on XForms

(The slides are online)