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

11–20 of 173 posts

Re: Discipline Doesn’t Scale

#11

Post by jandrewrogers »

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 locks by the worst-case access frequency for a core to understand contention. In practice, this is often on the order of 100ms, which means the locks are effectively contention-free and the fast path almost always wins.

Re: Discipline Doesn’t Scale

#13

Post by dllthomas »

mdwhatcott wrote: post #2

The lack of discipline doesn't scale even more than discipline.

A more precise phrasing of the sense intended by the article would be that reliance on discipline doesn't scale. Encourage discipline, supply it as you're able, but recognize that when the concern is important it probably calls for additional measures.

Re: Discipline Doesn’t Scale

#14

Post by scottlamb »

smitty1e wrote: post #3

Discipline for its own sake is certainly wasteful. What grieves me is lack of inquisitive ness and communitcation. If we're not deepening our understanding of how things work, and working together, then things get wobbly. True story: delimited text data ingest file. Guy wrote a C language file to hack the upper byte off the characters, and then write them back to disk. At a glance we think "C! This was a performance…

I think it's also important to remember that these things we sometimes consider character traits can be quite situational:

In the absence of deadlines or other external pressure, I sometimes write beautiful, uselessly incomplete code. With mild deadline pressure, I do all right. In a toxic, death march environment, I can see how teamwork and inquisitiveness might drain away and someone would write the terrible code you just described.

(See also: fundamental attribution error. I wrote the bad code because of the death march. He wrote the bad code because he's intellectually lazy.)

Re: Discipline Doesn’t Scale

#15

Post by juped »

>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 world, work.

Re: Discipline Doesn’t Scale

#16

Post by lmm »

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…

> But there’s also this idea that the magical compiler does good enough abd there’s no reason to challenge the assembler. But there are programming problems where that is in fact essential.

Citation needed. I've seen people claiming this for years, and I've yet to see a single case where handwritten assembler actually did better than spending the same amount of effort on speeding up the compiled program (e.g. taking 5 minutes to actually set the right target architecture).

> Writing great asm or C is as challenging as writing great css. But to be sure, knowing what your code actually requires hardware to do is really valuable. It matters and we don’t have abstraction in many cases to abstract that away totally.

> It doesn’t hurt to have a good idea on how the machine works.

On modern hardware both C and ASM are distractions. If you actually want to understand the performance you need to look at cache misses and mispredicted branches; reading through C or an ASM listing will only serve to mislead you. Strangely enough, the crowd that wants you to learn C seem to be the same people who are vehemently against using the kind of profiling tools that will actually tell you what's going on.

Re: Discipline Doesn’t Scale

#17

Post by quickthrower2 »

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…

I think there is a meme (in the true sense of the word, not a silly picture) where the basis of languages like C and assembler is implanted in say JavaScript and how it does things. For example references vs. values and how this affects closures. Why have a lexical scopes? All this stuff which confuses the fuck out of new programmers, might be simpler if they learned C first.

I think this can trip newbies up. Especially from bootcamps, who don't understand why their code is working, and I feel like replying with "well think about how the object is stored in memory" because none of the stuff that's built on that will make sense without it. I'd like to understand more myself. It would be useful to have some idea of what the compiler is doing with things like lexical scopes. I think that's the only way to really understand them as the abstractions are too leaky.

Re: Discipline Doesn’t Scale

#18

Post by User23 »

Whenever I hear the term discipline in the context of computing I always think of Dijkstra's excellent book A Discipline of Programming[1]. His definition of discipline makes a lot more sense to me than the one in this article. And discipline in the sense of proficiency with the predicate calculus absolutely does scale.

[1] https://www.goodreads.com/book/show/2276288.A_Discipline_of_...

Re: Discipline Doesn’t Scale

#19

Post by xxxtentachyon »

quickthrower2 wrote: post #17
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…

I think there is a meme (in the true sense of the word, not a silly picture) where the basis of languages like C and assembler is implanted in say JavaScript and how it does things. For example references vs. values and how this affects closures. Why have a lexical scopes? All this stuff which confuses the fuck out of new programmers, might be simpler if they learned C first. I think this can trip newbies up. Especia…

I think that’s all still addressed by him saying (paraphrased here) “learning C doesn’t teach you your system; it teaches you the C virtual machine.” You could just as easily teach the usefulness of lexical scoping and memory layout by teaching people a simplified version of a modern JavaScript engine and teaching them to inspect the accompanying intermediate representation. Bootcamps don’t dive into these things and give attendees intuitions for some model of computing because they know what people are paying for (learning the level of JS necessary to land a job as quickly as possible).
Post reply on HN