
Dataless Programming (1967) [pdf] - hecubus
http://www.rand.org/content/dam/rand/pubs/research_memoranda/2007/RM5290.pdf
======
jamii
This one of the ideas we have been attempting to realise in Eve (eg
[http://www.lighttable.com/2014/07/18/imperative-
thinking/](http://www.lighttable.com/2014/07/18/imperative-thinking/)). We
separate the data model (expressed as relations) from the physical
implementation of that model (one or more physical data structures per table
that implement the queryable interface). The compiler is then responsible for
deciding how to evaluate a given query, based on the available data-
structures, indexes, hereustics and user hints.

It seems radical in a programming context but it is a pretty standard and well
proven separation in the database world. My favourite work along this line is
[https://infosys.uni-saarland.de/publications/DJ11.pdf](https://infosys.uni-
saarland.de/publications/DJ11.pdf) which defines the data model to be an
append-only list of tuples and treats the creation of all other data-
structures, indexes, views etc as part of a single global optimisation
problem.

~~~
eru
Have you read the "Out of the tarpit" paper
([http://shaffner.us/cs/papers/tarpit.pdf](http://shaffner.us/cs/papers/tarpit.pdf))?
It deals with using relations in programs as opposed to just in your
databases.

At Standard Chartered we regularly used relations as a perfectly cromulent
data structure in our programs.

~~~
jamii
Many times :)

Some of our other big inspirations are Bloom
([http://boom.cs.berkeley.edu/index.html](http://boom.cs.berkeley.edu/index.html))
and OctopusDB ([https://infosys.uni-
saarland.de/projects/octopusdb.php#secti...](https://infosys.uni-
saarland.de/projects/octopusdb.php#section_publications)).

------
CGamesPlay
This appears to roughly describe a precursor to SQL, which appeared 7 years
after this document. This was definitely a common problem. Imagine building
your most recent application, but not having easy access to an SQL-backed ORM.
How would you go about implementing it? The data model would definitely
heavily confound your attempts to build a clean system.

~~~
xtrumanx
> The data model would definitely heavily confound your attempts to build a
> clean system.

Can you expand on that. I build systems that don't use an ORM but still
requires interfacing with a SQL database so I'm curious how one ends up
writing "unclean" systems if not using an ORM. Sure, if you've got SQL all
over your code-base that's bad but if you were to use the repository pattern
it would be as if you were using an ORM in your code-base except within the
repository itself.

~~~
CGamesPlay
I actually equated using SQL to using ORM in my comment since I imagined most
people would be using one, but imagine if you didn't have SQL and you had to
store the data on a file system yourself.

------
chris-laffra
Interesting tidbit: Hard to imagine these days, but this language
specification appears typed by hand on a typewriter, most likely this model:
[http://magazinesadsandbooks.com/Magazine-Ad-for-Remington-
Ra...](http://magazinesadsandbooks.com/Magazine-Ad-for-Remington-Rand-KMC-
Typewriter-1967-P2184062.aspx)

------
mapleoin
So the solution to this problem is common knowledge by now, isn't it?
Separation of concerns, different abstraction layers, MVC (at least the M and
C parts), even OOP interfaces. These after all should be known by all CS
professionals.

The article seems to be just a piece of history. What am I missing?

