7 ms·

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

by FraaJad 10y ago

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.
      - qwertyuiop924 10y ago
        True enough about Haskell. As for Rust, as awkward as it can be at times, it feels more pleasant than Nim to me much of the time.
        progman 10y ago
        Rust is an awesome language. It has the power to replace C++ and Java as industry standard. However, there are three points which annoy me. First, the Rust compiler is huge (LLVM based). Second, it requires a native Rust compiler for bootstrap. Third, it doesn't compile to C which makes porting to other platforms difficult. Nim doesn't have these problems. It is small, self-hosting, and easily portable.
        qwertyuiop924 10y ago
        That's true, but Rust and its compiler components are fairly well ported, LLVM's going to be near the top of the porting list for any new architecture, and processors are almost a monoculture at this point.
        pcwalton 10y ago
        > Third, it doesn't compile to C which makes porting to other platforms difficult. Not compiling to C is a feature. It insulates us from the undefined behavior of C (signed overflow never results in UB in Rust, for example) and allows us to actually get proper debug info.
        Araq 10y ago
        Compiling to C vs using LLVM is a complex design tradeoff. For example, the Posix standard specifies a C interface. Quote: "The stat structure shall contain at least the following members..." This means you can wrap 'struct stat' in Nim once and be done with it (since the mapping to C is by generating C code) whereas for eg Rust you need to wrap it once for every different OS (and potentially even for every OS version+CPU combination), since the offsets and sizes can differ. So yes, porting to other platforms really is easier when you have a C code generator.
  - dom96 10y ago
    > If they just remove those immature ugly features like strong spaces Strong spaces are already gone.
    - progman 10y ago
      That's good news, thanks!
qwertyuiop924 10y ago
Yes, but Nim's macro system, while very powerful, is, at present, the most clumsy and awkward thing I've seen. it's imperative, like Lisp macros. However, unlike Lisp macros, there are no templates, and the datastructure that Nim's macros manipulate is much closer to the actual AST, and thus far more complex. Because of this, Nim macros must clumsily plug together an AST, and do so in a manner that's so noisy that you have to squint to see what it's actually doing by the time you're done. Meanwhile, Lisp macros are not necessarily shorter, but it's far easier to see what's going on.
- mrkgnao 10y ago
  > much closer to the actual AST I thought Lisp code was its own AST, although I don't really know much about Lisp.
  - qwertyuiop924 10y ago
    Many people claim that, but no Lisp compiler or interpreter beyond toy level actually uses it as such: It doesn't provide a lot of the syntactic information compilers need. However, Lisp code as AST is an excellent abstraction for macros, so that's what macros manipulate.
