4 ms·

> Although anyone worth their salt should recognize the halting problem Bah humbug. You can be a totally competent engineer and not immediately recognise the h

> Although anyone worth their salt should recognize the halting problem Bah humbug. You can be a totally competent engineer and not immediately recognise the halting problem, just like you can be a totally competent auto-mechanical engineer and not recognise a oxidation-reduction reaction. You can solve high-value real business problems every day for the rest of your life and never encounter a single decision that will be meaningfully informed by knowing about the halting problem. Computer science != software engineering.

dragonwriter 14y ago
> You can solve high-value real business problems every day for the rest of your life and never encounter a single decision that will be meaningfully informed by knowing about the halting problem. I dunno; I find that plenty of times dealing with fairly pedestrian business-problem requests its not uncommon to run into something that is desired that is equivalent to solving the halting problem; recognizing the difference between problems that are merely difficult and potentially expensive and risky investments of time and ones that are knowably impossible is pretty useful in terms of choosing where to allocate time and effort. > Computer science != software engineering. True, but software engineering depends on computer science, and, as in any form of engineering, understanding the well-known outer theoretical limits of what can be done is pretty important to engineering.
- mseebach 14y ago
  A good software engineer will know that there are limits to his capabilities, so my point is that in practice it's useless to differentiate between "merely difficult and potentially expensive and risky investments of time" and "knowably impossible", because, with the resources at hand, the former will, in fact, be impossible. > True, but software engineering depends on computer science, and, as in any form of engineering, understanding the well-known outer theoretical limits of what can be done is pretty important to engineering. I disagree - you can get by very well by understanding the inner, practical limits. Again, just like an auto-mechanical engineer: He doesn't need to understand the details of combustion or the process of refining oil, just enough to understand it works in the context of his domain: engineering cars. On the other hand, he also needs to know a little about suspension (but not the calculus of the harmonic oscillator) and enough metallurgy to weld the chassis safely. And don't get me started on computer scientists that can't code.
  - dragonwriter 14y ago
    > A good software engineer will know that there are limits to his capabilities, so my point is that in practice it's useless to differentiate between "merely difficult and potentially expensive and risky investments of time" and "knowably impossible", because, with the resources at hand, the former will, in fact, be impossible. In practice, many of the most useful things to invest time and energy in are difficult, potentially expensive, and risky (often, because of the risk, you want to dual track this with a less-risky, lower-payoff approach) things that have high payoffs if successful. OTOH, the knowably impossible things are dead ends. So, no, they aren't the same thing in practice.

dragonwriter 14y ago

> You can solve high-value real business problems every day for the rest of your life and never encounter a single decision that will be meaningfully informed by knowing about the halting problem. I dunno; I find that plenty of times dealing with fairly pedestrian business-problem requests its not uncommon to run into something that is desired that is equivalent to solving the halting problem; recognizing the difference between problems that are merely difficult and potentially expensive and risky investments of time and ones that are knowably impossible is pretty useful in terms of choosing where to allocate time and effort. > Computer science != software engineering. True, but software engineering depends on computer science, and, as in any form of engineering, understanding the well-known outer theoretical limits of what can be done is pretty important to engineering.

mseebach 14y ago
A good software engineer will know that there are limits to his capabilities, so my point is that in practice it's useless to differentiate between "merely difficult and potentially expensive and risky investments of time" and "knowably impossible", because, with the resources at hand, the former will, in fact, be impossible. > True, but software engineering depends on computer science, and, as in any form of engineering, understanding the well-known outer theoretical limits of what can be done is pretty important to engineering. I disagree - you can get by very well by understanding the inner, practical limits. Again, just like an auto-mechanical engineer: He doesn't need to understand the details of combustion or the process of refining oil, just enough to understand it works in the context of his domain: engineering cars. On the other hand, he also needs to know a little about suspension (but not the calculus of the harmonic oscillator) and enough metallurgy to weld the chassis safely. And don't get me started on computer scientists that can't code.
- dragonwriter 14y ago
  > A good software engineer will know that there are limits to his capabilities, so my point is that in practice it's useless to differentiate between "merely difficult and potentially expensive and risky investments of time" and "knowably impossible", because, with the resources at hand, the former will, in fact, be impossible. In practice, many of the most useful things to invest time and energy in are difficult, potentially expensive, and risky (often, because of the risk, you want to dual track this with a less-risky, lower-payoff approach) things that have high payoffs if successful. OTOH, the knowably impossible things are dead ends. So, no, they aren't the same thing in practice.