
Final “STEPS Toward the Reinvention of Programming” Paper [pdf] - e12e
http://www.vpri.org/pdf/tr2012001_steps.pdf
======
Animats
This is a strange paper. It reads a lot like "Personal Dynamic Media", Kay's
paper from the 1970s, which led to the Alto and Smalltalk. Back then, this was
all new. Now, it's not.

The big thing here seems to be defining domain-specific languages (they don't
use that term) which allow certain classes of problems to be written
concisely. The examples given of those language look rather conventional:

    
    
        selectionWatcher <- 
          when 
            DocEditor.selectedDocBox :b 
          then 
            this.textContents(if b then b.printString() else "")
        ...
    

Their approach to GUI programming:

    
    
        layout
            ^ KSSimpleLayout new
            keep: #topLeft  of: ’titleBar’ to: 0@0;
            keep: #right    of: ’titleBar’ to: #right offset: 0;
            keep: #height   of: ’titleBar’ to: 25;
        ...
    

These are constraints for a constraint engine, which is a good idea not
original with them. But writing constraints as text is painful. You can do
that sort of thing in CAD programs such as Autodesk Inventor from the GUI, and
you get useful error messages when you overconstrain or underconstrain. That's
how web page layout really ought to work.

They created about 100 domain-specific languages, and in each, the demo
programs are short, because the languages are well-matched to the specific
problem. But they didn't get to the point where they put users on these
languages. That's needed to find out if they're as concise as claimed, or the
users end up writing complex code to get around limitations of the language.

There are widely used domain-specific languages, such as Matlab and Excel. In
each of those, stuff the language designer thought of is easy, and hard stuff
is really ugly. That's what usually happens.

Not seeing the big breakthrough here.

~~~
sp332
The big breakthrough is making it easy to create new DSLs for any situation.
Every area of the OS has its own language (and you can just add more if you
feel the need) so that the whole OS including networking and GUI is very
compact, understandable, and hackable. This particular project focused on
compactness, just to prove that it is quantitatively more expressive.

~~~
skratlo
I was studying Racket lately, and it sounds very familiar now. DSLs, or
dialects as Racket calls them, is surely way to go and improve productivity,
it should however, always be possible to descent down, or escape from that
DSL, where needed, to avoid the hacks that work around a certain limitation of
this or that DSL. (lisp macros, wink wink)

