6 ms·

Excellent! Lots of good tips. The `with` syntax is new to me, but it looks useful for dealing with lots of subfields. Its also a good point that while Nim look

Excellent! Lots of good tips. The `with` syntax is new to me, but it looks useful for dealing with lots of subfields. Its also a good point that while Nim looks like Python, it very much isn't. Nim is overall much better designed from a computer science perspective with saner scoping rules, etc, IMHO. That means that while Nim as a language is relatively complex, overall its easier to work with than C++ or even Python which have lots of special cases.

pjmlp 6y ago
Nim is heavily inspired by Wirth languages, where you have the same capabilities to do low level programming, without the traps of C derived languages.
- jstimpfle 6y ago
  Citation required. How can Wirth languages (e.g. Pascal, Modula) have "the same capabilities for low level programming", but without the traps, of C derived languages (e.g. C, C++)? The idea suggests itself that you can have one or the other, but not both. Personally from trying it out, I like the speed resulting from the stricter module system. And there might be a little additional protection against bad builds resulting from it. But I assume it comes at a price in flexibility as well - I can't really tell since I quit after working 6 months in it.
  - deleted 6y ago
    [deleted]
  - wffurr 6y ago
    Undefined behavior and null terminated strings with the attendant buffer overflows are not fundamental constants of low level programming; they’re implementation details of C. Rusty (and Nim, Modula, Pascal, Ada, etc.) show that it’s perfectly possible to write low-level code with zero-cost abstractions without “unsafe by default” programming languages like C.
    - jstimpfle 6y ago
      > Undefined behavior UB in C has some unfortunate historic problems, and is _probably_ way too complicated. But UB per se is needed for a number of really important optimizations - for example, for array indexing using 32-bit integers you need to be able to assume that index-scaling operations (implemented as multiplications/shifts) don't overflow. > null terminated strings null terminated strings are like 10-50% space savers compared to string + length tuples for realistic strings (which are small). They're also easy to pass around and require no bikeshedding what's the best string type. You can easily make your own type if you want (struct String { const char *buffer; int length; }) or you can just use C++ and one of the more terrible full featured string types with all sorts of badly matching built-in memory management and what not. (By the way, the issue with SetLength() that I described in my other comment applies to Pascal Strings, too) (Oh, and Pascal/Delphi also wants you to choose between PChar, String, AnsiString, WideString and what not, and for every little thing you're doing you need to locate and use the proper API for whatever string type you've chosen. Or you need to do conversions before the calls, with all the necessary implicit memory allocations. Enjoy!) (Oh, this is basically how I achieved a 100x-1000x speedup in a module of a business application in a short Delphi stint. I converted the string data to chunk-allocated bytes with manually computed indexing - instead of allocating thousands of little strings and throwing them back and forth. That reduced the total application startup time (including a lot of code that I never touched) from minutes (in some cases) to something bearable (1-5 secs). > with the attendant buffer overflows are not fundamental constants of low level programming Of course they are. If you're not controlling bytes directly, and deciding about data layout and tradeoffs, I wouldn't call that low-level programming. YMMV. But - while my code is never fuzzed - it's been years since I've been bitten by a string bug. The importance of this stuff is way overblown, and knowledge and experience how to program with simple data structures is only found in more obscure corners of the internet. Also, very little in systems programming is about strings.
      - wffurr 6y ago
        Optimization war stories aside (which is cool, thank you!), this reads like the classic apologetics "C is fine if you just use it correctly". Whereas in practice large C and C++ projects and libraries regularly suffer from severe security vulnerabilities exploited in the wild specifically from buffer overflows and use-after-free bugs.
  - pjmlp 6y ago
    Has answered multiple times, including to your previous comments. - bounds checking enabled by default for arrays and strings - real enumerations that aren't implicit converted into numeric types (fixed in C++11, if one bothers to use enum classes) - enumerations can be used as indexes (C++ can work around this with enum classes and some boilerplate templates) - most data conversions must be done explicitly - ability to actually define subtypes that are enforced by the type system (C++ offers this, provided one does the required boilerplate class/template code) - memory allocation by default doesn't require doing math with data sizes (C++ as well, yet there is too much malloc()/free() pollution in C++ code bases) - no need to deal with pointers for out parameters, thanks reference parameters, which even in C++ there isn't any guarantee they aren't null, even though that would actually trigger UB) - in some of the dialects, namely Modula-2 and Oberon and the languages derived from them, unsafe code requires explicit import of SYSTEM package - if one wants to do crazy C like code, all the necessary gear is available, pragmas to turn off bounds checking, pointer arithmetic, unchecked casts, unions, mapping variables to explicit memory addresses, pointers to callbacks, it is everything there in the package. The original bare bones ISO Pascal wasn't no longer relevant in the mid-80's, unless the teacher didn't knew any better. In fact, IBM i, z/OS and Unisys ClearPath have done pretty well with PL/S, PL.8 and NEWP, only adding support for C and C++ after the market started to care about POSIX support on mainframes.
    - jstimpfle 6y ago
      > bounds checking enabled by default for arrays and strings You can make your own explicit bounds checks, or you can use valgrind (which, just like any type system, can understand only simple situations). You can use C++ which actually does allow you to do bounds checking by default, if you're into such things. > - real enumerations that aren't implicit converted into numeric types (fixed in C++11, if one bothers to use enum classes) > - enumerations can be used as indexes (C++ can work around this with enum classes and some boilerplate templates) > - ability to actually define subtypes that are enforced by the type system (C++ offers this, provided one does the required boilerplate class/template code) These are total non-issues in practice, since treating them as integers is usually what you want (you almost always want to support some light arithmetic on them, you want to store sentinel values sometimes...). Furthermore (as you say) C++ allows you to treat them as separate types. > most data conversions must be done explicitly This is the same with C, except for integral types where though you need to turn on warnings to avoid implicit downcasts of integral types with some (most?) compilers. For upcasts, implicit is what you want. > memory allocation by default doesn't require doing math with data sizes (C++ as well, yet there is too much malloc()/free() pollution in C++ code bases) That's FUD, if you do memory allocation - of course you need to compute the number of bytes you need. If you do "new Foo[count]" you're likely doing it wrong anyway, just like if you're calling malloc directly. To equate memory allocation with malloc (or syntax sugar in fancy object languages) is WRONG. malloc() is a stupid default allocator, and you don't know what allocator you're getting if you don't provide your own. Good system performance often requires writing (simple) custom allocators instead of using malloc which has to deal with random allocation sizes, allocation patterns, and multiple threads. Whether using your own allocator or not, it shouldn't be too much to expect you to write a single line like: #define ALLOCATE(type, count) ((type *) do_alloc(sizeof (type), (count))) Or even #define ALLOCATE(ptr, count) (ptr = do_alloc(sizeof *(ptr), (count)) Now tell me, why exactly is "new Foo[count]" safer than "ALLOCATE(Foo, count)"? Or just do this minimal boilerplate by hand, this is not a practical issue unless your code is very badly factored (good code requires only few allocations). > no need to deal with pointers for out parameters, thanks reference parameters, which even in C++ there isn't any guarantee they aren't null, even though that would actually trigger UB) This is not a problem at all in practice, and anyway, if you need a lot of that you're doing something wrong. I very much like that C keeps it simple and you always see what happens. This is unlike Pascal and its Objects extensions, where it's impossible to see which data you're actually mutating because there are like 10 different "adressing modes". For example, dynamic arrays in Pascal can be assigned to other variables (or passed through a function parameter), and they will share memory, but only until one calls SetLength() on one "reference" at which point a Copy-on-Write is happening and they split lifes. This is not only not useful but extremely confusing. And the whole object extensions to Pascal (I can speak for Delphi) are built in that way - trying to not let the user see the complexity of what they're doing - which works until it doesn't, which is when you're dealing with extremely difficult to debug problems. Frankly Delphi ecosystem is a mess because it's a set of layers where each time they tried to be clever and add another philosophy-driven set of classes with implicit behaviours on top that was supposed to fix the previous layer's mistakes. > - if one wants to do crazy C like code, all the necessary gear is available, pragmas to turn off bounds checking, pointer arithmetic, unchecked casts, unions, mapping variables to explicit memory addresses, pointers to callbacks, it is everything there in the package. The original bare bones ISO Pascal wasn't no longer relevant in the mid-80's, unless the teacher didn't knew any better. This is why I took issue - you can't have both low-level bit twidding and "memory safe" programming. At most you can have a language that lets you choose between one or the other in a rather integrated system, but then you're still dealing with this abstraction gap, and having to traverse it constantly is not pleasant.
  - atombender 6y ago
    I'm not sure why any "citation" is needed here. C is widely accepted as being deeply unsafe language, and C++ has inherited those traits, and is still working on plugging the weaknesses some 35 years later. Of course you can do things like bounds checking manually in C, and run with all sorts of warnings enabled, and you can use static code analyzers that uncover entie classes of bugs, but the whole point is to never get that far in the first place. I worked with Borland's Pascal dialect for 10+ years, and it offered a great deal of protections while still allowing you to use unsafe constructs when you needed to get close to the metal (e.g. pointer arithmetic and even embedded assembly code). But "safe by default" solves a lot of problems.
    - jstimpfle 6y ago
      Pascal's low-level semantics are comparable to C's. That's why I dispute that it doesn't have the same traps. I agree that if you program C by emulating higher-level object systems, it becomes unmanageable and a lot of bugs around object lifetimes appear, and they're very hard to fix. I personally don't have a great interest in such object systems, but fail to see how C++ should be any worse than Pascal in terms of perceived safety resulting from the higher level of abstraction.
    - blackrock 6y ago
      The problem that I see with Nim, is that it transpiles down to C. So, does it mean, that Nim can inherit these unsafe behaviors of C? Or did the Nim language creators safely avoid the pitfalls of C? Whereas a language like Zig and Rust, compiles its code down to LLVM.
      - pjmlp 6y ago
        That is an implementation detail, nothing prevents a future release of Nim compiler to directly generate machine code.
        blackrock 6y ago
        Fascinating. When will they do it? I would prefer it generate direct machine code instead.
