Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Clojure?

gaiwan.co

Post reply on HN
Print view View original

281–290 of 302 posts

Re: Why Clojure?

#281

Post by ivanb »

kaliszad wrote: post #265
ivanb wrote: post #192

Earlier quoted context omitted.

The parent comment illustrates the problem with one clear example. In real-world code functions pass around amorphous maps, they add, subtract and transform fields. There is no way to know what's being passed around without reading the source of the whole chain. Statically typed languages reduce the need to know how the data is structured or manipulated. The market has clearly chosen this benefit over what Clojure ca…

Yes and no. Statically typed languages only know that data stored in some piece of memory was conforming to some kind of shape/ interface when it was first stored there. That's why tricks like SIMD Within A Register (SWAR) work at all. E.g. when you need to parse temperatures from string input very fast like in the 1BRC: https://questdb.com/blog/billion-row-challenge-step-by-step/ How does your type system help there…

I'm assuming you replied to the wrong comment. If not, then all I see is straw men about performance, and I didn't mention none.

Re: Why Clojure?

#282

Post by incangold »

nogridbag wrote: post #237
hlship wrote: 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…

I gave Clojure a shot some years ago and even wrote an important tool used daily by all employees at our company in Clojure. The problem for me was maintenance. If I had to make any change to that code, I had to dive into the REPL just to understand it. Whereas with something like Java, even if something is poorly written and not documented, I can get at least a minimum understanding of the code just looking at the t…

Built a significant system in Clojure (from several smaller systems). Same experience.

I wish Hickey had built gradual typing in to the language.

I still love Clojure anyway.

Re: Why Clojure?

#283

Post by lkitching »

huahaiy wrote: post #272
lkitching wrote: post #268

Earlier quoted context omitted.

Of course Clojure has to ultimately be compiled into a native format for the host platform, bytecode in the case of the JVM implementation, but that doesn't require type checking in the same way Java does. Clojure functions are compiled into implementations of clojure.lang.IFn - you can see from https://clojure.github.io/clojure/javadoc/clojure/lang/IFn.h... that this interface simply has a number of overloads of an…

But if you add type hint in the signature, it does check the type. Basically, if you specify the type, it will check type. Just like any language that is not automatically inferring types, e.g. Java. So it is the same as Java. You guys make it out like Clojure is doing something extra to hide Java types, but it doesn’t. What Clojure does is really minimal on top of Java. It barely hides anything. If you give it type,…

I've already shown that type hints do not constitute type checking:

  (defn f [^String s] (.length s))
  (f 3)
is a valid Clojure program that fails at runtime with a cast error.

  class X { public static int f(String s) { return s.length(); } }
  X.f(3)
is not a valid Java program at all. Clojure compilation generates bytecode to dispatch dynamically and all but the most basic checks are handled at runtime by the JVM. This is fundamentally different to the static type checking that languages like Java and Scala do. It's not that Clojure is hiding something from Java, but rather that it isn't doing the considerable amount of effort the Java type checker does to analyse the program before execution. This is by design - Clojure has deliberately avoided adding a static type system in favour of things like spec.

Re: Why Clojure?

#284

Post by ldite »

erichocean wrote: post #206
ivanb wrote: post #192

Earlier quoted context omitted.

The parent comment illustrates the problem with one clear example. In real-world code functions pass around amorphous maps, they add, subtract and transform fields. There is no way to know what's being passed around without reading the source of the whole chain. Statically typed languages reduce the need to know how the data is structured or manipulated. The market has clearly chosen this benefit over what Clojure ca…

> There is no way to know what's being passed around without reading the source of the whole chain. But that's not what a Clojure dev would do. 1) We use Malli [0] (or similar) to check specs and coerce types if needed at every point. Checks can be left on in production (I do), or disable–up to you. 2) If the coercion is difficult, use something like Meander. [1] 3) If even that isn't straightforward and you need act…

> But that's not what a Clojure dev would do.

Apparently I and my fellow Clojure devs aren't real Clojure devs. Or perhaps you mean "true" clojure developers, or "good" clojure developers. (cf. https://en.wikipedia.org/wiki/No_true_Scotsman)

