4 ms·

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

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.
        axman6 4y ago
        I have to disagree with vm this, Haskell is by far the most powerful imperative language I’ve used, because it allows me to abstract what I mean by imperative programming. I don’t have time to go into details but nearly every statement you’ve made here is in my opinion wrong, other than the difficulty in debugging (and there are very good reasons why this is difficult). I’ e never found it hard to write fast Haskell, because I put in the effort to learn how to do it. People forget they also put in the time to learn how to write fast C++, and Java; it’s a very large portion of any software engineering curriculum, it’s literally what algorithms is all about. People find writing fast Haskell hard not because it is fundamentally hard, but because they were never taught how. > due to the lack of native accommodations to bind into fast code, or even into GPUs. I have no idea what you mean by this, GHC provides a very good FFI, and there are libraries for binding to Rust, R, Objective-C and others. We also have Accelerate for data processing on GPUs, which includes runtime compilation of native code for both GPUs and CPUs.
  - jstimpfle 4y ago
    Have you tried?
    - rowanG077 4y ago
      Yes, what kind of question is that? Why would I say this if I didn't do it myself. I have written many imperative style functions in Haskell. It's basically required if you are doing things with files, network or Hardware interfaces.
      - sudosysgen 4y ago
        We're not talking about functions, rather about larger programs where most of the code has to be imperative.
        feanaro 4y ago
        What are these programs where most of the code has to be imperative? That seems like a design decision, not an inherent constraint for most programs.
- 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.

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.
      - axman6 4y ago
        I have to disagree with vm this, Haskell is by far the most powerful imperative language I’ve used, because it allows me to abstract what I mean by imperative programming. I don’t have time to go into details but nearly every statement you’ve made here is in my opinion wrong, other than the difficulty in debugging (and there are very good reasons why this is difficult). I’ e never found it hard to write fast Haskell, because I put in the effort to learn how to do it. People forget they also put in the time to learn how to write fast C++, and Java; it’s a very large portion of any software engineering curriculum, it’s literally what algorithms is all about. People find writing fast Haskell hard not because it is fundamentally hard, but because they were never taught how. > due to the lack of native accommodations to bind into fast code, or even into GPUs. I have no idea what you mean by this, GHC provides a very good FFI, and there are libraries for binding to Rust, R, Objective-C and others. We also have Accelerate for data processing on GPUs, which includes runtime compilation of native code for both GPUs and CPUs.
- jstimpfle 4y ago
  Have you tried?
  - rowanG077 4y ago
    Yes, what kind of question is that? Why would I say this if I didn't do it myself. I have written many imperative style functions in Haskell. It's basically required if you are doing things with files, network or Hardware interfaces.
    - sudosysgen 4y ago
      We're not talking about functions, rather about larger programs where most of the code has to be imperative.
      - feanaro 4y ago
        What are these programs where most of the code has to be imperative? That seems like a design decision, not an inherent constraint for most programs.
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.