3 ms·

Meh. I have had the time to learn a fair amount of Haskell and do a few projects in it (mainly interpreters). It's a fun language in some ways, and it was nice

Meh. I have had the time to learn a fair amount of Haskell and do a few projects in it (mainly interpreters). It's a fun language in some ways, and it was nice to know how to use it because it expands your ways of thinking, but beyond that it's not terribly useful, and I don't think that it's much better at that than other functional programming languages. Learning about the type-system is neat but IMO not as perspective changing as "getting" purely functional programming. However, as an actual tool to do actual work, I really don't see why you would go about it for anything but very specific projects.

feanaro 4y ago
I seriously suspect there is a bimodal distribution are play here, because I would love to use Haskell, or something like it that's possibly more powerful like Idris, wherever I could. And at the same time I notice a lot of people expressing your sentiment. These systems make it easy(er) to model concepts in a mathematical way and this is my natural (or preferred?) mode of thinking. And they enable you to do it easily and ergonomically. What is there not to like? (I know there are flaws at hand, even some potentially very debilitating flaws depending on your use case. But damn, I'd use these languages wherever I can.)
- sudosysgen 4y ago
  See the thing is, I also love thinking about things mathematically/as relations/as recurrences. But I like the more imperative way of thinking about algorithms and data wrangling just as much. So in practice, I'll go for a language that allows me to do both easily, instead of going for something like Haskell where any imperative way of doing things is very painful (as well as other issues, of course). So why would I use Haskell and limit myself for fairly marginal benefit?
  - rowanG077 4y ago
    How is the imperative way painful in Haskell? Nothing stops you from just writing everything in the IO monad if you feel your algorithm is easier to write in an imperative style.
    - sudosysgen 4y ago
      What's the point of using Haskell if I'm going to do that? I much prefer using a language that does imperative programming very well and functional programming fairly well if I'm going to use both.
      - rowanG077 4y ago
        Because Haskell is a general purpose programming language. It doesn't do imperative programming worse then for example Python or C#.
        sudosysgen 4y ago
        That's very false. Python or C# are significantly better at imperative programming.
      - feanaro 4y ago
        The point is you're going to have parts of the program where you won't be doing imperative style at which Haskell will excel, including at combining and composing the imperative and non-imperative components. There is also the saying that Haskell is the world's best imperative language, and that is not without reason, since you can re-use its usual power of abstraction while writing imperative code too.
        sudosysgen 4y ago
        I completely disagree that Haskell is a good imperative style language. It's barely adequate by today's standards. It's awkward, it has a bad ecosystem, it has just as many issues with hidden state, etc... The only reason you would want to write imperative Haskell over a modern imperative language is the typesystem, but even that can be an issue sometimes, and I'd risk saying that the Rust or C++ typesystems while being very slightly less expressive are better at scale overall due to their flexibility imo. Another big one is that it really sucks to debug. Seriously, it's brutally slow compared to what you can do with a good debugger in other languages. If you care about performance, Haskell can be significantly worse than others, both lower level compiled languages (lazy evaluation, large amounts of trash to be collected by the GC, cache trashing, etc...), and higher level interpreted languages, due to the lack of native accommodations to bind into fast code, or even into GPUs. There are a lot of disadvantages to Haskell if you're going to do mostly imperative code.
  - jose_zap 4y ago
    Haskell is a great language for imperative programming, actually. You are not limited by the language in that regard.
    - sudosysgen 4y ago
      People say that a lot, but it's not my experience. Your imperative code will be less readable, an order of magnitude more difficult to debug, and it's going to be much harder to leverage the ecosystem.
      - jose_zap 4y ago
        Our experiences differ, then. I have found it to be more easy to refactor and parallelize that other languages I have used. Debugging has not been difficult either, but I have always use print debugging in every language, so there is not much I can compare.
  - feanaro 4y ago
    For me personally, it is because the benefit is not fairly marginal nor do I feel like limiting myself when using Haskell, not even for imperative parts of the program.
