4 ms·

Lots of programmers forget that they should also be engineers, and not only computer scientists (or wannabe computer scientists). I can still remember how duri

Lots of programmers forget that they should also be engineers, and not only computer scientists (or wannabe computer scientists). I can still remember how during the first programming class I took at uni 20 years ago the teacher told us that "engineering is all about compromises and especially about what compromises you should choose to make or not" (in that context she was talking about memory vs processor usage), and while I managed to barely pass her class that piece of advice has stuck to me ever since. Looking at things through the compromise lenses (for lack of a better phrase) would eliminate lots of misunderstandings rightfully pointed out by the OP in this article.

deleted 7y ago
[deleted]
totalZero 7y ago
The failure of engineering in the presented hypothetical examples is a failure to understand the use case. I say this because I remember a class I took in college where I built a chat application and the TA chided me for using a hashed message ID instead of using random number generation. I was concerned that eventually there would be collisions and that would lead a message to either be undelivered or delivered to two parties (depending on implementation). The TA said "yeah but that's an infinitesimal risk." The problem with his view was that the intended user group would eventually see this failure occur. It's not an avoidable edge case, it's a bug that will impact the general use case. The failure could occur on an important message ("I'm gonna be at work late, can you pick up the kids") or a sensitive one ("I can't believe you cheated on me with our babysitter"), and the user would have no idea what happened. The article mentions NSA hacking and aggressive computation on a small microprocessor, but those issues are both easily avoidable by the atypical user. Are you a spy? Don't rely on HTTPS. Are you building an embedded system? Learn how to use C++ instead of Python. There is plenty of room within engineering to have sound practices that use computer science to mitigate edge cases. A problem arises when those edge cases don't affect the intended user, or are easily and obviously mitigated by the user choosing a better tool.
- gridlockd 7y ago
  If the chance of a collision is literally infinitesimal then the failure will not occur, period. In practice the chance may be just extremely low but then so is the chance that your hash algorithm causes a collision. In fact, that should be more likely for the same number of bits.
- test1235 7y ago
  So would you accept that your solution is sound, from an engineering perspective, but could be considered overkill for a college class?
  - gridlockd 7y ago
    A sufficiently large and properly generated random number is as unlikely or less likely to collide than a sufficiently large hash. However, using the random number is strictly simpler to implement, therefore it wins out from an engineering standpoint, unless you do not have access to proper RNG.
  - totalZero 7y ago
    Depends where you go to school.
- scatters 7y ago
  If the chance of a random number collision is low enough, it becomes likelier that a message will be undelivered or double-delivered due to hardware error (a "cosmic ray", though more likely thermal noise or radioactivity). Quantum computing in particular hugely relies on the observation that an infinitesimal chance of error is as good as a zero chance. And of course, hashes can collide as well.
- ubu7737 7y ago
  Using GUIDv4 presents an infinitesimal risk of collision, particularly given that GUIDv4 space is partitioned by the clock, and globally clocks are roughly synchronized. It's the kind of edge case that you worry about when you are also optimistic that you might win the Powerball lottery in your lifetime. IOW: bad at math.
jkoudys 7y ago
That's a good perspective. What's really lacking from so many of the "bad" comments is the context of the original comment. If you drop the context of someone using Python to process a moderate amount of text on a large, non-real-time system, then project your own context where it doesn't work, then sure python is not a good choice. If you can't agree on a basic context, or choose to force a context on them, then there's no compromise. Like in your teacher's example, you can't compromise between memory and cpu if you have no idea which you care about more. They're mostly of the format "I like spoons because they can pick up liquids!", then the reply is "no forks are much better because they have tines to stab with!", without anyone saying if they want to eat soup or spaghetti.
- zelias 7y ago
  This is spot on. As the old saying goes, "you can't have an argument about euthanasia with someone who thinks euthanasia is a musical group."
  - ourmandave 7y ago
    Every reviewer of their performances says, "They're killing it!"
- SkyBelow 7y ago
  >If you drop the context of someone using Python to process a moderate amount of text on a large, non-real-time system, then project your own context where it doesn't work, then sure python is not a good choice. If you can't agree on a basic context, or choose to force a context on them, then there's no compromise. There may also be past traumatic experiences that are sought to be avoided. How many times does it take for some management to grab your local working python solution, slam it into production, and then complain when it falls apart? Even with a single such instance, you begin to look at things with the view that the context may be shifted away from the intention. In such a situation, you are fully aware the context is locally with 1,000 files and not in some production environment with some 1,000,000,000, but you are rejecting the notion that those contexts can be so completely separated because a past instance showed such separations can be undone. Once bitten twice shy.