masklinn 6y ago
> The `with` syntax is new to me, but it looks useful for dealing with lots of subfields. It's not syntax, but rather a third-party macro[0], which it should be noted is inspired by a rather horrible feature of the same name in javascript. Though I guess the devil would be in the details. [0] https://github.com/zevv/with https://github.com/zevv/with
- zevv 6y ago
  And I'm not even ashamed!
  - elcritch 6y ago
    Thanks @masklin for pointing that out -- sloppy language on my side, but I also didn't realize it was a third party library. Thanks @zevv for the macro!
- akavel 6y ago
  There's also stdlib's with (https://nim-lang.org/docs/with.html https://nim-lang.org/docs/with.html), though for some reasons I'm not aware of it doesn't seem listed in the stdlib's ToC :/
mhh__ 6y ago
https://dlang.org/spec/statement.html#WithStatement https://dlang.org/spec/statement.html#WithStatement D also has withs. Definitely in the "not necessary but nice to have" category of features, particularly when implementing state machines (i.e. statment soup)
- planetis 6y ago
  We have like 5 different `with` macros including one in stdlib.
  - mhh__ 6y ago
    I assume "We"=Nim? It's an interesting pattern to test language designs with. On the one hand expressive macros can be disastrous in big codebases, on the other hand a more "monadic" (implemented via passing some kind of object through a chain rather than algebraically) way is very template-intensive.
    - cb321 6y ago
      At least one (very bottom of [1]) of the 5+ variants makes you list which fields the code gets access to (in a tiny 6 line Nim macro). That is an alternate, perhaps more keystroke-heavy solution to the problem bothering @simias. [1] https://github.com/c-blake/cligen/blob/master/cligen/macUt.nim https://github.com/c-blake/cligen/blob/master/cligen/macUt.n...
- simias 6y ago
  I seem to be in the minority but I really dislike this type of sugar. I find that it always makes code harder to read because you can't disambiguate what the code is doing without some heavy context, and changes to the class can profoundly change the way the code is behaving without triggering as much as a warning. For this same reason I really dislike that in C++ you can just implicitly drop the "this->" to target class members. You can never tell at a glance what "foo = blah" does if you don't know whether "foo" is a member of "this" or not. I think your page demonstrates what I mean in the "nested WithStatement" example: Foo foo; Bar bar; Baz baz; f(); // prints "f" with(foo) { f(); // prints "Foo.f" with(bar) { f(); // prints "Bar.f" with(baz) { f(); // prints "Bar.f". `Baz` does not implement `f()` so // resolution is forwarded to `with(bar)`'s scope } } with(baz) { f(); // prints "Foo.f". `Baz` does not implement `f()` so // resolution is forwarded to `with(foo)`'s scope } } with(baz) { f(); // prints "f". `Baz` does not implement `f()` so // resolution is forwarded to `main`'s scope. `f()` is // not implemented in `main`'s scope, so resolution is // subsequently forward to module scope. } Wi I get that sometimes it can cut on a lot of repetition, but I think I would be fine if the syntax was more explicit while still avoiding repetition, for instance: with (some_object) { .some_member = 1; .some_other = 4; not_a_member = .some_method(); } And beyond that make it non nestable (i.e. only the first level of "with" is taken into account) to avoid the situation above with complicated overloading. In my experience that would account for 99% of uses of `with` while making the code a lot more readable without requiring a lot of context to make sense of it. Although frankly even that might arguably overkill, for dynamic languages or ones with type inference you might as well just do something like: { let v = &mut some_annoyingly.long.thing(); v.foo = bar; v.baz(); } It's almost the same amount of typing and you don't need any magic.
beagle3 6y ago
Nim is a huge language, but it is very well designed, and unlike e.g. C++, you can use and discover its feature gradually - including when using 3rd party libraries. It has lispy macros (except reader macros - you start with a parsed-to-ast text), closures, effect tracking, C/C++ level performance &interop and a lot more - but somehow, somewhat by language design and somewhat by community standards, you don't need to fully understand these things (and hardly to be aware of them) when writing your own Nim code or when using 3rd party libraries. (Whereas in C++, you can pick your own subset for your own code, but as soon as you pull in a 3rd party library, you HAVE to understand the preprocessor, templates, often template metaprogramming, lambda capture rules if that library is built for them, etc).

pjmlp 6y ago

Nim is heavily inspired by Wirth languages, where you have the same capabilities to do low level programming, without the traps of C derived languages.

jstimpfle 6y ago
Citation required. How can Wirth languages (e.g. Pascal, Modula) have "the same capabilities for low level programming", but without the traps, of C derived languages (e.g. C, C++)? The idea suggests itself that you can have one or the other, but not both. Personally from trying it out, I like the speed resulting from the stricter module system. And there might be a little additional protection against bad builds resulting from it. But I assume it comes at a price in flexibility as well - I can't really tell since I quit after working 6 months in it.
- deleted 6y ago
  [deleted]
- wffurr 6y ago
  Undefined behavior and null terminated strings with the attendant buffer overflows are not fundamental constants of low level programming; they’re implementation details of C. Rusty (and Nim, Modula, Pascal, Ada, etc.) show that it’s perfectly possible to write low-level code with zero-cost abstractions without “unsafe by default” programming languages like C.
  - jstimpfle 6y ago
    > Undefined behavior UB in C has some unfortunate historic problems, and is _probably_ way too complicated. But UB per se is needed for a number of really important optimizations - for example, for array indexing using 32-bit integers you need to be able to assume that index-scaling operations (implemented as multiplications/shifts) don't overflow. > null terminated strings null terminated strings are like 10-50% space savers compared to string + length tuples for realistic strings (which are small). They're also easy to pass around and require no bikeshedding what's the best string type. You can easily make your own type if you want (struct String { const char *buffer; int length; }) or you can just use C++ and one of the more terrible full featured string types with all sorts of badly matching built-in memory management and what not. (By the way, the issue with SetLength() that I described in my other comment applies to Pascal Strings, too) (Oh, and Pascal/Delphi also wants you to choose between PChar, String, AnsiString, WideString and what not, and for every little thing you're doing you need to locate and use the proper API for whatever string type you've chosen. Or you need to do conversions before the calls, with all the necessary implicit memory allocations. Enjoy!) (Oh, this is basically how I achieved a 100x-1000x speedup in a module of a business application in a short Delphi stint. I converted the string data to chunk-allocated bytes with manually computed indexing - instead of allocating thousands of little strings and throwing them back and forth. That reduced the total application startup time (including a lot of code that I never touched) from minutes (in some cases) to something bearable (1-5 secs). > with the attendant buffer overflows are not fundamental constants of low level programming Of course they are. If you're not controlling bytes directly, and deciding about data layout and tradeoffs, I wouldn't call that low-level programming. YMMV. But - while my code is never fuzzed - it's been years since I've been bitten by a string bug. The importance of this stuff is way overblown, and knowledge and experience how to program with simple data structures is only found in more obscure corners of the internet. Also, very little in systems programming is about strings.
    - wffurr 6y ago
      Optimization war stories aside (which is cool, thank you!), this reads like the classic apologetics "C is fine if you just use it correctly". Whereas in practice large C and C++ projects and libraries regularly suffer from severe security vulnerabilities exploited in the wild specifically from buffer overflows and use-after-free bugs.
- pjmlp 6y ago
  Has answered multiple times, including to your previous comments. - bounds checking enabled by default for arrays and strings - real enumerations that aren't implicit converted into numeric types (fixed in C++11, if one bothers to use enum classes) - enumerations can be used as indexes (C++ can work around this with enum classes and some boilerplate templates) - most data conversions must be done explicitly - ability to actually define subtypes that are enforced by the type system (C++ offers this, provided one does the required boilerplate class/template code) - memory allocation by default doesn't require doing math with data sizes (C++ as well, yet there is too much malloc()/free() pollution in C++ code bases) - no need to deal with pointers for out parameters, thanks reference parameters, which even in C++ there isn't any guarantee they aren't null, even though that would actually trigger UB) - in some of the dialects, namely Modula-2 and Oberon and the languages derived from them, unsafe code requires explicit import of SYSTEM package - if one wants to do crazy C like code, all the necessary gear is available, pragmas to turn off bounds checking, pointer arithmetic, unchecked casts, unions, mapping variables to explicit memory addresses, pointers to callbacks, it is everything there in the package. The original bare bones ISO Pascal wasn't no longer relevant in the mid-80's, unless the teacher didn't knew any better. In fact, IBM i, z/OS and Unisys ClearPath have done pretty well with PL/S, PL.8 and NEWP, only adding support for C and C++ after the market started to care about POSIX support on mainframes.
  - jstimpfle 6y ago
    > bounds checking enabled by default for arrays and strings You can make your own explicit bounds checks, or you can use valgrind (which, just like any type system, can understand only simple situations). You can use C++ which actually does allow you to do bounds checking by default, if you're into such things. > - real enumerations that aren't implicit converted into numeric types (fixed in C++11, if one bothers to use enum classes) > - enumerations can be used as indexes (C++ can work around this with enum classes and some boilerplate templates) > - ability to actually define subtypes that are enforced by the type system (C++ offers this, provided one does the required boilerplate class/template code) These are total non-issues in practice, since treating them as integers is usually what you want (you almost always want to support some light arithmetic on them, you want to store sentinel values sometimes...). Furthermore (as you say) C++ allows you to treat them as separate types. > most data conversions must be done explicitly This is the same with C, except for integral types where though you need to turn on warnings to avoid implicit downcasts of integral types with some (most?) compilers. For upcasts, implicit is what you want. > memory allocation by default doesn't require doing math with data sizes (C++ as well, yet there is too much malloc()/free() pollution in C++ code bases) That's FUD, if you do memory allocation - of course you need to compute the number of bytes you need. If you do "new Foo[count]" you're likely doing it wrong anyway, just like if you're calling malloc directly. To equate memory allocation with malloc (or syntax sugar in fancy object languages) is WRONG. malloc() is a stupid default allocator, and you don't know what allocator you're getting if you don't provide your own. Good system performance often requires writing (simple) custom allocators instead of using malloc which has to deal with random allocation sizes, allocation patterns, and multiple threads. Whether using your own allocator or not, it shouldn't be too much to expect you to write a single line like: #define ALLOCATE(type, count) ((type *) do_alloc(sizeof (type), (count))) Or even #define ALLOCATE(ptr, count) (ptr = do_alloc(sizeof *(ptr), (count)) Now tell me, why exactly is "new Foo[count]" safer than "ALLOCATE(Foo, count)"? Or just do this minimal boilerplate by hand, this is not a practical issue unless your code is very badly factored (good code requires only few allocations). > no need to deal with pointers for out parameters, thanks reference parameters, which even in C++ there isn't any guarantee they aren't null, even though that would actually trigger UB) This is not a problem at all in practice, and anyway, if you need a lot of that you're doing something wrong. I very much like that C keeps it simple and you always see what happens. This is unlike Pascal and its Objects extensions, where it's impossible to see which data you're actually mutating because there are like 10 different "adressing modes". For example, dynamic arrays in Pascal can be assigned to other variables (or passed through a function parameter), and they will share memory, but only until one calls SetLength() on one "reference" at which point a Copy-on-Write is happening and they split lifes. This is not only not useful but extremely confusing. And the whole object extensions to Pascal (I can speak for Delphi) are built in that way - trying to not let the user see the complexity of what they're doing - which works until it doesn't, which is when you're dealing with extremely difficult to debug problems. Frankly Delphi ecosystem is a mess because it's a set of layers where each time they tried to be clever and add another philosophy-driven set of classes with implicit behaviours on top that was supposed to fix the previous layer's mistakes. > - if one wants to do crazy C like code, all the necessary gear is available, pragmas to turn off bounds checking, pointer arithmetic, unchecked casts, unions, mapping variables to explicit memory addresses, pointers to callbacks, it is everything there in the package. The original bare bones ISO Pascal wasn't no longer relevant in the mid-80's, unless the teacher didn't knew any better. This is why I took issue - you can't have both low-level bit twidding and "memory safe" programming. At most you can have a language that lets you choose between one or the other in a rather integrated system, but then you're still dealing with this abstraction gap, and having to traverse it constantly is not pleasant.
