Why programming isn't for everyone

on mouseUp
  get name of me
  put the value of the last word of it after card field "lcd"
end mouseUp

I've long thought that the real issue is that that isn't English, and no matter how much you make it look like English it never will be.
Come the day when a programming language looks exactly like English it will still have the property that the computer will do what it's told with an attention to detail and reckless disregard for actual intent that would put any lawyer to shame.
Programming fundamentally requires a level of precision and detail of thought that most people aren't prepared to deal with.

@Tolomea: I think that programming strong AI, that could guess your intent or ask you when you're not clear enough, etc. is still gnarly. Basically instead of programming you now have something like a project meeting – the AI says, "OK, but what about the old files?" and now you have to think together, ultimately whatever the AI proposes you must understand and choose between alternatives. I believe the core gnarliness lies in inspecting those alternatives. Another way of saying it is that a part of programming is a sort of "project management", that software tends to become a "project" requiring some sort of "management", and this sort of project management isn't for everyone.

"The main reason is that development leads to maintenance, and maintenance leads to suffering."

Reflection on the contortions "normal" users go through to achieve things shows that this statement is bunk.

Tools that bring more power to these users are good things, and HyperCard was one of those tools. The most common programming tool (used by non-programmers) is the spreadsheet. Users create immense works that are an incredible pain to maintain, but they do it because it is the only choice they know they have. "Fun" doesn't come into the equation.

Spreadsheets is an interesting borderline example to discuss.

Human languages suffer from a lack of precision. You can tell what I want to say if I use bad grammar or the wrong case. Even if a computer is made to understand those imperfections, it seems rather unnecessary. In my opinion, an English-like syntax such as the one in your example is actually *less* readable than (non-esoteric) programming language syntax.

@"This never ends and quickly stops being fun"

Sometimes, but not all code maintenance is tedious. Refactoring a mess of poorly written unruly code is a bit like cleaning your house; it seems mostly boring at the time, but once you're done and can look out and see poorly designed buggy code suddenly become a well crafted bug free architecture, there's certainly a feeling of enjoyment.

Although on second thought, I'd say the enjoyment factor of fixing a bug is somewhat close to a ratio of time spent vs code modified. Days where you spend 4 hours tracking a bug down only to realize that there was only a single line of code you had to change... those just suck.

@saurabh: I agree as far as my own taste goes; the upshot is that whatever one's taste, it's possible to make language syntax or some other sort of command interface fairly understandable to people who aren't deeply involved with computers.

@PherricOxide: I think that this sort of enjoyment is a "second-order" thing happening to people who do lots and lots of this sort of work. You aren't enjoying because that's what you came to do, but because you've realized the inevitability of what you're doing and how much worse the alternatives are. I think it's an acquired taste, and it's only acquired, together with proficiency, through a lot of experience.

Check this post, this guy is actually working since 10 years on what he calls "Conversational Interface". http://wesnerm.blogs.com/net_undocumented/2012/01/conversational-interfaces-redux.html

I think you are right that the main problem is maintenance. I don't think there is a general solution. All you can do is minimize the maintenance needs by making the simplest program with the simplest IT stack that will solve the problem.

IMHO this is also the best way to make programming accessible to approximately everyone. First you assume that they understand their problem domain and the problem that they want to solve. Then you give them the simplest possible computer so that they don't have to spend any more time than necessary learning how to program it.

