Folks, check out @Duncan Cragg's http://object.network/. I recently got around to reading up and found the programming model simple and the vision powerful. I wonder if there are even 'just spreadsheets' that use this model.
Of course I'd like to hear people disagree with me 🙂. I think our community needs a thesis on what things end-users might actually like to program.
3 years ago
yeah, that precise thing is a high value for me: it seems like template-y things/WYSIWYG editors rather inescapably confine themselves to the tasks/usages that the platform designers have foreseen, so those things feel like cul-de-sacs of utility. same thing for platforms which confine themselves to certain kinds/shapes of data— how crazy would it be if you had to pick a different programming language if you wanted to work on tables, and a different one for images, and a different one for trees, and so on? that is weirdly the case right now, especially for node-based editors (which is the world I am in right now).It makes a lot more sense to me to offer the same basic primitives that "real" programming languages offer, and vet that those primitives/concepts are well designed/received. Then "interesting" functionality comes by implementing/exposing interesting APIs over those primitives.
I agree with Nick that simply referencing the value of a state variable represents less cognitive burden for the programmer, than remembering the name of yet another function call. OSX has gotten to an absurd API count, and when you take the API's for all the Java classes it exceeds 10,000, which is a huge cognitive burden for the programmer. Java exacerbates the API problem by having multiple ways to do similar things, so you then have to wonder which API set would be best, and when you merge other modules of code from other authors, you then start mixing which API sets are in use, and it gets ugly in a hurry. This is one of the reasons why the era of interchangeable parts did not occur with the Java language, and one of my reasons why Java has to be scrapped ASAP.I think of a function as doing some isolated calculation like Trig functions which have a very complex internal implementation but are trivial to use, taking only a single input.The problem i have with API's is the quantity one has to learn to accomplish anything. In the Apple 2 days, you might learn a few dozen. In Apple Macintosh it was a few hundred. Win32 GDI was also a few hundred albeit a much more modal/complex set than Apple's clever and clean Quickdraw. Fast forward to today, and nobody even prints books with the full set of API's because the books would be too fat. Because we aren't printing the documentation on paper, people aren't noticing the load, but I prefer printed documentation, and after emptying my 500 sheet input tray of my fancy canon laser printer, i give up and want to scrap the whole thing. My Beads language project is the result of my extreme distaste for how complex the current toolchain is, mostly caused by an API explosion. You can build a graphical interactive chess game with audio, autosizing graphics, etc., with under 20 API's and i consider that a big win for the programmer as I don't need a fancy context sensitive IDE to help prop up an overcomplex mess, and can learn the 20 API calls after repetitive usage.
I've been thinking recently that "end-user programming" as term is overly focused on individuals as opposed to communities, for two reasons:1) To make/customize anything worth using, it will be complex enough that you'll want/need to use pre-existing widgets/libraries that others have made in order to do it without it taking all your time. I think end-user programming biases towards languages and tools that a single person can make entirely themselves, and thus rules out the more interesting and complex software artifacts people could create. When focused on the individual user, we don't place enough emphasize on the collaboration (through using the code of others) that will be necessary to allow people to make amazing things without programming full time.2) The vast majority of computer usage is collaborative to some extent, be it friends and family, work colleagues, clients, vendors, strangers online, etc. Only a small minority of computer use is me writing in a journal that no-one will see. Everything else is co-created and meant to be shared, or browsing what others have shared.Thus I propose deprecating the term "end-user programming" in favor of "end-community programming." My thinking on this was likely mostly provoked by @Bosmon and @Philip Tchernavskij
Well said. You are correctly noticing that I am criticizing the original vision of the empowered individual in favor of the empowered community, because it's a much more important, alebit harder, problem. If we need to liberate users first as a stepping stone, I'm all for it. But I don't want us to lose sight of the fact that empowered communities is what we're aiming at