Hacker News Reader

Comment by tome | Hacker News Reader

> processors are still procedural

Exactly. I don't know why Haskell fanboys insist on abstracting us so far from the machine. Declarative programming is really unhelpful because it says nothing about the order in which code executes.

We live in a mutable physical universe that corresponds to a procedural program. One thing happens after another according to the laws of physics (which are the procedural program for our universe). Electrons move one after another around circuits. Instructions in the CPU happen one after another according to the procedural machine code.

The universe would never consider running 2020 before 2019 and a CPU will never execute later instructions before earlier instructions.

Haskell fanboys talk about immutable data structures like it's beneficial to go back in time and try again. But it's a bad fit for the CPU. The CPU would never run some code and then decide it wants to go back and have another go.

View on HN

You're saying a lot of wrong things about CPUs. CPUs do execute instructions "out-of-order", and they do speculative execution and rollback and have another go. Branch prediction is an example.

All of this is possible only with careful bookkeeping of the microarchitectural state. I agree the CPU is a stateful object. But even at the lowest level of interface we have with the CPU, machine code, there are massive gains from moving away from a strict procedural execution to something slightly more declarative. The hardware looks at a window of, say, 10 instructions, deduces the intent, and executes the 10 instructions in a better order, which has the same effect. (And yes, it's hard for me to wrap my head around it, but there is a benefit from doing this dynamically at runtime in addition to whatever compile-time analysis.) In short, it is beneficial to go back and have another go.

This was demonstrated also in https://snr.stanford.edu/salsify/. If you encode a frame of video, but your network is all of the sudden to slow, you might desire to encode that frame at a lower quality. Because these codecs are extremely stateful (that's now temporal compression works), you have to be very careful about managing the state so for can "go back and have another go".

I am less confident about it, but what you say about the universe also seems wrong. What physical laws do you know take the form of specifying the next state in terms of the preceding state? And literally many of them are time-reversible.

Thanks. It was an attempt at parody but apparently I didn't lay it on thick enough. I'll try to up my false-statements-per-paragraph count next time.

What you wrote about CPUs many people believe, and many simpler CPUs operate like that. So it was difficult for me to detect as parody. Sorry that I missed it! It's funny in hindsight.

Not sure what the parody was in computing 2020 before 2019.

> Exactly. I don't know why Haskell fanboys insist on abstracting us so far from the machine.

I believe it is because abstractions are the way we have always made progress. Is the C code that's so close to the machine not just an abstraction of the underlying assembly, which is an abstraction of the micro operations of your particular processor, which in turn is an abstraction of the gate operations? The abstractions allow us to offload a significant part of mental task. Imagine trying to write an HTML web page in C. Sure it's doable with a lot of effort, but is it as simple as writing it using abstractions such as the DOM?

> We live in a mutable physical universe that corresponds to a procedural program. One thing happens after another according to the laws of physics (which are the procedural program for our universe).

You just proved why abstractions are useful. "One thing happens after another" is simply our abstraction of what actually happens, as demonstrated by e.g. the quantum eraser experiment [1][2].

[1] https://en.wikipedia.org/wiki/Delayed-choice_quantum_eraser

[2] https://www.youtube.com/watch?v=8ORLN_KwAgs

>I believe it is because abstractions are the way we have always made progress.

>The abstractions allow us to offload a significant part of mental task

Edge/corner cases in our abstractions is also how propagation of uncertainty[1] happens. You can't off-load error-correction [2]

[1] https://en.wikipedia.org/wiki/Propagation_of_uncertainty

[2] https://en.wikipedia.org/wiki/Quantum_error_correction

I'm not sure what you mean by "You can't off-load error-correction". In the case of classical computing, we do off-load error-correction (I don't have to worry about bit flips while typing this). In the case of quantum computing, if we couldn't offload error-correction, an algorithm such as Shor's wouldn't be able to written down without explicitly taking error-correction into account. Yet, it abstracts this away and simply assumes that the logical qubits it works with don't have any errors.

> Instructions in the CPU happen one after another

https://en.wikipedia.org/wiki/Superscalar_processor

> a CPU will never execute later instructions before earlier instructions

https://en.wikipedia.org/wiki/Out-of-order_execution

> The CPU would never run some code and then decide it wants to go back and have another go

https://en.wikipedia.org/wiki/Speculative_execution

Actually the FP fanboys, all the way back to those IBM mainframes where Lisp ran.

Even C abstracts the machine, the ISO C standard is written for an abstract machine, not high level Assembly like many think it is.

Abstracting the maching is wonderfull, it means that my application, if coded properly, can scale from a single CPU to a multicore CPU + coupled with GPGPU, distributed across a data cluster.

Have a look at Feynamm's Connection Machines.

> The universe would never consider running 2020 before 2019 and a CPU will never execute later instructions before earlier instructions.

Except thanks to a compile-time optimization.

And ooo-execution that happens at _runtime_.

Reply on news.ycombinator.com