NikiNov 22

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

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

@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?

Show threadswannodetteNov 22
@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.
Show threadNikiNov 22
@swannodette I don’t follow. Are you suggesting that languages are easier to change when they have 1000x more users?
Show threadswannodetteNov 22
@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.
Show threadNikiNov 22
@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
Show threadNikiNov 22
@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)
Show threadswannodetteNov 22
@nikitonsky this is a typical pet feature. Tiny changes to the reader often have surprising repercussions w/ what's out there. Anyways painting this is as easy along any dimension is just disingenuous.
Show threadNoah BogiesNov 24
@swannodette @nikitonsky no one's painting it as an easy feature. folks are saying that if there's communal desire for a specific feature (calling features you don't like "pet features" feels rude) and willingness to supply the effort to implement and support those features, it still feels bad to be gated by the whims of one or two people.
Show threadswannodetteNov 24
@noahtheduke @nikitonsky `pet feature` is less derogatory than meaning it serves some personal taste. I don't have any feeling here about this specific case other than - it just looks like something only a specific slice of users care about at all.
Show threadNoah BogiesNov 24

@swannodette @nikitonsky Ah sure.

isn't that true of every feature? how many folks will use the discard reader? or core.asyc.flow? or transducers? if a vocal subset of the user-base is saying "this feature will directly benefit our experience with and usage of the language" and they're willing to implement and maintain it, why the reticence?

Show threadswannodetteNov 24
@noahtheduke @nikitonsky no I would not say true of every feature. discard reader is old, so that seems part of Clojure's take on updating Lisp when it first appeared. core.async.flow is a library. transducers solve a problem everyone actually has which is being forced to generate garbage whether or not it's required for the task at hand.
Show threadNoah BogiesNov 24

@swannodette hard to say. i benefit from transducers because of the underlying changes, but i have yet to write one for any specific purpose and if they were in a library instead, i wouldn't use it. i've never deliberately used a future and don't see any reason why i would. i'm never going to use the new stateful stream seq functions. should those be excluded from the language?

the beauty of any general purpose language is that you can choose which parts to use to accomplish your goal.

Show threadswannodetteNov 24
@noahtheduke well important to not conflate our personal experience w/ what can be gleaned in surveys or other forms of data collection https://raw.githubusercontent.com/lispcast/lispcast.github.io/master/files/clojure-analysis-results.csv
Show threadNoah Bogies
@swannodette i'm sorry, i don't know what that list means or how to interpret it
Nov 25 at 1:06amWeb