6 ms·

I was quite enthusiastic about Clojure at first, I rally enjoyed experimenting with it but when the novelty fade off I lost interest because of: 1. The minimal

I was quite enthusiastic about Clojure at first, I rally enjoyed experimenting with it but when the novelty fade off I lost interest because of: 1. The minimal syntax makes it harder to read than more traditional languages. 2. It's uncomfortable to do imperative or object-oriented programming in Clojure. (Yes, many problems are easier to express in other than the functional paradigm.) 3. Using state is not a priori wrong but it's difficult in Clojure. 4. The parentheses are sometimes annoying, especially when I want to quickly test something in the REPL. Some lispers (like Paul Graham) believe in something like "macros make lisp the most productive language on Earth, at least for the top x % programmers". From my experince, this is just wishful thinking. It makes them feel special and better than others.

fogus 13y ago
> It makes them feel special and better than others. That's an incredibly cynical view. I'm sorry that Clojure was not for you -- it happens. People have different ways of thinking and the language that makes sense to you might not make sense to me. This is natural I would say and not likely reflective of general intelligence. There's no need to be bitter about it.
- RivieraKid 13y ago
  I loved playing with Clojure, especially with the overtone library. But I just couldn't see myself be more productive in Clojure than in Python. > People have different ways of thinking and the language that makes sense to you might not make sense to me. This is natural I would say and not likely reflective of general intelligence. There's no need to be bitter about it. I was mostly refering to the essay by Paul Graham that is sometimes referenced here on HN. I find some of PG's claims about lisp's productivity ridiculous and almost religious.
kaoD 13y ago
Macros are frowned-upon within the Clojure community, and for very good reasons. EDIT: okay, I got downvoted for some reason. Care to explain why? The mantra in Clojure is "don't write macros until you NEED macros" (or some alternative[1]). They make things horribly complicated and are awful to debug and make code that uses them hard to debug too... especially within a JVM environment (your code gets translated twice). [1] http://clojurefun.wordpress.com/2013/01/09/when-do-you-need-macros-in-clojure/ http://clojurefun.wordpress.com/2013/01/09/when-do-you-need-...
- RivieraKid 13y ago
  I didn't downvote you but the only significant advantage of the lisp syntax is macros. I was always under the impression that the syntax is a price for macros. If macros aren't really used, I don't see reasons for the lisp syntax.
  - kaoD 13y ago
    Macros are frowned-upon but used when necessary. To put an analogy: people would've disgusted if you used a life jacket for no good reason, but they're handy when you really need them :) I also like Lisp syntax regardless of macros, mainly because it's simple, consistent and prefix notation is really handy. The S-expr abstraction IS useful when dealing with code blocks (see https://news.ycombinator.com/item?id=5940620 https://news.ycombinator.com/item?id=5940620)
    - RivieraKid 13y ago
      Brainfuck syntax is even simpler and more consistent ;)
      - kaoD 13y ago
        If Brainfuck syntax was half as powerful as powerful as S-expressions that would be a valid comparison.
  - dktbs 13y ago
    I would argue that s-expressions are powerful for reasons other than macros, but I agree that the prefix notation and boatloads of parentheses can initially require a lot of extra effort for no apparent payoff. When I began writing clojure code (in vim) this was a constant source of frustration for me. The paredit.vim plugin [https://github.com/vim-scripts/paredit.vim https://github.com/vim-scripts/paredit.vim] made things much easier and led me to give emacs a serious try. Writing lisp in an editor with paredit is a magical feeling. It turns the onion of parentheses into a structure that you can navigate and modify without having to worry about keeping things balanced. For me, this has made the parens effectively disappear from my focus.
ww520 13y ago
The "lisp is the most productive language on Earth" claim is mainly a selective bias. People who are good with their tools are very productive. Naturally they view their own tools as superior. One of the biggest Lisp proponents (forgot his name) when joining Google found out that other good developers using other languages were just as productive.
cgag 13y ago
Clojure is the language I find easiest to read because of it's minimal syntax. I guess while I'm here, my feelings on the other points: 2) good, it's a functional language 3) Clojure's state management is excellent, discouraging mutable state is a good thing. 4) the reply highlights the matching parens when you close them, it hasn't been much of a problem for me
- RivieraKid 13y ago
  2) Fine, but functional paradigm is suitable only for a subset of real world problems, so it shrinks the usefulness of the language. 3) Sometimes mutable state is the best way to go. I'm not in the "mutable state is wrong" religion :)
  - weavejester 13y ago
    I'd argue that the functional model more accurately represents the real world than mutable objects. When you use mutable state, you're creating a model that essentially ignores time. Sometimes this is a useful omission when performance is required, but time is so integral to our Universe it's hard to remove it from a model without unforeseen consequences.
    - RivieraKid 13y ago
      Functional programming is definitely not the best approach in every situation. Sometimes it's more useful to look at the problem from imperative, object-oriented views, logic, etc. perspective. There's no paradigm that rules them all. Paradigm's are just different ways to look and decompose the problem. You need different tools in different situations. I'm not sure what you mean by saying that mutable state ignores time. Real world applications have state, you can't avoid it.
      - weavejester 13y ago
        Not all paradigms are equally useful. Mutable state pretends that change happens instantaneously, which isn't how the real world works. Let's say you observe the state of a lightbulb. You might say "The lightbulb is on," but the lightbulb could be turned off, rendering your statement technically invalid. So instead you might say, "The lightbulb is on, now", but even that's not necessarily true, as in the time it took the light to reach your eyes, the lightbulb could have been turned off. So the most accurate description you could give would be "The lightbulb was on, 10 nanoseconds ago." Systems with mutable state have no explicit time element. So "x = 1" is analogous to saying "The lightbulb is on." Systems with immutable state have to be more specific about time, so they might say "x[when t=0] = 1". Can you see how this is a more accurate representation? Mutability is really only useful under the following circumstances: 1. You need performance. 2. You have only one thread. 3. You are performing no I/O.
