4 ms·

The ecosystem might be small but as you said it can grow and I think there's enough people out there willing to give a new language a try if it seems appealing

by jdrek1 4y ago

The ecosystem might be small but as you said it can grow and I think there's enough people out there willing to give a new language a try if it seems appealing enough, it's quite common to try a new language for Advent of Code for example. That being said, honestly the thing that stops me from trying/using Nim that the compiler enforces a style and that style is just wrong (it enforces spaces). Same goes for Go which enforces the opening brace on same line style. The people writing those languages can have whatever style they like for their code, but forcing me to use it is very off-putting to say the least. I get that this is probably a minor issue for most people but I can't deal with change that well and things like this are super annoying, especially since there is not one single reason for forcing a certain style on everyone. I'm aware that `#? replace(sub = "\t", by = " ")` works, but it's a hack and I'd have to inject it everywhere, not a good solution. But at least it's better than Go in this regard.

ryukoposting 4y ago
> That being said, honestly the thing that stops me from trying/using Nim that the compiler enforces a style and that style is just wrong (it enforces spaces) I agree that the spaces thing is weird. Personally, I don't care what style anyone uses in any language. Nim doesn't care either (besides tabs, for some reason). All I ask is that your style is readable and consistent. It seems like every developer has hot takes about code style. With Nim, no matter what hot takes you have about code style, I can import your module without you forcing your style into my code. I'm a firmware engineer by day, and it seems like every embedded C codebase on earth uses a different style. For me, it's refreshing to be able to write code that's styled consistently, regardless of the styles used by dependencies.
- jdrek1 4y ago
  Exactly, as long as it's readable and consistent I don't care what style other people write their code in, all I ask is that they and the compiler give me the same freedom and Nim and Go don't do that. > It seems like every developer has hot takes about code style. With Nim, no matter what hot takes you have about code style, I can import your module without you forcing your style into my code. I assume you're talking about the partial case insensitivity of Nim? I find that a bit weird tbh but I can see the appeal, you no longer would have things like a dependency doing weird things like all caps function names and forcing you to have that in your code.
  - ryukoposting 4y ago
    To some extent, Nim has a valid excuse because Whitespace is syntax. Forcing spaces should (ostensibly) make parsing more reliable, and users are less likely to have weird problems caused by their editors. Regardless, it's a negligible problem in my eyes. > I assume you're talking about the partial case insensitivity of Nim? That's one part of it, yes. I include UFCS in that as well. Case-insensitivity isn't as weird once you start using the language. Everything in the stdlib (and every Nimble package I've used) is in camelCase anyway, so I often forget that feature even exists. If anything, I'm grateful the language punishes people for trying to name one function `doHttpThing' and another function `doHTTPThing'.
    - jdrek1 4y ago
      I'll admit that it's much easier in languages that are not whitespace sensitive but imho it's not an unsolvable problem for the ones that are and software from 50 years ago not handling things correctly is not an argument if you ask me. I know it bothers me more than it probably should and likely more than the average person but at the end of the day such things have an influence on people. Everyone has some things they just prefer and imo forcing everyone to use one specific style is always a worse solution than using tools like code formatters and letting people have their way. > That's one part of it, yes. I include UFCS in that as well. Oh yeah, UFCS is pretty nice. Though I don't like the extra step Nim takes of dropping parentheses for 0 argument functions, I'd very much like to see if I'm calling a function or not. Sure for things like the size of an array it doesn't really matter but the call could be expensive. This is mostly for reading code though, obviously in my own code I'd never drop them. > Case-insensitivity isn't as weird once you start using the language. Everything in the stdlib (and every Nimble package I've used) is in camelCase anyway, so I often forget that feature even exists. If anything, I'm grateful the language punishes people for trying to name one function `doHttpThing' and another function `doHTTPThing'. I'd argue that it's still weird because the first letter is still case sensitive and I"m coming from a case sensitive language but being able to use foreign code in your own style is very appealing. I can't think of any good reason why anyone would deliberately have two different functions with the same name in different cases anyway, the closest example I can think of would be T and t for temperature and time but you can also just type those words out, more expressive anyway.
MercurialBlue 4y ago
From Araq on Nim Forums: > I decided to make Nim "space only" after having read an interview with Guido van Rossum who said that it is what he would do for Python if he were to decide it again. Also, and more importantly, back then I had never seen "tabs for indentation, spaces for alignment" applied correctly once. In fact, "compress 8 spaces into a tab" was quite common. (This is not the same as "tabs for indentation"!) In other words, it seems Nim simply attempts to learn from Python's mistakes (even PEP8 discourages the use of tabs for new projects), mixing tabs with spaces brings several potential technical issues for a whitespace-sensitive language, so why not just sidestep that problem entirely?
- jdrek1 4y ago
  Guido van Rossum also seems to prefer tabs but was held back by the community [1]. But even if he changed his mind since then those reasons are incredibly weak if you ask me, they basically boil down to "some software 50 years ago was pure shit" and that's not a valid reason. Tabs are simply the superior/right tool for indentation. You might want to see a tab 8 chars wide and I want 4 but we both see the loop body indented one level. With spaces enforced one of us would not see the code as they'd like it to be and while that might seem like pure preference on surface the simple truth is that preferences matter (see the recent thread about the ideal font for reading speed - it's different for everyone) and tabs provide the freedom while spaces don't. And in some cases they matter even more, for example I've worked with someone who was visually impaired and pretty much needed a tab size of 0 to be able to work, he wouldn't be able to do that with spaces. The only argument that ever comes from spaces people is "alignment" and while I personally think that most if not all of the things people try to align don't get any benefit from that alignment whatsoever nobody advoces for tabs only, you can still always use spaces if you really really really need to align something. Some people messing that up is really not a reason to straightup ban the superior way, you could just train those people better. If you want to align stuff, go ahead. The thing that matters is that if I don't care about your alignment while you do and we both have different tab width preferences then with tabs we both get what we want while with spaces only you would. Also while this was mostly about tabs vs spaces, those are not the only aspects of a style and the main point was that an enforced style will always upset some people. People simply work differently and intentionally preventing them from using whatever they like is pretty close to malicious if you ask me and in the best case still disrespectful. Some people work better in light mode, some prefer a complete rainbow IDE, some prefer to use raw vi, etc. Or for a better analogy, maybe someone codes much better while listening to loud death metal or whatever. Obviously in an office that would annoy other people but the solution is not to ban developers from listening to music completely but rather to make them use headphones in such cases so that other people are not affected. For code style I might work better with a certain one and you with a different style and that's okay, we just come up with some compromise style that the code is converted to before committing. Languages that enforce a certain style simply don't have this freedom. Now in whitespace sensitive languages like Python if (and only if) you want to align stuff then yeah things can go boom. But it also is not an unsolvable problem, if the code is all spaces then it just works, if the code is all tabs with no "alignment" then it just works, and if you use tabs with some spaces because you want aligned stuff that can pretty much be checked by the parser. Error if a space is found before a tab, error if a line has more than one tab more than the previous one, etc. I don't think sidestepping this problem is worth alienating people. [1] https://legacy.python.org/search/hypermail/python-1994q2/0205.html https://legacy.python.org/search/hypermail/python-1994q2/020...
Tozen 4y ago
Likely the Python-like/Whitespace-sensitive language issue is vastly more polarizing than people suspect. Possibly, if a person was introduced to a certain style with their first language (maybe second), it can become a preference. Then add to that, the compiler is enforcing a certain style, and perhaps a lot of people are being turned off/away. I can't even count the number times, over the years, I've had the silliest discussions with people about Pascal syntax. Untold numbers of people used to C-like syntax could not get over begin...end, instead of {...}. Then, even in Pascal circles (and other languages), there was the space versus tab or K&R versus Allman style preferences. It might seem trivial on the surface, but don't think it is. If a person has spent years working with things a certain way, that's what they are comfortable with. Depending on the person, it can take a lot or there has to be very strong incentives to pull them out of their comfort zone. People might look at Nim (or other languages), on just that aspect alone, and not be interested.

by jdrek1 4y ago

ryukoposting 4y ago

> That being said, honestly the thing that stops me from trying/using Nim that the compiler enforces a style and that style is just wrong (it enforces spaces) I agree that the spaces thing is weird. Personally, I don't care what style anyone uses in any language. Nim doesn't care either (besides tabs, for some reason). All I ask is that your style is readable and consistent. It seems like every developer has hot takes about code style. With Nim, no matter what hot takes you have about code style, I can import your module without you forcing your style into my code. I'm a firmware engineer by day, and it seems like every embedded C codebase on earth uses a different style. For me, it's refreshing to be able to write code that's styled consistently, regardless of the styles used by dependencies.

jdrek1 4y ago
Exactly, as long as it's readable and consistent I don't care what style other people write their code in, all I ask is that they and the compiler give me the same freedom and Nim and Go don't do that. > It seems like every developer has hot takes about code style. With Nim, no matter what hot takes you have about code style, I can import your module without you forcing your style into my code. I assume you're talking about the partial case insensitivity of Nim? I find that a bit weird tbh but I can see the appeal, you no longer would have things like a dependency doing weird things like all caps function names and forcing you to have that in your code.
- ryukoposting 4y ago
  To some extent, Nim has a valid excuse because Whitespace is syntax. Forcing spaces should (ostensibly) make parsing more reliable, and users are less likely to have weird problems caused by their editors. Regardless, it's a negligible problem in my eyes. > I assume you're talking about the partial case insensitivity of Nim? That's one part of it, yes. I include UFCS in that as well. Case-insensitivity isn't as weird once you start using the language. Everything in the stdlib (and every Nimble package I've used) is in camelCase anyway, so I often forget that feature even exists. If anything, I'm grateful the language punishes people for trying to name one function `doHttpThing' and another function `doHTTPThing'.
  - jdrek1 4y ago
    I'll admit that it's much easier in languages that are not whitespace sensitive but imho it's not an unsolvable problem for the ones that are and software from 50 years ago not handling things correctly is not an argument if you ask me. I know it bothers me more than it probably should and likely more than the average person but at the end of the day such things have an influence on people. Everyone has some things they just prefer and imo forcing everyone to use one specific style is always a worse solution than using tools like code formatters and letting people have their way. > That's one part of it, yes. I include UFCS in that as well. Oh yeah, UFCS is pretty nice. Though I don't like the extra step Nim takes of dropping parentheses for 0 argument functions, I'd very much like to see if I'm calling a function or not. Sure for things like the size of an array it doesn't really matter but the call could be expensive. This is mostly for reading code though, obviously in my own code I'd never drop them. > Case-insensitivity isn't as weird once you start using the language. Everything in the stdlib (and every Nimble package I've used) is in camelCase anyway, so I often forget that feature even exists. If anything, I'm grateful the language punishes people for trying to name one function `doHttpThing' and another function `doHTTPThing'. I'd argue that it's still weird because the first letter is still case sensitive and I"m coming from a case sensitive language but being able to use foreign code in your own style is very appealing. I can't think of any good reason why anyone would deliberately have two different functions with the same name in different cases anyway, the closest example I can think of would be T and t for temperature and time but you can also just type those words out, more expressive anyway.

MercurialBlue 4y ago

From Araq on Nim Forums: > I decided to make Nim "space only" after having read an interview with Guido van Rossum who said that it is what he would do for Python if he were to decide it again. Also, and more importantly, back then I had never seen "tabs for indentation, spaces for alignment" applied correctly once. In fact, "compress 8 spaces into a tab" was quite common. (This is not the same as "tabs for indentation"!) In other words, it seems Nim simply attempts to learn from Python's mistakes (even PEP8 discourages the use of tabs for new projects), mixing tabs with spaces brings several potential technical issues for a whitespace-sensitive language, so why not just sidestep that problem entirely?

jdrek1 4y ago
Guido van Rossum also seems to prefer tabs but was held back by the community [1]. But even if he changed his mind since then those reasons are incredibly weak if you ask me, they basically boil down to "some software 50 years ago was pure shit" and that's not a valid reason. Tabs are simply the superior/right tool for indentation. You might want to see a tab 8 chars wide and I want 4 but we both see the loop body indented one level. With spaces enforced one of us would not see the code as they'd like it to be and while that might seem like pure preference on surface the simple truth is that preferences matter (see the recent thread about the ideal font for reading speed - it's different for everyone) and tabs provide the freedom while spaces don't. And in some cases they matter even more, for example I've worked with someone who was visually impaired and pretty much needed a tab size of 0 to be able to work, he wouldn't be able to do that with spaces. The only argument that ever comes from spaces people is "alignment" and while I personally think that most if not all of the things people try to align don't get any benefit from that alignment whatsoever nobody advoces for tabs only, you can still always use spaces if you really really really need to align something. Some people messing that up is really not a reason to straightup ban the superior way, you could just train those people better. If you want to align stuff, go ahead. The thing that matters is that if I don't care about your alignment while you do and we both have different tab width preferences then with tabs we both get what we want while with spaces only you would. Also while this was mostly about tabs vs spaces, those are not the only aspects of a style and the main point was that an enforced style will always upset some people. People simply work differently and intentionally preventing them from using whatever they like is pretty close to malicious if you ask me and in the best case still disrespectful. Some people work better in light mode, some prefer a complete rainbow IDE, some prefer to use raw vi, etc. Or for a better analogy, maybe someone codes much better while listening to loud death metal or whatever. Obviously in an office that would annoy other people but the solution is not to ban developers from listening to music completely but rather to make them use headphones in such cases so that other people are not affected. For code style I might work better with a certain one and you with a different style and that's okay, we just come up with some compromise style that the code is converted to before committing. Languages that enforce a certain style simply don't have this freedom. Now in whitespace sensitive languages like Python if (and only if) you want to align stuff then yeah things can go boom. But it also is not an unsolvable problem, if the code is all spaces then it just works, if the code is all tabs with no "alignment" then it just works, and if you use tabs with some spaces because you want aligned stuff that can pretty much be checked by the parser. Error if a space is found before a tab, error if a line has more than one tab more than the previous one, etc. I don't think sidestepping this problem is worth alienating people. [1] https://legacy.python.org/search/hypermail/python-1994q2/0205.html https://legacy.python.org/search/hypermail/python-1994q2/020...

Tozen 4y ago

Likely the Python-like/Whitespace-sensitive language issue is vastly more polarizing than people suspect. Possibly, if a person was introduced to a certain style with their first language (maybe second), it can become a preference. Then add to that, the compiler is enforcing a certain style, and perhaps a lot of people are being turned off/away. I can't even count the number times, over the years, I've had the silliest discussions with people about Pascal syntax. Untold numbers of people used to C-like syntax could not get over begin...end, instead of {...}. Then, even in Pascal circles (and other languages), there was the space versus tab or K&R versus Allman style preferences. It might seem trivial on the surface, but don't think it is. If a person has spent years working with things a certain way, that's what they are comfortable with. Depending on the person, it can take a lot or there has to be very strong incentives to pull them out of their comfort zone. People might look at Nim (or other languages), on just that aspect alone, and not be interested.