Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The compiler is your best friend

blog.daniel-beskin.com

Post reply on HN
Print view View original

11–20 of 149 posts

Re: The compiler is your best friend

#11

Post by addaon »

JohnFen wrote: post #8
skydhash wrote: post #4

Earlier quoted context omitted.

A comment "this CANNOT happen" has no value on itself. Unless you've formally verified the code (including its dependencies) and have the proof linked, such comments may as well be wishes and prayers. Yes, sometimes, the compiler or the hardware have bugs that violate the premises you're operating on, but that's rare. But most non pure algorithms (side effects and external systems) have documented failure cases.

> A comment "this CANNOT happen" has no value on itself. I think it does have some value: it makes clear an assumption the programmer made. I always appreciate it when I encounter comments that clarify assumptions made.

But if you spell that `assert(false)` instead of as a comment, the intent is equally clear, but the behavior when you're wrong is well-defined.

Re: The compiler is your best friend

#12

Post by the__alchemist »

LegionMammal978 wrote: post #2

> How many times did you leave a comment on some branch of code stating "this CANNOT happen" and thrown an exception? Did you ever find yourself surprised when eventually it did happen? I know I did, since then I at least add some logs even if I think I'm sure that it really cannot happen. I'm not sure what the author expects the program to do when there's an internal logic error that has no known cause and no defini…

This is what rust's `unreachable()!` is for... and I feel hubris whenever I use it.

Re: The compiler is your best friend

#13

Post by eterm »

addaon wrote: post #11
JohnFen wrote: post #8

Earlier quoted context omitted.

> A comment "this CANNOT happen" has no value on itself. I think it does have some value: it makes clear an assumption the programmer made. I always appreciate it when I encounter comments that clarify assumptions made.

But if you spell that `assert(false)` instead of as a comment, the intent is equally clear, but the behavior when you're wrong is well-defined.

Better yet, `assert(false, message)`, with the message what you would have written in the comment.

Re: The compiler is your best friend

#14

Post by JohnFen »

addaon wrote: post #11
JohnFen wrote: post #8

Earlier quoted context omitted.

> A comment "this CANNOT happen" has no value on itself. I think it does have some value: it makes clear an assumption the programmer made. I always appreciate it when I encounter comments that clarify assumptions made.

But if you spell that `assert(false)` instead of as a comment, the intent is equally clear, but the behavior when you're wrong is well-defined.

I agree that including that assert along with the comment is much better. But the comment alone is better than nothing, so isn't without value.

Re: The compiler is your best friend

#15

Post by LegionMammal978 »

skydhash wrote: post #10
JohnFen wrote: post #8

Earlier quoted context omitted.

> A comment "this CANNOT happen" has no value on itself. I think it does have some value: it makes clear an assumption the programmer made. I always appreciate it when I encounter comments that clarify assumptions made.

Such comments rot so rapidly that they're an antipattern. Such assumptions are dangerous and I would point it out in a PR.

Do you not make such a tacit assumption every time you index into an array (which in almost all languages throws an exception on bounds failure)? You always have to make assumptions that things stay consistent from one statement to the next, at least locally. Unless you use formal verification, but hardly anyone has the time and resources for that.

Re: The compiler is your best friend

#16

Post by addaon »

eterm wrote: post #13
addaon wrote: post #11

Earlier quoted context omitted.

But if you spell that `assert(false)` instead of as a comment, the intent is equally clear, but the behavior when you're wrong is well-defined.

Better yet, `assert(false, message)`, with the message what you would have written in the comment.

`assert(false)` is pronounced "this can never happen." It's reasonable to add a comment with /why/ this can never happen, but if that's all the comment would have said, a message adds no value.

Re: The compiler is your best friend

#17

Post by eterm »

addaon wrote: post #16
eterm wrote: post #13

Earlier quoted context omitted.

Better yet, `assert(false, message)`, with the message what you would have written in the comment.

`assert(false)` is pronounced "this can never happen." It's reasonable to add a comment with /why/ this can never happen, but if that's all the comment would have said, a message adds no value.

Oh I agree, literally `assert(false, "This cannot happen")` is useless, but ensuring message is always there encourages something more like, `assert(false, "This implies the Foo is Barred, but we have the Qux to make sure it never is")`.

Ensuring a message encourages people to state the assumptions that are violated, rather than just asserting that their assumptions (which?) don't hold.

Re: The compiler is your best friend

#18

Post by skydhash »

LegionMammal978 wrote: post #15
skydhash wrote: post #10

Earlier quoted context omitted.

Such comments rot so rapidly that they're an antipattern. Such assumptions are dangerous and I would point it out in a PR.

Do you not make such a tacit assumption every time you index into an array (which in almost all languages throws an exception on bounds failure)? You always have to make assumptions that things stay consistent from one statement to the next, at least locally. Unless you use formal verification, but hardly anyone has the time and resources for that.

If such an error happens, that would be a compiler bug. Why? Because I usually do checks against the length of the array or have it done as part of the standard functions like `map`. I don't write such assumptions unless I'm really sure about the statements, and even then I don't.

Re: The compiler is your best friend

#19

Post by scubbo »

xnorswap wrote: post #5
skydhash wrote: post #3

The whole article gives a generated vibe, but I did want to point out this particular snippet > The compiler is always angry. It's always yelling at us for no good reason. It's only happy when we surrender to it and do what it tells us to do. Why do we agree to such an abusive relationship? Programming languages are a formal notation for the execution steps of a computing machine. A formal system is always built arou…

I also don't like that phrasing. It's like complaining of guard-rails while running around erratically. The guard rails aren't abusing you, they're helping you. They aren't "angry", they're just constraints.

Right, and I suspect that was the author's intent - to evoke a sympathetic frustration that newer programmers might feel, and then to point out how the frustration is ill-aimed.

Re: The compiler is your best friend

#20

Post by barishnamazov »

The "lies" described here are essentially the definition of weakly typed programming, even in statically typed languages.

Functional languages like ML/Haskell/Lisp dialects has no lies built in for decades, and it's good to see the mainstream programming (Java, TS, C++, etc.) to catch up as well.

There are also cute benefits of having strong schemas for your API as well -- for example, that endpoint becomes an MCP for LLMs automatically.

Post reply on HN