Expert to Expert: Rich Hickey and Brian Beckman - Inside Clojure
- Posted: Oct 06, 2009 at 10:29 AM
- 77,396 Views
- 27 Comments
Download
How do I download the videos?
- To download, right click the file type you would like and pick “Save target as…” or “Save link as…”
Why should I download videos from Channel9?
- It's an easy way to save the videos you like locally.
- You can save the videos in order to watch them offline.
- If all you want is to hear the audio, you can download the MP3!
Which version should I choose?
- If you want to view the video on your PC, Xbox or Media Center, download the High Quality WMV file (this is the highest quality version we have available).
- If you'd like a lower bitrate version, to reduce the download time or cost, then choose the Medium Quality WMV file.
- If you have a Zune, WP7, iPhone, iPad, or iPod device, choose the low or medium MP4 file.
- If you just want to hear the audio of the video, choose the MP3 file.
Right click “Save as…”
- High Quality WMV (PC, Xbox, MCE)
- MP3 (Audio only)
- MP4 (iPod, Zune HD)
- Mid Quality WMV (Lo-band, Mobile)
- WMV (WMV Video)
Clojure is a dynamic programming language created by Rich Hickey that targets both the Java Virtual Machine and the CLR. It is designed to be a general-purpose language, combining
the approachability and interactive development of a scripting language with an efficient and robust infrastructure for multithreaded programming. Clojure is a compiled language - it compiles directly to JVM bytecode, yet remains completely dynamic. Every
feature supported by Clojure is supported at runtime. Clojure provides easy access to the Java frameworks, with optional type hints and type inference, to ensure that calls to Java can avoid reflection.
Clojure is a dialect of Lisp, and shares with Lisp the code-as-data philosophy and a powerful macro system. Clojure is predominantly a functional programming language, and features a rich set of immutable, persistent data structures. When mutable state is needed, Clojure offers a software transactional memory system and reactive Agent system that ensure clean, correct, multithreaded designs.
Astrophysicist and Software Architect Brian Beckman interviews Rich Hickey to dig into the details of this very interesting language. If you don't know much about Clojure and the general problems it aims to solve, well, watch and listen carefully to this great conversation with plenty of whiteboarding and outstanding questions. Expert to Expert simply rocks! Thank you for spending time with us, Rich! Clojure is great!
PS: You can donate to the Clojure project should you feel so inclined.
Clojure is a dialect of Lisp, and shares with Lisp the code-as-data philosophy and a powerful macro system. Clojure is predominantly a functional programming language, and features a rich set of immutable, persistent data structures. When mutable state is needed, Clojure offers a software transactional memory system and reactive Agent system that ensure clean, correct, multithreaded designs.
Astrophysicist and Software Architect Brian Beckman interviews Rich Hickey to dig into the details of this very interesting language. If you don't know much about Clojure and the general problems it aims to solve, well, watch and listen carefully to this great conversation with plenty of whiteboarding and outstanding questions. Expert to Expert simply rocks! Thank you for spending time with us, Rich! Clojure is great!
PS: You can donate to the Clojure project should you feel so inclined.
Comments Closed
Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation,
please create a new thread in our Forums,
or
Contact Us and let us know.
Follow the Discussion
Brian Beckman And Rich Hickey! ARGHHHHH
Loading...
I'm quite impressed with the persistence characteristic of Clojure. That's a kind of purity of its own.
Clojure and Scala look like the hot languages of the day and both run on JVM and also CLR.
Must revisit Are We There Yet?
I had no idea Clojure supported the CLR...!
This is great! Thanks for the awesome video!
This is great! great! great!
I would like to see the continuation of this discussion!
Finally I can use Lisp, before I completely forget it.
It's been more than 10 years since I last work on it, but Clojure makes perfect sense to try out some real world scenarios.
Wow, that's really awesome!
"
Status: definitely alpha. Developers only at this point.
Alpha = rough edges, incomplete features, slow.
"
This from the ClojureCLR link dated feb 2009, is this still the case? Would love to be able to actually use Clojure on .Net
I'm pretty sure it's getting more stable. I'll ask Rich.
C
Nice stuff. I like the deep language design topics.
For those that might be interested....
Clojure for Java Programmers
http://clojure.blip.tv/file/982823/
Channel 9 seems to be on a roll at the moment. Erik appears to be a Functional Force of Nature and now we've got Brian back! Awesome. I'm not saying they are connected, but if the apparent increase in the rate of innovation and related deep thinking in the fields of programming languages, tools and runtimes is due in some small part to having the comfort factor of a fast-enough single threaded future removed then the 'retreat' to multicore is one of the best things to happen to the software industry in the last seven years.
The implications of the statement "objects conflate value and identity" and "this is broken" appears to me to me that the CLR model is broken (shock!) since the CLR operates on {C,MS}IL which maintains the C#/VB notion of objects. Correct?
Even if Clojure can be built on the CLR and JVM, can we say that these VM's are appropriate for the paradigm shift that's only just begun?
It's actually quite astonishing, this view of an object as a timeline of values, where each value is its state in a point in time. Also, I love the connection between Clojure "objects" and IObservable. Reminds me of Brian's comment "...mutable, and very observably so". Almost like IO on steroids since IO deals with properties whereas here you can take the whole object and it becomes a timeline.
A language like this which these powerful datastructures built into the language is quite appealing even if conventional wisdom is to not have it in libraries. D does the same with its maps although its notion of a map is completely traditional and imperative.
It's quite disturbing that in this world of increasing immutability, the BCL stands out as incredibly mutable. Is this good enough to build the future on do you think or can we no longer hide that the imperative style language(s) that the CLR was founded on and the BCL was written in is broken for the future? Looks like a big reconstruction project. And what primitives do you choose to rebuild it for the future. Task and Future ain't cutting it.
I love the concepts of Clojure even if the LISPy syntax "red pill" may be too tough swallow. But there's no reason why something like this could not underpin many DSL's, such as what we see in "Oslo".
And the reference to Timewarp brings up again the connection between programs and the OS and what the OS offers programs and how it interacts with them. Sounds like a great potential interview.
Hmm...
Yeah I only got round to reading this a couple of weeks ago:
http://wiki.jvmlangsummit.com/images/a/ab/HickeyJVMSummit2009.pdf
And by the end couldn't help feeling that we are definately trending towards a very different, post OO, world. The prize wil go to the company that produces a language product that enables the same economics in terms of being able to hire VB type developers and yet contains at its heart these fundamental 'new' approaches.
It's LISP! It keeps coming back like Freddie Kruger.
http://xkcd.com/297/
In your dreams!
Clojure-CLR is hosted here.
C
Both the JVM and CLR are not in stasis... They will evolve to meet the needs of the future. I'm not sure disgarding them in the light of new programming languages with different semantics for objects is correct. It's just too early to tell if the general purpose mainstream programming community is willing or able to throw away their current toolbox as opposed to simply adding new tools to it... I think what you're seeing with C# and VB.NET becoming more hybrid in nature (functional + imperative + dynamic) is a trend that will continue. The question "how long can a single language be used to solve most problems" is a very good one. Time will tell, I guess...
C
Actually LISP is not that hard if you don't have to balance parenthesis manually. 10-15 years ago it was a pain, but with modern IDEs it should be very easy. And you can event apply C like formatting:
(
func1
(
func2 x y
)
(
func3 a b
)
)
One thing that appears pretty clear is that CLR/JVM are built for (static) imperative object-oriented languages, since that is what characterizes IL itself. Both of these paradigms are under attack - although Scala has shown a remarkable compromise, marrying object-orientedness and declarativeness. If the CLR is able to track purity, at least immutability, then maybe all the old baggage wohn't matter too much. It's also clear that on the continuum of adaptation we see small changes that allow explicit expression of parallelism in a convenient way, although very much depending on some level of purity. LINQ and Rx are more significant changes, although still nested in very impure host languages. It's still quite fascinating: what should be the "bottom language" - the language that everything else is expressed in terms of. Also interesting is the interaction between operating system and VM. We've already seen some discussion on this Dave Probert on the UMS and in the Flapjax interview.
Observing C-9 . . .
It's no accident that Emacs (your grandfather's IDE) + Lisp go together like, mmmmm, tea & crumpets? caramel & peanuts? sunshine & daisies? drum & bass? All but the core of Emacs is written in ELisp, and Emacs has a zillion indentation and paren-balancing tricks for making coding of Lisp (a.k.a. Lots of Insipid Silly Parentheses) tolerable.
And follow-up to your excellent interview, Brian.
Persistent Data Structures & Managed References
Quotes of the talk:
And the paper mentioned: "Why calculating is better than scheming"
What ever happened to that project Brian was working on (back in a vid with Erik on monads). Is he almost ready to c9 it? Language, library, or other?
Stay tuned
C
(func1
(func2 x y)
(func3 a b))
would look better IMHO though
(func1 (func2 x y) (func3 a b))
isn't all that bad to begin with.
So glad to see the Clojure for the CLR project revitalized! Kudos for getting Rich Hickey in a C9 interview, guys!
I just updated the status on ClojureCLR from 'alpha' to 'beta'. This is not an attempt to improve the code via wishful thinking, but an update to the README to bring it in accord with the current state of the code.
The project is under active development. It is usable. Only beta because of some things that still need work: a few missing things in CLR interop (assembly-qualified names for types, handling generic types); a need for an installer for casual users (as opposed to the current install process more suitable for the hardy); and some more tuning for performance. The wiki on the github site (http://github.com/richhickey/clojure-clr) is the best place to get a sense of what remains to be done.
What it needs most at the moment is people using it.
It looks like the intuition that a LISP(y) language like Clojure could be a nice compilation target for other languages, due to its extremely simple foundations, is not completely insane: I found this paper on compiling Java to Scheme (many times you see compiling Scheme to Java instead; reminding me of Gilad Bracha's statement about having a dynamic language at the bottom and decorating it with types afterwards: static on dynamic, not dynamic on static). The same should apply equally well to C#, VB et al. What do you think about the idea of using something like Clojure as the "bottom language" rather than just a top-language? In particular having more or less all data expressed in the nice Clojure datatypes? Sounds nice, except for mutable objects, reading...
PS - The feasibility of Haskell in Scheme
I've always liked the idea of a collection of interacting BCLs, each in its own little isolated realm of innocent, joyful imperativeness (that is, each in its own "ambient monad," whether that be just an appdomain or a whole process). Now, just design interprocess or inter-domain communication as monadic binds in serial and in parallel, plunk the whole thing down in a synchronization and scheduling discipline, and away you go. The synch-and-scheduling discipline could be Time Warp (though we still need to formulate the Time Warp monad precisely), or it could be IObserv* (we know this monad), or delimited continuations and coroutines (likely isomorphic to IObserv*).
That was just great.
It's really a privilege to have access to material like this for free, so thank you.
You're welcome! Much more to come!
C
Remove this comment
Remove this thread
close