5 ms·

I don't like working with clojure. Its basically modern perl. I've worked with both professionally, and the outstanding point with both has been: - programmer

I don't like working with clojure. Its basically modern perl. I've worked with both professionally, and the outstanding point with both has been: - programmers try to be clever in their code, write one giant file full of complicated specialized 'beautiful' code, forget everything they know about breaking big tasks into simple small ones. - code is a nightmare to maintain for non-author - non-authors working on code results in adhoc mess of styles Play with, sure. Learn a few things and watch the videos, absolutely. Rich is a really thoughtful talker. I actually quite enjoyed clojure before I had to collaborate on a code base. ...but goodness me. I cannot strongly enough recommend against using it professionally.

davedx 9y ago
> - programmers try to be clever in their code, write one giant file full of complicated specialized 'beautiful' code, forget everything they know about breaking big tasks into simple small ones. What on earth does this have to do with clojure? Programmers will do this in any language, there's nothing special about clojure here. I personally don't find LISP languages to be the most readable, but I'm fairly sure it's subjective. If you learned LISP and then went to Java, your brain would probably struggle to process all the verbosity...
- shadowmint 9y ago
  Rubbish. I've worked with a dozen languages, and its unquestionable that certain ones attact a high ratio of terse complicated code. Clojure is specifically renouned (and celebrated) for its low LOC counts; people go as far as saying (literally on /r/clojure) given a choice of library, pick the one with a lower LOC. That's not because people write simple pointless libs like lpad; its because the community actively encourages terse complicated code.
  - yogthos 9y ago
    This is demonstrably false.
  - ambulancechaser 9y ago
    I've seen this logic about choosing a library but I think you are attributing a different rationale to it. I've seen it said if you find more than one library doing what you need, go through a hierarchy of criteria to choose and choose the first one that wins; in the event of a tie, evaluate the next point 1. pick the one with the most readable, understandable architecture 2. choose the one that focuses more on what you are looking for and not a slew of different things 3. choose the one with fewer lines of code This third point is not "choose the more clever library" but more along the lines of choose the more straight forward and simple library. It's not code density you are evaluating but focus.
  - specialist 9y ago
    Hearing you on FM. (Totally agree with you.) But honest question: Does where you work in the stack, meaning the level of abstraction, matter for language choice? Or vice versa? I've written a few parsers in Java. Not terrific but not terrible either. My (future) interest in Clojure is CSP. Mostly because I'm tired of wrestling with concurrency. But I'm not sure I'd want to be doing data processing with it.
- magpi3 9y ago
  > What on earth does this have to do with clojure? Programmers will do this in any language, there's nothing special about clojure here. I haven't programmed in Java in over ten years, but one if its "advantages" (at least back in the day) was what I called its object-oriented handcuffs, which prevented programmers from being too fancy with their code. Every file had to be a class. Every class was an object. Namespaces were clearly and rigidly defined. Setters and getters were standard for defining properties of an object. Etc. The net result was frustration for programmers who detested such rigidity, but relief for any new programmer coming into a project because Java made it very difficult to write the kind of "specialized beautiful code' that shadowmint laments. Lisps in particular allow the kind of freedom that programmers love and project managers hate. And I say that as someone who loves writing code in lisp (racket in particular).
  - DigitalJack 9y ago
    I've never seen anyone put more than one namespace in a single file in clojure. I don't think the compiler would even understand that... While you can define classes in clojure, it's not the common way to do things, and so namespaces take the role of classes insofar as compartmentalizing code. It's not normal to operate on data in another namespace directly... you can do it, but it doesn't feel natural in the language. You do it through an interface (called a protocol in clojure), or through functions in that namespace. So in that sense, you are still using getters and setters for everything. But yeah, there is a lot of freedom in clojure. And that favors the writer, not the reader. Hence it can be difficult to grok somebody's code if they are more comfortable using the more advanced features of the language.
    - hellofunk 9y ago
      > namespaces take the role of classes insofar as compartmentalizing code Indeed! In fact, this is one of the sanest ways to do something resembling OO in Clojure.
  - cnlwsu 9y ago
    Java still has same issue too with bored engineers. Over engineering happens. AbstractSingletonProxyFactoryBean anyone? But really strongly typed languages like java is easier than most dynamic typing language to jump into _if the project is sane_.
