No, the problem with people with depression is that they're depressed. Whether they care too much about what others think about them is a mostly separate issue.
If you're going to describe it as conquest, sure. You said "the settlers...voted first for democracy", which is just a euphemism for overthrowing the government. So, the settlers overthrew the government, turned it over to the US, and now the US thinks (by reason of conquest) that it owns what the Kingdom used to own. It's worth noting that the US President was opposed to the overthrow and annexation. You haven't contradicted anything I've said.
I don't want to accept wrong answers. Lost sale? That happens whether I pirate or abstain. Consuming a good? Show me what's gone when I've pirated. Watching without permission? How does that affect the copyright holder?
It's a very simple question that you don't appear to have an answer for.
I was never convinced that the simulation hypothesis is worthwhile. If I believe I'm part of a simulation, shouldn't I do the same things as if I weren't?
The simulation appears to limit my knowledge of physics, and it hasn't implemented a serious particle accelerator. What I've got is access to various books, and whichever journal articles the simulation predicts I'll look at.
You have no reason to believe that anything other than the Earth's surface up through geosynchronous orbit are simulated in detail. This would explain the Fermi paradox: there are no aliens because they wren't explicitly simulated, and the base class for Planet doesn't include intelligent life, that being a mixin applied only to the most detailed simulation.
We might be the point of the simulation. The tiny speck of the Universe might be the only one being simulated at full resolution, with stars more than a kiloparsec(or whatever) away being simulated as stars, not as collections of particles.
And computability is based on what a Turing machine can do. Assuming the Church-Turing Thesis that a Turing machine can do anything we'd describe as computation, how do we know that another reality can't have some method of doing things that we wouldn't recognize as computation?
You're assuming that math is the same in the real world as in this one (seems likely) and that computation is the same thing (less likely). The abstract says that classical computing can't efficiently calculate some quantum effects, which is plausible. (The abstract then goes on to talk about things I don't understand, so I'm not tempted to RTFA.)
You also seem to be assuming that the Universe is continuous. Is there any evidence that ispacetime isn't quantized on a scale we can't yet measure?
My immediate reaction to something being observed being uncomputable is: How do we know? Either we can compute what we expect, or any random garbage will do. Nor does "X is uncomputable" mean "there isn't an easy special case". Since I don't understand what TFA (Abstract in this case) is really saying, I'm very open to correction.
We don't need an infinite chain of simulations in our space. Suppose Q ran five hundred Universe simulations yesterday afternoon (whatever that means in the Q continuum). What Q didn't know was that the Q continuum was just a simulation written by Ponder Stibbons on a more advanced version of Hex, and Mustrum Ridcully wanted a couple thousand of them before lunch.
In wartime, inadequate training results in casualties and damage. In peacetime, inadequate training results in casualties and damage once war comes. It took time to get training establishments functioning for WWII, and we had the advantage of not having to fight Germany for months after war was declared. The Navy was probably the best prepared of the services, and we suffered horrible losses off the Eastern Seaboard for months.
Good idea. Hulls that just sit in the water have some pretty severe speed limits due to wave resistance. If you can get that 8K-ton destroyer planing, it'll move a lot faster and save fuel.
Once upon a time, I was in a car with five other people, and we had a flat tire. I wound up trying to take the tire off. I could just barely budge the lug nuts. The other guys tried, and the driver got the car to a gas station, where the mechanic told us "That's a X, it has left-hand threads on the left wheels" and the problem was solved.
I have a little right-left confusion sometimes, and it was worse back then. If I'd been on my own, I'd have tried turning it the other way, and I would have gotten the lug nuts off. However, with five other people looking at me, I knew I had to be turning in the right direction, and didn't want to look stupid by turning the wrench in the wrong direction.
Just having people around can enforce group expectations, even when they're wrong.
And then you design a system to catch people gaming the system designed to catch people gaming the system. This can go on forever. Also, as the system gets more and more rigid, it's more likely that it will force intelligent and qualified people to do the exact wrong thing at some times, and require paperwork when they should be paying attention to something else.
A rational manager would look at a tool and think, "This is $1199 a year for a developer I spend $150K a year on. Does it make my developer 1% more efficient? If so, it's worth it."
Writing programs that write programs can be a very useful technique. However, people have been trying to come up with ways to eliminate those pesky programmers for pretty much my entire lifetime, and I haven't seen any indications of success, ever. It's possible to write tools that eliminate some of the complexity around representing a problem, and it's possible to write tools that can come together to represent lots of problems, but either the program-writing tools are very limited or they only accept stuff written in some formal language - in other words, they're compilers from one language into another.
If your program is so complex that you don't know what it does at all times and how it can fail, it's too big.
If your program isn't that complex, there are some very useful things that I guarantee it isn't doing. Things should be made as simple as they can be, and no simpler. Some real-world tasks are extremely complex.
Exactly what represents bits is irrelevant to the programmer (although the details of the access method can be very relevant). A bit is represented as whatever is convenient for the machine. Bits have been represented by dots on cathode ray tubes, dynamic electron or mercury flow conditions, tiny little magnets of one polarity or another, current, whether a capacitor is charged or not, and many different methods. It is possible to make machines to be almost completely reliable so that what a bit is doesn't matter to a programmer.
Architects work on a much more limited scale than programmers do. Architects work with known components that can be put together in a limited number of ways. This doesn't say they can't do wonderful things with them, but the problem space is limited.
Programmers tend to work in a much larger problem space.
Also, if the architect makes a major mistake, there are serious consequences, while the programmer is more sheltered from them.
There are problems that will not be understood until code has been written and the results examined. You're unlikely to make a really good UI on the first try, and, when you try it, you will very often find the customer doesn't want what the customer said he or she wanted.
Fortunately, agile can handle this with iterative development, while strict waterfall can't.
Modern CPUs are very complex, unlike the ones I grew up with, when it was easy to understand what the CPU was doing at any given time. That complexity is normally abstracted by the compiler's code generator This seems to work, as far as I can tell, and it makes my life easier.
Sounds like you never did anything major. If you understand in detail what the code is supposed to be doing, getting the code generally right is usually not that difficult. Getting it precisely right is that difficult, when you're dealing with hundreds of thousands of lines of code in the system.
That's how being human works. If something isn't difficult, somebody will scale it up until it is.
In an early issue of a magazine (Dr. Dobb's?) I saw a review of (IIRC) and Imsai computer, and the reviewer praised the flat switches as a great improvement over the Altair's switches.
Slashdot Mirror
No, the problem with people with depression is that they're depressed. Whether they care too much about what others think about them is a mostly separate issue.
If you're going to describe it as conquest, sure. You said "the settlers...voted first for democracy", which is just a euphemism for overthrowing the government. So, the settlers overthrew the government, turned it over to the US, and now the US thinks (by reason of conquest) that it owns what the Kingdom used to own. It's worth noting that the US President was opposed to the overthrow and annexation. You haven't contradicted anything I've said.
I don't want to accept wrong answers. Lost sale? That happens whether I pirate or abstain. Consuming a good? Show me what's gone when I've pirated. Watching without permission? How does that affect the copyright holder?
It's a very simple question that you don't appear to have an answer for.
I was never convinced that the simulation hypothesis is worthwhile. If I believe I'm part of a simulation, shouldn't I do the same things as if I weren't?
The simulation appears to limit my knowledge of physics, and it hasn't implemented a serious particle accelerator. What I've got is access to various books, and whichever journal articles the simulation predicts I'll look at.
How do you know that? You can always write a smaller number, but there's no guarantee that it has anything to do with reality.
You have no reason to believe that anything other than the Earth's surface up through geosynchronous orbit are simulated in detail. This would explain the Fermi paradox: there are no aliens because they wren't explicitly simulated, and the base class for Planet doesn't include intelligent life, that being a mixin applied only to the most detailed simulation.
Or, for Heinlein fans, "The Unpleasant Profession of Jonathan Hoag", in which humanity is an artist quickly "painting" over the Sons of the Bird.
We might be the point of the simulation. The tiny speck of the Universe might be the only one being simulated at full resolution, with stars more than a kiloparsec(or whatever) away being simulated as stars, not as collections of particles.
And computability is based on what a Turing machine can do. Assuming the Church-Turing Thesis that a Turing machine can do anything we'd describe as computation, how do we know that another reality can't have some method of doing things that we wouldn't recognize as computation?
You're assuming that math is the same in the real world as in this one (seems likely) and that computation is the same thing (less likely). The abstract says that classical computing can't efficiently calculate some quantum effects, which is plausible. (The abstract then goes on to talk about things I don't understand, so I'm not tempted to RTFA.)
You also seem to be assuming that the Universe is continuous. Is there any evidence that ispacetime isn't quantized on a scale we can't yet measure?
My immediate reaction to something being observed being uncomputable is: How do we know? Either we can compute what we expect, or any random garbage will do. Nor does "X is uncomputable" mean "there isn't an easy special case". Since I don't understand what TFA (Abstract in this case) is really saying, I'm very open to correction.
We don't need an infinite chain of simulations in our space. Suppose Q ran five hundred Universe simulations yesterday afternoon (whatever that means in the Q continuum). What Q didn't know was that the Q continuum was just a simulation written by Ponder Stibbons on a more advanced version of Hex, and Mustrum Ridcully wanted a couple thousand of them before lunch.
In wartime, inadequate training results in casualties and damage. In peacetime, inadequate training results in casualties and damage once war comes. It took time to get training establishments functioning for WWII, and we had the advantage of not having to fight Germany for months after war was declared. The Navy was probably the best prepared of the services, and we suffered horrible losses off the Eastern Seaboard for months.
Good idea. Hulls that just sit in the water have some pretty severe speed limits due to wave resistance. If you can get that 8K-ton destroyer planing, it'll move a lot faster and save fuel.
Once upon a time, I was in a car with five other people, and we had a flat tire. I wound up trying to take the tire off. I could just barely budge the lug nuts. The other guys tried, and the driver got the car to a gas station, where the mechanic told us "That's a X, it has left-hand threads on the left wheels" and the problem was solved.
I have a little right-left confusion sometimes, and it was worse back then. If I'd been on my own, I'd have tried turning it the other way, and I would have gotten the lug nuts off. However, with five other people looking at me, I knew I had to be turning in the right direction, and didn't want to look stupid by turning the wrench in the wrong direction.
Just having people around can enforce group expectations, even when they're wrong.
And then you design a system to catch people gaming the system designed to catch people gaming the system. This can go on forever. Also, as the system gets more and more rigid, it's more likely that it will force intelligent and qualified people to do the exact wrong thing at some times, and require paperwork when they should be paying attention to something else.
A rational manager would look at a tool and think, "This is $1199 a year for a developer I spend $150K a year on. Does it make my developer 1% more efficient? If so, it's worth it."
Writing programs that write programs can be a very useful technique. However, people have been trying to come up with ways to eliminate those pesky programmers for pretty much my entire lifetime, and I haven't seen any indications of success, ever. It's possible to write tools that eliminate some of the complexity around representing a problem, and it's possible to write tools that can come together to represent lots of problems, but either the program-writing tools are very limited or they only accept stuff written in some formal language - in other words, they're compilers from one language into another.
If your program isn't that complex, there are some very useful things that I guarantee it isn't doing. Things should be made as simple as they can be, and no simpler. Some real-world tasks are extremely complex.
Exactly what represents bits is irrelevant to the programmer (although the details of the access method can be very relevant). A bit is represented as whatever is convenient for the machine. Bits have been represented by dots on cathode ray tubes, dynamic electron or mercury flow conditions, tiny little magnets of one polarity or another, current, whether a capacitor is charged or not, and many different methods. It is possible to make machines to be almost completely reliable so that what a bit is doesn't matter to a programmer.
Architects work on a much more limited scale than programmers do. Architects work with known components that can be put together in a limited number of ways. This doesn't say they can't do wonderful things with them, but the problem space is limited.
Programmers tend to work in a much larger problem space.
Also, if the architect makes a major mistake, there are serious consequences, while the programmer is more sheltered from them.
There are problems that will not be understood until code has been written and the results examined. You're unlikely to make a really good UI on the first try, and, when you try it, you will very often find the customer doesn't want what the customer said he or she wanted.
Fortunately, agile can handle this with iterative development, while strict waterfall can't.
Modern CPUs are very complex, unlike the ones I grew up with, when it was easy to understand what the CPU was doing at any given time. That complexity is normally abstracted by the compiler's code generator This seems to work, as far as I can tell, and it makes my life easier.
Sounds like you never did anything major. If you understand in detail what the code is supposed to be doing, getting the code generally right is usually not that difficult. Getting it precisely right is that difficult, when you're dealing with hundreds of thousands of lines of code in the system.
That's how being human works. If something isn't difficult, somebody will scale it up until it is.
In an early issue of a magazine (Dr. Dobb's?) I saw a review of (IIRC) and Imsai computer, and the reviewer praised the flat switches as a great improvement over the Altair's switches.