5 ms·

Great write-up! I expected this to reference a few "normal" language features like static typing, operator overloading, or generics, but instead it was a list o

by benhoyt 12y ago

Great write-up! I expected this to reference a few "normal" language features like static typing, operator overloading, or generics, but instead it was a list of some really neat off-the-beaten-track features: * Run regular code at compile time * Extend the language (AST templates and macros); this can be used to add a form of list comprehensions to the language! * Add your own optimizations to the compiler! * Bind (easily) to your favorite C functions and libraries * Control when and for how long the garbage collector runs * Type safe sets and arrays of enums; this was cool: "Internally the set works as an efficient bitvector." * Unified Call Syntax, so mystr.len() is equivalent to len(mystr) * Good performance -- not placing too much emphasis on this, but it's faster than C++ in his benchmark * Compile to JavaScript

sillysaurus3 12y ago
Everything old is new again.
- benhoyt 12y ago
  Care to flesh that out a bit?
  - dingdingdang 12y ago
    Ah, yes, I remember back in 1959 when we all was rocking the Cobol and I used to auto compile straight to Javascript with a Future module so magnificent that it auto-compile-manifested a V8 JS engine with which to run it. Deal with that boring Nim compiler.
  - sillysaurus3 12y ago
    When I saw that the top comment is a list of language features which are mostly extremely old, I thought that was interesting, so I pointed out how old those features are. And got hammered for it in spite of the fact that it's true. Obviously, it doesn't matter whether those features are old or new. What matters is whether the language executes them in a compelling way. But almost every single one of those features has been a core aspect of programming languages which have been around since before most of us were born. Also, the mods have strongly urged me to write shorter comments, and to write comments less frequently. And they've suggested that more than once. I try to oblige, and this is the result. So technically I can't flesh out my comments without going against their advice. Of that list of nine features, I'm certain six are extremely old: * Run regular code at compile time * Extend the language (AST templates and macros); this can be used to add a form of list comprehensions to the language! * Add your own optimizations to the compiler! * Bind (easily) to your favorite C functions and libraries * Unified Call Syntax, so mystr.len() is equivalent to len(mystr) * Good performance -- not placing too much emphasis on this, but it's faster than C++ in his benchmark I wouldn't be surprised if GC control and typesafe enums are also extremely old, bringing that up to "8 out of 9 features are old." But it's at least 6 out of 9.
    - zahary 12y ago
      Well, you have to combine just two of these features to leave Nim in a very small company of languages, mostly developed in the last decade. Good performance and meta-programming ("run regular code at compile time") used to be found at the opposite ends of the programming languages spectrum and Nim is unifying them in a single package - that's what people are excited about.
      - sillysaurus3 12y ago
        Good performance and meta-programming ("run regular code at compile time") used to be found at the opposite ends of the programming languages spectrum Actually, Lisp has been executing regular code at compile time with good performance since the tail end of the 1980's. Maybe even before that. This is why I said "everything old is new again."
        zahary 12y ago
        Depends on your definition of "good performance". Idiomatic lisp was never able to compete with the Fortran-s and C/C++-s of its age, but Nim is.
        sillysaurus3 12y ago
        "Good performance": Within a factor of ~2 to ~4 of native C. No one said idiomatic Lisp was performant. They said Lisp was performant. Seriously, it's not even difficult. It's not like it's a situation where it's easy to accidentally kill your performance by writing elegant code while having no idea why it's slow. Optimizing a Lisp codebase is a straightforward exercise, no more difficult than optimizing a Lua or Javascript codebase. If someone hasn't shipped more than a toy program with Lisp, it's easy to believe the opposite. But if you try it, you'll see that it's true.
    - klibertp 12y ago
      To be a bit more specific as to where else these ideas are found: * Run regular code at compile time Lisp, of course. Since very long ago. * Extend the language (AST templates and macros); this can be used to add a form of list comprehensions to the language! Lisp, but also Dylan, Elixir, JS with Sweet.js and more. See for example here: https://opendylan.org/articles/macro-system/index.html https://opendylan.org/articles/macro-system/index.html * Add your own optimizations to the compiler! I'm not sure here. * Bind (easily) to your favorite C functions and libraries Almost every serious language has FFI for C. Nimrod offers a possibility to use statically linked libraries, which is not very popular, but for example Gambit Scheme does this since long ago. * Unified Call Syntax, so mystr.len() is equivalent to len(mystr) Lua, somewhat. Also Dylan again. * Good performance -- not placing too much emphasis on this, but it's faster than C++ in his benchmark Too many to count. * Compile to JavaScript OCaml. And more: almost every language has a compile-to-JS project for it (although only a couple are workable). EDIT: > typesafe enums are also extremely old Aren't those just sum types? This would make them as old as ML at least. This of course doesn't make Nimrod any less interesting a language and some combinations of those features may be rather novel. Still, 'everything old is new again' I think is 100% true for all of these features. In reality you won't ever encounter truly unprecedented features in general purpose languages and outside of academia: one can go to LtU site for those. All the rest languages are built on really old (proven) concepts, which they reimplement and package in a (very) different ways. I have no idea why would you get downvoted for stating such fact.
