It's one thing to take an approach like Apple Automator (a much beloved automation environment), but it's another entirely to say, "General Purpose Software should be within the grasp of the 'average person.'" It's not clear that the goal is even reasonable! A lot of software, to do what it does, requires the use of complex mathematics, algorithms, and cryptography that frequently even the implementors only vaguely understand. Manipulating those in an abstract and correct fashion is difficult in the extreme (e.g., the morass of timing attacks that have plagued modern implementations of cryptographic protocols). We can barely make software with smart people!

Yeah, you are exactly right. Programming languages need to be designed for the very best programmers -- they are the ones that need the productivity boost. For me, not understanding the language is never a problem. Making something "easier to understand" will not help me write software that goes together faster or ends up more reliable. It often has the opposite effect; Java's lack of ... everything, for the sake of simplicity, really slows me down. Comparatively, learning a new concept is much easier. If I start using a library that uses Arrows, I read the Arrow paper, spend a few days playing with it, and then I have one more tool that will help me be more productive every day for the rest of my life. Making a language that doesn't have arrows saves me reading a paper about them, but it wastes my time every day for the rest of my life.

So, "simple" programming languages -- do not want. I am not saying that you should start your "intro to computer programming" class with a long lecture about category theory, but I am saying that you should never hide things from people that want to know about them.

In terms of theory, I found the "Applicative Programming with Effects" paper and the "Typeclassopedia" very helpful.

http://www.soi.city.ac.uk/~ross/papers/Applicative.html

http://haskell.org/sitewiki/images/8/85/TMR-Issue13.pdf

I started doing a real implementation of these data structures in Perl this week. (I say "real" because people have "added Monads to Perl" before, but they didn't really add Monads, they just added a "programmable semicolon".) Anyway, in doing so, I saw in great detail the relationships between the various types (specifically "liftM2 ($)" and "<*>"), and tried to generalize things as much as possible. The result was something like Arrows, and that helped me understand the "why" in addition to the "how". Writing test cases was also helpful to me; using these esoteric stuctures in "real code" helped me build up the intuition needed to advance farther.

Anyway, it took me three readings of the Applicative Programming with Effects paper to get Applicative Functors, and after that, Arrows were pretty easy. So I recommend that paper, and lots of poking around in ghci.

To bring this back on topic, yeah, it would be hard to teach this stuff to Joe Average. But a language that allows it is still important to develop. (I also learned firsthand that language design decisions to make it difficult to implement certain features. Implementing the equivalent of "instance Monoid b => Monoid (a -> b)" is almost impossible to do cleanly, due to the polymorphism of "mempty"; it's defined in Haskell as "mempty _ = mempty", and in Perl, we discard the type information before we have a chance to pick the "second" mempty.)

While I know that there are a lot of horror stories (and I can tell a few), some of the most productive "programmers" I've ever met used MS Access or Excel.

If you don't consider advanced usage of these applications as a form of programming, then you are illustrating the point: It is not only possible to "dumb down" programming, it is inevitable. So much so that you haven't even noticed it happening.

I'm talking about "general purpose software," which encompasses a huge volume of space. Rare is the person who can competently address the wide variety of problems found in the world of software. Excel and Access, in my view, are perfect examples of paring down the acceptable problem space to something reasonable and making tools for people to solve those specific problems naturally. You can't write a 3d engine in excel, but that's okay, because the tool is not for that.

But this argument breaks down when you try to take it to a general-purpose software kit, which has to handle anything and everything. In this wide, unshielded world of hard problems you have to have the most capable and powerful tools available. Deliberately limiting tools in this environment is like saying, "Our river pilots have lots of experience handling barges, so it'd be counter productive to train them on oceangoing vessels, we'll just build bigger, sturdier barges for ocean travel." Yes, sailing on the open ocean requires more powerful and complex tools, but you appreciate those tools when the ocean gets rough.

You can, a guy has done it. I'm only being pedantic because this is cool if you haven't seen it:

http://www.gamasutra.com/view/feature/3563/microsoft_excel_r...

So what? The goal of turning every user into a programmer is perfectly reasonable. Almost all users of the early systems and computers were also programmers. Even today, business users make use of Excel/Access and some macros to do some programming (even though it can be seen as basic).

Don't you remember a time when operating systems came with programming languages and compilers and actively promoted them to the user?

Oh, and HyperCard. There was another great example of "user's" programming. I've also seen some hideously ugly GIMP script-fu scripts but they worked and did the job of the "user" that wrote them.

In the end, the distinction between a user and a programmer is artificially created by software that doesn't view anybody else as smart enough to enter the monastary of the programmer.