------
kristianp
One of the demos of their research was a "A full TCP/IP stack in under 200
LoC" (2008), see
[https://news.ycombinator.com/item?id=846028](https://news.ycombinator.com/item?id=846028)
, Described in
[http://www.vpri.org/pdf/tr2007008_steps.pdf](http://www.vpri.org/pdf/tr2007008_steps.pdf)

It appears as an example in the cola source:
[https://github.com/robertpfeiffer/cola/tree/master/function/...](https://github.com/robertpfeiffer/cola/tree/master/function/examples2/tcp)

------
ozten
One of the key issues was that they started STEPS with the premise that they
needed NSF funding for running the FONC project on super computers. This
strategy is to "time travel" 10 years into the future, like Alan Kay did at
Parc to develop the Alto.

In this last phase of the STEPS project, sub-systems like the graphics system
were close to running fast enough on commodity hardware, that they changed
course during this last phase, abandoning time sloted for design iterations
and exploration, to focus on optimization instead.

~~~
wmf
And unless they were researching parallel programming, a supercomputer
wouldn't run desktop GUI software any faster anyway. Maybe this wasn't obvious
back in 2007.

~~~
ozten
I think they were looking at custom architectures implemented in FPGAs.

------
twelvechairs
Im not usually an advocate of 'you need to hire a UX/UI person' but this
really needs a good one. Its trying to show people a lot of different
information and theres no graphical clarity to it at all. Worse it looks like
the worst kind of interfaces from the early 1990s. Its painfully obvious
nobody on the team has any graphic/visual background. I guess its just the
difficulty of projects coming from a university/science/research basis where
these things arent valued because they are hard to quantify.

~~~
wolfgke
> I guess its just the difficulty of projects coming from a
> university/science/research basis where these things arent valued because
> they are hard to quantify.

IMHO rather because in research projects at universities there is no position
(in the sense that one can spend money on it) for people who aren't either
researcher or administration. UX people surely have their importance but they
neither bring research results nor they are a "necessary evil" (adminstration
- which is no contradiction that good adminstration personal can be really
helpful).

~~~
seanmcdirmid
Well, there are HCI researchers who do design/UX/UI; more straight up design
research in CS would be nice though.

------
wangii
I can't believe this group of incredibly smart people have produced this not-
so-impressive paper. Sure, the size of source codes is a big problem. but is
LOC the most cost-effective issue to investigate into? Why none of the
existing module approaches work? Is this really a language problem can be
magically solved by FPR? Can this 20k app handle Chinese characters? How many
corner cases does it handle?

Abstraction leaks, and I don't believe in any silver bullet.

~~~
corysama
Is it the magical solution to all of life's problems? No. It is damn
impressive. Yes.

Right now we live in a world where everything we do depends on multiple layers
of 10s-100s of millions of lines of code _each_ for the compilers, the
operating systems, the browsers or platform libraries (ex Qt). It's physically
impossible to _read_ a significant amount of the code in any of these layers,
much less understand it. Then we get to add in modules and libraries like
Boost or Js-Framework-Melange-Of-The-Week and we don't even know how anything
we are doing with the topmost platform level even works. We've gone from
Fortran to this in 60 years. What is this going to look like in another 60
years?

An alternative future is something like Nile. Reading Nile's code requires
some up-front study. That sounds like work compared to "I can look at a for-
loop in any package and know instantly that it is for-looping er...
something... for some reason..." But, it's the kind of up-front study that is
reasonable for a smart high schooler to pull off. With reasonable effort, that
kid could understand literally every character of the Nile source and start
making major, sweeping modifications. Contrast that with Cairo --which at a
high level is not much more complex than Nile, but I'll be damned if anyone
but it's maintainers can claim to understand every line and make major
changes.

~~~
andreapaiola
In 60 years the software will write itself

[http://techcrunch.com/2016/05/09/siri-creator-shows-off-
firs...](http://techcrunch.com/2016/05/09/siri-creator-shows-off-first-public-
demo-of-viv-the-intelligent-interface-for-everything/)

~~~
jules
That's what they thought a couple of decades ago too. I've heard of some
research into programming languages decades ago not getting funded because "in
a few years we won't need programming languages anyway". It might be true this
time, but it might not.

~~~
andreapaiola
Ok, but progress is progress. What does it matter what happened 20 years ago?

------
e12e
ozten[2] wrote:

"Last week VPRI[1] published the final "STEPS Toward the Reinvention of
Programming" paper[this submssion].

Although it is 2012, it had been unavailable publicly until now. A great way
to catch up on how FONC ended. It was worked on by many individuals being
cited as part of HARC.

[1] [http://vpri.org/html/writings.php](http://vpri.org/html/writings.php)

[2]
[https://news.ycombinator.com/item?id=11680238](https://news.ycombinator.com/item?id=11680238)

~~~
NotUsingLinux
Sorry but its 2016, publishing a paper is not enough. Alan kay of all should
now we need more , we need:

The three/four pillars of reproducible research

Often in the discussions around open and reproducible science we focus three
main types of research products

1\. the paper: the traditional narrative document, often 2. the data:
increasingly appreciated as a first-class citizen of scientific record with
data repositories providing DOIs 3\. the code: recognized as a research
product, but the last to be integrated into literature system and given DOI

4\. the environment: a critical and under-appreciated ingredient for
computational reproducibility

THAT should be the minimum for all science projects IMHO. What do you think?

~~~
e12e
I'd love to see full sources and build system that allowed everyone to play
with Frank. I was sure I'd made a comment to that effect somewhere, but I
can't find it now, perhaps it was eaten by my outdated smart phone.

On the other hand, I believe the paper(s) might very well be more important:
exploring the ideas. I think it's a difference between a research project in
computer science, and an engineering project. The first lambda calculus was
just a project - they thought they'd need years to get the thing running. And
then someone just coded up eval() in machine-code and they were bootstrapped.

I to want the implementation of eval(), but I'm not unhappy that they've
shared their ideas.

~~~
e12e
Oh, yeah there it was:
[https://news.ycombinator.com/item?id=11686096](https://news.ycombinator.com/item?id=11686096)

------
david927
For me, they ran before they could walk. Anything graphics-related could wait
(although Nile is awesome, so they're forgiven). It feels like they were
focused on trying to sell their findings rather than just focusing on
research.

But I'm a huge fan of everyone involved in this, so that's not criticism --
just speculation.

------
agumonkey
I suggest people to walk the fonc mailing list, lots of old threads with smart
people discussing interesting ideas.

------
kennethfriedman
I'm curious how much of the code base will be publicly available. It would be
great to try this stuff out.

~~~
david927
One portion, Nile, is available on github:

[https://github.com/damelang/nile](https://github.com/damelang/nile)

~~~
e12e
See also Ometa:

[http://tinlizzie.org/ometa-js/](http://tinlizzie.org/ometa-js/)

[https://en.wikipedia.org/wiki/OMeta](https://en.wikipedia.org/wiki/OMeta)

[https://github.com/alexwarth/ometa-js](https://github.com/alexwarth/ometa-js)

And Cola:

[https://en.wikipedia.org/wiki/COLA_(software_architecture)](https://en.wikipedia.org/wiki/COLA_\(software_architecture\))

Some more links on the WP page for VPRI:
[https://en.wikipedia.org/wiki/Viewpoints_Research_Institute](https://en.wikipedia.org/wiki/Viewpoints_Research_Institute)

And VPRI's own wiki:

[http://www.vpri.org/vp_wiki/index.php?title=Main_Page](http://www.vpri.org/vp_wiki/index.php?title=Main_Page)

As far as I've been able to gather, the most immediately useful stuff, is the
ideas and concepts in OMeta, as well as the various implementations of OMeta.

~~~
joshmarinacci
Ometa is amazing. Ohm, the successor is even better.

~~~
e12e
I believe that's:
[https://github.com/cdglabs/ohm](https://github.com/cdglabs/ohm) ? I see I've
starred it at some point, but can't remember really looking at it. But if it's
a refined/improved OMeta, it would indeed be interesting. Thanks for the
reminder.

~~~
msingle
That's the one.

------
cowardlydragon
I hear APL is concise.

~~~
cowardlydragon
You know what else was concise for UI? HTML.

... but people wanted their rounded corners.

... so now it's not concise.

------
mlvljr
A relevant lecture from Alan Kay:

[https://www.youtube.com/watch?v=FvmTSpJU-
Xc](https://www.youtube.com/watch?v=FvmTSpJU-Xc)

