The problem of getting from the East coast to the West coast has not changed in 100 years (move body until done), yet when was the last time you had to set the spark and choke and hand-crank a car? Cars solve real problems, and today's cars are sophisticated enough that essentially anyone can use one. To solve real problems.
Certainly the problems solved by a car are in a more narrow domain than programming languages. But cars themselves are in a narrower domain than internal combustion engines.
Edit: stealth.
Further, a car is simple to use out of the box, but customization beyond do-dads and bling? Nope, not really easier than it ever was. Different tools? sure. Different base skills? not really. Anyone can do it? Not so much.
And before I go into tech equivalencies here, if you think cars are pretty much the same and can be abstracted to "the car" for the purposes of this discussion, go buy a van or pick up truck. Watch your social graph get all buzzy and see the request pour in for help, turns out your form of tradeoff in "car" are very very useful to people, and suddenly a car isn't just a car.
Further, I would argue that we have done wonders for the tech equivalent of "car". We have amazing computation devices in our pocket that just do what people never knew they wanted to do in the form of "phone". We have awesome abilities to have web presence unthinkable (outside of internet famous blog machines) 10 years ago, in the form "social graph". These are great and just work for most people, until they need something different...
In the infrastructure department: the ability to do semi-custom stuff has grown in ways unimaginable in the car world. Need a website to do your magic? Here are a bunch of platforms like app engine or heroku, all you need to do is get your custom stuff in place, don't worry about the machinery to feed it. Up and down the customization level there are more entry points as well. Going back to the car world, how easy is it really to get a ricer put together? How easy is it to put in crazy hydrolics or a good thumping stereo system? Need to rip off the doors, reshape the body and put in a different engine? Good luck getting a doctor to just do that without serious learning curve.
Basically, my point here is that hard stuff is hard. If it isn't your specific field, it is easy to just blow off the stuff that caters to the masses as "they made it easy", and at the same time, it is easy to blow off the stuff in your field which caters to the masses as "not done well".
Final thought: a lot of people look at cars and computers the same way, as soon as the littlest thing goes wrong, they freak. or they take it to the mechanic who asks "why haven't you changed the oil in 7 years? (c.f. our IT guys who ask why they don't have anti-virus installed).
Exactly my point. They didn't use to be simple. Crank, choke, throttle, water in the battery, where's the next fuel repository, where are my goggles, where is the rug for my legs, etc. Now they are, and you just think of moving your body from here to there, and almost not at all about how to make your car help you do that. Now people use a car casually.
It's that kind of change, only much more profound and difficult to achieve, that will be needed before people can "program" (if we still call it that) computers casually.
So, perhaps computers themselves have progressed much like cars. It is now possibly to use a computer casually. But programming per se is significantly less casual than it once was.
I wouldn't know an opcode from a gerund, and I don't want to know.
Now I can Write a Program for Dummies, or I can write Python the Hard Way, or I can <script>alert('hello world')</script>, all as close as https://encrypted.google.com/search?hl=en&q=how%20do%20I... while holding a sandwich in one hand. That's not as casual as the OP would like, but it's pretty darn casual compared to The Day.
Edit: vocabulary.
I remember what it was like beginning programming in the 80's and trust me, it was much harder then.
Back then BASIC was the only language I could get for free. In order to learn C I had to (1) buy an upgraded version of my computer (CoCo 3) that had more memory to run an OS, (2) buy the OS-9 operating system (3) buy a C compiler for said OS (4) buy the K&R book. In total, I think that cost around $400, which explains why I didn't learn C until after I graduated (EE, not CS) and had a job to pay for that stuff.
Last year, to learn Javascript I opened my browser, got a free download of Notepad++, searched a Javascript tutorial and began programming. If I wanted to learn C from scratch today, it would be as simple as downloading gcc. Not to mention that expert help if I get stuck is all over the net.
Getting started in technology, at any level I can think of, is much easier today than at any time in the past.
My point was that you now have to go out of your way to learn to program. There are a lot of options, and casual programming involves a lot of libraries (which usually themselves depend on libraries). Those microcomputers were very inviting in that regard.
But computing problems _have changed_. Not necessarily in areas like problem size (although that has happened) but also in areas of usability and convenience.
A much more apt analogy would be: the problem of stopping at the grocery store after work is 50 years old, why can't I get an optimal set of directions that accounts for rush hour traffic in 2012? I can give you any number of reasons: we've built more roads, there are more drivers, travelling salesman turned out to be a hard problem, game theory is hard, etc. In some dimensions (cranking the car, proclivity of gas stations, etc.) the situation has improved, but solving some problems re-emphasize the ones we haven't solved.
Software is not really comparable to cars because it's not a solution -- it's a tool to build solutions. Comparably, we have devised easier ways to drive nails into wood (nailguns instead of hammers), but nails still exist and have to be driven into wood. So I don't think software will ever really be casual, just like building construction will never really be casual. Just too many variables to take into consideration.
You do realize that this is like saying "certainly two times N is smaller than two to the Nth power"? ;)
That said, I enjoyed reading your very insightful post :)
Implied inside your question is the idea that we can, in advance, choose the right level of abstraction. That we have a library / language / set of verbs that is neither too high level (like Automator) nor too low-level (like your bash script example) to solve the problem. While I think we can improve a little bit on the set of abstractions that we have, I think a broad solution is naive.
As a point example, I used to be frustrated that so-called 3D engines tended to grow until they included the kitchen sink. Why do I need a menu system as part of my 3D engine? Why do I need a sound engine? Can't I just use system libraries like a sane person? etc. All I want is a set of primitives that let me render models to the screen. How hard can it be?
It turns out that the problem of rendering graphics to a screen quickly is so hard that it actually infects the hardness of other problems. Doing elastic collisions is a trivial thing that any first-year physics student can do. Until, that is, your game loop skips six frames because it's busy rendering graphics code, at which time you need to retroactively handle collisions that have occurred in the past. Now we're doing rocket science, and so your graphics library needs its own physics system, because you're not going to derive that stuff. And that, basically, is the story of every feature added to every serious game engine that exists today.
You see this problem everywhere you look, for example, at one point people thought POSIX and C were reasonable building blocks that everyone would use, and at another point people thought that about Java. At first, BSD sockets was the primitive, now we're starting to think about HTTP connections as the primitive, maybe we should work to make REST requests in Python not suck so damn much? But at this point SPDY looks like it might be turning into a thing, so maybe we should just build primitives for that instead? If you look at this staggering tower of abstractions you start to see things that seem crazy, like SPDY including its own flow control even though TCP already has it, because TCP has some bad assumptions that should be really be fixed at the network level, but will never be fixed there as a practical matter. I hope you followed Inception, because if not you're gonna have a bad time.
I'm doing a bad job of explaining this, but I had this insight first after reading an article by Kamp, the author of Varnish: https://www.varnish-cache.org/trac/wiki/ArchitectNotes. He makes the argument with a specific example that as we have moved to higher-level primitives, we've built an overly simplistic mental model of how the lower-level ones like OS and hardware work. As a result, we implement our own caching code, because we've forgotten that OSes were designed to do that for us. So in a sense we have more power because we have this nice set of high-level primitives, but in practice we've forgotten all the things that those primitives wrap, we've started to believe that they are simple because they look simple. And so, we muddy up our application code with all this stuff that has already been solved.
I doubt very much that there is any software program that people actually use that is not either undergoing a big refactor right now or has one scheduled, either to make things "simpler" (less abstraction) or "more powerful" (more abstraction). Just thumbing through the projects that I work on, I am adding features to a mental backlog for a future refactor for every single one of them. This seems to be like a fundamental problem that all software projects have, and creating a new set of primitives and saying "no seriously, that should do the trick" is at best going to yield a nice little language like Python or Ruby that somebody will post articles about on HN saying why it's so hard for casual use.