Live data from Hacker News

Why Clojure?

gaiwan.co

151–160 of 302 posts

Re: Why Clojure?

#151
post #93

I've been working in Clojure now for about 12 years. Maybe 12+ years of Java prior to that. I've created some great apps, and great libraries (in both Clojure and Java). I often describe Clojure as "the least worst programming language", which is an off-handed complement, but I think accurate. Things you don't like can generally be fixed (at least locally) using macros and libraries. The core is strong, a good basis…

How does the REPL approach scale in very large codebases? I.e. code that talks to multiple services, complex configurations, etc..

Even better than in small ones, because you don't need to spend 60 seconds building and restarting the application after changing one line: You simply redefine a single function at runtime and them can test the effect immediately.

Re: Why Clojure?

#152
I've been working with Clojure on and off for over a decade, and I've found it exceptionally efficient at solving a wide range of problems—making it one of the best general-purpose languages available. However, I sometimes envy the capabilities of OTP, which provides a straightforward way to build fault-tolerant servers without the overhead of managing containers or databases.

Additionally, while the growing number of compile targets in the Clojure ecosystem is impressive, it can also create confusion for newcomers. Whether it's compiling to native code with Jank, generating quick script snippets with Babashka, or using subsets of ClojureScript like sci or cherry, the diversity is both a strength and a challenge. I believe a concerted effort to unify configurations across these targets would help streamline the ecosystem and make it easier for developers to choose the right tool for their needs.

Re: Why Clojure?

#153
post #108

Earlier quoted context omitted.

I played with Clojure just a bit in 2014 because I wanted to write GUIs in Om, and this gave me a seriously warped habit of calling React.el('div',...) for a while. Sorry not sorry. I'm used to using TDD for fast feedback as I'm molding my code. Do you miss unit testing? Or, do you find that the REPL in no way obviates unit testing? And, do you miss static typing?

Not the OP but: One can develop with TDD in Clojure quite smoothly depending on choice of tooling; with CIDER in Emacs there are keyboard shortcuts to run tests for the current namespace or the entire project, so feedback can be very fast (if your tests are fast). I've also used (some time ago) test runners that stay running and re-test when a file is saved. In fact, it can be nice to do one's explorations in the REP…

> In fact, it can be nice to do one's explorations in the REPL and then reify one's discoveries as tests.

This is how I wrote unit tests when I worked on Mathematica: try out every edge cases of the function in a notebook, and then use a tool to extract all the input/output cells and convert them to tests. I didn't know the term reify for this practice, I like it!

Re: Why Clojure?

#154

Earlier quoted context omitted.

Coming from a love of strong typing (scala) clojure dynamic typing was a real adjustment. One thing I grew to really love is how small my changes were when I’m just adjusting a decidedly brownfield chain of functions that operate on data. With go in place at work, I added a couple fields to a core data type in my business and I ended up with thousands of lines of changes to pipe them everywhere. Doing the correspondi…

The Haskell type `[x] -> [x]` (the equivalent of `List[A] -> List[A]`) tells you an incredible amount about the function. It tells you that the function must calculate a subset of a permutation of the input list. The function cannot be anything else (or else it will crash or hang). In a language with stricter requirements you can omit even the crash/hang caveat. Don't underestimate the amount of information even simp…

Not necessarily a permutation; e.g.

    f :: [a] -> [a]
    f [] = []
    f (x:xs) = x: x: f xs

Re: Why Clojure?

#155

I’ve never used Scala or Clojure, but I heard them discussed a lot in the same circles in the late teens. It seems like Scala kinda vanished from common mention. Whatever happened to it, and what made Clojure take off?

I'd say most of its niches (async with Futures, akka, spark) now have other options. Also, Scala 3 happened.

Re: Why Clojure?

#156

I love writing Clojure. Whenever I say that publicly, there are inevitably some voices challenging my stance with skepticism, criticism, and attempts to discredit whatever I say provides practical value for me. Then I have to explain to them, "no, it's not the only language I know," "yes, I've used dozens of other languages before," "yes, including languages with robust static type systems as well." And you know what…

Did you or any of your fellow devs have ADD or ADHD? How did they adapt to dynamic types?

I have ADD and I once heard that devs with ADD/ADHD have an incredibly small heap size for context but compensate for their weakness by being great at solving logical problems in that small heap. Types have been essential for me when functioning in code bases. I really struggle with pure JS and untyped Python.

Clojure was similarly hard for me. What tools and/or techniques do such folks use for comprehending already written Clojure code?

Re: Why Clojure?

#157
post #57

I run a multi-million dollar business which I started with common lisp. I since moved away to go and then rust but I've been looking at clojure again lately. For a team that needs to get s** done and has more per employee productivity than Faang combined it's hard to beat the speed with which you can build things when you have the repl and interactive programming. The jvm while doesn't have great error messages is a…

Why did you move away from go? I don't use it, but seems like productive language, being simple, fast to compile and performant.

> being simple

Being simple is not a good thing. A simple language means that the programs become complex and hence complicated. The advantage is that it's easy to get up to speed and to write greenfield code though.

Re: Why Clojure?

#158

Earlier quoted context omitted.

I think the Java 8+ functional APIs/streaming/etc. kind of stole Scala's thunder. Java has all of the necessary tools to replicate the functional style of Scala now, and it's a lot easier to hire for, so :/

Ah, got it. So it’s not to much that Scala went away, as that Java became Scala?

No, not at all. It's just that Scala was hyped at a time and now it is a mature and stable language and hence "boring".

How often you hear of a language online does not reflect how much it is actually used. Nor does it reflect on how good the language is.

Re: Why Clojure?

#159
post #34

I like Clojure well enough, but it feels like every single time I see it mentioned now is an write up trying to justify using it.

> justify using it Justify using it against what? Can you name a single other language that does things better than Clojure? Not from your "point of values," but try seeing it from my position. Is there anything that can replace Clojure for me? I love the dynamism, malleability of the language - the flow; writing Clojure programs for me feels like playing a video game - it's plenty of fun. I don't get the same kicks…

Haha, it is "against what" that you have added by yourself. And that's exactly the issue with this kind of posts and comments: going right away into either a very defensive mode or a fight mode.

Re: Why Clojure?

#160
post #125

Earlier quoted context omitted.

I don't think spec with solve issues you are having about dynamic types. Spec is about asserting structure at domain boundaries; once you're inside a context, it will not do anything. i.e. If you're connecting stuff together and you want to make sure the state is correct as you pass between contexts -> great! If you're writing stuff and internally you miss having a strong type system... uh... I don't think it's reall…

why not just program to protocols? For complex data structures I typically just hide details behind a protocol and deal with the set of interface functions. You can then freely mess with the internals and not worry about details

In my experience (mainly when trying to understand the implementation of core.logic), the problem with protocols is that the code inspection tools choke on them.
Post reply on HN