Live data from Hacker News

Is Haskell really the language of geniuses and academia? (2019)

habr.com

71–80 of 83 posts

Re: Is Haskell really the language of geniuses and academia? (2019)

#71

Earlier quoted context omitted.

Go is only successful because Google spent so much money propping it up by paying people to write stuff in it. It has so many major flaws that it would have had no chance of taking off otherwise. If Google had spent the same amount of money on Haskell instead, it'd be even more popular than Go is today.

Go is very simple, provides decent static type safety, has a nice concurrency model, and compiles to fast static binaries across all major platforms. People choose it all the time because it’s a great choice. A wild number of popular open source tools are written in go, very few of them created by google. As someone who wrote go for many years I think you’re overstating how limiting it’s “major flaws” are. And fwiw g…

Everything you just said either applies equally to Haskell, or is a cultural factor mostly explained by what the parent comment wrote.

Re: Is Haskell really the language of geniuses and academia? (2019)

#72
post #65

Earlier quoted context omitted.

Go is only successful because Google spent so much money propping it up by paying people to write stuff in it. It has so many major flaws that it would have had no chance of taking off otherwise. If Google had spent the same amount of money on Haskell instead, it'd be even more popular than Go is today.

This a pretty hot take. I'm in the early stages of learning go. So far I like it a lot, but I come from the perspective of a data person who only knows python. I want to learn a compiled language, what would you suggest instead?

Haskell, Idris or Rust! I share the largely negative opinion of Go.

(my background is mostly python, R, javascript, clojure)

Re: Is Haskell really the language of geniuses and academia? (2019)

#73

With Haskell, one always finds articles explaining how great it is, how its features (pure functionality) lend to correct code. But, articles explaining the core use cases and how only this language enabled solving it are rare. I'd love to read someone's decision postmortem that goes something like 'Here is a problem we were looking to solve. And here is how specific features A/B/C of Haskell helped us solve it well.…

> But with Haskell, it seems a reverse process was followed. It starts with some (questionable?) assumptions like lazy evaluation is good and then builds on top of it.

Haskell was created by researches who wanted to study properties of lazy functional programming. I’ve never heard anyone say they did it because lazy evaluation was “good”, it was their area of research. The co-creator has even said that if he had to do it over again it might be better if it were strictly evaluated.

I worked in Haskell for a few years before switching over to a very closely related but strictly evaluated language, PureScript.

The pureness and laziness of Haskell forced the creators to work out monads for IO which I find extremely useful. Haskell-like monads certainly can (and have) been implemented in strictly evaluated languages.

I don’t miss implicit laziness very often, but I’ll say with partially applied functions, it’s nice to know that values will be calculated as needed and results shared across invocations once those functions are fully applied. That’s something I wish we had in PureScript. Note that in addition to laziness this also requires a compiler optimization that moves let bindings out of inner functions, aka let-floating.

Laziness is also nice as it allows you to be very declarative, defining what things are without ever worrying about the calculations running when you don’t need the result. In practice it’s easy enough to create thunks manually and evaluate them when needed. Doing this can get tedious and the resulting code is less succinct.

Re: Is Haskell really the language of geniuses and academia? (2019)

#74
post #63

Earlier quoted context omitted.

How are you using this zipped list later? That could influence the design of the parsing function and the intermediary data structure.

That's the sort of thing I worry about when I'm coding in C. Here, the parsing is done; the intermediate data structure is built in. For now, it's printed to the console and thrown away (becomes garbage), but if anything else is done with it, it will be in that same form.

If you want a language where the compiler does not care about how you use your data (and will not help you avoid silly mistakes) then Haskell is not the language for you.

It's possible to ask the Haskell compiler to not care, but this would be so far from idiomatic Haskell that it wouldn't help you if I wrote that code here, I don't think.

Re: Is Haskell really the language of geniuses and academia? (2019)

#75
post #32

Earlier quoted context omitted.

I've tried to articulate this through pointing out that the documentation culture of Haskell is lacking and indeed I've been called "willingly ignorant, and proud to state that fact publicly" IMO thats really the only remaining problem of Haskell. Most of its documentation is just plain terrible. Rust is probably more difficult to learn as a language, yet the documentation culture is so awesome that one can power thr…

By "documentation", do you mean introductions/tutorials, or references? I'll agree the former could use some work, but I find the latter to be excellent.

I find the reference is not really great. Some of it stems from the fact that function argument names aren't really present in the documentation. Most languages that have excellent documentation will explicitly state what each argument is, something to the point of mind numbing repetitiveness. Often the documentation is written in a way that allows you to start reading anywhere and still understand everything, which is less common with Haskell

