> making a big fraction of users into programmers is that we don't know how to do it
It depends on how you define "programmer." At Microsoft in the late 90s/early 00s we were very happy that there were so many Visual Basic programmers, but several million of those included people who would not self-identify as a programmer. That is, they were people who would write VB oneliners in either Excel or Access; people who would make or modify "keyboard record & replay" macros; etc.
I agree that trying to make everybody a full-blown systems or application programmer seems like a very hard problem.
By "programming" here I just meant someone who writes (or modifies) even a small amount of code. We found that this was always an extremely small fraction of users, even in the easiest cases.
I certainly agree that self-identifying as programmers would be totally the wrong criterion.
Consider the number of people today who edit a URL in their browser location bar (for example to delete unnecessary trailing information if they are going to email it, or to try to fix it if it doesn't work). I bet a good study of a representative user population would find that only 10% or less would do this even if it was suggested.
If someone is willing to do that I'm willing to consider them a programmer in this context. They have made the basic leap to understand how to map between text and behavior, how to debug, etc.
Not sure about it constituting programming, but that (awareness of being able to manipulate the resource portion of a URL) does strike me as a good litmus test of general power-userdom.
Funnily enough, starting from Yosemite, Safari has started to hide that portion until you click into the address bar.
I don't think it's even a matter of definition. Most people just don't want to program computers. They want to just sit down and use them. If they really did want to write programs (in any way you define that term), they would: the tools are available. A few people explore macros, etc. provided in sofware such as Excel, but most people don't, and it's not because of the tools, it's because they just don't have the need to do it.
Those of us who became programmers in part because of discoverable built-in programming environments would argue that even if only .5% of users do any programming, the inclusion of those features is worthwhile because the other 99.5% of users will benefit from the code written by the few who were inspired to become programmers.
Design for extremes: if you make stuff for people who hate programming, that will make it easier for people who love it. You may end up coming up with ways to boost productivity (and fun) for people you never even thought about before:
https://books.google.com/books?id=idNhCcrANP0C&lpg=PA57&ots=...
Like the philosophy of the book, though the examples are really old school. I don't think the operative dimension is "love" vs. "hate" -- more like "can easily handle" vs. "find difficult".
But I don't see how to apply it to programmability -- and I don't think Apple has found any way. How could you make something programmable for people whose eyes slide over a URL without being able to see its parts? (Note: they maybe are willing but they can't, just like grandpa can't make his hands stop shaking and get the key into the lock. Naturally after enough frustration they come to "hate" whatever it is.)
It depends on how you define "programmer." At Microsoft in the late 90s/early 00s we were very happy that there were so many Visual Basic programmers, but several million of those included people who would not self-identify as a programmer. That is, they were people who would write VB oneliners in either Excel or Access; people who would make or modify "keyboard record & replay" macros; etc.
I agree that trying to make everybody a full-blown systems or application programmer seems like a very hard problem.