And even if we were Clojure devs we've inherited multiple big Clojure codebases that were apparently written by non-Clojure devs, and heavily refactoring is not on the to-do list.

Re: Why Clojure?

#285

Post by cutler »

Byamarro wrote: post #180
hlship wrote: 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…

Maybe I miss what REPL really is, but... If REPL is the main value proposition, how is it better from average JavaScript development? Dev tools allow you to basically interactively work with your code.

It's totally different. The R in REPL retains its original reference to the Lisp READer which is special when your code is structured as an AST as in all Lisps. Only in Lisps can you select the left paren of a deeply nested function and hit Eval. Other language REPLs are really just shells by comparison.

Re: Why Clojure?

#286

Post by cutler »

cogman10 wrote: post #257
snarkyturtle wrote: post #218

Earlier quoted context omitted.

So they try to make the least-worst JVM environment which is great if you're dead-set on using the JVM, which has a lot of pros. For most people Python/Javascript also does the job and you don't need to learn another paradigm — a Lisp — to code for it, which also makes sense. However, learning a Lisp also makes you a better coder because of immutability and less side-effects. Hence why Clojure is still around.

> learning a Lisp also makes you a better coder It can do, but it also can make you a worse coder. Specifically in typed languages. One of the issues I've ran into with Clojure devs doing Java is that instead of relying on a type, they tend to want to write stuff like `Map >`. Even when the key sets in both maps are well known. This becomes worse when you mix that with Immutability. Immutability can be fine except wh…

Clojure data structures implement structural sharing which minimises copying overhead.

Re: Why Clojure?

#287

Post by m1n1 »

m1n1 wrote: post #115
eddd-ddde wrote: post #107

Earlier quoted context omitted.

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

I worked with a 60K LOC thing* that talked to multiple services and had complex configuration. Ran fine on my laptop pointed at the company's dev env. The REPL let me test my changes while inside the thing as it ran. No problems. Someone wrote a nice *recording* debugger too which helped immensely -- no more "oops, I'm past the interesting part and have to start over" * in prod we usually give it a small number of la…

Forgot to add: multiple threads ... multiple DBs ... multiple topics on more than one kind of message queue ... hitting and serving REST endpoints -- all no problem for the REPL and the debugger[0].

If the thing was in Java, each fix attempt would mean waiting for startup and state re-creation. And each successful debug could have meant multiple sessions (vs visiting any mix of spots in a single recording)

[0] https://www.flow-storm.org/

Re: Why Clojure?

#288

Post by eigenhombre »

erichocean wrote: post #198
hhhAndrew wrote: post #153

Earlier quoted context omitted.

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

Reify is a general term, it means to "make concrete" (or to "make real" depending on the usage) something that is previously fuzzy or abstract. When you make a concrete subclass of an abstract class, you are "reifying" that class. When you made the abstract class from the concept of something, you are "reifying" that concept. It's a fun word.

And, possibly, Clojurists are more likely to use the word, because of: https://clojuredocs.org/clojure.core/reify

Re: Why Clojure?

#289

Post by gavmor »

huahaiy wrote: post #114
gavmor wrote: 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?

REPL code is copy/pasted straight into tests. So really, REPL is for helping write tests. BTW, when Clojurians talk about REPL, it's not about that separate window where you type and run the code as in other language such as python. They are talking about an invisible REPL running behind the scene, to which they send code within their editors, and the results show up in the editors too. There's no need to "miss stati…

> copy/pasted

When I've seen it done, it's seemingly executed in-place, which is very cool.

Re: Why Clojure?

#290

Post by lukev »

KingMob wrote: post #136
lukev wrote: post #96

Earlier quoted context omitted.

I think there's something here. I'm not sure it's a bad thing. A negative framing might be that there's a sort of elitism. A more positive framing might be that it simply reflects a tension between different, valid views of how to build software which are sometimes (but not always) in tension. After all, an elitist can also sometimes be right. Disclosure: I say this as someone who has been about as deep as you can go…

As someone who was equally deep (I worked with you and the Danes), I think a lot of that elitism isn't just about building software. It's a large part of why I've stepped back from clj these days.

love this... would love to discuss more (but not quite sure who you are)... hit me up via other channels?
Post reply on HN