yogthos 9y ago
I've been working with Clojure professionally for the past 6 years, and this is completely contrary to my experience. Clojure is the first language I've used where I'm able to easily read through libraries and understand them. Clojure uses a small number of common patterns that are applied to solving a wide variety of problems. Most code in the wild that I've seen tends to actually look very similar, and follows common structure. I've contributed to many Clojure libraries, and many people have contributed to libraries I maintain. My team also maintains Clojure projects that have been in production for years, and we find them much easier to maintain than comparable Java projects we've written previously.
- tigershark 9y ago
  Maybe you didn't have much experience in programming before learning clojure? I never had any problems in understanding how a library worked in a language that I knew. And I have looked at the source code of quite big libraries in my life.
  - yogthos 9y ago
    I've worked with Java for over a decade in the enterprise before I started using Clojure.
    - tigershark 9y ago
      And which Java libraries where so complex that you could not understand them?
      - yogthos 9y ago
        I didn't say I couldn't understand them. I was talking about the amount of time it takes to understand a typical library in a language like Java. My experience is that you would have to spend a lot of time jumping through different classes, and often have to step through things in a debugger to understand them. By contrast, I find that code in Clojure libraries to be much easier to read and understand. You literally needs orders of magnitude less code to solve same kinds of tasks, and it tends to be organized much better. I can open a namespace and read it top to bottom to see what it's doing. That's pretty much never the case with a non-trivial Java class. As a concrete example consider the Java Flyway migrations library to the Clojure migratus library that I've taken over maintaining https://github.com/flyway/flyway/tree/master/flyway-core/src/main/java/org/flywaydb/core https://github.com/flyway/flyway/tree/master/flyway-core/src... https://github.com/yogthos/migratus/tree/master/src/migratus https://github.com/yogthos/migratus/tree/master/src/migratus They both provide same core functionality, and I was able to understand the Clojure version in a few hours. It would take me much longer to understand Flyway or to be meaningfully contribute to it.
miguelrochefort 9y ago
I think that's true for most languages that are dynamically typed and let you effortlessly implement your own DSLs.
cnlwsu 9y ago
I worked on a large-ish clojure project with ~15 (people left and joined) person team for years and I haven't experienced any of your points. Sounds more like an new project with a group of people not quite familiar with the language yet, which would have the problems you listed in any language.
KirinDave 9y ago
Are we doing opinion threads now? Okay. I can do one too! I do like working with clojure. It's my favorite dynamically typed programming language by an easy margin. It's basically everything that was a good idea in Python and Ruby brought under the unifying role of a Lisp syntax, with a good Java FFI. This makes it slightly harder to learn (it's very difficult to learn Clojure if you don't at least know Java). It has a very clean syntax for the most part. Parenthesis handling does need some automation (basically everyone copied paredit) but has the nice property that refactoring is a breeze and extremely predictable. Except for rogue agents like me and a few others, very few programmers go crazy with defmacro, which makes Clojure often a lot more orderly and understandable than lots of Common Lisp code. I've run a shop with 6 clojure developers collaborating with engineers in both mobile and web space, and in many places Clojure was such a delight that cljs began to creep into the web frontends. In many cases the mobile devs contributed API endpoint handlers to the codebase and they said in general it was easy to work with (although folks sometimes had problems with more complex map types; often because of leftover code from the Bad Old Days when :symbol-a and :symbol_a both got introduced into our codebase because of bugs in AWS bindings choking on -'s). Clojure, like many dynamic languages, is ultimately limited by its lack of a type system. At some point systems become challenging to refactor. To combat this, a lot of discipline about testing and builds needs to happen. I built a business around Clojure, sold it to a bank, and made lots of money and friends along the way (and just yesterday the bank announced they have decided to kill it because they don't like it, but that's got little to do with clojure and everything to do with <REDACTED>). We did stuff that VCs flat out claimed was impossible, to my face. I'm much more interested in other languages now, but that's not because I think Clojure is bad. It's because I think that my development as a software engineer requires I put Clojure down for a few years and work with other concepts.
- bhnmmhmd 9y ago
  >> ...the bank announced they have decided to kill it because they don't like it, but that's got little to do with Clojure... I think that had something to do with Clojure. The thing is, businesses usually follow best-practices and choosing a language like Clojure is certainly not a best-practice (even if developers had really good reasons to use it). For example, who maintains the code? How many Clojurists (is that a word?) can you find to work on the project? The bank would be better off by sticking to Java/Python/C#/etc. Just because you can do it, doesn't mean that you should. That's a bad habit I've seen from many developers (honestly, I understand the interest to learn more languages and use them at work, but that often results in short-sightedness when building a project).
