Co.Design

Why Aren't Computer Programming Languages Designed Better?

An experiment by computer science researchers shows that Perl, a major commercial programming language, is no more intuitive to use than a fake language with a completely random syntax. What gives?

For many digital products, poor user interface design and UX can sink an app’s fortunes even if the underlying engineering is powerful and innovative. (Remember Color?) But what about the interfaces behind the interface, the ones that developers spend hundreds or thousands of hours interacting with while they build software for the rest of us?

Yes, I’m talking about programming languages. Unless you’ve had specialized training, looking at lines of code is like reading hieroglyphs, only less intuitive. According to findings by researchers from Southern Illinois University, this reaction isn’t just because you’re a n00b: they found that Perl, a major programming language used by untold zillions of developers, is no more intuitive to novices than a language with a randomly generated syntax.

Let that sink in. Programming languages are tools, designed by people for a specific purpose. What this study showed is that the design of this particular tool, Perl, is so ridiculously opaque that, from the perspective of a novice programmer, a string of characters bashed out by a monkey at a keyboard would literally make an equal amount of sense. Ouch. Of course, the researchers didn’t set out to take down Perl. They were running experiments to determine the usability of Quorum, a so-called "evidence-based programming language" whose design was informed by surveys, usability studies, and field tests. "We have observed that novices learning to program at the university or younger levels can have significant difficulty learning the syntax of general purpose programming languages, which may initially seem arbitrary," the authors write.

They created a "placebo language" called Randomo, whose syntax was randomly generated, to use in trials alongside Quorum and Perl. Novice programmers were able to write sample programs more accurately in Quorum versus Perl--an interesting, but not terribly surprising, result. More surprising was how Perl compared to Randomo. To quote the paper: "Perl users were unable to write programs more accurately than those using a language designed by chance."

I asked Andreas Stefik, the paper’s lead author, what design attributes an "evidence-based programming language" like Quorum had that made it easier for novices to use accurately. He said that their usability testing showed that simply finding natural-language replacements for some of the more abstruse syntax went a long way. For example:

integer i = 0
repeat 10 times
i = i + 1
end

That still looks mostly like Greek to me, but Stefik compares it to this equivalent statement in Java ("which is similar to Perl is some ways," he says):

for(int i = 0; i < 10; i++) {
}

That’s not Greek, it’s Klingon. The Perl version uses fewer characters, which many geeks would no doubt see as more efficient or precise; but Stefik says that the Quorum version accomplishes exactly the same commands. "I think that whenever you make a product design simpler there’s a potential danger of removing features that experts need," he tells Co.Design. "We are trying very hard not to do that."

So why aren’t all programming languages designed this way? "I doubt that most language designers meant for their languages to be hard to understand or use," Stefik says. "The problem is that programming languages are created either by committee or by extreme technical wizards with magical math powers. The broad computer science academic community has not paid a tremendous amount of attention to programming language usability. I think that our discipline mostly uses anecdotes to argue about programming languages. As such, it is no wonder that the arguments get heated."

Startups like Codecademy, which aim to teach non-coders how to program, are white hot. Would they be necessary if the programming languages themselves were better-designed? Probably--Python may be considered "easier" to use than Perl, but it still takes some hand-holding to get started with. But evidence-based programming languages are a fascinating variation on the traditional practice of UI design. Every piece of software we use was written by other people, slaving away over thousands of lines of code. Why shouldn’t those "interfaces" be as humanely designed as the ones we tap and swipe?

Add New Comment

