Live data from Hacker News

Why Clojure?

gaiwan.co

161–170 of 302 posts

Re: Why Clojure?

#161
post #61
post #54

Who are these articles for? I feel like Clojure’s value proposition is pretty well understood, and every last Clojure pitch can be relied upon to make the same exact points.

These articles are necessary to counteract armchair critics who are afraid of unfamiliar things and feel insecure. This crowd is loud: you can hear the choir of "but no one is using it, I tried it once and there were parentheses, I tried it and it was too hard, I hate the JVM" — there needs to be a voice that says it works (and works well!) for some people. FWIW, it works for me — I would not have been able to build…

Where are these mythical armchair critics living normally, what do they do, how much of their time is put into plotting of how to bring a misery for Closure coders?

Point of my sarcasm here is: you guys invoke them by yourself by writing overly defensive or overly religious posts. Then there will be ofc some critics, as with everything: they do not necessarily express a deliberate scheme against Clojure world. They are just some folks with different opinions, and also: very often wrong ones. But, as an advocate, please don't go into an offended teenager mode, when all the world plots against you; because a lot of rhetoric around defending Clojure sounds like that.

Re: Why Clojure?

#162
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..

I use Integrant to make systems out of components that are tied together at runtime. I have the option of running real versions or mock versions in tests or the REPL, with config drawn from the environment or config files or parameters. I can boot or reboot any combination of components at will. It’s fairly easy to divide and conquer this way.

Re: Why Clojure?

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

Not the same thing, but having something like JRebel can get quite close, and even if jshell isn't the best example of REPL, it isn't that bad either.

Re: Why Clojure?

#164

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…

I've never seen anything but praise for clojure.

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 normalising all data at the boundaries, good naming conventions) this wouldn't have been a problem, but that discipline is optional, and headbanging aggravation results.

(This is, of course, a generic "dynamic typing" problem, but that's a key feature of Clojure)

Re: Why Clojure?

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

Thank you, this is the most concise description I've seen for the REPL. That gets often lost due to the curse of knowledge.

It's a completely different thing to be coding "from within your running program" and it's hard to signal that to who has never tried.

Re: Why Clojure?

#166
I would have loved to continue working in Clojure but the jobs just aren't there. I spent 2 years trying to get a job and and couldn't even get an interview. 2 weeks of Ruby on Rails searching got me 2 interviews.

Re: Why Clojure?

#167

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

I too am excited about Jank but I thought it wasn't even hobby project ready yet?

Also yeah, I agree that Babashka is a delight. I've been using it to manage a Caddy server via Caddy's JSON API and it worked great, super flexible.

Re: Why Clojure?

#168
post #149
post #125

Earlier quoted context omitted.

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

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.

Re: Why Clojure?

#169

Earlier quoted context omitted.

I'd argue defprotocol, deftype, and defrecord provide much weaker guarantees than a type system. Dtuff like defprotocol tends to serve a similar use case to using an interface in Java. You specify the signatures for the functions, and then a concrete implementation can be provided using a library. Ring servers are a good example of this where you can easily plug different server implementations by just swapping a lib…

Nobody would argue that Java is not statically typed. That's my point. Clojure offers the same as what Java offers. If you write code in a defprotocol everywhere style, as many Clojure libraries do, your code won't compile if you got the types wrong. The same as Java. How's that not static typing? Which part of that is weaker? So what exactly this "Clojure dynamic typing" nonsense is about, I fail to see. Automatical…

> If you write code in a defprotocol everywhere style, as many Clojure libraries do, your code won't compile if you got the types wrong. The same as Java. How's that not static typing? Which part of that is weaker? > So what exactly this "Clojure dynamic typing" nonsense is about, I fail to see.

No-one has the time to learn all these languages, so for those of us not in the know, the most generous we can be is to take these praise articles at face value. And these articles are typically 'dynamic good', 'static bad'.

From the article:

  they insist on a statically typed worldview leading to parochial, snowflake APIs that defy abstraction and higher level manipulation, or both.
So I guess the user base for this language is those developers who think dynamic is better than static, and go for (as-static-as-Java) Closure.

Re: Why Clojure?

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

What was it about Elixir that you found dissatisfactory? I am currently evaluating Clojure vs. Elixir for a new project.
Post reply on HN