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

31–40 of 173 posts

Re: Discipline Doesn’t Scale

#31

Post by BeetleB »

lmm wrote: post #16
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…

I spent time with a team that wrote math functions in assembly. They also wrote them in C so they would be more portable. Their aims were similar for both - similar accuracy and performance.

The C versions were usually slower - sometimes a lot slower. They knew all the optimizations the compiler was doing and tweaked as much as they could.

In general, though, you're right. I'm particularly annoyed at universities that insist on making their students do all their microcontroller labs in assembly. When I took the course, the professor made us do only two assignments in assembly, and the rest in C. He said it had been over a decade since he had encountered a real world microcontroller problem where one needed the assembly - and he said this some decades ago.

I don't do microcontroller stuff for a living, but anecdotally, the only people I've met who insist one must program in assembly for microcontroller problems do not do it for a living.

Re: Discipline Doesn’t Scale

#32

Post by progre »

billjings wrote: post #30
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…

I hate these articles that feature a programmer who works within a certain domain and assume all programming tasks are similar. Citation needed? Last I checked, Graham was working on a C64 Smalltalk80 VM as a side project, so I presume he's not completely ignorant of low-level development. And statements like "Your computer is not a fast PDP11" are aimed directly at low level development.

It's Amiga Smalltalk, I think?

Re: Discipline Doesn’t Scale

#33

Post by overgard »

qppo wrote: post #29
overgard wrote: post #23

Earlier quoted context omitted.

I really think lock-free concurrency models are the long term best bet. Locks and shared memory scale pretty badly, on top of being super hard to get right.

Lock free algorithms and data structures are even harder to get right! And most of the canonical descriptions of them assume that you have a garbage collector and that memory allocation is a bounded operation. Neither of which is really true when you're working in constrained situations. On top of that, locking is faster than most lock-free strategies unless you deal with high contention or deterimistic guarantees (9…

When I say lock free, im suggesting concurrency that doesn't assume shared memory. I think the notion of multiple cores working on nearby memory blocks just is a bad way to do this, and so threaded models are not great. More along the lines of an actor model or how gpus subdivide work.

Re: Discipline Doesn’t Scale

#34

Post by Animats »

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…

"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 primitives.

The opposite extreme is POSIX locks. Locks are the OS's problem, and nothing in the code says what's covered by the lock. That was once standard practice and is now recognized as being bad.

Re: Discipline Doesn’t Scale

#35

Post by billjings »

progre wrote: post #32
billjings wrote: post #30

Earlier quoted context omitted.

I hate these articles that feature a programmer who works within a certain domain and assume all programming tasks are similar. Citation needed? Last I checked, Graham was working on a C64 Smalltalk80 VM as a side project, so I presume he's not completely ignorant of low-level development. And statements like "Your computer is not a fast PDP11" are aimed directly at low level development.

It's Amiga Smalltalk, I think?

You are correct, sir. I must have had commodore on the mind after that VIC20 Doom port made the rounds recently.

Re: Discipline Doesn’t Scale

#36

Post by jevgeni »

Anyone who ever tried starting Lotus/IBM Notes cares about latency and performance now. I’m sure the JVM was great for the perceived developer productivity, but it doesn’t make a better product.

Re: Discipline Doesn’t Scale

#37

Post by coddle-hark »

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…

> 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.

The thing is, sometimes you need to know how those lower layers work in order to make that judgement. If you’re writing networking code in JavaScript and don’t know what sockets are, you’re going to have a bad time sooner or later.

Re: Discipline Doesn’t Scale

#38

Post by Enhex »

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…

im pretty sure Rust builds on top of C++11's move semantics and unique_ptr.

Re: Discipline Doesn’t Scale

#39

Post by boardwaalk »

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.

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 me. Of course Rust didn’t invent all of its solutions from scratch.

Re: Discipline Doesn’t Scale

#40

Post by nightowl_games »

As a Mid Range Millenial, I fall right into age range who cut their teeth in an era just past this guy: the jquery web dev. It's amazing to read this because I think I was part of the group that began the exponential curve of new technologies. I wasn't exposed to this "hazing" at all. I was believed in. I was valued. I was encouraged to explore.

The religion of the time was to work on things that increased developer productivity time. Performance be damned. It flowed naturally at the time. Computers were (and are) fast enough to create these web apps! We just need to get more features (and better looking ones!) out the door!

And now here I am sitting on the other side, looking at all my peers work and thinking "slow down, everyone. We've made too much stuff. We need to organize and catalogue and refine and optimize"

It's like culture is a Tick/Tock cycle. This guy was a Tock - a refinement of existing technology. I was a Tick - an explosion of new technology.

And now (I believe) we are witnessing another Tock - a refinement, a culling of the weak, a centralization.

I love reading the historical programmers account. As I near 30 I realize, that I will become that, a history lesson for the fresh minds of the era.

I think I have lots to teach you. I need only to refine, cull, centralize, and catalogue my thoughts. Piece them into theories of abstraction, class hierarchies of ideas, if you will.

For I experienced the polar opposite of this. I experienced the explosion.

And yet still, I agree.

Discipline doesn't scale. This encoding of discipline into system. I agree with it.

That defines a large part of my job - to take the "best practise" and encode it into the day-to-day.

This concept: "discipline doesn't scale" is fundamental to our history. It seems trivially true.

This prose is excellent, this history lesson is important and valued, and the fable of this story rings true.

Post reply on HN