
Why Clojure? - jjgomo33
https://blog.cleancoder.com/uncle-bob/2019/08/22/WhyClojure.html
======
cutler
Clojure is by far the best programming language I've ever used. Rich Hickey's
Sermons On The Mount changed the game of programming once and for all. With
Clojure you could finally have your Lisp cake and eat it. Witness the sheer
chutzpah of the guy when he basically told Ruby devs they were doing it wrong
at Rails Conf in 2012
([https://www.youtube.com/watch?v=rI8tNMsozo0](https://www.youtube.com/watch?v=rI8tNMsozo0)).

~~~
noncoml
> by far the best programming language I've ever used

Would love to hear why? What is that make Clojure such a good experience for
you?

~~~
invalidOrTaken
Not the grandparent, but I realized the other day that I'm at nine years of
clojure, so...

What's made clojure so great, imo, is its unicorn status as a principled-yet-
practical language. That "principled" part is not worthless---it means that a
lot of great minds are drawn to it. Before react took over the world, clojure
folks were already taking steps in that direction.

A lot of other things. The "sequence" as a core abstraction is very powerful.
Immutable data structures by _default_ make functional programming perfomant
and efficient.

Speaking of data structures, data structure literals have spoiled me for other
languages. After Java, especially.

And none of this mentions clojure's lispiness. The ease of metaprogramming has
allowed the community to build some of the best tooling out there, between
CIDER for emacs, and Figwheel for the browser---oh, did I forget to mention
clojurescript? Being able to reuse code on the front and backend is great for
web applications.

Clojure isn't "everything." I think I'd still benefit from learning Haskell,
APL, and Forth, and I wouldn't mind knowing Ruby and js a bit better. And I'll
probably be dragged back to Python and R if I keep doing maths.

But if someone asked me which single language would probably do the most for
them professionally, I'd say clojure. It's the language people start startups
so they can use it.

~~~
amelius
What is GUI programming like in Clojure? What libraries exist, and what
paradigms are used? E.g. is it more like React or is it more like Gtk/Qt?

~~~
logicprog
There's a really good UI framework for Clojure (not ClojureScript) called
seesaw. If I recall correctly it was swing, but it's a very nice data focused,
functional library. It really works well with the Clojure philosophy and
interactive development. It's also VERY complete.

There are downsides, however. The UIs that it creates definitely look like
Swing apps. I.e. ugly at least on Linux. Also, the up to date documentation is
difficult to find, I'll like to it here when I get home. The GitHub-linked
docs work fine, but they do miss a few features.

------
fsloth
Can anyone give a pro/cons analysis of a ML variant versus of a Lisp variant.
Let's say F# versus Clojure?

One of the general arguments in Lisp vs the world is that lisp is more
concise. F# is really concise. It has datastructures as intrinsic part of the
language syntax (just like Clojure, i.e in F# [|,,,|] is an array and in
Clojure [...] is a vector, so more or less the same thing). Furthermore, the
type inferences concierges the developer through the regular bureaucracy
involved with strong type systems so effortlessly that you seldom notice it
... unless your code does not compile, in which case it's wrong somewhere and
you need to fix it (which you needed to do anyway).

Ok, so for the sake of the argument, let's say the syntax is equally light for
F# and Clojure, and their support for immutability is in the same ballpark.
And let's remove the argument "a type system is an encumbrance" because that
will only lead to situation specific debates - one side will say that massive
refactorings are a pita without types, and the other side responds that in
Clojure you can use data schemas and should have unit tests anyway. And those
discussions never lead anywhere conclusive.

So, besides the above mentioned topics, is there anything general one can say
of the distinctive advantages of these two languages in specific situations,
including how their two different ecosystems and runtimes affect the calculus?

I suppose it's extremely rare to have experts who have participated in any
large scale industrial developments with both of the languages, but if there
are, it would be really nice to hear their opinion. And the things I listed as
"outside of the discussion" might actually be critical, who knows...

~~~
pbiggar
My previous startup (CircleCI) was written in Clojure, my current one
(Darklang) is written in OCaml. I decided not to use Clojure again because
it's not statically typed, and my number one frustration when I coded in the
CircleCI codebase was that it was very very hard to know what shape a value
had, and whether it could be null.

OCaml certainly has a lot of flaws, and is not nearly as "nice" a language as
clojure, but the productivity of static typing (in the statically typed
functional language sense, not the C++/Java sense) is huge. Knowing you can do
a big refactor and the type system has your back is massive.

We sponsored core.typed to add types to Clojure, but there were flaws at the
time (they have have been fixed since), and we didn't end up sticking with it.

So Clojure I wouldn't use again. OCaml I would, despite having significant
flaws (every language has significant flaws).

~~~
fsloth
Thanks so much! This was exactly the sort of industrial benchmark I was after.

Am I correct in summarizing your experience as:

The possible encumbrance caused by types at prototyping phase is paid back
several times when refactoring a production codebase?

~~~
pbiggar
Hmm, I think it's more that types make it possible to refactor without fear,
both at the prototyping phase (when you refactor so much, I had 800 lines of
python before that that I was afraid to touch) and later.

------
kllrnohj
The response to "but is it slow" is pretty disappointingly bad.

> No. Clojure is not slow. Oh, look, it’s not C. It’s not assembler. If
> nanoseconds are your concern than you probably don’t want Clojure in your
> innermost loops. You also probably don’t want Java, or C#. But 99.9% of the
> software we write nowadays has no need of nanosecond performance. I’ve built
> a real time, GUI based, animated space war game using Clojure. I could keep
> the frame rates up in the high 20s even with hundreds of objects on the
> screen. Clojure is not slow.

If you're going to respond to this question at least provide _some_ comparison
maybe.

But otherwise that anecdote of "I could keep the frame rates up in the high
20s even with hundreds of objects on the screen." absolutely screams
_extremely slow_. High 20s FPS with hundreds of objects is incredibly bad on
the surface of things. Maybe it's closures fault, maybe it isn't and is
instead the fault of whatever was doing the drawing. But it's not a good look
either way if that's the only data point that can be provided.

Similarly the IDE/dynamic type question seems to have missed the main downside
of dynamic languages - lack of good IDE & other tooling support. How well are
things auto-completed for me? How well does the IDE warn I've made a type
error _before_ I've gone through a long compile & test iteration loop? How
well do linters or other things work, or is there some aspect of LISP that
means this is just not an issue like it is in other languages?

~~~
kbd
The biggest thing keeping me from ever seriously learning Clojure is the JVM.
Slow startup time means I'd never use Clojure for "scripts", and I certainly
don't want to have to manage the JVM in production scenarios, so when would I
use Clojure? If there was a native version that could produce static binaries
like Go/Nim/Rust I'd be much more interested to learn it.

~~~
scythe
By contrast, one principal reason I started learning Clojure was
ClojureScript. Making stuff that can run in the browser or as a browser
extension is awesome for cross-platform compatibility.

~~~
mbo
If you like "functional and runs on the JVM" you might like ScalaJS too. It's
a mature transpiler, and the community has rallied to ensure that all the
important libraries compile both to the JVM and to JS.

------
mabbo
> 1\. Economy of expression

Funny, this list is the same one I use as to why I'm so annoyed with Clojure
right now.

I inherited a mission-critical Clojure ML library my team uses for it's
primary business goals. It was written 4 years ago by a research scientist-
who quit 3 years ago. We know what it's supposed to do. We know that it seems
to do the job well. We just can't understand the code well enough to be
certain of what it's doing or how it's doing it. If this thing breaks or stops
working, we're screwed.

The problem is that the author, like most of us, found great joy in writing
very few characters to express very big ideas. Clojure let him do that to an
extreme degree. And I'm sure if you were sitting beside the author, with him
explaining these dense expressions, you would be enlightened at the elegance
and beauty of this language.

Sadly, I was not.

I'm sure Clojure is a lovely language. But it lets you write a Voynich
manuscript that compiles.

~~~
stjohnswarts
This is why I like python and C, almost impossible to layer in multiple layers
of opaqueness with them. You can almost always deconstruct what the original
person was trying to do, whether they were successful or not.

~~~
hyperion2010
Hahahahah. The inheritors of my python code who are not my future self would
beg to differ. I have so many opaque patterns that are vital and yet purely
conventional it hurts. They will miss the intention and go off and do
something else to solve a similar problem and now we have two patterns.

------
namelosw
A little bit off-topic, but I'm really confused that, why people on HN like
Clojure and hate JavaScript? I didn't have any analytical data but it's very
obvious already to anyone who read HN often. Are they possibly be the same
crowd or just independent groups of people?

For me, Clojure and JavaScript (at least for modern React community) are
similar when it comes to usage: Dynamic typing with Hash-map centric modeling,
use functions to compose thing but mostly without monadic patterns. The
methodology in the Clojure community has an official name: "It's just data".
This methodology works, and have it's own pros and cons. The obvious pro is
people can write generic functions without poking hundreds of nominal types,
interfaces and type classes.

The only big difference I see is macro, but Clojure community also doesn't
recommend writing macros unless you have to. There are also protocols and
types, but they're not encouraged to poke around, it's still map-first
recommended across the community.

There are very few language communities follow the "It's just data patterns".
From Java to Python to ML, people mostly modeling things with fixed-property
model, instead of just untyped maps, unless they have to.

For Lisps, I don't see map-centric approach is that stressed. Scheme might be
still list-centric, Common Lisp is more diversed when it comes to approaches.

Why people hate JavaScript so much? And why people speak highly of Clojure?
It's just about inconsistent details, or about the whole design itself? Is
there any important point I missed?

~~~
sbmassey
I don't hate any language myself, only the codebases I have to deal with, but
Clojure is very different from Javascript in its support for immutability,
such that if you want to update values you have to use atoms, agents etc. This
goes a long way towards making up for the lack of typing when trying to
understand peoples code.

Some people also find the lack of random syntactical noise in Lisp style
syntax preferable.

------
LandR
Has anyone done both elm and clojure script for Web work? Which did you
prefer, which had the best tooling etc?

I need to learn Web, as mucj as I don't want to, and love clojure and fp. Also
figwheel looks awesome, but how hard is it to setup.

I also think maybe to really get the best out of clojure script you also need
to learn react??

I'm not sure this is the case with elm.

Any other non js alternatives?

~~~
yakshaving_jgt
I have about two years of professional experience working with ClojureScript,
and about three years professional experience working with Elm.

There’s almost no comparison.

Elm compiles much more quickly.

Elm produces much more performant code.

Elm enables you to write software that works reliably much more quickly
because type errors happen at compile time, rather than at runtime like in
ClojureScript.

ClojureScript’s error messages are at times incomprehensible. Elm’s error
messages are best in class.

Elm is far easier to learn than ClojureScript, and you’re right — you _do_
need to know React if you’re writing a non-trivial ClojureScript application.

Elm is criticised for not allowing a synchronous IO escape hatch. This is a
pretty bad criticism I think. Being able to guarantee where effects _won’t_
happen is a pretty great thing. Any effects work and/or JS interop can be done
with ports. Ports work just fine.

Elm is also criticised for denying the user a lot of “power features” like
typeclasses. I find it mildly annoying sometimes that I don’t have everything
I want, but I understand the trade-off. This is to make the language more
accessible to your average JavaScript developer who has never tried anything
from this family of languages. And I sure as hell don’t find it annoying
enough to want to drop the type-checking compiler.

------
jmnicolas
Can someone explain me why they always (OK let's say almost always) use math
formulas to show what you can do with a programming language ?

I'm a desktop application programmer, not a mathematician. I don't need to
print the first 25 squares of integers or Fibonacci whatever. In fact I think
the hardest math I did at work was using modulo to get even and odd numbers
...

Show me how you parse a csv file, how do you connect to webservices or
retrieve data from a database, show me how to do a simple GUI, show me
something useful for the common dev.

I'll judge your ultimate programming language on these menial tasks that
comprise 99.9% of my programming time.

~~~
beders
Extracting two columns out of a excel sheet:

    
    
         (->> (d/load-workbook file "Questionnaire.xlsx")
           (d/select-sheet "Sheet1")
           (d/select-columns {:A :item :B :price}))

~~~
jmnicolas
Now we're talking. It would probably take 20+ lines of C# to do the same
thing.

How do you manage errors? What happens if Questionnaire.xlsx or Sheet1 doesn't
exist ?

~~~
purple_ducks
> How do you manage errors?

It becomes unwieldy like every other language.

> What happens if Questionnaire.xlsx or Sheet1 doesn't exist ?

Runtime exception.

I've seen too much Clojure code (and this goes for every language where error
handling is optional - Hi Javascript!) just skip error handling and focus on
"happy path".

And as demonised as Java's checked exceptions are, they at least forced error
handling to be thought of.

~~~
beders
Or you could use:
[https://github.com/adambard/failjure](https://github.com/adambard/failjure)

Ya'll underestimate the power of a programming language to create a
programming language. Just replace the arrow with `ok->>`

------
yakshaving_jgt
Clojure is one of the better dynamic languages.

The rub however is that GHC can check the consistency of my software faster
than I or my colleagues will ever be able to, and programmer time is
expensive.

So that's why _not_ Clojure.

~~~
iLemming
> and programmer time is expensive

That's why you need to spend 3 years learning Haskell? I feel that's the right
amount of years for an average Joe programmer to reach meaningful productivity
with the language. Well, maybe I'm exaggerating, maybe it's just two years.
Plus/minus another year to learn and understand compiler pragmas.

~~~
yakshaving_jgt
Hey, I won’t deny that it takes a relatively long time to learn Haskell to a
standard where you’re comfortably writing web applications with it.

I’m not sure how that’s a rebuttal to my point though.

I run a startup. I’ve already put the time in to learn the technology. I’ve
learned other technologies too. This one happens to be the one I find the
cheapest (now) to write. Did it take my employees a long time to learn
Haskell? Maybe! But I didn’t pay for that. They learned the technology for
whatever reason, and I’m seeing far better returns on my investment than I
think I would have if I hired a bunch of Clojure developers. My previous full-
time gig was at a Clojure startup. Their pace is pretty atrocious compared to
the pace of my current team.

~~~
iLemming
Alright, jokes aside, let's not get into "measuring dicks" and argue which one
is better. I know Clojure, and I know some Haskell. I love both. They both
have their strengths and weaknesses. To be honest - I always find things in
one that I wish existed in another and vice versa.

But your simple dismissal of Clojure (even though seem to be an educated one)
has no merits. Don't feel bitter because Clojure is growing in popularity (in
relative terms) and Haskell seems stagnated. Haskell is an older language and
has had its ups and downs, and I think it will be fine. Clojure as well - no
matter how aggressively haskellers would evangelize against it, it will
continue to grow steadily. Think of it as a gateway drug into Haskell. I know
people who jumped that way, and I know people who went the other way - from
Haskell to Clojure.

To me, it is like using headphones - some prefer wired ones, some people enjoy
wireless, even though audio quality suffers, wireless gives them a lot of
freedom and might be viewed as a "more practical choice." To that though,
proponents of wired might say: "what if the battery dies?". It is an endless
and quite pointless debate. So let's concur: Haskell is great, and Clojure is
fantastic too.

~~~
yakshaving_jgt
> But your simple dismissal of Clojure has no merits.

I believe it has an impact on my business' bottom-line. Saving money in
business is a merit.

> Don't feel bitter because Clojure is growing in popularity and Haskell seems
> stagnated.

That… was an odd take. I'm not sure what gave you the impression that I would
be bitter about Clojure growing in popularity (not that I think it is,
anyway). I have nothing invested in Clojure not being a popular language, and
the idea that Haskell has stagnated is a little hilarious.

> Haskell is great, and Clojure is fantastic too.

Again, I have never denied Clojure's merits. My position is pretty simple — I
have found it cheaper to build Internet software businesses with Haskell than
with Clojure.

------
hsaliak
This is all nice and exciting until you start to 1) Debug code, the high
density of clojure code means that this is really painful. 2) Read code you
wrote a while back. The high density of clojure code means that this is really
painful.

