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

Discipline Doesn’t Scale

sicpers.info

Post reply on HN
Print view View original

71–80 of 173 posts

Re: Discipline Doesn’t Scale

#71

Post by jchw »

boardwaalk wrote: post #39
jchw wrote: post #10

Earlier quoted context omitted.

I think this is a little oversimplified, because I’m pretty sure C++0x had move semantics and usable smart pointers prior to Rust really entering the public conscience/probably before it existed . AFAICT Rust takes a lot of inspiration from how you would “fix” C++, in ways that you could never actually do in C++ because it would break backwards compatibility.

I suppose it depends on what you would consider being “serious” about memory safety. I view move semantics as not a memory safety thing at all (in fact, use-after-move can be exactly as ugly as use-after-delete), and smart pointers as a “let’s just make things marginally better than raw raw new/delete” thing. Smart pointers in C++ can still be null, after all. Calling C++ not serious about seems a reasonable take to…

Smart pointers + static analysis + sanitizers is the best options I am aware of for improving the correctness of C++ programs, and I don't think Rust really had much to do with them. The picture painted that Rust made the C++ standards committee scramble to start addressing safety seems wrong; it feels more like there's been a mostly steady increase in safety over time without need for any outside influence.

Re: Discipline Doesn’t Scale

#72

Post by imtringued »

spyckie2 wrote: post #43
nemo44x wrote: post #6

I hate these articles that feature a programmer who works within a certain domain and assume all programming tasks are similar. Yes, it would appear there is an anti-pattern of programmers that feel like going lower level for certain things matters. It doesn’t always. Programming computers has multiple levels of abstraction for solving different problems. But there’s also this idea that the magical compiler does good…

The point of the article isn't to belittle someone for having a good, deep knowledge of machines. The foundation of most code written is built by those people. The point of the article is to point out that languages, frameworks, or apis that expect a level of discipline to write well are inferior to ones that don't expect discipline out of its coders. The takeaway shouldn't be - I as a programmer shouldn't learn how…

Well, and here I thought that discipline doesn't scale because it is not a universal concept. Having "discipline" in C will not transfer to better discipline in other languages because each language has a different feature to abuse. C might have malloc/free with catastrophic consequences but C++ has templates which lend themselves to a different type of abuse i.e. excess complexity.

Re: Discipline Doesn’t Scale

#73

Post by andi999 »

juped wrote: post #15

>but I do occasionally still hear people telling less-experienced developers that they should learn C to learn more about how their computer works. Your computer is not a fast PDP-11, all you will learn is how the C virtual machine works. Yes, this is wrong in that sense, but by learning C you learn how C works, and therefore how your computing systems, which are going to be C at some level because we live in Unix's…

Although I think learning C opens up your accessible domains of programming widely. I mean, if you know C it doesnt even take a weekend to learn (the basics of) CUDA. Or you can just buy an simple embedded system and do data aquisition easily. Also there is a reason C is often under the hood of other programming languages like Python, Tcl, and (I read on the internet) Julia, Ruby and Perl.

I dont mean you can then write these languages, but you can look under the hood and read the source code (also if you want to write extensions it is useful).

Re: Discipline Doesn’t Scale

#74

Post by andi999 »

I do not think that memory is the biggest problem here, with RAII it "only" requires medium discipline, but UB is the dragon in the closet here. Avoiding UB requires a huge amount of discipline (or luck)

Re: Discipline Doesn’t Scale

#75

Post by einpoklum »

Well, discipline is indeed difficult to scale; however:

* There is no automation for writing good code and for good design - and that too requires discipline.

* In many cases, harnesses which relax discipline requirements have costs: dependencies, larger surface area for compromising security, performance...

* Very often, the mass of undisciplined coders rely on libraries and other core pieces of code written with a lot more discipline.

Re: Discipline Doesn’t Scale

#76

Post by pizza234 »

imoverclocked wrote: post #67
pm90 wrote: post #60

Earlier quoted context omitted.

Do you think the market is not pricing it correctly? In the dawn of computing, machines were far less common, much more expensive, and society was willing to pay programmers boatloads of money to write optimized code because that was cheaper. The hardware engineers did an excellent job, they reduced costs of computing by a lot. Society is not willing to pay programmers boatloads of money to write optimized code; beca…

... or reduce software engineering salaries. Arguably, people want faster software if they also want faster hardware.

Well, consider Slack as an example.

Performance-wise, it's bottom of the barrel quality. A single developer has done, in this compartment (Ripcord), much better than their team did. If we want to consider similar languages, Microsoft did enormously better with VSC.

The result is, sadly, that Slack is still widely used.

Re: Discipline Doesn’t Scale

#77

Post by einpoklum »

jchw wrote: post #10
Animats wrote: post #7

Over a decade ago I used to argue this with the C++ committee people. Back then, they were not concerned about memory safety; they were off trying to do too much with templates. The C++ people didn't get serious about safety until Rust came along and started looking like a threat. Now they're trying to kludge Rust features into C++ by papering over the unsafe stuff with templates, with some success. But the rot under…

I think this is a little oversimplified, because I’m pretty sure C++0x had move semantics and usable smart pointers prior to Rust really entering the public conscience/probably before it existed . AFAICT Rust takes a lot of inspiration from how you would “fix” C++, in ways that you could never actually do in C++ because it would break backwards compatibility.

Everybody and their uncle have an idea about how they would "fix C++" - but these ideas mostly contradict each other and would make for rather different languages :-)

Re: Discipline Doesn’t Scale

#78

Post by didibus »

Hum, I think this person is missing the other side. It isn't that discipline will save you, it is that some programmers want power and control, and don't like restrictions. Those programmers do sometimes believe they know better, or just prefer and enjoy the creativity given to them. Thus any language that restricts you isn't something they favour.

Re: Discipline Doesn’t Scale

#80

Post by einpoklum »

boardwaalk wrote: post #39
jchw wrote: post #10

Earlier quoted context omitted.

I think this is a little oversimplified, because I’m pretty sure C++0x had move semantics and usable smart pointers prior to Rust really entering the public conscience/probably before it existed . AFAICT Rust takes a lot of inspiration from how you would “fix” C++, in ways that you could never actually do in C++ because it would break backwards compatibility.

I suppose it depends on what you would consider being “serious” about memory safety. I view move semantics as not a memory safety thing at all (in fact, use-after-move can be exactly as ugly as use-after-delete), and smart pointers as a “let’s just make things marginally better than raw raw new/delete” thing. Smart pointers in C++ can still be null, after all. Calling C++ not serious about seems a reasonable take to…

> I view move semantics as not a memory safety thing at all (in fact, use-after-move can be exactly as ugly as use-after-delete),

Note that move-destructors were also considered for C++11, and were not added for lack of time / implementation experience . And this is really too bad, because they are at least as important as move constructors if not more so; I've yet to encounter a case where you actually want to use a moved-from object after the move.

Post reply on HN