Clojure and the technology adoption curve

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

The tradeoff for anything "simple" is that you are then left to pick up the pieces (with libraries or your own code) if you want to do anything "complex".

As an example: C doesn't have the complication to the language of having "built in" types for hashes or lists. This makes the language easier, since you don't have to learn the extra syntax and grow the mental model of how they were implemented. On the other hand, if you need a hash or list - you need to create your own (or adopt someone else's implementation via a library).

C is a simple and powerful language, but there's so much you have to do yourself, that it's easy to get something wrong.

Clojure (and lisps in general) hide their complexity in macros. This level of abstraction can be great, until you have to dive into the macro and see exactly how it's manipulating your code. Or write your own and troubleshoot the resulting dynamic code.

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

People should learn first through Racket and its awesome DrRacket. I wish I first learned programming in Racket and not Basic and Assembly.

My kids will go through Racket in a few years.

Very simple way to put it. Probably why people argue that it's a question of nurture. When introduce to the bliss(at first) of mutable memory it a bit complicated to ask people to twist their brain, until late down the road. Now taught without this unfair comparison point, people will quickly find the "mutation free" easy to deal with with proper basic principles.

> The hard part of Clojure really boils down to one thing: you do not have an assignment operator.

Nah. You have `let` which is exactly that.

I'm not familiar with the myth of having to be a genius to learn clojure. Not having an assignment operator is the same problem anyone would have in trying to move from an imperative to a functional language.

You can be productive in clojure, I think, without being extremely fluent. But Clojure does tend to some perl-esque terseness. Browsing down this page (http://clojure.org/reader) everything is fine until you start getting into macro characters, and then the dispatch macro, and then the regex dispatch macro. I think you could write perfectly fine clojure code without knowing the details of all of these, but it can be frustrating to not know if your code is idiomatic clojure or merely badly translated from another language.

For myself, there are a couple things that make Clojure difficult. I believe they all stem in part from the language being simple.

First, there seems to be at least two ways to do things: the verbose way and the succinct way. This creates more things beginners have to memorize.

Second, so many :keywords. Presumably some function/macro needed to be made more flexible and/or more succinct for certain circumstances so they add magical (from this beginner's POV) :keywords to make it translate their arguments in different ways. Clojure functions seem more like Unix commands rather than functions in most programming languages I'm used to.

And finally, an imperative programmer's tendency to create long functions. As a beginner my brain starts to shutoff once I encounter a Clojure function that reaches 5-10 lines. But 5-10 lines in an imperative language is pretty short.

Clojure is a simpler language, but because of that it doesn't benefit from the syntax highlighting more complex languages may have. This makes it more difficult (for me) to parse similarly lengthed Clojure programs. Of course similarly lengthed Clojure programs can do more than an imperative language, so it should probably be split into more functions, which would make it easier for me, as a beginner, to read.

I feel like people tout the succinctness of Clojure as a benefit because you can write shorter programs. I've come to think it's a benefit because you can section off more of your code into descriptive functions without exploding your code length, which make the program easier to read. When I start to use that succinctness to write less code it quickly becomes unreadable if I revisit it in a month.

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.

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.

Reading the books such as "The Joy of Clojure" and "Clojure Applied" helped me to leave the OO behind when getting into Clojure.

As an example there's an essay at

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.

One cannot leave OO behind in a language that by definition, supports OO via protocols and multi-methods.

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.

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.

I had many revelations while reading and doing the exercises of the SICP book.

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.

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

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

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

A dense functional language like Clojure or Haskell has about a 10x reduction in lines of code once you get rid of all the OO boilerplate and replace it with composable, higher-order functions. I used to write c++ for a living and when I switched to Clojure, my days are still full of the same level of development work, but the amount of code that I actually write is dramatically less. In a functional language, a lot more goes into the thought process of how to construct algorithms rather than in meeting the demands of the OO environment you work in. In some languages you have no choice but to make classes for even the tiniest of tasks, which is a limiting requirement to put in the hands of someone trying to creatively solve a problem from any angle without preconceived design patterns influencing the approach. FP instead lets you concentrate on other matters and usually use your brain for the fun stuff more often.

I can't seem to find it now, but I remember reading an essay, probably by Joel Spolsky -- on mentoring a newly hired junior Cprogrammer. The programmer had implemented some functionality in C, and had written lots of tiny function calls, with descriptive names, that composed to form the solution. The author called the programmer into the office, and berated the coding style, citing "efficiency" as a reason for why the program was an example of poor coding style.

The main point of the article, was that the junior programmer was right: well structured, self-documenting code is always better than fast code. If it ends up being too slow, and (in the case of C) can't be fixed with "inline" and "-O2", then, and only then, move towards a different, hopefully more efficient solution.

Now, obviously, writing functional-style C isn't the only (or perhaps even the best) way of writing structural, clean, C code.

But functional composition, especially with help from the underlying programming language, can be compact, and very easy to reason about.

Never mind the fact that approximately half of Haskell (and some clojure?) programmers appear to think that "f a b" is more readable than "scaleVector Vector Factor". Conciseness can be a weakness as well as a strength.

I think the idea behind homoiconicity is that you can generate and modify code using the same tools you would use on data; not string functions and regular expressions to manipulate the text you would call eval() on. Trying to understand semantics of code blocks this way is like parsing html with regular expressions. I used to modify built-in functions in emacs lisp by calling a modifying function (though later I was told the canonical way to do it was just to copy the function elsewhere, modify it, and evaluate it after the built-in was loaded).

Rich Hickey had a talk (not sure which one it is at the moment) about how we used to refer to programmers as data processors as the core of your job was reading data from somewhere, processing that data, then moving that data somewhere else. We've moved away from that definition but the fact is, at its core, we are still data processors.

Once you've convinced yourself of that and you look at Clojure through that lens you will find immense power in that language, as everything is built around data transformations.

I do think the move away from data processors as a title is more of an ego thing...none of us probably wants to be called a data processor.

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

That's significantly less powerful if you lack structured ways to compose things together before evaling them.

In a nutshell:

- Functional programming style tends to make your programs easier to reason about, as it avoids state/mutation. This also makes testing your programs much easier, and can also make concurrency easier.

- It's a different way of thinking. Some problems are much easier to solve in a functional fashion, some are much easier in a imperative fashion.

- Functional code can increase code re-usability as it decouples data from its operations

- A lot of functional languages have very advanced type systems compared to say, Java or C++. I'm personally a big fan of static typing and after learning F# I am sorely missing its type system in C#

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.