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

121–130 of 173 posts

Re: Discipline Doesn’t Scale

#121

Post by blub »

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…

Rust is not a good example of a language which doesn't require discipline: on the contrary, it requires very much discipline and thinking deeply about lifetimes and resources. The difference to C++ (since that's what you've mentioned) is that the compiler double-checks everything at the end. The advance in programming language usability will not come from arcane tools like Rust, but from tools like Java, Python or Go which make previously complicated things simpler with e.g. garbage collection or coroutines.

Using "scale" is also misleading, because to use again your example C++ is a mainstream programming language and one of the most popular in the world. It towers above Rust by any thinkable metric related to scale - popularity, projects, developers, libraries, etc.

I do agree that discipline isn't enough... in the sense that one can't rely on discipline to achieve safety. This is a well known principle of safety engineering, which applies to all systems, not just SW or SW/HW systems. Discipline remains nevertheless essential, because it's one of the main things influencing the "human factor".

Re: Discipline Doesn’t Scale

#122

Post by rocqua »

jandrewrogers wrote: post #11
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’m not sure “what locks it” is a useful question. Locking is a performance and scalability destroying operation in a time when we care about both. Systems that care about both largely avoid locking (including most “lock-free” locks) altogether outside of rare cases, and in such rare cases the logic is simple. Nothing is lost by avoiding locks with good architecture. In big multi-core systems, I model the handful of…

The question is not about actual software locks.

The question is "What prevents me from making changes to this variable without breaking everything".

So the point is not "What locks guard this data" the point is, how do I determine whether I can currently modify (or even read) this data. This allows the compiler to check that, indeed, you never use the data in a way that would break things. Hence your compiler can then give guarantees about thread-safety.

Now it seems likely that, when compilers do this and you write wrong code, your conclusion might be "I need a mutex lock for this", or if performance matters, "I need to rewrite this to allow performant lockless code. But the main question remains "Can I currently modify this data without issues".

Re: Discipline Doesn’t Scale

#123

Post by Cthulhu_ »

bluetomcat wrote: post #89
ChrisMarshallNY wrote: post #84

Personally, I think Discipline is one of the things that separate “coders” from “engineers.” This sounds like it’s really a treatise on “learning to build a house by making your own nails.” Of course that won’t scale. Especially if most houses, these days, are prefab, and don’t use too many nails. But learning how to stay out of flood plains, and selecting good prefab sources, is vital to being a builder. The first o…

Our contemporary corporate and social culture doesn't encourage or reward discipline. We produce mostly throwaway stuff that has to be released as soon as possible on the market, or else the company goes out of business. The incentives for craftsmanship and diligence are just not there.

I do get it though; there is a lot of things you can do with code in addition to the minimally viable, but the cost is time and effort (short-term and long-term (e.g. maintenance)), and eventually money will run out.

You have to set a boundary for "good enough" somewhere, else you end up stuck in analysis paralysis or whatever a catchy term is.

That said, today's development tooling helps you have a baseline of quality pretty quickly; languages that do not have memory issues, compilers and typed languages, etc.

Re: Discipline Doesn’t Scale

#124

Post by mathstuf »

oblio wrote: post #110
trumpeta wrote: post #108

Earlier quoted context omitted.

I’d argue it doesn’t make sense to fix c++. A language is not about what you can do with it, its about what it doesn't let you do. C++ will continue letting you do everything in the name of backward compatibility.

At some point, that's going to stop being sustainable. I think C++ could really use what Rust calls generations. Figure out the obviously bad ideas and deprecated them over 10 year cycles. That would allow the language to shrink again, I don't think it ever did.

They're called "editions". And it was proposed to the C++ committee, but with things like ADL and SFINAE existing, making any substantial changes just isn't possible. What happens if you SFINAE on a class derived from an STL container with a method removed in Y from a module in edition Y when it is declared in a module with edition X (where it would exist)? Does the method exist or not? When using contracts from different editions which holds? In what context is the question asked?

