Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nimrod for C programmers

github.com

Post reply on HN
Print view View original

31–40 of 67 posts

Re: Nimrod for C programmers

#31

Post by rbehrends »

idlewan wrote: post #28

If you're interested in Nimrod's performance, it's really good: http://codegolf.stackexchange.com/questions/26459/how-high-c...

As the person who wrote that: the speedup here is primarily due to using a smarter algorithm, though Nimrod helped in keeping the constant factor low.

I expect that one could get the same performance in C, though unrolling the top levels of the recursive search would be a bit more cumbersome and having efficient bound checks for arrays in Nimrod helped in debugging some variants of the algorithm.

In short, the benefits of Nimrod here were expressiveness and safety rather than raw performance (though having performance of optimized code that is competitive with C hardly hurts, either).

Re: Nimrod for C programmers

#32

Post by mahkoh »

Dewie wrote: post #20
J_Darnley wrote: post #11

Earlier quoted context omitted.

This is the first time I've heard of Nimrod and being an amateur C user these are the parts I don't like: - No curly braces around anything. - Whitespace seems to be important, just like python. - Some nonsense about unsigned integers. The best thing I saw was that it has C's explicit-size integers. The one thing I wish every C program would use rather than having configure guess which basic type it should use.

> - No curly braces around anything. Do you find curly braces to have some aesthetic? That you like to see it in code for its own sake?

Yesterday I reported a bug which had already been fixed several weeks ago but reappeared in a new version.

After looking through the original patch and the current version, I found that the bug was caused by significant indentation. The maintainer had decided to add comments and accidentally indented the code one more level, making it part of an if branch. Braces would have prevented this.

Re: Nimrod for C programmers

#34

Post by pcwalton »

heinrich5991 wrote: post #4

How does Nimrod compare to Rust, in terms of goals?

Rust provides memory safety with no garbage collection. Like every other industrial language, Nimrod requires garbage collection in the form of (deferred) reference counting to achieve safety.

Re: Nimrod for C programmers

#35

Post by pcwalton »

dbaupp wrote: post #16
heinrich5991 wrote: post #4

How does Nimrod compare to Rust, in terms of goals?

Rust focuses very much on low/no-overhead memory safety (especially memory safety without a GC), while Nimrod seems to be more focused at more convenient low-level programming, but without quite such a strong push for memory safety and reliable very high performance (e.g. GC is compulsory for safety). That's not to say that Rust isn't convenient, but the quest for strong memory safety & performance guarantees doesn't…

> My reading of the Nimrod FAQ[2] ("An unsafe shared memory heap is also provided") implies this isn't (as easily) possible in Nimrod.

Nimrod's GC is not thread safe, so you have to use raw unsafe allocation and deallocation in order to share objects between threads (last I looked anyway). This is in contrast to Rust, for which memory safety is important even in multithreaded scenarios.

Re: Nimrod for C programmers

#36

Post by pjmlp »

_pmf_ wrote: post #25
barrkel wrote: post #17

Earlier quoted context omitted.

I'll assert that a majority of C programmers do not understand unsigned types and misuse them. It's quite common to end up needing to use both signed and unsigned types in the same expression and to end up invoking undefined behaviour trying to protect yourself. C overflow semantics (i.e. undefined) in particular. Signed types should be the default, and overflow should be defined as wrapping two's complement. There's…

> The places where unsigned numbers are justified are incredibly rare: bitwise operations I take it you do not work with bare metal at all.

I take you aren't aware OP was on the Delphi compiler team and has lot of experience with low level coding.

Re: Nimrod for C programmers

#38

Post by rbehrends »

Nursie wrote: post #29
barrkel wrote: post #17

Earlier quoted context omitted.

I'll assert that a majority of C programmers do not understand unsigned types and misuse them. It's quite common to end up needing to use both signed and unsigned types in the same expression and to end up invoking undefined behaviour trying to protect yourself. C overflow semantics (i.e. undefined) in particular. Signed types should be the default, and overflow should be defined as wrapping two's complement. There's…

Third case, dealing with raw data from networks, from devices, from flash memory etc. where you actually need to manipulate every bit accurately. Fourth case - situations in which you have a scalar quantity, and do not care about positive or negative. Overflow is a separate issue and you must either make sure you either know the range of the data and pick an appropriately sized storage type, or explicitly check for o…

> Fourth case - situations in which you have a scalar quantity, and do not care about positive or negative.

This is actually where you have to be really careful, because there can be corner cases surrounding zero. E.g.:

  for (i=len-1; i>=0; i--) { ... }
Yes, either ints or unsigned numbers can overflow, but underflowing a natural number is much more common.

Don't take my word for it, ask Bjarne Stroustrup or Chandler Carruth: http://stackoverflow.com/questions/18795453/why-prefer-signe...

Re: Nimrod for C programmers

#39

Post by J_Darnley »

Dewie wrote: post #20
J_Darnley wrote: post #11

Earlier quoted context omitted.

This is the first time I've heard of Nimrod and being an amateur C user these are the parts I don't like: - No curly braces around anything. - Whitespace seems to be important, just like python. - Some nonsense about unsigned integers. The best thing I saw was that it has C's explicit-size integers. The one thing I wish every C program would use rather than having configure guess which basic type it should use.

> - No curly braces around anything. Do you find curly braces to have some aesthetic? That you like to see it in code for its own sake?

Not the curly brace itself but I find it a good marker for a block of code. Something should mark the start and end of a loop or conditional. Bash has esac, fi, and done, for example.
Post reply on HN