4 ms·

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 a

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 enough abd there’s no reason to challenge the assembler. But there are programming problems where that is in fact essential. It’s not a kissing contest. 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.

tonyarkles 6y ago
> Writing great asm or C is as challenging as writing great css I would argue that writing great asm that is more efficient than your idiomatic C code is going to be a very very challenging task on modern non-embedded CPUs. The compiler definitely knows more than I do about how the internal architecture works and which instructions to reorder to prevent stalls etc
- Const-me 6y ago
  > writing great asm that is more efficient than your idiomatic C code is going to be a very very challenging task SIMD intrinsics are not idiomatic C, they are idiomatic assembly. Here's an example when they improved by a factor of 3.6: https://stackoverflow.com/a/63759887/126995 https://stackoverflow.com/a/63759887/126995 That's not an unusual outcome.
- mtzet 6y ago
  This easily turns into a strawman. Does writing good C code include checking the disassembly and reworking the C code when the compiler produces bad results? I've seen several examples of the compiler being brilliant until suddenly a simple change makes it not brilliant at all anymore. Compilers are just tools.
- jimmaswell 6y ago
  Writing assembly pales in comparison to tracking down some of the more ridiculous CSS problems. Winforms got a lot of hate for some reason I don't understand, but designing with it in Visual Studio is the easiest, best, most sane layout/designing experience I've ever had. It makes me wish the web was more like that.
lmm 6y ago
> 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.
- cipherboy 6y ago
  > 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). Take some time looking at established open source projects where IBM has heavily invested in optimizing for the POWER architecture. I'm thinking things like glibc, gmp, Golang, openssl, ... The results they get from their hand rolled assembly far exceeds what gcc/llvm spit out. (At least, it did 2-3 years ago.) Back when the Linux Technology Center (LTC) was a thing, I was fortunate enough to meet many of the individuals working on these projects. They are all wizards. Brilliant. One of them retired recently and went on to start pveclib to make some of these optimizations in number crunching more accessible to others: https://github.com/open-power-sdk/pveclib https://github.com/open-power-sdk/pveclib I was once in his office asking about assembly instructions for SHA-3 (a project that sadly didn't go very far) and he could quote useful scalar/vector instructions to me and their timing/latency stats faster than I could find them in the manual.
- Const-me 6y ago
billjings 6y ago
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.
- progre 6y ago
  It's Amiga Smalltalk, I think?
  - billjings 6y ago
    You are correct, sir. I must have had commodore on the mind after that VIC20 Doom port made the rounds recently.
coddle-hark 6y ago
> 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.
spyckie2 6y ago
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 the machine works. The takeaway should be - if I'm designing an API/Language/framework, I should figure out how much I'm relying on an engineer's discipline to make the code great (performant, robust, secure, etc). If I can reduce that reliance, the API/Language/Framework becomes better.
- hrktb 6y ago
  I like the focus on scale in the title, and think it’s very apt. Requiring discipline is not superior or inferior, but doesn’t scale. It’s then your to decide how much it matters: do you have/need to only focus on a small group or are you tools targeted at a wide audience or you want it to widely succeed ? The answers to that question won’t be the same for everyone.
  - spyckie2 6y ago
    My usage of inferior/superior is contextualized mainly to scaling but the article mentioned many more things other than scale in the anecdotes (like producing better code overall). Maybe the vagueness of the word choice is a bit controversial in this definition-sensitive environment.
- imtringued 6y ago
  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.
- mlthoughts2018 6y ago
  > “ 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.” I think this is what the parent comment that you responded to is saying is totally bogus. A good example is Python. In my company, the teams using Python run circles around the teams using C++ and Java. The Python teams ship higher quality stuff that is both more reliable (it turns out that lack of a compiler for various static checks not only doesn’t make anything more reliable, but also slows things down unreasonably on large code bases), and easier to modify and adapt to changing requirements.

tonyarkles 6y ago

> Writing great asm or C is as challenging as writing great css I would argue that writing great asm that is more efficient than your idiomatic C code is going to be a very very challenging task on modern non-embedded CPUs. The compiler definitely knows more than I do about how the internal architecture works and which instructions to reorder to prevent stalls etc

Const-me 6y ago
> writing great asm that is more efficient than your idiomatic C code is going to be a very very challenging task SIMD intrinsics are not idiomatic C, they are idiomatic assembly. Here's an example when they improved by a factor of 3.6: https://stackoverflow.com/a/63759887/126995 https://stackoverflow.com/a/63759887/126995 That's not an unusual outcome.
mtzet 6y ago
This easily turns into a strawman. Does writing good C code include checking the disassembly and reworking the C code when the compiler produces bad results? I've seen several examples of the compiler being brilliant until suddenly a simple change makes it not brilliant at all anymore. Compilers are just tools.
jimmaswell 6y ago
Writing assembly pales in comparison to tracking down some of the more ridiculous CSS problems. Winforms got a lot of hate for some reason I don't understand, but designing with it in Visual Studio is the easiest, best, most sane layout/designing experience I've ever had. It makes me wish the web was more like that.

lmm 6y ago

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

cipherboy 6y ago
> 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). Take some time looking at established open source projects where IBM has heavily invested in optimizing for the POWER architecture. I'm thinking things like glibc, gmp, Golang, openssl, ... The results they get from their hand rolled assembly far exceeds what gcc/llvm spit out. (At least, it did 2-3 years ago.) Back when the Linux Technology Center (LTC) was a thing, I was fortunate enough to meet many of the individuals working on these projects. They are all wizards. Brilliant. One of them retired recently and went on to start pveclib to make some of these optimizations in number crunching more accessible to others: https://github.com/open-power-sdk/pveclib https://github.com/open-power-sdk/pveclib I was once in his office asking about assembly instructions for SHA-3 (a project that sadly didn't go very far) and he could quote useful scalar/vector instructions to me and their timing/latency stats faster than I could find them in the manual.
Const-me 6y ago

billjings 6y ago

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.

progre 6y ago
It's Amiga Smalltalk, I think?
- billjings 6y ago
  You are correct, sir. I must have had commodore on the mind after that VIC20 Doom port made the rounds recently.

coddle-hark 6y ago

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

spyckie2 6y ago

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 the machine works. The takeaway should be - if I'm designing an API/Language/framework, I should figure out how much I'm relying on an engineer's discipline to make the code great (performant, robust, secure, etc). If I can reduce that reliance, the API/Language/Framework becomes better.

hrktb 6y ago
I like the focus on scale in the title, and think it’s very apt. Requiring discipline is not superior or inferior, but doesn’t scale. It’s then your to decide how much it matters: do you have/need to only focus on a small group or are you tools targeted at a wide audience or you want it to widely succeed ? The answers to that question won’t be the same for everyone.
- spyckie2 6y ago
  My usage of inferior/superior is contextualized mainly to scaling but the article mentioned many more things other than scale in the anecdotes (like producing better code overall). Maybe the vagueness of the word choice is a bit controversial in this definition-sensitive environment.
imtringued 6y ago
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.
mlthoughts2018 6y ago
> “ 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.” I think this is what the parent comment that you responded to is saying is totally bogus. A good example is Python. In my company, the teams using Python run circles around the teams using C++ and Java. The Python teams ship higher quality stuff that is both more reliable (it turns out that lack of a compiler for various static checks not only doesn’t make anything more reliable, but also slows things down unreasonably on large code bases), and easier to modify and adapt to changing requirements.