3 ms·

There is a reality out there, we're not arguing over pastels vs. chalk vs. pencils. You can write webapps in assembly if you're so motivated and tenacious.

jfl 17y ago
Yes. But do you understand that every one has its own partial, subjective view of that reality. Your post is your own view, not an neutral, scientific study. Your point ("mutable state equals additionnal arguments to all functions") is at best a caricature or just plain wrong : a function can access only the part of the state it has in scope or for which it has a handle, most of the time by dereferencing its arguments, in a controlled fashion. I would love to find some good paper about new ways to tame the state of my program, how to manage the references that flow accross my call stack and get duplicated without my being aware of. Pointer uniqueness ? pointer adoption ? State partition by domain ? Nothing compelling so far. Unless you have to share state between threads, There is no problem using imperative style in a multithread environment. Threads allocated to incoming requests in typical webapps don't share state (they do it through the database). When it comes to FP, the tone is usually "you're doing it all wrong" and the message more or less "do without state". In other words, alleviate some pain by enduring some different kind of pain. My subjective view... Peace.
- cemerick 17y ago
  A caller of a function in an imperative environment cannot assume anything about the scope of that function's access of mutable state within the program. My characterization of the situation might be a little spectacular w.r.t. specifics (e.g. 316 arguments, etc), but I've not seen a robust refutation of the principle. There's no doubt that there is subjectivity w.r.t. practices and methodologies, not to mention domain-specific tendencies and requirements. But it's a little absurd to claim that, very specifically, mutable state is on par with persistent data structures (or, at the very least, immutable state constructs) on almost any axis of reliability or ability to reason about a program's operation, especially in conjunction with any degree of concurrency. "Pain" is definitely subjective. IMO, if you're not feeling at least a little pain, you're not pushing your skills, your craft, etc. Too much pain, and it's possible you've not kept yourself limber enough to stretch for the big wins, regardless of context.
  - jfl 17y ago
    "A caller of a function in an imperative environment cannot assume anything about the scope of that function's access of mutable state within the program" This really doesn't make sense. main() { A a = new A(); f(); ... } the caller main() can assume that "a" is not in scope of f(). Is it the robust refutation you need ? The caller can further assume that the scope of f() is limited to the part of the state for which there is a path from a global variable or from one of its parameters (You can see the state as a graph. The nodes are the data and the links are the references) Therefore, this scope is not the whole state but a limited subset of the state. Claiming otherwise is wrong and does not help to bring attention to what need to be improved : this subset is itself a superset of the part of the state that the function really need. We need new techniques to hide more state to the function, for example some kind dereferencement control ?
    - KirinDave 17y ago
      I believe cemerick meant, "A caller of a function in an imperative environment cannot assume anything about the scope of that function's access of mutable state within the program without reading the entire program." If they verify it by perfectly understanding the underlying code, the of course that doesn't hold. But even in the code snippet you gave us, we really don't know if global state is being manipuated. For example, A could be handling global counters or referencing global variables (common example: stdin and stdout). And how do you know that a doesn't get manipulated by f()? You'd have to check! Perhaps A's constructor registers all A's it every creates and then f() marks all A's for protection from garbage collection? Really, we can't assume anything about the code snippet you gave us without verifying it. The code might be modular, it might be reasonably modular, or it might be a complete mess. This boundary of uncertainty is what functional programmers are railing against, and what you're defending.
      - deleted 17y ago
        [deleted]
      - jfl 17y ago
        We have to agree to disagree. Peace.

jfl 17y ago

Yes. But do you understand that every one has its own partial, subjective view of that reality. Your post is your own view, not an neutral, scientific study. Your point ("mutable state equals additionnal arguments to all functions") is at best a caricature or just plain wrong : a function can access only the part of the state it has in scope or for which it has a handle, most of the time by dereferencing its arguments, in a controlled fashion. I would love to find some good paper about new ways to tame the state of my program, how to manage the references that flow accross my call stack and get duplicated without my being aware of. Pointer uniqueness ? pointer adoption ? State partition by domain ? Nothing compelling so far. Unless you have to share state between threads, There is no problem using imperative style in a multithread environment. Threads allocated to incoming requests in typical webapps don't share state (they do it through the database). When it comes to FP, the tone is usually "you're doing it all wrong" and the message more or less "do without state". In other words, alleviate some pain by enduring some different kind of pain. My subjective view... Peace.

cemerick 17y ago
A caller of a function in an imperative environment cannot assume anything about the scope of that function's access of mutable state within the program. My characterization of the situation might be a little spectacular w.r.t. specifics (e.g. 316 arguments, etc), but I've not seen a robust refutation of the principle. There's no doubt that there is subjectivity w.r.t. practices and methodologies, not to mention domain-specific tendencies and requirements. But it's a little absurd to claim that, very specifically, mutable state is on par with persistent data structures (or, at the very least, immutable state constructs) on almost any axis of reliability or ability to reason about a program's operation, especially in conjunction with any degree of concurrency. "Pain" is definitely subjective. IMO, if you're not feeling at least a little pain, you're not pushing your skills, your craft, etc. Too much pain, and it's possible you've not kept yourself limber enough to stretch for the big wins, regardless of context.
- jfl 17y ago
  "A caller of a function in an imperative environment cannot assume anything about the scope of that function's access of mutable state within the program" This really doesn't make sense. main() { A a = new A(); f(); ... } the caller main() can assume that "a" is not in scope of f(). Is it the robust refutation you need ? The caller can further assume that the scope of f() is limited to the part of the state for which there is a path from a global variable or from one of its parameters (You can see the state as a graph. The nodes are the data and the links are the references) Therefore, this scope is not the whole state but a limited subset of the state. Claiming otherwise is wrong and does not help to bring attention to what need to be improved : this subset is itself a superset of the part of the state that the function really need. We need new techniques to hide more state to the function, for example some kind dereferencement control ?
  - KirinDave 17y ago
    I believe cemerick meant, "A caller of a function in an imperative environment cannot assume anything about the scope of that function's access of mutable state within the program without reading the entire program." If they verify it by perfectly understanding the underlying code, the of course that doesn't hold. But even in the code snippet you gave us, we really don't know if global state is being manipuated. For example, A could be handling global counters or referencing global variables (common example: stdin and stdout). And how do you know that a doesn't get manipulated by f()? You'd have to check! Perhaps A's constructor registers all A's it every creates and then f() marks all A's for protection from garbage collection? Really, we can't assume anything about the code snippet you gave us without verifying it. The code might be modular, it might be reasonably modular, or it might be a complete mess. This boundary of uncertainty is what functional programmers are railing against, and what you're defending.
    - deleted 17y ago
      [deleted]
    - jfl 17y ago
      We have to agree to disagree. Peace.