5 ms·

Nice list, thank you for compiling it. I'm one of the Nim core devs so I naturally disagree. A lot on the list is painted as a negative, whereas I see it as a p

by dom96 8y ago

Nice list, thank you for compiling it. I'm one of the Nim core devs so I naturally disagree. A lot on the list is painted as a negative, whereas I see it as a positive, in particular: > * A return variable within procedures that works in the same fashion as an assembly routine with a registry Not sure I see the parallels between assembly and I don't understand why you think this feature is negative, can you elaborate? > * Mutable strings I love these! No need for messing around with `StringBuilder` and the like. > * Mutable everything That's simply false. You can choose between mutability and immutability, in fact you can even have an immutable `string` if you really want one: `let x = "asd"`. Now let me discuss some of your other points: > * Hate speech against functional concepts in the community (with all the related biases that this brings) Communities are large. A lot of us love functional programming and are bringing more and more of it into Nim. > * Some arrogant community members were tolerated just because they wrote popular blog posts on Nim implementing a fashionable pet project. Can you elaborate on who this was and how/where they were tolerated? > * no clear consistent design direction > * too many pragmas > * too many pascal syntax mixed with other language syntaxes These are mostly subjective so there isn't much I can say. Perhaps Nim just isn't for you due to its syntax, but many out there love it. > * no module namespacing > * modules worked not much better than C libraries... (I am generalizing) This is false too. Every imported module is in its own namespace. > * python 3 (without any library or optimization) was faster than compiled nim to count words on a moderately large text. Did you compile with -d:release? :)

nudpiedo 8y ago
Hi Dom96, thanks for answering point by point. Unfortunately I cannot answer all of these things since I got this impression about two years ago, and things might have changed or perhaps I got them wrong (as you say some of them are subjective). For example, I cannot tell what compilation option I used but I remember I went for the max speed I could and that I used default Nim language constructs and default python constructs (no libs), the compilation was one of the most sold features so I believe I used the release mode and that there was a marginal difference in favouring of python (subsecond). Think However that python has also many optimizations for string manipulation and that under the cover all runtime objects are references whereas in compiled languages developers are naked in front of the CPU. Knowing that you are core-dev I must say that building a language is very hard, and that by not bringing much to the state of the art and overselling too early it is easy to get compared and valued by subjective aspects or mere impressions. Heads up, keep it with the great work and do not take it personally, make the language shine in some unique aspect. Also do not forget that my comment was just an unfavourable opinion based on some observations I made years ago; I could change my opinion on the language anytime and give it again a chance if it brings me any benefit for my development, or it is fun, or it has some solutions for the problems I need to solve. Thanks for answering.
- woah 8y ago
  Lol, “naked in front of the CPU”
- deleted 8y ago
  [deleted]
atilaneves 8y ago
> > * Mutable strings > I love these! No need for messing around with `StringBuilder` and the like. D has immutable strings and no StringBuilder. Same with Python. Concatenating isn't exactly hard.
- dom96 8y ago
  In my experience code that needs to generate strings in Python would usually use a list of strings and then use `join` at the end. What's the problem with just making strings mutable?
  - atilaneves 8y ago
    The usual problems with making things mutable: that mutable state is the root of all evil.
  - ernst_klim 8y ago
    >What's the problem with just making strings mutable? They are not arrays of characters until you use ASCII/KOI8 or similar encodings. So there is no point in mutating them, you need unicode normalization facilities, formatters and stuff to deal with them properly. And a proper mutable unicode string would give you a terrible performance penalty.
    - kbd 8y ago
      It also applies to things such as using strings as dictionary keys. Immutable strings allows you to use them as keys without worrying about them being modified and breaking things. It's why Ruby encourages symbols as hash keys. I don't know Nim yet so I don't know what their solution is. It's also what allows Python to do interning of strings, since they can't change.
      - dom96 8y ago
        Nim gives you the choice of whether something is immutable or not. A `Table[T, Y]` (Nim's dictionary type) simply doesn't allow the key to be modified, no matter what the key type is.
bunderbunder 8y ago
I've just been learning Nim lately, and, for the most part I like a lot of how Nim handles these things. Getting to choose between mutability and immutability, together with procs having to explictly say when they intend to mutate one of their arguments, is fantastic. That said, I do agree with GP's first point, and can at least elaborate on it from my own perspective: At first I liked the implicit `result` variable, mostly just because it saved some typing. I quickly found it to be a source of confusing bugs, though, because accidental mismanagement of the feature would result in default values being implicitly returned rather than compiler errors. I think I ultimately agree with the Zen of Python here: Explicit is better than implicit. Also, Nim has, by my count, three different ways of returning a value from a proc: The implicit `result` var, returning the value of the last expression, and explicit `return` statements. It has four if you count modifying ref arguments. That's pretty TMTOWTDI for my tastes.
Symmetry 8y ago
I think what op meant about importing is one of the things I don't like about Nim. If you have import os then both existsFile("test.txt") and os.existsFile("test.txt") will work whereas I prefer Python's forcing you to use the later. Nim is definitely a language for small teams where you can expect everybody to agree on sensible best practices and not get too clever.
- Tiberium 8y ago
  Just use `from os import nil` and you'll be only able to use that module with "os" prefix.
  - Symmetry 8y ago
    You can follow that convention and it works but you could also just have the convention of always using os.existsFile. Again, if you follow sensible rules when using Nim you're fine and the compiler will protect from mistakes better than most compiled languages. It's just laziness and cleverness that are dangers :)