- atombender 6y ago
  I'm not sure why any "citation" is needed here. C is widely accepted as being deeply unsafe language, and C++ has inherited those traits, and is still working on plugging the weaknesses some 35 years later. Of course you can do things like bounds checking manually in C, and run with all sorts of warnings enabled, and you can use static code analyzers that uncover entie classes of bugs, but the whole point is to never get that far in the first place. I worked with Borland's Pascal dialect for 10+ years, and it offered a great deal of protections while still allowing you to use unsafe constructs when you needed to get close to the metal (e.g. pointer arithmetic and even embedded assembly code). But "safe by default" solves a lot of problems.
  - jstimpfle 6y ago
    Pascal's low-level semantics are comparable to C's. That's why I dispute that it doesn't have the same traps. I agree that if you program C by emulating higher-level object systems, it becomes unmanageable and a lot of bugs around object lifetimes appear, and they're very hard to fix. I personally don't have a great interest in such object systems, but fail to see how C++ should be any worse than Pascal in terms of perceived safety resulting from the higher level of abstraction.
  - blackrock 6y ago
    The problem that I see with Nim, is that it transpiles down to C. So, does it mean, that Nim can inherit these unsafe behaviors of C? Or did the Nim language creators safely avoid the pitfalls of C? Whereas a language like Zig and Rust, compiles its code down to LLVM.
    - pjmlp 6y ago
      That is an implementation detail, nothing prevents a future release of Nim compiler to directly generate machine code.
      - blackrock 6y ago
        Fascinating. When will they do it? I would prefer it generate direct machine code instead.

