Expert to Expert: Rich Hickey and Brian Beckman - Inside Clojure

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.

  • ClojureCLR
  • ClojureScript
  • Scala on 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

       )

  )

   

   

  it becomes very straight forward.

• 

  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:

  • "Unless you think of composites as values, you're doomed, You might not be doomed now, but you'll be doomed in the future."
  • "...and our class libraries have destroyed our brains in this area" (speaking of mutable objects, specifically a mutable date object)

  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