Hacker News Reader

Comment by mratsim | Hacker News Reader

Weave is my multithreading library. It's just a recap of what I went through for future reference.

I unfortunately didn't have time to go through:

- compiling glibc from source

- converting my code to C

- trying to reduce multithreaded synchronization code to a minimal example given how non-deterministic any of those bugs are

- do a write-up

That said, it seems like people went through the motions 4 months after me in this bug:

- https://sourceware.org/bugzilla/show_bug.cgi?id=25847 which affects C#, OCaml, Python

Someone also fully reimplemented Glibc condition variable in TLA+ to prove that the glibc code was buggy:

- https://probablydance.com/2020/10/31/using-tla-in-the-real-w... (at the bottom)

View on HN

Wow.

I'd normally respond with (when looking at the very complex relevant glibc code), "complexity is a code smell", but I don't understand the problem space enough to legitimately suggest that here, other than to say that in my experience programming thus far, if you require this much complexity for any part of your system, it is in all likelihood reflective of a design flaw (possibly elsewhere).

High-performance concurrency is just the kind of problem that may well require a complex solution.

Why do so many people use the word smell to disparage code? The human part of me always feels it's super douchy and elitist, and the engineer part hates it because it's inaccurate and misleading.

It's an analogy to the way we detect things like food spoilage or gas leaks by smell. For the vast majority of us most code smells are actually observed visually (Why is this nested 10 levels deep? Why are there 20 parameters to this method?) so I suppose we could start saying code eyesores, but that often has the wrong sense (even more strongly negative) than smell.

It's really only douchy or elitist if it's strictly used in an insulting or disparaging way. Most of the time when people talk about code smells it's meant to indicate, just like with real-world odd, bad, or unexpected smells: Something doesn't seem right. I could be wrong, but it warrants investigation.

Using the examples above, deep nesting and large numbers of parameters are indications of a potential problem, but are not necessarily problems. It could be that a refactoring is in order, but it may also be that everything is fine (just not pretty).

I understand the point of the analogy, my question was more why is such a bad one so popular. something something makes my hair stand up, as alternative that's actually good; used to mean the feeling of anxiety. No one mentions smells when they're talking about good code. Similar to normal american english conversations, if someone mentions a smell unprovoked, it's normally a disgusting smell. So when used against code, it's implying the code is repulsive. Which to me at least feels super insulting to respond to code (text on a screen) with such a vicseral response, of distrust/dislike.

I don't think everyone, let alone most people, makes the leap from "smell" to "repulsive". "My fridge smells funny" is not the same as "My fridge smells so bad it makes me want to puke". The first is a cause for investigation, the second is a cause for real concern.

Most code "smells" are in the former category, they are not describing the code as "repulsive" but "off". If you're making that leap then you're going to need to supply (or find) another term for what is described, for now over 20 years, as a code smell. Since most people don't have the same visceral reaction you do, they won't care.

It's a qualitative word for a qualitative assessment.

For example, it is quite possible that code that is nested 30 levels deep is provably correct. Since we are humans, is that likely? No, it is not. Or at least, it is certainly less likely than 3-level-deep code. So you look at some code and without doing any deep analysis you can make some "probably valid" assumptions which come from your experience.

If you're so bent on accurate engineering, answer me this: Why are technology choices often "fashion-driven", without any significant empirical data to support their choice over other alternatives? (My latest pet peeve in this space is widespread use of Docker.) And where data DOES exist (such as to support the statement "Functional languages produce far fewer bugs per LOC written"), why don't more programmers/engineers heed that?

This is beautiful and satisfying.

Reply on news.ycombinator.com