Haskell for a New Decade [pdf] • Hacker News Board

Re: Haskell for a New Decade [pdf]

#61

Post by smabie » Wed, Jun 24, 2020, 2:09 AM UTC

bcatanzaro wrote: post #22

nightski wrote: post #19

Earlier quoted context omitted.

I can't speak for everyone but for me the type system is not what made Haskell difficult. I loved it. What made it difficult was laziness. I'd find myself always trying to reason about execution (even though most of the time you probably shouldn't). Laziness might even be fine in a world built around it, but for a language to be practical it has to interface with systems that are not designed that way (numerous exter…

I felt that way too. I remember the first time I tried to make a lazy list of random numbers in Haskell. It didn't work because of course the random number generator is stateful which conflicts with laziness. It was a disappointing moment for sure.

There's no reason that you can't do this. Of course, you're not going to be able to just simply return a list of random numbers. But you can get a Rand [Int] or whatever and then evaluate it in an IO monad using evalRandIO.

Re: Haskell for a New Decade [pdf]

#62

Post by nh2 » Wed, Jun 24, 2020, 2:13 AM UTC

JoelMcCracken wrote: post #50

pydry wrote: post #42

Earlier quoted context omitted.

I've always been somewhat skeptical of Haskell due to the scarcity of things you could point to and say "that was made with Haskell and it made it so much better". it's usually the same 3 pieces of software people point to, none of which are particularly noteworthy. with rust, by contrast, which is ostensibly much less general purpose and hasn't been around as long there's already quite a collection and it's easy to…

Haskell does have an issue of people using it being more interested in doing clever things and researching topics than building cool applications. Haskell jobs do exist, I have one of them. The big problem is that there are more people who want to do those jobs than there are jobs, so they seem very scarce. But anyway there are also a number of investment banks I have heard that use Haskell as their “secret weapon” a…

> “secret weapon” and do not advertise it

Both Standard Chartered and Barclays loudly advertise that they use Haskell.

A quick web search turns up their job offers on Reddit, and both also send people to conferences such as Haskell eXchange, to talk about their team tasks, structure, and size. Example: [1]

Their code bases were discussed on HN before, e.g. [2].

Standard Chartered also funded the development of GHCs low-latency, non-stop-the-world, incremental GC, for 2 years until it was recently released [3].

[1] https://skillsmatter.com/skillscasts/9098-haskell-in-the-lar...

[2] https://news.ycombinator.com/item?id=13073605

[3] https://www.well-typed.com/blog/2019/10/nonmoving-gc-merge/

Re: Haskell for a New Decade [pdf]

#63

Post by cpeterso » Wed, Jun 24, 2020, 2:22 AM UTC

nh2 wrote: post #37

quickthrower2 wrote: post #9

I think the focus on Haskell is missing the mark a bit. Haskell is about programming language researchers and enthusiasts having a excellent example language to try out ideas. Over the years it has turned into a production ready platform. As the PDF shows there are many languages spun off Haskell and it doesn't even mention them all. Then there are language features in C# and Java, Typescript etc. that are coming acr…

Counter point on "investment": I was in a Haskell team at Google, and have trained groups at various companies professionally. From that experience, for a normal developer with working experience in Java, Python, or C++: * It takes 2-3 weeks of full-time onboarding (half with a coach, half self-study) to work on a typical industrial Haskell project. * It takes around 3 months of full-time participation in such a proj…

Can you share what kind of system your Haskell team worked on at Google? I thought Google projects were limited to a few blessed languages. Once upon a time that was Java, C++, and Python but I guess that would now include Go and Rust (in parts of Fuchsia and possibly Chrome).

Re: Haskell for a New Decade [pdf]

#64

Post by sizeofchar » Wed, Jun 24, 2020, 2:23 AM UTC

nh2 wrote: post #60

co_dh wrote: post #52

Earlier quoted context omitted.

It was google, a bad sample of programmers.

It's odd how the various smaller companies I referred to, many of which are normal enough that you may never have heard of them, get summarised as "It was Google". I only mentioned it to also include the largest org I know where onboarding onto a Haskell project was not a problem.

I think he meant "bad sample" in the sense that those programmers aren't representative of abilities of average programmers. Ie, he thinks Google programmers are top programmers.

Re: Haskell for a New Decade [pdf]

#65

Post by dllthomas » Wed, Jun 24, 2020, 2:25 AM UTC

smegma2 wrote: post #30

bcatanzaro wrote: post #22

Earlier quoted context omitted.

I felt that way too. I remember the first time I tried to make a lazy list of random numbers in Haskell. It didn't work because of course the random number generator is stateful which conflicts with laziness. It was a disappointing moment for sure.

What was the problem exactly? I don't see any issues with generating e.g. an infinite list of random numbers in Haskell.

On the one hand, of course you can. But I do understand how it might seem tricky if you're too focused on trying to glue together `Gen a`s (or even `MonadRandom m => m a`s), principally with Monad.

To the grandparent, assuming the trouble was as I understand it, the idea is to split your state and advance one new state down the lazy list while the rest of the computation uses the other new state.

Eliding constraints for brevity, if you have:

    split :: g -> (g, g)
    random :: g -> (a, g)

then you can say

    lazyRandomList :: g -> ([a], g)
    lazyRandomList oldState =
        let (listState, newState) = split oldState
         in (makeList listState, newState)
      where
        makeList inState =
            let (value, nextState) = random inState
             in value : makeList nextState

When you match on the outer tuple, the split gets forced, but `makeList listState` is still a thunk. You can go ahead and use `newState` all you want without forcing it.

Once you force it, you have a cons, with two thunks that can be forced independently. The tail evaluates to a similar cons produced from a different state. A lazy list.

It's true that it's infinite, but you can fix that (if you want to) by taking the head (perhaps a random number of elements); it's easier to control the distribution of length that way than with some fixed chance you produce nil at each step, although that approach works too.

Re: Haskell for a New Decade [pdf]

#66

Post by logicchains » Wed, Jun 24, 2020, 2:29 AM UTC

Twisol wrote: post #33

zerr wrote: post #12

Earlier quoted context omitted.

From the pure language perspective (i.e. batteries aside), what do you miss in Rust from Haskell?

Everyone else pretty much said it for me. To elaborate more personally: the distilled expression of pure functions as _the_ basic entity of modular engineering is such a huge selling point for me. Lazy evaluation is also surprisingly valuable in this vein, because I can compose components -- pass the output of a component to the input of another -- with the assurance that I'll only pay for that computation if it's ac…

>Very few languages, even in the functional world, have such a strict separation.

It's catching on. Nim has the noSideEffect pragma (enabled by default if a function is defined with "func" rather than "proc"), and D has a "pure" annotation. Both are compiler-checked.

Re: Haskell for a New Decade [pdf]

#67

Post by lmm » Wed, Jun 24, 2020, 2:30 AM UTC

quickthrower2 wrote: post #9

I think the focus on Haskell is missing the mark a bit. Haskell is about programming language researchers and enthusiasts having a excellent example language to try out ideas. Over the years it has turned into a production ready platform. As the PDF shows there are many languages spun off Haskell and it doesn't even mention them all. Then there are language features in C# and Java, Typescript etc. that are coming acr…

> A lot of stuff to get your head around. There are complex topics from category theory to metaprograming. Sure you can ignore it - until you want to use a web framework that uses those concepts, then it's on you.

I'm convinced this is just FUD. Every language's main web framework has a bunch of complex concepts to learn - if you want to use Rails you're going to have to learn about ActiveRecord, metaclasses, whatever it is that rails uses for routing. By the time you've got productive in an enterprise-scale codebase, you've learnt just as much as if you were using Haskell - the only difference is that the knowledge is less transferable.

Re: Haskell for a New Decade [pdf]

#68

Post by JoelMcCracken » Wed, Jun 24, 2020, 2:33 AM UTC

nh2 wrote: post #62

JoelMcCracken wrote: post #50

Earlier quoted context omitted.

Haskell does have an issue of people using it being more interested in doing clever things and researching topics than building cool applications. Haskell jobs do exist, I have one of them. The big problem is that there are more people who want to do those jobs than there are jobs, so they seem very scarce. But anyway there are also a number of investment banks I have heard that use Haskell as their “secret weapon” a…

> “secret weapon” and do not advertise it Both Standard Chartered and Barclays loudly advertise that they use Haskell. A quick web search turns up their job offers on Reddit, and both also send people to conferences such as Haskell eXchange, to talk about their team tasks, structure, and size. Example: [1] Their code bases were discussed on HN before, e.g. [2]. Standard Chartered also funded the development of GHCs l…

There are numerous others who do not, though.

Re: Haskell for a New Decade [pdf]

#69

Post by logicchains » Wed, Jun 24, 2020, 2:36 AM UTC

nextos wrote: post #10

Very informative slides. I do not have real-world experience with Haskell, aside from little toy projects, but I have a lot of experience with other functional languages in the ML family and Scheme. Idris 2 looks appealing, but they should have also mentioned other approaches like Fstar, Lean and Z3. I quite like Fstar since they are delivering a big verified code base, as implied by the name of the effort: Project E…

>A toolkit where you can create DSLs with limited expressiveness, which in turn make it easy to build and verify things.

This is a common approach in the Coq ecosystem, writing DSls for building things, and custom automation for them. See for instance papers by Adam Chlipala.

Re: Haskell for a New Decade [pdf]

#70

Post by nybble41 » Wed, Jun 24, 2020, 3:12 AM UTC

bcatanzaro wrote: post #22

nightski wrote: post #19

Earlier quoted context omitted.

I can't speak for everyone but for me the type system is not what made Haskell difficult. I loved it. What made it difficult was laziness. I'd find myself always trying to reason about execution (even though most of the time you probably shouldn't). Laziness might even be fine in a world built around it, but for a language to be practical it has to interface with systems that are not designed that way (numerous exter…

I felt that way too. I remember the first time I tried to make a lazy list of random numbers in Haskell. It didn't work because of course the random number generator is stateful which conflicts with laziness. It was a disappointing moment for sure.

> the random number generator is stateful which conflicts with laziness

It's not difficult to create a stateful computation in a non-strict runtime environment. Laziness is compatible with (local) state. Haskell's random package is designed around explicitly threading the PRNG state through the computation:

    import System.Random (Random, RandomGen, random)
    import Data.List (unfoldr)

    randomList ∷ (Random a, RandomGen g) ⇒ g → [a]
    randomList = unfoldr (Just ∘ random)

Since the function passed to `unfoldr` always returns a `Just` value, the resulting lazy list never ends. If you're not familiar with `unfoldr`, it's essentially the opposite of `foldr`: instead of applying a reduction function to a list it produces a list by iteratively applying a generator function to a seed—in this case the PRNG state.

As it happens, this function already exists as `System.Random.randoms`. You use it like this:

    main = do
      (xs :: [Int]) ← randoms  newStdGen
      mapM_ print xs

There are related functions `randomR` and `randomRs` which take a lower and upper bound in addition to the state.

If you were trying to achieve this effect with `randomIO` or `randomRIO`—perhaps to avoid explicitly threading the state—then you will run into difficulties. Not because of laziness; rather the contrary. The problem is that IO actions are strict by default, so you can't easily combine them to create a lazy list. You would need to use something like `System.IO.Unsafe.unsafeInterleaveIO` to defer the generation of the random values until they were actually demanded, but then you're mutating the shared, global PRNG state each time an item is evaluated from the list and the result would not be deterministic or repeatable even if you started with a known seed.