5 ms·

The thing is, CPUs are designed to execute imperative programs. A stream of instructions is imperative. Until we see real hardware that executes functional prog

The thing is, CPUs are designed to execute imperative programs. A stream of instructions is imperative. Until we see real hardware that executes functional programs, FP will always be somehow treated as a second-class citizen in the computing world.

gagege 11y ago
The thing is, CPUs are designed to execute imperative programs. A stream of instructions is imperative. Until we see real hardware that executes object-oriented programs, OOP will always be somehow treated as a second-class citizen in the computing world. Everything we do is an abstraction.
- bluetomcat 11y ago
  Abstractions sometimes do not match well with the underlying abstractions that they depend on. The Von Neumann architecture is all about state and mutability, and yet FP tries to stay as far as it can from that. OOP is really a supplement layer over imperative programming and doesn't deny any of its underpinnings.
  - Retra 11y ago
    Abstractions necessarily do not match the underlying infrastructure. That's why they are called abstractions. That's also why we use them: because we don't want to be bound by underlying infrastructure. PS: Computers are not inherently digital, either.
  - dragonwriter 11y ago
    > The Von Neumann architecture is all about state and mutability, and yet FP tries to stay as far as it can from that. As I understand it, real world FP isn't about "staying away from" state and mutability, its about providing tools for managing state and mutability as a means to manage the complexity of reasoning about programs using it. E.g., Haskell's monadic approach essentially makes every Haskell program one that produces (as the result of the main function) the imperative program that is actually executed by the runtime.
DanWaterworth 11y ago
The thing is, CPUs are designed to execute machine code. Machine code isn't memory safe. Until we see memory safety implemented at the machine layer, memory safe languages will always be somehow treated as second-class citizens in the PL world.
- pjc50 11y ago
  Well, we do have hardware memory safety, that's what the MMU is for. Clearly it's not being used enough. What we need to do is bring containerization down to the level of individual functions, so that the MMU can enforce encapsulation. (I'm not sure whether this is a joke, a brilliant idea, or a piece of FP advocacy. You could probably get a CS graduate paper out of trying it, though)
  - mcguire 11y ago
    Been done (damn, I'm channelling some of the arrogant beardy Usenix guys). Check the ScoutOS literature; one of the followons was a systems paper about a multiserver microkernel OS with memory boundaries between servers. Wherein we learn once again that it kills performance. (Dammit. Somebody stop my arrogant ass.)
- sklogic 11y ago
  MMU and MPUs had been around for ages. More exotic, tagged memory architectures also existed in the past.
pjc50 11y ago
The LISP machine was never popular, but it did exist.

gagege 11y ago

The thing is, CPUs are designed to execute imperative programs. A stream of instructions is imperative. Until we see real hardware that executes object-oriented programs, OOP will always be somehow treated as a second-class citizen in the computing world. Everything we do is an abstraction.

bluetomcat 11y ago
Abstractions sometimes do not match well with the underlying abstractions that they depend on. The Von Neumann architecture is all about state and mutability, and yet FP tries to stay as far as it can from that. OOP is really a supplement layer over imperative programming and doesn't deny any of its underpinnings.
- Retra 11y ago
  Abstractions necessarily do not match the underlying infrastructure. That's why they are called abstractions. That's also why we use them: because we don't want to be bound by underlying infrastructure. PS: Computers are not inherently digital, either.
- dragonwriter 11y ago
  > The Von Neumann architecture is all about state and mutability, and yet FP tries to stay as far as it can from that. As I understand it, real world FP isn't about "staying away from" state and mutability, its about providing tools for managing state and mutability as a means to manage the complexity of reasoning about programs using it. E.g., Haskell's monadic approach essentially makes every Haskell program one that produces (as the result of the main function) the imperative program that is actually executed by the runtime.

DanWaterworth 11y ago

The thing is, CPUs are designed to execute machine code. Machine code isn't memory safe. Until we see memory safety implemented at the machine layer, memory safe languages will always be somehow treated as second-class citizens in the PL world.

pjc50 11y ago
Well, we do have hardware memory safety, that's what the MMU is for. Clearly it's not being used enough. What we need to do is bring containerization down to the level of individual functions, so that the MMU can enforce encapsulation. (I'm not sure whether this is a joke, a brilliant idea, or a piece of FP advocacy. You could probably get a CS graduate paper out of trying it, though)
- mcguire 11y ago
  Been done (damn, I'm channelling some of the arrogant beardy Usenix guys). Check the ScoutOS literature; one of the followons was a systems paper about a multiserver microkernel OS with memory boundaries between servers. Wherein we learn once again that it kills performance. (Dammit. Somebody stop my arrogant ass.)
sklogic 11y ago
MMU and MPUs had been around for ages. More exotic, tagged memory architectures also existed in the past.

pjc50 11y ago

The LISP machine was never popular, but it did exist.