11 ms·

Clojure is currently the sexy lisp du jour. When I first learned Clojure, to me it was the first time programming truly clicked with me. That first time I ever

Clojure is currently the sexy lisp du jour. When I first learned Clojure, to me it was the first time programming truly clicked with me. That first time I ever felt that spark of "oh my god, so that's what programming can be like!"

weavie 10y ago
What was it about Clojure that made it click?
- grabcocque 10y ago
  Lisp's propensity for terse, expressive code. Persistent data structures. A novel approach to concurrency by mainstream language standards.
- madmax96 10y ago
  I like Clojure because it's a Lisp 1 and the novelty of having MVCC implemented in my language. With respect to the Lisp 1/2 debate, I hate how this: (defun foo (g y) (g y)) (foo #'- 10) ; error Is an error in Common Lisp. Instead, you have to: (defun foo (g y) (funcall g y)) (foo #'- 10) ; works That's just so inelegant IMO. Scheme does the "right" thing and lets you do: (define (foo g y) (g y)) (foo - 10) ; works but lacks a de facto build tool and package management system. (I also really like Scheme's macro system, but not everyone agrees). Clojure solves the build tool and package management system, does the "right" thing with higher order functions, and offers seamless Java(Script) interop, which is why it has enjoyed more "mainstream" success than other Lisps.
  - bitwize 10y ago
    R7RS has a standard package system. There seems to be some consensus on using Marc Feeley's Snow for distribution of R7RS packages. If you're running Racket, there's also PLaneT.
  - lispm 10y ago
    But: (define (foo lst) (list (map + lst) (map - lst))) WTF? Or: (define (foo + - lst) (+ (reduce + lst) (reduce - lst))) (foo - +)
  - zeveb 10y ago
    > I like Clojure because it's a Lisp 1 That's one of the things I hate about Clojure. I _like_ being able to do this: (defun foo (list) (list "length" (length list)))
    - madmax96 10y ago
      That is convenient, but keep in mind that namespaces solve this problem: (defn foo [list] (clojure.core/list "length" (count list))) Or, in the case of CL, we could do this: (defun foo (list) (cl:list "length" (length list))) I'd argue that you should do this anyway to clarify what you mean by "list" when you shadow a common name like that.
      - junke 10y ago
        > I'd argue that you should do this anyway to clarify what you mean by "list" when you shadow a common name like that. Absolutely not, don't encourage people to do this in CL. Clojure is Clojure, you have to do this, or if you prefer you can use use (refer ... :rename {...}) to reference external names with different local names. CL packages have their own semantic w.r.t. importing and shadowing symbols. Without context, if I read your example in CL, I am starting to ask myself if I am in a package where you defined a "list" function, because this is the unique case that requires me to explicitely qualify cl:list. If there was any confusion in the first place, I could easily select the symbol and ask Lisp what it is and whose package it belongs to.
        madmax96 10y ago
        Readability matters. Specifying the namespace of `list` communicates one and only one idea: I am referring to a particular binding of `list`. By leaving out the namespace qualifier when you shadow a symbol you can only add to the cognitive load necessary to understand the meaning of the code. A languages' only purpose to communicate meaning, whether that be to a machine or a person. > if I read your example in CL, I am starting to ask myself > if I am in a package where you defined a "list" function Anytime you use a shadowed symbol, qualify it with a namespace. Just because you can do something does not mean you should. It won't hurt the code and it makes the meaning perfectly clear.
qwertyuiop924 10y ago
Clojure never really caught on with me. It's not the ideas, so much as the really complex ecosystem that the JVM mandates. Which is why I tend to avoid the JVM like the plague. Now Scheme on the other hand...
- soberhoff 10y ago
  Familiarity lessens fear. I've been coming to Clojure from Java so to me the JVM and its standard libraries are a feature not a drawback.
  - qwertyuiop924 10y ago
    The standard library is a benefit, the complexity requirements are the drawback: In java, and the JVM, nothing, no matter how simple, is ever simple.
pjmlp 10y ago
I really enjoy playing with it, and every now and then, do my 4Clojure challenges. But the only scenario I could eventually use it for, portable code between Android and UWP isn't really covered by it. ClojureCLR is behind Clojure and doesn't run on .NET Core. Clojure for Android still has lots of performance problems and the project hasn't been updated since mid-2015.
- JBiserkov 10y ago
  Take a look at ClojureScript (if you haven't already). It compiles to a subset of JavaScript which is then compiled and optimized with the Google Closure compiler (the one used for GMail and GMaps) to produce even better JavaScript. You can target UWP and Android via React Native + ClojureScript react wrapper(s). A interesting fact is that the wrappers are up to twice faster than the normal react due to immutability in the language which enables very efficient implementations of shouldComponentUpdate. https://blogs.windows.com/buildingapps/2016/04/13/react-native-on-the-universal-windows-platform/ https://blogs.windows.com/buildingapps/2016/04/13/react-nati...
  - pjmlp 10y ago
    I don't want to use JavaScript based tools. Right now I am using C++14.
    - mcguire 10y ago
      Isn't that roughly akin to saying, "I don't want to use the combination hammer/screwdriver; I prefer to bang the threaded nails in with flint flakes that I have knapped myself and that are sharp on every side?"
      - pjmlp 10y ago
        No, C++ is a first class language in iOS, Android and WP SDKs with corresponding tooling, debuggers and IDE support. JavaScript implies another layer to debug and even more complexity writing FFI code.
anti_dang 10y ago
Clojure code is uglier to me than most modern Perl code. Mixing brackets in a lisp should be criminalized.

weavie 10y ago

What was it about Clojure that made it click?

grabcocque 10y ago
Lisp's propensity for terse, expressive code. Persistent data structures. A novel approach to concurrency by mainstream language standards.
madmax96 10y ago
I like Clojure because it's a Lisp 1 and the novelty of having MVCC implemented in my language. With respect to the Lisp 1/2 debate, I hate how this: (defun foo (g y) (g y)) (foo #'- 10) ; error Is an error in Common Lisp. Instead, you have to: (defun foo (g y) (funcall g y)) (foo #'- 10) ; works That's just so inelegant IMO. Scheme does the "right" thing and lets you do: (define (foo g y) (g y)) (foo - 10) ; works but lacks a de facto build tool and package management system. (I also really like Scheme's macro system, but not everyone agrees). Clojure solves the build tool and package management system, does the "right" thing with higher order functions, and offers seamless Java(Script) interop, which is why it has enjoyed more "mainstream" success than other Lisps.
- bitwize 10y ago
  R7RS has a standard package system. There seems to be some consensus on using Marc Feeley's Snow for distribution of R7RS packages. If you're running Racket, there's also PLaneT.
- lispm 10y ago
  But: (define (foo lst) (list (map + lst) (map - lst))) WTF? Or: (define (foo + - lst) (+ (reduce + lst) (reduce - lst))) (foo - +)
- zeveb 10y ago
  > I like Clojure because it's a Lisp 1 That's one of the things I hate about Clojure. I _like_ being able to do this: (defun foo (list) (list "length" (length list)))
  - madmax96 10y ago
    That is convenient, but keep in mind that namespaces solve this problem: (defn foo [list] (clojure.core/list "length" (count list))) Or, in the case of CL, we could do this: (defun foo (list) (cl:list "length" (length list))) I'd argue that you should do this anyway to clarify what you mean by "list" when you shadow a common name like that.
    - junke 10y ago
      > I'd argue that you should do this anyway to clarify what you mean by "list" when you shadow a common name like that. Absolutely not, don't encourage people to do this in CL. Clojure is Clojure, you have to do this, or if you prefer you can use use (refer ... :rename {...}) to reference external names with different local names. CL packages have their own semantic w.r.t. importing and shadowing symbols. Without context, if I read your example in CL, I am starting to ask myself if I am in a package where you defined a "list" function, because this is the unique case that requires me to explicitely qualify cl:list. If there was any confusion in the first place, I could easily select the symbol and ask Lisp what it is and whose package it belongs to.
      - madmax96 10y ago
        Readability matters. Specifying the namespace of `list` communicates one and only one idea: I am referring to a particular binding of `list`. By leaving out the namespace qualifier when you shadow a symbol you can only add to the cognitive load necessary to understand the meaning of the code. A languages' only purpose to communicate meaning, whether that be to a machine or a person. > if I read your example in CL, I am starting to ask myself > if I am in a package where you defined a "list" function Anytime you use a shadowed symbol, qualify it with a namespace. Just because you can do something does not mean you should. It won't hurt the code and it makes the meaning perfectly clear.

qwertyuiop924 10y ago

Clojure never really caught on with me. It's not the ideas, so much as the really complex ecosystem that the JVM mandates. Which is why I tend to avoid the JVM like the plague. Now Scheme on the other hand...

soberhoff 10y ago
Familiarity lessens fear. I've been coming to Clojure from Java so to me the JVM and its standard libraries are a feature not a drawback.
- qwertyuiop924 10y ago
  The standard library is a benefit, the complexity requirements are the drawback: In java, and the JVM, nothing, no matter how simple, is ever simple.

pjmlp 10y ago

I really enjoy playing with it, and every now and then, do my 4Clojure challenges. But the only scenario I could eventually use it for, portable code between Android and UWP isn't really covered by it. ClojureCLR is behind Clojure and doesn't run on .NET Core. Clojure for Android still has lots of performance problems and the project hasn't been updated since mid-2015.

JBiserkov 10y ago
Take a look at ClojureScript (if you haven't already). It compiles to a subset of JavaScript which is then compiled and optimized with the Google Closure compiler (the one used for GMail and GMaps) to produce even better JavaScript. You can target UWP and Android via React Native + ClojureScript react wrapper(s). A interesting fact is that the wrappers are up to twice faster than the normal react due to immutability in the language which enables very efficient implementations of shouldComponentUpdate. https://blogs.windows.com/buildingapps/2016/04/13/react-native-on-the-universal-windows-platform/ https://blogs.windows.com/buildingapps/2016/04/13/react-nati...
- pjmlp 10y ago
  I don't want to use JavaScript based tools. Right now I am using C++14.
  - mcguire 10y ago
    Isn't that roughly akin to saying, "I don't want to use the combination hammer/screwdriver; I prefer to bang the threaded nails in with flint flakes that I have knapped myself and that are sharp on every side?"
    - pjmlp 10y ago
      No, C++ is a first class language in iOS, Android and WP SDKs with corresponding tooling, debuggers and IDE support. JavaScript implies another layer to debug and even more complexity writing FFI code.

anti_dang 10y ago

Clojure code is uglier to me than most modern Perl code. Mixing brackets in a lisp should be criminalized.