~~~
badsavage
looks like you don't know FP

pure functions are completely separate to every other parts of your software,
they are very readable and easy to debug

* edit: don't write functions longer than a few lines

~~~
iLemming
This. I've been using Clojure for a few years. Only once I had to actually use
a debugger. Just out of curiosity.

------
mbrodersen
I played around with Closure for a while to learn its cost/benefits. It is
basically the love child of Lisp, Haskell and Java. So it introduces nothing
new to the world. However it is certainly an interesting mix that some
developers like. And Rich Hickey is an entertaining speaker/presenter/seller
of Clojure. Even if you don't care about Closure, watch his talks on YouTube.

~~~
yakshaving_jgt
Clojure has nothing at all to do with Haskell.

I can't think of two more opposed camps in programming.

~~~
nimih
You're right, one is a language with a data-structure-centric approach to
problem solving and an emphasis on pure transformations of immutable nested
trees and lazy sequences, and the other one forces you to learn the word
Monad.

Edit: Joking aside, I do think you're right in terms of the ideological
foundations and organizational structures of the two languages (clojure's
emphasis on practicality, curation and evolution of the core library+language
by a single BDFL, compared to haskell's origins in PL research and democratic
design/maintainence), but in practice I think a lot of that comes out in the
wash--dynamicism vs. static typing is definitely a huge difference, but
there's a lot more to language design and the material practice of building
software than whether your compiler reads type signatures, and I think that
along those axes, especially when compared to other mainstream programing
languages/ecosystems, clojure and haskell end up being pretty close.

