Live data from Hacker News

Modern C [pdf]

icube-icps.unistra.fr

61–70 of 396 posts

Re: Modern C [pdf]

#61
post #48
post #32

Earlier quoted context omitted.

Note that var1 and var2 are not the same type: char* var1, var2; Traditional style makes this clear.

> We bind type modifiers and qualifiers to the left. Good idea in theory but your example shows how bad it behaves in practice.

Usually declare variables one per line, so, type is still clear when:

char* var1;

char var2;

Re: Modern C [pdf]

#63

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.

True. Even very successful database projects in Java have some issues with GC pauses. Go seems to be, IMO, taking the things Java is best at and trying to make something better. Basically, how would you build Java today if you could do it again?

> Basically, how would you build Java today if you could do it again?

Take Modula-3 (1986), change the keywords to lowercase and re-brand it as "Cool Language X".

Still better Go than C.

Re: Modern C [pdf]

#64

Earlier quoted context omitted.

Yeah, again and again. it's like blaming a hammer for the potential of breaking your finger when you use it, and proposing the use of a spoon, instead.

If the handle of the hammer you're holding was a chainsaw that randomly turns on and off. And also sometimes explodes killing your entire family and pet dog. Don't blame the explodey-chainsaw-hammer, it's just a tool . Okay an idiotically dangerous too that nobody in their right mind should use, but still just a tool.

> If the handle of the hammer you're holding was a chainsaw

Except it isn't.

It's just a hammer, with a handle of a hammer.

> And also sometimes explodes killing

Except it doesn't.

At best, some people are reckless and end up causing problems due to their recklessness.

Enough with these silly hyperboles. Cushioned environments lead to less problems.

Re: Modern C [pdf]

#65
post #52

Another day for the HN crowd to express their distaste for C :)

In a PDF no less. I for one do not miss C (or Objective-C for a long time) at all. I built my first commercial app in C starting in the mid 1985 (Mac). That's how much of an antique this language is.

And yet, the OS and the browser you used to type this comment was written in C or a C-derivative like C++.

Re: Modern C [pdf]

#66

Earlier quoted context omitted.

Yeah, again and again. it's like blaming a hammer for the potential of breaking your finger when you use it, and proposing the use of a spoon, instead.

If the handle of the hammer you're holding was a chainsaw that randomly turns on and off. And also sometimes explodes killing your entire family and pet dog. Don't blame the explodey-chainsaw-hammer, it's just a tool . Okay an idiotically dangerous too that nobody in their right mind should use, but still just a tool.

Eh, no need to overreact that much. Look. Hardware is hardware, and this is where tire meets the road so people can lay the foundation for the upper levels.

It is what it is. It's not user friendly because hardware just isn't, low levels aren't, and it has to just perform.

> 'idiotically dangerous'

Well, I don't want to sound harsh, but nobody forces anybody to do systems programming if they perceive C as such. There is JavaScript, python and plethora of other safe and cozy languages, but: the low level has to be done.

Re: Modern C [pdf]

#67
What alternatives there are for C/C++ if you want to write library that you can call from Python, R, Matlab, Java, Rust, Lua, node.js ... and have good performance?

Old ones like Ada and Fortran of course.

There are newcomers like Rust and Go. Are their C api's mature and portable?

Re: Modern C [pdf]

#68
post #36
post #9

It's been a decade or more since I've worked in C (and have never been a heavy C coder). Is "modern C" really a thing? I mean, is there some subset of C that is safer than what I think of when I think of C? I know about stuff like reference counting techniques, rather than manual memory management, for example, and that goes miles towards safer coding. But, even so, the variety of ways you can shoot yourself in the f…

Go has chosen to omit assert(), because assert() is frequently misused they say. Antibiotics are also frequently misused, but that is not a good reason to prohibit them. The omission of assert() makes Go a non-starter. Rust seems more promising, but it is still not to the point where I am interested in rewriting SQLite in Rust, though I may revisit this decision in future years. Some current reasons to continue to pr…

> Rust has "immutable variables". Seriously? How can an object be both variable and immutable?

"Immutable variables" is frequently used, true, but the official term is "immutable bindings".

Re: Modern C [pdf]

#69
post #52

Another day for the HN crowd to express their distaste for C :)

Yeah, again and again. it's like blaming a hammer for the potential of breaking your finger when you use it, and proposing the use of a spoon, instead.

More like blaming a power-saw for the potential of destroying your table when you want to cut some bread.

If you are in for cutting a tree, go for it.

Re: Modern C [pdf]

#70
post #51

I personally prefer Prehistoric C, which only has the two language keywords "ugh" and "grunt". Modern C has too many keywords for my taste.

> "grunt"

I'm sorry, you cannot use this keyword as it will cause a conflict with Javascript tools.

Post reply on HN