Which (sort of) supports GP's argument. We have programming environments on one end, full products on another and spreadsheets (maybe also MS Access) in the middle. The environment looks crowded.
Btw, I'd love spreadsheets-as-apps replaced with something more maintainable but they also have a huge advantage: you can start using a spreadsheet with zero programming. Unless you copy that, you can't compete for that niche.
If we have room at the ends (for new programming environments, and new products), why can't we have room in the middle?
Something else with zero programming is online form builders; some already have constraints and reporting systems. If they added simple programming constructs, it could be as powerful as you like. (e.g. google forms enables you to skip to different questions based on previous answers, though it's getting away from easy visualization, unlike spreadsheets).
You can view them as being a database, derived from input forms - what's stopping them growing towards unmaintainable real databases, in the way that spreadsheets can grow into unmaintainable apps?
A way to think about this is not in terms of a complex thing, but in terms of a simple thing... a toy... to which you can add-on complexity. e.g. I'm not sure that the first spreadsheets were fully programmable, but just related different cells by formula. And I know for sure that the first RDBs didn't have stored procedures.
Maybe, this could be done for many webapps: wiki + scripts; reddit + scripts (what would that be?); youtube + scripts (we have it a little bit with links on parts of the video). The puzzle is imagining what could possibly be the use of these... it helps if you already have a manual version that you are automatic (that's what the visicalc guys did: "spreadsheets" existed, on paper, before them: http://inventors.about.com/library/weekly/aa010199.htm).
There's visual webapps for assembling webservices, but they don't seem to have taken off. Maybe the "problem" is that they scale - the thing you create is good for more than just one person, unlike most spreadsheet documents, which (excluding templates) contains your own specific data - often, proprietary business data. Because it can scale, people invest more effort in it, and are happy to use proper APIs etc. And then, consumers don't have an unsatisfied need, because it's already done.
Therefore, perhaps the "toy" needs to be about a particular business or person (e.g. be about their data).
Also: Arguably, Flash authoring tools took the place of hypercard.
I think we agree - my point was not that there is no room in the middle but that if you want to go there you need to give some zero-programming benefits for starters.
And yes, forms are an example of what this benefit might be.
Yes, I think your zero-programming point was spot on (though check that spreadsheet link: I was surprised to learn that visicalc automated existing paper spreadsheets, so "programming" wasn't even an issue, at least for its initial massive success).
But note that we're not really in "support of GP's argument" anymore. ;-) That's what I was arguing against (but excellently provocative questions BTW).
Point well taken. So the question then becomes, why only one (or a small number of) such environments? (Also, I consider spreadsheets hardly trivial. I marvel at what some people can do in Excel ;)
And my answer to my own question is still the one I previously implied: There is no market for this kind of environment.
Consider, your problem needs to be:
* Repetitive enough to benefit from automation
* Complicated enough that automating it would yield a significant gain in the long run.
* Simple enough to not require going to an actual full-blown programming environment.
* Not numerically solvable, since spreadsheets have that covered.
* Not solvable via macro-recording or workflow solutions, since that market is also well-covered.
I'd say that does leave a fairly small sector. Hence, low demand for Hypercard-like solutions.
I had the same reaction of "no market" from the article, but on reflection I suggest turn it around: instead of thinking of it as "a programming environment", think of it as a specific application first, which has customization added to it, and eventually becomes programmable. Seeing it this way, such environments are very common - they are just not presented as "programming environments". And that may be what is different about Hypercard - how it it thought of, not what it actually was.
- I think macro-recording etc counts as a trivialized programming environment
- Many standard desktop applications are programmable (though today point, they just throw in a pre-existing language) - Word processors (Word uses VB, .net; OpenOffice uses Java/Python; Adobe acrobat uses Javascript. I think you'll find in earlier word-processors (for eg), they had more limited programming environments, before that, not fully programmable scripting; before that, only macros, before that only specific and limited explicit configuration... and before that, no customization at all.
- Flash authoring tools can do what Hypercard did, and more; they are also very easy to use for simple things, and even do it in a similar way to hypercard (but include a full programming environment for more complex things, like spreadsheets do). NOTE: flash's programming abilities have been enhanced tremendously over the years. I don't know the origins, but I wouldn't be surprised if it initially didn't have a "programming" capability, but just customizing some aspects of playing movies.
- html + javascript itself is not that different from hypercard, especially if you include an "authoring tool", of which a great many exist.
- wiki's are also hyperlink based...
- online forms (wufoo, google forms) - they derive a database from forms (like ORM, but skipping the objects, to be "FRM"), and include constraints, different paths, and reporting tools.
- vim has a programming language, but it's about as pretty as programming with a spreadsheet. This is because it evolved from something simpler, to get specific tasks done - I don't think vi was programmable! certainly not in the earliest versions (emacs is the exception, beginning with an actual programming language). I'm not even sure that shells were initially programmable for that matter... and that's about as close to a programmer as a tool can get.
[Also please check my follow-up comments, esp: visicalc was not initially about programming.]
---
TL;DR I put it to you that any tool can have automation added on to it - and if we view it this way, "trivialized (or specialized) programming environments" are the norm, not the exception. Their goal is not "programming", but to solve the specific problems and meet the specific needs of their users.
But the natural direction of a customization/configuration is programmability (and then to add programming features to help manage complexity, e.g. libraries, namespaces etc). It might take a while to get there. Some instances we see are only part-way there (see above); some stop growing/die before becoming attaining that level of customizability.
Going back to flash, ActionScript 3 added optional static types, enabling dramatically faster performance; before then, it was a version of Javascript; before that, it was a kind of hacked together script thing. I don't know what they had way back in Flash 1.0, but I suspect it wasn't yet programmable... just as visicalc 1.0 wasn't programmable...
If you look at it as purely customization, yes, there's a thriving market. But the author is specifically looking for something that creates a world 'where the distinction between the “use” and “programming” of a computer has been weakened'.
And the point is that those are fundamentally different activities. There's only a very small intersection that needs the simplicity of "use" and the complexity of "programming". And given that's an incredibly hard balance to strike, I stand by "no market" - at least for a product _specifically_ aimed there.
aka "operation" vs "design". I agree, for targeting that explicitly as a pedagogical or philosophical end in itself.
A cool ideal, btw (though I think it works better with less powerful programming - more concrete, perhaps only regular or context free not turing complete).
In real (non-coding) life, there's usually overlap, of "adjustments". e.g. you're cutting tomatoes with a knife, and adjust the knife's angle, or your grip, or move the tomato, spin it on a vertical axis, rotate it, try sawing vs slicing, maybe change knives, etc. Perhaps you exclaim "This is the best knife for tomatoes!" and resolve to use only it henceforth. But many of these adjustments are unconscious, and part of everything we do. Is it "operation" or "design"? I think it's fuzzy in practice; we often chip away at things as we learn and adapt.
True, in software, there's usually a sharp line between user (operating) and programmer (designing). Customization crosses that line: macros, templates - even, hiding menus you don't use.
Is hiding a menu "programming"? While not turing complete, it's a step closer to it.
I agree there's not much market for the combination, in itself. Programming is so accessible these days, if you want to do it, you just do it. Probably starting with HTML "programming", then Javascript or PHP. It even looks like a real website! It's like hypercard, but global.
Btw, I'd love spreadsheets-as-apps replaced with something more maintainable but they also have a huge advantage: you can start using a spreadsheet with zero programming. Unless you copy that, you can't compete for that niche.