~~~
yakshaving_jgt
Your flippant comment is not constructive, nor is it very accurate in my
experience.

The last Clojure team I worked with decided to add “rop” to our project. The
documentation in this library seems to go to great lengths to avoid using the
word “monad”, despite the fact that the entire idea being encouraged by this
library is monadic composition, but specialised to the Either monad. I mean
come on, this library even takes its bind operator from Haskell.

These Clojure programmers were not Haskellers. They were just as indoctrinated
as any other Clojurists and probably would have made the same flippant comment
that you did.

And yet, here we are.

> clojure and haskell end up being pretty close.

In terms of the cost of building a software business, this has not been my
experience. In my experience, the cost of building software at a scale beyond
trivial is higher with Clojure than it is with Haskell.

~~~
nimih
I'm not sure I follow your complaint about "rop" (which is a library I'm not
familiar with), and I suppose my jokiness obscured the point I was trying to
make, so I'll try reiterating, since it seems like you're talking past it (I
will also try to address the points you raise).

First, to be clear, haskell's type system is powerful and interesting and
useful, and clojure's lack of good static analysis tools IMO represents a
serious [comparative] deficiency in the ecosystem (and spec is obviously no
substitute). I don't think that it will ever be possible for clojure to get
even close to the sort of compile-time checking/guarantees that haskell
offers, nor do I think clojure is particularly well-suited for the powerful
higher-level abstractions that you see in e.g. lens or recursion-schemes (or,
honestly, even Control.Traversable). My personal experience (both as a
hobbyist and professionally) has been that there are some practical advantages
from clojure's dynamism such that it probably makes sense (in a cost/benefit
sense) to eschew static typing in some/many circumstances, but I really only
have anecdotal evidence plus some intuition backing that up.

