Why Your Programming Language Is “Too Academic”

The Groovy/Grails Podcast guys asked me what it was like to have a foot in both the Rails and Grails communities, which has gotten me thinking for a while. One of the thoughts I had was about the “too academic” complaint that I hear bandied about so much: language/feature X is too academic, and therefore shouldn’t be studied/will never be adopted/is too hard for you so don’t bother/eats babies/whatever.

What’s interesting about this complaint is because it’s both totally wrong and completely right.

A lot of people who are fans of a “too academic” language chalk up the “too academic” claim to laziness (that’s “false laziness” for my Perl peeps). They assert that Intuitive Means Familiar, and the “too academic” claim is simply people whining about not putting the hard work in to learn a new language. This is a mistake: a more insidious criticism is at work, and language designers need to pay attention to it.

To see the problem, let’s take a brief foray into web application sites. One of the common things these sites have is a limited-capability free account — see the pricing plans of GitHub, Less Accounting, Remember the Milk (their “Pro” account), and ActionMethod as examples[1]. The thinking behind this “freemium” business model is simple: get people in and using the site, and then start to hit them up for money once they’re already engaged. By offering these free accounts, people can quickly go from being a non-user to a user of the site — potential users don’t have to cross the extra hurdle of deciding whether or not it’s worth money, getting out their credit card, etc.: they can shift from non-user to user by simply filling out the form.

[1] Notably, 37Signals products don’t have this, but that speaks more towards their marketing success than against the general principle.

Amazon, in a genius maneuver, goes one further. If you use a user-only feature of the site, you get prompted with a page like this:

In one fell swoop, just by entering the username/password you’d like, you can shift from non-user to user.

 

This ability to quickly shift from non-user to user is called gradual adoption, and it’s a key user interface concept. Basically, the idea is that it should be easy for someone to use the most common or useful aspects of your site without having to deal with too much hassle.

Now, let’s get back to programming languages. For even moderately experienced corporate programmers, there is a whole body of functionality which is taken as a “solved problem”. Working with these solutions make up most of the day-to-day work for the programmer-technician[2]. So, when said programmer encounters a new language, they come with the expectation that said things are solved. This is usually false, if simply because of the sheer amount of effort spent on building up technologies in their corporate language of choice. Still, most programmers interested in learning the language will push on, and many will even start to write their own versions — and that’s when their confronted with The Wall.

[2] More on programmer-technicians over at The Programmer is Dead; Long Live the Developer!, a post which has proven itself more and more accurate with the rise of CMSes (including WordPress), Rails, Grails, and other whole-stack solutions.

The Wall (in an entirely non-Pink Floyd sense) is this point in learning some programming languages where you suddenly are required to grok the entire language in order to use any of it. In some languages, it comes shortly after “Hello, World!”. And clever languages where developers slam, full-speed, into The Wall are the ones which are “too academic”. The basic complaint is twofold:

1. The functionality that I consider a given for day-to-day work doesn’t exist, and
2. Only the language designers and the most fervent evangelists are skilled enough to write the solution.

Notably, neither of these issues have anything to do with academia: it’s quite possible for a language to come out of industry which had the same qualities — in fact, many DSLs are fair prey for the same criticism. So, in that sense, the criticism is totally bogus. However, the underlying cause for complaint is fair, even if the way it is expressed isn’t.

If we look at languages which have really gotten a strong foot-hold, it’s easy to see that while each language provided profoundly new and impressive features, the language also provided a process of gradual adoption: it was easy for those already familiar in a dominant language to make the step into the next language. So Raganwald is right in saying that a major win for Ruby was Enumerable’s collect, select, detect, and inject methods — but Ruby also provides a plain ol’ shellish for loop. Java may be object-oriented, but it’s very easy to write procedural code in it (believe me, I’ve had to maintain my fair share of it). And so on up the chain.

It’s fitting that while I was writing this blog post, a post entitled “functional newbie, domain entites” was posted to Scala-User, and Brad Buchsbaum made the following astute statement in a follow-up:

Is there a missing chapter 34 in “Programming Scala”: How to port a tangled ball of mutable state — i.e. a reasonably sized java program — to beautiful “object-functional” scala code? Who is writing on this topic?

The usual gurus on this list talk avidly and feverishly about the niceties of the type system or whether “break” should be added to the language but when someone asks a mundane question about mutable objects and how to migrate such things from java to scala the answer is usually “well, there’s this pre-SIP that is going to make all of that a cinch”.

Dirk brings up the example of a complex graph of objects, where buried somewhere at the bottom of the hierarchy is a Point instance. What happens when Point.x changes? I’d like to add, what happens when Point.x changes and x is bound to a “spinner” GUI component that the user can view and manipulate? Indeed, often the entire object graph is mirrored at the UI level and this achieved by sprinkling listeners all over the place and monitoring for mutations. What is the scala-way to solve this basic problem?

This issue has come up in other ways on the Scala mailing lists: two very good conversations on this topic are at Scala: Great potential, but not ready for production and Scala, Scala you got me worried — the latter thread includes my particular criticism of Scala, which Martin Odersky addresses fairly directly, albeit insufficiently (IMHO).

In contrast, consider Groovy: the key sales pitch of Groovy is “quite literally Java, but without the pain”. Its superset-of-Java nature means that you can start with a Java file, change its suffix to “.groovy”, and build it with groovyc. This is an obvious win via gradual adoption. Gant is another good example — even ignoring ant2gant, its basic functionality mirrors Ant, right down to providing a transparent way to reference Ant Tasks.

The lesson for language designers and maintainers is simple: provide a gradual adoption route for people who know another programming language. Key among this is allowing a way to mimic functionality of popular languages, and providing an API which is accessible.