Live data from Hacker News

Haskell in the Large [pdf]

code.haskell.org

121–130 of 139 posts

Re: Haskell in the Large [pdf]

#121
post #8

Has anyone used both Haskell and OCaml (or F#?)? How do they compare in practice? I've been wanting to put some time into a functional language and I've been debating between Haskell and OCaml. Because of F#, OCaml seems like it might be the more practical language (i.e. direct job opportunities). However, excluding F#, Haskell does seem to much more popular than OCaml.

I have used all three languages professionally—Haskell & some OCaml at Facebook, and some F# at Xamarin—and would recommend learning Haskell.

There’s a strong community around Haskell, with a decent library ecosystem and high-quality implementations, and learning it will make it easy to pick up F# or OCaml—the reverse is not necessarily true.

F# is a decent choice if you want to write functional code in .NET land, but Visual Studio and MonoDevelop support for F# aren’t as good as for C#.

OCaml is a good language, but I would recommend against it. Like F#, it has some syntactic and semantic conveniences that Haskell lacks. However, the community is small, there are relatively few libraries, and the runtime falls down when you need to do anything with large arrays or floating-point math.

Re: Haskell in the Large [pdf]

#122
post #8

Has anyone used both Haskell and OCaml (or F#?)? How do they compare in practice? I've been wanting to put some time into a functional language and I've been debating between Haskell and OCaml. Because of F#, OCaml seems like it might be the more practical language (i.e. direct job opportunities). However, excluding F#, Haskell does seem to much more popular than OCaml.

I have used all three languages professionally—Haskell & some OCaml at Facebook, and some F# at Xamarin—and would recommend learning Haskell. There’s a strong community around Haskell, with a decent library ecosystem and high-quality implementations, and learning it will make it easy to pick up F# or OCaml—the reverse is not necessarily true. F# is a decent choice if you want to write functional code in .NET land, bu…

> OCaml is a good language, but I would recommend against it. Like F#, it has some syntactic and semantic conveniences that Haskell lacks.

I haven't had a chance to use OCaml or F# yet, what syntactic and semantic conveniences are you talking about?

Re: Haskell in the Large [pdf]

#123
post #49

“Make illegal states unrepresentable” Types pay off the most on large systems. Architectural requirements captured formally. This more than ANYTHING else is why I want to move enterprisey app code to Haskell. Having worked on numerous ginormous enterprisey systems -- which are usually doing pretty straightforward things, just at scale, and needing to be maintained by non-brilliant developers -- I can say pretty secur…

Another thing is contract programming, but it is really hard to sell to managers where shipping cheap outweights quality. I don't envision FP or contract based programming in enterprise offshore code.

Imagine a super-charged version of the method where Java Architects make class hierarchies and interfaces for offshore/contract programmers.

I think FP (and contract based programming) would do a much better job than Java for varying qualities of programmers on very large projects.

Re: Haskell in the Large [pdf]

#124
post #102

Earlier quoted context omitted.

Two asides, which I don't think you missed but I just wanted to expand on... First, "Turing complete" means that you can compute anything anyone else can compute. It doesn't necessarily mean you can do it with a reasonable encoding, or do with it what you need to do with it. At the boundary between systems, encoding matters quite a lot! Second, it's certainly true that there are constraints you can express in Haskell…

I bring up the lack of turing completeness because in the space of type languages you can make even more powerful arguments. What you mention about reasonable encodings is sufficient, but we can get more strength. And, yeah... even a type system as primitive as C can catch interesting invariants. This is an important counterpoint to the general idea that "types never say anything interesting".

"I bring up the lack of turing completeness because in the space of type languages you can make even more powerful arguments. What you mention about reasonable encodings is sufficient, but we can get more strength."

Certainly. I had every confidence you understood that. I just wanted to be sure we avoided strengthening the "Turing complete means it can do anything any other language can" misconception.

Re: Haskell in the Large [pdf]

#125
post #105
post #87

Earlier quoted context omitted.

Your version, while not very different, is not easier to read than that of the parent post. A few weeks into learning Haskell, reading x:xs will become second nature, so much so that "head" and "tail" become noise. (Also, "head" and "tail" are function names in the Prelude, but I'll assume you meant to write "hd" and "tl" or something like that).

(Also, "head" and "tail" are function names in the Prelude, but I'll assume you meant to write "hd" and "tl" or something like that). No, I overlooked that. Writing "hd" and "tl" would be opposite to my point! I think that "head:tail" is much more readable and much more informative than "x:xs".

Shadowing built-in names comes with it's own set of problems. (At least that's the opinion of the compiler writers that enable warnings about shadows by default.)

Re: Haskell in the Large [pdf]

#126
post #36

Earlier quoted context omitted.

> I would also like to know how many of the core team members have PhDs and MScs. Don't forget the MDs! (Not joking, one of the people Don's team has an MD.) I used to work for Don at Standard Chartered. Getting good Haskellers seemed way easier than the hiring efforts of my current employer (Google) focussing on more traditional languages. But I guess, that's mostly a function of pent up demand for Haskell jobs.

Where is all this pent up demand? I mean I get what you're saying. Most academics know Haskell and Standard Chartered hires academics but there is a bit of circular thing going on there.

Oh, there are quite a lot of programmers working with more conventional languages in their day job, but are using Haskell as a hobby. They are easy to hire with the lure of Haskell.

Since moving away from Standard Chartered I have turned into one of them.

Re: Haskell in the Large [pdf]

#127
post #95
post #40

Earlier quoted context omitted.

I'm curious, what do you mean they compose better and allow for analysis [better than monads]?

gergoerdi covered analysis, but composition is simple. For any two Applicatives F and G and value type A the following 4 values are all Applicative values F A G A F (G A) G (F A) But for monads only the first two are monads for general monads F and G. So, Applicatives compose better!

And to get F (G A) with Monads, F needs to be a Monad transformer.

In addition to composition, products of Applicatives are also Applicatives:

(F A, G A)

Re: Haskell in the Large [pdf]

#128
post #127
post #95

Earlier quoted context omitted.

gergoerdi covered analysis, but composition is simple. For any two Applicatives F and G and value type A the following 4 values are all Applicative values F A G A F (G A) G (F A) But for monads only the first two are monads for general monads F and G. So, Applicatives compose better!

And to get F (G A) with Monads, F needs to be a Monad transformer. In addition to composition, products of Applicatives are also Applicatives: (F A, G A)

Even for monad transformers it's not necessarily the case that direct composition leads to a monad. For instance, ContT looks like

    newtype ContT r m a = ContT ((a -> m r) -> m r)
so ContT M A is not the same as Cont (M A).

Monads also compose under products as two parallel monadic computations

    data (f * g) a = Pair (f a) (g a)

    p1 :: (f * g) a -> f a
    p1 (Pair fa _) = fa

    p2 :: (f * g) a -> g a
    p2 (Pair _ ga) = ga

    instance (Monad f, Monad g) => Monad (f * g) where
      return a = Pair (return a) (return a)
      Pair fa ga >>= k = Pair (fa >>= p1 . k) (ga >>= p2 . k)
You can also talk about composition under sums

    data (f + g) a = Inl (f a) | Inr (g a)
and you'll get compositions of applicatives here so long as you have a notion of natural transformation

    class Natural f g where
      phi :: f a -> g a

    instance (Applicative f, Applicative g, Natural f g) => Applicative (f + g) where
      pure a = Inl (pure a)
      Inl ff  Inl fa = Inl (    ff      fa)
      Inr gf  Inr ga = Inr (    gf      ga)
      Inl ff  Inr ga = Inr (phi ff      ga)
      Inr gf  Inl fa = Inr (    gf  phi fa)
but there's no way to get a similar monad. It turns out that you have to "know what branch to go down before you start" in exactly the kind of way applicatives allow and monad preclude.

Re: Haskell in the Large [pdf]

#129
post #102

Earlier quoted context omitted.

I bring up the lack of turing completeness because in the space of type languages you can make even more powerful arguments. What you mention about reasonable encodings is sufficient, but we can get more strength. And, yeah... even a type system as primitive as C can catch interesting invariants. This is an important counterpoint to the general idea that "types never say anything interesting".

"I bring up the lack of turing completeness because in the space of type languages you can make even more powerful arguments. What you mention about reasonable encodings is sufficient, but we can get more strength." Certainly. I had every confidence you understood that. I just wanted to be sure we avoided strengthening the "Turing complete means it can do anything any other language can" misconception.

Ah ah, fair---certainly never worth reinforcing the turing tar pit argument!

Re: Haskell in the Large [pdf]

#130
post #117
post #111

Earlier quoted context omitted.

The entire Java community pines for lisp, whether they know it or not. That's why Apache Ant was invented, it's Java's manifestation of Greenspun's Tenth Rule.

Is it confined to the Java community? Seems a bit more widespread, honestly.

Well yeah, that's why the original Greenspun's tenth rule cited "Any sufficiently complicated C or Fortran program..."

Those who do not learn from history are doomed to repeat it. That is the only logical explanation for why XML even exists.

Post reply on HN