abc_lisper 9y ago
Sorry, but don't agree with what you are saying. Clojure is very different from Perl. I would argue Clojure is more readable than Java (when written well). Immutability by default means Clojure code can be read like math equation on a board. Sure, it's tough if you don't put in the effort to learn the notation, but once that barrier is crossed, it's a very usable language. Also, this notion of code should be readable by everyone (not involved with the project) is bullshit. Learn the notation once, make use of it forever. All that is needed to do to find the grain of the problem, and cut along it (and REPL helps a lot with that). Contrarily, you can write code assuming no background - which leads to Java like code, where everything must be repeated. Perl is a write-only context-dependent (with side-effects too) language, because Larry Wall thinks computer languages should be like human languages.
cloudkj 9y ago
I've also worked with both Perl and Clojure professionally. I think Clojure code, by nature, has a higher chance at being "beautiful" or elegant, or at the very least as a close proxy, minimal. I feel that doing a lot with a little is easier in Clojure, and it makes these "beautiful" code snippets less likely to be mysterious and more likely to be understood by maintainers down the line, even sans documentation. The non-author comment is well taken though, as I find Clojure development to have a much higher thinking-to-coding ratio, so when a solution gets translated from the author's head to code, much of the complexity can be hidden due to the conciseness and lack of verbosity. I didn't really find that to be a problem in Perl, however, with the exception of perhaps the (over/ab)use of complicated regular expressions.
- vgy7ujm 9y ago
  Remove regex abuse and newb/non-programmer code structure and Perl as written by a knowledgeable person is a most beautiful language. When yourself are knowledgeable and understand the "magic" it is beautiful beyond most languages.

davedx 9y ago

> - programmers try to be clever in their code, write one giant file full of complicated specialized 'beautiful' code, forget everything they know about breaking big tasks into simple small ones. What on earth does this have to do with clojure? Programmers will do this in any language, there's nothing special about clojure here. I personally don't find LISP languages to be the most readable, but I'm fairly sure it's subjective. If you learned LISP and then went to Java, your brain would probably struggle to process all the verbosity...

shadowmint 9y ago
Rubbish. I've worked with a dozen languages, and its unquestionable that certain ones attact a high ratio of terse complicated code. Clojure is specifically renouned (and celebrated) for its low LOC counts; people go as far as saying (literally on /r/clojure) given a choice of library, pick the one with a lower LOC. That's not because people write simple pointless libs like lpad; its because the community actively encourages terse complicated code.
- yogthos 9y ago
  This is demonstrably false.
- ambulancechaser 9y ago
  I've seen this logic about choosing a library but I think you are attributing a different rationale to it. I've seen it said if you find more than one library doing what you need, go through a hierarchy of criteria to choose and choose the first one that wins; in the event of a tie, evaluate the next point 1. pick the one with the most readable, understandable architecture 2. choose the one that focuses more on what you are looking for and not a slew of different things 3. choose the one with fewer lines of code This third point is not "choose the more clever library" but more along the lines of choose the more straight forward and simple library. It's not code density you are evaluating but focus.
- specialist 9y ago
  Hearing you on FM. (Totally agree with you.) But honest question: Does where you work in the stack, meaning the level of abstraction, matter for language choice? Or vice versa? I've written a few parsers in Java. Not terrific but not terrible either. My (future) interest in Clojure is CSP. Mostly because I'm tired of wrestling with concurrency. But I'm not sure I'd want to be doing data processing with it.
