
Myths programmers believe - atilaneves
https://atilanevesoncode.wordpress.com/2018/06/12/myths-programmers-believe/
======
eesmith
"C is magically fast."

The use of "magic" turns the viewpoint into a strawman position. Who thinks it
is "magically" fast. Some, perhaps, but enough to consider it a view held by
large numbers of programmers?

My experience is that hand-tuned assembly slows down over time relative to C,
because C compilers keep getting more clever in what they optimize, and are
able to handle new instruction sets with different timing profiles.

The text after "Line coverage is a measure of test quality" only shows that
line coverage is not a _perfect_ measure of test quality. It could still be an
approximate measure of test quality.

The author writes "Programmers that comment on Hacker News or Proggit links
are not a randomly sampled cross section of the industry. They’re better."

Is there any evidence for that? Or is that a myth as well?

Overall these are misconceptions that some programmers have, and mostly junior
programmers at that. I was hoping for something more along the lines of
[https://www.mjt.me.uk/posts/falsehoods-programmers-
believe-a...](https://www.mjt.me.uk/posts/falsehoods-programmers-believe-
about-addresses/) (for addresses) and
[https://www.kalzumeus.com/2010/06/17/falsehoods-
programmers-...](https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-
believe-about-names/) (for names).

~~~
atilaneves
> Who thinks it is "magically" fast. Some, perhaps, but enough to consider it
> a view held by large numbers of programmers?

In my experience, yes. Counting the number of people I've met in person and
the ones whose opinions I've read online, there are dozens of people who seem
to believe this. Do I have stats on this? No. It's just my anecdotal evidence.
As is the rest of the list.

> My experience is that hand-tuned assembly slows down over time relative to C

My point was that other native code AOT languages do just as well or better. I
wasn't advocating writing assembly, I doubt I'd do as good of a job as the
people who write compiler backends.

> The text after "Line coverage is a measure of test quality" only shows that
> line coverage is not a perfect measure of test quality. It could still be an
> approximate measure of test quality.

Fair point.

> Is there any evidence for that? Or is that a myth as well?

Possibly a myth I believe in myself. It's my anectodal evidence, and I'd love
to be proven wrong by actual data.

> Overall these are misconceptions that some programmers have, and mostly
> junior programmers at that

My experience is that senior programmers are worse, because they refuse to
acknowledge they might be wrong.

~~~
eesmith
What does "magically" mean to you?

If I say "the C compiler has millennia of work by a small army of clever
people", do you think I'm saying it's "magic"?

You wrote "My point was that other native code AOT languages do just as well
or better"

In that section you only mention C and assembly. It is not until much later
mention other AOT languages.

BTW, you wrote "C maps closely to hardware. / If “hardware” means a PDP11 or a
tiny embedded device, sure."

Is that not also a myth?
[https://en.wikipedia.org/wiki/PDP-11_architecture#Myth_of_PD...](https://en.wikipedia.org/wiki/PDP-11_architecture#Myth_of_PDP-11_influence_on_programming_languages)

As
[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.138...](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.138.35&rep=rep1&type=pdf)
points out, C was implemented for other systems within its first year. Surely
any strong biases towards a PDP-11 specific hardware would have been noticed
very early on.

~~~
atilaneves
> What does "magically" mean to you?

That by virtue of using a C compiler the code will, with no effort on my part,
run faster than equivalent code written in a different language. That, if an
implementation exists in C, that no other implementation can beat it.

I'm railing on against it because I've met people who believe that first
paragraph, literally.

> If I say "the C compiler has millennia of work by a small army of clever
> people", do you think I'm saying it's "magic"?

No. But one can use the same backends as the current C compilers for other
languages. The results will be the same.

> In that section you only mention C and assembly. It is not until much later
> mention other AOT languages.

My bad. Sometimes things are obvious to me and I incorrectly assume that other
people will get what I'm saying.

> Is that not also a myth?
> [https://en.wikipedia.org/wiki/PDP-11_architecture#Myth_of_PD...](https://en.wikipedia.org/wiki/PDP-11_architecture#Myth_of_PD..).

From the link you posted:

"However, the C programming language did take advantage of several low-level
programming features of the PDP-11, resulting in their inclusion into new
processor".

I'd say no to the myth question. Reasonable people may disagree.

> C was implemented for other systems within its first year

I don't doubt it. Those systems were far, far simpler than an last-gen x86
processor.

My point isn't that "it's fancy PDP11 assembly", it's that today's hardware
isn't even close to being represented by C. Or, at the very least, no more so
than alternatives.

I've seen a lot of people write that they can see the assembly that would be
generated when they read C. I don't think they've looked at the output of a
compiler in a long while if that's the case.

~~~
eesmith
You used 'magically' twice, so the definition you just gave is incomplete. The
second use was "GC languages are magically slow."

Yes, the C language took advantage of byte addressing on the PDP-11, and most
computers since then support byte addressing because of C.

That's hardly the same as "C maps closely to a PDP-11", which is the claim you
made that I am arguing is a myth.

The link I gave to
[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.138...](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.138.35&rep=rep1&type=pdf)
describes "THE MACHINE MODEL OF UNIX". Nothing about that model is closely
tied to the PDP-11 hardware, that I can tell.

C-with-intrinsics does a decent job of matching the machine's instruction set,
with a fallback to be able to support machines which don't support specific
instructions.

FWIW, no programming language, not even assembly, is able to handle "cache
hiearchies, cache lines, memory prefetching, out-of-order execution, etc".

------
atilaneves
Author here. A list of beliefs about programming that I maintain are
misconceptions.