masklinn 6y ago

> The `with` syntax is new to me, but it looks useful for dealing with lots of subfields. It's not syntax, but rather a third-party macro[0], which it should be noted is inspired by a rather horrible feature of the same name in javascript. Though I guess the devil would be in the details. [0] https://github.com/zevv/with https://github.com/zevv/with

zevv 6y ago
And I'm not even ashamed!
- elcritch 6y ago
  Thanks @masklin for pointing that out -- sloppy language on my side, but I also didn't realize it was a third party library. Thanks @zevv for the macro!
akavel 6y ago
There's also stdlib's with (https://nim-lang.org/docs/with.html https://nim-lang.org/docs/with.html), though for some reasons I'm not aware of it doesn't seem listed in the stdlib's ToC :/

mhh__ 6y ago

https://dlang.org/spec/statement.html#WithStatement https://dlang.org/spec/statement.html#WithStatement D also has withs. Definitely in the "not necessary but nice to have" category of features, particularly when implementing state machines (i.e. statment soup)

planetis 6y ago
We have like 5 different `with` macros including one in stdlib.
- mhh__ 6y ago
  I assume "We"=Nim? It's an interesting pattern to test language designs with. On the one hand expressive macros can be disastrous in big codebases, on the other hand a more "monadic" (implemented via passing some kind of object through a chain rather than algebraically) way is very template-intensive.
  - cb321 6y ago
    At least one (very bottom of [1]) of the 5+ variants makes you list which fields the code gets access to (in a tiny 6 line Nim macro). That is an alternate, perhaps more keystroke-heavy solution to the problem bothering @simias. [1] https://github.com/c-blake/cligen/blob/master/cligen/macUt.nim https://github.com/c-blake/cligen/blob/master/cligen/macUt.n...
simias 6y ago
I seem to be in the minority but I really dislike this type of sugar. I find that it always makes code harder to read because you can't disambiguate what the code is doing without some heavy context, and changes to the class can profoundly change the way the code is behaving without triggering as much as a warning. For this same reason I really dislike that in C++ you can just implicitly drop the "this->" to target class members. You can never tell at a glance what "foo = blah" does if you don't know whether "foo" is a member of "this" or not. I think your page demonstrates what I mean in the "nested WithStatement" example: Foo foo; Bar bar; Baz baz; f(); // prints "f" with(foo) { f(); // prints "Foo.f" with(bar) { f(); // prints "Bar.f" with(baz) { f(); // prints "Bar.f". `Baz` does not implement `f()` so // resolution is forwarded to `with(bar)`'s scope } } with(baz) { f(); // prints "Foo.f". `Baz` does not implement `f()` so // resolution is forwarded to `with(foo)`'s scope } } with(baz) { f(); // prints "f". `Baz` does not implement `f()` so // resolution is forwarded to `main`'s scope. `f()` is // not implemented in `main`'s scope, so resolution is // subsequently forward to module scope. } Wi I get that sometimes it can cut on a lot of repetition, but I think I would be fine if the syntax was more explicit while still avoiding repetition, for instance: with (some_object) { .some_member = 1; .some_other = 4; not_a_member = .some_method(); } And beyond that make it non nestable (i.e. only the first level of "with" is taken into account) to avoid the situation above with complicated overloading. In my experience that would account for 99% of uses of `with` while making the code a lot more readable without requiring a lot of context to make sense of it. Although frankly even that might arguably overkill, for dynamic languages or ones with type inference you might as well just do something like: { let v = &mut some_annoyingly.long.thing(); v.foo = bar; v.baz(); } It's almost the same amount of typing and you don't need any magic.

beagle3 6y ago

Nim is a huge language, but it is very well designed, and unlike e.g. C++, you can use and discover its feature gradually - including when using 3rd party libraries. It has lispy macros (except reader macros - you start with a parsed-to-ast text), closures, effect tracking, C/C++ level performance &interop and a lot more - but somehow, somewhat by language design and somewhat by community standards, you don't need to fully understand these things (and hardly to be aware of them) when writing your own Nim code or when using 3rd party libraries. (Whereas in C++, you can pick your own subset for your own code, but as soon as you pull in a 3rd party library, you HAVE to understand the preprocessor, templates, often template metaprogramming, lambda capture rules if that library is built for them, etc).