They will have to learn how to program though (ideally after learning the basics in school). There is no way around it. English syntax programming languages and the entire galaxy of related ideas for making programming look like something other than arranging instructions for a (more or less) formally defined machine to execute are completely wrongheaded. To say it is an AI-complete problem is a vague underspecification: what you would need to do is provide the customer with an entire automated developer (so you can have the project meeting type discussions Yossi mentions in comment #2). Not only do you have to figure out how to do that, but you have to figure out how to do it cheaper than a meat developer. Then it produces an overly complex program that is a maintenance nightmare, because it doesn't know as much about the problem as the customer, the developers ran out of funding after implementing the programming skills and didn't have time to give it the best communication skills, and it is motivated to justify its electricity bill and the enormous amortized cost of its development rather than being motivated to making the simplest possible program so you can get back to thinking about real problems in a real domain.

Is it possible to make very complex machines that do not need much maintenance? Yes; they are called microprocessors. Microprocessors are expensive, but most applications are not as complex as a microprocessor and are much easier to do some maintenance on if it's not quite right the first time. And you don't need expensive fabs for software.

I don't know for sure that anyone could write small applications without needing to learn what amounts to a second career's worth of skill given the right K-12 education and a reformed software industry, but I think it's plausible. Perhaps more plausible are specialized meat developers who can write simpler programs that don't require so much maintenance. But maybe you'd have to reform the software industry (and possibly also K-12 education) just to get that.

And maybe that's all Marxist engineering utopia nonsense. Here's an alternate theory: People are cheap enough, and software is cheap enough to copy and distribute, that it's usually business optimal to pay specialists to talk to the domain experts and then quickly crank out buggy software to sell to as many people as possible, and in the rare case when you want software that you can't sell to very many people, it's still business optimal to pay specialists to talk to the domain experts and then quickly crank out buggy software because that's what they know how to do and that's what the system is set up to support because that's how to make money in the general case. In other words, there is no business case for getting everyone to program (or for writing programs that are easy to maintain, most of the time).

"it is motivated to justify its electricity bill and the enormous amortized cost of its development" – and that's a pretty optimistic scenario; it could as well try to take over the world, starting with infecting everything connected to the net with malware while it were at it :)

Everyone knows that C/C++ programmer gets most thrills from writing main() function (i.e. writing new code), not from maintaining and refactoring old code. That's why there are so many open source programs that cannot get to 1.0 release, but end up being constantly rewritten from scratch until the developer finishes college (has no more spare time) or gets bored with it and starts a new project.

The no-fun part of programming (read: maintaining) is not the only part that keeps some people from writing software. I think there is a bigger reason: some people simply think in terms less structured and organised than computer programs. Some people think in ideas and pictures they have trouble communicating to other people (even when those other people are attentive and willing to surmise or ask for clarifications), not to mention cold and strict machines that computer are. You know the saying: computers work as programmed, not as intended :-)

I, too, think that the programming language is not the main barrier. I think the effort needed to describe the problem and specify the needed result (so one does not get a million possible answers from a computer and has to dig through them to get the one) may for some people be greater enough to discourage them from using a computer.

I agree about the programmed vs intended part, I'm just not sure how bad it is on average. It seems as though a lot of non-programmers "get it" – see computers for what they are and realize the need to be precise in their instructions.

I agree writing long-lasting or large programs has the problems you describe, but do I think there are a lot of use-cases for one-off scripts that people could write and find interesting/useful, if they knew only a little bit of programming, in an environment that was vaguely accessible to them.

When given a suitable environment, even one that is broken in various ways, people do actually do so: many "non-programmers" in office settings write reasonably complex Excel macros, because Excel is there, has a macro language, and the barrier to entry is low enough that you slip into programming somewhat accidentally, when all you thought you were doing was editing a spreadsheet. Processing has also been somewhat successful in getting media artists to consider writing bits of code a legitimate thing they could do.

@Mark: I think the trouble begins when you start interacting with the larger environment – exchanging data, networking, that sort of thing. Scripting inside a reasonably closed environment has more chances to be "one-off".

To me, in this context, a "non-programmer" is someone who is doing very little programming – someone who spends much time programming is a "programmer" whatever his education and skills are. So the question to me isn't how easy it is for someone without special education to get into programming but whether they can get out :) – how much time maintaining those Excel macros is going to cost. It could be that diving into Excel macros is a net gain in a number of cases reasonably large to be interesting; I do believe that the majority of MS Office users do zero scripting, so in this sense Excel definitely isn't a programming platform "for everyone" nor is programming becoming similar to literacy either in its utility or in the extent to which it is widespread through Excel.

Basically all I'm saying is that users will forever be the majority and programmers will forever be a comparatively tiny minority, no matter what tools are available. Perhaps a close analogy is what happened with cars: you could once repair them yourself whereas today many things are infeasible to repair for the owner, however, even back in the old days many people would rather not touch their car (I'd be one of those people for sure...). I think that with time, computers will similarly become less accessible to people and lamenting the demise of systems such as HyperCard is a bit like lamenting the demise of manually repairable cars.

I appreciate the perspective here. But I think things have and are changing in the world of software. There are always new technologies to use and upgrades, along with a stronger product focus in software nowadays, that can be done that when mixed in with maintenance to make the whole experience fun.

One thing though, your comment "However, I don’t think businesses have the power to prevent anything that works well for many people from happening." isn't quite right. Apple is leading the way for others to stop any such tinkering and their chief weapon is software patents. If someone can successfully patent the switch and "drag and drop" (I think Apple calls it slide to unlock), we are in deeeeeep trouble.

