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).
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.