- oscargrouch 12y ago
  Dont know why you have been downvoted, because this is a kind of "pascal rebirth - the mission". Of course it borrow some things from Python.. but i dont know why this has to be bad. When i was a kid pascal was a thing.. and my first hello worlds were programmed in it (away from C), then in my teens, Delphi was a thing, relearn to program in it, and it kept me away from Visual Basic (ohh-hay) Pascal/Delphi was so fun to program with (thanks Hejlsberg!), but somehow the tech world turned into this C syntax dominated world, because of the popularity of the Unix.. And i must say, playing a little bit with Nim, it make me feel that again.. the joy of programming.. And i've always feel Python kind of nasty, i confess, not very easy to read the code.. like a messy code comming from a five year old.. but Nim doesnt have that feel.. it feels like pascal in the old days.. pretty serious but also fun and pragmatic!
rogerbinns 12y ago
As a pythonista one thing that struck me in the code fragments is zeroes and ones appearing everywhere. It looks very easy to have off by one errors. (It is very rare to have off by one errors in Python due to the way counting and ranges work.)
- kbenson 12y ago
  I don't program in Python, but I thought one of the contention points the community had was the syntax of slices and such (starting at one instead of zero, or one sire of the range being inclusive, I can't recall). If that's true, I would imagine that would encourage for some off by one errors. Then again, maybe it's not nearly as contentious as it sounded in a few comments.
  - vbit 12y ago
    Slices start at 0, not 1. However they are inclusive of both boundary items. This matches how ranges are specified in Nim.
    - haldean 12y ago
      Slices in Python are not inclusive of the second index; lst[0:2] gives you a list containing the first two elements.
- def- 12y ago
  I guess you could use fewer magic numbers if you want, for example instead of: proc createCRCTable(): array[256, CRC32] = for i in 0..255: You can write: proc createCRCTable(): array[256, CRC32] = for i in result.low .. result.high: Or: proc createCRCTable(): array[256, CRC32] = for i, v in result: # index, value Or define your own indices iterator: iterator indices(x) = for i in x.low .. x.high: yield i proc createCRCTable(): array[256, CRC32] = for i in result.indices: I think I should propose adding indices to the standard library.
  - rogerbinns 12y ago

by benhoyt 12y ago

sillysaurus3 12y ago

Everything old is new again.

benhoyt 12y ago
Care to flesh that out a bit?
- dingdingdang 12y ago
  Ah, yes, I remember back in 1959 when we all was rocking the Cobol and I used to auto compile straight to Javascript with a Future module so magnificent that it auto-compile-manifested a V8 JS engine with which to run it. Deal with that boring Nim compiler.
