8 ms·

I looked at Nim briefly. It seemed cool, but there were some things that I just heavily disagree with. Forcing a keyword for discard means that there's an incen

I looked at Nim briefly. It seemed cool, but there were some things that I just heavily disagree with. Forcing a keyword for discard means that there's an incentive for imperative code not to return a value, whereas I argue that that should be encouraged. Also, I find the macro system unweildy to use, especially coming from Lisp.

shakna 10y ago
From my Python background, Nim felt great. However, once I started a reasonably sized project, getting Nim to compile it became difficult. Lots of small little quirks that weren't greatly documented. However, when it did build, it was reasonably fast, and allowed me to tweak the C code when I disagreed with the compiler. Macros were still getting developed, last I played with Nim, but I'm not sure comparing with Lisp is fair. I adore Lisp, and its macros. (Both CL style and Scheme). But most languages are designed to constrain the programmer to a way of thinking, a series of patterns. Lisp was the opposite. Even in languages that try to give the programmer flexibility, they miss the power of Lisp's homoiconity. That being said, I think Nim is trying to find a middle ground between Python's "only one way to do it" and Lisp's "get out of the programmers way". Its a decent language, albeit with a tiny, rather opinionated, development team.
- qwertyuiop924 10y ago
  They're still in development? Well then, maybe there's hope.
  - dom96 10y ago
    The whole language is still in development. If there are things you dislike, like the macros, then please submit some bug reports on Github[1] or talk to us on IRC[2] and Gitter[3]. Ideally, help us improve it by submitting pull requests :) 1 - https://github.com/nim-lang/Nim/issues https://github.com/nim-lang/Nim/issues 2 - irc.freenode.net #nim 3 - https://gitter.im/nim-lang/Nim https://gitter.im/nim-lang/Nim
  - shakna 10y ago
    Just a shout out to dom96 below, that guy was awesome when I was blindly fumbling with the language. Snappy responses to Github Issues, with really clear, really polite responses. Even when I was an idiot.
    - dom96 10y ago
      Thanks! I don't remember exactly what you asked, but don't put yourself down, everybody has to start somewhere :)
- progman 10y ago
  > Lots of small little quirks that weren't greatly documented. For instance? > But most languages are designed to constrain the programmer to a way of thinking, a series of patterns. Lisp was the opposite. Lisp is still the opposite. Exactly this is the problem of Lisp: It is too powerful. I admire Lisp for its power, and there actually is no other language with such a freedom. Everyone can write his own DSL to simplify his task. Writing DSLs is extremely easy in Lisp. However, this doesn't profit maintainability, and it makes sharing code with others difficult. You actually need a lot of discipline that you code in such a way that it remains maintainable. In teams you need to constrain the way of thinking otherwise you can quickly run into chaos. Java is the opposite of Lisp. You cannot code productively in Java unless you use a sophisticated framework. Such frameworks force you to a certain style of coding which profits maintainability. That is one factor which explains the huge success of Java in business. Nim and Rust combine both paradigms. They provide a certain degree of freedom, and they require a certain degree of discipline. Haskell requires an extreme amount of discipline. In case of Haskell's freedom I am not convinced.
  - shakna 10y ago
    > Lots of small little quirks that weren't greatly documented. > For instance? Nimble file naming [0]. It must end in '.nimble', and must have at least character in front of that suffix, but the prefix doesn't actually matter. I'm not convinced on the maintainability argument. Many, many projects have a coding style guide. LISPs require one too. Once you have one, maintaining the code becomes as difficult as any other language. I've encountered unmaintainable Python code [1], and insanely well documented Scheme code [2]. I'm not sure the language has much to do with it, apart from supporting a wide range of paradigms and patterns. I'm not sure black-boxing through use of a sophisticated framework is any better than the way you work in more flexible languages. Here's my take: * Nim is great. The use of the 'auto' keyword let me be productive using it. * Scheme is great. It lets me do insane things, and the compiler will optimise it to work, and well. (Rather than breaking three similar function into pieces, I can make one function that generates all three functions using their commonalities). * Java is the smart kid at college who always answers questions in the form of a thesis. He isn't wrong, but you don't really remember what he was saying. [0] https://github.com/nim-lang/nimble/issues/166 https://github.com/nim-lang/nimble/issues/166 [1] Hence why things like this exist: http://docs.python-guide.org/en/latest/writing/structure/ http://docs.python-guide.org/en/latest/writing/structure/ [2] http://cvs.savannah.gnu.org/viewvc/slib/slib/alist.scm?revision=1.6&view=markup&pathrev=MAIN http://cvs.savannah.gnu.org/viewvc/slib/slib/alist.scm?revis...
