11 ms·

Clojure 15th Anniversary: A Retrospective

170 points by simonpure 4y ago

dvrp 4y ago
I truly wonder where will Clojure be in 10 years.
- chaps 4y ago
  Still optimistically hopeful the wider world will use it one day.
jonahbenton 4y ago
Highly recommend seeing some of the technical presentations NuBank folks have put together (even before buying Cognitect). Some of the most impressive technical work I have ever seen.
- Dopameaner 4y ago
  Are you referring to anything other than the infoq talks. Those were good.
ngcc_hk 4y ago
The problem is how to reliably installed. Only install it once. But wilder issue is can it run on notebook (I can do lisp after some struggle but not sure about this) for ease of sharing of idea. The iPad version used a bit but not sure about too many things and I switch back to common lisp.
- kimi 4y ago
  What is there to install? once you have Java, there is nothing else but Clojure itself (that is a Java library...)
billfruit 4y ago
From my brief time trying it out about 3-4 years ago, the major things that needs improvement include: 1. Improve startup times. 2. Ditch leiningen, its functionality should be included in base clojure. 3. Emacs toolchain for Clojure seems massively complex and have too many parts. Makes it difficult to get it reliably installed/setup. 4. Getting it set up on Windows seems obscure, which shouldn't be. Part of the problem is that lein is not distributed with clojure. 5. Error messages are cryptic. 6. Needs a lisp style debugger. Once an exception occurs we need to get a repl at that point of state. 7. Needs provision include Local jars easily without having to set up a maven repo for the same. This is very important for hobbyist work, and for exploratory programming.
- kimi 4y ago
  Modern Clojure includes that - it's deps.edn (though I'm good with Leiningen). And ditch Emacs (unless you are already using it/used to it) and try VSCode + Calva that runs basically out of the box. Exceptions... yes.... they are clear when you know what they mean, but it takes time, because they are so long. Startup... you only start a REPL once, so does not really matter (to me at least). For compiled code, you can try GraalVM, that has zero-ish startup time - because all static initialization is resolved at compile-time. Just my $.02 Edit: Calva also includes a debugger - never used it, but here it is https://calva.io/debugger/ https://calva.io/debugger/
  - funstuff007 4y ago
    > you only start a REPL once, so does not really matter People say this a lot in Clojure, but don't you worry about global vars that no longer point to what you thought they pointed to? For this reason alone, I almost always load a new Python REPL.
    - kimi 4y ago
      Not sure what you mean here, but... no. You can rebind, of course, but I never found myself in a situation where the REPL was too bad to be used. I usually restart the REPL only when I add a dependency, so it will be fetched without me caring about it.
e3bc54b2 4y ago
As someone who really really tried to like Clojure, here's the issues I faced, roughly in order starting from biggest: 1. No framework. Clojurists tend to prefer libraries and I would too, but for a newbie starting out, when every other language seems to have converged on one standard way of doing things (Spring, Rails, Phoenix, Django etc), Clojure just gets in the way with decision fatigue. 2. Leaky abstraction. At every level it is apparent that Clojure is hosted on JVM or Javascript. Simply knowing Clojure is not enough, and you have to understand the underlying semantics to know what is going on. Exception stack traces are excellent example. 3. Unmaintained libs. While the language is stable and libs are much more likely to work still, unmaintained libs often mean some stuff does not work or needs to be figured out. Often people just drop to using Java libs instead, but then the wrapping business tends to get tedious. 4. Java is improving faster with more pattern matching, records and functional programming features. Other JVM hosted languages are becoming less appealing.
- lgrapenthin 4y ago
  1) There are enough templates and starter packs with documentation. Frameworks have been tried, but they quickly turn out to limit your Clojure given powers. 2) Thats true, but its not leaky abstraction. Clojure never claims to abstract the host away, it embraces it so you can do all low level Java/JS stuff and seemlessly use their libraries without FFIs. 3) You have all Java/JS libs. Most Clojure libs are simply "done", so they get no commits. I don't know of any unmaintend ones. 4) Java is improving? Clojure is mostly done with that already. It was designed long after Java and makes many improvements obsolete.
  - spinningarrow 4y ago
    I think this response is a good illustration of the frustration that I (and I suspect many others) have with Clojure. I’m speaking as someone who’s been excited by it since around 2012, has helped run Clojure meetups, and has tried many times to advocate for its usage. I really _really_ want to love Clojure but the first three points (unfortunately along with the Lisp syntax simply because it’s different enough) alienate too many people from the language and it seems like that’s something that Clojure has at best accepted as not the target audience and at worst is still unwilling to acknowledge.
