Nimrod for C programmers • Hacker News Board

Re: Nimrod for C programmers

#21

Post by jessaustin » Sun, May 04, 2014, 1:20 PM UTC

SeanDav wrote: post #18

idlewan wrote: post #13

Earlier quoted context omitted.

- No curly braces around anything. - Whitespace seems to be important, just like python. That might be a 'bug' for you, but that's a feature for most. At least for Python, Yaml, Coffeescript, Jade, Stylus and Nimrod users :)

A "C" type programming language with no curly brackets (or equivalent) and significant whitespace is a huge negative for me and utter deal breaker. This is the first time I have heard about Nimrod and was very interested to see more. It was all looking so good until I came to this part. Literally I stopped browsing the Nimrod site and closed it down (with some regret) as soon as I saw this. Not interested anymore.

Does this strong preference come from any particular experience? E.g., has Python's significant whitespace caused persistent errors on a project?

Re: Nimrod for C programmers

#22

Post by DennisP » Sun, May 04, 2014, 1:44 PM UTC

barrkel wrote: post #17

eliteraspberrie wrote: post #10

I strongly disagree with the rationale for not supporting unsigned integer types by default. In fact, I think unsigned should be the default, and the advice on the Escher Technologies blog is harmful. Other than that, Nimrod has been a pleasure to use. If you need a metaprogramming language to generate C, use Nimrod.

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…

I don't find bitwise operations incredibly rare. I use them fairly often in my side projects (various simulations and optimizers).

Re: Nimrod for C programmers

#24

Post by deckiedan » Sun, May 04, 2014, 1:54 PM UTC

jessaustin wrote: post #21

SeanDav wrote: post #18

Earlier quoted context omitted.

A "C" type programming language with no curly brackets (or equivalent) and significant whitespace is a huge negative for me and utter deal breaker. This is the first time I have heard about Nimrod and was very interested to see more. It was all looking so good until I came to this part. Literally I stopped browsing the Nimrod site and closed it down (with some regret) as soon as I saw this. Not interested anymore.

Does this strong preference come from any particular experience? E.g., has Python's significant whitespace caused persistent errors on a project?

From Python-land, if you find that no brackets are meaning it's hard to tell where conditionals & functions end, it's usually a good sign that you're logic is getting too nested.

Yes, it's a pain to work with massively nested logic, but it's actually python's way of saying, "dude! keep your functions small and simple!", which I've come to appreciate.

It's one of the things I like about python, actually, is that it really tries hard to encourage you to write good code. Once things start looking ugly and hard to understand, it usually means that the logic & method you're trying to implement isn't a great choice.

Re: Nimrod for C programmers

#25

Post by _pmf_ » Sun, May 04, 2014, 2:13 PM UTC

barrkel wrote: post #17

eliteraspberrie wrote: post #10

I strongly disagree with the rationale for not supporting unsigned integer types by default. In fact, I think unsigned should be the default, and the advice on the Escher Technologies blog is harmful. Other than that, Nimrod has been a pleasure to use. If you need a metaprogramming language to generate C, use Nimrod.

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.

Re: Nimrod for C programmers

#26

Post by plg » Sun, May 04, 2014, 2:24 PM UTC

I read the title too quickly and I thought it said

C for nimrod programmers

Re: Nimrod for C programmers

#27

Post by andreasvc » Sun, May 04, 2014, 2:33 PM UTC

SeanDav wrote: post #18

idlewan wrote: post #13

Earlier quoted context omitted.

- No curly braces around anything. - Whitespace seems to be important, just like python. That might be a 'bug' for you, but that's a feature for most. At least for Python, Yaml, Coffeescript, Jade, Stylus and Nimrod users :)

A "C" type programming language with no curly brackets (or equivalent) and significant whitespace is a huge negative for me and utter deal breaker. This is the first time I have heard about Nimrod and was very interested to see more. It was all looking so good until I came to this part. Literally I stopped browsing the Nimrod site and closed it down (with some regret) as soon as I saw this. Not interested anymore.

Do you realize how close-minded you sound? This is purely a bikeshed issue.

Re: Nimrod for C programmers

#28

Post by idlewan » Sun, May 04, 2014, 3:06 PM UTC

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

Re: Nimrod for C programmers

#29

Post by Nursie » Sun, May 04, 2014, 3:17 PM UTC

barrkel wrote: post #17

eliteraspberrie wrote: post #10

I strongly disagree with the rationale for not supporting unsigned integer types by default. In fact, I think unsigned should be the default, and the advice on the Escher Technologies blog is harmful. Other than that, Nimrod has been a pleasure to use. If you need a metaprogramming language to generate C, use Nimrod.

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 overflows.

Re: Nimrod for C programmers

#30

Post by Nursie » Sun, May 04, 2014, 3:21 PM UTC

J_Darnley wrote: post #11

bsaul wrote: post #2

Every time i look at this language feature, it seems like a dream come true. Yet, i stopped believing in santa when i was 4 so could anyone here points at its ugly parts ?

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.

I've been trying to get my team to think more about which 8nteger type they use, the range of values, portability etc etc.

The C99 stdint types really should be second nature to C developers, it always surprises me how many just haven't heard of them.