The Two Things about Computer Programming
fishbowl.pastiche.org
fishbowl.pastiche.org
With the obligatory footnote: "Unless you get into multithreading - then all bets are off." ;-)
However, from the perspective of the programmer it is non-deterministic. It only becomes deterministic when it is coupled with a particular scheduler and dispatcher. Most programmers strive to write cross platform code.
On what planet? Surely not this one, as most programs are very tightly coupled to particular operating systems.
Regardless, a future version of any single platform could include changes to the scheduler and/or dispatcher.
which is the part that gets rid of the "does what you tell it" bit, since now it's doing what it thinks it should, which might not be very consistent or easily determinable because minor variations during a race can produce wildly differing results.
Just because we don't know the laws that govern quantum mechanics doesn't mean they're not there.
As best we can tell, sometimes certain information doesn't exist so you may very well get something truly random that averages out to something that looks like what we think of as deterministic, classical behavior.
Which is why there's no way to be certain that it is or is not deterministic. According to current knowledge, quantum uncertainty is not deterministic -- solving the Schroedinger wavefunction for hydrogen, for example, shows no way to predict the future location of an electron. The best we can do is a probability distribution.
If, however, as the parent mentions, hidden variables do exist behind quantum mechanics, it could turn out that it was deterministic all along.
</pedantry>
How does that even remotely suggest non-determinism?
> If, however, as the parent mentions, hidden variables do exist behind quantum mechanics,
Isn't it obvious that we're not even remotely close to knowing everything?
The uncertainty principles simply suggests that we perhaps can never grasp or understand all the details; it doesn't in any way imply that these unknown details don't exist. It'd be foolish to think that "because we can't predict it therefore it's non-deterministic".
The computer will do exactly what you tell it to, but your brain is not capable of determining exactly what the computer will do (it'll process billions of instructions a second, if you tried to fully map out the operations of a computer in complete detail you wouldn't get even a fraction of a second done in your lifetime). Which is why we have to use abstractions, models, and various techniques to render that complexity manageable by human minds.
I wish there were a better/more formal way to quote things on HN as it can lead to confusion with attribution. Purely italic text doesn't quite cut it, but nor does the "source code" quoting feature.
1. How to represent data
2. How to transform representations 1. Data Structures
2. Algorithms 3. ...
4. PROFIT!2. If you think you have a reliable system for doing it, you're probably doing the computer's job
1. Graph search
2. Representing problems as graph search
- multi-agent systems
- knowledge representation/reasoning
- machine learning
- CSPs
So a lot of the interesting work (imo) is on non-graph knowledge representations, like answer-set programming, situation calculus, etc. They often ground out in some variety of graph search to do the inference, but that's just the solver algorithm, not where the research that interests me is at. It's like saying that graph search grounds out in x86 asm twiddling bits in a computer, so all AI is just bits in a computer, which is also true but misses the point.
Though it does remind me that there was a comment from someone in the 60s or 70s amounting to, "all AI boils down to heuristic search".
I usually find that making it fast makes it inelegant.
You still need to pick the right algorithms, but I've personally been really focusing on elegancy. Maintenance and Operation of code is the major costs of software, not writing new stuff -- so when you write new stuff, I believe that decreasing those other costs should be the first priority.
That said, I agree with you. Most of the time, the elegant solution is fast or can be made fast.
'git' is a good example of this.
I also find that a lot of times when programmers look at something elegant and say "that'll be slow", it's because they're wrongly estimating the relative speeds of things. A common example: they're counting function calls when they should be counting I/O operations that are many, many orders of magnitude slower.
1. You have to figure out what you need to build.
2. Engineer the solution in such a way that changes in the requirements result in relatively minor changes to the code.
A good ballpark, but not entirely true. At some point you'll end up with a smaller problem that cannot be broken up further. For the most part these may be solved problems, like `increment foo`, but at some point you might hit an unsolved atomic level problem that you either need to spend a lot of time working on, or forces you to find an alternative path.
E.g. input stream: stream of description of Turing machines and their input tape. Output stream: A stream of booleans that are true iff the respective machine holds.
Apply indirection to anything with unspecified runtime. When you need a result, put a reasonable waiting time on it, and if it doesn't happen assume the source has died and handle it as an error code.
2. Managing Expectations
2. You've overlooked or ignored things that need to be considered.
Pretty much sums up the source of all pain in day-to-day programming.
As for "incentives matter," what, because incentives incentivize?
1. You don't know what you're talking about.
2. You don't know it yet.
2. Input/Output.
2. Accepting thing #1 will make you a better programmer
2. Write for the human
2. Empathy for users and other programmers