2 ms·

The spooky danger comes from lazy evaluation. The "line-by-line" level has nothing to do with global mutable state. It has to do with locally mutable state.

The spooky danger comes from lazy evaluation. The "line-by-line" level has nothing to do with global mutable state. It has to do with locally mutable state. It's a lot simpler to change code that is written in terms of for loops and accumulator variables, than it is to change code written in terms of maps, folds, intercalates, whatever. In any reasonably architected software, you can see how a function depends on global state by looking at its argument list. Those that use database connections take the database connection. Those that create database connections receive a parameter that tells them what to connect to. Pretty much everything writes log messages. If you're in a position to choose Haskell, then you're also in a position to make your software this way.

phamilton 11y ago
I disagree on the for loops claim. A well written for loop is generally a decomposed pipeline of an optional filter/takeWhile plus a map plus an optional reduce. Easy-to-edit for loops separate those concerns. Easy-to-edit functional programs separate those concerns. It's all the same. As far as "you can see how a function depends on global state by looking at its argument list" you are actually referencing systems that avoid global state. Dependency Injection is the process of taking global state and making it local state.
- efnx 11y ago
  Yeah, for and while loops can be done with a simple fold - accumulating a tuple. But you've got so many other options.
- SamReidHughes 11y ago
  A function that takes a database connection as a parameter does use global state, the state in question being the world outside the process. If you want some convincing about the for loops claim, well, first I recommend considering how keyboard users often overlook cases where using a mouse would be more efficient, and then I recommend trying some programming contest like the Google Code Jam using Haskell. Then try using C++, or D or something. Once upon a time, I didn't do programming contests, but some people from IRC got me to try the Code Jam. I thought I'd use Haskell, being very familiar with it, and the experience was a most illuminating disaster. On the other hand, C++ worked out pretty well, even though I was a total cargo cult functional programming weenie at the time and had a real bad attitude about C++, while having only used it for a couple of college classes. You'll find yourself much more aware of how much time you spend stumbling over functional code after that.
  - codygman 11y ago
    > some people from IRC got me to try the Code Jam. I thought I'd use Haskell, being very familiar with it, and the experience was a most illuminating disaster. On the other hand, C++ worked out pretty well, even though I was a total cargo cult functional programming weenie at the time and had a real bad attitude about C++ Were you familiar with pure functional data structures and algorithms or at least simulating imperative ones with ST when needed? If not, I don't think you can fairly say that Haskell is bad for programming contests whereas C++ worked out pretty well. You at least need to compare the two with an equivalent knowledge of implementing algorithms with each, not that figuring out or even approximating that equivalence would be easy . > You'll find yourself much more aware of how much time you spend stumbling over functional code after that. I'm well aware of when/how much I stumble over functional code since I still have vastly more experience with the imperative paradigm. All I can do is try and keep an open mind to logical arguments and keep writing code in multiple languages and multiple paradigms to know what the best answer is for a given scenario or set of scenarios. > how keyboard users often overlook cases where using a mouse would be more efficient Don't see how this is relevant, but I'll bite... what cases would this be? I of course agree that gaming or navigating a 3d world is better with a mouse, but I struggle to see where programming related tasks would be better suited to using mouse.
    - SamReidHughes 11y ago
      As for Haskell, I was... fully functional, programming with... multiple techniques.
    - SamReidHughes 11y ago
      Now that I'm done putting 900 miles on my odometer, let me expand on that. The ST monad is not the answer. If you're writing code and suddenly you realize you need to modify state, there's a big difference between adding a variable, and rewriting the whole thing to sit inside the ST monad. And if you put everything inside the ST monad in the first place, you're working with a much more cumbersome imperative language than one where you have to write newSTRef for every variable you create.
codygman 11y ago
> It's a lot simpler to change code that is written in terms of for loops and accumulator variables, than it is to change code written in terms of maps, folds, intercalates, whatever. for loops are less structured than maps or folds meaning that divining the meaning of one is more difficult. I think that for loops seem easier because many developers have a lot of previous experience with imperative constructs. > In any reasonably architected software, you can see how a function depends on global state by looking at its argument list. Most code isn't reasonably architected. > If you're in a position to choose Haskell, then you're also in a position to make your software this way. But then you lose out on all of the other advantages of Haskell. I'd love to hear your responses to the reasons why the Haxl team at facebook chose Haskell. Here's a link: https://news.ycombinator.com/item?id=7874537 https://news.ycombinator.com/item?id=7874537

