Quantum this,
Quantum that...
Haskell
God writes Haskell
101–110 of 128 posts
Re: God writes Haskell
#102Haven’t we actually established that God DOES in fact play dice, that Niels Bohr was right, and that Einstein was wrong?
No, in fact I would say almost the exact opposite. Einstein's famous quote was expressing his distaste for the "Copenhagen interpretation" of quantum mechanics. Among people who seriously think about interpretations of quantum mechanics, many (but not all) think that there are serious flaws with the Copenhagen interpretation.
Re: God writes Haskell
#103This makes me believe simulation theory even more tbh. Quantum mechanics exist to fuse operations, altogether making simulating our universe more computationally inexpensive.
People write this sort of thing a lot, and I don't really understand it. Simulating quantum systems is dramatically (formally speaking exponentially) more expensive than simulating classical ones (at least as far as our current understanding of complexity theory goes). If you're going to simulate a universe, and you want to cheap-out on computer power, then you should simulate a classical one.
Re: God writes Haskell
#104Earlier quoted context omitted.
>If you can reason about f and g that doesn’t mean that you can tell anything useful about f o g I'm confused. If you can reason about f and g, there is nothing more to know about f o g -- provided f and g are pure functions. The whole thing is about making sure side-effects are properly pushed at the boundaries so that you can keep working with pure functions. Haskell just provides more help (or more constraints) to…
f :: Integer -> Boolean g f n = if (f n) then (g f (n+1)) else (is_it_reachable) Will it ever terminate (or insert any other interesting property that you wish) with f = collatz? I know this is the atomic bomb case, but you can actually quite easily increase the complexity in realistic programs by just a few compositions, it doesn’t take much.
Here you are defining a new function, not composing two functions.
But if you consider a program implementation of pure functions, this might not be true; for example f and g use a quantity of RAM, but the RAM used by f o g exceeds your computer RAM and thus explodes. Or, if we work with objects, some values (e.g. internal values of the object, or context values) may be changed that make the final result of f o g different from what you would normally expect.
The promise of working "functionally" is to avoid the second class of problems. For the first class this is just a problem of computer systems, but pure functions means that the memory should be able to be reclaimed efficiently. And for the limits of computability theory (like the halting problem), nothing works except oracle machines, but no startup has ever delivered a functional one!
Re: God writes Haskell
#105Earlier quoted context omitted.
f :: Integer -> Boolean g f n = if (f n) then (g f (n+1)) else (is_it_reachable) Will it ever terminate (or insert any other interesting property that you wish) with f = collatz? I know this is the atomic bomb case, but you can actually quite easily increase the complexity in realistic programs by just a few compositions, it doesn’t take much.
Who said anything about termination? The original point was about composition. The guarantees of the component parts are the same as the composition. It's neither clear that f or g will terminate, and it's the same for f . g If the halting problem is really your biggest concern when developing software then you're lucky!
The Halting problem’s immediate consequence is Rice’s theorem, which is much more wide-reaching then termination.
Re: God writes Haskell
#106Interestingly i don't think we know that the speed of light remains constants, nor could we devise a test to determine it.
Currently the speed of light is constant by definition of the meter. If we were to find certain cases where the speed of light appears to be different from c, that would be interpreted as compression or expansion of spacetime. For example, universal expansion can be reinterpreted as light being faster in the past. I'm wondering whether it could be reinterpreted as time having a variable rate.
we only measure the two directional speed of light (bounce timing). The Einstein convention assumes that speed is the same in all directions. i'm not saying it's not. Just that it's impossible to tell otherwise. Einstein mentioned this in his paper.
Re: God writes Haskell
#107I would bet that He writes Lisp. Ultimately everything is the same. Particles. Above it: particles made of particles.
God wrote in Lisp, Bob Kanefsky performed by Julia Ecklar. My favorite song. https://www.prometheus-music.com/audio/eternalflame.mp3 Refrain (full lyrics): http://www.songworm.com/lyrics/songworm-parody/EternalFlame.... For God wrote in Lisp code When he filled the leaves with green. The fractal flowers and recursive roots: The most lovely hack I’ve seen. And when I ponder snowflakes, never finding two the same, I kn…
I only clicked on the comments to find out if anyone had posted this. It is also a favorite of mine and I don't even really write in Lisp! Though it has actually inspired me to start using emacs and fiddle with elisp and CL a bit.
Re: God writes Haskell
#108Haven’t we actually established that God DOES in fact play dice, that Niels Bohr was right, and that Einstein was wrong?
Not according to Everett and about half of practicing physicists: https://en.wikipedia.org/wiki/Many-worlds_interpretation
You can also throw in the Bohmians, since you can express at least non-relativistic QM in purely deterministic terms akin to stat mech (it's purely classical uncertainty about your position in configuration space, and there are stat-mech-like arguments for why that distribution should be very close to the Born distribution).
Personally I don't know all that many physicists who think the universe is fundamentally stochastic (I work in quantum information).
Re: God writes Haskell
#109Re: God writes Haskell
#110Earlier quoted context omitted.
The key is to not write large Haskell programs. Write many Haskell libraries and compose them. This scales infinitely and is an excellent way to build software. But it's also hard to do and takes good & deliberate technical leadership if you want to get 50+ engineers doing it.
If you can reason about f and g that doesn’t mean that you can tell anything useful about f o g, so no, this is a factually incorrect statement. Sure, if we have a separate unit of functionality, write a function for that. But that’s no silver bullet - complexity is unbounded.
> If you can reason about f and g that doesn’t mean that you can tell anything useful about f o g
What? The ability to reason about f o g (for various definitions of o) is the promise of Haskell and one of its entire ecosystem's foundational principles.
Local reasoning is absolutely possible.