Recently I had a brief discussion on Twitter about the ease of use of programming languages. The points I wanted to make warranted more space than 140 characters would allow, so with thanks to Antonio for the blog space, here they are.
For decades, the holy grail of programming languages has been to create a language that is as simple to adopt as possible, while providing as vast an array of functionality as imaginable. Every new language boasts of its ease of use: "See? You can do a network call and pass the result to your view in one line!" Yet beginners still feel that programming is a black art, and many people, some experts included, feel that programming languages are to blame. I disagree. In a perfect world, programming is as simple as talking to the computer, which interprets the commands and does what the author means. Unfortunately this requires superhuman intelligence on the computer's part: not only does it need to interpret your language of choice, resolve any ambiguity arising due to your accent, and set down what you said, it also needs to resolve any ambiguity arising due to your choice of words, catch contradictions in your instructions, ask you to resolve them, and so on. It's so complicated that human beings can't do it right: specifying requirements is one of the most complicated and error-prone processes imaginable. So the day is still far off when programming can be reduced to writing a requirements spec. Until then, we are left with using actual programming languages, which can be quite daunting. Let's consider designing a language with user experience in mind, by which we mean that beginners would feel right at home in it (this is not the only user experience, but let's pretend it is). What would such a beast look like? Already we have languages like Ruby and Python that can look pretty much like English. If those are too difficult to understand, then clearly bringing the language closer to English doesn't help much. We also have languages that try to help by working very hard to ensure that a certain type of consistency exists in the code; Haskell, for instance, ensures that you are working with whatever data you claim to want to work with, and that you do not change it in a uncontrolled manner. Yet Haskell is considered a difficult language to master, because in order to provide this functionality, it introduces complex mathematical abstractions that the user must thoroughly understand. Clearly, helping the user avoid errors (even if only of a restricted kind) is not a bonanza, either. What's left? Really, only one thing: providing pre-packaged solutions for known problems, aka, libraries. And we have them, for every language: it has probably been years since a working programmer has had to write network socket calls—some generous and knowledgeable souls wrote the code, tested it thoroughly, and then donated it to the community. And libraries like jQuery take things that once were thought horrendously complex and make them trivial. This helps a lot—but now it adds a new form of complexity: the libraries one must be familiar with. Again, a barrier to entry. Let me posit, to explain this complexity whack-a-mole, that learning programming is hard not because of the languages are difficult, but because programming is difficult. Why? Because it solves difficult problems. To be sure, some languages are easier to learn than others, up to a point, but that is a very superficial ease. If your goal is to write a program that says "Hello World" on the console, half a dozen languages let you do that in one line of code—can't get much simpler than that. But if you want your browser to take a string, interpret it as a layout, add reactions to it based on user interaction, fetch data, and make the whole shebang operate as if the user were in a desktop application while making asynchronous calls to the server...well, of course it's going to be hard. No language in the world will help you because this is not a simple problem. If you're starting to learn programming and find it hard, good! You're not deluded: it is hard. Of course, I encourage you to give yourself the benefit of the doubt when your gut instinct says "this should be easier". And if you have a way to make it easier, write it! Publish it! We will love you for it. But the truth is, if it's harder than it seems it should be, it's probably because it's not easy to simplify. Because even though it looks like a simple concept, endless edge cases will bring it in conflict with other parts of the system in unpredictable ways. Because we have not yet reached that level of abstraction. This is really the crux of the matter: abstraction. Once upon a time, programming was literally guiding bits through a processor, with punch cards. Now we get to tell browsers (browsers!!) to layout boxes of content, to create gradients, to display specific fonts, or even to use tables (but don't do that; we keep it civilized). Whatever problem you think could be solved by a better language probably can't, but it probably can be solved by a better abstraction, which one day might make it into a language. The languages we have today reflect the level of abstraction we have gotten to. They are our report card. So, yes, we should try to improve our languages. But let me dispel an illusion right now: that will not make programming easier or more accessible. Because when, after blood and sweat and tears, doing X is finally easy, we will move on to wanting Y, which should be so easy, beginners could do it—if only these darned languages didn't stand in the way.
--
You can follow Alexandros on Twitter as @nomothetis.