phamilton 11y ago

I disagree on the for loops claim. A well written for loop is generally a decomposed pipeline of an optional filter/takeWhile plus a map plus an optional reduce. Easy-to-edit for loops separate those concerns. Easy-to-edit functional programs separate those concerns. It's all the same. As far as "you can see how a function depends on global state by looking at its argument list" you are actually referencing systems that avoid global state. Dependency Injection is the process of taking global state and making it local state.

efnx 11y ago
Yeah, for and while loops can be done with a simple fold - accumulating a tuple. But you've got so many other options.
SamReidHughes 11y ago
A function that takes a database connection as a parameter does use global state, the state in question being the world outside the process. If you want some convincing about the for loops claim, well, first I recommend considering how keyboard users often overlook cases where using a mouse would be more efficient, and then I recommend trying some programming contest like the Google Code Jam using Haskell. Then try using C++, or D or something. Once upon a time, I didn't do programming contests, but some people from IRC got me to try the Code Jam. I thought I'd use Haskell, being very familiar with it, and the experience was a most illuminating disaster. On the other hand, C++ worked out pretty well, even though I was a total cargo cult functional programming weenie at the time and had a real bad attitude about C++, while having only used it for a couple of college classes. You'll find yourself much more aware of how much time you spend stumbling over functional code after that.
- codygman 11y ago
  > some people from IRC got me to try the Code Jam. I thought I'd use Haskell, being very familiar with it, and the experience was a most illuminating disaster. On the other hand, C++ worked out pretty well, even though I was a total cargo cult functional programming weenie at the time and had a real bad attitude about C++ Were you familiar with pure functional data structures and algorithms or at least simulating imperative ones with ST when needed? If not, I don't think you can fairly say that Haskell is bad for programming contests whereas C++ worked out pretty well. You at least need to compare the two with an equivalent knowledge of implementing algorithms with each, not that figuring out or even approximating that equivalence would be easy . > You'll find yourself much more aware of how much time you spend stumbling over functional code after that. I'm well aware of when/how much I stumble over functional code since I still have vastly more experience with the imperative paradigm. All I can do is try and keep an open mind to logical arguments and keep writing code in multiple languages and multiple paradigms to know what the best answer is for a given scenario or set of scenarios. > how keyboard users often overlook cases where using a mouse would be more efficient Don't see how this is relevant, but I'll bite... what cases would this be? I of course agree that gaming or navigating a 3d world is better with a mouse, but I struggle to see where programming related tasks would be better suited to using mouse.
  - SamReidHughes 11y ago
    As for Haskell, I was... fully functional, programming with... multiple techniques.
  - SamReidHughes 11y ago
    Now that I'm done putting 900 miles on my odometer, let me expand on that. The ST monad is not the answer. If you're writing code and suddenly you realize you need to modify state, there's a big difference between adding a variable, and rewriting the whole thing to sit inside the ST monad. And if you put everything inside the ST monad in the first place, you're working with a much more cumbersome imperative language than one where you have to write newSTRef for every variable you create.

codygman 11y ago

> It's a lot simpler to change code that is written in terms of for loops and accumulator variables, than it is to change code written in terms of maps, folds, intercalates, whatever. for loops are less structured than maps or folds meaning that divining the meaning of one is more difficult. I think that for loops seem easier because many developers have a lot of previous experience with imperative constructs. > In any reasonably architected software, you can see how a function depends on global state by looking at its argument list. Most code isn't reasonably architected. > If you're in a position to choose Haskell, then you're also in a position to make your software this way. But then you lose out on all of the other advantages of Haskell. I'd love to hear your responses to the reasons why the Haxl team at facebook chose Haskell. Here's a link: https://news.ycombinator.com/item?id=7874537 https://news.ycombinator.com/item?id=7874537