As a new comer, it's really disheartening to see such a reaction from experienced (compared to me at least) Nim coders. I hope the core Nim devs lax their dictatorship so that more people can contribute and help improve this project ..
I have been shown a cold shoulder twice for mere documentation improvement proposals:
See issue 6216 which led to a conclusion that the .. and ..< must always be surrounded by spaces to prevent issues like those. So that other newbies don't waste the time as I did, I opened PR 6228, to be shot down by @Araq with I prefer if people actually learn the language's rules instead of blindly following a coding style that requires the minimum amount of understanding. Why would the tutorial still use the incorrect convention of ``0..9`` over ``0 .. 9`` when the former could trip new comers!?
Some time later.. issue 6958. The new strformat library in Nim 0.18.0 trampled upon the fmt identifier from a pre-existing strfmt library. The older fmt mimicked the Python .format, while the current fmt in Nim standard lib strformat mimicks Python f-strings. Both string interpolation features can technically exist in parallel. But with my suggestions going unheard in that issue, the older strfmt library is now unusable.. I see that as a big loss to this already small Nim community. The author of that older library has unfortunately stopped using Nim.
Such experiences put if off from tinkering with Nim for about a year.
And recently, I made one more attempt to learn Nim, and was quickly faced by issue 7852. Note that that issue was quickly closed without understanding what I was saying, and my proposal to "fix that issue" by fixing the docs got lost in thin air.
The Nim community is really small, and I would like the core devs to be more open-minded about any contribution they get (and not hand-wave suggestions from "New newbies" who otherwise have good programming experience in other languages).
Quick update.. good guy data-man fixed the very first issue I mentioned above by the time I finished writing that. Yay! :)
But my point for the core devs to be more open-minded still stands.
I have had a very similar experience to yours. I don't even remember the exact issue being touched, but I remember being put off from tinkering with Nim for a year because of a response I found rude. Don't remember the question, don't remember the answer, but I remember being pissed and angry at @Araq. That's been a long time ago, so no hard feelings by now :-)
I think we just have to understand that @Araq is not the softest of guys and has, well, a tough manner of speech. He says it as it is and doesn't sugarcoat things. Great programmers are not necessarily great community managers, and they don't have to be. We should accept him the way he is, I suppose ¯_(ツ)_/¯
Personally, I too think Araq could be softer in discussions, that it would be better for the Nim community in general, given the authority he has. But that's just an opinion.
what you mean with "more open-minded"
I didn't know how to best express that sentiment, so it ended up with that. May be I meant "the my way or highway attitude".. But it's the sentiment you get on:
- Me: "Hey, here's a PR with tutorial docs with the correct spacing needed for 0 .. 9 style ranges so that newcomers don't copy-paste the space-less 0..9 everywhere and then end up in difficult to debug situations." Dev: "They just need to understand how the operators should be used".
- Me: "Can you use a different identifier name than fmt in the strformat library, because then I cannot load the already existing strfmt library that also has the same identifier.. and both fmt versions have different functions?". Dev: "nobody should import both at the same time."
- Me: "The noinit pragma activation is unclear.. after spending many hours I realized that it works only on local vars in procs; the document should be updated." Dev: (closes issue, no action taken).
Wow I will try not to be offended. Thanks for answering my question :P
Hrm, am I missing something? What offends you about @kaushalmodi's post?
What @araq avoided usually is micro-improvement and that's still need to be merged to main branch. Imagine if there are 100 PRs and all those are micro-improvement :)
The first issue, it's actually not hard to write it by ourselves that I'm not sure whether it's indeed improvement or not.
For the space-things in operators invocation, Nim is really different with other languages where in Nim we can define operators by ourselves. Hence we must know the different between binary-operator and unary-operator and space holds significant thing to differentiate between two.
Take a look for example in this thread enumerate date string. Should we create PR for this .. ? I personally don't think so :)
I just want to say I have completely different experience compared to yours, perhaps you should try to contribute to Nim project from different angle/perspective, and then you'll get different response.
Thank you.
Well ... what can I say... I'm sorry if I tend to offend people but yes, I want Nim to grow and I am accepting PRs. Not "crazy" ones though. ;-)
Ignoring the tone in my answers, all the points I made I would made again. For example, I don't want the manual to contain a long-winded explanation about how .noInit has nothing to do with Python's None. Nim is not defined in terms of "differences to Python". If you can keep the patch to one or two lines (".noInit is only used to get speed improvements in fringe cases, it's only active for the native code targets") it would have been accepted though.
Both string interpolation features can technically exist in parallel. But with my suggestions going unheard in that issue, the older strfmt library is now unusable.. I see that as a big loss to this already small Nim community.
They do exist in parallel, it is not "unusable", the only thing that's somewhat hard to do is to use both in the same module. Which I still consider a fringe case. If you know how to make strformat better, please create a PR.
From my perspective it's you who is rude. You don't listen, you make bold unsupported claims ("strfmt is now unusable") and when you struggle with something, it's of course Nim's fault and you demand immediate action.
Well ... what can I say... I'm sorry if I tend to offend people but yes, I want Nim to grow and I am accepting PRs. Not "crazy" ones though. ;-)
Thank you. First of all, I apologize and fix my tone of communication.
For example, I don't want the manual to contain a long-winded explanation about how .noInit has nothing to do with Python's None. Nim is not defined in terms of "differences to Python".
There seems to be some miscommunication. I never once talked about noinit vs Python -- See my previous discussions here, here in this thread, and here. (For that latter thread, not knowing that noinit worked only for local vars led me to think that somehow it wasn't working for me. I had spent many hours debugging before I started that thread. Better documentation would save that.)
The manual says this here:
The implicit initialization can be avoided for optimization reasons with the noinit pragma:
var
a {.noInit.}: array [0..1023, char]
But it does not say that:
- {.noinit.} can be used only for local variables.
So I am just asking for that clarification in the manual. As C is the default backend, it would also be nice to document the default behavior of {.noinit.} for that.
If you can keep the patch to one or two lines (".noInit is only used to get speed improvements in fringe cases, it's only active for the native code targets") it would have been accepted though.
I wouldn't mind providing a patch. Though I don't see my self qualified to document noinit as I don't understand the internals. The patch should also clarify that code snippet for noinit.. var a {.noInit.}: array [0..1023, char].. it's very unclear and does not tell that that var is local.. adding a simple proc line on the top would bring much more clarity.
They do exist in parallel, it is not "unusable", the only thing that's somewhat hard to do is to use both in the same module. Which I still consider a fringe case. If you know how to make strformat better, please create a PR.
The ship has sailed. It's just disappointing that the new strformat could have been fixed before it got baked into 0.18.0. I would make a PR without a hitch if I could i.e. if I knew Nim better.. still a lot to learn on templating, macros, etc.
From my perspective it's you who is rude.
I could have done a better job controlling my frustration. I agree.
You don't listen, you make bold unsupported claims ("strfmt is now unusable")
That was an oversight on my part as I was writing that first post. I did specify that issue in a more technically correct phrasing in a later comment. Practically, one might like to (I would like to) use both fmt variants in the same module. But that's not possible. And I also like the strformat library. What I meant in my comment that you quoted was that as strformat is part of standard library and actively maintained, anyone would use just that if they had to pick between that and the old strfmt library.. and thus eventually people will end up sacrificing the Python .format feature that old library brought.
and when you struggle with something, it's of course Nim's fault and you demand immediate action.
I would challenge that bit.. I do **a lot** of research and self study before I raise any issue on Nim. And I never demanded an immediate action for those noinit, "../..<" and strformat/strfmt issues.. just some action. The action requested for the first 2 of those 3 was just documentation update.
The ship has sailed. It's just disappointing that the new strformat could have been fixed before it got baked into 0.18.0.
Well I disagree. I don't see how it could "have been fixed".
I would challenge that bit.. I do a lot of research and self study before I raise any issue on Nim. And I never demanded an immediate action for those noinit, "../..<" and strformat/strfmt issues.. just some action.
Alright, good to know. :-)
Well, I need to agree @Araq can be harsh but he does change his minds if given enough arguments. I remember him arguing ownership and destructors are not the way to go, like, year ago or maybe two and now just see his blog post about it. ;)
By the way... are there really some people who think noInit has anything in common with None? :-o None is basically nil, I'd say.
...and I also agree with Araq that the OP seems quite rude. :-/
Looks like you ninja-editted your comment..
Ninja-editing is a hard temptation to resist sometimes, I'm quite addicted to it myself. I've always wondered to what degree it is a bad habbit.
On other forums I used to have the etiquette to mark my edits in brown, but I think formatting possibilities are more limited here. I also used to make archive.is snapshots, but now that's also not working.
I think edit versioning would be a great feature to add to the forum...