Live data from Hacker News

Why Clojure?

gaiwan.co

141–150 of 302 posts

Re: Why Clojure?

#141

Earlier quoted context omitted.

Did you move from CL because of hiring or another reason? I cannot imagine leaving CL and if I had to, I would go for abcl and then add clojure. Depending on the business that is of course. As long as I don't need to build a 1000s person tech team, I would not move; it's just far faster until you get to a scale where processes take over everything.

Hiring. And honestly the docs and stuff look really dated and I understand why people are a bit put off. At some point you have to modernize the look and feel of the ecosystem. The docs are really detailed though and if it was just me and a few others I would have gone to CL in a heartbeat.

Yes, they look dated but most things are just so incredibly stable, robust, easy to work with once you are in.

One of my pet peeves on github is with modern ecosystems that people ask after 1 week of no commits 'is this project dead'; we use rocksolid well documented and robust libraries that have basically not been updated for a decade; apparently you dont need to change the api every 2 days completely and introduce breaking changing in minor versions of libraries where the actual thing they have solved hasn't changed since the dawn of computers themselves... Like is the normal in npm libs for github star vying.

And the supposed lack of libraries; sure it happens, but more often it is so easy to roll (99% of npms) that in CL no one would use the CL lib if their was one; faster to roll than search for one.

I agree with the modernisation steps though: need to bring together fairly recent enough industry users and scan their code base for which common lisp functions and libs are used (as for as I see, most practical people use a subset and don't often go look for different ways to do something they might be buried in hyperspec somewhere) and distill that down to a Industry Common Lisp 'spec' and modernise everything related to that.

Re: Why Clojure?

#142
post #25

Earlier quoted context omitted.

You should give Gleam a shot. No REPL, but its simplicity, functional-ity and the BEAM lend themselves to the get-shit-done approach

Gleam takes more code to write than rust. Doesn't have a strong enough documentation / ecosystem yet. But I agree the beam VM is very underutilized and underappreciated.

> Gleam takes more code to write than rust.

Do you have some source for that? Perhaps an example?

Re: Why Clojure?

#143
post #13

Earlier quoted context omitted.

I feel like there’s a minimum developer quality that’s needed when using a language like Clojure, without static typing, and with a wealth of idioms and best practices that need to be followed and libraries that need to be known. Without it it’s a matter of time before the codebase can’t be developed anymore and the software doesn’t work as intended.

I would love to see how Clojure's "wealth of idioms and best practices that need to be followed and libraries that need to be known" compare to almost any other popular language. Clojure is by far the simplest most straightforward language I've ever used with very few details and gotcha's that need to be memorized.

I think Go, for all its flaws, is an example of a language where mediocre developers can be more successful.

Java would be another.

Re: Why Clojure?

#144
As I skimmed trough the article, the most important pros of Clojure seem to be: REPL, functional language, immutable data, dynamic typing.

I wonder what would happen if someone adds a REPL to F#. Sure, it wouldn't have dynamic typing, but isn't static typing good for large code bases?

In particular, judging from the article and comments, it seems that the major boon is having an REPL integrated in the IDE, running in the background, so you can have feedback while you are writing the code.

Having such an integrated REPL for a language like Python would make the productivity up to par with Clojure?

I am trying to understand if Clojure has a particular feature other languages can't add with ease.

Re: Why Clojure?

#145

Learning clojure has improved all of my programming in every language. I’m in love with the simplicity and smallness of it. Rich said one of the reasons he built it was he was programming like this already (pure functions acting on data) but the languages he was using didn’t support it well. There is a lot to be learned and applied even if you can’t use clojure at work every day.

>Rich said one of the reasons he built it was he was programming like this already (pure functions acting on data) but the languages he was using didn’t support it well.

But he could have been using F#, OCaml, Haskell. So it might not be just about pure functions and immutable data.

Re: Why Clojure?

#146
post #142

Earlier quoted context omitted.

Gleam takes more code to write than rust. Doesn't have a strong enough documentation / ecosystem yet. But I agree the beam VM is very underutilized and underappreciated.

> Gleam takes more code to write than rust. Do you have some source for that? Perhaps an example?

No. Take that with a grain of salt. I did some large file reading in the past and gleam doesn't have a good abstraction for that yet whereas in rust it was straightforward. Simplifile basically reads the whole file into memory.

Re: Why Clojure?

#147

As I skimmed trough the article, the most important pros of Clojure seem to be: REPL, functional language, immutable data, dynamic typing. I wonder what would happen if someone adds a REPL to F#. Sure, it wouldn't have dynamic typing, but isn't static typing good for large code bases? In particular, judging from the article and comments, it seems that the major boon is having an REPL integrated in the IDE, running in…

I use Python with a REPL in Emacs, it's relatively similar. The two important differences to Lisps I see:

1. Syntax. It's a bit easier to just evaluate a symbolic expression (put in a simplified manner: anything enclosed by parentheses) than to select a region of Python code to evaluate. But it's no major issue. Don't know about any syntax that has similar properties, Ruby seems to be somewhat similar in spirit, every expression returning an object. Python OTOH has all kinds of constructs you can't evaluate readily.

2. Functional code. Lisp code is generally largely side effect free, Python is not. That goes from the libraries down to how you write your own code by convention. Evaluating code without side effects for quick feedback is a breeze. For side effect riddled code, it's kinda easier to just use unit tests with mocks etc. for that. There are lots of languages with good functional libraries nowadays.

Generally speaking, the things you list are what used to be unique about Lisp. But apart from the two points I'm making, I don't believe that's the case anymore. Lots of languages got inspired in the last few decades. I love Lisps and I wish I could use them more, but I'm happy lots of popular languages got reasonably close.

Re: Why Clojure?

#148

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.

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".

Re: Why Clojure?

#149
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

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

Re: Why Clojure?

#150
post #22
post #20

Earlier quoted context omitted.

The repl isn't slow, what are you referring to?

Probably referring to startup time. Larger apps solve this with the “reloaded” type of workflow ( https://www.cognitect.com/blog/2013/06/04/clojure-workflow-r... )

I would often leave repls running for days so it never seemed to matter.
Post reply on HN