4 ms·

> We are in an industry that is so new, so fast-moving and so financially rewarding that people tend to gravitate towards popular programming languages. These p

> We are in an industry that is so new, so fast-moving and so financially rewarding that people tend to gravitate towards popular programming languages. These people are quick to migrate to a new technology, they often skip fundamentals or simply have no interest in gaining fundamental knowledge. One might say that this simply signals the success of these languages in attracting newer programmers. Senior developers should have this fundamental knowledge regardless of language. I've read numerous impassioned calls to use a given language like this over time. Clojure, Haskell, every flavor of Lisp there is. More times than not, it leads me to a few weeks of buying into the hype, believing it's going to be the most transformational experience I've had as a developer. Lines like this seduce you so easily; who wouldn't want to be able to express their ideas with so little friction? > _ is the most expressive and flexible language. You can reach a flow-state where ideas can freely flow from your mind into code And these languages can be a good way to learn new ideas and paradigms, sure. But for me, a lot of their usefulness ends there. The tooling, documentation, community, and everything else beyond the language often matter as much as the language itself. And for better or worse, you simply have more eyeballs on these things as the language gets more popular.

yladiz 5y ago
>The tooling, documentation, community, and everything else beyond the language often matter as much as the language itself. And for better or worse, you simply have more eyeballs on these things as the language gets more popular. I would argue they matter even more than the language. Community is probably the main important one, but the others you mention are foundational too. For example having good documentation is crucial and is basically the way people get familiar with the language over time. For Clojure specifically, I think the shit documentation is one reason it will continue to grow slowly, because it reflects poorly on the maintainers and shows they don't care about newcomers or people who don't "know it". It's such a poor reflection on the language that the core documentation is so bad that there's the community one that exists purely to show examples and explain things that the terse docs don't.
- kbuchanan 5y ago
  It's true, the Clojure ecosystem is especially hostile to newcomers—in my view it's the principle reason the language has not grown more quickly. There are community members have made the documentation much more manageable, but beginners are still very much left to their own to discover solutions to pretty common problems. But I disagree that it reflects poorly on the maintainers—rather, I think it illustrates that, for the most part, Clojure was created by experienced language pragmatists, for other experienced pragmatists. Clojure tends to be a refuge from other languages, not something a person is born into. The State of Clojure each year consistently shows how many other languages Clojure users already knew before coming to the language. I appreciate how the maintainers value backwards-compatibility (nothing ever breaks, it only gets better), that they are strongly committed to making the language great in the long run, and are unmoved from the language's founding values. I do hope as a community we can do a better job for newcomers, for all our sakes—new blood brings new perspectives, but it's okay that "growing the community" isn't the Core team's top priority. (But hopefully becomes someone's priority in the community at some point...)
  - filoeleven 5y ago
    > I appreciate how the maintainers value backwards-compatibility (nothing ever breaks, it only gets better), that they are strongly committed to making the language great in the long run, and are unmoved from the language's founding values. This shows even in the half-life of the Clojure repo: https://m.imgur.com/a/rH8DC https://m.imgur.com/a/rH8DC That image is 5 years old now, I saw it in the 2016 discussion linked below, but the trajectory is clear especially when compared to the other popular repos analyzed in the post. https://news.ycombinator.com/item?id=13112449 https://news.ycombinator.com/item?id=13112449
- sokoloff 5y ago
  I am teaching myself Clojure now (starting around US Thanksgiving to be ready for some advent-of-code problems in it). I never found the docs lacking. Of course, I was using the community docs without knowing (nor caring) that they were community rather than core team docs. Clojure will grow slowly because it’s different (and “harder” in some ways) from other language platforms. I don’t think many people will be turned off by the fact that excellent docs are at a different URL.
didibus 5y ago
> believing it's going to be the most transformational experience I've had as a developer Learning Clojure was probably the most transformational experience I had as a developer. Before that I knew Python, C#, Java, C++, and a bit of Ruby and JS. But learning Clojure and getting to use the Lisp syntax, an interactive development workflow, learning about FP, the simplicity of immutable data, and the power of macros made programming interesting again and it just turns out I have so much more fun using Clojure to program in. > You can reach a flow-state where ideas can freely flow from your mind into code I wouldn't say that's totally the case. While the interactive development and the succinctness and simplicity of Clojure does help with my productivity, coding still requires thoughts, and asking yourself how do I implement this and that and thinking through it is still often needed for all but trivial tasks. The big difference for me is that this process is now a lot more fun and engaging. It might not be that you'll find a niche language like Clojure more fun and engaging, but it could be that you do, and that's the appeal I think. For some, there's a niche language out there that they just enjoy a lot more for one reason or another.
swlkr 5y ago
I went through a long clojure/lisp phase and although I’m not using anymore, I became a much better programmer because I can more easily see abstractions and how data flows through more complex systems using OOP or whatever.
roenxi 5y ago
There are also signals that Clojure is genuinely challenging to learn. If a language is favoured by senior developers and the user base tends to be people with a decade of programming experience then that is a hint that newbies can't learn the language. Maybe that is ok. Having an expert language to bolt on to Javascript or the JVM might be just what the doctor ordered. But there are a lot of tricky aspects to Clojure, and a lot of ideas that are outside the mainstream (eg, not really having variables). And the language leads people into complex nested functional structures that are challenging to debug - breaking up a big map or reduce to debug it when something is going wrong is not much fun. I can see people giving up and going back to for loops rather than toughing it out and learning how to do things functionally. And the tooling can be atrocious. Running "clj --help" and deciphering what it all means is not for the faint hearted. A user needs to be familiar with Clojure data structures, Java, build system ideas for both (like aliases, coordinates, namespaces, classpath, file loading process) as a prerequisite, then there are no hints from the deps.edn syntax so one has to read the entire manual to know what options there are. Doing something more than running a repl or a single file can easily spiral into an entire weekend project in my experience. That is a bit silly to admit to, but I suspect it is a big barrier in practice. The competition is "pip install" and Python lets multi-file projects work quite well even without understanding the packaging system. For a Java hosted language it is hard to avoid the classpath.
boppo1 5y ago
I read the term "fundamentals" so frequently, but so rarely see them enumerated and defined. What are 'the fundamentals'? K&R? SICP? Someone once answered 'knowing your data structures and algorithms' but the only thing I see more than 'fundamentals' is a derisive attitude toward leetcode (which seems to be about par for 'knowing your data structures and algorithms').
lkrubner 5y ago
But it's also the case that some programming communities are huge but not very intelligent. At the risk of indulging in a cliche, I'll point to the reputation that PHP had for many years, and which it still somewhat has. This was a community that was, for a long time, dominated by WordPress programmers who engaged in every possible worst practice and anti-pattern. You could, in a sense, get work done in PHP. But you didn't necessarily learn a lot while you were in that community. I mostly wrote PHP from 1999 to 2009. I got a lot done. I had fun. But it is a language that if you try to go fast, you automatically end up with sloppiness. More than most languages, the entropy sets in fast, the tech debt piles up unless you invest incredible effort to fight back against it. Ruby was better, and the Ruby community was much more intelligent, but in every Rails project I worked on, once it grew past a certain point, me and my team started having endless debates about "How should we refactor these fat models?" When I started writing Clojure, one thing that surprised me as how easy it was to avoid tech debt. Writing short functions comes naturally and without effort. Simply getting away from for() loops and using better aggregation structures cleans up the code in astonishing ways. The thoughtfulness and universalness of the seq interface impressed me in 2010 as much as the PHP "array" flexibility had impressed me in 2000. It was an obvious step forward. You could say I'm taking easy shots by focusing on PHP, but I could say some of the same things about Ruby. Handing blocks to iteration methods is better and cleaner than the ambitious confusion of the PHP array structure, but it still is not as clean or universal as what Clojure achieved with seq. And as Zach Tellman has said, it's a rare language where you can just scan a file and the syntax of the language tells you so much about the structure of the code. EDN has been designed with an unusual thoughtfulness.

yladiz 5y ago

>The tooling, documentation, community, and everything else beyond the language often matter as much as the language itself. And for better or worse, you simply have more eyeballs on these things as the language gets more popular. I would argue they matter even more than the language. Community is probably the main important one, but the others you mention are foundational too. For example having good documentation is crucial and is basically the way people get familiar with the language over time. For Clojure specifically, I think the shit documentation is one reason it will continue to grow slowly, because it reflects poorly on the maintainers and shows they don't care about newcomers or people who don't "know it". It's such a poor reflection on the language that the core documentation is so bad that there's the community one that exists purely to show examples and explain things that the terse docs don't.

kbuchanan 5y ago
It's true, the Clojure ecosystem is especially hostile to newcomers—in my view it's the principle reason the language has not grown more quickly. There are community members have made the documentation much more manageable, but beginners are still very much left to their own to discover solutions to pretty common problems. But I disagree that it reflects poorly on the maintainers—rather, I think it illustrates that, for the most part, Clojure was created by experienced language pragmatists, for other experienced pragmatists. Clojure tends to be a refuge from other languages, not something a person is born into. The State of Clojure each year consistently shows how many other languages Clojure users already knew before coming to the language. I appreciate how the maintainers value backwards-compatibility (nothing ever breaks, it only gets better), that they are strongly committed to making the language great in the long run, and are unmoved from the language's founding values. I do hope as a community we can do a better job for newcomers, for all our sakes—new blood brings new perspectives, but it's okay that "growing the community" isn't the Core team's top priority. (But hopefully becomes someone's priority in the community at some point...)
- filoeleven 5y ago
  > I appreciate how the maintainers value backwards-compatibility (nothing ever breaks, it only gets better), that they are strongly committed to making the language great in the long run, and are unmoved from the language's founding values. This shows even in the half-life of the Clojure repo: https://m.imgur.com/a/rH8DC https://m.imgur.com/a/rH8DC That image is 5 years old now, I saw it in the 2016 discussion linked below, but the trajectory is clear especially when compared to the other popular repos analyzed in the post. https://news.ycombinator.com/item?id=13112449 https://news.ycombinator.com/item?id=13112449
sokoloff 5y ago
I am teaching myself Clojure now (starting around US Thanksgiving to be ready for some advent-of-code problems in it). I never found the docs lacking. Of course, I was using the community docs without knowing (nor caring) that they were community rather than core team docs. Clojure will grow slowly because it’s different (and “harder” in some ways) from other language platforms. I don’t think many people will be turned off by the fact that excellent docs are at a different URL.

didibus 5y ago

> believing it's going to be the most transformational experience I've had as a developer Learning Clojure was probably the most transformational experience I had as a developer. Before that I knew Python, C#, Java, C++, and a bit of Ruby and JS. But learning Clojure and getting to use the Lisp syntax, an interactive development workflow, learning about FP, the simplicity of immutable data, and the power of macros made programming interesting again and it just turns out I have so much more fun using Clojure to program in. > You can reach a flow-state where ideas can freely flow from your mind into code I wouldn't say that's totally the case. While the interactive development and the succinctness and simplicity of Clojure does help with my productivity, coding still requires thoughts, and asking yourself how do I implement this and that and thinking through it is still often needed for all but trivial tasks. The big difference for me is that this process is now a lot more fun and engaging. It might not be that you'll find a niche language like Clojure more fun and engaging, but it could be that you do, and that's the appeal I think. For some, there's a niche language out there that they just enjoy a lot more for one reason or another.

swlkr 5y ago

I went through a long clojure/lisp phase and although I’m not using anymore, I became a much better programmer because I can more easily see abstractions and how data flows through more complex systems using OOP or whatever.

roenxi 5y ago

There are also signals that Clojure is genuinely challenging to learn. If a language is favoured by senior developers and the user base tends to be people with a decade of programming experience then that is a hint that newbies can't learn the language. Maybe that is ok. Having an expert language to bolt on to Javascript or the JVM might be just what the doctor ordered. But there are a lot of tricky aspects to Clojure, and a lot of ideas that are outside the mainstream (eg, not really having variables). And the language leads people into complex nested functional structures that are challenging to debug - breaking up a big map or reduce to debug it when something is going wrong is not much fun. I can see people giving up and going back to for loops rather than toughing it out and learning how to do things functionally. And the tooling can be atrocious. Running "clj --help" and deciphering what it all means is not for the faint hearted. A user needs to be familiar with Clojure data structures, Java, build system ideas for both (like aliases, coordinates, namespaces, classpath, file loading process) as a prerequisite, then there are no hints from the deps.edn syntax so one has to read the entire manual to know what options there are. Doing something more than running a repl or a single file can easily spiral into an entire weekend project in my experience. That is a bit silly to admit to, but I suspect it is a big barrier in practice. The competition is "pip install" and Python lets multi-file projects work quite well even without understanding the packaging system. For a Java hosted language it is hard to avoid the classpath.

boppo1 5y ago

I read the term "fundamentals" so frequently, but so rarely see them enumerated and defined. What are 'the fundamentals'? K&R? SICP? Someone once answered 'knowing your data structures and algorithms' but the only thing I see more than 'fundamentals' is a derisive attitude toward leetcode (which seems to be about par for 'knowing your data structures and algorithms').

lkrubner 5y ago

But it's also the case that some programming communities are huge but not very intelligent. At the risk of indulging in a cliche, I'll point to the reputation that PHP had for many years, and which it still somewhat has. This was a community that was, for a long time, dominated by WordPress programmers who engaged in every possible worst practice and anti-pattern. You could, in a sense, get work done in PHP. But you didn't necessarily learn a lot while you were in that community. I mostly wrote PHP from 1999 to 2009. I got a lot done. I had fun. But it is a language that if you try to go fast, you automatically end up with sloppiness. More than most languages, the entropy sets in fast, the tech debt piles up unless you invest incredible effort to fight back against it. Ruby was better, and the Ruby community was much more intelligent, but in every Rails project I worked on, once it grew past a certain point, me and my team started having endless debates about "How should we refactor these fat models?" When I started writing Clojure, one thing that surprised me as how easy it was to avoid tech debt. Writing short functions comes naturally and without effort. Simply getting away from for() loops and using better aggregation structures cleans up the code in astonishing ways. The thoughtfulness and universalness of the seq interface impressed me in 2010 as much as the PHP "array" flexibility had impressed me in 2000. It was an obvious step forward. You could say I'm taking easy shots by focusing on PHP, but I could say some of the same things about Ruby. Handing blocks to iteration methods is better and cleaner than the ambitious confusion of the PHP array structure, but it still is not as clean or universal as what Clojure achieved with seq. And as Zach Tellman has said, it's a rare language where you can just scan a file and the syntax of the language tells you so much about the structure of the code. EDN has been designed with an unusual thoughtfulness.