KirinDave 10y ago
I don't see how a keyword that allows return values to be ignored creates an incentive to create void functions. I sort of find the idea refreshing myself. As a full time Clojure developer, I consider Nim to be the closest thing I can find to what I want for a great experience coding closer to the bare metal.
- drewr 10y ago
  Can you say more about what you like?
- qwertyuiop924 10y ago
  It's not so much that it allows it to be ignored, it's that if you want it to be ignored, you have to use that keyword. It means that there's syntactic noise in cases where you don't care about the return value of a function that has one, and thus discourages you from writing functions like that.
  - dom96 10y ago
    The idea behind this feature is to ensure that you don't lose important data, not to discourage you from writing functions which return values. For cases where a functions return value is truly optional, you can use the {.discardable.} pragma.
    - qwertyuiop924 10y ago
      Huh. Interesting idea. I suppose that could work. I'm still not wholly convinced that Nim is for me, but you've definitely alleviated some of my biggest concerns.
FraaJad 10y ago
It's hard to please a Lisper about any other language's macro system. So, this is a wash.
- ternaryoperator 10y ago
  It's hard to please a Lisper about any other language's features. FTFY.
  - deleted 10y ago
    [deleted]
  - progman 10y ago
    I disagree. I have written a lot of Lisp and Scheme code, and now I am very content with Nim. I also tried Rust and Haskell but those languages are too cluttering for me. Nim is compact, well readable, powerful and performant. Nim developed from the bottom up, being closely related to C which is nice and makes porting to other platforms easy. The Nim development team adds only features which really make sense. If they just remove those immature ugly features like strong spaces and the redundancy of underscores then Nim 2.0 could be a really great language.
    - qwertyuiop924 10y ago
      OTOH, as a schemer, I much prefer Haskell and Rust to Nim, both theoretically and in practice. What syntax and abstractions you like are down to how you think, and Lisp programmers are programmers like any other, not incarnations of the spirit of smugness, as many people paint us.
      - progman 10y ago
        > What syntax and abstractions you like are down to how you think Obviously this is not only my problem because there are only sparely applications written in Haskell. It is possible to write real world applications in Haskell, as proven by Leksah and the window manager xmonad. However, would you write an MS Office clone in Haskell? I wouldn't. I am still honestly interested in Haskell but I cannot understand why the cabal hell has not been fixed yet. Sandboxes and VMs are no option for me. Rust, Nim, and many other languages don't have this problem which points out that the cabal hell is due to Haskell's nature. Rust is another story. It is way more practical than Haskell, and I would use it for safety and systems programming. Nim however has become my favorite after a long journey of languages because I am really productive with it. Only Lisp has a similar productivity, and sometimes I still use it. Nim has the advantage of being very close to C which makes porting to other platforms extremely easy -- and hence also all my Nim code.
agentgt 10y ago
I have the same problem with almost all new languages including Rust: everything should be an expression and not a statement. Even conditional logic constructs (if/else) should be an expression (i.e. return a value). The language doesn't even have to be pure or hard core FP to follow this philosophy.
- nathancahill 10y ago
  I highly agree, especially about the if/else. The more I code, the more I try to elimante branching. If statements as expressions would be ideal.
  - qznc 10y ago
    Most mainstream languages (C, Java, etc) have this. The ternary operator ?:
    - 35bge57dtjku 10y ago
      That's like farting in the bathtub and calling it a hot tub.
      - tigershark 10y ago
        Why? It is an expression, not a statement regardless of your farting nonsense.
        35bge57dtjku 10y ago
        Because they aren't the same thing.
- hermanradtke 10y ago
  Based on my understanding, Rust is an expressive language. What have you seen that is not expressive?
