Live data from Hacker News

Clojure is cool

ahungry.com

91–100 of 133 posts

Re: Clojure is cool

#91
post #76
post #31

Earlier quoted context omitted.

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

> 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 Could it just be that you are all better developers than you were 8 years ago, and the language doesn't really make a difference?

We're obviously better developers than we were 8 years ago since we've had a lot of practice in that time. However, my team has hired many people in that time, and we also regularly hire co-op students. We see that new employees are able to write better code in Clojure as well regardless of their experience. We've also found that it's easier to train beginners to be effective with Clojure than it was with Java. The language is smaller, more consistent, and encourages good patterns out of the box.

Re: Clojure is cool

#92

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

Code-sharing between ClojureScript and Clojure is a killer app

Is code sharing actually a thing between the front-end and back-end? I find that almost all interesting code "re-use" comes from libraries.

Re: Clojure is cool

#93

Earlier quoted context omitted.

Here is just one example of what client/server code-sharing makes possible: Hyperfiddle apps are fully CLJC which means literally the same code runs in the browser for view things, the JVM for web service things, inside Datomic Peer for database things, also Node and soon lambdas. Since they all share the same code, they can coordinate I/O automatically and transparently. Never code network side effect ever again! ht…

> literally the same code runs in the browser for view things, the JVM for web service things No, it does not. The same Clojure code may be the source for both execution environments, but that doesn't mean that the code that runs (JVM bytecode or JavaScript in the browser) is remotely similar, follows the same rules, errors under the same conditions, or otherwise behaves similarly. That's not an argument against code…

You're correct that there is a difference between execution environments between the JVM and Js. However, in practice you're very unlikely to run into them. My team has been heavily relying on cross-compilation for about three years now. We have yet to run into a scenario where this kind of problems actually came up.

Re: Clojure is cool

#94
post #53

Earlier quoted context omitted.

Literally interviewed at a company that is doing the same thing. B series, clojure/scala codebase, moving away to Elixir Phoenix.

Looks like a big waste of time and resources. They're probably just trying to use the "coolest" thing without worrying about delivering things.

You would think but they measured what they need and they are sure that Elixir is the right fit for their use case. They aren't a CRUD company, like 99% of others. They are doing freaky things with multiple freaky orchestrations with multiple freaky OLD-WORLD institutions. Rails aint gonna cut it.

Re: Clojure is cool

#95

Earlier quoted context omitted.

Here is just one example of what client/server code-sharing makes possible: Hyperfiddle apps are fully CLJC which means literally the same code runs in the browser for view things, the JVM for web service things, inside Datomic Peer for database things, also Node and soon lambdas. Since they all share the same code, they can coordinate I/O automatically and transparently. Never code network side effect ever again! ht…

> literally the same code runs in the browser for view things, the JVM for web service things No, it does not. The same Clojure code may be the source for both execution environments, but that doesn't mean that the code that runs (JVM bytecode or JavaScript in the browser) is remotely similar, follows the same rules, errors under the same conditions, or otherwise behaves similarly. That's not an argument against code…

[deleted]

Re: Clojure is cool

#96
post #79

Earlier quoted context omitted.

No, core.spec does not address the main issues with dynamic typing. It offers some neat stuff, but it is not a replacement for static typing.

Dude, Clojure is a dynamically typed language and always will be. If you don't like it use something else.

You may want to check out Typed Racket as an example of what people can do if they decide they want types in their lisp. [0]

[0] https://docs.racket-lang.org/ts-guide/

Re: Clojure is cool

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

I looked over the first example in the article and I don't think this assessment stands up. The Java example could easily be written with reflection and end up quite a lot shorter than the Clojure example.

Sure, you can trade off static typing for terseness. This isn't a Java vs Clojure issue. You can make code even terser by abandoning documentation. Even more terse by abandoning tests!

I don't have time to fully dive into the second example, but at first glance it looks like poorly written Java. You can write Java in a functional style! It can look a lot like Kotlin or Scala or even Clojure, and I generally prefer it to.

Badly written code looks terrible in every language.

Re: Clojure is cool

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

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…

If bug count is proportional to LOC and LOC per day are constant across languages, then bugs per day might be the same. But you'd still expect features to be getting implemented at a higher rate, and you'd expect a lower bug count per feature. That's ultimately the metric that's most interesting from a business perspective.

IME, the bugs are also easier to deal with in the more expressive language. They tend to be things like faults in the business logic or gross edge cases that people are likely to catch in code review or QA. Whereas the bugs in languages like Java seem to typically be really annoying things like off-by-one errors, comparing Integers with ==, and goofy run-time type errors that sail past the compiler because of weak static type checking when generics are at play, and also past code review because people aren't expecting to have to review for type errors when they're using a static language.

Re: Clojure is cool

#99

nil is not. nil punning is a band-aid. Otherwise, I love the lang.

On the contrary, nil punning seems exceptionally well suited to a dynamic language. In general, I'm only burned by nil propagating into Java, almost all Clojure code seems to handle nil appropriately. I'm unsure of a good way to represent optionality in a dynamic language without a static type system. Or rather, doing so with the tools available -- core.match vs real pattern matching -- seems rather un-ergonomic. I'm…

You are right regarding the dynamic language, well, dynamic. I haven't put any thought into it and I can't come up with a viable solution of eliminating nil without some type system strategy (Maybe/Either Monads in Haskell, Option in Rust, etc). It's kind of a bummer, because I love the Lisp dialect of Clojure, but really appreciate software projects that I've written in the past that don't crash due to a forgotten potential nil value handling.

You do have a point!

Re: Clojure is cool

#100
post #41

Earlier quoted context omitted.

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

> Java 8 is still relatively recent for the Enterprise world. Most actual surveys put Java 8 penetration at 70 - 80%. Dig deeper and the This is what makes the entire exercise a myth. People may want to believe this stuff but again it has no practical basis.

How are those surveys done? I'm not sure if the type of companies I'm thinking about are answering surveys, or otherwise participate in broader developer community.

I was pretty much spearheading the use of Java 8 in one company ~2.5 years ago, but I know some teams actively developing there only upgraded a year ago, and I'm willing to bet the main customer still didn't...

Post reply on HN