magpi3 9y ago
> What on earth does this have to do with clojure? Programmers will do this in any language, there's nothing special about clojure here. I haven't programmed in Java in over ten years, but one if its "advantages" (at least back in the day) was what I called its object-oriented handcuffs, which prevented programmers from being too fancy with their code. Every file had to be a class. Every class was an object. Namespaces were clearly and rigidly defined. Setters and getters were standard for defining properties of an object. Etc. The net result was frustration for programmers who detested such rigidity, but relief for any new programmer coming into a project because Java made it very difficult to write the kind of "specialized beautiful code' that shadowmint laments. Lisps in particular allow the kind of freedom that programmers love and project managers hate. And I say that as someone who loves writing code in lisp (racket in particular).
- DigitalJack 9y ago
  I've never seen anyone put more than one namespace in a single file in clojure. I don't think the compiler would even understand that... While you can define classes in clojure, it's not the common way to do things, and so namespaces take the role of classes insofar as compartmentalizing code. It's not normal to operate on data in another namespace directly... you can do it, but it doesn't feel natural in the language. You do it through an interface (called a protocol in clojure), or through functions in that namespace. So in that sense, you are still using getters and setters for everything. But yeah, there is a lot of freedom in clojure. And that favors the writer, not the reader. Hence it can be difficult to grok somebody's code if they are more comfortable using the more advanced features of the language.
  - hellofunk 9y ago
    > namespaces take the role of classes insofar as compartmentalizing code Indeed! In fact, this is one of the sanest ways to do something resembling OO in Clojure.
- cnlwsu 9y ago
  Java still has same issue too with bored engineers. Over engineering happens. AbstractSingletonProxyFactoryBean anyone? But really strongly typed languages like java is easier than most dynamic typing language to jump into _if the project is sane_.

yogthos 9y ago

I've been working with Clojure professionally for the past 6 years, and this is completely contrary to my experience. Clojure is the first language I've used where I'm able to easily read through libraries and understand them. Clojure uses a small number of common patterns that are applied to solving a wide variety of problems. Most code in the wild that I've seen tends to actually look very similar, and follows common structure. I've contributed to many Clojure libraries, and many people have contributed to libraries I maintain. My team also maintains Clojure projects that have been in production for years, and we find them much easier to maintain than comparable Java projects we've written previously.

tigershark 9y ago
Maybe you didn't have much experience in programming before learning clojure? I never had any problems in understanding how a library worked in a language that I knew. And I have looked at the source code of quite big libraries in my life.
- yogthos 9y ago
  I've worked with Java for over a decade in the enterprise before I started using Clojure.
  - tigershark 9y ago
    And which Java libraries where so complex that you could not understand them?
    - yogthos 9y ago
      I didn't say I couldn't understand them. I was talking about the amount of time it takes to understand a typical library in a language like Java. My experience is that you would have to spend a lot of time jumping through different classes, and often have to step through things in a debugger to understand them. By contrast, I find that code in Clojure libraries to be much easier to read and understand. You literally needs orders of magnitude less code to solve same kinds of tasks, and it tends to be organized much better. I can open a namespace and read it top to bottom to see what it's doing. That's pretty much never the case with a non-trivial Java class. As a concrete example consider the Java Flyway migrations library to the Clojure migratus library that I've taken over maintaining https://github.com/flyway/flyway/tree/master/flyway-core/src/main/java/org/flywaydb/core https://github.com/flyway/flyway/tree/master/flyway-core/src... https://github.com/yogthos/migratus/tree/master/src/migratus https://github.com/yogthos/migratus/tree/master/src/migratus They both provide same core functionality, and I was able to understand the Clojure version in a few hours. It would take me much longer to understand Flyway or to be meaningfully contribute to it.

miguelrochefort 9y ago

I think that's true for most languages that are dynamically typed and let you effortlessly implement your own DSLs.

cnlwsu 9y ago

