What most people seem to be arguing is either that the people currently using Excel and VB6 should suck it up and learn a real language or that they shouldn't be programming at all (I'm not saying you are, but this is the general sentiment I encounter in eg http://developers.slashdot.org/story/14/07/09/131243/normal-...). There are number of different spheres of programming with different requirements. For the sphere of end-user programming (which Jonathan Edwards explicitly calls out in this post) there are a huge number of people who have to choose between simple tools which don't work well or complex tools that they don't have the time to learn. This sphere has seen little change since the start of the millennium (Excel is still the best option by far, for all its limitations). The OP is arguing for efforts to close the gap and produce simple tools for their simple needs.
"What most people seem to be arguing is either that the people currently using Excel and VB6 should suck it up and learn a real language or that they shouldn't be programming at all"
And why is that such a problem? If you can handle excel and vba you can learn to program. A lot of existing languages are easier to learn than excel+vba.
Excel is not easy to use if you want to do anything moderately complex. Even after years of training all through school and in the workplace the average user can't do much programmatically with it.
Excel solved the input/output problem, the availability problem, and the business acceptability problem.
By that I mean business users were doing a massive amount of data entry and data manipulation mainly in order to do simple calculations and view data logically in tables. They did this without thought to automate but it made automation 10x easier.
As a business grunt I can't just install python and start cutting code. If I said "Hey boss I can automate this with python. It will only take me 2 weeks" I've got no hope. For starters corporate IT wouldn't even let me install python. But I can spend a month fiddling around in a spreadsheet to automate the same task and my manager will be happy.
> It's not just programming that is hard, it's editing, debugging, compiling, version control, packaging, deploying, upgrading etc. Existing tools give you a huge amount of flexibility and power (that most end-user tasks don't need) at the expense of a brutal learning curve.
Sure, I agree all of those steps are painful, and I think everyone here agrees that anything that can improve them is welcome! At the same time, some of them only exist in specific contexts. For example, is the guy writing an Excel macro not bothered about version control because Excel is an easy-to-learn tool that achieves simplicity, or because he isn't building something collaboratively with a team of 5 other people, all working on the same task?
By the way, I read your article. I fully agree with this:
"Finally, environments can't be black boxes. Beginners need a simple experience but if they are to become experts they need to be able to shed the training wheels and open the hood. Many attempts at end-user programming failed because they assumed the user was stupid and so wrapped everything in cotton wool. Whenever we provide a simplified experience, there should be an easy way to crack it open and see how it works."
I'd add that they also need to be able to reach for the complex tools once they've mastered the simpler ones.
I think you misunderstood my point somewhat. I'm not saying that Excel solved the version control problem - far from it. Manual version control by emailing copies of spreadsheets was identified as a major cause of errors in various studies.
My point is that for end-user programming to work we need version control, deployment, packaging etc to scale down as well as up. The software industry has a tendency to fetishize scaling up and ignore scaling down.
Experienced professional programmers still struggle with git in their day-to-day workflow (http://www.sussex.ac.uk/Users/bend/ppig2014/13Church-Soderbe...). The average end-user has no chance. Even if the underlying data model is something like git, the experience for the user needs to be more like undo-tree or etherpad.
Excel smooths the learning curve for calculation/simulation - you can get started by just putting in some numbers and learning a few basic functions. If that's all you need, that's all you have to learn. I want to see the same pay-as-you-go approach for all our tools.
It's not just programming that is hard, it's editing, debugging, compiling, version control, packaging, deploying, upgrading etc. Existing tools give you a huge amount of flexibility and power (that most end-user tasks don't need) at the expense of a brutal learning curve. They make complex things possible but easy things tiresome. Consider how long it takes for the average CS undergrad to reach a point where they could build, deploy and maintain the simple webapp I described in that post.
There is definitely room for a simplified set of tools that lets end-users build simple applications with a pay-as-you-go approach to complexity and learning curve.
>There is definitely room for a simplified set of tools that lets end-users build simple applications with a pay-as-you-go approach to complexity and learning curve.
You want this to succeed, then pick a domain and solve that problem for people.
It's not the source control that is the primary problem. You can do Excel-like things on Google Drive, which has integrated revision control, shared editing, and a dozen other features to help the average user or team get things done.
No, the primary problem is that most people don't know what they want. They don't even know what's possible, much less how to accomplish it. Ask any consultant and they'll agree with me: The first thing you need to do is figure out what the users actually can use based on their needs.
It's like Henry Ford said: If you asked users what they wanted, they'd have told him they wanted a faster horse. [1]
The problems exist because they aren't easy to solve unless you have the expertise. I'm not poo-pooing Excel or any other domain-specific solution. If you can create a general solution to a problem (say, for example, WordPress), then users can plug together the pieces they need and create an app.
But there is no "language" that will solve the "average person can't program" problem in the general case any more than there's a paintbrush that will solve the "average person can't paint" problem.
