Live data from Hacker News

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

habr.com

61–70 of 83 posts

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

#61
How do you do this in Haskell: read a variable number of lists from standard input, until the nil symbol is seen. The lists are heterogeneous: they can contain any mixture of numbers, symbols, strings or any other objects. Then zip them together (truncating them to the length of the shortest one).

TXR Lisp:

  1> [apply zip (gun (read))]
  (1 2 3)
  (a b c)
  ("foo" 3 :bar)
  nil
  [Ctrl-D][Enter]
  ((1 a "foo") (2 b 3) (3 c :bar))
CL:

  [2]> (apply #'mapcar #'list (loop for x = (read) while x collect x))
  (1 2 3)
  (a b c)
  ("foo" 3 :bar)
  nil
  ((1 A "foo") (2 B 3) (3 C :BAR))

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

#62
post #46
post #40

Earlier quoted context omitted.

I don't think that's correct. Especially since there's a community-led organization with the specific goal of increasing adoption https://haskell.foundation/

I think there are many different people with different opinions in the community. The inofficial motto of 'avoid "success at all costs"' is not a joke. It's easy-ish to achieve success if you allow yourself to pander to the masses who don't always understand what they are missing, and there's always been an element in the Haskell community that tries to do what's right, notwithstanding what the large masses think.

'Tried to it right notwithstanding what masses think' and commercial success are not exclusive. Two examples. Clojure's maintainers very carefully vet what goes into the core language. It has been a source of frustration for some contributors too. But the net result has been more positive than negative and the language has been successful (relative comparison with Haskell). Second example is Lua. There was a comment by its creator (I'm paraphrasing from memory) 'Lua grows by answering why, not by answering why not'. But it still has found (again, relatively more) success, despite being conservative about language feature-set.

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

#63

How do you do this in Haskell: read a variable number of lists from standard input, until the nil symbol is seen. The lists are heterogeneous: they can contain any mixture of numbers, symbols, strings or any other objects. Then zip them together (truncating them to the length of the shortest one). TXR Lisp: 1> [apply zip (gun (read))] (1 2 3) (a b c) ("foo" 3 :bar) nil [Ctrl-D][Enter] ((1 a "foo") (2 b 3) (3 c :bar))…

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

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

#64

Earlier quoted context omitted.

Seems like a lot of people disagreed, because Go is definitely a “successful” language. Kind of getting sick of hearing these same complaints, over and over, to be honest.

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 go ranks much higher than haskell on stack overflow’s annual developer survey.

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

#65

Earlier quoted context omitted.

Seems like a lot of people disagreed, because Go is definitely a “successful” language. Kind of getting sick of hearing these same complaints, over and over, to be honest.

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?

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

#66
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?

Rust.

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

#67

Earlier quoted context omitted.

Seems like a lot of people disagreed, because Go is definitely a “successful” language. Kind of getting sick of hearing these same complaints, over and over, to be honest.

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.

I'm kind of with you about Google being heavily responsible to the level of which Go became an success, but that has been the case (backed by large companies) for many popular programming languages such as C, C++, Java, Rust, etc... It helps, but not every corporate backed language is successful or makes it to the top 20.

I don't completely buy the argument that a Google backed Haskell would have been as popular as Go. Readability (which is subjective), familiarity (often C is the reference), and the ease of which the language can be learned are still major factors in widespread acceptance.

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

#68
post #40
post #17

Earlier quoted context omitted.

I suspect that the community is overall quite happy with increased adoption being a non-goal. That is, it does not need to shift to an engineering-mindset because it does not value the consequences of that shift.

I don't think that's correct. Especially since there's a community-led organization with the specific goal of increasing adoption https://haskell.foundation/

That's fair: calling it a "non-goal" is an overstatement.

How about: the least-valued of all goals?

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

#69
post #50

Earlier quoted context omitted.

I believe clojure has laziness out of the box as well. While both languages are functional, in contrast to Haskell, clojure doesn't have functors or monads. My understanding is that the same problem is essentially solved in a different way with macros.

According to https://clojure-doc.org/articles/language/laziness/ , Clojure isn't lazy by default, but does support lazy sequences (like IEnumerable in C#).

I stand corrected, then! Thank you.

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

#70
post #63

How do you do this in Haskell: read a variable number of lists from standard input, until the nil symbol is seen. The lists are heterogeneous: they can contain any mixture of numbers, symbols, strings or any other objects. Then zip them together (truncating them to the length of the shortest one). TXR Lisp: 1> [apply zip (gun (read))] (1 2 3) (a b c) ("foo" 3 :bar) nil [Ctrl-D][Enter] ((1 a "foo") (2 b 3) (3 c :bar))…

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.

Post reply on HN