yogthos 13y ago
A lot of the objections your raise are very subjective. >1. The minimal syntax makes it harder to read than more traditional languages. I personally find that the minimal syntax makes it much easier to read the code. The more syntax the language has the more of it you have to keep in your head when reading code. Different language features might interact in unexpected ways, and so on. This is mental overhead that I don't need to worry about when the syntax is regular. >2. It's uncomfortable to do imperative or object-oriented programming in Clojure. (Yes, many problems are easier to express in other than the functional paradigm.) Could this stem from the fact that you're likely much more familiar with OO and you've spent years internalizing OO patterns for solving problems. I find that for majority of problems I deal with functional solutions tend to be simpler, cleaner, and more reusable. OO on the other hand is directly at odds with reuse because you marry logic and data together into classes. If you write a method and you need to use it for a different problem, you often have to jump through hoops to do it. On top of it OO encourages premature classification. If you create a class and you need to use that data in a different way later you have to translate it in some way. This is why you have things like wrapper and adapter patterns. This problem simply doesn't exist in functional code. You simply group functions into a namespace that has same organizational benefits as a class. A namespace can represent a specific domain, but you can easily pass the output of a function from one namespace to a function in a different namespace. >4. The parentheses are sometimes annoying, especially when I want to quickly test something in the REPL. There's a lot less control characters in Clojure than say in Java. If you count all your parens, curly brackets, semicolons, commas, and so a language like Java has far more noise in it. There are very few languages that have cleaner significantly syntax in my opinion. Also, if you're using a proper editor you rarely have to deal with something like balancing parens by hand. >From my experince, this is just wishful thinking. From my experience, actually having worked with Clojure production systems for a few years, now macros can be incredibly helpful in expressing problems cleanly and removing boilerplate.
- sultezdukes 13y ago
  I find that for majority of problems I deal with functional solutions tend to be simpler, cleaner, and more reusable. OO on the other hand is directly at odds with reuse because you marry logic and data together into classes. If you write a method and you need to use it for a different problem, you often have to jump through hoops to do it. On top of it OO encourages premature classification. If you create a class and you need to use that data in a different way later you have to translate it in some way. This is why you have things like wrapper and adapter patterns. This can't be emphasized enough. I never understood why so many people thought that putting methods and data together was a good idea. I think Rich Hickey in an interview with Stuart Halloway possibly once said that when you jam your methods in with your data you're essentially creating a mini-dsl that makes reuse impossible. I can't agree more.

