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…
Is Haskell really the language of geniuses and academia? (2019)
71–80 of 83 posts
Re: Is Haskell really the language of geniuses and academia? (2019)
#72Earlier 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?
(my background is mostly python, R, javascript, clojure)
Re: Is Haskell really the language of geniuses and academia? (2019)
#73With 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.…
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)
#74Earlier 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.
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)
#75Earlier 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.
Re: Is Haskell really the language of geniuses and academia? (2019)
#76Earlier 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.
Re: Is Haskell really the language of geniuses and academia? (2019)
#77Re: Is Haskell really the language of geniuses and academia? (2019)
#78Earlier 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?
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)
#79I 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)
#80Earlier 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.
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.