- captainmuon 10y ago
nnq 10y ago
Imperative code benefits a lot in readability and maintainability if it follows some kind of CQS pattern ( https://en.wikipedia.org/wiki/Command%E2%80%93query_separation https://en.wikipedia.org/wiki/Command%E2%80%93query_separati... , http://martinfowler.com/bliki/CommandQuerySeparation.html http://martinfowler.com/bliki/CommandQuerySeparation.html ). Never used Nim but its `discard` keyword seems to nudge people in this direction. Yeah, looking at it from the perspective an utopical pure functional world this seems as much of an abomination as "out arguments" in C# ...but in real world code things look different :)
- qwertyuiop924 10y ago
  CQS is neat, but return values on imperative functions are really useful. For one thing, it allows you to compress your API, have an action that can be used solely for the side effect, or for the value of that expression. In addition, you can use it to determine success or failure, and other important information about the function.

shakna 10y ago

From my Python background, Nim felt great. However, once I started a reasonably sized project, getting Nim to compile it became difficult. Lots of small little quirks that weren't greatly documented. However, when it did build, it was reasonably fast, and allowed me to tweak the C code when I disagreed with the compiler. Macros were still getting developed, last I played with Nim, but I'm not sure comparing with Lisp is fair. I adore Lisp, and its macros. (Both CL style and Scheme). But most languages are designed to constrain the programmer to a way of thinking, a series of patterns. Lisp was the opposite. Even in languages that try to give the programmer flexibility, they miss the power of Lisp's homoiconity. That being said, I think Nim is trying to find a middle ground between Python's "only one way to do it" and Lisp's "get out of the programmers way". Its a decent language, albeit with a tiny, rather opinionated, development team.

qwertyuiop924 10y ago
They're still in development? Well then, maybe there's hope.
- dom96 10y ago
  The whole language is still in development. If there are things you dislike, like the macros, then please submit some bug reports on Github[1] or talk to us on IRC[2] and Gitter[3]. Ideally, help us improve it by submitting pull requests :) 1 - https://github.com/nim-lang/Nim/issues https://github.com/nim-lang/Nim/issues 2 - irc.freenode.net #nim 3 - https://gitter.im/nim-lang/Nim https://gitter.im/nim-lang/Nim
- shakna 10y ago
  Just a shout out to dom96 below, that guy was awesome when I was blindly fumbling with the language. Snappy responses to Github Issues, with really clear, really polite responses. Even when I was an idiot.
  - dom96 10y ago
    Thanks! I don't remember exactly what you asked, but don't put yourself down, everybody has to start somewhere :)
progman 10y ago
> Lots of small little quirks that weren't greatly documented. For instance? > But most languages are designed to constrain the programmer to a way of thinking, a series of patterns. Lisp was the opposite. Lisp is still the opposite. Exactly this is the problem of Lisp: It is too powerful. I admire Lisp for its power, and there actually is no other language with such a freedom. Everyone can write his own DSL to simplify his task. Writing DSLs is extremely easy in Lisp. However, this doesn't profit maintainability, and it makes sharing code with others difficult. You actually need a lot of discipline that you code in such a way that it remains maintainable. In teams you need to constrain the way of thinking otherwise you can quickly run into chaos. Java is the opposite of Lisp. You cannot code productively in Java unless you use a sophisticated framework. Such frameworks force you to a certain style of coding which profits maintainability. That is one factor which explains the huge success of Java in business. Nim and Rust combine both paradigms. They provide a certain degree of freedom, and they require a certain degree of discipline. Haskell requires an extreme amount of discipline. In case of Haskell's freedom I am not convinced.
- shakna 10y ago
  > Lots of small little quirks that weren't greatly documented. > For instance? Nimble file naming [0]. It must end in '.nimble', and must have at least character in front of that suffix, but the prefix doesn't actually matter. I'm not convinced on the maintainability argument. Many, many projects have a coding style guide. LISPs require one too. Once you have one, maintaining the code becomes as difficult as any other language. I've encountered unmaintainable Python code [1], and insanely well documented Scheme code [2]. I'm not sure the language has much to do with it, apart from supporting a wide range of paradigms and patterns. I'm not sure black-boxing through use of a sophisticated framework is any better than the way you work in more flexible languages. Here's my take: * Nim is great. The use of the 'auto' keyword let me be productive using it. * Scheme is great. It lets me do insane things, and the compiler will optimise it to work, and well. (Rather than breaking three similar function into pieces, I can make one function that generates all three functions using their commonalities). * Java is the smart kid at college who always answers questions in the form of a thesis. He isn't wrong, but you don't really remember what he was saying. [0] https://github.com/nim-lang/nimble/issues/166 https://github.com/nim-lang/nimble/issues/166 [1] Hence why things like this exist: http://docs.python-guide.org/en/latest/writing/structure/ http://docs.python-guide.org/en/latest/writing/structure/ [2] http://cvs.savannah.gnu.org/viewvc/slib/slib/alist.scm?revision=1.6&view=markup&pathrev=MAIN http://cvs.savannah.gnu.org/viewvc/slib/slib/alist.scm?revis...

KirinDave 10y ago

