4 ms·

All programming is just function composition. This is an idea that I got from studying category theory. Concatenative programming is just a first step in that

All programming is just function composition. This is an idea that I got from studying category theory. Concatenative programming is just a first step in that direction. I leave the details an an exercise for the reader.

knome 1y ago
side effects are quite the thorn in this theories side. hard to describe message passing in purely applicative terms.
- nine_k 1y ago
  Effects are pretty smoothly described by monads; there's an entire well-respected language built on top of that. One of the problems of the purely applicative approach is that you get a nice algebra for describing your results, including the sequence of effects, but reasoning about the resources spent by the computation becomes harder.
  - knome 1y ago
    monads were certainly a clever fix for the difficulties otherwise caused by passing around the world as a value. I might argue that laziness makes haskell something different than purely applicative. It's not just pure values being passed around. It's a language built atop suspended self-caching invocable thunks getting knotted up and then firing off in chain reaction. main = do let hello = foo world world = bar hello putStrLn $ show hello putStrLn $ show world where foo v = [v] bar v = length v
90s_dev 1y ago
Modern programming is. But look at assembly, which is what actual machines do. And you can write assembly with tons of gotos and not a single function in sight.
- jrvieira 1y ago
  Modern machines do. But the dominance of imperative assembly is more about historical momentum and engineering tradeoffs than fundamental necessity. We don't have to go all-in on Von Neumann.
- antonvs 1y ago
  Time to read "Debunking the 'Expensive Procedure Call' Myth, or, Procedure Call Implementations Considered Harmful, or, Lambda: The Ultimate GOTO": https://dspace.mit.edu/handle/1721.1/5753 https://dspace.mit.edu/handle/1721.1/5753 The point is there's a closer connection between functions and gotos than you might imagine.
  - dreamcompiler 1y ago
    There's really no such thing as a 'function' at the assembler level. There are pure jumps and there are jumps that also perform side effects on a register conventionally called a 'stack pointer' (and on the memory that register points to) but no true 'functions.' This is roughly the point Steele is making, in addition to his point that the stack pointer side effects are often unnecessary (i.e. tail jumps). Implementing a stack pointer in hardware is merely a legacy hack: Before people figured out continuations they didn't know any better.
    - antonvs 1y ago
      > There's really no such thing as a 'function' at the assembler level. That's like saying "There's really no such thing as a 'chair' at the quantum level."
    - xboxnolifes 1y ago
      If you look at the computer (registers, cache, RAM, storage, etc) as one whole, every assembler instruction is just a function that takes in the state of the computer and returns a new state. Multiple assembler instructions is then using function composition.
      - 1y ago

knome 1y ago

side effects are quite the thorn in this theories side. hard to describe message passing in purely applicative terms.

nine_k 1y ago
Effects are pretty smoothly described by monads; there's an entire well-respected language built on top of that. One of the problems of the purely applicative approach is that you get a nice algebra for describing your results, including the sequence of effects, but reasoning about the resources spent by the computation becomes harder.
- knome 1y ago
  monads were certainly a clever fix for the difficulties otherwise caused by passing around the world as a value. I might argue that laziness makes haskell something different than purely applicative. It's not just pure values being passed around. It's a language built atop suspended self-caching invocable thunks getting knotted up and then firing off in chain reaction. main = do let hello = foo world world = bar hello putStrLn $ show hello putStrLn $ show world where foo v = [v] bar v = length v

90s_dev 1y ago

Modern programming is. But look at assembly, which is what actual machines do. And you can write assembly with tons of gotos and not a single function in sight.

jrvieira 1y ago
Modern machines do. But the dominance of imperative assembly is more about historical momentum and engineering tradeoffs than fundamental necessity. We don't have to go all-in on Von Neumann.
antonvs 1y ago
Time to read "Debunking the 'Expensive Procedure Call' Myth, or, Procedure Call Implementations Considered Harmful, or, Lambda: The Ultimate GOTO": https://dspace.mit.edu/handle/1721.1/5753 https://dspace.mit.edu/handle/1721.1/5753 The point is there's a closer connection between functions and gotos than you might imagine.
- dreamcompiler 1y ago
  There's really no such thing as a 'function' at the assembler level. There are pure jumps and there are jumps that also perform side effects on a register conventionally called a 'stack pointer' (and on the memory that register points to) but no true 'functions.' This is roughly the point Steele is making, in addition to his point that the stack pointer side effects are often unnecessary (i.e. tail jumps). Implementing a stack pointer in hardware is merely a legacy hack: Before people figured out continuations they didn't know any better.
  - antonvs 1y ago
    > There's really no such thing as a 'function' at the assembler level. That's like saying "There's really no such thing as a 'chair' at the quantum level."
  - xboxnolifes 1y ago
    If you look at the computer (registers, cache, RAM, storage, etc) as one whole, every assembler instruction is just a function that takes in the state of the computer and returns a new state. Multiple assembler instructions is then using function composition.
    - 1y ago