That aside, the point I was trying to get at was that both haskell and clojure
encourage you to build complex data representations out of simple, easy to
understand, composable, persistent structures, and then build up computations
by composing pure transformations on them. Additionally, both languages have
reasonable concurrency models/primitives, good tools for creating expressive
DSLs (if that's your thing), and powerful interactive development
environments. I, personally, find all of these features to be incredibly
important for effectively developing software--they shape in a very real way
the processes I use to plan and write and debug code--and most languages in
common use today lack at least a couple of them (some languages have none of
them, in fact).

~~~
yakshaving_jgt
Ok, thank you for clarifying.

Frankly, it’s not often I hear a rational argument like this in a typical
Haskell vs Clojure debate. Usually I just hear zealotry and a refusal to
address Clojure’s shortcomings, just like in the Robert Martin blog post. In
fact come to think of it, many of the other comments on this thread which are
replies to criticisms of Clojure are along the lines of “well, maybe you just
didn’t try hard enough. Maybe you failed. It’s not the system that failed.
Clojure is too perfect to fail.”

This kind of rhetoric is frighteningly similar to that used in multi-level
marketing.

I won’t deny Clojure’s benefits. They _are_ there, and I did say in another
comment that Clojure is one of the most sound dynamic languages. But I don’t
think everyone is honest like you were just now about its drawbacks. Robert
Martin certainly isn’t honest about it.

------
avmich
Having disagreed with Uncle Bob for years, now I'm starting to see some
reasoning in his thoughts :) .

