Live data from Hacker News

Why Clojure?

blog.cleancoder.com

161–170 of 202 posts

Re: Why Clojure?

#161

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.

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

Re: Why Clojure?

#162
post #48

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.

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

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

Re: Why Clojure?

#163
post #91

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

What do you mean "the lack of a component system"? There's Mount, Component, Integrant. The last thing any language needs is to "encourage" some kind of programming. And Clojure is just that - it has small, stable core. The rest can be done with libraries.

Re: Why Clojure?

#164

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.

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

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.

Re: Why Clojure?

#165
post #152

Earlier quoted context omitted.

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…

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

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.

Re: Why Clojure?

#166
post #91

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

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

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.

Re: Why Clojure?

#167
post #57

Earlier quoted context omitted.

The above posters point on Homoiconicity is a big one, here is a quick (and silly) example for anyone unfamiliar with the term. Take the following clojure: (+ 1 2) => 3 Here the ( ) delimits, a list, and as the blog post says most lists are function calls. In this case the function is + and it's params are 1 and 2. It means if we do this (1 + 2) We get an exception that 1 isn't a function... However, we can tell Cloj…

Why not just do that as a function though? Why use a macro?

Because function arguments are evaluated before the function itself. In this case, that evaluation would fail because numbers do not implement IFn, and hence cannot be called.

Macro arguments are not evaluated, and so this works.

You could make it a function, and pass the arguments quoted, but it'd be more cumbersome.

Re: Why Clojure?

#168
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?

Re: Why Clojure?

#169

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.

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

I wonder which is more closer: 3years or "a week or two" to learn enough haskell to start writing things with it.

At least for OCaml/ReasonML it was "less than a week" for me and Haskell is probably not that much harder than another ML.

Re: Why Clojure?

#170

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

I don't think there's a lot of hate. It's just a quirky language that is at the heart of web application development. Based on its history, it has a lot of compromises. And not good ones.

It could be vastly improved with a proper REPL-based development (i.e. think developing within the browser dev tools, kinda, sorta), but instead we are now going the other way: Adding types and a compiler and making it harder to mis-type things, but also harder to work as productively.

I guess overall it has a few more ways on how you can shoot yourself in the foot compared to cljs ;)

Post reply on HN