deleted 7y ago
[deleted]
AnimalMuppet 7y ago
Absolutely. In software engineering (a somewhat different field from computer science), the answer is almost always "it depends".

deleted 7y ago

[deleted]

totalZero 7y ago

The failure of engineering in the presented hypothetical examples is a failure to understand the use case. I say this because I remember a class I took in college where I built a chat application and the TA chided me for using a hashed message ID instead of using random number generation. I was concerned that eventually there would be collisions and that would lead a message to either be undelivered or delivered to two parties (depending on implementation). The TA said "yeah but that's an infinitesimal risk." The problem with his view was that the intended user group would eventually see this failure occur. It's not an avoidable edge case, it's a bug that will impact the general use case. The failure could occur on an important message ("I'm gonna be at work late, can you pick up the kids") or a sensitive one ("I can't believe you cheated on me with our babysitter"), and the user would have no idea what happened. The article mentions NSA hacking and aggressive computation on a small microprocessor, but those issues are both easily avoidable by the atypical user. Are you a spy? Don't rely on HTTPS. Are you building an embedded system? Learn how to use C++ instead of Python. There is plenty of room within engineering to have sound practices that use computer science to mitigate edge cases. A problem arises when those edge cases don't affect the intended user, or are easily and obviously mitigated by the user choosing a better tool.

gridlockd 7y ago
If the chance of a collision is literally infinitesimal then the failure will not occur, period. In practice the chance may be just extremely low but then so is the chance that your hash algorithm causes a collision. In fact, that should be more likely for the same number of bits.
test1235 7y ago
So would you accept that your solution is sound, from an engineering perspective, but could be considered overkill for a college class?
- gridlockd 7y ago
  A sufficiently large and properly generated random number is as unlikely or less likely to collide than a sufficiently large hash. However, using the random number is strictly simpler to implement, therefore it wins out from an engineering standpoint, unless you do not have access to proper RNG.
- totalZero 7y ago
  Depends where you go to school.
scatters 7y ago
If the chance of a random number collision is low enough, it becomes likelier that a message will be undelivered or double-delivered due to hardware error (a "cosmic ray", though more likely thermal noise or radioactivity). Quantum computing in particular hugely relies on the observation that an infinitesimal chance of error is as good as a zero chance. And of course, hashes can collide as well.
ubu7737 7y ago
Using GUIDv4 presents an infinitesimal risk of collision, particularly given that GUIDv4 space is partitioned by the clock, and globally clocks are roughly synchronized. It's the kind of edge case that you worry about when you are also optimistic that you might win the Powerball lottery in your lifetime. IOW: bad at math.

jkoudys 7y ago

That's a good perspective. What's really lacking from so many of the "bad" comments is the context of the original comment. If you drop the context of someone using Python to process a moderate amount of text on a large, non-real-time system, then project your own context where it doesn't work, then sure python is not a good choice. If you can't agree on a basic context, or choose to force a context on them, then there's no compromise. Like in your teacher's example, you can't compromise between memory and cpu if you have no idea which you care about more. They're mostly of the format "I like spoons because they can pick up liquids!", then the reply is "no forks are much better because they have tines to stab with!", without anyone saying if they want to eat soup or spaghetti.

zelias 7y ago
This is spot on. As the old saying goes, "you can't have an argument about euthanasia with someone who thinks euthanasia is a musical group."
- ourmandave 7y ago
  Every reviewer of their performances says, "They're killing it!"
SkyBelow 7y ago
>If you drop the context of someone using Python to process a moderate amount of text on a large, non-real-time system, then project your own context where it doesn't work, then sure python is not a good choice. If you can't agree on a basic context, or choose to force a context on them, then there's no compromise. There may also be past traumatic experiences that are sought to be avoided. How many times does it take for some management to grab your local working python solution, slam it into production, and then complain when it falls apart? Even with a single such instance, you begin to look at things with the view that the context may be shifted away from the intention. In such a situation, you are fully aware the context is locally with 1,000 files and not in some production environment with some 1,000,000,000, but you are rejecting the notion that those contexts can be so completely separated because a past instance showed such separations can be undone. Once bitten twice shy.

deleted 7y ago

[deleted]

AnimalMuppet 7y ago

Absolutely. In software engineering (a somewhat different field from computer science), the answer is almost always "it depends".