Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Haskell in the Large [pdf]

code.haskell.org

Post reply on HN
Print view View original

51–60 of 139 posts

Re: Haskell in the Large [pdf]

#51

Post by tome »

tel wrote: post #29
rtpg wrote: post #28

Earlier quoted context omitted.

It's so weird to me that in a world of more asynchronicity than ever we want to bring Haskell to strict-land. On the opposite end, there is so much boilerplate optimisation out there to get around the strictness of other programming languages that would be solved with a non-strict mode

Strictness can always embed laziness---this is sometimes an argument for the natural superiority of strictness---so long as you have lightweight lambdas. Thus, in OCaml you'll see a lot of thunk () = long_computation effectively. Is that syntactic noise enough to disable the advantages of laziness? Actually, maybe!

> Strictness can always embed laziness

And vice versa, although I think embedding strictness in laziness is probably more syntactically heavyweight.

http://h2.jaguarpaw.co.uk/posts/strictness-in-types/

> Is that syntactic noise enough to disable the advantages of laziness? Actually, maybe!

Hmm, if that's the case then it seems that

    thunk = return long_computation
is enough to disable the advantages of monads! :)

Re: Haskell in the Large [pdf]

#52

Post by pjmlp »

dkarapetyan wrote: post #17

I see. So all you need are compiler/interpreter experts that can turn any problem into a interpreter/compiler problem and you're golden. I'm not saying the approach is not worthwhile but how exactly does this generalize to other workplaces where there is no critical mass of such experts? I mean they have their own compiler for Haskell for Pete's sake. I would also like to know how many of the core team members have P…

> So all you need are compiler/interpreter experts that can turn any problem into a interpreter/compiler problem and you're golden.

Any text processing, symbolic data structure manipulation can be reduced to a compiler phase, it is just apparently many CS degrees don't teach it properly.

> Alternatively, Facebook has been experimenting with Haskell and OCaml. Seeing their case studies would be valuable as well.

Microsoft Research also does lot of FP related work.

Re: Haskell in the Large [pdf]

#53

Post by dkarapetyan »

tel wrote: post #23
dkarapetyan wrote: post #17

I see. So all you need are compiler/interpreter experts that can turn any problem into a interpreter/compiler problem and you're golden. I'm not saying the approach is not worthwhile but how exactly does this generalize to other workplaces where there is no critical mass of such experts? I mean they have their own compiler for Haskell for Pete's sake. I would also like to know how many of the core team members have P…

I think "interpreter/compiler" problems arise way more frequently than people expect. It's just they're often not called that until they're being tackled by interpreter/compiler experts. In particular, you can think of things like message passing, interpreter/command patterns, and anything which uses reflection as being at least a little like an AST/interpreter pattern if you look at it in the right light. Then, if y…

I completely agree. When viewed from the right angle almost everything is a combination of some "VM bytecode" and a "compiler" targeting that bytecode. Greenspun's tenth rule applies to anything large enough. That's not what I'm getting at.

What I'm getting at is that when you have a bunch of problem solvers well versed in programming language design and theory the programming language at that point is no longer relevant. Standard Chartered doesn't have all that software because Haskell somehow gave them superpowers. Standard Chartered has all that software because a bunch of PhDs chose Haskell to write it in and along the way Lennart wrote another compiler because why not, the man is good at it. So instead of being a case study in how to apply a functional language to solve problems this is really a presentation about what kind of people you want to hire to build systems, i.e. PhDs, MScs, and MDs (apparently).

Imagine if the title of this post was "PHP in the large". Would anyone take it seriously? Does anyone really believe PHP is a great language to build large systems in? No, everyone would immediately jump on the fact that all of it is running on HHVM and there are bunch of smart folks optimizing the hell out of it. Same here.

The metapoint here is really a quote by Rich Hickey from a David Nolen talk/blog post - "Not everything is awesome". There are few hidden gems in the presentation when concessions are made by including Any type and re-inventing a lot of Erlang style process management. I wonder why more trading companies don't leverage Erlang and Dialyzer?

The relevant post for the quote: http://swannodette.github.io/2015/01/09/life-with-dynamic-ty....

