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

“C is how the computer works” is a dangerous mindset for C programmers

words.steveklabnik.com

Post reply on HN
Print view View original

381–387 of 387 posts

Re: “C is how the computer works” is a dangerous mindset for C programmers

#381

Post by spopejoy »

shadowgovt wrote: post #371
adev_ wrote: post #368

Earlier quoted context omitted.

> But solving a problem with dynamite is still solving a problem with dynamite; there's a lot more ways it can go wrong than solving the problem with a steam drill, to torture an analogy a bit. Excepted that a language is not absolute, is not dynamite or not dynamite. It is what you do of it depending of the subset you use. C++ is not exception.

Agreed. But I won't reach for a language that lets me treat all my program's working memory as an undifferentiated integer-addressable array of bytes if I don't need that to solve the problems I'm trying to solve. ... which goes back to the topic of the HN post; that's only one way to look at the state of a running program, and it's a way that has strengths and weaknesses. The utility of it comes at the cost of the p…

C++ has always been the language that "has a safe subset to use but nobody can agree what that subset is".

JS is ... well, JS

This is at least for me the first time I've seen them discussed in the same breath, which is revolutionary: C++ the language bringing a blue screen to a desktop near you; JS the language bringing your startup to its knees.

I guess I never realized that while they are polar opposites, there are probably some subtle cultural similarities that would make for some hilarious unearthing

Re: “C is how the computer works” is a dangerous mindset for C programmers

#382

Post by geofft »

evil-olive wrote: post #341
geofft wrote: post #297

Earlier quoted context omitted.

This is literally the reason I most recently wrote some C, but - do you really need linking ? You can pretty easily use a Python library from Ruby by writing a little loop in Python that accepts JSON input and produces JSON output, and calling that as a Ruby subprocess. It's fairly rare that you actually need to be in the same process. (The thing I wrote was a wrapper for unshare(), so it did strictly need to be in-p…

> You can pretty easily use a Python library from Ruby by writing a little loop in Python that accepts JSON input and produces JSON output, and calling that as a Ruby subprocess. If you're a Ruby application, sure, you can use a Python library by forking off a subprocess. Just make sure to document the installation requirements - in addition to having Ruby and the correct gems installed, you also need Python (which v…

Sure, but there's an equivalent problem in the C world - go back in time a couple years before we figured out how to do precompiled binary-compatible C extensions in Python and try running 'pip install numpy'.

I'm mostly thinking that if you already have a Python library you really like, chances are you already have a Python environment capable of running it. (The environment doesn't have to be related to your Ruby environment at all! If you want to get Ruby through your OS and Python through a Docker container, or whatever, that should work fine.)

Re: “C is how the computer works” is a dangerous mindset for C programmers

#383

Post by pjmlp »

pdimitar wrote: post #379
pjmlp wrote: post #378

Earlier quoted context omitted.

Depends where you look, Swift, Kotlin and TypeScript live from their tooling.

My favourite language -- Elixir -- is the same. I also quite admire Rust's and Golang's tooling. CLI tooling is the best it ever was in history (from where I stand at least). But IDE tooling isn't a first class citizen for many languages these days, is what I was saying.

I beg to differ, I rather enjoy languages that pursue the dream from Xerox PARC than working like when I was in high school during the late 80's.

Just for reference, my first UNIX was Xenix.

Don't see the point why people buy expensive computers to just use them like we did at the university lab with IBM X terminals.

The main difference was that instead of Slack we had xterms dedicated to run talk sessions.

Re: “C is how the computer works” is a dangerous mindset for C programmers

#384

Post by otabdeveloper2 »

pdimitar wrote: post #373
otabdeveloper2 wrote: post #252

Earlier quoted context omitted.

> C++ has a standard that's too long and hard to understand, so let's use a language without any standard whatsoever instead! Good lord, if that's the kind of human capital that's involved in making next-generation languages, then I have no doubt what will still be used to write serious software in 2080. (Hint: not Rust.)

You'd be more helpful if you specified what else would you deem appropriate -- as opposed to resorting to snarky sarcasm that brings nothing interesting to the discussion except supposedly degrade people whose tech choices you disagree with.

The phrase 'undefined behavior' only makes sense in the context of an ISO standard.

For any particular combination of compiler, OS and computer architecture there are no 'undefined behaviors'; you only care about the concept if you want portability to a different compiler/OS/architecture.

So the idea that C++ sucks because of 'undefined behavior', so let's use some random language without an ISO standard or any portability guarantees at all is completely and utterly insane.

Re: “C is how the computer works” is a dangerous mindset for C programmers

#385

Post by masklinn »

saagarjha wrote: post #225
masklinn wrote: post #135

Earlier quoted context omitted.

> If you want to go with that analogy, UB is a kin of you intentionally pointing your gun to your foot, taking your time to aim it precisely on your foot, and in spite of all the possible warnings and error messages that are shouted at you… Yeaaaah not really: #include #include #include static char a[128]; static char b[128]; int main(int argc, char *argv[]) { (void)argc; strcpy(a + atoi(argv[1]), "owned."); printf("…

And many (myself included) think that the compiler should not warn about this code, even if it can potentially exhibit undefined behavior, because it would make it impossible to write code at all without warnings. (A good static analyzer or code reviewer should call it out, though.)

That's completely fair. I'm not criticising the compiler not complaining about this code, I'm providing a counter-point to rumanator's assertion that:

> UB is a kin of you intentionally pointing your gun to your foot, taking your time to aim it precisely on your foot, and in spite of all the possible warnings and error messages that are shouted at you…

Because they could hardly be more wrong, the average UB is completely invisible to static analysers because it's a dynamic condition which the type system is not smart enough to move to static. That's why it's an UB and not, say, a compile error.

Re: “C is how the computer works” is a dangerous mindset for C programmers

#386

Post by gpderetta »

Symmetry wrote: post #175
gpderetta wrote: post #34

Earlier quoted context omitted.

You are never going to get any guaranteed sensible behaviour for a double free or an use after free [1]. In comparison to those giant issues, all other instances of UB are minor. [1] well, you can today by swapping malloc for a GC-enabled implementation, but the fact is that almost nobody does.

Surely signed integer overflow is also a big problem. And reads from uninitialized memory.

I don't think integer overflow itself is a big deal. Unbounded array access, especially local array acces, is though, and I forgot about it.

Re: “C is how the computer works” is a dangerous mindset for C programmers

#387

Post by [deleted] »

Symmetry wrote: post #175
gpderetta wrote: post #34

Earlier quoted context omitted.

You are never going to get any guaranteed sensible behaviour for a double free or an use after free [1]. In comparison to those giant issues, all other instances of UB are minor. [1] well, you can today by swapping malloc for a GC-enabled implementation, but the fact is that almost nobody does.

Surely signed integer overflow is also a big problem. And reads from uninitialized memory.

[deleted]
Post reply on HN