Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Failing in Haskell

jappie.me

Post reply on HN
Print view View original

41–50 of 55 posts

Re: Failing in Haskell

#41

Post by siknad »

cleancoder0 wrote: post #34
schwurb wrote: post #20

Adressing the whitespread conception "It is hard to programm in Haskell because it is pure": If you can write python, you can write Haskell. Don't believe me? 1. Write your program completely in the IO Monad, in a huge do-block 2. Factor out as much pure functionality as possible (= Have as little code in your big IO-programm as possible.) Start at 1. and iterate 2. as many times as you please. It will already be a p…

What Haskell did with Monads is nice, but eventually Monads are just tags on what functionality the function uses. That being said, I like that Nim and Koka did exactly that. You just tag the functions (IO, Async, Whatever) and it works. In Haskell, you need monad transformers (which have a runtime costs) or whatever else was made to allow you to work with multiple different effects.

> which have a runtime costs

As monad is just an interface, it doesn't necessary cause runtime costs. Identity is a monad too. Effects may not always require sacrificing performance, but as they can be used to implement exceptions they are not just free compile time annotations. Also the differences discussed there: https://www.reddit.com/r/haskell/comments/3nkv2a/why_dont_we...

Re: Failing in Haskell

#42

Post by zeepthee »

HL33tibCe7 wrote: post #35

> Some of my intelligent colleagues mucked up error handling. Not only were they failing, they were failing WRONG 1. This frustrates me because doing failing correctly in Haskell is quite easy Leaving aside that publicly shitting on your colleagues is an extremely bad look and makes you come across incredibly arrogant, isn’t the fact that the intelligent colleagues didn’t get it pretty strong evidence that error hand…

I changed it, lov me HL33tibCe7 senpai

Re: Failing in Haskell

#43

Post by matt_kantor »

andi999 wrote: post #38
AnimalMuppet wrote: post #36

Earlier quoted context omitted.

Well... wasn't numpy, at least initially, a Python wrapper around Fortran libraries? Sure, that made them accessible to a bunch more people, but it wasn't some Python-only wonder. Someone could probably write the same bindings for Haskell, if they haven't already.

Maybe some of the experts could name the haskell equivalent libraries/wrappers.

I'm certainly not an expert (have only dabbled in both Haskell and Python, and never used numpy), but a web search found https://pechersky.github.io/haskell-numpy-docs which compares numpy to https://hackage.haskell.org/package/hmatrix. I also came across https://hackage.haskell.org/package/vector.

Re: Failing in Haskell

#44

Post by caente »

youerbt wrote: post #14
codeflo wrote: post #5

I've written small stuff in Haskell a decade ago. I have a soft spot for the language -- it has clearly influenced many notable languages that came after it. But I also admire the patience of anyone who actually manages to use it in practice, there are so many little papercuts that don't get resolved, basically for a decade or more. If I'm cynical, I'd say that's because little practical stuff is often not worth publ…

> But I also admire the patience of anyone who actually manages to use it in practice Nothing you point out gets even close, in my mind, to stuff like null pointers or untyped code. So I wonder what languages you have in mind that require less patience. > you need IO for that. Which the language makes intentionally hard to use Well, that is simply not true.

>Nothing you point out gets even close, in my mind, to stuff like null pointers or untyped code. So I wonder what languages you have in mind that require less patience.

You two are talking about two different things: - The parent is talking about the ecosystem, how menial tasks have tooling in "less interesting" languages - You are talking about the language itself

I would venture to guess that the parent would agree with you, if talking about the language in a vacuum.

An interesting competition would be to develop a complex product, without external dependencies.

My sad guess is that languages that are filled with escape hatches, like Java, Javascript, or python, would defeat more strict languages.

It's a sad guess, because I actually do prefer the Haskell way.

Re: Failing in Haskell

#45

Post by Kototama »

schwurb wrote: post #20