DeathArrow 4y ago
Sorry to sound so misinformed, but since Clojure is a Lisp, what advantages does it have over other Lisp dialects such as Common Lisp?
- simongray 4y ago
  https://clojure.org/about/rationale https://clojure.org/about/rationale
  - DeathArrow 4y ago
    Thanks. I know how to search the internet. I was more interested to hear someone's opinion. Preferably opinion of someone who worked with Clojure and another Lisp dialect.
    - throwamon 4y ago
      Good news, the link provided ticks all your boxes: - You didn't have to search for it - Someone's (Rich Hickey's) opinion - He has worked with Clojure - He has worked with another Lisp dialect
    - vindarel 4y ago
      There's this: testimonies from lispers https://gist.github.com/vindarel/3484a4bcc944a5be143e74bfae1025e4 https://gist.github.com/vindarel/3484a4bcc944a5be143e74bfae1... gently biased towards CL.
    - simongray 4y ago
      I have worked professionally—and almost exclusively—with Clojure since 2018. That rationale answers the question you had. Stop being so passive-aggressive.
- eigenhombre 4y ago
  Wrote Clojure professionally for eight years, and Common Lisp enthusiast. Clojure, the product (largely) of one person, is more opinionated than CL, the product of a committee. As a result, I find its design to be more cohesive, being oriented around functional programming and a set of core abstractions which play very well together. It has a bit more syntax than CL does out of the box, mostly for collection types. But the biggest practical difference for many people, once they get their heads around Clojure's functional nature, is Java interop and the JVM. It is idiomatic to use Java classes directly from Clojure, and the library ecosystem is just vast, dwarfing any other lisp's. Deployment as an uberjar is typically a smooth story. These days I'll reach for Common Lisp for personal projects, simply because of its startup speed and because I like some of the quirks of the language. But if I am going to need a library I know exists in Clojure/Java and is solid, which does happen, Clojure's a no-brainer for me. Finally, there are a lot more jobs for Clojure than for CL, as far as I can tell.
manx 4y ago
Clojure is dynamically typed, right? Just curious: how do you refactor large codebases without a compiler telling you if the pieces still fit together? (I'm coming from Scala)
- kaba0 4y ago
  While there are some static type libs for clojure if I’m not mistaken, the standard solution is to use spec, which employs contracts. These can be used to check arbitrary things at runtime, with quite readable error messages. Also, due to the extensive use of FP and not much side effects, you can catch most of these mistakes at test time - not the same as a good static type system, but it is an interesting tradeoff, better expressivity, but not happening at compile time.
  - KingMob 4y ago
    The standard advice with spec is to use it at the edges of the system, and not for every function and input. Probably because it incurs runtime overhead to use, and design overhead to apply. On top of which, it's still listed as "alpha" after 6+ years. As a runtime contract, spec can check things type systems can't, but IMO it's not pervasive enough in most code bases to really satisfy.
    - kaba0 4y ago
      Yeah, I absolutely agree. (Though perhaps using them internally as well may be okay, just disable it at prod)
- lukashrb 4y ago
  Could you specify, what you mean by "refactor large codebases"? > compiler telling you if the pieces still fit together? You still write tests in scala do you?
  - manx 4y ago
    Since types give me guarantees that pieces still fit together, I usually only need a handful of unit tests for my non-trivial algorithms, plus some integration tests. Never for functions which hand things around. After fixing all compile errors caused by a massive code change it almost always still just works.
nnmg 4y ago
I'll always admire clojure. Loved the simplicity and philosophy, and I wrote a few toy projects. Unfortunately I felt like I could never really take advantage of the power of clojure or do real work in it because I didn't know or have a history with Java. It always felt like clojure was for enlightened Java or JS programmers, and I didn't want to learn Java and clojure at once so I was stuck in beginner land.
- casion 4y ago
  You don't need to learn Java, only be aware of it. Nubank has 100(0?)s of devs that don't know Java at all and successfully use Clojure. Even if your assumption is true, what's wrong with that? A language which offers more value over an existing base of knowledge is valuable and isn't uncommon.
  - geokon 4y ago
    Past a very baby level you kinda need to know the JVM world a bit. Lots of keywords like "classpath", Maven, reflection etc.. You def don't need to know Java as a whole, but it was actually a little challenging and confusing to catch up on the relevant JVM bits. Educational material either doesn't use it at all or assumes you know it
slifin 4y ago
Here's to many more anniversaries Clojure doubled my salary in 2 years and made programming fun again
lukashrb 4y ago
I'm really greatful for clojure to exist. It exposed me to a lot of concepts and gave me a new perspective to think about problems, which in turn helped me to grow tremendously as a developer. The emphasis to work directly with the data is quite unique to clojure (as I'm aware of, please proof me wrong on this) which allows me to just dive in and think about the problem I want to solve instead of fighting my language or framework. The interactivity of the environment paired with immutability results in an instant feedback loop which let me get into mental flow really fast, which is a joy.
dmichulke 4y ago
Happy birthday, most of my projects these days in clojure/script, including - an (admittedly tiny) BI tool clone (think metabase / PowerBI) - a search engine for private charter flights - a live trading bot for cryptocurrencies (it's only breaking even though) Altogether 17k lines of code. What else is there to say?
jakebasile 4y ago
Clojure really brings out the negativity in a lot of people. I love the language and the ecosystem and it's done wonders for my career. Is it perfect? No. There are definitely warts. But whenever Clojure is brought up I tend to see a lot of the same criticisms. I feel compelled to defend the honor of my favorite language, so here's my perspective on a couple of the perennial issues people bring up. This doesn't mean that if you think these things you're wrong, but this is my perspective having used Clojure for a long time. Startup times are a non issue. Does the fact your server takes a few extra seconds to start on deploy actually matter? No, it doesn't. In development I hardly restart my REPL unless I update a dependency or pull from a branch. Even in the latter case I can usually use Cider to refresh it. In my 8 years of writing Clojure that other people give me money for I can confidently say it's never been a big issue. I love that it runs on the JVM and doesn't hide it. There's infinite libraries for every weird enterprise B2B widget so I don't have to screw around (much) to get them to work. The JVM is a great tool and runs on anything. Types. Everyone always hand wrings about types because they don't understand how anyone could possibly refactor the huge data structures they're used to from OOP without types. It's also, largely, a non issue. For one, data structures are not the abstraction in functional programming. Functions are. You don't need to write class OtherCompanyAccountsGetter, you just write a function that maybe takes a couple parameters and returns the accounts. You then test that function. Then you build more functions on top of it. If the underlying API changes you go change that one function and make sure your tests still pass. If something drastically changes about inputs you can easily find all usages and fix things up. Additionally, in my experience, FP leads to systems that need far less big time refactoring than OOP, since things are encouraged to be broken up into much smaller pieces (functions) and those pieces are meant to be black boxes. The worst Clojure codebase I've worked in was far easier to understand than the worst OOP codebase I've worked in.
- mountainriver 4y ago
  Types are pretty useful outside of OOP for catching a bunch of runtime errors and serving as documentation to help understand the code. I haven’t written a ton of clojure but every large untyped code base I’ve seen is a mess, and usually there are people around it claiming it’s not
jiyinyiyong 4y ago
Congratulations to Clojure! I used ClojureScript for several years and I still consider it the best designed dynamic language in the open community. JavaScript might be great in many aspects due to huge contributions from Google and Mozilla, but it can hardly fix its young and immature designs made in last century. Personally I moved to my own language Calcit for my own projects using dynamic language tools. Calcit is still following lots of designs from Clojure.
tmountain 4y ago
Early Clojure adopter here (2008). Clojure completely transformed the way that I think about programming, and Rich Hickey's talks ignited a passion for computer science that still drives me to this day. While I use Clojure less than I used to, I view it as a truly beautiful language with a coherent and thoughtful design. The community has always been fantastic, and the thought leaders (rich, stu, fogus, chouser, david nolan, etc) have given so much to the world. I'm very happy to see the language is still making forward progress and has carved out ecosystems (i.e., finance) where it's finding solid adoption. Not much else to say besides a huge THANK YOU to everyone that has helped bring it this far. It has brought a lot of people a lot of joy.

170 points by simonpure 4y ago

dvrp 4y ago

I truly wonder where will Clojure be in 10 years.

chaps 4y ago
Still optimistically hopeful the wider world will use it one day.

jonahbenton 4y ago

Highly recommend seeing some of the technical presentations NuBank folks have put together (even before buying Cognitect). Some of the most impressive technical work I have ever seen.

Dopameaner 4y ago
Are you referring to anything other than the infoq talks. Those were good.

ngcc_hk 4y ago

The problem is how to reliably installed. Only install it once. But wilder issue is can it run on notebook (I can do lisp after some struggle but not sure about this) for ease of sharing of idea. The iPad version used a bit but not sure about too many things and I switch back to common lisp.

kimi 4y ago
What is there to install? once you have Java, there is nothing else but Clojure itself (that is a Java library...)

billfruit 4y ago

From my brief time trying it out about 3-4 years ago, the major things that needs improvement include: 1. Improve startup times. 2. Ditch leiningen, its functionality should be included in base clojure. 3. Emacs toolchain for Clojure seems massively complex and have too many parts. Makes it difficult to get it reliably installed/setup. 4. Getting it set up on Windows seems obscure, which shouldn't be. Part of the problem is that lein is not distributed with clojure. 5. Error messages are cryptic. 6. Needs a lisp style debugger. Once an exception occurs we need to get a repl at that point of state. 7. Needs provision include Local jars easily without having to set up a maven repo for the same. This is very important for hobbyist work, and for exploratory programming.

kimi 4y ago
Modern Clojure includes that - it's deps.edn (though I'm good with Leiningen). And ditch Emacs (unless you are already using it/used to it) and try VSCode + Calva that runs basically out of the box. Exceptions... yes.... they are clear when you know what they mean, but it takes time, because they are so long. Startup... you only start a REPL once, so does not really matter (to me at least). For compiled code, you can try GraalVM, that has zero-ish startup time - because all static initialization is resolved at compile-time. Just my $.02 Edit: Calva also includes a debugger - never used it, but here it is https://calva.io/debugger/ https://calva.io/debugger/
- funstuff007 4y ago
  > you only start a REPL once, so does not really matter People say this a lot in Clojure, but don't you worry about global vars that no longer point to what you thought they pointed to? For this reason alone, I almost always load a new Python REPL.
  - kimi 4y ago
    Not sure what you mean here, but... no. You can rebind, of course, but I never found myself in a situation where the REPL was too bad to be used. I usually restart the REPL only when I add a dependency, so it will be fetched without me caring about it.

e3bc54b2 4y ago

As someone who really really tried to like Clojure, here's the issues I faced, roughly in order starting from biggest: 1. No framework. Clojurists tend to prefer libraries and I would too, but for a newbie starting out, when every other language seems to have converged on one standard way of doing things (Spring, Rails, Phoenix, Django etc), Clojure just gets in the way with decision fatigue. 2. Leaky abstraction. At every level it is apparent that Clojure is hosted on JVM or Javascript. Simply knowing Clojure is not enough, and you have to understand the underlying semantics to know what is going on. Exception stack traces are excellent example. 3. Unmaintained libs. While the language is stable and libs are much more likely to work still, unmaintained libs often mean some stuff does not work or needs to be figured out. Often people just drop to using Java libs instead, but then the wrapping business tends to get tedious. 4. Java is improving faster with more pattern matching, records and functional programming features. Other JVM hosted languages are becoming less appealing.

lgrapenthin 4y ago
1) There are enough templates and starter packs with documentation. Frameworks have been tried, but they quickly turn out to limit your Clojure given powers. 2) Thats true, but its not leaky abstraction. Clojure never claims to abstract the host away, it embraces it so you can do all low level Java/JS stuff and seemlessly use their libraries without FFIs. 3) You have all Java/JS libs. Most Clojure libs are simply "done", so they get no commits. I don't know of any unmaintend ones. 4) Java is improving? Clojure is mostly done with that already. It was designed long after Java and makes many improvements obsolete.
- spinningarrow 4y ago
  I think this response is a good illustration of the frustration that I (and I suspect many others) have with Clojure. I’m speaking as someone who’s been excited by it since around 2012, has helped run Clojure meetups, and has tried many times to advocate for its usage. I really _really_ want to love Clojure but the first three points (unfortunately along with the Lisp syntax simply because it’s different enough) alienate too many people from the language and it seems like that’s something that Clojure has at best accepted as not the target audience and at worst is still unwilling to acknowledge.