~~~
Jach
His book _Clean Code_ is pretty good. Not in the sense that everything is
agreeable in it (though some not so great programmers would benefit themselves
and those around them from following it religiously) and a decent chunk of it
is covered much more briefly with one chapter of _The Practice of Programming_
but you can actually see the book as the artifact of a reasoning mind taking
certain principles and articulating them. It lacks the usual polite qualifiers
like "I think..." or "In my opinion..." or "Obviously not in all but in many
cases generally speaking..." before every assertion which annoys some people.
A fair number of his blog posts are like that too. Where Uncle Bob gets an
unfair reputation is when people take things out of context from the larger
works and (sometimes willfully) misinterpret them -- he doesn't say you should
never ever have comments, for instance. Of course some of it is his own doing
from occasional tweets that are by necessity of the medium less well thought
out or conveyed.

------
Bahamut
My team owns a Clojure app, amongst a lot of other apps - my understanding is
the current DRI (who inherited this app once the original one left for another
org) doesn't like working in it though, and that has been the experience of
other developers who have been recruited to the project over the past two
years. Most developers I work with on a day to day basis don't have any
interest in learning Clojure, and would rather work with Scala, the JVM
language most heavily used within my org.

One of my teammates also has production ClojureScript experience, and called
it the worst of both worlds (Clojure and JavaScript). The primary problem is
it doesn't try to abstract away the DOM, the most typically problematic part
of working with JS.

