Live data from Hacker News

Simple Ain't Easy, but Hard Ain't Simple: Leaving Clojure for Ruby

blog.appcanary.com

11–20 of 20 posts

Re: Simple Ain't Easy, but Hard Ain't Simple: Leaving Clojure for Ruby

#11
post #6

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

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 (launchi…

Exactly my cliché of the Clojure community: a discussion about simple things like testing and tooling becomes a place to brag about some random features of Clojure. Insulting my patience (or the original author) on the way is a new one.

You're just confirming my last point, professional Clojurist? Enjoy it. Others, be warned.

Re: Simple Ain't Easy, but Hard Ain't Simple: Leaving Clojure for Ruby

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

Re: Simple Ain't Easy, but Hard Ain't Simple: Leaving Clojure for Ruby

#14
post #2

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

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

Re: Simple Ain't Easy, but Hard Ain't Simple: Leaving Clojure for Ruby

#15

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

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

Re: Simple Ain't Easy, but Hard Ain't Simple: Leaving Clojure for Ruby

#16

Earlier quoted context omitted.

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 (launchi…

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

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

Re: Simple Ain't Easy, but Hard Ain't Simple: Leaving Clojure for Ruby

#17
post #16

Earlier quoted context omitted.

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

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

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.

Re: Simple Ain't Easy, but Hard Ain't Simple: Leaving Clojure for Ruby

#18
post #16

Earlier quoted context omitted.

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

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.

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

Re: Simple Ain't Easy, but Hard Ain't Simple: Leaving Clojure for Ruby

#19

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

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

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.

Re: Simple Ain't Easy, but Hard Ain't Simple: Leaving Clojure for Ruby

#20

Earlier quoted context omitted.

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

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

calling spec upon every core function invocation will surely be a performance hit, and a big one for tight loops.
Post reply on HN