- galaxyLogic 4y ago
  > Haskell code has the unfortunate property that the types of the functions are harder to understand than their implementations. Interesting point. What is the purpose of type-declarations? To make implementation easier to understand, I think. When you know (and understand) the type of a component or function you know how to use it, and how to not use it, and thus how to write code that uses it and does what you think it should do. But if types are harder to understand than the implementation, then types don't help much, do they?
  - axman6 4y ago
    On the contrary, when you can move your complexity into the type system, the. You have just taught your compiler how to check that you are using things correctly, and that is insanely useful in large scale software.
- jstimpfle 4y ago
  > These systems make it easy(er) to model concepts in a mathematical way I feel this is largely a lie. The type system is still a crippled language that is also incompatible with the runtime language. It possible to do some very specific things in it, but does it help you describe a system's data flows? Memory allocation patterns? GUI layout engine? I think the solution is: Just use regular code, it works best. Use types to describe interfaces. Simple types, because with anything else you're painting yourself in a corner.
  - feanaro 4y ago
    I think it is largely not, though it's not something that is a magical solution to all modelling problems. It probably depends on the domain you're solving problems in, but on the other hand, I've written CRUD applications in Haskell successfully and would characterize it as a nice experience. > It possible to do some very specific things in it, but does it help you describe a system's data flows? Memory allocation patterns? GUI layout engine? I feel you're underselling quite a bit when you say very specific things, but again, perhaps this depends on the problem domain, your thinking style, your programming style or some other undetermined factor. Out of the things you mention, I would say a definite yes to system's data flows, weaker yes for GUI layout and no to memory allocation patterns, because that is a known weak point.
axman6 4y ago
> it’s not terribly useful Well, it’s been paying my wages for the past eight years, so it’s incredibly useful to me. Are we services “very specific projects”? Are data processing systems? Are geospatial data munging? Are financial systems? Those all sound like mundane, every day projects, and they’re exactly what I’ve been working on. And when it comes to “actual work”, that’s where Haskell truly shines - being able to fearless refactor code and iterate until the compiler is happy again is my favourite feature of Haskell. It’s not the “neat type system”, it’s the ability to not have to keep the entire project in my head at absolutely all times because I might forget to make a stupid change the compiler should have caught for me. The productivity is massive, once you’ve invested the time, but it does take time and it is an investment.

feanaro 4y ago

I seriously suspect there is a bimodal distribution are play here, because I would love to use Haskell, or something like it that's possibly more powerful like Idris, wherever I could. And at the same time I notice a lot of people expressing your sentiment. These systems make it easy(er) to model concepts in a mathematical way and this is my natural (or preferred?) mode of thinking. And they enable you to do it easily and ergonomically. What is there not to like? (I know there are flaws at hand, even some potentially very debilitating flaws depending on your use case. But damn, I'd use these languages wherever I can.)

sudosysgen 4y ago
See the thing is, I also love thinking about things mathematically/as relations/as recurrences. But I like the more imperative way of thinking about algorithms and data wrangling just as much. So in practice, I'll go for a language that allows me to do both easily, instead of going for something like Haskell where any imperative way of doing things is very painful (as well as other issues, of course). So why would I use Haskell and limit myself for fairly marginal benefit?
- rowanG077 4y ago
  How is the imperative way painful in Haskell? Nothing stops you from just writing everything in the IO monad if you feel your algorithm is easier to write in an imperative style.
  - sudosysgen 4y ago
    What's the point of using Haskell if I'm going to do that? I much prefer using a language that does imperative programming very well and functional programming fairly well if I'm going to use both.
    - rowanG077 4y ago
      Because Haskell is a general purpose programming language. It doesn't do imperative programming worse then for example Python or C#.
      - sudosysgen 4y ago
        That's very false. Python or C# are significantly better at imperative programming.
    - feanaro 4y ago
      The point is you're going to have parts of the program where you won't be doing imperative style at which Haskell will excel, including at combining and composing the imperative and non-imperative components. There is also the saying that Haskell is the world's best imperative language, and that is not without reason, since you can re-use its usual power of abstraction while writing imperative code too.
      - sudosysgen 4y ago
        I completely disagree that Haskell is a good imperative style language. It's barely adequate by today's standards. It's awkward, it has a bad ecosystem, it has just as many issues with hidden state, etc... The only reason you would want to write imperative Haskell over a modern imperative language is the typesystem, but even that can be an issue sometimes, and I'd risk saying that the Rust or C++ typesystems while being very slightly less expressive are better at scale overall due to their flexibility imo. Another big one is that it really sucks to debug. Seriously, it's brutally slow compared to what you can do with a good debugger in other languages. If you care about performance, Haskell can be significantly worse than others, both lower level compiled languages (lazy evaluation, large amounts of trash to be collected by the GC, cache trashing, etc...), and higher level interpreted languages, due to the lack of native accommodations to bind into fast code, or even into GPUs. There are a lot of disadvantages to Haskell if you're going to do mostly imperative code.
