The Programming Language of the Future

The other day I linked this interesting article in an otherwise typical rant about how Schemers need to make more of an ecumenical appeal. It's by Paul Graham, and it's speculation about the Next Big Thing in programming languages. There's lots of chatter about this on the web. Maybe because programming languages are sprouting like weeds these days (because of the explosion in internet usage, no doubt), people are starting to wonder if C/C++ and Java's days aren't numbered. Naturally there's a lot of curiosity about what could come next.

Graham's article is by far the most sensible commentary I've heard on this. As anyone who programs will know, discussions about the comparative merits of various programming languages are more about religion than substance. People like what they like, end of story. This is one of the rare moments (which sort of makes me wonder whether Graham isn't a C programmer? For some reason, C programmers have always struck me as less "religious" than the others - which is ironic considering I once compared them to Republicans) where we get to step back and take a real look. But that's neither here nor there. fI wanted to respond to some of his points.

1. Programming languages are for people - Now this seems like rather an obvious thing to say, but it's amazing how often it gets forgotten. Programming languages are for people - right. Actually talking to the machine is the compiler's job. If we were comfortable flipping bit switches, we wouldn't have ever needed PLs. But since we do need them, we should remember why we need them. The compiler can translate what we say into machine-speak, we need them to tell the compiler what to do. I.e. - the language should neither be totally geared toward the idea that there is a machine, nor totally geared toward the idea that programs are proofs. But here's where Graham really got my attention:
   

   
   And when I say languages have to be designed to suit human weaknesses, I don't mean that languages have to be designed for bad programmers. In fact I think you ought to design for the best programmers, but even the best programmers have limitations.
   

   
   Thank you, thank you, THANK YOU! This idea of what to orient programming languages toward - it's like walking on a tightrope. On the one hand, we use machines, but on the other we're people. Those of the school that say that languages should be designed for people really do have an annoying tendency to pander to the lowest common denominator. But that's never the point. Tools (well, good toold, anyway) are not generally designed for any old moron. They're designed for performance - and yes, sometimes that means you have to get a bit of training. Well, no difference here. When we say we're designing for programmers, we don't mean for any old schmuck who wants to write a one-off web application. The bulk of programming is done by professionals, and their software is only useful to anyone else if they can work their magic. This is my major complaint against Java. I don't need a language that holds my hand all day, thanks. I know what I'm doing.
   


2. Design for Yourself and Your Friends - this is equivalent to the point made in the quote above, I guess, but he thought it was worth making twice, and so do I. A good operational definition of a good programming language is that it is one that good programmers will want to use. If you're cool enough to be designing one, then you probably qualify as a "good programmer," and lots of your friends probably do too. So make what you like, not what you think other people might want.


3. Give the Programmer as Much Control as Possible - Again, I stand up and cheer. I don't necessarily mind a language building in some safeguards here and there, but it needs to at least leave me an escape hatch. I touched on this some in my discussion of Scheme and ML. I'm new to ML, so if I got this wrong, apologies - but one of the frustrating things about ML in relation to Scheme is that it doesn't seem to wanna let you out of lexical scope. Variables are persistent and can't be changed. I tend to agree that this is a good idea, but I like that Scheme gives me set! so that I can change variables in a pinch if that's what's required. I also like that it gives me call-cc. Not that I usually need it, but it's nice that it's there just in case. Languages should aim for maximum expressive power. Again, I don't mind if they cater to one programming philosophy over another. Just - at the end of the day, I need to be able to say everything that I could possibly need to say, you know?


4. Aim for Brevity - here I jump ship a bit. I do indeed think that brevity is underestimated in language design (talking here about brevity of expression in the syntax and keywords, not necessarily in the language specification a la Scheme) - especially by a certain industry whore. But if Perl has taught us nothing else, it's taught us that this can be taken too far. TMTOWTDI may be nice for impressing your friends with how quickly you can type in a working line, but come back after an hour and even you won't be able to read that string of symbols on the screen you call a "program." Brevity is nice, but not at the expense of readability and uniformity. I would think it's more accurate to say that there's a balance here. Ruby seems to have struck that balance nicely - though I still think Python is the readability and learnability king.


5. Admit What Hacking Is - I have to grudgingly give him this point:
   

   
   A lot of people wish that hacking was mathematics, or at least something like a natural science. I think hacking is more like architecture.
   

   
   Right. Unfortunately, I'm one of those people who has a tendency to fall into the "programs are proofs" trap of functional programming. I like to think that programming is mathematics, I confess. But I know it's wrong. Programming is like architecture, right. It's about building things. The functional meets the sublime. There's an aspect of it that speaks to "elegance" and such, but it's not fully an art. There's an aspect of it that needs to be practical, but it's also not fully an engineering task. It's both. Architecture, not math. Right. As much as I hate to admit it - that's right.


6. Are People Really Scared of Prefix Syntax? - This may be the line that really grabbed me about this list - let me know it was something unusual. I've often wondered about this myself. Prefix syntax, for the uninitiated, is what Scheme and Lisp use. Rather than y = x + 1, Scheme and Lisp say things like (+ x 1). I really like prefix syntax, I'll admit it. It's natural to think of operators as functions - and nice to apply things like addition in the same way that you apply functions. So maybe I'm biased against those who don't - but I do often wonder if people have some irrational objection to it.


7. A Language Has to Be Good for Writing Throwaway Programs - Completely agree. Python is highly addictive for this reason. And Java and C/C++ offputting, for the same reason. Language designers need to keep in mind that desktop computers are now ubiquitous and that few people bother having formerly ordinary things like calculators anymore. Lots of "one-off" programming gets done, in other words, and people who do a lot of this appreciate and return to languages that don't make it a chore.


8. Syntax Is Connected to Semantics - yes, I think so too. And I do much prefer languages whose syntax reflects in some intuitive sense the operation that's going on.

In another section entitled "Ideas Whose Time Has Returned" he lists, among others:

1. Efficiency - He writes:
   

   
   Recently it was starting to seem that computers were finally fast enough. More and more we were starting to hear about byte code, which implies to me at least that we feel we have cycles to spare. But I don't think we will, with server-based software. Someone is going to have to pay for the servers that the software runs on, and the number of users they can support per machine will be the divisor of their capital cost.
   

   
   
   Indeed. I also believe that efficiency will start to become more of a concern again - and also largely for this reason. I often wondered if maybe it wasn't just because I was biased against Java (because the Java people are the ones who repeat this meme the loudest). It's nice to hear someone else say this.

In a section on Pitfalls and Gotchas

1. Object-Oriented Programming -
   

   
   I realize this is a controversial one, but I don't think object-oriented programming is such a big deal. I think it is a fine model for certain kinds of applications that need that specific kind of data structure, like window systems, simulations, and cad programs. But I don't see why it ought to be the model for all programming.
   

   
   Couldn't have said it better myself, and couldn't agree more. Right - OOP is useful (indispensible, really) for certain kinds of applications. But it isn't the grand paradigm shift people like to think of it as. It's a highly organized nameing scheme, nothing more. It allows programs to be organized in a highly readable way, and allows you to violate scope rules in something like a disciplined fashion. These are nice for giant, graphics-based projects. It's completely useless, and even counterproductive, for day-to-day stuff. I agree that the Language of the Future should support OOP, but I completely reject the kind of approach that Ruby has taken, where absolutely everything (including the counter in a loop!) is an object. This is just silly. Objects are nice, but they have their place. Some things are more intuitive the old-fashioned way.
   
   But this line is pure beauty:
   

   
   I think part of the reason people in big companies like object-oriented programming is because it yields a lot of what looks like work. Something that might naturally be represented as, say, a list of integers, can now be represented as a class with all kinds of scaffolding and hustle and bustle.
   

   
   
   HA! Right.
   
2. Design by Committee - Yes indeed! All the best languages have identifiable developers. Python, Ruby, Scheme, C++ (though not C). All the crappy ones - JAVA, Objective-C, OCaml - were designed by teams. Perl stands out here, though. Definitely has a single designer, but I can't stand it. However, I guess this is just personal taste. A lot of otherwise cool people program in Perl and love it. And it did bring us cool regular expressions, I have to admit. But Matz, Soustroup and Guido are all cooler than Larry Wall, so I'm still mostly right!

For what it's worth...