7 ms·

Clojure and the technology adoption curve

98 points by Ernestas 11y ago

PaulHoule 11y ago
In my mind you are not leaving OO behind when you get into Clojure, but the big conceptual challenges revolve around doing things in an immutable way. It is obvious how to do some things and not to do others.
- Ernestas 11y ago
  Reading the books such as "The Joy of Clojure" and "Clojure Applied" helped me to leave the OO behind when getting into Clojure.
  - thenipper 11y ago
    I've been going through "Clojure for the Brave and True". It's been great so far, it does a good job of explaining out functional programming. Though I already had one foot in that realm with playing around with Racket and learning Scheme in college.
- VLM 11y ago
  As an example there's an essay at http://www.lispcast.com/solid-principles-in-clojure http://www.lispcast.com/solid-principles-in-clojure which elaborates on SOLID OO design in Clojure and provides some code examples. For example there's a pretty clear example of the right way to apply SRP to a functional paradigm. I'd interpret it as you need SOLID to do successful OO (required but not sufficient), but using as much SOLID as reasonably possible under any paradigm also happens to result in good/better software. In that way there can be a lot of confusion about what is OO and what is merely usually found nearby OO but isn't OO specific.
  - juliangamble 11y ago
    (Disclaimer: I'm a huge fan of Eric Normand, and had a couple of dinners with him at Clojure Conj last year.) I think the value of SOLID is that it gives you tools for thinking about your code. I think there is lots of room for a critique and even a debunking of SOLID. Indeed, Kevin Henney has done just that. http://yowconference.com.au/slides/yow2013/Henney-SOLIDDeconstruction.pdf http://yowconference.com.au/slides/yow2013/Henney-SOLIDDecon...
- pjmlp 11y ago
  One cannot leave OO behind in a language that by definition, supports OO via protocols and multi-methods.
  - ddellacosta 11y ago
    How are protocols and multi-methods OO?
    - emidln 11y ago
      multi-methods at least are isa?-based. This implies that they obey ad-hoc hierarchies created via derive as well as traditional java inheritance hierarchies. protocols are little more than open-ended interfaces (i.e. I can extend them at run-time to my things and to other things).
      - KingMob 11y ago
        Just a slight addendum: Clojure multimethods can resolve to a concrete method implementation based on any function of their parameters. So, in addition to single dispatch based on class (a la Java), you could also dispatch based on the classes of multiple parameters or on the value of the field 3 objects deep.
        emidln 11y ago
        kinda. The dispatch is on a single value and isa? isn't mapped over that single value if it happens to be a collection. This means you can dispatch on multiple concrete values in a collection or the isa? hierarchies of a single thing, but you don't get to isa? everything in the collection (unless you do it yourself over some limited set of things you care about; like you said, method dispatch is over ANY function). This means that you can do something like (defmulti cares-about-a-and-c "multimethod that cares about the first and third args" (fn [a b c] [a c])) (defmethod cares-about-a-and-c [:alpha :gamma] [a b c] (prn "got :alpha and :gamma")) (defmethod cares-about-a-and-c [1 3] [a b c] (prn "got 1 and 3")) but the following won't really work how you want it to: (defmethod cares-about-a-and-c [String String] [a b c] (prn "Got two things that match (isa? String)")) (cares-about-a-and-c "foo" nil "bar") ;; doesn't call our last method You could, however, define something based on class and not isa? via your dispatch function: (defmulti cares-about-class-of-a-and-c "" (fn [a b c] (mapv class [a c]))) (defmethod cares-about-class-of-a-and-c [String String] [a _ c] (println "Got the strings: " a " and " c))
simula67 11y ago
I am having a lot of trouble trying to understand the hype behind functional programming. I have read McCarthy's paper on LISP, completed Odersky's course on Scala etc. No revelation so far ( yes, maybe I am stupid, but I won't admit it ). Is it only useful for study as a model that inspired modern programming languages ? For example : "obvious power of code becoming data." Many languages have eval() where data can be treated as code.
- escherize 11y ago
  One main goal of functional programming is writing less error prone code. When mapping a function over a sequence there's no way to get an off by one error, or any other bug associated with typical for loop. Not a lot of aspects of functional programming are tied to the code is data idea (formally called homoiconicity). However when writing Clojure, the user is actually inputting Clojure data structures. Something I've noticed is structural navigation inside the editor has beneficial. I can edit Clojure code so much faster than any algol-family (C-like) language I've used. And while I find it important to spend more time thinking than typing, it's easier for me to stay in flow when the code is so malleable.
- dmichulke 11y ago
  Traverse a <String, Int> hashmap, remove all strings with an even key string size and sort it by the last character in the string, then add the string size to the integer (here you have a list of integers) and sum the product of the numbers at index 0 and n-1, 1 and n-2, ... Compare the the code size in Java and Clojure. If that is not enough, do the same thing but start with java objects (and their clojure equivalent: a hashmap) for some given object/map property. EDIT: And if that is not enough, use as property of the object a string, defined only during run-time by a user input.
  - nickbauman 11y ago
    Exactly this. The amount of code to do things is shockingly small. When I was first learning Clojure I stumbled on a "lack of good documentation" in third party libraries. I'd google around for something that solved the problem I was trying to solve so I wouldn't reinvent the wheel. I'd find, say, a github repo that had a couple of sentences in its README that purported to solve my problem and then nothing else. What the hell, I thought; why no decent doc? Then I realized: the solution was implemented in 40 lines of Clojure. Reading the source was the fastest way to figure it out. It still happens to me. Every time it does, I have this warm feeling of investing in something of great value.
evgen 11y ago
Probably worth noting that a lot of the companies with an interest in Clojure cited as Early Majority are simply non-Clojure companies that picked up an Early Adopter startup as an acquisition and need to continue development and does not necessarily represent greenfield Clojure development at that company (I know this for a fact regarding one of the companies cited on the list, suspect the same for a few of the others.) While Clojure foundered a bit after its start in the race to become Java.next I think that what has ended up saving it, or at least given it new life that it really needed, is a particular combination that is not even mentioned anywhere in the article: Clojurescript and React wrappers like Om and Reagent. I know more people considering Clojure(script) as a path to a combined web app and mobile app (via React-native) than I do people looking at Clojure to power the back-end.
- nkassis 11y ago
  I think (and have seen from personal experience) that some of those groups are more just individual teams that have adopted clojure on their own but are relatively niche and isolated from the larger companies. I don't think it's mostly made up of acquisitions. Teams in some large tech companies are free to choose the language that best fits their needs and so you can find pockets of clojure, go, etc ... around. Also the ones I've had personal experience with were all backend teams. I think clojurescript is still lagging backend clojure in tech companies but all I have is anecdotal evidence.
- pjmlp 11y ago
  Here in Germany I only see Clojure ads in relation to big data startups[0]. Very seldom do classic companies ask for anything other than JavaScript on the browser or Java on the JVM. [0] Same applies to other FP languages on the JVM.
  - talloaktrees 11y ago
    It's same same in the US outside of SF and NYC
nickbauman 11y ago
It is a myth that you have to be a genius programmer to pick up Lisp dialects like Clojure. I think it's the opposite: the cognitive load of more complex languages that are "easier to learn" than Clojure (like Scala or even Java itself, for instance), a complexity I consider accidental and not essential to whatever problem you are solving, is more difficult. The hard part of Clojure really boils down to one thing: you do not have an assignment operator. If you realize you must now program without that, how would you do that? Answering that question in concrete cases is your only real problem. Other things, like the parens, well, you stop even noticing them after your first few hours. When you first start, just move the paren one word to the left from where you're used to and you're good to go. The syntax after that is so simple, you will find it liberating.
- bad_user 11y ago
  > you do not have an assignment operator Except that you do have assignment. Even more so, every def is a Var, defn definitions themselves being vars that can be redefined, in true Lisp tradition and you also have atoms and you can use mutable arrays or any mutable collections you like, with people doing plenty of that. The emphasis on its simplicity is also misleading. For example Clojure developers pride themselves on how Clojure does not do OOP, except when it does of course, plenty of examples being in Clojure's standard library, starting from really basic things such as ISeq. And this is actually confusing beginners that read introductions such as yours and I think it's doing Clojure a slight disservice, especially because this isn't defining what Clojure is or explaining why it is awesome. I do agree with the sentiment. Just the other day I was trying to understand a piece of C# code that was written in a classic style, mutating variables and arrays in place to calculate something that could have been described as pure and very understandable expressions. And oh my god, it's as if I forgot how that was and I hated every minute of it.
  - nickbauman 11y ago
    Not in any way that matters to people who use the assignment operator in other languages. Of course what you're saying is correct but pointing this out to beginners is like explaining that the steering wheel of the car can be removed and used as a lethal weapon. It's pedantic and misleading. I don't say and I don't see others saying "Clojure does not do OOP". If you notice this feel free to point this out; even ask me for support. Our community should be exemplary of keeping these things consistent. We all need to do our part.
mark_l_watson 11y ago
A long while ago I wrote a Java book [1] (my usual cookbook style) and decided to also support Scala and Clojure. It was so very much easier writing Clojure wrappers than Scala wrappers. Java and Clojure mix very well in projects: set up a separate Java source path and let lein build everything. [1] you can grab a free copy at http://markwatson.com/opencontent_data/book_java.pdf http://markwatson.com/opencontent_data/book_java.pdf - it is my Java Semantic Web book.
msluyter 11y ago
Let's say I'm sold on Clojure (I am; I think it's awesome) and I want to convince my boss to convert a crufty Java 7 enterprise app to a better alternative. What is the argument for Clojure compared to, say, Kotlin? How difficult is a complete conversion to Clojure compared to other JVM alternatives. My guess, in terms of ease of transition: Java 8 > Kotlin > Scala > Clojure That's just my impression, especially if you're risk averse and want to make improvements as incrementally as possible. But I could be wrong. Anyone have a good counterexample?
- astine 11y ago
  Clojure's strongest selling point as compared to other JVM languages is probably its concurrency story. If your enterprise app is of any sort of size, you've probably run into concurrency related bugs. Another strong advantage is the development lifecycle. It's much tighter thanks to the live coding built right in. This should make it much faster to catch bugs or feel out new code. You can also use this to implement zero-downtime deploys and patching.
deleted 11y ago
[deleted]

98 points by Ernestas 11y ago

In my mind you are not leaving OO behind when you get into Clojure, but the big conceptual challenges revolve around doing things in an immutable way. It is obvious how to do some things and not to do others.

Ernestas 11y ago
Reading the books such as "The Joy of Clojure" and "Clojure Applied" helped me to leave the OO behind when getting into Clojure.
- thenipper 11y ago
  I've been going through "Clojure for the Brave and True". It's been great so far, it does a good job of explaining out functional programming. Though I already had one foot in that realm with playing around with Racket and learning Scheme in college.
VLM 11y ago
As an example there's an essay at http://www.lispcast.com/solid-principles-in-clojure http://www.lispcast.com/solid-principles-in-clojure which elaborates on SOLID OO design in Clojure and provides some code examples. For example there's a pretty clear example of the right way to apply SRP to a functional paradigm. I'd interpret it as you need SOLID to do successful OO (required but not sufficient), but using as much SOLID as reasonably possible under any paradigm also happens to result in good/better software. In that way there can be a lot of confusion about what is OO and what is merely usually found nearby OO but isn't OO specific.
- juliangamble 11y ago
  (Disclaimer: I'm a huge fan of Eric Normand, and had a couple of dinners with him at Clojure Conj last year.) I think the value of SOLID is that it gives you tools for thinking about your code. I think there is lots of room for a critique and even a debunking of SOLID. Indeed, Kevin Henney has done just that. http://yowconference.com.au/slides/yow2013/Henney-SOLIDDeconstruction.pdf http://yowconference.com.au/slides/yow2013/Henney-SOLIDDecon...
pjmlp 11y ago
One cannot leave OO behind in a language that by definition, supports OO via protocols and multi-methods.
- ddellacosta 11y ago
  How are protocols and multi-methods OO?
  - emidln 11y ago
    multi-methods at least are isa?-based. This implies that they obey ad-hoc hierarchies created via derive as well as traditional java inheritance hierarchies. protocols are little more than open-ended interfaces (i.e. I can extend them at run-time to my things and to other things).
    - KingMob 11y ago
      Just a slight addendum: Clojure multimethods can resolve to a concrete method implementation based on any function of their parameters. So, in addition to single dispatch based on class (a la Java), you could also dispatch based on the classes of multiple parameters or on the value of the field 3 objects deep.
      - emidln 11y ago
        kinda. The dispatch is on a single value and isa? isn't mapped over that single value if it happens to be a collection. This means you can dispatch on multiple concrete values in a collection or the isa? hierarchies of a single thing, but you don't get to isa? everything in the collection (unless you do it yourself over some limited set of things you care about; like you said, method dispatch is over ANY function). This means that you can do something like (defmulti cares-about-a-and-c "multimethod that cares about the first and third args" (fn [a b c] [a c])) (defmethod cares-about-a-and-c [:alpha :gamma] [a b c] (prn "got :alpha and :gamma")) (defmethod cares-about-a-and-c [1 3] [a b c] (prn "got 1 and 3")) but the following won't really work how you want it to: (defmethod cares-about-a-and-c [String String] [a b c] (prn "Got two things that match (isa? String)")) (cares-about-a-and-c "foo" nil "bar") ;; doesn't call our last method You could, however, define something based on class and not isa? via your dispatch function: (defmulti cares-about-class-of-a-and-c "" (fn [a b c] (mapv class [a c]))) (defmethod cares-about-class-of-a-and-c [String String] [a _ c] (println "Got the strings: " a " and " c))

simula67 11y ago

I am having a lot of trouble trying to understand the hype behind functional programming. I have read McCarthy's paper on LISP, completed Odersky's course on Scala etc. No revelation so far ( yes, maybe I am stupid, but I won't admit it ). Is it only useful for study as a model that inspired modern programming languages ? For example : "obvious power of code becoming data." Many languages have eval() where data can be treated as code.

escherize 11y ago
One main goal of functional programming is writing less error prone code. When mapping a function over a sequence there's no way to get an off by one error, or any other bug associated with typical for loop. Not a lot of aspects of functional programming are tied to the code is data idea (formally called homoiconicity). However when writing Clojure, the user is actually inputting Clojure data structures. Something I've noticed is structural navigation inside the editor has beneficial. I can edit Clojure code so much faster than any algol-family (C-like) language I've used. And while I find it important to spend more time thinking than typing, it's easier for me to stay in flow when the code is so malleable.
dmichulke 11y ago
Traverse a <String, Int> hashmap, remove all strings with an even key string size and sort it by the last character in the string, then add the string size to the integer (here you have a list of integers) and sum the product of the numbers at index 0 and n-1, 1 and n-2, ... Compare the the code size in Java and Clojure. If that is not enough, do the same thing but start with java objects (and their clojure equivalent: a hashmap) for some given object/map property. EDIT: And if that is not enough, use as property of the object a string, defined only during run-time by a user input.
- nickbauman 11y ago
  Exactly this. The amount of code to do things is shockingly small. When I was first learning Clojure I stumbled on a "lack of good documentation" in third party libraries. I'd google around for something that solved the problem I was trying to solve so I wouldn't reinvent the wheel. I'd find, say, a github repo that had a couple of sentences in its README that purported to solve my problem and then nothing else. What the hell, I thought; why no decent doc? Then I realized: the solution was implemented in 40 lines of Clojure. Reading the source was the fastest way to figure it out. It still happens to me. Every time it does, I have this warm feeling of investing in something of great value.

evgen 11y ago

Probably worth noting that a lot of the companies with an interest in Clojure cited as Early Majority are simply non-Clojure companies that picked up an Early Adopter startup as an acquisition and need to continue development and does not necessarily represent greenfield Clojure development at that company (I know this for a fact regarding one of the companies cited on the list, suspect the same for a few of the others.) While Clojure foundered a bit after its start in the race to become Java.next I think that what has ended up saving it, or at least given it new life that it really needed, is a particular combination that is not even mentioned anywhere in the article: Clojurescript and React wrappers like Om and Reagent. I know more people considering Clojure(script) as a path to a combined web app and mobile app (via React-native) than I do people looking at Clojure to power the back-end.

nkassis 11y ago
I think (and have seen from personal experience) that some of those groups are more just individual teams that have adopted clojure on their own but are relatively niche and isolated from the larger companies. I don't think it's mostly made up of acquisitions. Teams in some large tech companies are free to choose the language that best fits their needs and so you can find pockets of clojure, go, etc ... around. Also the ones I've had personal experience with were all backend teams. I think clojurescript is still lagging backend clojure in tech companies but all I have is anecdotal evidence.
pjmlp 11y ago
Here in Germany I only see Clojure ads in relation to big data startups[0]. Very seldom do classic companies ask for anything other than JavaScript on the browser or Java on the JVM. [0] Same applies to other FP languages on the JVM.
- talloaktrees 11y ago
  It's same same in the US outside of SF and NYC

nickbauman 11y ago

It is a myth that you have to be a genius programmer to pick up Lisp dialects like Clojure. I think it's the opposite: the cognitive load of more complex languages that are "easier to learn" than Clojure (like Scala or even Java itself, for instance), a complexity I consider accidental and not essential to whatever problem you are solving, is more difficult. The hard part of Clojure really boils down to one thing: you do not have an assignment operator. If you realize you must now program without that, how would you do that? Answering that question in concrete cases is your only real problem. Other things, like the parens, well, you stop even noticing them after your first few hours. When you first start, just move the paren one word to the left from where you're used to and you're good to go. The syntax after that is so simple, you will find it liberating.

bad_user 11y ago
> you do not have an assignment operator Except that you do have assignment. Even more so, every def is a Var, defn definitions themselves being vars that can be redefined, in true Lisp tradition and you also have atoms and you can use mutable arrays or any mutable collections you like, with people doing plenty of that. The emphasis on its simplicity is also misleading. For example Clojure developers pride themselves on how Clojure does not do OOP, except when it does of course, plenty of examples being in Clojure's standard library, starting from really basic things such as ISeq. And this is actually confusing beginners that read introductions such as yours and I think it's doing Clojure a slight disservice, especially because this isn't defining what Clojure is or explaining why it is awesome. I do agree with the sentiment. Just the other day I was trying to understand a piece of C# code that was written in a classic style, mutating variables and arrays in place to calculate something that could have been described as pure and very understandable expressions. And oh my god, it's as if I forgot how that was and I hated every minute of it.
- nickbauman 11y ago
  Not in any way that matters to people who use the assignment operator in other languages. Of course what you're saying is correct but pointing this out to beginners is like explaining that the steering wheel of the car can be removed and used as a lethal weapon. It's pedantic and misleading. I don't say and I don't see others saying "Clojure does not do OOP". If you notice this feel free to point this out; even ask me for support. Our community should be exemplary of keeping these things consistent. We all need to do our part.

mark_l_watson 11y ago

A long while ago I wrote a Java book [1] (my usual cookbook style) and decided to also support Scala and Clojure. It was so very much easier writing Clojure wrappers than Scala wrappers. Java and Clojure mix very well in projects: set up a separate Java source path and let lein build everything. [1] you can grab a free copy at http://markwatson.com/opencontent_data/book_java.pdf http://markwatson.com/opencontent_data/book_java.pdf - it is my Java Semantic Web book.

msluyter 11y ago

Let's say I'm sold on Clojure (I am; I think it's awesome) and I want to convince my boss to convert a crufty Java 7 enterprise app to a better alternative. What is the argument for Clojure compared to, say, Kotlin? How difficult is a complete conversion to Clojure compared to other JVM alternatives. My guess, in terms of ease of transition: Java 8 > Kotlin > Scala > Clojure That's just my impression, especially if you're risk averse and want to make improvements as incrementally as possible. But I could be wrong. Anyone have a good counterexample?

astine 11y ago
Clojure's strongest selling point as compared to other JVM languages is probably its concurrency story. If your enterprise app is of any sort of size, you've probably run into concurrency related bugs. Another strong advantage is the development lifecycle. It's much tighter thanks to the live coding built right in. This should make it much faster to catch bugs or feel out new code. You can also use this to implement zero-downtime deploys and patching.

deleted 11y ago

[deleted]