iffycan 8y ago
Regarding just the last point, I also came across a case where Python (and Node) were outperforming my Nim code (just counting lines in a file). But I just happened to be using a slow line reading thing [1]. You should definitely give Nim another shot. It has been very pleasant to use. [1] https://github.com/nim-lang/Nim/issues/9026 https://github.com/nim-lang/Nim/issues/9026
ptx 8y ago
>> * Mutable strings > I love these! No need for messing around with `StringBuilder` and the like. But if I get a string passed to me and want to hold on to it for later use, I can't be sure that someone else holding a reference to it won't modify it after I got it, right? So I will have to make a copy to be safe. Or does Nim solve this somehow?

by dom96 8y ago

nudpiedo 8y ago

Hi Dom96, thanks for answering point by point. Unfortunately I cannot answer all of these things since I got this impression about two years ago, and things might have changed or perhaps I got them wrong (as you say some of them are subjective). For example, I cannot tell what compilation option I used but I remember I went for the max speed I could and that I used default Nim language constructs and default python constructs (no libs), the compilation was one of the most sold features so I believe I used the release mode and that there was a marginal difference in favouring of python (subsecond). Think However that python has also many optimizations for string manipulation and that under the cover all runtime objects are references whereas in compiled languages developers are naked in front of the CPU. Knowing that you are core-dev I must say that building a language is very hard, and that by not bringing much to the state of the art and overselling too early it is easy to get compared and valued by subjective aspects or mere impressions. Heads up, keep it with the great work and do not take it personally, make the language shine in some unique aspect. Also do not forget that my comment was just an unfavourable opinion based on some observations I made years ago; I could change my opinion on the language anytime and give it again a chance if it brings me any benefit for my development, or it is fun, or it has some solutions for the problems I need to solve. Thanks for answering.

woah 8y ago
Lol, “naked in front of the CPU”
deleted 8y ago
[deleted]

atilaneves 8y ago

> > * Mutable strings > I love these! No need for messing around with `StringBuilder` and the like. D has immutable strings and no StringBuilder. Same with Python. Concatenating isn't exactly hard.

dom96 8y ago
In my experience code that needs to generate strings in Python would usually use a list of strings and then use `join` at the end. What's the problem with just making strings mutable?
- atilaneves 8y ago
  The usual problems with making things mutable: that mutable state is the root of all evil.
- ernst_klim 8y ago
  >What's the problem with just making strings mutable? They are not arrays of characters until you use ASCII/KOI8 or similar encodings. So there is no point in mutating them, you need unicode normalization facilities, formatters and stuff to deal with them properly. And a proper mutable unicode string would give you a terrible performance penalty.
  - kbd 8y ago
    It also applies to things such as using strings as dictionary keys. Immutable strings allows you to use them as keys without worrying about them being modified and breaking things. It's why Ruby encourages symbols as hash keys. I don't know Nim yet so I don't know what their solution is. It's also what allows Python to do interning of strings, since they can't change.
    - dom96 8y ago
      Nim gives you the choice of whether something is immutable or not. A `Table[T, Y]` (Nim's dictionary type) simply doesn't allow the key to be modified, no matter what the key type is.

bunderbunder 8y ago

I've just been learning Nim lately, and, for the most part I like a lot of how Nim handles these things. Getting to choose between mutability and immutability, together with procs having to explictly say when they intend to mutate one of their arguments, is fantastic. That said, I do agree with GP's first point, and can at least elaborate on it from my own perspective: At first I liked the implicit `result` variable, mostly just because it saved some typing. I quickly found it to be a source of confusing bugs, though, because accidental mismanagement of the feature would result in default values being implicitly returned rather than compiler errors. I think I ultimately agree with the Zen of Python here: Explicit is better than implicit. Also, Nim has, by my count, three different ways of returning a value from a proc: The implicit `result` var, returning the value of the last expression, and explicit `return` statements. It has four if you count modifying ref arguments. That's pretty TMTOWTDI for my tastes.

Symmetry 8y ago

I think what op meant about importing is one of the things I don't like about Nim. If you have import os then both existsFile("test.txt") and os.existsFile("test.txt") will work whereas I prefer Python's forcing you to use the later. Nim is definitely a language for small teams where you can expect everybody to agree on sensible best practices and not get too clever.

Tiberium 8y ago
Just use `from os import nil` and you'll be only able to use that module with "os" prefix.
- Symmetry 8y ago
  You can follow that convention and it works but you could also just have the convention of always using os.existsFile. Again, if you follow sensible rules when using Nim you're fine and the compiler will protect from mistakes better than most compiled languages. It's just laziness and cleverness that are dangers :)

iffycan 8y ago

Regarding just the last point, I also came across a case where Python (and Node) were outperforming my Nim code (just counting lines in a file). But I just happened to be using a slow line reading thing [1]. You should definitely give Nim another shot. It has been very pleasant to use. [1] https://github.com/nim-lang/Nim/issues/9026 https://github.com/nim-lang/Nim/issues/9026

ptx 8y ago

>> * Mutable strings > I love these! No need for messing around with `StringBuilder` and the like. But if I get a string passed to me and want to hold on to it for later use, I can't be sure that someone else holding a reference to it won't modify it after I got it, right? So I will have to make a copy to be safe. Or does Nim solve this somehow?