
Simple Ain't Easy, but Hard Ain't Simple: Leaving Clojure for Ruby - sharksandwich
https://blog.appcanary.com/2017/hard-isnt-simple-ruby-clojure.html
======
gozur88
One thing he said I absolutely agree with - when you're in a crunch situation,
either in a startup or a new high-pressure project at BigCo, you don't pick a
tool set with which you're not familiar. Even if it looks very nice. You're
going to have enough frustration making deadlines without the additional
hassle of discovering the warts (and they're always there) of a new language.

Where I work there are always projects that are a little bit under management
radar - things that need to be done but don't need to be done in a big hurry.
That's the right kind of project to scratch your chin and say "You know, I've
never written anything in whitespace."

~~~
dagw
Someone once gave me the piece of advice that a project should only have one
'difficult' part. If it's a difficult domain problem or a difficult deadline,
use an easy language (as in one your already very familiar with). If it's an
easy domain problem and an easy deadline, then feel free to use a difficult
language or framework (meaning one that you'll have to learn while you're
doing the project.)

------
elsen
His experience matches most of mine:

I've been learning & trying to use clojure(script) for ~2 years now. A few
things I miss in every other languages:

\- The REPL: I usually don't need a debugger,

\- Figwheel: that makes frontend dev a pleasure,

\- reagent/reframe: are incredibly straightforward, there's no special syntax,
no special constructs, just a few functions, a few concepts (dispatch /
subscribed) and you're done,

\- core.async: based on a simple channels / pipeline paradigm

But then you get into the practicalities of testing & writing code. Shady
special cases[1][2], annoying testing tools[3], useless stack traces. And
other issues everybody knows. Simple things that become a 30 min discussion
with 3 different libraries and 2 blog articles to go through[4].

To me, there's this hardcore group of clojur'ist that seems to be hyper
productive and keep introducing new concepts. And the "rest" (me at least),
that are floundering. You fight with useless stacktraces? Boom, transducers.
You deal with buggy test runners? Bam, a new specification library with test
generations.

I've started moving my code to ES6 and Go. The community is filled with
helpful people, but it seems to me that if you're not writing Clojure
professionally already, the language is becoming less and less relevant.

[1]
[https://github.com/replikativ/superv.async/issues/2#issuecom...](https://github.com/replikativ/superv.async/issues/2#issuecomment-292112698)

[2] [https://clojurians-
log.clojureverse.org/clojurescript/2017-0...](https://clojurians-
log.clojureverse.org/clojurescript/2017-05-06.html#inst-2017-05-06T11:16:17.076103Z)

[3]
[https://github.com/bensu/doo/issues/134](https://github.com/bensu/doo/issues/134)

[4] [https://clojurians-
log.clojureverse.org/clojurescript/2017-0...](https://clojurians-
log.clojureverse.org/clojurescript/2017-05-06.html#inst-2017-05-06T08:48:31.683316Z)

~~~
hcarvalhoalves
The examples you raised are all - I believe not by coincidence - related to
how Clojure interact with the host platform (both Java and Javascript). It
simply doesn't shield you from it. As a consequence tracebacks bubble up, and
you're expected to know how to debug it, and hopefully use the debugger of the
host platform. This is aggravated on JS since JS exceptions mean nothing most
of the time.

clojure.spec (launching on 1.9) will allow better error reporting on some
cases, but the philosophy of the language has always being about giving you a
lot of power vs. shielding you from complexity.

Also, a lot of people being introduced to Clojure from a Ruby background (and
others, ofc) are having to learn simultaneously about: functional programming,
Lisp, immutable data structures, the internals of JS/JVM, advanced concepts
like STM, CSP, and a whole host of new libraries. That is a steep learning
hill, specially if one bought the argument that programmers are snowflakes who
can't take frustration. Once you're on the other side though, the complex,
messy real-world projects become more amenable, because Clojure was created
thinking about those. That's what Rich meant by "Simple ain't easy".

IMHO, working at a company w/ a codebase of ~150 projects written in Clojure,
the productivity has paid off w/ interest though.

~~~
meredydd
_> specially if one bought the argument that programmers are snowflakes who
can't take frustration._

I think that characterising a (clearly knowledgeable, well-referenced) account
of frustrations - especially ones that do not occur in other languages - with
the dismissive term "snowflake" is exactly where the stereotype of the "smug
Lisp weenie" comes from.

I have used and loved Clojure for years now (I wrote the patch that made
Clojure vectors implement java.util.List, back in the pre-1.0 days). The fact
that these problems exist doesn't itself give me existential worries about the
future of the language. The fact that almost every Twitter thread in the OP,
and the parent comment, contained this sort of dismissive reaction makes me
very worried indeed.

If we replicate the community of Common Lisp, we will end up replicating its
level of industry adoption.

~~~
lispm
> If we replicate the community of Common Lisp

Peter Norvig, Paul Graham, Dan Weinreb, Edi Weitz, Jans Aasman, Patrick
Winston, Kent Pitman, the people from Clozure/Franz/LispWorks/..., and many
many others.

That would be hard to replicate.

~~~
meredydd
And yet, even these luminaries were insufficient to propel significant
industrial adoption in the face of a famously hostile/arrogant/condescending
community. The same fate befalling Clojure would be terrible.

~~~
lispm
I find such a comment very hostile, arrogant and condescending.

------
zubat
Dreaming up new analogous phrasings to easy != simple now.

Fun > easy > simple?

------
dusanm
Revenge of the averages

------
blain_the_train
IMO The Clojure Community does care about developer happiness. I think
"happiness" is very subject, Clojure makes me happy, i'm a dev, what more can
i say on that? As Phillmv made his work about his feelings, i feel its
appropriate todo the same @phillmv blog and talk made me angry and sad at the
same time. I took a minute to try and understand why i felt this way and
concluded it was because while his technical concerns were valid, his tone
belittled my own experiences. He says he wasn't as productive in a new
paradigm, with a new language, on a tight deadline and because of this the
Clojure Community doesn't care about Developer Happiness? He says he isn't
talking about he community, but the langauge itself, but languaages dont have
feelins so i'm confused on how his complaint isn't being leveled at the people
behind and using the language. From my perspective, Clojure enables people to
do things that while possible in other languages, would require a lot more
effort:

1\. Projects like Onyx and Jepsen where a small team was able to accomplish
something beautiful. 2\. Property based testing and the awesomeness of ReFrame
state charts?

What @phillmv tried todo was very ambitious, and its awesome that he gave it a
shot, but his overarching conclusion seems to put the blame on Clojure and
that seems both unfair and unproductive.

Here are his specific clojure concerns and how i feel the community is
addressing them in a way that makes me feel very happy:

1\. StackTraces are hard to understand: Clojure Spec has been written about a
ton in this regard 2\. Debugger: Sayid Pro looks really promising, maybe a big
company could pick it up and support it? But from my limited perspective
things could be better for this story. 3\. Startup Time: I don't know if
anything is being done to address this, the current wisdom is that you work
within the repl and structure your projects so they can be "reloaded" which
has lot of nice properties.

Here are His Concerns i think are language agnostic:

1\. It hard to Structure large apps : While Clojure applied has some
suggestions i think every project is context specific. 2\. New learning curve
(lots of new ideas like reducers, map, transdecures, macros) : Their are a
wealth of resources on all these topics, what in particular was he not getting
answers about? 3\. JVM requires deep editor integration: I feel this is true
of every JVM language. 4\. Dependency hell: True in every language? Clojure
spec is actual designed to help with this eventually!

So his pain points are real, but thats not where he puts the emphasis. Rather
he puts that on his feelings. And as John Oliver has warned us, that makes it
easy to trivialize real problems, which i feel is what has been done here.

~~~
jgalt212
> StackTraces are hard to understand: Clojure Spec has been written about a
> ton in this regard

developers cannot be expected to spec out every function prototype. that's
just not a good use of time.

~~~
blain_the_train
total agree, I hope Clojure Spec will eventually be applied to most Core
Clojure functions, and that information will trickle up to user defined
functions. But thats only a hope, and possible based on my limited knowledge
of the tool.

However, aren't most languages with the best errors messages Static and
Strongly Typed?

My point was more that I think Spec was created to help address the issue. Not
necessarily that it was even a good solution.

~~~
jgalt212
calling spec upon every core function invocation will surely be a performance
hit, and a big one for tight loops.

------
BatFastard
My fav is Hard is easy, easy is hard.

~~~
elsen
You mean complex is easy, simple is hard?

~~~
BatFastard
indeed