Just my own encounter with it so far - I haven't had the experience of writing
production Clojure myself, but from what I've seen with the syntax, I'm still
happily primarily writing JS so far when I'm not writing Python/Scala/etc.

~~~
kgwxd
Ive been doing various methods of js dev with tons of different framworks and
traspilers for 20 years, nothing is more pleasant to work with than
ClojureScript and re-frame once you learn it. It's the best of all the worlds,
and the DOM is very abstracted away via React. State transition is a breeze
with immutable data structs. Theres only 1 language to write, no JSX ugliness.

~~~
vga805
I have had a similar experience over the past 15 years. re-frame is absolutely
wonderful.

~~~
etatidem
+1

------
ertucetin
Here is my "Why Clojure?" blog post: [https://medium.com/@ertu.ctn/why-
clojure-seriously-why-9f5e6...](https://medium.com/@ertu.ctn/why-clojure-
seriously-why-9f5e6f24dc29)

------
cultofmetatron
been jumping into clojure lately myself. after years of js fatigue I've been
dying for a functional pairing to elixir on the backend. clojure is growing on
me with its nice hot code reloading and macros. (babel is basicly an overgrown
macro)

~~~
Royalaid
Are you using Clojure or Clojurescript?

~~~
simongray
Sounds like ClojureScript since they're also saying they use Elixir on the
backend.

