3 ms·

A few comments have cheerfully reproduced the stock objection that a program with no side effects does nothing and is thus useless. By extension functional prog

A few comments have cheerfully reproduced the stock objection that a program with no side effects does nothing and is thus useless. By extension functional programming is useless and it's all pointless. I'd like to counter that a function from vector of bytes to vector of bytes can be pure, terminating, implement some algorithm of great commercial interest and map exactly onto a program that reads said vector of bytes from stdin and sends them to stdout. If you're really generous, it can write two vectors of bytes, and tie the other one to stderr. That covers such useless academic things as your compiler.

kstrauser 3y ago
I guess that depends on whether you consider write(2) to have side effects. No, really, I've been in the room when people debated whether that was pure enough. It's an interesting exercise to talk through, at least.
- mrkeen 3y ago
  Even taking write as an effect (which I do), that doesn't stop it from being a trivial attachment to an otherwise pure artifact. IO in -> pure stuff of interest -> IO out The purity is in no way compromised by being IO-adjacent.
- JonChesterfield 3y ago
  I think that's an aliasing question. If write is sending bytes to somewhere else, it's pure. In exactly the same way that returning a value type from a function is pure, or passing a value type to some other function is pure. Since they're all the same thing. A unix process is a function in a literal sense. If you've aliased read and write to the same thing then mutation is back with us and sorrows return. Vaguely tangential, it's totally possible to write a program that uses read() to copy all of stdin to its own address space allocated with brk(), does whatever maths it wants, then sends some of the result back out with write(). Three syscalls, useful userspace program, no libc involved.
jrvarela56 3y ago
This talk [1] made me conclude something along these lines. You need side-effects to make anything useful, just make sure they're segregated in a specific place in your program. This makes it easier to make most of the program pure and make it clear where the dangerous stuff happens. [1] Boundaries by Gary B. from Destroy All Software https://www.youtube.com/watch?v=yTkzNHF6rMs https://www.youtube.com/watch?v=yTkzNHF6rMs

kstrauser 3y ago

I guess that depends on whether you consider write(2) to have side effects. No, really, I've been in the room when people debated whether that was pure enough. It's an interesting exercise to talk through, at least.

mrkeen 3y ago
Even taking write as an effect (which I do), that doesn't stop it from being a trivial attachment to an otherwise pure artifact. IO in -> pure stuff of interest -> IO out The purity is in no way compromised by being IO-adjacent.
JonChesterfield 3y ago
I think that's an aliasing question. If write is sending bytes to somewhere else, it's pure. In exactly the same way that returning a value type from a function is pure, or passing a value type to some other function is pure. Since they're all the same thing. A unix process is a function in a literal sense. If you've aliased read and write to the same thing then mutation is back with us and sorrows return. Vaguely tangential, it's totally possible to write a program that uses read() to copy all of stdin to its own address space allocated with brk(), does whatever maths it wants, then sends some of the result back out with write(). Three syscalls, useful userspace program, no libc involved.

jrvarela56 3y ago

This talk [1] made me conclude something along these lines. You need side-effects to make anything useful, just make sure they're segregated in a specific place in your program. This makes it easier to make most of the program pure and make it clear where the dangerous stuff happens. [1] Boundaries by Gary B. from Destroy All Software https://www.youtube.com/watch?v=yTkzNHF6rMs https://www.youtube.com/watch?v=yTkzNHF6rMs