104 Comments

  • Nick Reyntjens

    I am designing a system based on nesting folders that allows end user to build applications. It is very simple yet very powerful and filled with semantical and physiological aspects. The people here will like it. I believe I have done a good job at 'designing a programming language'

    It is an essence a file system that can calculate: http://www.solebase.comIf you like it please write about it or post it. A startup can use all the help it can get!

  • Cinilak

    What a bunch of nerdy comments. Yeah this guy technically doesn't know what he's talking about, but you know perfectly well what the point is that he's trying to make.
    I bet most of people here prefer shorthand syntax just to show how hard core they are. Speaking as a programmer, computer programming is not that hard - once you know it. Learning humanly unreadable syntax and undeciferable programming logic is. It puts most people off programming as they weigh if it's worth spending months learning something that seems from another universe or going for that easy to get career in retail or office admin. Let me tell you something about my fellow developers; every time you meet one, each and every ones got the world figured out. All the variables in their existance are static, and OMG please don't ask them a stooopid question. Worst mistake.A typical conversation revolves around the nerd trying to outsmart you, whilst demoing the best of his borderline Aspergers social skills. Whilst doing highly paid jobs with skills you can pick up on the internet, hardly any of them offer to share knowledge and help train their friends who are currently in manual jobs. Instead they prefer to peacock their "skills" and spend their time continuously scanning for other peoples slip ups in conversation so that with force of Thor's hammer slam down anyone with their "superior" intellect and shine on their throne. We need a world where people can automate things, not jump to hoops in order to learn how to program a machine. This might have been ok for the last 40-50 years, but the future is now. Even Bill Gates said in his AMA reddit that he is surprised that programming languages aren't easier to learn by now, or something in those lines. Efficiency of code is preventing us from simplifying languages?Please. 90% of code produced today aint google or facebook. Not every application needs a 1000 file framework and super efficiency which sacrifices readability of code. I'm not saying lets get rid of frameworks and efficient code, I'm saying lets find ways of getting anyone we can into programming. I genuinely believe it will make a world a better place. We need a planet of thinkers, not deadweight lever pullers. 

  • Jt T

    BRAVO!!!!!!!!!!! But, if you look at the way most people speak English now, I see little difference between that and most basic programming languages. The programming languages shouldn't be THAT hard for them :D

  • Mjaksen

    True but irrelevant. C/C++ *IS* a terrible language to express oneself in, but it's pretty good at organizing large software projects and interfacing with all the link libraries and shared libraries that it needs to get the job done. And yes, C/C++ isn't great at organizing large code and projects or interfacing to libraries either, but it's good enough.

    I have *never* seen a language that is concise, contextually clear, and easy to read, that can also organize code/objects/threads/errors and place nice with the os/shared libs.

    Another commenter posed the idea of contextually useful code vs. the normal procedural crap we usually use:

           user.users.each { |user| send_email_to_user }     **ex 1

    instead of

           for(i=0;i<10;i++) send_email_to_user(user.users[i])     ** ex 2

    Ex 1 seems better in that it expressed the actual programmers intent without regard to implementation. But I still find it counter-intuitive... not ugly, just awkward. Shouldn't "send_email_to_user" be the crux of the command, and not where the data is? so

          send_email_to_user ( |*| user.users )     **ex 3

    though some may find even that ugly or imprecise. Of course, to a programmer that is expecting FOR loops everywhere this may also appear annoying. And if I needed to iterate over users and a list of emails, the code is then confusing:

          send_email_to_user ( |*| user.users, |*| emails.letter )     **ex 4

    so there *really* is no pleasing everyone.

    Regarding the commenter who said that web apps are a collection of languages and technologies MacGuyver-ed together, well they are and they really shouldn't be. It might be nicer to have all those *other* tech interfaced into a object interface or unit so you could call it from the program neatly. I've *never* seen this done nicely. Normally it feels as jury-rigged as a warp drive made of safety pins and stone knives.

  • Guest

    This article is completely ridiculous, even though I can see what the author is trying to say. Just google this : "coding horror programming talent". You'll find so many entries basically saying this : "some people can not be taught how to code". Most likely because their brains do not process information like a real programmer does.

    You can find other references on the subject if you search the web...

  • Drew Brigham

    The key to understandable code (apart from being well structured..and formed..) is appropriate commenting.

    Oh and hopefully some unit tests, or TDD, and some autodoc....and maybe reSharper...oh and using common design patterns...oh and.

    Wait a second, this programming thing isn't just about the actual code!

    (o rly?)

  • Sitaram Chamarty

    I don't understand.  You wouldn't want random untrained joes to wire your house, why would you (or those Southern Illinois folks) think it's ok to let them *program*?

  • Simon

    The issue with writing software is not being able to program; it's being able to program *well*.

    There are a number of languages out there which have been specifically designed to be easier to write for novice programmers. What generally ends up happening is that novices then end up writing software, and the quality of the end product suffers as a result.

    I'm not knocking novices -- we were all novices at one point -- but I guess most companies have got somewhere an Access database system or simple VB6 program that they rely on for some task but which is woefully inadequate, or worse, a security minefield, because it was written by someone who didn't really understand the technical issues.

  • josh_cheek

    The Ruby version:

    i = 0
    10.times { i = i + 1 }

    But, why would you want to do something like this? Probably because you want to do something with each of these numbers. Most commonly in languages like Java, iterate over each item in some array (for non programmers: an array is an ordered list of items, accessed by their position in the list). Say an array of ten users that you want to send emails to.10.times { |i| send_email_to users[i] }Now you don't have to maintain the incrementing. Now why should you have to know you have ten users? What if you have eleven? And why should you have to access by index? Really you're just interested in doing something with each user.users.each { |user| send_email_to user }Much more readable than what either of the above would have done, because it has certain abstractions that are very powerful (in this case, closures). The lisp versions are even more powerful, but the syntax behind them is also more arcane (in Lisp, though, much of the power comes from the syntax -- it is not arbitrary).But more than being readable, it's implementation agnostic. What if your users aren't in an array, they're in a linked list? This line of code doesn't change. What if they're in a binary search tree or a magic object that isn't a collection at all, but maybe just wraps a file pointer and reads over each line? This code doesn't change, because it doesn't need to know the details of iteration. So easier to read and much more powerful.But, honestly, I don't think its the languages that make programming hard (though certainly they can facilitate / impede thought -- see Sapir-Whorf hypothesis). It's really all the tangential stuff you have to know. How your environment works, how to install the language, how to deal with the errors, how to set up the path, the source control, manage the dependencies, deploy to the cloud, connect to the database, etc.

  • Trpatri

    Programming languages are the least of your worries.  I write code every day in various languages, just to develop what appears to a user as a simple search application.  Knowing one or more programming languages is the least of our worries, and probably the easiest part of our job to learn. 

    Here is a typical list of technologies one has to know to deploy any reasonable size web 'application' these days.  Ready?  (We'll just stick with a Java shop on this example.)Java, JSTL, JSP, JavaScript, JSON, HTML, XML, XSLT, XPATH, XML Schema, HTTP, HTTPS (yes and all the gory details of PKI that go along with that mess), CSS, SQL etc...Get the idea.  That is only a sampling of what a web developed has to deal with on a daily basis.  I didn't even mention all the enabling tools like operating systems, editors, IDEs, Configuration Management tools, build tools (make, ant, maven) etc., that keeps it all humming along.  And patterns, don't get me started on patterns.  Notice how the core language, Java in this case, was only one of many players in this little concert of technologies.You can swap out the primary language for many others, but in the end, you are still going to have to make all of that other 'stuff' play nicely together.  It isn't easy.  Fun yes, because its a challenge, but it is not easy. The computer language is the least of the problem.

    So go ahead, learn a language. That is where one starts to become a "programmer."  Go ahead, define a new verbose computer language (been tried before and nobody uses them).  That is the small stuff compare to what it is really like to be a software developer.

  • Unclemilford

    This also fails to account for productivity.  Languages designed to apply to the masses tend to be extremely verbose and cumbersome.  I have to believe there is a direct correlation of productivity to number of characters typed (hence the point of a stenographer).  I also fail to understand this initiative of teaching programming to everyone, thereby forcing language architects to simplify for the masses.  I don't recall my mechanic teaching me how to fix my car, yet I drive that everyday.

  • Matt Popke

    This is a pathetically misinformed article. As someone who has degrees in both computer science and industrial design, I weep that this is being taken seriously by anyone. "Humanely designed" programming languages almost invariably suck. You simply can't express complex *executable* concepts in something like Applescript. That's why people go to school for these sorts of things.

    And it's not even the languages that are difficult to learn. A half-decent software developer should be able to pick up any new programming language in a matter of weeks without instruction. It's easy. The hard part is understanding the core concepts of software design and development and having the discipline to do the job correctly.

    I would normally expect people familiar with design to appreciate that much, but apparently it's all greek to some.

  • gbacoder

    There is a lot of work being done on this. More and more tools are coming out, esp. in iphone dev. http://www.readwriteweb.com/mo...
    I have to say though being a programmer with many years experience, the line "for(int i = 0; i < 10; i++)" makes perfect sense. I can read a line like that like the back of my hand. It's also considerable more flexible than the repeat 10  times line.  And no way would I want to type integer when i could type int!!!! Do you have any idea how often I type that in???!  And code completion would just not work from int to integer (would be a pain). For loops like above  are used so often by programmers, that there is no problem understanding them. And it's nice to have the extra power if need it.  I think the lesser used commands could perhaps be made more descriptive. 
    But it's certainly an issue, the amount of time and effort it takes to write code.  I'm looking at ways to improve this as a startup company.  

  • Peter

    I haven't used Perl, but it has a C-style syntax. And I can say that while C/C++ might be abstruse for the nOOb, they are really pretty simple and it doesn't take that long to get reasonably up to speed in them (barring the obfuscations of some wizards with preprocessor macros). In particular, you can learn C++, say, much more easily than you can a new natural language.

    And since the normal programming languages (those that aren't like Intercal and Brainfuck, e.g.) aren't that hard to pick up, the main focus should really be on how intuitive and efficient they are for programmers who have already learned them. 

    It's like math, sort of. If your standard is natural language, division/fraction notation isn't particularly intuitive. But to someone who knows the notation, ab / b is very intuitive, and it's immediately obvious that you can cancel the bs. So the goal of an intuitive programming syntax shouldn't be to emulate natural language, necessarily, but to provide intuitive hooks and syntax for the types of things that programmers do a lot. Things like loop structures, or map/accumulate/reduce in functional programming languages. Making branches easy to read and think about. That sort of thing. And it just may be that it's easier to express these types of structures and operations in a more specialized notation than what you'd derive from trying to emulate natural language.*

    Still, the idea of developing and testing a language for usability is great, and if it's working for Quorum, then let's hope those techniques spread to more languages. And  while programming languages for professionals should take advantage of more specialized syntax, there's still room for well designed, easy languages for people who only ever want to dabble.

    *so let me mini-rant about Lisp style syntax, where there are no intuitive hooks, and absolutely everything looks like a list. Sure, easy to parse mechanically, not so helpful for thinking  about what's going on.

  • alexander

    all i wanted to do was set up my own website.  of course i just couldn't use the templates available and so i went into the back end - not smart.  to make a long story short, i ended up using the 'hunt and pick' method.  if i change this, does that do what i want?  i eventually started to recognize some of it, but i should have known when i found a website that was titled 'how to use the Joomla manual', i was in for a real ride.