Back in 2003, Paul Graham gave a keynote speech entitled "The Hundred Year Language" (he later expanded this for his book "Hackers and Painters"). He envisioned what an early 22nd century programming language would look like ... what would control the flying cars and robot spaceships.
To my eyes, it looks a lot like Clojure.
He talks about languages that can be highly expressive, yet can be tuned for better performance. He explicitly references Lisp, Clojure's very-close cousin. He's concerned with parallel computation (which is to say, concurrency) ... which is one of Clojure's strong suits.
In any case, check it out ... and see if you are seeing what I'm seeing.
I think the 100 year language is statically typed. The way I look at things, a statically typed language adds another dimension of expression which you can use to describe your program.
ReplyDeleteI do think that Clojure is really well done and has interesting and useful approaches to concurrency, but you could say the same about Haskell, with Clojure's advantage being that running on the JVM puts it at the center of an ecosystem which is looking for new languages but not new platforms.
A poignant comment in Graham's essay is his notion of efficiency -- that processor cycles in the future will always be wasted and that the true inefficiency is wasting programmers' time on needless work.
ReplyDeleteHe also asserts that object-oriented programming is just a sustainable way to write spaghetti code. But spaghetti is language-agnostic. You can make anywhere.
I agree with Tom Davies. Bugs introduced by parallelism (race conditions, deadlocks, live locks, priority inversions, insufficient parallelism) are generally not detectable by test suites, no matter how large and comprehensive. These bugs are all "Heisenbugs", in that they generally work (or at least appear to), and small, irrelevant changes to the code can radically change their expression. The only hope you have for finding those bugs is static analysis, aka static typing.
ReplyDeleteI will also add that, while being on the JVM is a huge win for Clojure at the moment, it's a long term huge loss. All those lovely, useful, java libraries are all imperative in nature, and will not scale. Amdahl's law will kill the JVM.
@Brian
ReplyDeleteI agree that access to JVM libraries is not that exciting; that Clojure interoperates with JVM libraries is pragmatic and a necessity, but that advantage of the JVM in the installed base and the performance of Hotspot.
I also don't think that type safety introduces significant tools for verifying concurrent behavior, whereas Clojure's focus on immutable (persistent) datatypes does help ensure thread safety. It now kills me when I work in Java or JavaScript and don't have access to proper, immutable data types.
To reiterate; Clojure provides the patterns and tools to bypass the concurrency issues that are common in traditional Java. When the only data shared between threads is immutable the world simplifies greatly ... and the fact that there are well defined mechanisms (atoms, actors, etc.) for communicating between threads also helps address the problems. I do agree that the remaining problems, often the result of misuse of these tools and patterns, will be more subtle problems such as insufficient parallelism.