Even things like integer promotion rules or "trivial" things like "deprecate NULL and 0 for nullptr" are likely untouchable with any edition mechanism for C++ that doesn't end up Breaking the World.

Re: Discipline Doesn’t Scale

#125

Post by archibaldJ »

Coming from the FP perspecitve, I think a useful way is to see things in terms of striking a balance between

"knowing the value of everything and the cost of nothing"

and

"knowing the cost of everything and the value of nothing"

and it is extremely context-sensitive esp with respect to the team of people making the software.

As humans we tend to forget that programmers are ultimately just machines that turn coffee into reads and writes = )

Re: Discipline Doesn’t Scale

#127

Post by jpab »

clktmr wrote: post #118
Animats wrote: post #34

Earlier quoted context omitted.

"What locks it" can include "owned by different threads". That's a lock at a higher level, really. "Lock free" data structures are tied very closely to the data being locked, and depend heavily on certain CPU operations being atomic. This is more of an issue with ARM than with x86, because ARM needs more fence instructions. Really, "lock free" programming is just locking critical sections with lower level hardware pr…

> Really, "lock free" programming is just locking critical sections with lower level hardware primitives Can fence instructions really be seen as locking mechanism? While a lock generally is bound to some data, memory fences are bound to relationships between data or a piece of code. I don't know if Rust or any other language can help you with that. Isn't the actual bad practice to expose locks at all? If the locking…

The fences aren't a locking mechanism, at least not on their own. The lower (hardware) level locks are the steps in the cache coherency protocols (potentially including explicit cache line locking signals) that allow an execution unit to, eg, perform a correct atomic compare-exchange operation on a 32/64/128-bit piece of data.

See also, eg, the LOCK prefix on x86 instructions.

(disclaimer: I only have approximate knowledge of anything, I'm not an expert)

Re: Discipline Doesn’t Scale

#128

Post by arthev »

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…

"The encouraging thing today is that we're kind of converging on good practices in language design." - doubtful that we'll arrive at good practices in language design through incremental steps from a flawed base. All the mentioned languages are low-level.

Re: Discipline Doesn’t Scale

#129

Post by rkangel »

andrewjl wrote: post #120
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…

There's something I've always been curious about wrt `auto`, and that's why have the keyword at all? In Swift for instance, one can just use `var` or `let` to express mutability and have the compiler infer the type. Is there a particular reason C++ can't, or perhaps chooses not to, do this?

I'm not sure there's a particular difference between the two except the keyword chosen. You type "auto my_var_name = func_call()" or you type "let my_var_name = func_call()". In both cases you get an inferred type for a variable.

Mutability is very different in C++ though - const is quite a complex topic, and isn't as simple as "this variable binding is/isn't mutable".

Re: Discipline Doesn’t Scale

#130

Post by rkangel »

bluetomcat wrote: post #89
ChrisMarshallNY wrote: post #84

Personally, I think Discipline is one of the things that separate “coders” from “engineers.” This sounds like it’s really a treatise on “learning to build a house by making your own nails.” Of course that won’t scale. Especially if most houses, these days, are prefab, and don’t use too many nails. But learning how to stay out of flood plains, and selecting good prefab sources, is vital to being a builder. The first o…

Our contemporary corporate and social culture doesn't encourage or reward discipline. We produce mostly throwaway stuff that has to be released as soon as possible on the market, or else the company goes out of business. The incentives for craftsmanship and diligence are just not there.

> Our contemporary corporate and social culture doesn't encourage or reward discipline

I think there is some selection bias here. The majority of particiapants in HN discussion generally people who work for startups and people who work with web technologies. The Silicon Valley culture might be focused around time to market, but there is a large (mostly unheard) group of people who exist in a very different culture. For example: C is still an incredibly popular language (for better or worse), but on HN you won't hear much about it outside the Linux Kernel.

A lot of this enterprise software development suffers from some very different problems (the time to market thing brings benefits in terms of making productivity important) but also has benefits in terms of thinking about investments long term (when done well).

Post reply on HN