4 ms·

> Haskell's perceived as an impractical language because it is one †. Theoretically maybe ;) The real world disagrees with you however: https://www.fpcomplet

> Haskell's perceived as an impractical language because it is one †. Theoretically maybe ;) The real world disagrees with you however: https://www.fpcomplete.com/business/haskell-industry/ https://www.fpcomplete.com/business/haskell-industry/ https://wiki.haskell.org/Haskell_in_industry https://wiki.haskell.org/Haskell_in_industry > At the line-by-line level, purely functional code also takes more effort to edit, once written, than imperative code. How? You can locally reason about purely functional code which makes it much easier to edit then it's imperative counterpart which likely depends on global mutable state. > Lazy evaluation is a big risk, if you aren't writing programs that start and finish. Have you written much lazy evaluated code? Have you written much Haskell code? > and there's a big spooky bit of danger that comes with it. Can you elaborate on this? It sounds like "Haskell is bad because reasons that are spooky".

deeviant 11y ago
You link two cherry picked pro-Haskell links as proof that "the world believes that Haskell's is totally practical language"? Good grief.
- codygman 11y ago
  I was never trying to prove "the world believes that Haskell's is totally practical language". My response was purely a rebuttal to: "Haskell's perceived as an impractical language because it is one" The "cherry picked pro-Haskell links" were picked because they link to examples of Haskell's practical uses in industry. Should I have created a faulty rebuttal that didn't list real world counter-examples of "Haskell's perceived as an impractical language because it is one"? I don't think I could find a link to practical uses of any language in industry that wasn't "cherry picked".
SamReidHughes 11y ago
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.
efnx 11y ago
Dude - stop trying to explain to HN how great Haskell is. The longer it takes people to catch on the more of a head start we get. In the mean time we can continue to be extremely productive writing programs we can maintain easily and refactor confidently without unit tests, while reaping the benefits of a great community that provides an awesome standard library and thousands of other useful packages (all in a cohesive, standard format). It may not be as fast as hand optimized C. It can be within a factor of 2. Though it can be cross compiled to many platforms without any changes. But I digress - it's my secret weapon and I'd like to keep it that way ;)

deeviant 11y ago

You link two cherry picked pro-Haskell links as proof that "the world believes that Haskell's is totally practical language"? Good grief.

codygman 11y ago
I was never trying to prove "the world believes that Haskell's is totally practical language". My response was purely a rebuttal to: "Haskell's perceived as an impractical language because it is one" The "cherry picked pro-Haskell links" were picked because they link to examples of Haskell's practical uses in industry. Should I have created a faulty rebuttal that didn't list real world counter-examples of "Haskell's perceived as an impractical language because it is one"? I don't think I could find a link to practical uses of any language in industry that wasn't "cherry picked".

SamReidHughes 11y ago

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.

efnx 11y ago

Dude - stop trying to explain to HN how great Haskell is. The longer it takes people to catch on the more of a head start we get. In the mean time we can continue to be extremely productive writing programs we can maintain easily and refactor confidently without unit tests, while reaping the benefits of a great community that provides an awesome standard library and thousands of other useful packages (all in a cohesive, standard format). It may not be as fast as hand optimized C. It can be within a factor of 2. Though it can be cross compiled to many platforms without any changes. But I digress - it's my secret weapon and I'd like to keep it that way ;)