Atlas · Details
Language Grubbing
Author’s note
Really not worth it unless you are a languages historian. This is just my own survey of the available languages at the time. Tour de Babel has some overlap with this and is better all around.
AI Notes
After a year of off-hours "grubbing" through about twenty languages, Steve opens with the meta-lessons rather than a ranking: languages form religions because they're hard to master and mould their users' thinking; new ones appear constantly because mini-languages emerge faster than old languages can adapt; marketing beats merit, and a language only has to be perceived as easy to learn. Then the capsule tour. C is timeless. C++ gets its grievance saved for later. Java is the cautionary case — the only language whose code base grows superlinearly with the feature set, which is what's driving the Java world toward refactoring-tool automation. Perl fades from memory faster than any language he's used. Python is surprisingly expressive; Ruby is the daily driver. Smalltalk waited patiently and Java stole its day. Common Lisp is goliath-ugly but goliath-capable; Scheme is small and beautiful and not turn-key; ML is fast under the strict type system; Haskell still looks years from production.
It's a compact index of Steve's mid-2000s language thinking — most of his later language posts trace back to one of these capsules. The closing line: languages DO matter.
Related listings
-
2005
Choosing Languages
Same arc — the prescriptive companion. Grubbing is the descriptive survey; Choosing Languages is the decision framework Steve built on top of it.
-
2004
Tour de Babel
Same shape, one year apart. Tour de Babel is the longer marquee survey of the corpus; Grubbing is the shorter, more personal stocktaking that pairs with it.
-
2005
Is Weak Typing Strong Enough?
Same year — the depth piece for the type-system thread that runs through every language note in Grubbing. Where Grubbing comments in passing on each language's typing story, Weak Typing argues the position at length.
From the peanut gallery
Read the rest of the thread · 5 more
-
This is a pretty interesting summary, overall. I was surprised not to see any mention of Objective C, until I realized that the language is practically invisible outside of the OS X world. You mentioned mini-languages so much at first that I was half-expecting a Paul Graham style trumpeting of Lisp when you reached it in your list. Imagine my surprise when it turned out to be a fairly reasonable glance that matched my own experience: "Gosh, the idea of Lisp is just gee-whiz cool. But damn, the implementations of it suck in countless ways."
I still do most of my work in less than a half-dozen languages, but it's always interesting to look at more. So far my experience with new languages has been along the same lines as the kid poking at roadkill with a stick, trying to figure out if it really is dead. There is a lot I'd like to do, but I've got the pressure of limited free time staring me down. In the meantime, all my roadkill poking seems to be making me more proficient at the languages I do know, especially Ruby.
Oh, and there *is* a Smalltalk-based embeddable scripting language available on the OS X platform (FScript). It's got more users than I would expect, but it's still not exactly taking the world by storm. Not even the relatively small world of OS X. The developers of GNU Smalltalk have also worked pretty hard to make it accessible to people accustomed to file-based development. It's nice, and definitely worth taking a closer look at if you don't feel like starting up a Squeak VM just so you can learn about the language.
Haskell ... oh man, Haskell looks so cool. I downoaded a PDF tutorial for it months ago, and haven't had a chance to look at it since. Well, I suppose I've had chances, but I haven't actually *remembered* during those vital free hours.
Oh, REBOL (http://www.rebol.com/, http://rebol.org for a lot of good sample scripts, http://coolnamehere.com/geekery/rebol/ for a couple of very low-level introductory articles for my niece) is another interesting niche language. It works from the philosophy that all computer programming should involve creating a dialect of your main language that fits into the problem domain. It's a really intriguing idea, and I would love to see them do more. Unfortunately, the developers have been stuck in a beta loop for about four years now, with no sign of releasing a new official stable release that more cautious people can use.
Too bad I'm buried deep in learning why folks hate obidos so much.
-
Mark, thanks for the corrections/clarifications on ML/OCaml. I agree with all of them.
I think writing high-performance programs is a challenge in any language, especially once they reach a certain size. Heck, much of the challenge is to know when to worry about performance and when not to.
I'm not sure if it's harder to write efficient code in ML than in C++ — it's tricky to do an apples-to-apples comparison unless you're equally proficient in both, and I have far less experience with ML than with C++.
I think every language has a set of recurring idioms and patterns that lend themselves to better-performing code. Many of the patterns I see in ML are equally valid for Lisp, Scheme, Haskell, Erlang, or any other functional language. I suspect that with enough experience, these idioms become second nature.
I've been very interested in figuring out ways to apply functional programming ideas in Java and C++. Plenty of people out there have the same interest, as it can often yield more modular, robust code. Josh Bloch recommends it highly in "Effective Java". Google has a number of papers (e.g. http://labs.google.com/papers/mapreduce.html) that rave about it as well.
Of course, once you start using the functional style in your C++ or Java, many ML-style optimizations become directly applicable. So I'd argue that learning how to write high-performance ML programs isn't a *total* waste of effort.
(I'm sure you weren't arguing that. I'm belaboring the point just in case any Alert Readers think there's no value in looking at functional languages if you're not going to use them in production.)
-
Brian: thanks for the feedback. I do like Objective-C, and I shouldn't have left it out. I've never really understood how C++ managed to eclipse Objective-C, but I suspect it all comes down to marketing.
There's another very promising new language that probably should have made my summary list: Groovy. I'm nearing completion of a project to implement a small but nontrivial GUI-based application in five different JVM languages: Java, JRuby, Jython, Kawa Scheme, and Groovy. So far, Groovy appears to be the "best" of the bunch. I'll do a blog on it in a few weeks, comparing and contrasting them.
Paul Graham likes Lisp a lot, no question. But he probably wouldn't have sequestered himself away to work on Arc for a hundred years (if I understand his plan correctly) if the existing Lisps weren't all problematic. I'd love to use one of them, but so far it's been a real struggle.
I still plan on devoting a fair amount of time to learning the ins and outs of Common Lisp, and I'll try to write some sort of significant application in it at some point. If nothing else, knowing Common Lisp enables you to do some pretty amazing things with Emacs.
Thanks for the pointers to F-Script and REBOL. Incidentally, I tried hard to get Gnu Smalltalk working on my Windows/Cygwin box and failed miserably. Oh well.
Alas, I think I've only been averaging about half an hour a day on language experimentation, so it's a slow-going process. Fun, though.
-
Any chance you've read this interview with Alan Kay yet? I was reading it over the weekend and was reminded about the things you've been writing about for the last couple of months.
-
Yeah Dan, you're about the 30th person to send me that link. Thanks though!
It's an interesting article. People seem to think that Alan Kay is really bitter, and that he feels the world has done him an injustice, or whatever. I didn't get that impression when I read the article, though. I thought everything he said made a lot of sense.
I suspect the people who think this of him are the kinds of people who say: "you're just jealous because C++ proved to be way cooler than your language". That's the same kind of person that tells a Mac user: "you're just jealous because Windows proved to be way cooler than the Mac."
It all comes down to your personal definitions of "jealous" and "cooler". :-)
"On average, OCaml produces code that's as fast or faster than C++, and this isn't because the OCaml compiler writers are smarter than the C++ compiler writers. It's strictly a function of the fact that the OCaml compiler knows a lot more about what's going on in your program than a C++ compiler can possibly know."
The OCaml compiler was designed to be a very aggressive optimizing compiler. And high performance ML/OCAML code is often precisely engineered to expose optimization opportunities to the compiler, i.e. making all recursion use tail-call, continuation style computation, clever use of call-cc, etc. Rewriting your code so the compiler can optimize away the inefficiencies of functional languages is pretty hard for nontrivial programs. So while the compiler writers of ML/OCaml may not be smarter than their C++ counterparts, the people that write high-performance ML programs probably are :).
Not taking anything away from ML, I personally loved using it in school, but I'm not gonna try writing high performance apps in it.
Your argument that compiled ML/OCaml is faster than C++ because of type information doesn't work in the light of languages like C which have almost no type system and yet outperforms just about anything outside of assembly. But that's a bigger topic.
— Mark · February 17, 2005 07:36 PM