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

51–60 of 67 posts

Re: Nimrod for C programmers

#51

Post by [deleted] »

mahkoh wrote: post #32
Dewie wrote: post #20

Earlier quoted context omitted.

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

[deleted]

Re: Nimrod for C programmers

#52

Post by TylerE »

inglor wrote: post #46

Why would I use Nimrod and not C++? C++ matured quite a bit over the last 20 years and I'm not sure what advantages Nimrod has over it. The tutorial mentions C++ a lot of times but does not mention any advantage for Nimrod.

It gives you 90% of the performance and control, great metaprogramming, all in a language that's much much much less of a minefield than C++.

Like, imagine you could write Python instead of C++, except that it only ran 10% slower instead of 10,000% slower.

Re: Nimrod for C programmers

#53

Post by audunw »

eliteraspberrie wrote: post #48
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…

I think you hit the nail on the head: the problem is education. Generally, a C programmer who took the time to understand integer types and their behaviour won't make mistakes with either signed or unsigned types. But making unsigned types second class only reinforces bad habits (or what I consider bad).

> But making unsigned types second class only reinforces bad habits (or what I consider bad).

What do you mean by that? Don't you think that having to do "import unsigned" before they use unsigned types, make some people think twice? Don't you think a few people might think "Do I really understand this feature? Should I perhaps read the documentation for this module?"

Re: Nimrod for C programmers

#54

Post by audunw »

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…

> Third case, dealing with raw data from networks, from devices, from flash memory etc. where you actually need to manipulate every bit accurately.

I just started working on this kind of application (well, USB protocols, but same issues) in Nimrod.

First of all: just do "import unsigned" and you can work with unsigned just fine. I don't see why this is an issue, any more than that you have to do "import libusb".

Second: I found that, knowing that unsigned types are a second-class citizen lead me towards writing a much better library. It encourages you to expose only signed integers to the next level up in the app. The next thing I realized is that this will very quickly cause Nimrod programmers to write and adopt a "Protocol Buffers"-like library for dealing with network protocols, binary files and similar things. And that will be a much better solution than dealing with things like unsigned integers and endianess in manual code.

Re: Nimrod for C programmers

#55

Post by audunw »

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

The point is that, "bare metal" is really a special case of programming.

Most general purpose programming languages don't have features specific for web-programming imported by default.

Nimrod supports bare metal programming just as fine as C. You just have to import the relevant modules, just as you'd import the URL module if you were writing a web-server.

Nimrod aims at being approachable to some of the Python/Ruby crowd as well, who are used to numbers that are always signed and can't overflow. Defaulting to the biggest available signed integers, and discouraging library writers from throwing unsigned integers at you for no reason is a decent compromise.

Re: Nimrod for C programmers

#56

Post by mamcx »

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.

Not interested?

The C brackets stuff is a mess:

http://www.slate.com/articles/technology/bitwise/2014/02/app... (The error above is not only about the gotos)

Is inconsistent. Cause bugs. Can be write like brackets don't exist (http://www.andromeda.com/people/ddyer/topten.html), nullify your argument. Pick the above link and count how much problems are masked with the illusion of the brackets.

Is unnecessary (add noise just to help the parser), and python, haskell and other languages show that could be done better.

Re: Nimrod for C programmers

#57

Post by dom96 »

egeozcan wrote: post #33

I love working with Nimrod. What it lacks is some documentation. For example, if you want to use PostgreSQL with it, the only documentation you can find is this: http://nimrod-lang.org/postgres.html

There is also http://nimrod-lang.org/db_postgres.html. But I agree that documentation is an area we need to improve on!

Re: Nimrod for C programmers

#59

Post by pcwalton »

rbehrends wrote: post #50
pcwalton wrote: post #43

Earlier quoted context omitted.

I think this demonstrates a problem with C-style for loops (as opposed to iterators) more than unsigned integers.

The problem lies with len-1 underflowing, not the loop that uses the result. For another example, to test congruence of x and y modulo m, you check if (x-y) % m == 0. This also blows up for unsigned integers if y > x unless m is a power of 2. Even iteration is not always over containers or some other structure in a way where the boundaries can be inferred and do not have to be computed, and not always in an order tha…

Even iteration over explicit ranges of unsigned integers can be handled by a Python range()-style iterator, without the risk of this bug (since the iterator itself is responsible for avoiding this gotcha).

Re: Nimrod for C programmers

#60

Post by Nursie »

rbehrends wrote: post #47
Nursie wrote: post #42

Earlier quoted context omitted.

In that loop one should check that len is at least 1 first... I read that page, or at least some of it, it mostly seemed to be opinion rather than solid reason.

> In that loop one should check that len is at least 1 first... No. The code is correct in that regard if you use int for i and len. Having to check len is an artifact of using unsigned. > I read that page, or at least some of it, it mostly seemed to be opinion rather than solid reason. I'm not talking about the comments. I'm talking about what Bjarne Stroustrup (the designer of C++) and Chandler Carruth (Google's LL…

Only if a sub 1 len is valid input, which it may not be. Either way the example is contrived and does not cover all other situations in which a scalar quantity is required. Not all are loop controllers.

I did not watch the video, no time right now. The top comment tells us what they think, not why.

Post reply on HN