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

191–200 of 302 posts

Re: Why Clojure?

#191

Post by daslu »

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.

One important detail is that in Lisps like Clojure, printed values can usually be read back as code. So, the REPL is really a read-eval-print-LOOP.

Another detail is that the whole culture of the language, oriented towards immutable data, makes it very easy to evaluate almost any sub-expression in your code, which makes the whole code introspectable in a very playful and dynamic way.

Re: Why Clojure?

#192

Post by ivanb »

mkreis wrote: post #174
ldite wrote: post #164

Earlier quoted context omitted.

The dynamic typing and "everything is a map" can be a PITA. At the moment I'm working on a codebase that has I/O to JSON APIs, Avro schemas and postgres databases. That means that a field called "date" can be either a string, integer days since the epoch or a Java Date, and (because this codebase isn't great) there's no way of knowing without tracing the call stack. With the right discipline (specs, obsessively norma…

I'd emphasize that it's a problem with your particular code base. If you set it up correctly, all dates are properly parsed at the boundaries and you would only deal with one type of date inside your app. I'm working on a large Clojure app with a lot of date handling and never had any issues. For me, a date is always juxt/tick date.

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

Re: Why Clojure?

#193

Post by rrgok »

lkitching wrote: post #176
huahaiy wrote: post #114

Earlier quoted context omitted.

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…

Neither defprotocol nor deftype introduce static typing into Clojure. Errors in their usage are not checked statically and are only discovered at runtime.

So what happens at runtime if errors are found?

Re: Why Clojure?

#194

Post by geokon »

serpix wrote: post #168
mrkeen wrote: post #149

Earlier quoted context omitted.

I don't know enough about protocols. Will the compiler stop you if you misuse them?

The compiler will not know if a protocol is not passed to a function expecting a protocol. Whereas a static typing language will not compile. Similarly nothing prevents invoking missing functions of a protocol, you will only know during runtime.

Well you're typically not thinking of a compilation step with Clojure.. so I found the original question a bit not-applicable

The goal isn't to introduce .. a compilation step? but to have the program blow up in the spot where there is an type mismatch. If you don't use a protocol you may not blow up, you may generate a nil, and you may blow up much further down the line (or not at all)

In the rare instances where dynamic types cause problems, they're virtually always something convoluted like that. The protocol design pattern describes the interface and protects you from hard to debug situations

Re: Why Clojure?

#195

Post by cess11 »

dmos62 wrote: post #190
cess11 wrote: post #185

Earlier quoted context omitted.

You can keep a JVM running in the background with your project loaded and send stuff there from your IDE/editor. I don't think this is possible with JavaScript.

You can eval strings in Javascript, so pretty sure that's possible.

Looking around I don't find any maintained projects for this purpose.

Re: Why Clojure?

#196

Post by erichocean »

rootnod3 wrote: post #104
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…

Haven't worked much in Clojure, but I have the same experience with Common Lisp. The malleability and live image workflow is just very pleasant to work with.

Clojure is like that, but because data structures are default immutable, and all of the standard library (and the vast majority of 3rd party libraries) are also default immutable, the stress level is much lower.

You can still get mutability and I do this on every project. But it's a very small percentage of the code, less that 1%, and also well-defined.

Something like FlowStorm [0] isn't really practical in anything but Clojure, and things like Clerk [1] are easy and very natural.

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

Re: Why Clojure?

#197

Post by worthless-trash »

sundarurfriend wrote: post #148
golly_ned wrote: post #122

Earlier quoted context omitted.

I've never seen anything but praise for clojure.

I was gonna reply something similar too. The only "counters" people have when talking about Clojure (that I see, as a non-Clojurian) are pretty weak, and are usually: "it uses JVM, and JVM bad mmmkay" and the typical lazy dismissal of Lisps as "omg it's parantheses everywhere".

My new favourite is am seeing is clojure doesnt have enough syntactic sugar.

SMH.

Re: Why Clojure?

#198

Post by erichocean »

hhhAndrew wrote: post #153
eigenhombre wrote: post #117

Earlier quoted context omitted.

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!

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.

Re: Why Clojure?

#199

Post by dionian »

daslu wrote: post #191
Byamarro wrote: post #180

Earlier quoted context omitted.

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.

One important detail is that in Lisps like Clojure, printed values can usually be read back as code. So, the REPL is really a read-eval-print-LOOP. Another detail is that the whole culture of the language, oriented towards immutable data, makes it very easy to evaluate almost any sub-expression in your code, which makes the whole code introspectable in a very playful and dynamic way.

I never got deep into any lisp like language but this was one of my favorite aspects of them - homoiconicity.

Re: Why Clojure?

#200

Post by xigoi »

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…

> Things you don't like can generally be fixed (at least locally) using macros and libraries.

What macro do I use to make it not run on the JVM? :)

Post reply on HN