- progman 10y ago
  > However, unlike Lisp macros, there are no templates That's wrong. Nim has both macros and templates. > Lisp macros are not necessarily shorter, but it's far easier to see what's going on. Even Lisp macros are not perfect. You always have to care for new symbol names where the lexical scope could be affected.
  - qwertyuiop924 10y ago
    Yes, but Nim doesn't have imperative templates, so its template system is fairly limited. As for hygene problems, Nim's system has the same issues. Here's an example of the problem: This is a simple Nim macro from the tutorial: macro debug(n: varargs[expr]): stmt = result = newNimNode(nnkStmtList, n) for x in n: result.add(newCall("write", newIdentNode("stdout"), toStrLit(x))) result.add(newCall("write", newIdentNode("stdout"), newStrLitNode(": "))) result.add(newCall("writeLine", newIdentNode("stdout"), x)) What the heck is that doing? Now let's compare to my lisp of choice, Chicken Scheme (although this macro would be much the same in any Lisp with imperative macros) (define-syntax debug (ir-macro-transformer (lambda (x i c) (let ((exprs (cdr x))) (cons 'begin (map (lambda (expr) `(begin (write (quote ,expr)) (display " : ") (display ,expr) (display "\n"))) exprs)))))) Now see, that's much clearer. And before you ask, yes, this macro is completely hygenic, because it uses ir-macro-transformer. Don't worry too much about it if you're not familliar with Chicken Scheme. It's not the important part.

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

by 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.
    - qwertyuiop924 10y ago
      True enough about Haskell. As for Rust, as awkward as it can be at times, it feels more pleasant than Nim to me much of the time.
      - progman 10y ago
        Rust is an awesome language. It has the power to replace C++ and Java as industry standard. However, there are three points which annoy me. First, the Rust compiler is huge (LLVM based). Second, it requires a native Rust compiler for bootstrap. Third, it doesn't compile to C which makes porting to other platforms difficult. Nim doesn't have these problems. It is small, self-hosting, and easily portable.
        qwertyuiop924 10y ago
        That's true, but Rust and its compiler components are fairly well ported, LLVM's going to be near the top of the porting list for any new architecture, and processors are almost a monoculture at this point.
        pcwalton 10y ago
        > Third, it doesn't compile to C which makes porting to other platforms difficult. Not compiling to C is a feature. It insulates us from the undefined behavior of C (signed overflow never results in UB in Rust, for example) and allows us to actually get proper debug info.
        Araq 10y ago
        Compiling to C vs using LLVM is a complex design tradeoff. For example, the Posix standard specifies a C interface. Quote: "The stat structure shall contain at least the following members..." This means you can wrap 'struct stat' in Nim once and be done with it (since the mapping to C is by generating C code) whereas for eg Rust you need to wrap it once for every different OS (and potentially even for every OS version+CPU combination), since the offsets and sizes can differ. So yes, porting to other platforms really is easier when you have a C code generator.
- dom96 10y ago
  > If they just remove those immature ugly features like strong spaces Strong spaces are already gone.
  - progman 10y ago
    That's good news, thanks!

qwertyuiop924 10y ago

Yes, but Nim's macro system, while very powerful, is, at present, the most clumsy and awkward thing I've seen. it's imperative, like Lisp macros. However, unlike Lisp macros, there are no templates, and the datastructure that Nim's macros manipulate is much closer to the actual AST, and thus far more complex. Because of this, Nim macros must clumsily plug together an AST, and do so in a manner that's so noisy that you have to squint to see what it's actually doing by the time you're done. Meanwhile, Lisp macros are not necessarily shorter, but it's far easier to see what's going on.

mrkgnao 10y ago
> much closer to the actual AST I thought Lisp code was its own AST, although I don't really know much about Lisp.
- qwertyuiop924 10y ago
  Many people claim that, but no Lisp compiler or interpreter beyond toy level actually uses it as such: It doesn't provide a lot of the syntactic information compilers need. However, Lisp code as AST is an excellent abstraction for macros, so that's what macros manipulate.
progman 10y ago
> However, unlike Lisp macros, there are no templates That's wrong. Nim has both macros and templates. > Lisp macros are not necessarily shorter, but it's far easier to see what's going on. Even Lisp macros are not perfect. You always have to care for new symbol names where the lexical scope could be affected.
- qwertyuiop924 10y ago
  Yes, but Nim doesn't have imperative templates, so its template system is fairly limited. As for hygene problems, Nim's system has the same issues. Here's an example of the problem: This is a simple Nim macro from the tutorial: macro debug(n: varargs[expr]): stmt = result = newNimNode(nnkStmtList, n) for x in n: result.add(newCall("write", newIdentNode("stdout"), toStrLit(x))) result.add(newCall("write", newIdentNode("stdout"), newStrLitNode(": "))) result.add(newCall("writeLine", newIdentNode("stdout"), x)) What the heck is that doing? Now let's compare to my lisp of choice, Chicken Scheme (although this macro would be much the same in any Lisp with imperative macros) (define-syntax debug (ir-macro-transformer (lambda (x i c) (let ((exprs (cdr x))) (cons 'begin (map (lambda (expr) `(begin (write (quote ,expr)) (display " : ") (display ,expr) (display "\n"))) exprs)))))) Now see, that's much clearer. And before you ask, yes, this macro is completely hygenic, because it uses ir-macro-transformer. Don't worry too much about it if you're not familliar with Chicken Scheme. It's not the important part.