Re: Is Haskell really the language of geniuses and academia? (2019)

#76
post #71

Earlier quoted context omitted.

Go is very simple, provides decent static type safety, has a nice concurrency model, and compiles to fast static binaries across all major platforms. People choose it all the time because it’s a great choice. A wild number of popular open source tools are written in go, very few of them created by google. As someone who wrote go for many years I think you’re overstating how limiting it’s “major flaws” are. And fwiw g…

Everything you just said either applies equally to Haskell, or is a cultural factor mostly explained by what the parent comment wrote.

Haskell probably has a much better concurrency model too with STM being quite awesome

Re: Is Haskell really the language of geniuses and academia? (2019)

#78

Earlier quoted context omitted.

> Do either of these problems manifest in Haskell? Haskell code varies a ton. Some people write simple, straightforward stuff in Haskell with lots of pure functions and relatively simple types, straightforward definitions. Some people invent complicated type systems for their app. Some use weird styles, like points free, or continuation passing. Some will rely heavily on abstractions like monads, applicative functors…

Is point free that weird? JS pipes are in the proposition process. Data → Process → Process → Process Is the above unclear?

That’s not really what I’m referring to. There’s actually a tool in Haskell that can rewrite code into a points free style, and it can handle much more complicated cases than just simple composition, it can handle multiple uses of a variable, it can eliminate multiple variables, etc. you can create some real incomprehensible stuff this way.

Edit: Here's a Haskell wiki article:

https://wiki.haskell.org/Pointfree

> Point-free style can (clearly) lead to Obfuscation when used unwisely. As higher-order functions are chained together, it can become harder to mentally infer the types of expressions. The mental cues to an expression's type (explicit function arguments, and the number of arguments) go missing.

> Point-free style often times leads to code which is difficult to modify. A function written in a pointfree style may have to be radically changed to make minor changes in functionality. This is because the function becomes more complicated than a composition of lambdas and other functions, and compositions must be changed to application for a pointful function.

> Perhaps these are why pointfree style is sometimes (often?) referred to as pointless style.

I have observed some relatively extreme examples of pointfree in the wild, and that's what I'm referring to.

Re: Is Haskell really the language of geniuses and academia? (2019)

#79
Until recently, learning Haskell for solving "real-world" problems is not at all easy. But there are now a lot more resources that one can consult.

I think it is highly rewarding to learn to program in Haskell. It offers you another perspective of approaching a computational problem and has a great ecosystem for many applications. And if you ever want to get into theorem-proving with Coq or Agda, knowing Haskell is a huge bonus.

My suggested learning path is as follows: 1. Read Get Programming with Haskell and do the Haskell MOOC at https://haskell.mooc.fi/ at the same time. 2. Read sections in Haskell Programming from First Principles not covered in 1. 3. Read Haskell in Depth.

Many years ago, I tried to learn Haskell from Haskell Programming from First Principles but couldn't get to the point I could write meaningful applications. I gave up after about a year. Early this year, I completed the Haskell MOOC and read most of Haskell in Depth and now I have a much better command of the language. And doing exercises on CodeWars, Hackerrank, and Exercism really help.

I would advise ignoring both the glowing praises and scathing criticisms. Learn it well enough and form your own judgement, assuming of course that you have time to do so.

Re: Is Haskell really the language of geniuses and academia? (2019)

#80
post #74

Earlier quoted context omitted.

That's the sort of thing I worry about when I'm coding in C. Here, the parsing is done; the intermediate data structure is built in. For now, it's printed to the console and thrown away (becomes garbage), but if anything else is done with it, it will be in that same form.

If you want a language where the compiler does not care about how you use your data (and will not help you avoid silly mistakes) then Haskell is not the language for you. It's possible to ask the Haskell compiler to not care, but this would be so far from idiomatic Haskell that it wouldn't help you if I wrote that code here, I don't think.

Is the question not just one of defining the sets of "things" that are being accepted here? It's not that the compiler shouldn't care, but that you have defined an appropriate data structure and set of acceptable types that you would nicely pattern-match on when using them later.

To @kazinator's point, it's not quite going to be just lists of random things, in that Haskell's list elements are all the same type, unlike what Common Lisp lets you do. I'd be more curious whether this could be lists of "Thing", where that Thing type is a typeclass that is inclusive of all the sorts of data you would expect to handle.

Post reply on HN