------
kazinator
> _I saw the CARs and CDRs and CADDADDRs and thought it was all just academic
> baloney; interesting but not truly useful._

 _car_ and _cdr_ are accessors for the fields of a basic data-structure;
nothing academic about that. The very origin of the names is rooted in
_systems_ work, not academics.

 _(caddr x)_ provides a shorthand for (car (cdr (cdr x))), which is a
pragmatic thing.

You know, like #(* % %) instead of (lambda (x) (* x x)).

~~~
jjtheblunt
i thought CAR and CDR were named after IBM (?) assembly language on an old
machine.

[https://en.wikipedia.org/wiki/CAR_and_CDR](https://en.wikipedia.org/wiki/CAR_and_CDR)

~~~
kazinator
That's right; and that's a systems programming origin, not academics.

------
jodrellblank
" _Economy of Expression. [..] It requires fewer lines. It require fewer
characters. It require fewer hours. It requires fewer mental gymnastics. So,
here, for your entertainment, is the program that prints the first 25 squares
of integers._ "

    
    
        (println (take 25 (map #(* % %) (range))))
    

And in APL[1], iota 25 is the first 25 integers, and feeding the same list
into both sides of multiply squares the list, then turning it from a row to a
column is tabling it. "Table the multiply-commute of the first 25 integers":

    
    
        ⍪×⍨⍳25
    

It's fewer lines, fewer characters, fewer hours, less syntax, less grammar,
fewer symbols, fewer functions, less nesting, fewer mental gymnastics. Yet ..
worse? Because those things you say both lead you towards codegolf, and
implicitly have "fewer mental gymnastics" mean "I'm familiar with it already".

[1]
[https://tryapl.org/?a=%u236A%D7%u2368%u237325&run](https://tryapl.org/?a=%u236A%D7%u2368%u237325&run)

------
SeriousM
The most annoying phrase was "less code, less time, less...". Uncle Bob
thought us to be explicit, help the reader understand the code and be verbose
with the variables etc. Now he loves a Syntax that says #(25 % %)...
Aaaalright, try to get a new company member understand a big code base with
this massive oneliners. I doubt that this is the right language for enterprise
projects.

~~~
beders
Here's the fundamental thing to understand. Especially if you are new to Lisp:

The lines are more concise. That also means you will need _more_ time per line
to read the code.

Especially in Java, you can skip over so much boiler plate code, you kinda
feel you are reading code fast.

Not so with Lisp. You need some familiarity with it and you will need to adapt
to a line just having more stuff to understand in it.

Also, you can tune this using libraries as many things are a la carte.

------
igouy
>> Robert C. Martin: _Smalltalk was also an image based language. Very few
programmers have ever wrapped their minds around what that really meant. So,
unfortunately, the language languished compared to all the text-file based
languages._ <<

Where is the evidence?

Back in the 1990's IBM taught many of their consultants Smalltalk, and
researched what made learning Smalltalk difficult —

 _Smalltalk, although recognized as a good platform for rapid prototyping and
software reuse, is widely regarded as difficult to learn. Unlike learning a
procedural language like Pascal or C, learning Smalltalk is dominated by
browsing and code comprehension. Learners of Smalltalk typically experience a
long, slow start-up phase in which they become familiar with the class
hierarchy and object-oriented computational model but do little meaningful
work (our colleague Dave Smith calls this "climbing the Smalltalk mountain")._

Programmers having to wrap their minds around the class hierarchy and OO was
seen to be the problem.

------
acangiano
Clojure is impressive. It's likely what I'd be focusing on if Elixir didn't
exist.

------
thelazydogsback
I've been programming in Lisps on and off since the mid 80's, and I like
Clojure the language, but in recent times as mostly as .Net programmer, I find
the JVM and the surrounding Clojure tooling rather baroque. I find tutorials
often cover Clojure/Lisp basics, but assume that you're coming from the Java
world, so I had some difficulty getting what I consider basic workflows
working as expected. If homoiconicity/macros/eval isn't an issue, I'm happy
with F#/C# for the most part, but wouldn't mind having Clojure in the
toolchest as well, but I'm not sure of the state and maintenance of
Clojure.net.

~~~
etatidem
You also have ClojureCLJ, although the tooling and libraries around aren't as
nice as on the JVM (many libraries and even clojure.core functions directly
interoperate with Java).

------
cakoose
> Now let’s compare that to the equivalent Java program:
    
    
      public class SquaresOfIntegers {
        public static void main(String[] args) {
          for (int i=0; i<25; i++)
            System.out.println(i*i);
        }
      }
    

> This is considerably more wordy, even if you don’t count the enclosing
> class.

First of all, Java is famously verbose. Nobody is impressed when a language is
more concise than Java.

But even ignoring that, the comparison isn't representative. The enclosing
class and 'main' function aren't needed for every additional fragment of code,
so it probably shouldn't be counted here.

------
Qerub
I might be damaged from years of Java, but my main imagined issue with Clojure
is the lack of a component system. Call it OCaml functors or OOP classes, but
instantiating a component with replaceable components as input is what I
personally need for large scale programming. To make things more concrete,
let's say you are writing an integration to another system using HTTP. On the
surface you'll have functions like `fetch-album-information` and they will
internally use a HTTP client. How do you handle TLS configuration, HTTP
connection pooling, etc. and make the function testable and lifecycle-managed
to allow clean shutdown? The easy answer is to parameterise the function with
another function that takes care of all of that. But that function will need
to come from somewhere and I imagine threading these kind of functions
explicitly through your entire program will make it less than palatable. The
alternative of using globals that can be replaced in testing carry all the
usual problems that global variables have but seems to be what many settle
with judging from Clojure code on GitHub. It seems like others are feeling
this pain and have invented band-aid solutions like
[https://github.com/stuartsierra/component](https://github.com/stuartsierra/component)
but this is something I think needs a first-class solution to encourage this
kind of programming.

~~~
hcarvalhoalves
Why is a library a "band-aid", and why is it necessary to have such feature in
the core language?

~~~
yakshaving_jgt
I think it’s an argument about ergonomics. Threading state throughout your
control flow is bad. Implicits like in Scala are bad. Global variables are
worse. Something like a Reader monad is less bad.

------
jjtheblunt
Amusingly, in an article about a lisp, he's got an unbalanced right
parenthesis.

------
cannabis_sam
Now we just need to wait 40 years for him to come around to the usefulness of
static types..

------
ncmncm
It just breaks my heart to see Uncle Bob seduced by a Java-family language
right when C++ is getting increasingly fun. He suffered through the bad old
days when C++ was only fast and powerful, and is now missing out on the good
new days.

I guess he's happy. At least he isn't touting Haskell. Bon Voyage, Bob!

But somebody needs to break it to him that Lisp is not a functional language.
Or, if it is, so is C++.

~~~
avmich
> that Lisp is not a functional language. Or, if it is, so is C++

You're missing the point. Everybody can write Fortran in any language.

