Live data from Hacker News

Clojure is cool

ahungry.com

31–40 of 133 posts

Re: Clojure is cool

#31

I like verbosity in programming language. It becomes pretty easy to read the code, compared to lambdas or other concise languages. If you are not working for a startup, majority of the time, you will be maintaining legacy code or bug fixing. I would take easily understandable verbose code over "clever" concise code every time.

I've worked with Java for over a decade professionally. Most of the verbosity in it is just noise, and does not provide any meaningful information.

Clojure code is far easier to maintain for a number of reasons. The code is declarative, so it separates what's being done from the implementation details. The first step of code maintenance is to understand the intent, and it's much easier to do that with declarative code. Immutability means that the code is largely referentially transparent, so the cognitive load of understanding a particular piece of code remains constant as the project size grows. This is not the case for imperative languages where you pass references to shared mutable state all over the place. The syntax is much smaller and more consistent, meaning that you have to learn less rules and quirks to understand the code. There are less chances of code being misinterpreted. Finally, you have the REPL, so you're able to run any code you're not clear about right from the editor in the context of your application.

My team moved from Java to Clojure about 8 years ago, and we find that it's much easier to maintain Clojure projects than it was for similar scope Java projects. We deliver faster, we have far less defects, and we're able to make changes much more reliably than we ever could with Java.

Re: Clojure is cool

#32
post #29
post #26

Earlier quoted context omitted.

Studies have found that bug count is roughly proportional to program length, across languages. Saying you prefer verbosity essentially means you prefer more bugs. 500 lines is generally less understandable than 40 lines. There may be cases where terseness can be too extreme, but I don't see it here. Is there some particular aspect of the Clojure code here that you think is overly clever, or hard to understand? This C…

can you link the studies? I'm genuinely interested

They have been linked many times here on HN over the last 2 years.

Re: Clojure is cool

#33

Jvm is bloated. So no closure for me. I prefer Go

The claims regarding JVM bloat are largely exaggerated, especially now that the JVM introduced modules. However, if it's not your thing it's worth noting that ClojureScript happily runs on Node. Here's an example of how easy it is to get up and running with https://github.com/yogthos/mastodon-bot

Re: Clojure is cool

#34
Every few weeks I see a Clojure post on HN, and almost always there's a battle going on in the comments over whether the language is too clever, impractical, a toy, poorly designed, etc. My experience with clojure (a ~1500 loc library) has been quite good. I won't say it's intuitive for those coming from imperative/OO backgrounds, but when it clicked it really clicked. If a team decides to invest the time to learn clojure(script) for part of their stack I'd say it's a phenomenal tool. Please don't knock a language because of a team management failure.

Re: Clojure is cool

#35
post #29
post #26

Earlier quoted context omitted.

Studies have found that bug count is roughly proportional to program length, across languages. Saying you prefer verbosity essentially means you prefer more bugs. 500 lines is generally less understandable than 40 lines. There may be cases where terseness can be too extreme, but I don't see it here. Is there some particular aspect of the Clojure code here that you think is overly clever, or hard to understand? This C…

can you link the studies? I'm genuinely interested

I just found this link https://labs.ig.com/static-typing-promise Clojure seems to be the best followed by Go, both designed to be simple

Re: Clojure is cool

#36
post #30

Earlier quoted context omitted.

There could be a counterpart here that Java as a language is so complicated that people often come up with these design patterns because they THINK they are necessary.

Except nobody actually writes Java code like this. Nobody implements the Map interface. It's just stupid code. The myth of Java bloat only serves people writing silly blog entries and others hung up on "best practices" from 15 years ago. It doesn't seem to have any practical basis.

I've implemented the Map interface maybe a half a dozen times in my career in Java and many more in Clojure (using reify and friends). It's often very convient to offer a map interface to some remote service or data store as well as situations where I needed very custom caching or a specialized algorithm. The harder the thing I'm working on, the more motivated I am to present its API as something standardized if possible. This lets my users spend their complexity budget on what feature I'm offering and not on some random API I threw together.

Re: Clojure is cool

#37
post #26

I like verbosity in programming language. It becomes pretty easy to read the code, compared to lambdas or other concise languages. If you are not working for a startup, majority of the time, you will be maintaining legacy code or bug fixing. I would take easily understandable verbose code over "clever" concise code every time.

Studies have found that bug count is roughly proportional to program length, across languages. Saying you prefer verbosity essentially means you prefer more bugs. 500 lines is generally less understandable than 40 lines. There may be cases where terseness can be too extreme, but I don't see it here. Is there some particular aspect of the Clojure code here that you think is overly clever, or hard to understand? This C…

And studies show that the number of lines of code a developer puts out in a day is basically constant across all languages. This is usually cited as an argument for more expressive languages.

But if bug count is proportional to LOC and LOC per day are constant across all languages, then bug per day will also be constant across all languages.

You can write shit code in any language. I used to think Java made it harder to write shit code, but the project I'm on right now has made be reconsider this opinion.

Re: Clojure is cool

#38
post #30

Earlier quoted context omitted.

There could be a counterpart here that Java as a language is so complicated that people often come up with these design patterns because they THINK they are necessary.

Except nobody actually writes Java code like this. Nobody implements the Map interface. It's just stupid code. The myth of Java bloat only serves people writing silly blog entries and others hung up on "best practices" from 15 years ago. It doesn't seem to have any practical basis.

There are places stuck with Java 6 or 7. Java 8 is still relatively recent for the Enterprise world.

Java 8 was a special version. Lambdas, stream API, diamond operator and new exception catching syntax together eliminated 50-80% of noise in Java code. The language is still verbose, but much less than pre-8.

(Still, I prefer reading Clojure. The form of Java language still causes too much structural noise in the codebase.)

Re: Clojure is cool

#39
I really like and use Clojure professionally, but I have become wary of the extraordinary time I spend dealing with runtime issues because of the dynamic typing. I hope the future of core.typed is bright. I know it is being very seriously worked on. It can't come soon enough for me. Nowadays, I prefer to write in any statically typed language even if it is more line counts, just for my own sanity.

Re: Clojure is cool

#40

Anyone who writes Lisp without taking a moment to add a docstring to every definition would never get a job offer from me. (Not to mention comments as appropriate.)

I don't think I would not extend a job offer for lack of a docstring, especially given how trivial most of these functions are paired with their self-explanatory names. I'd actually rather a namespace docstring explaining intended scope and api than function docstring for trivial functions. I've found that function schemas/specs and reasonable names eliminate 90% of docstring material. Whether the remaining 10% is worth the string above and beyond the fn name is a case by case deal.

Comments are fine when the code is doing something unexpected or that is very terse. In other scenarios, comments are just a land mine to be armed when the code changes and the comment isn't perfectly updated. Bugs largely come from developer expectations being broken (mostly by one of: misunderstanding data shape, some API detail, some language feature, or miscommunication on the feature with the owner) and stale comments are a contributor to this which can be avoided in many cases.

Post reply on HN