TheMessyRealWorld

ThoughtStorms Wiki

PaulSnively tweeted :

End-user programmable platforms have always been profoundly unserious for professional development for that reason.

It's unfortunate that it took nearly three decades of work at Symbolics, Texas Instruments, Xerox PARC... to offer proof by demonstration. But we have it.

To which I'm writing a long response.

I think we can analyse WHY this is, and do something about it :

The hardest part of programming is dealing with the complexity of the external world. Resources like OSs, dbs etc OUTSIDE your program.

Beautiful end-user-programmable systems like Smalltalk and Hypercard often get their niceness by insulating themselves from that external world. Living inside a self-contained image etc. And often pretending that external messiness doesn't exist.

OTOH, 'professional' software development usually has to struggle with the external messiness: third party libraries, servers, millions of users etc. Because 'nice' systems try to ignore all that, no one in that world really does any hard thinking about how to bridge the gap.

One way to make programming easier is to bring more of the external world INSIDE your programming language. To allow the same expressive language you have INSIDE your system to talk about these external resources. This is really what Docker, DevOps etc. are about: scriptable infrastructure.

Our challenge, then, is to do the same thing. Give the resources of the nice, expressive world inside the Smalltalk or Hypercard etc. images, the ability to talk about the messy external world. To define a kind of API / stub / semantics for real world messiness that the nice languages can implement against.

This needs some smart thinking by some smart people. But I suspect that if we saw this as our problem and wanted to fix it, a lot of the work could be done once to support a lot of nice languages.

In a sense this is what the web did. Provided a nice high-level API for the quite tricky problem of 'asking another machine for a document, and coordinating delivering it to us'. Once that was achieved it allowed a whole lot of not particularly experienced or technically sophisticated developers to make applications based on sharing documents between machines. Often in very sandboxed 'nice' environments like the browser.

The more we wrap the messiness of things like communicating with servers, accessing databases and file-systems, communicating with an AI etc. in convenient and easy APIs, the more we can give the nice end-user programmed systems access to them to do 'real world work'.