fogus 13y ago

> It makes them feel special and better than others. That's an incredibly cynical view. I'm sorry that Clojure was not for you -- it happens. People have different ways of thinking and the language that makes sense to you might not make sense to me. This is natural I would say and not likely reflective of general intelligence. There's no need to be bitter about it.

RivieraKid 13y ago
I loved playing with Clojure, especially with the overtone library. But I just couldn't see myself be more productive in Clojure than in Python. > People have different ways of thinking and the language that makes sense to you might not make sense to me. This is natural I would say and not likely reflective of general intelligence. There's no need to be bitter about it. I was mostly refering to the essay by Paul Graham that is sometimes referenced here on HN. I find some of PG's claims about lisp's productivity ridiculous and almost religious.

kaoD 13y ago

Macros are frowned-upon within the Clojure community, and for very good reasons. EDIT: okay, I got downvoted for some reason. Care to explain why? The mantra in Clojure is "don't write macros until you NEED macros" (or some alternative[1]). They make things horribly complicated and are awful to debug and make code that uses them hard to debug too... especially within a JVM environment (your code gets translated twice). [1] http://clojurefun.wordpress.com/2013/01/09/when-do-you-need-macros-in-clojure/ http://clojurefun.wordpress.com/2013/01/09/when-do-you-need-...

RivieraKid 13y ago
I didn't downvote you but the only significant advantage of the lisp syntax is macros. I was always under the impression that the syntax is a price for macros. If macros aren't really used, I don't see reasons for the lisp syntax.
- kaoD 13y ago
  Macros are frowned-upon but used when necessary. To put an analogy: people would've disgusted if you used a life jacket for no good reason, but they're handy when you really need them :) I also like Lisp syntax regardless of macros, mainly because it's simple, consistent and prefix notation is really handy. The S-expr abstraction IS useful when dealing with code blocks (see https://news.ycombinator.com/item?id=5940620 https://news.ycombinator.com/item?id=5940620)
  - RivieraKid 13y ago
    Brainfuck syntax is even simpler and more consistent ;)
    - kaoD 13y ago
      If Brainfuck syntax was half as powerful as powerful as S-expressions that would be a valid comparison.
- dktbs 13y ago
  I would argue that s-expressions are powerful for reasons other than macros, but I agree that the prefix notation and boatloads of parentheses can initially require a lot of extra effort for no apparent payoff. When I began writing clojure code (in vim) this was a constant source of frustration for me. The paredit.vim plugin [https://github.com/vim-scripts/paredit.vim https://github.com/vim-scripts/paredit.vim] made things much easier and led me to give emacs a serious try. Writing lisp in an editor with paredit is a magical feeling. It turns the onion of parentheses into a structure that you can navigate and modify without having to worry about keeping things balanced. For me, this has made the parens effectively disappear from my focus.

ww520 13y ago

The "lisp is the most productive language on Earth" claim is mainly a selective bias. People who are good with their tools are very productive. Naturally they view their own tools as superior. One of the biggest Lisp proponents (forgot his name) when joining Google found out that other good developers using other languages were just as productive.

cgag 13y ago

Clojure is the language I find easiest to read because of it's minimal syntax. I guess while I'm here, my feelings on the other points: 2) good, it's a functional language 3) Clojure's state management is excellent, discouraging mutable state is a good thing. 4) the reply highlights the matching parens when you close them, it hasn't been much of a problem for me

