Hacker News new | ask | show | jobs
by sjolsen 3670 days ago
>one of those things that divide programmers into two groups: one that instantly sees the elegance of this design and thinks it's so natural and obvious, and one that gets eternally confused by it.

Believe it or not, there are people who are capable of figuring out C's cute little "round trip through the integers" trick, but who would rather not deal with that bullshit every time they want to compare two values of non-numerical type. It's not elegant, it's not natural, it's only "obvious" to those of us who have had the standard workarounds for C's inexpressiveness drilled into our skulls, and if it were any different, we wouldn't bother with comparison operators in the first place!

I mean, I get that it's fun to squeeze useful semantics out of terse code, especially in an environment as constrained as C. But please don't act like the rest of us are stupid just because what you regard as elegant, we regard as more of a clever hack to be put up with for want of a simple equality operator.

2 comments

compare two values of non-numerical type

everything is "numerical" or can be interpreted as such. It's not C-specific at all, it's just a fact of how computers fundamentally operate. I suspect that might be why this issue is so divisive: if you started low-level with hardware, Asm and the like, then C does feel natural and obvious. If you started high-level with some other HLL, one that abstracts and hides this "essence", it won't.

Pointers are another example of something that is obvious to some but a huge mass of confusion and frustration to others. I've taught programming (mostly Asm and C), and this is quite common. You're not stupid, but you just aren't in the right perspective to understand it.

Those who are strong advocates of functional programming and wonder why others don't see the elegance probably think the same way about me. ;-)

>Pointers are another example of something that is obvious to some but a huge mass of confusion and frustration to others. I've taught programming (mostly Asm and C), and this is quite common. You're not stupid, but you just aren't in the right perspective to understand it.

I understand pointers. I understand integer-based encoding. I'm a firmware programmer, I started with FORTRAN and C-with-classes-style C++, I get how computers work. And do you know what makes computers work? Abstractions. Integers are just an abstraction on top of bit vectors are just an abstraction on top of memory are just an abstraction on top of flip-flops, on top of gates, transistors, digital circuitry, analog circuitry, the laws of electromagnetism -- the only reason we are able to construct something as complex as a pocket calculator and have it work at all is clear, mathematical abstraction. The fact that, in 2016, using such a fundamental abstraction as equality of non-numerical values requires anything beyond the two characters "==" is patently absurd.

My "frustration" is not a result of having trouble grasping first-year C.S. concepts. Nor is it the result of the mild incovenience of specifically having to use "strcmp" instead of "==". It's the result of working in an industry where the value of anything beyond first-year C.S. concepts is completely unrecognized, because it's not "how computers fundamentally operate." Both low-level and high-level computational abstractions are useful, and trying to accomplish anything interesting in a system which completely eschews one class of abstraction in favor of the other, whether it's C or Haskell, is hell.

But hey, it beats the hell out of Javascript :)

I don't think he was calling you stupid, podner :)

I just think "ah, it's a yes we have no bananas" and stop thinking about it :) It's nonzero cognitive load but it's not much.

I've dealt with enough active-low/inverting hardware such that "on" = 0 that it actually doesn't bother me at all. Assembly has that all through it at times.

Compared to reading code where people treat cell [1] as the first significant cell of an array ( usually translated from FORTRAN ) , this is a picnic.