←back to thread

611 points LorenDB | 2 comments | | HN request time: 0.586s | source
Show context
quietbritishjim ◴[] No.43913531[source]
I always enjoy reading articles like this. But the truth is, having written several 100s of KLOC in C++ (i.e., not an enormous amount but certainly my fair share) I just almost never have problems with this sort accidental conversion in practice. Perhaps it might trip me up occasionally, but will be noticed by literally just running the code once. Yes, that is an extra hurdle to trip over and resolve but that is trivial compared to the alternative of creating and using wrapper types - regardless of whether I'm using Rust or C++. And the cost of visual noise of wrapper types, already higher just at the writing stage, then continues to be a cost every time you read the code. It's just not worth it for the very minor benefit it brings.

(Named parameters would definitely be great, though. I use little structs of parameters where I think that's useful, and set their members one line at a time.)

I know that this is an extremist view, but: I feel the same way about Rust's borrow checker. I just very rarely have problems with memory errors in C++ code bases with a little thought applied to lifetimes and use of smart pointers. Certainly, lifetime bugs are massively overshadowed by logic and algorithmic bugs. Why would I want to totally reshape the way that I code in order to fix one of the least significant problems I encounter? I actually wish there were a variant of Rust with all its nice clean improvements over C++ except for lifetime annotations and the borrow checker.

Perhaps this is a symptom of the code I tend to write: code that has a lot of tricky mathematical algorithms in it, rather than just "plumbing" data between different sources. But actually I doubt it, so I'm surprised this isn't a more common view.

replies(6): >>43913574 #>>43913623 #>>43913644 #>>43913894 #>>43914148 #>>43914163 #
lmm ◴[] No.43913644[source]
> I just almost never have problems with this sort accidental conversion in practice.

95% of C++ programmers claim this, but C++ programs continue to be full of bugs, and they're usually exactly this kind of dumb bug.

> will be noticed by literally just running the code once.

Maybe. If what you're doing is "tricky mathematical algorithms", how would you even know if you were making these mistakes and not noticing them?

> the cost of visual noise of wrapper types, already higher just at the writing stage, then continues to be a cost every time you read the code. It's just not worth it for the very minor benefit it brings.

I find wrapper types are not a cost but a benefit for readability. They make it so much easier to see what's going on. Often you can read a function's prototype and immediately know what it does.

> Certainly, lifetime bugs are massively overshadowed by logic and algorithmic bugs.

Everyone claims this, but the best available research shows exactly the opposite, at least when it comes to security bugs (which in most domains - perhaps not yours - are vastly more costly): the most common bugs are still the really dumb ones, null pointer dereferences, array out of bounds, and double frees.

replies(2): >>43913941 #>>43914141 #
blub ◴[] No.43913941[source]
It’s the sociology of software development.

The guild of software developers has no real standards, no certification, no proven practices outside <book> and <what $company is doing> while continuing to depend on the whims of project managers, POs and so-caled technical leaders and others which can’t tell quality code from their own ass.

There’s usually no money in writing high-quality software and almost everything in a software development project conspires against quality. Languages like Rust are a desperate attempt at fixing that with technology.

I guess it works, in a way, but these kind of blog posts just show us how inept most programmers are and why the Rust band-aid was needed in the first place.

replies(4): >>43914820 #>>43919509 #>>43924115 #>>43930136 #
pjmlp ◴[] No.43924115[source]
Software developers no, but Software Engineering does, it is a professional title in many countries, where universities and engineers are only legally allowed to use such titles after being validated.
replies(1): >>43930189 #
1. rowanG077 ◴[] No.43930189[source]
I really don't think this matters. It's the processes beyond physical engineering that make it better. I have seen the most highly accredited software devs write the worst code. I have seen self-taught devs deeply consider implication of the things they are writing and solve the problem simply. And it's not even the case that I can perceive a trend. Well except for PhDs, I have met only one PhD that I know can write actual good code.
replies(1): >>43931896 #
2. foobahhhhh ◴[] No.43931896[source]
I think if PhDs are bad at code it is because they ain't coding in a team 7.6 hours a day. It is not the PhDness rather than not being a coder. (Sone PhDs might code a lot as a hobby and be good).

You can also write a medical PhD without knowing how to do first aid on a snake bite.