Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Clojure and the technology adoption curve

blog.juxt.pro

Post reply on HN
Print view View original

11–20 of 65 posts

Re: Clojure and the technology adoption curve

#11

Post by nickbauman »

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.

Re: Clojure and the technology adoption curve

#12

Post by Grue3 »

simula67 wrote: post #4

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 b…

I think you're confusing two concepts:

- functional programming (Haskell, Scheme, Clojure) which favors recursion and stateless functions

- homoiconicity (code=data) (all Lisps)

These two concepts are completely orthogonal, and there are many Lisps such as Common Lisp, Emacs Lisp where functional programming style is not encouraged. Most of the code in these languages can hardly be called functional.

Conversely, not all functional programming languages are Lisps or homoiconic, in fact most of them aren't.

Re: Clojure and the technology adoption curve

#13

Post by S4M »

simula67 wrote: post #4

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 b…

> Many languages have eval() where data can be treated as code.

I will just address this point, which IMHO is orthogonal to your question about the benefits of functional programming. Let me give you a simple example of macro: a macro print-variable that takes a variable and prints: "$variable = $value", where $variable is the variable name and $value its corresponding value. I wrote it on my Clojure REPL, and run it that way:

    user> (def x 4)
    #'user/x
    user> (print-variable x)
    x = 4
    nil
In a language without macros, the function print-variable wouldn't have access to the string "x" once x has been defined. In a language with eval, you could do something like:

    def print-variable(variable_name):
        value = eval(variable_name)
        eval("print("+variable_name+"="+value+")")
But you would have to call that function with a string, which is not as elegant and can lead to errors as the string could be misspelled.

Now, I will show you the code of the macro in Clojure:

    (defmacro print-variable [variable]  
         `(println '~variable "=" ~variable))
What is does is take the variable you want to print, and defer its evaluation (~variable) only when you want to know what value is assigned to that variable. In the meantime, it can get the name of the variable ('~variable).

Here is what it does when I expand the macro:

    user> (macroexpand '(print-variable x))
    (clojure.core/println (quote x) "=" x)
The clojure compiler transforms the macro into the expanded code, and then injects it into the rest of the code.

Hope this helps.

Re: Clojure and the technology adoption curve

#14

Post by nickbauman »

dmichulke wrote: post #9
simula67 wrote: post #4

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 b…

Traverse a 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)…

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.

Re: Clojure and the technology adoption curve

#15

Post by markc »

simula67 wrote: post #4

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 b…

Have you read "Why Functional Programming Matters"? https://www.cs.kent.ac.uk/people/staff/dat/miranda/whyfp90.p...

Re: Clojure and the technology adoption curve

#16

Post by nkassis »

evgen wrote: post #7

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 othe…

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.

Re: Clojure and the technology adoption curve

#17

Post by mark_l_watson »

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 - it is my Java Semantic Web book.

Re: Clojure and the technology adoption curve

#18

Post by klibertp »

simula67 wrote: post #4

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 b…

As other commenters said, you're confusing hype behind Lisp with hype behind FP. They may be related, but are not the same thing.

Almost all currently used languages have some functional programming support. Many "modern" languages are functional in nature, even if it's well hidden behind syntax sugar.

Lisps, and code-as-data, is different, in that it's about compile-time meta-programming and not runtime execution model. There are non-lisp languages which offer similar capabilities, see Elixir and Nimrod for some recent examples.

Anyway, if you want to understand practical advantages of FP you should just use it in practice. It shouldn't really come as a surprise that you can't see practical benefits if you only studied a bit of theory...

Re: Clojure and the technology adoption curve

#19

Post by bad_user »

nickbauman wrote: post #11

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: yo…

> 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.

Re: Clojure and the technology adoption curve

#20

Post by klibertp »

S4M wrote: post #13
simula67 wrote: post #4

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 b…

> Many languages have eval() where data can be treated as code. I will just address this point, which IMHO is orthogonal to your question about the benefits of functional programming. Let me give you a simple example of macro: a macro print-variable that takes a variable and prints: "$variable = $value", where $variable is the variable name and $value its corresponding value. I wrote it on my Clojure REPL, and run it…

Your Python example wouldn't work. eval is still scoped lexically. You'd need to get current stack frame, get locals from the previous frame and only eval within these locals. That's what TCL `upvar` does, BTW.

Macros let you avoid this kind of problems when meta-programming (but then they bring their own problems: hygiene, for example).

Post reply on HN