Gregory's Server@dotfox I was _just_ reading Steve Yegge rant about Clojure from 2011 about how hostile the community is for new features and guess what? https://groups.google.com/g/seajure/c/GLqhj_2915A/m/E0crn6zHLi0J?pli=1
|
12 comments
  @nikitonsky ok. I can't say it reads better for me, but I understand your point. However, I think it's ok to say that making changes for third-party readers can hardly be justified on the grounds that “it reads better for some developers”. Saying only that Go and Java have already adopted such syntax, so Clojure should do so as well, is not the best way to reason about such additions, don't you think? @dotfox it’s the perfect example. The feature is widely adopted among other PLs. It’s obviously good and desirable. It will harm no one. Implementation is probably 30 minutes. Yet “Clojure has its ways” @nikitonsky your not yet released edn reader will likely break after adding such separators. Why are you saying "harm no one"? @dotfox this change doesn’t even have to go into EDN, it could just be an addition to LispReader. And, as I said, implementation-wise it’s a trivial change @nikitonsky I was about to reply that none of those changes break the reader in unusual way when older version of clojure is used. like reader of any version of clojure prior to 1.10 will not read ##Inf as something valid, exception will be thrown. Unlike 42_000 that can be read as 42 followed by a symbol _000. But I forgot that underscore does not stop number reading in any version of clojure. So I don't know any technical difficulties in adding separators for number literals. @nikitonsky I have my opinion, you have yours. That's no reason to go back into toxic conversation and call someone "typical example". |
@nikitonsky sure, I'm no saint. thanks for pointing this out. let me rephrase - why do you need this way to write a number?