5 ms·

Does anyone else consider these type of articles the clickbait of the programming world? They tend to all follow the formula of 1. Make over the top statement

by mfDjB 7y ago

Does anyone else consider these type of articles the clickbait of the programming world? They tend to all follow the formula of 1. Make over the top statement in title. 2. Vaguely address the over the top statement in content. For example the author hasn't shown us why "All" programming languages are "wrong". They haven't shown how they would fix them to make them "right". Their premises (e.g. "computation is almost always free") are flawed. I wonder, if the title was called "A rant about some popular programming language paradigms" would it be as popular?

Antoninus 7y ago
Agreed. Between Lobste.rs and HN its becoming increasingly difficult to filter out worth-while content.
- dragonwriter 7y ago
  > filter out worth-while content Isn't that the opposite of the goal?
nuclx 7y ago
"computation is almost free" actually triggered me. that's the java argument from 20 years ago, now we have go and rust. it implies electron is actually a sane approach to ui development. the author is very vague about why exactly numbers don't fit in the type system, and in which languages. first class types for numbers exist in some languages. is he advocating for default overflow checks, which bloat code size?
- dragonwriter 7y ago
  > the author is very vague about why exactly numbers don't fit in the type system No, he’s quite specific: “hardware details such as the number of bits supported by an integer add instruction show through in the language semantics.” Now, it's also true that there are quite a lot of languages where this is not true, e.g., Scheme, Haskell (IIRC with the default numeric settings), Ruby, Python, for instance, and many more have numeric types in core language or stdlib that don't face this problem but don't make them the default for simple numeric literals.
- geocar 7y ago
  > the author is very vague about why exactly numbers don't fit in the type system Numbers are hard! Consider something simple: 9999999999999999.0 - 9999999999999998.0 In discussing what is Right™ we are making a choice between all the possible Good™ ways we can deal with that expression. Here are some of the most obvious: 1. atof() could fail since the string representation doesn’t match the resulting float, but then what should happen for 0.3? I've seen this only occasionally. 2. We could use a hypothetical atonumber() which uses decimal or big float or some other representation, but what does this do to performance? This gets tried a lot. 3. We can ignore the issue and blame the programmer for not constraining the input domain to that of our function. This is what most people do. I don't personally like any of these; I've seen and experienced some of the problems with each of the approaches, so I wonder if there's a Good™ fourth option (or a fifth). Maybe it's only because I have my own ideas of what a fourth option might look like that I'm not very quick to consider this a "solved" problem to the point that someone (anyone) knows the Right™ answer, but maybe it's worth you (and others!) thinking about this too. I'm extremely interested in suggestions here.
- taylodl 7y ago
  "computation is almost free" - don't say that around the accountant at my company responsible for paying our AWS bill!
krzepah 7y ago
I simply agree with what you said. "Computation is always free" made me cringe as well. I also felt that the initial page is abruptly stopped without giving any kind of explanation. Then clicking next you get jumped into a new language implementation : /
- dllthomas 7y ago
  The statement was "almost free", which is much more defensible than "always free", even if it doesn't fit every context. If we're limiting what we mean by "computation" to a few extra non-branching instructions on data we already have, I would probably even endorse it outside particularly unusual settings.
jerome-jh 7y ago
It is not an article but the annex of a complete book, whose author was not arrogant enough to make this text the introduction. Nonetheless I agreed with most of the points and saved the URL of the table of content for later review.

by mfDjB 7y ago

Antoninus 7y ago

Agreed. Between Lobste.rs and HN its becoming increasingly difficult to filter out worth-while content.

dragonwriter 7y ago
> filter out worth-while content Isn't that the opposite of the goal?

nuclx 7y ago

"computation is almost free" actually triggered me. that's the java argument from 20 years ago, now we have go and rust. it implies electron is actually a sane approach to ui development. the author is very vague about why exactly numbers don't fit in the type system, and in which languages. first class types for numbers exist in some languages. is he advocating for default overflow checks, which bloat code size?

dragonwriter 7y ago
> the author is very vague about why exactly numbers don't fit in the type system No, he’s quite specific: “hardware details such as the number of bits supported by an integer add instruction show through in the language semantics.” Now, it's also true that there are quite a lot of languages where this is not true, e.g., Scheme, Haskell (IIRC with the default numeric settings), Ruby, Python, for instance, and many more have numeric types in core language or stdlib that don't face this problem but don't make them the default for simple numeric literals.
geocar 7y ago
> the author is very vague about why exactly numbers don't fit in the type system Numbers are hard! Consider something simple: 9999999999999999.0 - 9999999999999998.0 In discussing what is Right™ we are making a choice between all the possible Good™ ways we can deal with that expression. Here are some of the most obvious: 1. atof() could fail since the string representation doesn’t match the resulting float, but then what should happen for 0.3? I've seen this only occasionally. 2. We could use a hypothetical atonumber() which uses decimal or big float or some other representation, but what does this do to performance? This gets tried a lot. 3. We can ignore the issue and blame the programmer for not constraining the input domain to that of our function. This is what most people do. I don't personally like any of these; I've seen and experienced some of the problems with each of the approaches, so I wonder if there's a Good™ fourth option (or a fifth). Maybe it's only because I have my own ideas of what a fourth option might look like that I'm not very quick to consider this a "solved" problem to the point that someone (anyone) knows the Right™ answer, but maybe it's worth you (and others!) thinking about this too. I'm extremely interested in suggestions here.
taylodl 7y ago
"computation is almost free" - don't say that around the accountant at my company responsible for paying our AWS bill!

krzepah 7y ago

I simply agree with what you said. "Computation is always free" made me cringe as well. I also felt that the initial page is abruptly stopped without giving any kind of explanation. Then clicking next you get jumped into a new language implementation : /

dllthomas 7y ago
The statement was "almost free", which is much more defensible than "always free", even if it doesn't fit every context. If we're limiting what we mean by "computation" to a few extra non-branching instructions on data we already have, I would probably even endorse it outside particularly unusual settings.

jerome-jh 7y ago

It is not an article but the annex of a complete book, whose author was not arrogant enough to make this text the introduction. Nonetheless I agreed with most of the points and saved the URL of the table of content for later review.