Much as I dislike software patents, they don't seem to prevent tinkering; Apple can prevent people from sliding to unlock, but not from running a root shell on their Android phone. More generally it seems that up until now the ability of software patents to stop competition is limited, though of course it could get worse with time.

Think it is also a mental issue: some people just don't "build" things generally. Some people do, just don't get the same enjoyment of "building something" that hackers tend to get out of getting a working program.

Also, much like some people can't put a Lego car together that doesn't shatter or break during transport, some people can't really put the logic behind 1+1 together to make 2 come out reliably. The first type of people doesn't have the intuition for shape and form that make a Lego car stay a Lego car instead of reverting to a pile of bricks; the second doesn't seem to have the intuition that builds a clear mental model of how a program is supposed to work, how control flows, what happens when etc. etc. So for them programming is a constant pain of compiler errors, inexplicable bugs and the program never quite working reliably.

So even if they did enjoy building things, trying to program tends to be off putting — too much pain, and no real gain.

I for one don't much enjoy working with the soldering iron: I perfectly well what the end result should look like, yet somehow after way too much time it's far too much tin and a few components soldered the wrong way round. Admittedly I've not done much soldering, but I can already tell that it isn't going to be my favourite thing in the world.

Could be a lot like that; the question is how much tools could help. What if you could get a device that took the gnarly parts out of soldering – would you do it more often then? What if people got environments where the gnarly parts are taken out of programming? So here I think the gnarly parts are basically too much part of what the whole deal is about.

Yeah but at the core the gnarly parts of soldering (much like programming) is the issue of doing your best yet still have it come out all wrong.

If you give me an automagic tool that takes my circuit diagram and solders it properly (thus removing the gnarly bits), then great, but what you've just done is handed me a preprogrammed Excel spreadsheet and told me to fill in "these values over there in those columns, then click that button — it'll work". It's not the way actual programming or soldering lies.

There's a sizable number of people who never, ever, will have to worry about most of the things programmers would consider the "gnarly bits" because they don't ever reach that stage in their programming efforts. They've given up or in case of engineering/CS students been told firmly not to bother with the second year before that point already.

In fact, this "why can't people program" issue is a fairly significant area of research in CS departments because, since about the first CS departments ever sprung into existence, this has ever been a major obstacle for first year students. First years' first programming course always comes out with a fairly predictable two hump curve in the distribution of grades. One is the "can't program" lot, who despite about 30 to 40 years of research into making programming more accessible (and hence improve their fate at the first course), still flunk the course with 2-4 out of 10 points. Then there's the "actually pretty good" lot who predictably score a sound 7-8 out of 10.

They do that whether the course was Pascal, Java or Scheme to mention a few popular first course languages, they do that whether to tools amount to a text editor and an interpreter in a console window, an industry IDE like Eclipse or NetBeans, or a connect-the-dots "teaching tool" such as BlueJ.

There's this real, gaping void in understanding between people who can't program and people who intuitively can. It's not impossible for someone to make the leap, but you can definitely feel it as you gaze in utter disbelief when you see someone struggle with things like variable assignment that are so... simple and obvious?

It's not a benign kind of gap either: it's intimidating. Any time you want you can re-experience some of that unease about your own code and about the time and effort it takes to do even the most trivial and boring of things.

Always been an imperative "destructive update" kinda guy? Learn XSLT. You'll weep for "proper" variable assignment. PHP the way the world is supposed to work for you? Then try some Haskell. Spoiled with an actually helpful tool chain? Try debugging a couple of "move or conditional jump depends on unitialised variable" or "invalid reads of size 0" type valgrind errors in a moderately complex C++ program, should be good fun.

Now about that last example: the point is not that the toolchain is going to be less than easy on you (due to not actually having a clue about the real problem either). The point is: you are going to have *no idea* on how to fix it.

To overcome such obstacles takes a basic attitude and skill that no tool can ever "do for you".

Looking at that english-like snippet makes my head hurt, would anyone honestly say it'd be easier to use that syntax? It looks like a mess, and a mess with nothing but undefined behavior; the uncanny valley of syntax. We can't even perfect computer-translation, let alone have a computer act on what it is translating. The day that english-like syntax will be viable, is the day that books can be scanned into the computer, and entire games created... until then, it's so much easier just learning a (thankfully) strict syntax.

Post a comment