Re: Haskell in the Large [pdf]

#54

Post by dkarapetyan »

pjmlp wrote: post #52
dkarapetyan wrote: post #17

I see. So all you need are compiler/interpreter experts that can turn any problem into a interpreter/compiler problem and you're golden. I'm not saying the approach is not worthwhile but how exactly does this generalize to other workplaces where there is no critical mass of such experts? I mean they have their own compiler for Haskell for Pete's sake. I would also like to know how many of the core team members have P…

> So all you need are compiler/interpreter experts that can turn any problem into a interpreter/compiler problem and you're golden. Any text processing, symbolic data structure manipulation can be reduced to a compiler phase, it is just apparently many CS degrees don't teach it properly. > Alternatively, Facebook has been experimenting with Haskell and OCaml. Seeing their case studies would be valuable as well. Micro…

Microsoft as well. I don't know what kind of production systems are built with F# but maybe there are a few.

Re: Haskell in the Large [pdf]

#55

Post by eru »

mercurial wrote: post #43
eru wrote: post #37

Earlier quoted context omitted.

I used both Haskell and OCaml professionally. OCaml's strictness makes some things easier to reason about. Haskell is a nicer language and has more momentum.

OCaml has, IMHO, strong syntactic advantages over Haskell which have a major impact on readability: - the way you access records (which also means it's not going to clutter your namespace) - named arguments - default values - not an OCaml-the-language property, but there is much less of a race in the OCaml ecosystem to write the shortest variable name possible and accumulate the most ASCII operators Also, the great m…

The modules are great in OCaml.

The short variable names in Haskell follow the convention that the more polymorphic your variable is, the shorter its name should be. Eg in

map f (x:xs) = f x : xs; map _ [] = []

f, x and xs are very polymorphic, so there's really no better longer name there.

Re: Haskell in the Large [pdf]

#56

Post by dkarapetyan »

eru wrote: post #36
dkarapetyan wrote: post #17

I see. So all you need are compiler/interpreter experts that can turn any problem into a interpreter/compiler problem and you're golden. I'm not saying the approach is not worthwhile but how exactly does this generalize to other workplaces where there is no critical mass of such experts? I mean they have their own compiler for Haskell for Pete's sake. I would also like to know how many of the core team members have P…

> 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.

Re: Haskell in the Large [pdf]

#57

Post by mercurial »

eru wrote: post #55
mercurial wrote: post #43

Earlier quoted context omitted.

OCaml has, IMHO, strong syntactic advantages over Haskell which have a major impact on readability: - the way you access records (which also means it's not going to clutter your namespace) - named arguments - default values - not an OCaml-the-language property, but there is much less of a race in the OCaml ecosystem to write the shortest variable name possible and accumulate the most ASCII operators Also, the great m…

The modules are great in OCaml. The short variable names in Haskell follow the convention that the more polymorphic your variable is, the shorter its name should be. Eg in map f (x:xs) = f x : xs; map _ [] = [] f, x and xs are very polymorphic, so there's really no better longer name there.

First, people are not shy about using short names in general, however polymorphic the variable is.

And you could easily write:

    map func (item:items)

Re: Haskell in the Large [pdf]

#58

Post by marmaduke »

spopejoy wrote: post #11

“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…

invariants could be lifted into the type system

Is there a reason this is only possible in Haskell, or does Haskell just make it super convenient / idiomatic?

Re: Haskell in the Large [pdf]

#59

Post by thu »

dkarapetyan wrote: post #17

I see. So all you need are compiler/interpreter experts that can turn any problem into a interpreter/compiler problem and you're golden. I'm not saying the approach is not worthwhile but how exactly does this generalize to other workplaces where there is no critical mass of such experts? I mean they have their own compiler for Haskell for Pete's sake. I would also like to know how many of the core team members have P…

"You're golden."

Indeed you are: you can use Haskell and GHC and reap the benefits of programming language and compiler experts. You can read the slides again and see that many things explained there are possible with GHC and don't require Mu.

I guess you can make a similar comment about PHP and Facebook. Facebook do have experts in compiler/interpreters to change the language/implementation to make it good at their scale.

Post reply on HN