Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The issue is basically that haskell is a lazy language which ends up leaking memory left and right. Most people that I have talked to about it seem to agree that haskell would be a trillion times better if it was a strict language. At least we now have Idris.


If Haskell was a strict language, we would never have invented monadic effects and would still be using () -> to (poorly) represent effects. Laziness forces you to avoid many such janky hacks that pervade almost every single strict language in existence (including most strict "functional" languages, where "functions" are, half the time, actually not), and which most people aren't even aware are janky hacks until they program with some kind of typed effect system


> we would never have invented monadic effects and would still be using () -> to (poorly) represent effects

What makes you think that?

> where "functions" are, half the time, actually not

Please elaborate.


  function foo() {
    print('effects');
  }
The above is not a function. It's a procedure.


And what about

    bar = error "effects"


It's a partial function that always returns _|_. Haskell is not a total language (and whether a total language can be practical is yet to be seen).


Sure, but what it returns is not an issue. The issue is that it does have an effect.


Whether it has an effect is not an issue. The issue is that it is referentially transparent.

Sure, we could have a discussion about whether partiality is an effect. Someone, somewhere is having that discussion. If the Haskell committee had had this discussion in 1987, chances are we wouldn't have Haskell at all.


This is the exact same objection people have been raising for 20 years. Yes, lifted types and partiality are probably bad. No, this isn’t an argument against distinguishing between functions and other objects. If anything, it just goes to show that Haskell should have been even more extremist about effect management.


> No, this isn’t an argument against distinguishing between functions and other objects

It was not supposed to be one. Rather, it was there to show that just like other languages Haskell functions can have effects (even if discouraged).


> What makes you think that?

Haskell is the only language outside of the proof assistant family to avoid the temptation to conflate evaluation with execution. It’s pretty clear in retrospect from looking at old papers on e.g. lazy list IO and old mailing list threads that modern monadic effects were born out of “well shit, Haskell makes us actually deal with this problem instead of doing what every ML language does with ()->”

> Please elaborate.

An object that is not referentially transparent is not a function. “Functions” in most languages are not necessarily referentially transparent, and even if they happen to be in a given case, it’s usually clear to neither the programmer nor the compiler.


Purity is what drives that as much or more than laziness. Well, I guess you can say that laziness came first and drove purity, which in turn drove effects.


Laziness forced haskellers to actually obey purity, because laziness breaks impure hacks.


Let me provide you a different perspective: A lazy language is one that "leaks space". A strict language, however, can "leak time". Imagine building an infinite list and pulling only ten elements from it. This is a situation where a strict language will create a "time leak" by attempting to build an infinite list.


How do you create an infinite list in C++ or Python?


precisely, you can't _because_ you'll have a "time leak" if you attempted such a thing.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: