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 Bogies
@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.
Nov 24 at 8:12pmWeb
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 threadNikiNov 25
@swannodette @noahtheduke what should we look at here? I tried couple of transducer-speficic functions (transduce, cat, sequence) and they sit around 200-300. Is this a lot?
Show threadNikiNov 25
@swannodette @noahtheduke found the source (https://ericnormand.me/article/100-most-used-clojure-expressions). That‘s 200 usages over 7000 Clojure projects. I’d call that a pet feature :)
The 100 Most Used Clojure Expressions

Would you like to optimize your learning of Clojure? Would you like to focus on learning only the most useful parts of the language first? Take this lesson from second language learning: learn the expressions in order of frequency of use.

Show threadswannodetteNov 25
@nikitonsky @noahtheduke into uses transduce, so would be more important to figure out which of those 11000 usages use transducers
Show threadswannodetteNov 25
@nikitonsky @noahtheduke my point is that we should combine some science w/ the soft stuff, these are things that I know Alex Miller does when assessing things
Show threadswannodetteNov 25
@nikitonsky @noahtheduke and sorry, the actual source https://blog.phronemophobic.com/dewey-analysis.html
Analyzing Every Clojure Project on Github

Show threadswannodetteNov 25
@nikitonsky @noahtheduke when this was alive this was an awesome tool to understand what the community was actually doing https://github.com/fbellomi/crossclj
GitHub - fbellomi/crossclj: CrossClj: cross-referencing the Clojure(Script) universe

CrossClj: cross-referencing the Clojure(Script) universe - fbellomi/crossclj

GitHub
Show threadNikiNov 25
@swannodette @noahtheduke But wait, what’s your point here? Are you saying that top half of this list are pet features and you prefer Clojure without them? Because survey shows they are barely used
Show threadswannodetteNov 25
@nikitonsky @noahtheduke no such point! Only about actually looking at data when thinking about adding *new* things
Show threadswannodetteNov 25
@nikitonsky @noahtheduke codeq queries across time ranges would be awesome for understanding transducer impact etc so we consider facts along with feelings
Show threadswannodetteNov 25
@nikitonsky @noahtheduke also, Rich wrote about this stuff from a higher vantage point some years ago https://gist.github.com/richhickey/1563cddea1002958f96e7ba9519972d9
Open Source is Not About You

Open Source is Not About You. GitHub Gist: instantly share code, notes, and snippets.

Gist
Show threadNoah BogiesNov 25
@swannodette i'm sorry, i don't know what that list means or how to interpret it
Show threadswannodetteNov 24
@noahtheduke @nikitonsky I don't personally see much benefit in allowing pet features to proliferate. It's definitely not the Clojure I want (and I'm not claiming what I want is the most important thing). I think most users don't care about pet features and never really did - this is not the kind of thing that comes up in surveys etc.
Show threadNikiNov 25
@swannodette @noahtheduke how would it come up in surveys? People don’t call features they care about pet features, do they? That’s your judgement. People create issues and vote for them. And I see a lot of open issues