I worked on a large-ish clojure project with ~15 (people left and joined) person team for years and I haven't experienced any of your points. Sounds more like an new project with a group of people not quite familiar with the language yet, which would have the problems you listed in any language.

KirinDave 9y ago

Are we doing opinion threads now? Okay. I can do one too! I do like working with clojure. It's my favorite dynamically typed programming language by an easy margin. It's basically everything that was a good idea in Python and Ruby brought under the unifying role of a Lisp syntax, with a good Java FFI. This makes it slightly harder to learn (it's very difficult to learn Clojure if you don't at least know Java). It has a very clean syntax for the most part. Parenthesis handling does need some automation (basically everyone copied paredit) but has the nice property that refactoring is a breeze and extremely predictable. Except for rogue agents like me and a few others, very few programmers go crazy with defmacro, which makes Clojure often a lot more orderly and understandable than lots of Common Lisp code. I've run a shop with 6 clojure developers collaborating with engineers in both mobile and web space, and in many places Clojure was such a delight that cljs began to creep into the web frontends. In many cases the mobile devs contributed API endpoint handlers to the codebase and they said in general it was easy to work with (although folks sometimes had problems with more complex map types; often because of leftover code from the Bad Old Days when :symbol-a and :symbol_a both got introduced into our codebase because of bugs in AWS bindings choking on -'s). Clojure, like many dynamic languages, is ultimately limited by its lack of a type system. At some point systems become challenging to refactor. To combat this, a lot of discipline about testing and builds needs to happen. I built a business around Clojure, sold it to a bank, and made lots of money and friends along the way (and just yesterday the bank announced they have decided to kill it because they don't like it, but that's got little to do with clojure and everything to do with <REDACTED>). We did stuff that VCs flat out claimed was impossible, to my face. I'm much more interested in other languages now, but that's not because I think Clojure is bad. It's because I think that my development as a software engineer requires I put Clojure down for a few years and work with other concepts.

bhnmmhmd 9y ago
>> ...the bank announced they have decided to kill it because they don't like it, but that's got little to do with Clojure... I think that had something to do with Clojure. The thing is, businesses usually follow best-practices and choosing a language like Clojure is certainly not a best-practice (even if developers had really good reasons to use it). For example, who maintains the code? How many Clojurists (is that a word?) can you find to work on the project? The bank would be better off by sticking to Java/Python/C#/etc. Just because you can do it, doesn't mean that you should. That's a bad habit I've seen from many developers (honestly, I understand the interest to learn more languages and use them at work, but that often results in short-sightedness when building a project).

abc_lisper 9y ago

Sorry, but don't agree with what you are saying. Clojure is very different from Perl. I would argue Clojure is more readable than Java (when written well). Immutability by default means Clojure code can be read like math equation on a board. Sure, it's tough if you don't put in the effort to learn the notation, but once that barrier is crossed, it's a very usable language. Also, this notion of code should be readable by everyone (not involved with the project) is bullshit. Learn the notation once, make use of it forever. All that is needed to do to find the grain of the problem, and cut along it (and REPL helps a lot with that). Contrarily, you can write code assuming no background - which leads to Java like code, where everything must be repeated. Perl is a write-only context-dependent (with side-effects too) language, because Larry Wall thinks computer languages should be like human languages.

cloudkj 9y ago

I've also worked with both Perl and Clojure professionally. I think Clojure code, by nature, has a higher chance at being "beautiful" or elegant, or at the very least as a close proxy, minimal. I feel that doing a lot with a little is easier in Clojure, and it makes these "beautiful" code snippets less likely to be mysterious and more likely to be understood by maintainers down the line, even sans documentation. The non-author comment is well taken though, as I find Clojure development to have a much higher thinking-to-coding ratio, so when a solution gets translated from the author's head to code, much of the complexity can be hidden due to the conciseness and lack of verbosity. I didn't really find that to be a problem in Perl, however, with the exception of perhaps the (over/ab)use of complicated regular expressions.

vgy7ujm 9y ago
Remove regex abuse and newb/non-programmer code structure and Perl as written by a knowledgeable person is a most beautiful language. When yourself are knowledgeable and understand the "magic" it is beautiful beyond most languages.