- sillysaurus3 12y ago
  When I saw that the top comment is a list of language features which are mostly extremely old, I thought that was interesting, so I pointed out how old those features are. And got hammered for it in spite of the fact that it's true. Obviously, it doesn't matter whether those features are old or new. What matters is whether the language executes them in a compelling way. But almost every single one of those features has been a core aspect of programming languages which have been around since before most of us were born. Also, the mods have strongly urged me to write shorter comments, and to write comments less frequently. And they've suggested that more than once. I try to oblige, and this is the result. So technically I can't flesh out my comments without going against their advice. Of that list of nine features, I'm certain six are extremely old: * Run regular code at compile time * Extend the language (AST templates and macros); this can be used to add a form of list comprehensions to the language! * Add your own optimizations to the compiler! * Bind (easily) to your favorite C functions and libraries * Unified Call Syntax, so mystr.len() is equivalent to len(mystr) * Good performance -- not placing too much emphasis on this, but it's faster than C++ in his benchmark I wouldn't be surprised if GC control and typesafe enums are also extremely old, bringing that up to "8 out of 9 features are old." But it's at least 6 out of 9.
  - zahary 12y ago
    Well, you have to combine just two of these features to leave Nim in a very small company of languages, mostly developed in the last decade. Good performance and meta-programming ("run regular code at compile time") used to be found at the opposite ends of the programming languages spectrum and Nim is unifying them in a single package - that's what people are excited about.
    - sillysaurus3 12y ago
      Good performance and meta-programming ("run regular code at compile time") used to be found at the opposite ends of the programming languages spectrum Actually, Lisp has been executing regular code at compile time with good performance since the tail end of the 1980's. Maybe even before that. This is why I said "everything old is new again."
      - zahary 12y ago
        Depends on your definition of "good performance". Idiomatic lisp was never able to compete with the Fortran-s and C/C++-s of its age, but Nim is.
        sillysaurus3 12y ago
        "Good performance": Within a factor of ~2 to ~4 of native C. No one said idiomatic Lisp was performant. They said Lisp was performant. Seriously, it's not even difficult. It's not like it's a situation where it's easy to accidentally kill your performance by writing elegant code while having no idea why it's slow. Optimizing a Lisp codebase is a straightforward exercise, no more difficult than optimizing a Lua or Javascript codebase. If someone hasn't shipped more than a toy program with Lisp, it's easy to believe the opposite. But if you try it, you'll see that it's true.
  - klibertp 12y ago
    To be a bit more specific as to where else these ideas are found: * Run regular code at compile time Lisp, of course. Since very long ago. * Extend the language (AST templates and macros); this can be used to add a form of list comprehensions to the language! Lisp, but also Dylan, Elixir, JS with Sweet.js and more. See for example here: https://opendylan.org/articles/macro-system/index.html https://opendylan.org/articles/macro-system/index.html * Add your own optimizations to the compiler! I'm not sure here. * Bind (easily) to your favorite C functions and libraries Almost every serious language has FFI for C. Nimrod offers a possibility to use statically linked libraries, which is not very popular, but for example Gambit Scheme does this since long ago. * Unified Call Syntax, so mystr.len() is equivalent to len(mystr) Lua, somewhat. Also Dylan again. * Good performance -- not placing too much emphasis on this, but it's faster than C++ in his benchmark Too many to count. * Compile to JavaScript OCaml. And more: almost every language has a compile-to-JS project for it (although only a couple are workable). EDIT: > typesafe enums are also extremely old Aren't those just sum types? This would make them as old as ML at least. This of course doesn't make Nimrod any less interesting a language and some combinations of those features may be rather novel. Still, 'everything old is new again' I think is 100% true for all of these features. In reality you won't ever encounter truly unprecedented features in general purpose languages and outside of academia: one can go to LtU site for those. All the rest languages are built on really old (proven) concepts, which they reimplement and package in a (very) different ways. I have no idea why would you get downvoted for stating such fact.
oscargrouch 12y ago
Dont know why you have been downvoted, because this is a kind of "pascal rebirth - the mission". Of course it borrow some things from Python.. but i dont know why this has to be bad. When i was a kid pascal was a thing.. and my first hello worlds were programmed in it (away from C), then in my teens, Delphi was a thing, relearn to program in it, and it kept me away from Visual Basic (ohh-hay) Pascal/Delphi was so fun to program with (thanks Hejlsberg!), but somehow the tech world turned into this C syntax dominated world, because of the popularity of the Unix.. And i must say, playing a little bit with Nim, it make me feel that again.. the joy of programming.. And i've always feel Python kind of nasty, i confess, not very easy to read the code.. like a messy code comming from a five year old.. but Nim doesnt have that feel.. it feels like pascal in the old days.. pretty serious but also fun and pragmatic!

rogerbinns 12y ago

As a pythonista one thing that struck me in the code fragments is zeroes and ones appearing everywhere. It looks very easy to have off by one errors. (It is very rare to have off by one errors in Python due to the way counting and ranges work.)

kbenson 12y ago
I don't program in Python, but I thought one of the contention points the community had was the syntax of slices and such (starting at one instead of zero, or one sire of the range being inclusive, I can't recall). If that's true, I would imagine that would encourage for some off by one errors. Then again, maybe it's not nearly as contentious as it sounded in a few comments.
- vbit 12y ago
  Slices start at 0, not 1. However they are inclusive of both boundary items. This matches how ranges are specified in Nim.
  - haldean 12y ago
    Slices in Python are not inclusive of the second index; lst[0:2] gives you a list containing the first two elements.
def- 12y ago
I guess you could use fewer magic numbers if you want, for example instead of: proc createCRCTable(): array[256, CRC32] = for i in 0..255: You can write: proc createCRCTable(): array[256, CRC32] = for i in result.low .. result.high: Or: proc createCRCTable(): array[256, CRC32] = for i, v in result: # index, value Or define your own indices iterator: iterator indices(x) = for i in x.low .. x.high: yield i proc createCRCTable(): array[256, CRC32] = for i in result.indices: I think I should propose adding indices to the standard library.
- rogerbinns 12y ago