RivieraKid 13y ago
2) Fine, but functional paradigm is suitable only for a subset of real world problems, so it shrinks the usefulness of the language. 3) Sometimes mutable state is the best way to go. I'm not in the "mutable state is wrong" religion :)
- weavejester 13y ago
  I'd argue that the functional model more accurately represents the real world than mutable objects. When you use mutable state, you're creating a model that essentially ignores time. Sometimes this is a useful omission when performance is required, but time is so integral to our Universe it's hard to remove it from a model without unforeseen consequences.
  - RivieraKid 13y ago
    Functional programming is definitely not the best approach in every situation. Sometimes it's more useful to look at the problem from imperative, object-oriented views, logic, etc. perspective. There's no paradigm that rules them all. Paradigm's are just different ways to look and decompose the problem. You need different tools in different situations. I'm not sure what you mean by saying that mutable state ignores time. Real world applications have state, you can't avoid it.
    - weavejester 13y ago
      Not all paradigms are equally useful. Mutable state pretends that change happens instantaneously, which isn't how the real world works. Let's say you observe the state of a lightbulb. You might say "The lightbulb is on," but the lightbulb could be turned off, rendering your statement technically invalid. So instead you might say, "The lightbulb is on, now", but even that's not necessarily true, as in the time it took the light to reach your eyes, the lightbulb could have been turned off. So the most accurate description you could give would be "The lightbulb was on, 10 nanoseconds ago." Systems with mutable state have no explicit time element. So "x = 1" is analogous to saying "The lightbulb is on." Systems with immutable state have to be more specific about time, so they might say "x[when t=0] = 1". Can you see how this is a more accurate representation? Mutability is really only useful under the following circumstances: 1. You need performance. 2. You have only one thread. 3. You are performing no I/O.

yogthos 13y ago

A lot of the objections your raise are very subjective. >1. The minimal syntax makes it harder to read than more traditional languages. I personally find that the minimal syntax makes it much easier to read the code. The more syntax the language has the more of it you have to keep in your head when reading code. Different language features might interact in unexpected ways, and so on. This is mental overhead that I don't need to worry about when the syntax is regular. >2. It's uncomfortable to do imperative or object-oriented programming in Clojure. (Yes, many problems are easier to express in other than the functional paradigm.) Could this stem from the fact that you're likely much more familiar with OO and you've spent years internalizing OO patterns for solving problems. I find that for majority of problems I deal with functional solutions tend to be simpler, cleaner, and more reusable. OO on the other hand is directly at odds with reuse because you marry logic and data together into classes. If you write a method and you need to use it for a different problem, you often have to jump through hoops to do it. On top of it OO encourages premature classification. If you create a class and you need to use that data in a different way later you have to translate it in some way. This is why you have things like wrapper and adapter patterns. This problem simply doesn't exist in functional code. You simply group functions into a namespace that has same organizational benefits as a class. A namespace can represent a specific domain, but you can easily pass the output of a function from one namespace to a function in a different namespace. >4. The parentheses are sometimes annoying, especially when I want to quickly test something in the REPL. There's a lot less control characters in Clojure than say in Java. If you count all your parens, curly brackets, semicolons, commas, and so a language like Java has far more noise in it. There are very few languages that have cleaner significantly syntax in my opinion. Also, if you're using a proper editor you rarely have to deal with something like balancing parens by hand. >From my experince, this is just wishful thinking. From my experience, actually having worked with Clojure production systems for a few years, now macros can be incredibly helpful in expressing problems cleanly and removing boilerplate.

sultezdukes 13y ago
I find that for majority of problems I deal with functional solutions tend to be simpler, cleaner, and more reusable. OO on the other hand is directly at odds with reuse because you marry logic and data together into classes. If you write a method and you need to use it for a different problem, you often have to jump through hoops to do it. On top of it OO encourages premature classification. If you create a class and you need to use that data in a different way later you have to translate it in some way. This is why you have things like wrapper and adapter patterns. This can't be emphasized enough. I never understood why so many people thought that putting methods and data together was a good idea. I think Rich Hickey in an interview with Stuart Halloway possibly once said that when you jam your methods in with your data you're essentially creating a mini-dsl that makes reuse impossible. I can't agree more.