Software Engineering Radio

I want to lend my vote to this being one of the best episodes. It demonstrates Markus’ exceptional skill as an interviewer — I can barely stand to listen to other technical interviews now as they seem so clumsy and disengaged in comparison. In addition, Hickey’s arguments about programming problems and his decisions for his language are accessible to me as a professional programmer.

[...] Brownsword (Electronic Arts), The History of JUnit and the Future of Testing with Kent Beck, Rich Hickey on Clojure, and my favorite, Software Craftsmanship with Bob Martin. Check the site for a full [...]

Like the other commenters, I also loved this episode. It made me interested enough in Clojure to download it and play around with it (nice GUI one-liner “hello world” for instance). However, I’m the kind of guy who would need a good book or two to really understand anything in depth.

Very good interview.

I also lauged out load at the point where Marcus said “I have no practical experience with Lisp” … ^_^

Please keep the shows coming!

As a long-time listener, I always appreciate the quality of your content. But this episode is one of your best: a great interview with excellent questions and discussion. I really appreciate material that allows me to think differently about programming (or insists that I do so).

The shift to inclusion of persistent data structures and STM brings to mind the original “structured programming” insights, replacing thickets of branches with well-understood structures: though seemingly obvious in hindsight, requiring vision and courage to achieve initially.

Thank you again, and please keep it coming!

Really, another great episode, thank you SE-Radio and especially Markus. The discussion about persistent data structures really caught my interest.
Btw. monads were more or less discussed in those two episodes:
Episode 108: Simon Peyton Jones on Functional Programming and Haskell
Episode 72: Erik Meijer on LINQ
I loved the clojure.jar joke and hints about what a language really is. Maybe sometime there will be platform(s), computational model, abstract syntax, concrete syntax and tooling as a set of composable components composing a language with interoperability only through abstract syntax.

# Maybe sometime there will be platform(s), computational model,
# abstract syntax, concrete syntax and tooling as a set of composable
# components composing a language with interoperability only through
# abstract syntax.

take a look at MPS (http://jetbrains.com/MPS). It does get close to this idea. I was actually thinking about building a prototype that extends Java with nice syntax accessing Clojure’s concurrency primitives…

Markus

..because Markus asks the questions that OO developers would ask. Hickey’s “no man crosses the same river twice” (JVM Summit) presentation is fantastic, and the “ant colony” video certainly sets out Clojure’s approach -but I didn’t think I would really learn much more until I had subjected my head to some healthy Clojuring.

But no -Hickey seems to concede more room for (principled management of) state in this interview. It makes more sense now. Good stuff. Take the afternoon off, Markus.

Pete F

I think references and mutability are indispensble for adequate object-oriented modelling. If they are entirely excluded (like in R), that leads to severe limitations. Clojure seems to combine a mainly functional, “value computation centric” approach with some reference types, and so may be able to avoid those limitations and indeed provide the “best” (in some sense) of the functional and the mainstream object-oriented worlds.

I wonder, though, what happens if you work with a collection (list, array, whatever) that contains e.g. atoms — doesn’t this result in possible unrepeatable results on the collection…? Like Markus I’d like to have some time to take a closer look at Clojure and find out…

It seems to me that the problems of large object graphs were somewhat exaggerated in this episode. If there are inexplicable / nonsensical / butterfly-effect like chaotic effects of calling some apparently innocent method, that’s an indication of modelling or design problems. With a good model, effects ripple through the object graph if, and only if, that’s what happens in the part of reality (the problem domain) that is captured.

Like other commenters I quite like the humour in these podcasts. I wonder, though, whether the remark I found funniest was entirely intended to be so: “There’s an Emacs mode for Clojure, and those who like it a bit more traditional can try this Netbeans plugin…”

Just wanted to say that this is the best interview I’ve heard in a long time. Well done, Markus.