This starts out at a pretty high-level ("What is a Lisp? What is Clojure?"), but eventually gets into some pretty interesting details about things like how Clojure's immutable data structures are implemented (I'm only about halfway through so far)
I had the great pleasure of attending a few of Brian’s talks at Amazon. Spectacularly engaging presenter. His work on Time Warp is especially captivating.
Interesting. Brian Beckman was the one who helped me get my first clojure environment up and running at Amazon, probably around 2012 or 2013.
I noticed before I left (2016) that he didn't have any projects running with clojure anymore...at least within the Amazon repos. I wonder if he's still using it at all.
I tried to keep tabs on him after he left MS and I'm surprised to find out he ended up at Amazon. He was obviously able to make theory real-world applicable in a big way. LINQ changed my entire perspective on programming. But on top of that, he's an excellent teacher/leader. Why didn't he have any speaking engagements while at Amazon (at least that I can find)?
I didn't really follow the Amazon tech talks while I was there, so I'm not really sure. I also didn't even realize the significance of who I was talking to when I approached him. All I knew was that when I searched for clojure code in the repos, his was the first name that popped up. I dropped by his desk unannounced and we talked for like an hour and he walked me through setting up an environment there on the spot.
I'm pretty sure he was the one that pitched drone delivery to Bezos, and he had worked on it the entire time I was there. As far as clojure goes, I have no clue why he seemed to stop using it, although I have my suspicions. I think common lisp was probably a better fit for what he was doing, and he seemed to be quite the expert with it, although I think I recall him talking fondly of Scala and F# as well.
Do people still use Clojure? For a while I was really hot on Clojure ... but then I haven't had a project in ten years where it even makes sense to introduce it into operations ... generally I've got Python or Go on the server and some mix of JS, Dart, Objective C, or Kotlin on the front end depending on the client platform.
Maybe someday I'll be responsible for writing a system back end from scratch and I can take off on a flight of fancy like this.
We have 4 open reqs for Clojure devs.
It's still an attractive platform to be honest.
Our frontends and backends are Clojure/ClojureScript and we wouldn't want it any other way
Can confirm as well, still use it at work for building all new stuff.
> but then I haven't had a project in ten years where it even makes sense to introduce it into operations
You don't really need a reason, if you want too and like the language and working with it makes you happier and more productive go for it. Because there's also no reason not too.
What is the sweat spot for clojure? Seems like it could be useful in places where the programmers are also responsible for "data entry" and it's better to use a lisp instead of xml or java annotations.
IT's a good functionally biased general purpouse dynamic language, with lots of libraries available, quick edit/debug feedback cycle, good tooling, and also works on the frontend where it can share code with the backend. So a lot of things.
If Spring is a hard requirement, sure. Writing Java-in-Clojure is pointless. I meant it more in the sense if you value simplicity and you are starting a project more or less from scratch or integrating into a good Java project that doesn’t rely on crufty frameworks.
Brian Beckman has the best interviews on Channel 9 [1] and there's usually, maybe always, a whiteboard involved. They're a bit old but I'm sure they're not completely outdated.
Oh man, this videos is partly why I got so into functional programming (though it actually took around eight more years to get into Clojure). Here were two really smart people talking about functional programming concepts in a really clear, concise way, which was interesting enough for me to look up functional programming techniques, which in turn led me to Scala and Haskell.
I will be watching this video again...thanks for linking it!
A bit of experience using ClojureCLR several years ago. I had mostly .Net experience at the time and wanted to explore so tried it out. I created some WinForms and Console apps, successfully passing stuff to and from C# code. I can't say there were any glaring problems with it. It worked surprisingly well. But eventually it was obvious that .Net was a 2nd class platform. Just, tooling wasn't there, so I just moved all that code to the Java ecosystem instead.
I'm still fairly removed from clojure. Most of what I do read doesn't convince me it is worth it over common lisp.
That said, the idea of conj bring an extended cons sounds really nice. Are there examples where the "you can change the fundamental data structure and the algo still works" pans out?
I fear this will be a lot like our industry's love of tries. Mostly impractical and more likely to cause bugs. :(
"you can change the fundamental data structure and the algo still works" - it doesn't really pan out, and it's not important in my experience of using Clojure for about ~8 years.
What makes Clojure worth it is the pervasive reduction of mutable state across your program without the cost and rigidity of creating types everywhere. Also great sharing of code across Clojure and ClojureScript:
I used CL as a hobbiest for years but never in code I would get paid for. Clojure is a different story. That you can run it on the JVM is a game changer when you want to introduce the code to a production environment. The massive amount of Java libraries and tooling plus the operational knowledge that organizations have make it a much easier sell even with "all those rackets". More language related reasons I prefer it to Common Lisp are things the syntax for vectors, maps and sets that give those data structures a more first class feel (CL users will probably disagree), persistent data structures and overall a fresh feel to the language.
Notice how there is a method to take a snapshot of the compiler state, which includes making copies of several hash tables, and a corresponding restore method to put it back. Hey, isn't there some GoF Design Pattern for this? Memento or something.
The thing is, if hash tables and objects were immutable, the whole code would be a shitshow, and perform badly too.
It would just not have that one problem: it would never have to copy a hash table in order to have a copy of the old one.
Immutable HAMT hash tables that I could conj to and then assign back into the original location would be a reasonable middle ground. Then I would still need he snapshot method; but it wouldn't have to do anything beyond returning (copy me).
It occurs to me I could implement a shallow hash table copy function, such that the original and new table share chains. Mutating either table (overwriting an existing key/value pair with a new value) would show up in the other, but deletions and insertions would not.
Internally those are "persistent data structures" in Clojure which don't duplicate the data but instead mutate a underlying tree that links both the old state and the new state
Then as a developer you are looking into a certain piece of that tree depending on what bit of the "mutated value" you are viewing
I assume this is to help ensure memory usage doesn't balloon but if you need to do mutation there are non-default features for doing that: https://clojure.org/reference/transients with all the pros and cons of mutation
