[mirceal]

> To be clear, there’s nothing inher­ently supe­rior about func­tional program­ming. (Despite the fact that these self-contained func­tions are also known as pure func­tions.) It is not the way computers work at a hard­ware level.

Hah. Weird way of approaching it but okay. Here's the thing: it is exactly how computers work at hardware level. If you look at an electronic circuit you and a program written in a functional way, the equivalence is almost 1:1. The circuits are self contained and you compose them to generate a new output from the inputs that are fed in.

[dahfizz]

That works for simple circuits. Actual computers have oodles of state - we usually call it "main memory". Assembly is a language that can only do one thing: mutate this state.

[mrkeen]

But it's a pain to write out assembly, so we go via LLVM and SSA.

In SSA, rather than modelling your program using 16 mutable registers (imperative folk love talking about "the real world" or "real computer"), we use an infinite number of immutable registers.

Infinite registers won't fit in a computer (we only have 16), and not being able to overwrite registers must kill performance right?

[dahfizz]

I'm not sure what your point is. Yes, it is possible to build "functional" layers of abstraction on top of real hardware. The hardware itself is not "functional", that's why you need layers of abstraction.

[mbrodersen]

The hardware is also not C style imperative. C/Haskell/Clojure/… are all abstractions that gets mapped to a very complicated extremely parallel hardware state machine. None of the main stream programming languages maps to real hardware. Which is a good thing! We want to use an abstraction that helps us getting the job done faster/better. It does not matter how much the abstraction you use maps to real hardware. As long as it gets the job done who cares?

[mrkeen]

> I'm not sure what your point is.

I'm pointing out that this is a terrible argument and needs to die: "It is not the way computers work at a hard­ware level"

> it is possible to build "functional" layers of abstraction on top of real hardware.

It's not just possible; I don't see any alternatives gaining traction anytime soon.

[mirceal]

that’s the point. more complex circuits are made from simple circuits. principle still applies. if you think about it, most problems with writing code stem from state management.

[dahfizz]

> more complex circuits are made from simple circuits. principle still applies.

And humans are made out of carbon, but you are never going to understand human emotion by studying carbon atoms really hard.

Assembly is the interface to the hardware. Assembly is imperitive. The abstraction that assembly exposes is a machine with global, mutable state. That's the way the hardware works.

[mirceal]

> And humans are made out of carbon, but you are never going to understand human emotion by studying carbon atoms really hard.

here is the problem with that line of reasoning: human emotion is difficult to define, highly subjective. it does not mean anything unless you are human and try to understand the emotions.

also, you probably need to focus more on K and Na ions and electrons if you are going down the emotional rabbit hole. Carbon is interesting, but apart from providing the skeleton for various things like dna, proteins etc i think it’s not where you’d start