- jose_zap 4y ago
  Haskell is a great language for imperative programming, actually. You are not limited by the language in that regard.
  - sudosysgen 4y ago
    People say that a lot, but it's not my experience. Your imperative code will be less readable, an order of magnitude more difficult to debug, and it's going to be much harder to leverage the ecosystem.
    - jose_zap 4y ago
      Our experiences differ, then. I have found it to be more easy to refactor and parallelize that other languages I have used. Debugging has not been difficult either, but I have always use print debugging in every language, so there is not much I can compare.
- feanaro 4y ago
  For me personally, it is because the benefit is not fairly marginal nor do I feel like limiting myself when using Haskell, not even for imperative parts of the program.
galaxyLogic 4y ago
> Haskell code has the unfortunate property that the types of the functions are harder to understand than their implementations. Interesting point. What is the purpose of type-declarations? To make implementation easier to understand, I think. When you know (and understand) the type of a component or function you know how to use it, and how to not use it, and thus how to write code that uses it and does what you think it should do. But if types are harder to understand than the implementation, then types don't help much, do they?
- axman6 4y ago
  On the contrary, when you can move your complexity into the type system, the. You have just taught your compiler how to check that you are using things correctly, and that is insanely useful in large scale software.
jstimpfle 4y ago
> These systems make it easy(er) to model concepts in a mathematical way I feel this is largely a lie. The type system is still a crippled language that is also incompatible with the runtime language. It possible to do some very specific things in it, but does it help you describe a system's data flows? Memory allocation patterns? GUI layout engine? I think the solution is: Just use regular code, it works best. Use types to describe interfaces. Simple types, because with anything else you're painting yourself in a corner.
- feanaro 4y ago
  I think it is largely not, though it's not something that is a magical solution to all modelling problems. It probably depends on the domain you're solving problems in, but on the other hand, I've written CRUD applications in Haskell successfully and would characterize it as a nice experience. > It possible to do some very specific things in it, but does it help you describe a system's data flows? Memory allocation patterns? GUI layout engine? I feel you're underselling quite a bit when you say very specific things, but again, perhaps this depends on the problem domain, your thinking style, your programming style or some other undetermined factor. Out of the things you mention, I would say a definite yes to system's data flows, weaker yes for GUI layout and no to memory allocation patterns, because that is a known weak point.

axman6 4y ago

> it’s not terribly useful Well, it’s been paying my wages for the past eight years, so it’s incredibly useful to me. Are we services “very specific projects”? Are data processing systems? Are geospatial data munging? Are financial systems? Those all sound like mundane, every day projects, and they’re exactly what I’ve been working on. And when it comes to “actual work”, that’s where Haskell truly shines - being able to fearless refactor code and iterate until the compiler is happy again is my favourite feature of Haskell. It’s not the “neat type system”, it’s the ability to not have to keep the entire project in my head at absolutely all times because I might forget to make a stupid change the compiler should have caught for me. The productivity is massive, once you’ve invested the time, but it does take time and it is an investment.