The one thing Clojure is really good at is making excuses. Whatever good or great idea you come up with, backwards-compatible, no downsides, doesn’t matter: be sure they will find a reason not to implement it.

You know it's excuses, not arguments, because they ignore these considerations when implementing other features.

Even Java in its stagnation days was moving faster than Clojure :(

https://ask.clojure.org/index.php/8511/add-digit-separators-support-to-number-literals

Add digit separators support to number literals. - Clojure Q&A

Just saw as part of Go 1.13 they added: > Digit separators: The digits of any number ... considering all the valid Clojure number literal. Thank You

@nikitonsky I’m fairly sympathetic to Alex‘s point about the various third party readers/parsers
@jack @nikitonsky yeah this. Changing the reader is a hard sync point for tooling and all the actively used dialects.

@swannodette @jack I’d give this argument benefit of a doubt but let’s look at the facts:

1. They change reader all the time (e.g. in 2017, 2018, 2023, 2024)
2. Java and Go have way bigger ecosystems but they managed to pull it off
3. (EDIT, added later) It’s a trivial change, can be added to any reader in an hour

Besides, this paints rather dim picture: is that it? Will nothing ever change about Clojure? Even in backwards-compatible way?

@nikitonsky @jack 1. no, not in a way that impacts all dialects, 2. do you really believe Clojure has the resources that Java and Go do? Your conclusion has a "sky is falling" rhetorical flavor which is really tiresome for maintainers.
@swannodette I don’t follow. Are you suggesting that languages are easier to change when they have 1000x more users?
@nikitonsky I don't think "resources" is ambiguous here? There are a number people that you know by name that will have to get together and synchronize for a feature of debatable value.
@swannodette Oh, you think implementation is an obstacle? I’m sure I can have patches for all major dialects in a day. It’s really trivial feature, come on
@swannodette but if the problem really is just organizing people and voting (or whatever the current process is), then yes, that is the part that pisses me off. Because that process is clearly not working (it’s not producing results, even for simplest matters)
@swannodette Actually, I never heard a complaint from dialect or tool maintainers that Clojure is changing too fast. Are you sure that issue really exists?
@nikitonsky case in point I've been thinking about and working on porting method values for months mostly for portability - I have tons of notes, many conversations w/ Thomas Heller and @borkdude - on paper it sounds trivial but it never is.
@swannodette Are you saying you’d rather Clojure never implemented them? (I’m sure you don’t, but that follows from your argument, and I’m trying to point that out)
@nikitonsky it doesn't follow from my argument at all! I've not said anything about what should or shouldn't be done, only the costs of doing so. The conclusion that you made seems far bigger of a leap - that the lack of progress on IMO uninteresting reader feature means anything at all about Clojure / dialect / tooling dev
@swannodette it would be a leap if it was the only case, unfortunately that has happened many times more on many other features, so yeah, I lost faith
@nikitonsky Clojure development is really the same as it was since day one, if Rich doesn't like it, it ain't gonna happen. I can understand how that might be disappointing if you missed that particular memo :)
@swannodette I feel like it had way more momentum ~10 years ago
@nikitonsky it's just my very limited perspective but very little has changed. It's definitely pushed some people away over the years, but *shrug*. Cool people are still doing cool things w/ Clojure and I get do my own cool things at work. Good enough for me.