@moerm
> So I find it utterly illogical to have Myvar, myvar, MyVar,My_var, my_var,
> My_Var, all boiling down to one and the same.
They are not one and the same. The first letter is case-sensitive.
* * *
@shashlick
> my vote is to liberalize further - no restrictions with (...) case sensitiv
@treeform
> I want a vote, more data is better.
Just like the light bulb Nim wasn't invented by a democratic vote. It was
created by one particular smart man.
Had there been a vote on the internet how a new language should be the outcome
might have been quite different. Maybe something like Ru
@dom96
First and most important: I love Nim and consider it to be the (almost) perfect
language (that just needs a bit more growing up and mature).
> Nim is #1 on JSON and #14 on Plaintext.
So, evidently **you picked 1 favourable result.**
You find my "suggestions" ridiculous? It's sad to hear
Hey everyone! I wanted to share a small library (really just a macro) that I
wrote to help increase interop with the JavaScript ecosystem. I'm working on
some web tooling for Nim and was need to export functions to the JavaScript
world. The path of least resistance was utilizing the CommonJS mod
I totally appreciate the effort involved in education but this is a good
feature. It might help to enhance the wiki entry and perhaps point to this
forum thread and anyone who complains can be redirected. They can then decide
on their own whether they agree or not. This is a Nim legacy and whoev
> @Dom96 can I ask you about some more context for this?
The context is multiple things:
* I've been speaking to more and more people recently about Nim, discussed
their experiences selling it to other programmers and the conclusion seems to
be similar. Style insensitivity is awkward and they
> I don't know if this is clear or not but if you want consistency, you
> actually want how Nim works today.
That is the theory, but in practice it's a little more complex thanks to the
additional rule which makes the _first letter of any identifier case
sensitive_. A library developer decides
Here is my opinion: **I want a vote**.
I understand the merits of style insensitivity and I've argued for these merits
for multiple years now. I want to keep this short, so in summary, what it
really boils down for me is:
* **Educating newcomers about style insensitivity is and always will be
I'm sure this is not the most efficient or most all-encompassing way to do it
but it's one of the simplest:
import sequtils, strutils, tables
proc `%` (s: string, subs: openArray[(string, string)]): string =
var newSubs = newSeqOfCap[string](subs.len * 2)
for sub
what is the nicest way you know to make this work:
import strutils
echo "$foo, $baa" % {"foo": "foofoo", "baa": "baabaa"}
# foofoo, baabaa
Run
also, should this maybe be possible in standard Nim? This would be so
convenient!
I don't know if this is clear or not but if you want consistency, you actually
want how Nim works today.
Say you start a project tomorrow and your idea of style consistency is
cAmelCase, you can use the Nim stdlib happily. But the moment you import a
library authored by someone whose idea of co
> I like consistency, and I don't want inconsistent naming in my code base. I
> want the compiler to help me get it right exactly. stylecheck option is
> supposed to do that
I want a vote, more data is better.
I also don’t think it matters. I would rather core devs focused on fixing bugs
and “real” problems. But a simple vote is not hard.
I think being consistent with other languages is good. This is where I favor
strict case sensitivity.
But I also think trying o
I would have been interested in a vote, but apparently I'm the minority ;).
Personally I find the case insensitivity very off-putting and it was one of the
reasons why I stayed away from Nim the first times I came across it.
> I appreciate when Nim forgives me a typo
That's my main concern abou
I have to agree with the general sentiment here.
I do not want a vote.
Stability of 1.0 is far more important.
@Dom96 can I ask you about some more context for this?
> I've seen many people wince when hearing about this feature
Where have you seen this? I ask because, outside of the normal red
Please give us a program that we can reproduce the problem with.
**I don 't want a vote**
I agree with GULPF too. You should work on stability, Would you please stop
chasing perfection and start hardening what you already have ?
> You picked 1 favourable result.
No, I didn't. I just didn't bother to post about others because I found your
suggestions ridiculous, and still do (sorry).
Nim is #1 on JSON and #14 on Plaintext. The languages that are above it in
Plaintext are: Go, C, Rust, Java, C#. I see no PHP, or any othe
**I don 't want a vote**
Human can read a word even it's in cmplete form.
The must important is not style-readibility but flow-readibility.
Style-readibility is superficial reasoning to mislead the actual issue when a
code is badly written.
Considering at current stage, stability is more impor
I have not used nim for a while, mostly because my current project is in
typescript, now, wouldn't it be easier if I wrote TypeScript?
Case sensitivity helps readability and code maintainability, and If I remember
well, nim team always believed that the language should be assisted by a proper
e
I think a vote with two options is not sufficient to find out, what users
really need. Maybe the rule for identifier equality should get adjusted to give
users more freedom in naming things: A leading and trailing underscore should
be allowed. I guess there are some users coming for example from
I don't want a vote. It's a great feature that already saved me many hours of
unproductive discussion. There are more pressing topics to focus on to v1.0
I think @Libman and @gemath are on to something in suggesting that the
programmer should be able to decide how to handle insensitivity. To help Nim's
adoption, I'd say by default the compiler should generate warnings when
"insensitivity is detected", but you could later switch warnings off
I am OK with the current state - I don't want a vote. If Andreas wants to
change it I am OK with it too.
@moerm Nim was not in the results for these categories because - well, probably
no entry for Nim was submitted :-)
Style insensitivity is my least favourite feature. That said, I also don't want
a vote. I'd rather have a stable 1.0 sooner instead of another language change
I do not want a vote.
* There's no reason to believe that a random set of users will make a better
decision than the core team.
* Nim has other, more pressing, problems.
As to the second question, whether style insensitivity is a good idea:
* Inside the same module: no it isn't. For a l
I'm too "casual" to submit a relevant opinion, I just want to add a little "-"
to the yglukhov enumeration : Insensitivity can scares newcomers. Most
languages are fully sensitive and most people are used to include the style as
a part of the identifier and to use the style to reduce the need to
Hmm, my personal review.. I adjusted to it in 2 days, ofc before adjusting i
thinked its shit xD I know Nim needs a buff in community, but It is only a
turnout for someone who refuses to invest 2 days in nim and if he is that much
lazy we probably dont need them
I have no issues with the feature. Sometimes as yglukhov said, it reduces the
pressure of getting it right the first time when you are in a hurry.
I read these comments too, but how many people actually using nim has an issue
with that? Not the idea itself, but the execution? I can't think of a
30 matches
Mail list logo
