4 ms·

Doesn't this fit the definition of a strawman argument? It's entirely possible and very natural to write imperative programs that don't rely on every possible

Doesn't this fit the definition of a strawman argument? It's entirely possible and very natural to write imperative programs that don't rely on every possible global variable your application has ever declared. True, if you're writing a library for consumption by others, then you would have to make it clear that your function depends on certain global variables being defined. But I would like to believe most people writing APIs for use by other programmers would know better than to rely on this type of behavior.

olavk 17y ago
In Haskell you can easily fake an environment with a bunch of mutable global variables avaliable throughout the program, although this is frowned upon. Since global mutable variables are discouraged even in imperative languages, I agree that the argument is a strawman. There is however a nice property that Haskell makes it explicit in the type signature if global mutable state is available to the function. This makes it a lot easier to guarantee that large parts of a program is indeed side-effect free.
nostrademons 17y ago
I think a lot of people missed the article that this one is replying to: http://prog21.dadgum.com/54.html http://prog21.dadgum.com/54.html That article's main point was that functional programming doesn't work because deep in the bowels of two otherwise-pure leaf functions, you might want to make their behavior interdependent. In an imperative language, you can do this through adding a simple global variable. In a functional language, you have to change the signatures of all the callers to add this new parameter. A lot of people pointed out that in a real program, you're asking for massive maintenance headaches if you connect two independent leaf functions through a global variable and make their behavior interdependent. In that context, this isn't a strawman, because somebody actually did suggest structuring programs this way. Make a silly suggestion, get a silly reply. I think both authors would do well to focus less on individual languages or programming paradigms and more on writing actual large-scale software systems. Because the imperative, OO, and functional worlds basically converge on that point: don't do that. You don't want the behavior of apparently-pure functions to change based on hidden, undocumented state. And once you document it, you might as well add it to the function signature, which is your "executable documentation" anyway.
- cemerick 17y ago
  I wasn't replying to that article -- at best, I was going off on a tangent prompted by a comment to that article.
  - nostrademons 17y ago
    Well, then it's a strawman. ;-) Nobody decent actually writes imperative programs where every function depends upon the global state of the whole program.
    - jrockway 17y ago
      The problem is that you can't know for sure until you read every line of code in the program, or at least read every function in a given call chain. In languages like Haskell, the type system ensures that there are functions whose effects can be understood by only reading that one function.
      - kelnos 17y ago
        True, but you're essentially arguing for a "nanny" language model that doesn't let you do things that someone decided is "unsafe" or "bad design." While I'd agree that writing a program in an imperative language where everything depends on hidden global state is a very poor choice, I'd rather use a language that trusts me to design my application as I see fit.
        jrockway 17y ago
        No I'm not. I'm arguing for safety as the default, and un-safety as an option. Haskell gives me this. The usual imperative languages don't even make safety an option. You just have to try hard and hope for the best.
        jimbokun 17y ago
        'True, but you're essentially arguing for a "nanny" language model that doesn't let you do things that someone decided is "unsafe" or "bad design."' Isn't the same true for, say, garbage collection? Higher level languages are often defined by the things they don't let you do, compared to lower level languages, in order to make your life easier. Of course, if you're a C++ programmer, you probably agree that both mandatory garbage collection and immutable state are equally nanny-language features.

olavk 17y ago

In Haskell you can easily fake an environment with a bunch of mutable global variables avaliable throughout the program, although this is frowned upon. Since global mutable variables are discouraged even in imperative languages, I agree that the argument is a strawman. There is however a nice property that Haskell makes it explicit in the type signature if global mutable state is available to the function. This makes it a lot easier to guarantee that large parts of a program is indeed side-effect free.

nostrademons 17y ago

I think a lot of people missed the article that this one is replying to: http://prog21.dadgum.com/54.html http://prog21.dadgum.com/54.html That article's main point was that functional programming doesn't work because deep in the bowels of two otherwise-pure leaf functions, you might want to make their behavior interdependent. In an imperative language, you can do this through adding a simple global variable. In a functional language, you have to change the signatures of all the callers to add this new parameter. A lot of people pointed out that in a real program, you're asking for massive maintenance headaches if you connect two independent leaf functions through a global variable and make their behavior interdependent. In that context, this isn't a strawman, because somebody actually did suggest structuring programs this way. Make a silly suggestion, get a silly reply. I think both authors would do well to focus less on individual languages or programming paradigms and more on writing actual large-scale software systems. Because the imperative, OO, and functional worlds basically converge on that point: don't do that. You don't want the behavior of apparently-pure functions to change based on hidden, undocumented state. And once you document it, you might as well add it to the function signature, which is your "executable documentation" anyway.

cemerick 17y ago
I wasn't replying to that article -- at best, I was going off on a tangent prompted by a comment to that article.
- nostrademons 17y ago
  Well, then it's a strawman. ;-) Nobody decent actually writes imperative programs where every function depends upon the global state of the whole program.
  - jrockway 17y ago
    The problem is that you can't know for sure until you read every line of code in the program, or at least read every function in a given call chain. In languages like Haskell, the type system ensures that there are functions whose effects can be understood by only reading that one function.
    - kelnos 17y ago
      True, but you're essentially arguing for a "nanny" language model that doesn't let you do things that someone decided is "unsafe" or "bad design." While I'd agree that writing a program in an imperative language where everything depends on hidden global state is a very poor choice, I'd rather use a language that trusts me to design my application as I see fit.
      - jrockway 17y ago
        No I'm not. I'm arguing for safety as the default, and un-safety as an option. Haskell gives me this. The usual imperative languages don't even make safety an option. You just have to try hard and hope for the best.
      - jimbokun 17y ago
        'True, but you're essentially arguing for a "nanny" language model that doesn't let you do things that someone decided is "unsafe" or "bad design."' Isn't the same true for, say, garbage collection? Higher level languages are often defined by the things they don't let you do, compared to lower level languages, in order to make your life easier. Of course, if you're a C++ programmer, you probably agree that both mandatory garbage collection and immutable state are equally nanny-language features.