5 ms·

It's really hard for me not to respond with pure snark. But I'm going to do my best. Since the essence of computing is processes, viewing all programs as proce

by jfoutz 4y ago

It's really hard for me not to respond with pure snark. But I'm going to do my best. Since the essence of computing is processes, viewing all programs as processes, it should be really easy to tell if any given process halts. But, it's not. Math has been around for a long long time, but it turns out there are some really hard problems that took thousands of years to even discover. It took a long time to decide that no internally consistent system can prove that it's internally consistent. Software, is pretty new. And software got kicked in the teeth right at its inception _because_ process and data are highly context sensitive. Now, I'd agree, that folks could probably put more thought into organization of data, and deeper thought about what process should operate on that data. But it's not like waving your hand and saying computers are about processing is particularly helpful. I don't need a machine to translate a program into its result. It might take more than my lifetime, but I can work it out with a pencil and paper. The hard part is building a process that's worth a damn. The thing flips back and forth from being an object, a row of bytes in memory somewhere, to a set of changes over time in a processor. (this could just as easily be brass gears, or punchcards in a loom). You can choose to look at it however you wish, but it's both. It's really hard to get right.

musicale 4y ago
> it should be really easy to tell if any given process halts. But, it's not. In theory, some processes could run forever. In practice, they do not. For example, sudo shutdown -h now usually works for me. If it doesn't then a hard powerdown usually does the trick. What's perhaps a more interesting question is whether a process will produce its desired output within a desired time frame or number of cycles. For practical time frames an empirical approach seems easy (just wait and check it), but I have no reason to believe that an analytic approach or proof would be "really easy" even if it was just N steps of symbolic execution.
- jfoutz 4y ago
  > sudo shutdown -h now That, is funny. There are a bunch of approaches, one approach uses 'gas' so you have to pay for computation steps. A bunch of SAT solvers use a clock - if you don't finish in 5 minutes, you get the axe. And yes, for the vast majority - it's fine. shutdown -h works great. Not many bugs are from "the set of all sets that do not contain themselves" paradoxes. > What's perhaps a more interesting question is whether a process will produce its desired output within a desired time frame. Everybody sort of learns about thundering herd in their own way. And retry loops. And many more. We try stuff, learn how it fails and fix it. And, as far as I know, that's the best we can do. Thinking about programs as processes (I think the author means natural process not unix process) is helpful, but it's not a magic wand.
edgyquant 4y ago
A process is an abstraction. It is not the essence of computing.

by jfoutz 4y ago

musicale 4y ago

> it should be really easy to tell if any given process halts. But, it's not. In theory, some processes could run forever. In practice, they do not. For example, sudo shutdown -h now usually works for me. If it doesn't then a hard powerdown usually does the trick. What's perhaps a more interesting question is whether a process will produce its desired output within a desired time frame or number of cycles. For practical time frames an empirical approach seems easy (just wait and check it), but I have no reason to believe that an analytic approach or proof would be "really easy" even if it was just N steps of symbolic execution.

jfoutz 4y ago
> sudo shutdown -h now That, is funny. There are a bunch of approaches, one approach uses 'gas' so you have to pay for computation steps. A bunch of SAT solvers use a clock - if you don't finish in 5 minutes, you get the axe. And yes, for the vast majority - it's fine. shutdown -h works great. Not many bugs are from "the set of all sets that do not contain themselves" paradoxes. > What's perhaps a more interesting question is whether a process will produce its desired output within a desired time frame. Everybody sort of learns about thundering herd in their own way. And retry loops. And many more. We try stuff, learn how it fails and fix it. And, as far as I know, that's the best we can do. Thinking about programs as processes (I think the author means natural process not unix process) is helpful, but it's not a magic wand.

edgyquant 4y ago

A process is an abstraction. It is not the essence of computing.