Clojure and Lisp Revival
By warren on Oct 14, 2008
I have always been fascinated by Lisp, but it just seemed like one of those languages that while theoretically nice was completely impractical. Lisp environments have either been powerful but proprietary, or have been free but limited in capability. Although Lisp is one of the oldest language around (circa 1950s!)it has remained a niche language, never quite attracting enough critical mass to make it a serious alternative to mainstream languages such as Java, ruby, or C#.
Clojure might just change that.
It's a Lisp dialect built on top of the JVM, and it solves many problems which have impaired Lisp adoption:
- Courtesy of the JVM, Clojure has access to the world's largest collection of software libraries.
- It's a two way street. Clojure is able to create classes that can be called from Java.
- Clojure has a cross platform GUI. Love it or hate it, Swing does a reasonable job at solving this problem. My money is on someone leveraging JavaFX libraries to build a DSL with Clojure. Might be a nice alternative to JavaFX script!
- It's got a free IDE. Enclojure is a Netbeans plugin that provides a namespace browser, editor, code completion, and interaction with REPL. For a Java guy used to the Edit-Compile-Jar-Deploy-Run cycle it's pretty neat to be able to incrementally send expressions to the REPL.
- It's fast (or at least fast enough). Expressions entered in the REPL (the Read Evaluate, and Print Loop) are compiled directly to Java byte code. As Java gets better at dynamic languages (think invokedynamic!), Clojure gets faster.
- It's practical. Rich Hickey, the mastermind behind Clojure, has made a few design choices that improve the performance and interoperability with the JVM. For example, Clojure supports vectors, maps, and sequences, all of which map nicely to Java constructs.
Most importantly, Clojure's functional style is perfectly suited to a future when massively parallel multi-core machines are the norm:
Functional programs eschew the external 'effects' of imperative
programs, and thus become easier to understand, reason about, and test,
since the activity of functions is completely local. To the extent a
portion of a program is purely functional, concurrency is a non-issue,
as there is simply no change to coordinate. [http://clojure.org/state]
Check it out here