I don't see how a keyword that allows return values to be ignored creates an incentive to create void functions. I sort of find the idea refreshing myself. As a full time Clojure developer, I consider Nim to be the closest thing I can find to what I want for a great experience coding closer to the bare metal.

drewr 10y ago
Can you say more about what you like?
qwertyuiop924 10y ago
It's not so much that it allows it to be ignored, it's that if you want it to be ignored, you have to use that keyword. It means that there's syntactic noise in cases where you don't care about the return value of a function that has one, and thus discourages you from writing functions like that.
- dom96 10y ago
  The idea behind this feature is to ensure that you don't lose important data, not to discourage you from writing functions which return values. For cases where a functions return value is truly optional, you can use the {.discardable.} pragma.
  - qwertyuiop924 10y ago
    Huh. Interesting idea. I suppose that could work. I'm still not wholly convinced that Nim is for me, but you've definitely alleviated some of my biggest concerns.

FraaJad 10y ago

It's hard to please a Lisper about any other language's macro system. So, this is a wash.

ternaryoperator 10y ago
It's hard to please a Lisper about any other language's features. FTFY.
- deleted 10y ago
  [deleted]
- progman 10y ago
  I disagree. I have written a lot of Lisp and Scheme code, and now I am very content with Nim. I also tried Rust and Haskell but those languages are too cluttering for me. Nim is compact, well readable, powerful and performant. Nim developed from the bottom up, being closely related to C which is nice and makes porting to other platforms easy. The Nim development team adds only features which really make sense. If they just remove those immature ugly features like strong spaces and the redundancy of underscores then Nim 2.0 could be a really great language.
  - qwertyuiop924 10y ago
    OTOH, as a schemer, I much prefer Haskell and Rust to Nim, both theoretically and in practice. What syntax and abstractions you like are down to how you think, and Lisp programmers are programmers like any other, not incarnations of the spirit of smugness, as many people paint us.
    - progman 10y ago
      > What syntax and abstractions you like are down to how you think Obviously this is not only my problem because there are only sparely applications written in Haskell. It is possible to write real world applications in Haskell, as proven by Leksah and the window manager xmonad. However, would you write an MS Office clone in Haskell? I wouldn't. I am still honestly interested in Haskell but I cannot understand why the cabal hell has not been fixed yet. Sandboxes and VMs are no option for me. Rust, Nim, and many other languages don't have this problem which points out that the cabal hell is due to Haskell's nature. Rust is another story. It is way more practical than Haskell, and I would use it for safety and systems programming. Nim however has become my favorite after a long journey of languages because I am really productive with it. Only Lisp has a similar productivity, and sometimes I still use it. Nim has the advantage of being very close to C which makes porting to other platforms extremely easy -- and hence also all my Nim code.

agentgt 10y ago

I have the same problem with almost all new languages including Rust: everything should be an expression and not a statement. Even conditional logic constructs (if/else) should be an expression (i.e. return a value). The language doesn't even have to be pure or hard core FP to follow this philosophy.

nathancahill 10y ago
I highly agree, especially about the if/else. The more I code, the more I try to elimante branching. If statements as expressions would be ideal.
- qznc 10y ago
  Most mainstream languages (C, Java, etc) have this. The ternary operator ?:
  - 35bge57dtjku 10y ago
    That's like farting in the bathtub and calling it a hot tub.
    - tigershark 10y ago
      Why? It is an expression, not a statement regardless of your farting nonsense.
      - 35bge57dtjku 10y ago
        Because they aren't the same thing.
hermanradtke 10y ago
Based on my understanding, Rust is an expressive language. What have you seen that is not expressive?
captainmuon 10y ago

nnq 10y ago

Imperative code benefits a lot in readability and maintainability if it follows some kind of CQS pattern ( https://en.wikipedia.org/wiki/Command%E2%80%93query_separation https://en.wikipedia.org/wiki/Command%E2%80%93query_separati... , http://martinfowler.com/bliki/CommandQuerySeparation.html http://martinfowler.com/bliki/CommandQuerySeparation.html ). Never used Nim but its `discard` keyword seems to nudge people in this direction. Yeah, looking at it from the perspective an utopical pure functional world this seems as much of an abomination as "out arguments" in C# ...but in real world code things look different :)

qwertyuiop924 10y ago
CQS is neat, but return values on imperative functions are really useful. For one thing, it allows you to compress your API, have an action that can be used solely for the side effect, or for the value of that expression. In addition, you can use it to determine success or failure, and other important information about the function.