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

Modern C [pdf]

icube-icps.unistra.fr

Post reply on HN
Print view View original

251–260 of 396 posts

Re: Modern C [pdf]

#251

Post by mitchty »

steveklabnik wrote: post #182
mitchty wrote: post #12

Earlier quoted context omitted.

Also if anyone is talking about systems programming, it would be beneficial if you specify what that means. I've seen people consider "systems" programming as relating to building web services. Traditionally systems programming would be more kernel level and utilities/daemons. Rust might be OK to start using for the latter, but its very much not yet where I'd start using it for new things for either of the traditiona…

> Given how much it changes I would NOT want to bet on using it for at least 5 years. Rust may be changing, but it's almost entirely _additions_. We've been stable for roughly 18 months now.

Sorry should have been more clear, my meaning was more around things like cargo and tooling rather than the language proper.

Don't take any of my criticism too harshly either, I do like and use Rust for side projects. But it is about 3 years away from where I'd consider using it for anything. I'm a bit more conservative than most here seem to be. Funny part is I'm the maverick in using new stuff compared to the people I work with.

Keep on trying to improve things either way!

Re: Modern C [pdf]

#252

Post by timow1337 »

yoha wrote: post #187
colanderman wrote: post #156

While I like a lot of what's in here, for (size_t i = 9; i is a pretty terrible example to put in the second chapter. I would not let that line pass code review. There is no need or place for cutesy cleverness in C. EDIT: Ugh, just found this too: isset[!!largeA[i]] += 1; Not only is that confusingly cutesy, but largeA[i] is a double . Please DON'T write – or encourage beginners to write! – such smug code! EDIT2: In…

Decrementing loops is the one place where I have indulged in some trickery. I do: for (size_t i = 9; i --> 0; ) This has the advantage to be very easy to pattern-match once known. Obviously, for a beginner, I would just do: for (int i = 9; i >= 0; i -= 1)

now do the second example with an unsigned type.

Re: Modern C [pdf]

#253

Post by solidsnack9000 »

mitchty wrote: post #29
solidsnack9000 wrote: post #24

Earlier quoted context omitted.

Rust is more focused on C compatibility and simple (dumb) operational semantics than Idris and other dependently typed languages. Rust will never require GC, for example; maybe Idris doesn't now but is that a focus for them?

Idris can compile to c, it requires no runtime. You're probably thinking of Haskell with its RTS. Idris is closer to ocaml in that regard. I cough may have already tried using idris in a kernel module. (for fun, not for serious)

I'm not thinking of Haskell. Idris compiles to C but there is an open question there, with regards to how memory will be handled now and in the future. Swift does not need a runtime either, since it uses automatic reference counting for everything; but it has not gone as far as Rust, which defaults to stack allocation everywhere.

This is not to say I doubt the ultimate approach of Idris: with dependent types you can do everything Rust is doing, and more. It's just a matter of project focus and ergonomics.

Re: Modern C [pdf]

#254

Post by yoha »

timow1337 wrote: post #252
yoha wrote: post #187

Earlier quoted context omitted.

Decrementing loops is the one place where I have indulged in some trickery. I do: for (size_t i = 9; i --> 0; ) This has the advantage to be very easy to pattern-match once known. Obviously, for a beginner, I would just do: for (int i = 9; i >= 0; i -= 1)

now do the second example with an unsigned type.

The point is that a beginner does not need to care about signedness. When you get to that point, you can take the time to explain how to loop properly over it.

Re: Modern C [pdf]

#255

Post by solidsnack9000 »

dlanouette wrote: post #124
solidsnack9000 wrote: post #26

Earlier quoted context omitted.

Databases have been written in Java, too; but the combination of performance unpredictability (not something Go has addressed, since it is also garbage-collected) and a bad C compatibility story has proven to limit the reach of these projects.

> Databases have been written in Java, too; Your comment seems to imply that java hasn't been successful for db development. HBase, Cassandra and ElasticSearch would all disagree. Yes, there are situations where GC is not appropriate. But I think those situations aren't as common as they are made out to be.

Well, I'm thinking of RDBMSes, of which there are some written in Java -- but I think you would agree, they have never gained much traction relative to Postgres and MySQL (or Oracle in enterprise).

HBase and ElasticSearch, and even Cassandra can be seen as somewhat niche today. This doesn't mean they aren't doing something of value; and it doesn't mean using the same platform for OLTP and OLAP is the way of the future; but it does mean the competition in their space is more limited and less indicative. There are ground-up rewrites of Cassandra in non-GC'd languages out there, for what it's worth.

Re: Modern C [pdf]

#256

Post by weaksauce »

pieterr wrote: post #240
xenihn wrote: post #232

Earlier quoted context omitted.

Do you have any recommendations for books?

K&R: https://www.amazon.com/gp/aw/d/0131103628/

Is that still relevant to how c looks and acts nowadays? I know you will learn a lot from it and it's an excellent book, but surely there is a better reference that is more up to date. Maybe not though.

Re: Modern C [pdf]

#257

Post by digler999 »

ape4 wrote: post #135

Goto is considered useful by the book: The use of goto and similar jumps in programming languages has been subject to intensive debate, starting from an article by Dijkstra [1968]. Still today you will find people that seriously object code as it is given here, but let us try to be pragmatic about that: code with or without goto can be ugly and hard to follow.

It's been brought up that there are a few handy uses for goto. I think the reason it's so heavily preached against is because of its name. For someone just starting out, the word "goto" might sound like a handy tool that could be useful for all sorts of things.

But instead of a measured response to make it the last tool you reach for, it's been made into a pariah.

Re: Modern C [pdf]

#259

Post by joeberon »

weaksauce wrote: post #256
pieterr wrote: post #240

Earlier quoted context omitted.

K&R: https://www.amazon.com/gp/aw/d/0131103628/

Is that still relevant to how c looks and acts nowadays? I know you will learn a lot from it and it's an excellent book, but surely there is a better reference that is more up to date. Maybe not though.

I think it's still really helpful to learn C and as a reference, but the code has a very terse and difficult to read style that I wouldn't recommend actually coding in, for example this is introduced in the first chapter, before anything is even studied in depth: https://www.dropbox.com/s/4hbwyid5jwen43t/Screenshot%202016-...

Re: Modern C [pdf]

#260

Post by junke »

sidlls wrote: post #239
junke wrote: post #216

Earlier quoted context omitted.

Vulnerabilities like buffer overflow do not happen in languages with a string type. Humans are responsible if something bad happens, but without a safety net, the outcome is worse.

Your first statement is pretty false, even in Rust (for example). Unless you mean something else by "buffer overflow" than I'm accustomed to.

You are right, "do not happen" sounds too much like "will never happen". See also Wikipedia's entry about that example[0]. My point is that if the programmer can't prove accesses are always within appropriate bounds, there should be a runtime check. That is simple. This is not "slow" (and even in the case it you need it fast and are ok to randomly crash, avoiding checks should be explicit). And some languages do it by default and make it really hard to mess with memory.

[0] https://en.wikipedia.org/wiki/Buffer_overflow#Choice_of_prog...

Post reply on HN