[HN Gopher] Software Development Languages: Haskell
___________________________________________________________________
Software Development Languages: Haskell
Author : colingw
Score : 27 points
Date : 2022-01-31 19:28 UTC (3 hours ago)
(HTM) web link (www.fosskers.ca)
(TXT) w3m dump (www.fosskers.ca)
| daenz wrote:
| I learned Haskell a few years ago, enough to read it, but not
| fluent enough to comfortably write it. Haskell scratches a real
| intellectual itch, related to how it formally captures certain
| concepts (types, purity, etc). But my opinion is that Haskell
| collapses under the weight of its terseness and academic
| complexity. Can it be extremely elegant? Yes, in contrived
| examples[0]. Is it able to maintain this elegance when dealing
| with common problems? No.
|
| 0. https://wiki.haskell.org/Introduction#Quicksort_in_Haskell
| laurensr wrote:
| Trivia: the recently posted PostgREST project was written in
| Haskell.
| lambdasquirrel wrote:
| It might be worth giving a pointer on setting up your own
| stackage server. Otherwise, Haskell projects can become an ugly
| monolith sooner in a company's lifetime than one might expect. It
| can then become a double-edged sword that you're quite productive
| in the language.
|
| The CI for a medium-sized Haskell-using company should have
| multiple instances of:
|
| Project repo -> CI compilation -> tests -> publish library to
| company's internal stackage.
|
| That way, when someone inevitably publishes something that breaks
| things, the other teams will have an _easy_ mitigation / known-
| good-version to fall back on.
|
| In other codebases (especially if they use the typical popular
| dynamic languages), you might start breaking things up into
| microservices sooner than you would with Haskell. But given that
| Haskell runs much, much faster than those other languages, and
| isn't quite the memory hog that the JVM is (when we're comparing
| to Scala), you might find that it'd help you scale if you broke
| up the codebase into libraries, rather than breaking it up into
| microservices. This is especially the case if your company /
| project is bottlenecked on ops (which many companies are, not
| just ones using Haskell). Multiple libraries is much easier to
| manage than microservices and forestalls the point at which
| you'll need serious dedicated ops.
| dwohnitmok wrote:
| > Haskell is in the best-of-class category when it comes to
| documentation. Haskell's type system quickly earns your trust,
| and once it does, you almost never need to read someone else's
| code in order to understand it; you can just read the type
| signatures shown in the docs and get on with your life.
|
| I don't think this is an accurate representation of how the
| Haskell community itself views the state of Haskell
| documentation. A large section of the community views the state
| of documentation as _very not_ best-of-class and strongly
| advocates for improving it (and views type signatures as a poor
| replacement for at least examples). See e.g.
| https://www.reddit.com/r/haskell/comments/2ory86/there_is_a_...
|
| Likewise "Otherwise, toss a coin!" as a response to Cabal or
| Stack makes me sad. Tooling can often depend on exclusively
| either one or the other (see e.g.
| https://plugins.jetbrains.com/plugin/8258-intellij-haskell) and
| the fact that from a capability point of view, they're converging
| on the same thing makes it an unnecessary point of friction for
| new users, although I understand the reasons for why they both
| came to be.
|
| EDIT: I should detach myself from the usual curmudgeonly HN
| comment to say that the organization of the article is very well
| done. I would like to see how non-Haskellers approach it because
| I think stuff like "What language idioms are available?" is a
| good way to approach a new language.
|
| EDIT 2: The original Reddit link was far older than I thought it
| would be. Here's a more extreme (more than I personally agree
| with) take on the situation, but is a lot more recent:
| https://old.reddit.com/r/haskell/comments/or93z3/what_is_you...
| dmitriid wrote:
| > I don't think this is an accurate representation of how the
| Haskell community itself views the state of Haskell
| documentation. A large section of the community views the state
| of documentation as very not best-of-class and strongly
| advocates for improving it
|
| Almost every time (though it's quite rarely) that I end up on a
| Haskell documentaiton page, I facepalm and move on. Yes,
| there's a dump of inpenetrable types. But... how do I actually
| use those types? :)
| ggm wrote:
| I think this is a very insightful comment. If the documents
| showed:
|
| 1) a simple instance of use of the language feature
|
| 2) a few typical instances of use
|
| and
|
| 3) did NOT use towers-of-hanoi, prime-sieve, mathematical
| smartness, pointless tricks unrelated to the core
| functionality, dubious features under dispute..
|
| The best UNIX man pages for systems commands do exactly this.
| They show all the commandline options in the sort-of BNF,
| they list the meaning/intent of the options (hopefully
| alphabetically) and under EXAMPLES they show you the 3
| cruicial commands you really came looking for, exactly as the
| worked when the manual page was written.
|
| I know I used man -s 1 or -s 8 to exemplify how to do man -s
| 2 and man -s 3 pages, but the point is they obey some simple
| (BNF) norms, some simple (nroff -man) format and EXAMPLES
| exemplify real-world use. Not "I am smart, watch me put a
| fruitloop in my nose" but real world, applicable instances.
| T-R wrote:
| I think, coming from other languages, it takes a while to
| really absorb how much you can rely on types to tell you what a
| function is doing - to the degree that for some functions you
| can infer the implementation from them[1].
|
| That said, Haskell documentation tends to be really lacking on
| some of the basics that other ecosystems get right, like where
| to start, shielding beginners from functions for more niche
| usecases, examples of how to build or deconstruct values, or
| end-to-end case studies. Some of the nicest things to _use_
| have an API that primarily comes from typeclasses in base, and
| don't provide any documentation beyond a list of typeclasses.
| My impression has been that most Haskellers seem to be on the
| same page that those things need work, though - I'm optimistic
| about the situation improving, but it's still hard to recommend
| to anyone expecting the experience of working with popular
| libraries from more mainstream ecosystems.
|
| [1] https://bartoszmilewski.com/2014/09/22/parametricity-
| money-f...
| Zababa wrote:
| Cabal and stack are also very hard to understand when starting
| out.
| Barrin92 wrote:
| From a practical software development POV I think the biggest
| problem with Haskell is the laziness by default. It's the central
| theoretical motivation for the language but when it comes to real
| work there are so many ways it can bite you, which is ironic
| given how much Haskell prioritizes safety in almost every other
| aspect of the language.
|
| To me it's always been hard to reconcile that you have to deal
| with so many restrictions in the language that save you from
| ending up in some ill-behaving program state, yet a wrong fold
| can basically blow your entire program up.
| colingw wrote:
| This is Part 3 of an on-going series about the usage of various
| languages for real-world software development.
___________________________________________________________________
(page generated 2022-01-31 23:01 UTC)