Adressing the whitespread conception "It is hard to programm in Haskell because it is pure": If you can write python, you can write Haskell. Don't believe me? 1. Write your program completely in the IO Monad, in a huge do-block 2. Factor out as much pure functionality as possible (= Have as little code in your big IO-programm as possible.) Start at 1. and iterate 2. as many times as you please. It will already be a p…

It's hard because there are so many concepts to understand. After reading one Python book you can write solid programs in Python. Not so in Haskell, you would need to understand also the extensions of the language which are popular and understand the best practices (what to use to compose I/O and in which context for example), on top of all the basics. That and understand how to work with complex types in libraries: that require time. That would be too much for one book.

Re: Failing in Haskell

#46

Post by DarylZero »

siknad wrote: post #41
cleancoder0 wrote: post #34

Earlier quoted context omitted.

What Haskell did with Monads is nice, but eventually Monads are just tags on what functionality the function uses. That being said, I like that Nim and Koka did exactly that. You just tag the functions (IO, Async, Whatever) and it works. In Haskell, you need monad transformers (which have a runtime costs) or whatever else was made to allow you to work with multiple different effects.

> which have a runtime costs As monad is just an interface, it doesn't necessary cause runtime costs. Identity is a monad too. Effects may not always require sacrificing performance, but as they can be used to implement exceptions they are not just free compile time annotations. Also the differences discussed there: https://www.reddit.com/r/haskell/comments/3nkv2a/why_dont_we...

Monad transformers are different from monads. Monad transformers do have runtime costs, they are adding indirection at runtime.

Re: Failing in Haskell

#47

Post by DarylZero »

dundarious wrote: post #16
madsbuch wrote: post #13

Earlier quoted context omitted.

What you are running into is the pureness of Haskell. The `head` function in Haskell is only partially defined. What you see as an exception is a case where a function is not defined. This is all by intent. defining a `head :: [a] -> Maybe a` is a very simple matter and definitely something a developer should be encouraged instead of using the prelude. exceptions in Haskell are not meant to be used as a first class t…

The issue as I see it, is that one of the main selling points of a pure language like Haskell, is that you have to explicitly state where a certain class of surprises/failures (from IO) lie, and therefore, you can account for them better, handle them cleanly, prevent them from arising accidentally or in some ways maliciously, etc. Partial functions are another kind of surprise/failure, but they are not at all explici…

> quite common/natural and accepted to use head

No it isn't, not at all.

What absurd slander.

Re: Failing in Haskell

#48

Post by toomanydoubts »

codeflo wrote: post #5

I've written small stuff in Haskell a decade ago. I have a soft spot for the language -- it has clearly influenced many notable languages that came after it. But I also admire the patience of anyone who actually manages to use it in practice, there are so many little papercuts that don't get resolved, basically for a decade or more. If I'm cynical, I'd say that's because little practical stuff is often not worth publ…

There are some alternative Preludes that attempt to fix this, bringing a safer std lib to the table.

Re: Failing in Haskell

#49

Post by whateveracct »

DarylZero wrote: post #46
siknad wrote: post #41

Earlier quoted context omitted.

> which have a runtime costs As monad is just an interface, it doesn't necessary cause runtime costs. Identity is a monad too. Effects may not always require sacrificing performance, but as they can be used to implement exceptions they are not just free compile time annotations. Also the differences discussed there: https://www.reddit.com/r/haskell/comments/3nkv2a/why_dont_we...

Monad transformers are different from monads. Monad transformers do have runtime costs, they are adding indirection at runtime.

Sometimes - it's pretty cool what GHC can do

Re: Failing in Haskell

#50

Post by [deleted] »

schwurb wrote: post #20

Adressing the whitespread conception "It is hard to programm in Haskell because it is pure": If you can write python, you can write Haskell. Don't believe me? 1. Write your program completely in the IO Monad, in a huge do-block 2. Factor out as much pure functionality as possible (= Have as little code in your big IO-programm as possible.) Start at 1. and iterate 2. as many times as you please. It will already be a p…

[deleted]
Post reply on HN