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

91–100 of 173 posts

Re: Discipline Doesn’t Scale

#91

Post by rigaspapas »

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…

Exactly. With so many people out there advertising themselves as "software engineers" but being "coders", companies fail to produce maintainable code without a bunch of strict rules. Coding manifestos are a must these days, otherwise you end up with a codebase that looks like the Tower of Babel.

Re: Discipline Doesn’t Scale

#92

Post by lioeters »

scandox wrote: post #85

> The performant is often not talked about in the same sentences as its usual companion species, the irrelevant. What I find is that programmers I've worked with who have been the most preoccupied with performance always seems to have focused their optimizations in the least valuable areas. It's as if performance mania is directly correlated with a kind of architecture blindness.

This week I had to deal with the exact thing you mention. A pull request for "performance optimization", basically a proposal to unwrap a higher abstraction to do it at a lower level, manually and directly.

Yes, it does save a few function calls and instantiating a class - but that's not where the real bottleneck is. The proposed changes would require rewriting large amounts of code elsewhere, making the logic more verbose and complex.

It took some effort to convince the person that the trade-off isn't worth it. I tried to be diplomatic, but I'm afraid they took it personally that the pull request was declined.

I wish I could have proved my objection with some metrics - how many milliseconds were shaved off by the proposal, versus the increased "cyclomatic complexity", as a measurement of its detrimental effect on the code base.

Re: Discipline Doesn’t Scale

#93

Post by ChrisMarshallNY »

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.

Sadly, you are correct, but that’s not new. This has been the case throughout history.

I was just thinking about the difference between “good,” and “excellent.”

If we look at the difference between a Henkels kitchen knife, and a Japanese Takayuki knife, we are talking exponentially divergent costs. The Takayuki is definitely a lot better than the Henkels, but is it twenty times as good, as the price difference might suggest?

But Henkels makes far better knives than most of the disposable crap out there. It costs more; usually two or three times as much as a “standard quality” knife. Worth it, though.

That’s sort of the “sweet spot” I aim for, and we don’t get there, without discipline, consistency, and patience.

Re: Discipline Doesn’t Scale

#94

Post by martinleslie »

jb1991 wrote: post #83

> Back in my day, everybody knew “no Markdown around town” and “don’t code in an IDE after Labour Day” what the heck do those phrases mean?

They're references to old fashioned sartorial etiquette: https://sartorialnotes.com/2016/09/02/never-wear-brown-in-to... and https://learningenglish.voanews.com/a/why-americans-don-t-we...

Re: Discipline Doesn’t Scale

#95

Post by lioeters »

foerbert wrote: post #42
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…

This is one of the few times I've seen anybody mention threading in Ada in this sort of discussion. I've become quite fond of the language, and my first brush over the tasking stuff left me fairly impressed/interested. However actually getting into it is something I've been meaning to do, so I don't really have much experience with it in practice. So I'm quite curious, what problems with it you were referring to?

Not OP, and not familiar with Ada - but this might go into the limitations of Ada's concurrency model:

Rendezvous Facilities: Concurrent C and the Ada Language - https://www.computer.org/csdl/journal/ts/1988/11/e1546/13rRU...

> The concurrent programming facilities in both Concurrent C and the Ada language are based on the rendezvous concept. Although these facilities are similar, there are substantial differences.

> Facilities in Concurrent C were designed keeping in perspective the concurrent programming facilities in the Ada language and their limitations. Concurrent C facilities have also been modified as a result of experience with its initial implementations.

> The authors compare the concurrent programming facilities in Concurrent C and Ada and show that it is easier to write a variety of concurrent programs in Concurrent C than in Ada.

Re: Discipline Doesn’t Scale

#96

Post by olau »

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…

IMHO, types for function parameters depends on the use case.

If you have a function in a standard library, types are obviously helpful, albeit it can be convoluted if they are templated.

On the other end of the scale, if you have a little helper function used to reduce duplication/increase readability in another function, explicit typing easily becomes busywork. This is where duck typing/templates shines.

I once sent a suggestion to the C++ committee people that they allowed easy templating of function parameters (something like "auto foo(auto bar)"), but I don't think people who are not used to duck typing appreciate how much it helps in the grunt work inside modules. At least, I didn't myself.

Re: Discipline Doesn’t Scale

#98

Post by bluetomcat »

ChrisMarshallNY wrote: post #93
bluetomcat wrote: post #89

Earlier quoted context omitted.

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.

Sadly, you are correct, but that’s not new. This has been the case throughout history. I was just thinking about the difference between “good,” and “excellent.” If we look at the difference between a Henkels kitchen knife, and a Japanese Takayuki knife, we are talking exponentially divergent costs. The Takayuki is definitely a lot better than the Henkels, but is it twenty times as good, as the price difference might…

Germany seems to be doing quite well in producing exactly those products from the upper-middle tier – mixing a reasonable blend of longevity, ingenuity and ergonomics, at an earthly cost. In the rest of the world and especially in "emerging markets" however, such products are often unaffordable, uncompetitive and even sometimes seen as old-fashioned. A household in India that goes from not having a kitchen cutlery set to having one cannot ever distinguish its level of quality because there is nothing else they can compare it to.

Re: Discipline Doesn’t Scale

#99

Post by timwaagh »

dusted wrote: post #57

While hardware engineers come up with faster and faster computers, software engineers come up with slower and slower and slower software. While I agree that having nice and easier thing is nice, and easier, performance is always relevant, if not for pride or principle, at least think about the environment, computer processors and memory chips consume electricity, and are really inefficient.. How many percentage of th…

if that's a business priority, that's a business priority. But it's not up to developers to set those.

Re: Discipline Doesn’t Scale

#100

Post by dkersten »

adwn wrote: post #41
jandrewrogers wrote: post #11

Earlier quoted context omitted.

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…

> Locking is a performance [...] destroying operation That is incorrect. Properly designed and implemented mutexes (like in the parking_lot crate [1]) are extremely fast in the uncontented case, and need just one byte of overhead (and no heap-allocated memory) per mutex. In the contented case, a lock-free algorithm still has to deal with arbitration between the different threads, so it's typically not faster than a l…

> it's typically not faster than a lock-based approach

A common train of thought seems to be "locks are slow, so lock free must be fast", while lock-free says nothing about performance -- only about forward progress.

Post reply on HN