Results 1 to 11 of 11

Thread: Nimrod: a new "better C++" class language

  1. #1
    Programmer Bulat Ziganshin's Avatar
    Join Date
    Mar 2007
    Location
    Uzbekistan
    Posts
    4,497
    Thanks
    733
    Thanked 659 Times in 354 Posts

    Nimrod: a new "better C++" class language

    a few days ago DrDobbs published a small article about Nimrod language. i've read the paper, then language tutorial and manual and found it very promising:
    • Nimrod is compiled down to C or JavaScript, making it highly portable and almost as efficient as C++
    • It supports simple OOP, managed and unmanaged pointers, GC, closures, user-defined operators, generics (a la C++ templates), discriminated unions, exceptions, RTTI - well, almost every technique i've ever seen in compiled languages
    • But the most exciting part is the support of syntax macros (called templates). They look like ordinal procedures, but with flexible parameter types and their body is textually inserted at the call place, so you can do everything with types, identifiers, expressions and code chunks passed as parameters. And even ordinary procedures may be implictly generic by supporting type classes (such as all objects, all structures, all objects and structures, all ordinal types or just "int | int64"). Generic programming, compile-time execution and syntax macroses together make Nimrod a truly low-level language allowing one to generate lots of boilerplate code without sacrificing performance


    So, in theory, Nimrod looks as very strong candidate to replace C++. It supports both modern high-level techniques and proper support for low-level coding. On the practice it don't yet reached 1.0 version, so it's not all roses:
    • Trying a few small examples, i got compiler panics twice. Well, that's not problem by itself, but if codegenerator have any bugs, it will make the entrie thing useless
    • I tried simple program computing multiplicative hash of file in C++ and Nimrod, and C++ was faster. Although Nimrod compiles to C, the generated code uses simple while() loop and it seems that GCC isn't smart enough to optimize it as much as native for() loop. This may be solved in future by direct LLVM backend
    • And finally, while low-level programming is possible, code isn't as terse as with C++, with more typecasts required, and "shr/shl/and..." operator names

  2. #2
    Member
    Join Date
    Jun 2009
    Location
    Kraków, Poland
    Posts
    1,471
    Thanks
    26
    Thanked 120 Times in 94 Posts
    There's another multi-paradigm language that's compiled to native binaries - Rust programming language from Mozilla.

    There's repo on GitHub: https://github.com/mozilla/rust (seems much more popular than Nimrod's one)
    Also there's Servo browser engine written in Rust: https://github.com/mozilla/servo

    It seems Rust is more or less on par with Nimrod when it comes to functionality (including macros).

    I'm not sure about translating to JavaScript though, but JavaScript is so different beast that I'm not convinced that compilation to JS is critical for adoption of such kind of language.


    And Rust looks more pleasant for me (than Nimrod)

  3. #3
    Programmer Bulat Ziganshin's Avatar
    Join Date
    Mar 2007
    Location
    Uzbekistan
    Posts
    4,497
    Thanks
    733
    Thanked 659 Times in 354 Posts
    i will take a look at D, Go, Vala, and Rust since i don't like the current C++ state.

    vectors implementation in Rust
    crit bit tree implementation in Nimrod

    except for "{}" i don't see much difference yet, and it is one of my issues with C++. i used to prefer if+fi style, but now i'm happy with haskellish indent-it style

    JavaScript is "browsers assembler" - that's the thing that makes compilation to JS so important
    Last edited by Bulat Ziganshin; 17th February 2014 at 17:29.

  4. #4
    Member
    Join Date
    Feb 2013
    Location
    San Diego
    Posts
    1,057
    Thanks
    54
    Thanked 71 Times in 55 Posts
    Quote Originally Posted by Bulat Ziganshin View Post
    except for "{}" i don't see much difference yet, and it is one of my issues with C++. i used to prefer if+fi style, but now i'm happy with haskellish indent-it style
    This works for me with gcc:

    Code:
    #include <stdio.h>
    
    #define if(x) if(x) {
    #define fi }
    
    
    
    
    int main()
    {
      if(1)
        printf("Works\n");
      fi
    
    
      return 0;
    }
    Is there anything else you dislike about C++?

  5. #5
    Member
    Join Date
    Feb 2013
    Location
    San Diego
    Posts
    1,057
    Thanks
    54
    Thanked 71 Times in 55 Posts
    I took a look at the Dr. Dobbs article. It doesn't look like a better C++; it looks like its ancestors are Lisp and ML. Have you looked at OCaml? OCaml is much older and better tested and it seems to have similar features and syntax. It's also supposed to be fast.

    Nimrod is too different from C to expect a simple and predictable translation into C.

  6. #6
    Member
    Join Date
    Dec 2013
    Location
    Italy
    Posts
    342
    Thanks
    12
    Thanked 34 Times in 28 Posts
    Mhhhh. but what's the realistic path for such languages?
    For me eps, if no eps^2.

    The world codebase (for object programs, not web) is in ancient C, that's a fact, with some C "sometimes plus plus" around.
    Even a language like C# is a small fraction.

    So you can have a beautiful C/C++/++C / in(c) or wathsoever but... who cares? 0.000003%?

    For example English is a very bad language, but is (more or less) worldwide spread.

    Italian in much better ( ), Chinese is almost incomprensible for 5/6 of the World (the 1/6 are already Chinese ) and so on...
    but... who speak Italian?

    Even hour time are meangingless (hours:min:seconds), but I don't bet that will be sobstitute with a Kilo-kile time (ten hours/day, ten minute/hour, ten second /minute).

    ---
    So if you are Chinese or Italian or Kazako... you need C, and C+ (not ++).
    Fragmenting languages in 10000000 is like Linux's distro, subdistro, forks, subforks.
    A babele-like waste of time and efforts.

    PS I'm a old programmer started with Z80 and 6502-assembler, to Acorn-RISC to Alpha-AXP, back in years when we write
    entire UNIX-like kernel OS with... vi... so I've tried (a great part) of last 25-year programming languages.

    Sadly (at 99%) a time wasted, about as trying 50-almost-equal Linux distro.

    Hard words? Yes, but I think true words.

  7. #7
    Member m^2's Avatar
    Join Date
    Sep 2008
    Location
    Ślůnsk, PL
    Posts
    1,612
    Thanks
    30
    Thanked 65 Times in 47 Posts
    I've been playing with Nimrod for the last couple of months, not much though. I find it:
    1. Quirky. Does things its own way. Examples:
    * syntax is a funky mix of various inspirations with many unique features
    * unsigned ints are second class citizens. The author doesn't like them
    * uint64 is not an ordinal type
    * there are 3 types of array that don't map to anything out there
    * arrays (the most regular ones) have indexes that are compile time constants. The constants are of type int. Though int is like most intptr_t's in C, pointer sized, they can't be larger than max int32.
    * AVR is a 16-bit platform
    2. Hard to learn. Has been the hardest for me since Haskell (hard on its own and for me - the 1st functional lang).
    * see (1)
    * no tutorial. The official one is really just a presentation of features.
    * outdated and incomplete docs
    * forum is not searchable
    * sometimes compiler messages are not good
    * Community is OK, but too small. You sometimes wait for a couple of days to get a reply.
    3. Efficient. Rust? Go? No kiddin'. In my experience as good as C or better. Yeah compiler got those while(1) loops left with goto better than hand tuned ones. At the same time it enables more optimizations, both high- and low-level ones.
    4. Low level, unsafe, trusting the dev. Just like in C, you can do all the hacks that you need.
    5. Rich
    * great macros
    * arbitrarily indexed arrays (not 0..N, but f.e. -N...-1)
    * integer ranges
    6. Superb in some cases
    A) garbage collection done right:
    * not forced (you can use malloc/free equivalents in parallel)
    * real-time. You can tell when and for how long is the gc supposed to run
    * configurable. For example you can disable cycle detection to make things faster
    But is it better than Parasail or Erlang?
    B) Effect system rocks
    C) integer overflow in a debug build leads to exception. In release is undefined behaviour. So you get both more speed (because you rarely use unsigned types) and more safety than in C. IIRC assertions work like that too.
    7. Underdeveloped. There are bugs, many features don't have all corner cases implemented.


    Overall, it seems like the 1st language since D to try to supercede C on all fronts. And it's much more different, much more modern than D. In some ways I find it less ambitious than I'd like (dependent types? whole compilation unit type inference? why not faster than C?), but there's nothing better. I'm not really sure it has a chance to succeed. I'm not really sure I want it to succeed. But it sure is a fresh breeze.
    Last edited by m^2; 18th February 2014 at 21:06.

  8. The Following 2 Users Say Thank You to m^2 For This Useful Post:

    Bulat Ziganshin (19th February 2014),Cyan (29th March 2014)

  9. #8
    Programmer kvark's Avatar
    Join Date
    Aug 2006
    Location
    Toronto, Canada
    Posts
    74
    Thanks
    1
    Thanked 1 Time in 1 Post

    Thumbs up

    I've been playing with Rust for a year and a half, but only recently started doing anything related to compression. It is a very solid language, in a sense that the basis for it is pretty simple and well-thought (borrowing, traits, algebraic types). It compiles with LLVM to native code, and targets C++ speed or even better, thanks to the fact the compiler knows about memory aliases (or the lack of thereof) and such. The rule "if it compiles, then it works" applies pretty much all the time, giving the Haskell-like programming feel to it. Rust has also one of the friendliest communities out there, and you are always welcome on the #rust channel at "irc.mozilla.org".

    I've put a lot of effort into https://github.com/alexcrichton/rust-compress, and invite you to join by learning Rust on the way!
    In parallel, I started building an actual BWT-DC compressor (which already works, albeit far from perfect): https://github.com/kvark/dark

  10. #9
    Member
    Join Date
    Jul 2013
    Location
    Germany
    Posts
    24
    Thanks
    4
    Thanked 4 Times in 4 Posts
    I chose D for my last simple project. Dlang.org together with the book "The D Programming Language" from Andrei Alexandrescu, designer and developer of D, were good sources to learn. I am amazed how easy things are, compared to C++.

    Many things are built into the language core. I especially like the way of concurrency and parallelization. Since I use D, I build my solutions around the multithreading of D. Together with the optimizing GCC compiler my programs run fast and utilize all cores.

    I feel that big projects are more managable in D than in C++. It is easy to import C libraries and binary object files, but while D is close to C, you often still have to look through the code to port C to D if you just copy and paste. The good thing is, that if the compiler does not show an error message, the code will work and do the same thing like in C.

  11. #10
    Member Alexander Rhatushnyak's Avatar
    Join Date
    Oct 2007
    Location
    Canada
    Posts
    232
    Thanks
    38
    Thanked 80 Times in 43 Posts
    Quote Originally Posted by Bulat Ziganshin View Post
    i will take a look at D, Go, Vala, and Rust since i don't like the current C++ state.
    Would you agree C++11 is better than the previous standards?
    According to http://blog.codeeval.com the two most used languages are Java and Python. Hopefully support for D, Vala, Rust and Nimrod will be added sooner or later.

    This newsgroup is dedicated to image compression:
    http://linkedin.com/groups/Image-Compression-3363256

  12. #11
    Programmer Bulat Ziganshin's Avatar
    Join Date
    Mar 2007
    Location
    Uzbekistan
    Posts
    4,497
    Thanks
    733
    Thanked 659 Times in 354 Posts
    Alex, i don't have a good knowledge of modern C++ standards. The most well-known C++11 features such as lambdas and atomics/STM are great. but overall, C++ has one fundamental flaw - it has pointer arithmetics and therefore isn't garbage-collected. i prefer to split the entire program into low-level part (compression algorihtms) that needs maximum speed and therefore manual memory control and pointer arithmetics, and high-level part that has garbage collection and all its benefits (i.e. expressions can create arbitrary data structures, lambdas remain valid after function exit and so on). GC opens way to full employment of functional programming style while STL looks like an FP assembler

    just now i do it by using Haskell for high-level program parts (and C++ for low-lvel). but i'm still interested in the single language than can be used for both low-level and high-level program parts. also i'm interested to see non-lazy high-level laguage since haskell laziness may be not optimal for modern application programming

Similar Threads

  1. Replies: 7
    Last Post: 4th January 2016, 15:06
  2. PAKKA (ZPAQ's Win32 "versioned" unpacker)
    By fcorbelli in forum Data Compression
    Replies: 21
    Last Post: 24th June 2015, 23:29
  3. "Implementing ppmc with hash tables"
    By RichSelian in forum Data Compression
    Replies: 8
    Last Post: 11th March 2013, 01:37
  4. PAQ8 C++ precedence bug (or "-Wparentheses is annoying")
    By Rugxulo in forum Data Compression
    Replies: 13
    Last Post: 21st August 2009, 20:36
  5. LZ77 speed optimization, 2 mem accesses per "round"
    By Lasse Reinhold in forum Forum Archive
    Replies: 4
    Last Post: 11th June 2007, 21:53

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •