3 ms·

Did you just compare passing data to passing functions? Because absolutely nothing about transferring data is specific to the program language paradigm chosen.

by beders 5y ago

Did you just compare passing data to passing functions? Because absolutely nothing about transferring data is specific to the program language paradigm chosen. Here's a task for you: Build a graph of objects holding state with your chosen OO language. Now write that state to disk and read it back in - guaranteeing a consistent state. Oops, a thread mutated some of the state while writing to disk? Damn it, need to add a some synchronization stuff. In all my objects. Oh now all my mutations need to go through a semaphore? No, wait I'll implement the Memento pattern for all my objects, that will help? (nope, it won't, you still need to synchronize across threads) If you operate on immutable data, that exercise in a functional language is literally two lines of code.

amw-zero 5y ago
This is just a comment about implicit vs. explicit state. What you described is not inherent to OO, though of course it's much easier to have implicit state in OO. I'm working in a codebase now that is very OO, but also is very diligent about having state be explicit. The exercise you described would also be 2 lines of code in this project.
Jweb_Guru 5y ago
Of course, with pure functional programming with no state under the hood, you would have failed at your original challenge of "build a graph" without further constraints (it's rather hard to ensure totality or that every pointer is accessible when you allow arbitrary cycles). I'm also not sure why you feel functional programming relieves you of the responsibility of making sure appropriate barriers are created between writes and reads to disk--message passing is more fundamental than programming paradigms, and you physically must make sure your messages synchronize somehow (and that you can recover from corrupted state, if there's a crash). Just writing once simply is not enough here! Also, without mutable state, how do I find the new head (where the appended stuff starts?). This has historically been a very annoying problem to deal with! Not that I think most of these concerns affect us much during day-to-day programming, by the way! I just find this a particularly poor example of the benefits of FP. In pretty much any useful distributed system, there will be some moving parts that need to be synchronized (like the actual messages to the storage layer), some state that needs to be maintained (root information a bootloader can follow to restore the system), and some weird domain specific stuff that's very hard to encode in types (like crash recovery, in this case). This is true whether or not what you want to do is conceptually purely functional--someone has to make decisions at each of these points about whether and how to expose the inner workings of the system, often in a way that trades off against things like flexibility, space overhead, reliability, and performance. And those decisions have to be relayed to the computer via some programming language that can talk state (or embedded into the hardware). Accepting that reality doesn't mean that everything has to be written in a "multiparadigm language" or anything like that, but it does mean being cautious about declaring that your favorite technique will automatically solve the issues plaguing another area of CS.

by beders 5y ago

amw-zero 5y ago

This is just a comment about implicit vs. explicit state. What you described is not inherent to OO, though of course it's much easier to have implicit state in OO. I'm working in a codebase now that is very OO, but also is very diligent about having state be explicit. The exercise you described would also be 2 lines of code in this project.

Jweb_Guru 5y ago

Of course, with pure functional programming with no state under the hood, you would have failed at your original challenge of "build a graph" without further constraints (it's rather hard to ensure totality or that every pointer is accessible when you allow arbitrary cycles). I'm also not sure why you feel functional programming relieves you of the responsibility of making sure appropriate barriers are created between writes and reads to disk--message passing is more fundamental than programming paradigms, and you physically must make sure your messages synchronize somehow (and that you can recover from corrupted state, if there's a crash). Just writing once simply is not enough here! Also, without mutable state, how do I find the new head (where the appended stuff starts?). This has historically been a very annoying problem to deal with! Not that I think most of these concerns affect us much during day-to-day programming, by the way! I just find this a particularly poor example of the benefits of FP. In pretty much any useful distributed system, there will be some moving parts that need to be synchronized (like the actual messages to the storage layer), some state that needs to be maintained (root information a bootloader can follow to restore the system), and some weird domain specific stuff that's very hard to encode in types (like crash recovery, in this case). This is true whether or not what you want to do is conceptually purely functional--someone has to make decisions at each of these points about whether and how to expose the inner workings of the system, often in a way that trades off against things like flexibility, space overhead, reliability, and performance. And those decisions have to be relayed to the computer via some programming language that can talk state (or embedded into the hardware). Accepting that reality doesn't mean that everything has to be written in a "multiparadigm language" or anything like that, but it does mean being cautious about declaring that your favorite technique will automatically solve the issues plaguing another area of CS.