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

51–55 of 55 posts

Re: Failing in Haskell

#51

Post by smegma2 »

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.

> Well, that is simply not true.

I think it's true, for example catch [1] requires IO. Do you mean with unsafePerformIO, or something else?

1: https://hackage.haskell.org/package/base-4.16.0.0/docs/Contr...

Re: Failing in Haskell

#52

Post by schwurb »

Kototama wrote: post #45
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:…

> After reading one Python book you can write solid programs in Python.

Okay, so our goal is to write a solid program. Let's see...

> Not so in Haskell, you would need to understand also the extensions of the language which are popular

You can simply go with vanilla Haskell2010. Dealing with strings will be a bit cumbersome, dealing with records will be a bit cumbersome, but you are still at 50% the boilerplate of an average java codebase.

> and understand the best practices (what to use to compose I/O and in which context for example)

No! This is what I was aiming at: You don't have to understand these best practises to have a solid program. Throw everything into one massive do-Block and the resulting program will be at least as solid as the solid python program.

> That and understand how to work with complex types in libraries

I concur that Python documentation is heaps better than Haskell documentation, although we are slowly improving. That said, I think the work is not harder: Learning how to speak with a postgres database or do numerical tasks requires times, period. What is different to Python is that the time spent chasing runtime errors is spent chasing compile errors in Haskell.

Another user linked this comparison of numpy vs. the Haskell equivalent, hmatric. It does not look more complicated in my opinion: https://pechersky.github.io/haskell-numpy-docs/

Re: Failing in Haskell

#53

Post by tome »

Kototama wrote: post #45
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:…

> you would need to understand also the extensions of the language

Not really. Extensions typically remove restrictions rather than add features, or rather, the ones you are likely to want to use do.

Re: Failing in Haskell

#54

Post by Tainnor »

bspammer wrote: post #32
Tainnor wrote: post #26

Earlier quoted context omitted.

Partial functions and exceptions are a compromise solution for the fact that you sometimes do know more than the compiler does. I think it's fine to throw an exception in the case of "programmer error". It's the equivalent of assertions in other languages. Yes, it can blow up, but at least the error is a bit more localised. Having head return a Maybe means that you'll have to awkwardly handly a Nothing case even in s…

Haskell has had non-empty lists as a type for a long time: https://hackage.haskell.org/package/base-4.16.0.0/docs/Data-... Having partial functions in the Prelude is, as far as I know, widely regarded as a mistake and they are only kept around for backwards compatibility. Anyone writing code nowadays should be using safeHead or non-empty lists.

Sure, but non-empty lists don't generalise easily to the case where you need the nth element, unless you nest them awkwardly.

Re: Failing in Haskell

#55

Post by andi999 »

AnimalMuppet wrote: post #36
andi999 wrote: post #33

Earlier quoted context omitted.

I like the idea of iterating from imperative to functional. Here the devils advocate for your if you can do it in python you can do it in haskell: I use quite a bit of numpy, scipy and matplotlib, are there equivalent libraries for Haskell?

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.

The old joke comes to mind:'How do you recognize a guitar player in the audience of a concert? They stand in a corner look at the stage and say 'I also could do that' '
Post reply on HN