DeathArrow 4y ago

Sorry to sound so misinformed, but since Clojure is a Lisp, what advantages does it have over other Lisp dialects such as Common Lisp?

simongray 4y ago
https://clojure.org/about/rationale https://clojure.org/about/rationale
- DeathArrow 4y ago
  Thanks. I know how to search the internet. I was more interested to hear someone's opinion. Preferably opinion of someone who worked with Clojure and another Lisp dialect.
  - throwamon 4y ago
    Good news, the link provided ticks all your boxes: - You didn't have to search for it - Someone's (Rich Hickey's) opinion - He has worked with Clojure - He has worked with another Lisp dialect
  - vindarel 4y ago
    There's this: testimonies from lispers https://gist.github.com/vindarel/3484a4bcc944a5be143e74bfae1025e4 https://gist.github.com/vindarel/3484a4bcc944a5be143e74bfae1... gently biased towards CL.
  - simongray 4y ago
    I have worked professionally—and almost exclusively—with Clojure since 2018. That rationale answers the question you had. Stop being so passive-aggressive.
eigenhombre 4y ago
Wrote Clojure professionally for eight years, and Common Lisp enthusiast. Clojure, the product (largely) of one person, is more opinionated than CL, the product of a committee. As a result, I find its design to be more cohesive, being oriented around functional programming and a set of core abstractions which play very well together. It has a bit more syntax than CL does out of the box, mostly for collection types. But the biggest practical difference for many people, once they get their heads around Clojure's functional nature, is Java interop and the JVM. It is idiomatic to use Java classes directly from Clojure, and the library ecosystem is just vast, dwarfing any other lisp's. Deployment as an uberjar is typically a smooth story. These days I'll reach for Common Lisp for personal projects, simply because of its startup speed and because I like some of the quirks of the language. But if I am going to need a library I know exists in Clojure/Java and is solid, which does happen, Clojure's a no-brainer for me. Finally, there are a lot more jobs for Clojure than for CL, as far as I can tell.

manx 4y ago

Clojure is dynamically typed, right? Just curious: how do you refactor large codebases without a compiler telling you if the pieces still fit together? (I'm coming from Scala)

kaba0 4y ago
While there are some static type libs for clojure if I’m not mistaken, the standard solution is to use spec, which employs contracts. These can be used to check arbitrary things at runtime, with quite readable error messages. Also, due to the extensive use of FP and not much side effects, you can catch most of these mistakes at test time - not the same as a good static type system, but it is an interesting tradeoff, better expressivity, but not happening at compile time.
- KingMob 4y ago
  The standard advice with spec is to use it at the edges of the system, and not for every function and input. Probably because it incurs runtime overhead to use, and design overhead to apply. On top of which, it's still listed as "alpha" after 6+ years. As a runtime contract, spec can check things type systems can't, but IMO it's not pervasive enough in most code bases to really satisfy.
  - kaba0 4y ago
    Yeah, I absolutely agree. (Though perhaps using them internally as well may be okay, just disable it at prod)
lukashrb 4y ago
Could you specify, what you mean by "refactor large codebases"? > compiler telling you if the pieces still fit together? You still write tests in scala do you?
- manx 4y ago
  Since types give me guarantees that pieces still fit together, I usually only need a handful of unit tests for my non-trivial algorithms, plus some integration tests. Never for functions which hand things around. After fixing all compile errors caused by a massive code change it almost always still just works.

nnmg 4y ago

I'll always admire clojure. Loved the simplicity and philosophy, and I wrote a few toy projects. Unfortunately I felt like I could never really take advantage of the power of clojure or do real work in it because I didn't know or have a history with Java. It always felt like clojure was for enlightened Java or JS programmers, and I didn't want to learn Java and clojure at once so I was stuck in beginner land.

casion 4y ago
You don't need to learn Java, only be aware of it. Nubank has 100(0?)s of devs that don't know Java at all and successfully use Clojure. Even if your assumption is true, what's wrong with that? A language which offers more value over an existing base of knowledge is valuable and isn't uncommon.
- geokon 4y ago
  Past a very baby level you kinda need to know the JVM world a bit. Lots of keywords like "classpath", Maven, reflection etc.. You def don't need to know Java as a whole, but it was actually a little challenging and confusing to catch up on the relevant JVM bits. Educational material either doesn't use it at all or assumes you know it

slifin 4y ago

Here's to many more anniversaries Clojure doubled my salary in 2 years and made programming fun again

lukashrb 4y ago

I'm really greatful for clojure to exist. It exposed me to a lot of concepts and gave me a new perspective to think about problems, which in turn helped me to grow tremendously as a developer. The emphasis to work directly with the data is quite unique to clojure (as I'm aware of, please proof me wrong on this) which allows me to just dive in and think about the problem I want to solve instead of fighting my language or framework. The interactivity of the environment paired with immutability results in an instant feedback loop which let me get into mental flow really fast, which is a joy.

dmichulke 4y ago

Happy birthday, most of my projects these days in clojure/script, including - an (admittedly tiny) BI tool clone (think metabase / PowerBI) - a search engine for private charter flights - a live trading bot for cryptocurrencies (it's only breaking even though) Altogether 17k lines of code. What else is there to say?

jakebasile 4y ago

Clojure really brings out the negativity in a lot of people. I love the language and the ecosystem and it's done wonders for my career. Is it perfect? No. There are definitely warts. But whenever Clojure is brought up I tend to see a lot of the same criticisms. I feel compelled to defend the honor of my favorite language, so here's my perspective on a couple of the perennial issues people bring up. This doesn't mean that if you think these things you're wrong, but this is my perspective having used Clojure for a long time. Startup times are a non issue. Does the fact your server takes a few extra seconds to start on deploy actually matter? No, it doesn't. In development I hardly restart my REPL unless I update a dependency or pull from a branch. Even in the latter case I can usually use Cider to refresh it. In my 8 years of writing Clojure that other people give me money for I can confidently say it's never been a big issue. I love that it runs on the JVM and doesn't hide it. There's infinite libraries for every weird enterprise B2B widget so I don't have to screw around (much) to get them to work. The JVM is a great tool and runs on anything. Types. Everyone always hand wrings about types because they don't understand how anyone could possibly refactor the huge data structures they're used to from OOP without types. It's also, largely, a non issue. For one, data structures are not the abstraction in functional programming. Functions are. You don't need to write class OtherCompanyAccountsGetter, you just write a function that maybe takes a couple parameters and returns the accounts. You then test that function. Then you build more functions on top of it. If the underlying API changes you go change that one function and make sure your tests still pass. If something drastically changes about inputs you can easily find all usages and fix things up. Additionally, in my experience, FP leads to systems that need far less big time refactoring than OOP, since things are encouraged to be broken up into much smaller pieces (functions) and those pieces are meant to be black boxes. The worst Clojure codebase I've worked in was far easier to understand than the worst OOP codebase I've worked in.

mountainriver 4y ago
Types are pretty useful outside of OOP for catching a bunch of runtime errors and serving as documentation to help understand the code. I haven’t written a ton of clojure but every large untyped code base I’ve seen is a mess, and usually there are people around it claiming it’s not

jiyinyiyong 4y ago

Congratulations to Clojure! I used ClojureScript for several years and I still consider it the best designed dynamic language in the open community. JavaScript might be great in many aspects due to huge contributions from Google and Mozilla, but it can hardly fix its young and immature designs made in last century. Personally I moved to my own language Calcit for my own projects using dynamic language tools. Calcit is still following lots of designs from Clojure.

tmountain 4y ago

Early Clojure adopter here (2008). Clojure completely transformed the way that I think about programming, and Rich Hickey's talks ignited a passion for computer science that still drives me to this day. While I use Clojure less than I used to, I view it as a truly beautiful language with a coherent and thoughtful design. The community has always been fantastic, and the thought leaders (rich, stu, fogus, chouser, david nolan, etc) have given so much to the world. I'm very happy to see the language is still making forward progress and has carved out ecosystems (i.e., finance) where it's finding solid adoption. Not much else to say besides a huge THANK YOU to everyone that has helped bring it this far. It has brought a lot of people a lot of joy.