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

ICFP report on the use of Haskell at Google

k1024.org

Post reply on HN
Print view View original

21–29 of 29 posts

Re: ICFP report on the use of Haskell at Google

#21

Post by strlen »

When I worked at Yahoo in an operations role ("production engineering", Yahoo's equivalent of Google's SRE), my team did something similar, we used OCaml in combination with Perl for one task: developing an a mini-language language for describing large clusters of machines (ranges of machines, querying and describing metadata such memberships of machine in a cluster, designating special nodes, descriptions of clusters). Although we ended up switching to C and lex/yacc for this mini-language (due to compiler issues after the switch to 64-bit OS, no idea if these compiler issues were fixed) it was a great experience.

I've since moved on to a software engineering role, but there's something to be said about the freedom (e.g., picking your tools) that exists when you're writing software that only you are responsible for.

Re: ICFP report on the use of Haskell at Google

#22

Post by nickik »

iustin wrote: post #12
edifice wrote: post #9

Earlier quoted context omitted.

It definitely depends on the algorithm. It also depends on the language. A lot of the difficulty of learning Haskell, for example, is in the type system. A dynamically typed FP lang like Clojure has a shallower learning curve.

It is true, but it's also unfortunate—I think a lot of Haskell's strengths come from its type system. So what makes Haskell worth learning also makes it hard to learn Haskell :)

Iit's also unfortunate - I think a lot of Clojure's strengths come from its macro system. So what makes Clojure worth learning also makes it hard to learn Clojure :)

There is stuff to learn in every language :)

Re: ICFP report on the use of Haskell at Google

#23

Post by loewenskind »

jerf wrote: post #10
runT1ME wrote: post #5

Earlier quoted context omitted.

>3. Programming effectively in a functional style is more difficult than banging out imperative code. As someone who is just starting to learn functional programming, do you believe this is because "we've" all been taught to think imperatively, and functional is just new to us? Or is it something inherent in functional style coding?

I think both are true. It is true that we aren't good at functional programming because we are not practiced. It is also true that functional programming makes some things intrinsically harder to do than in the imperative case. This is because modern functional programming gains its power by restricting the programmer, and building on those restrictions. (Sometimes I get in trouble when I try to distinguish between "…

Lisp was always multi-paradigm and supported functional programming.

I'm also not sure I'd go as far as to say "restricts" as much as demarcates. Composing existing code has been vary difficult in imperative languages (practically impossible when you have to deal with things like memory management and/or threading).

Re: ICFP report on the use of Haskell at Google

#25

Post by silentbicycle »

nickik wrote: post #19
silentbicycle wrote: post #14

Earlier quoted context omitted.

Some problems decompose cleanly that way, some don't. It's not hard to design a system where most is functional, though, and that's still useful . You've probably done that without considering it "functional programming"TM, just trying to cut out global variables and whatnot. Decades ago, "structured programming" was the new thing, and manifestos appeared about how gotos were "considered harmful". If you have a syste…

Your write but if you use a FP Language you are more forced to do so and it makes it easier to do. Why should I tear my self a arm of to do FP with Java or C++ if I can just use Haskell or a language that is not as strict as haskell.

No, you aren't. In OCaml, you can use mutable references, they're just not the default. Erlang has process dictionaries. Etc.

Haskell is unusually strict in that regard, turning what is normally a design option into an all-or-nothing situation.

Edit: I know there are a few ways around it via monads, but the culture surrounding Haskell seems quite a bit more likely to treat state/purity as an all-or-nothing issue than the others'. Maybe I'm making inaccurate assumptions about Haskell based on the loudest members of its community, though.

Re: ICFP report on the use of Haskell at Google

#26

Post by silentbicycle »

strait wrote: post #18
iustin wrote: post #12

Earlier quoted context omitted.

It is true, but it's also unfortunate—I think a lot of Haskell's strengths come from its type system. So what makes Haskell worth learning also makes it hard to learn Haskell :)

After working through a few of my own Haskell projects, I eventually found the type system disappointing. A better design would have made it even more sophisticated and harder to learn, IMO. That's the price to pay for being purely functional. Instead, I felt that certain design trade-offs were made, which in effect, make the type system awkward and tend to lead to inflexibility in writing ambitious, comprehensive pr…

Any examples you care to share?

Re: ICFP report on the use of Haskell at Google

#27

Post by jrockway »

iustin wrote: post #15
jrockway wrote: post #13

Weird. It seems like they didn't really know Haskell going into this; not having heard of "Either String" and not knowing that you can get a stack trace when you run your code in ghci.

I thought that is clear in the paper—I didn't have (almost) any experience with Haskell before, indeed. And the stack trace example is not related to ghci. You run software in production, and it crashes. What do you get?

I write my software in Haskell because it doesn't crash in production. But then again, before I deploy, I ensure that there are unit tests.

Re: ICFP report on the use of Haskell at Google

#28

Post by jrockway »

silentbicycle wrote: post #25
nickik wrote: post #19

Earlier quoted context omitted.

Your write but if you use a FP Language you are more forced to do so and it makes it easier to do. Why should I tear my self a arm of to do FP with Java or C++ if I can just use Haskell or a language that is not as strict as haskell.

No, you aren't. In OCaml, you can use mutable references, they're just not the default. Erlang has process dictionaries. Etc. Haskell is unusually strict in that regard, turning what is normally a design option into an all-or-nothing situation. Edit: I know there are a few ways around it via monads, but the culture surrounding Haskell seems quite a bit more likely to treat state/purity as an all-or-nothing issue than…

Not really. Mutable refs are provided by ST, which allows for chunks of your program where you are mutating state, but where the mutable state can't leak outside of boundaries you set.

(There is also the good-old-IORef, but I avoid IO for anything that's not input or output.)

Re: ICFP report on the use of Haskell at Google

#29

Post by gaius »

nickik wrote: post #19
silentbicycle wrote: post #14

Earlier quoted context omitted.

Some problems decompose cleanly that way, some don't. It's not hard to design a system where most is functional, though, and that's still useful . You've probably done that without considering it "functional programming"TM, just trying to cut out global variables and whatnot. Decades ago, "structured programming" was the new thing, and manifestos appeared about how gotos were "considered harmful". If you have a syste…

Your write but if you use a FP Language you are more forced to do so and it makes it easier to do. Why should I tear my self a arm of to do FP with Java or C++ if I can just use Haskell or a language that is not as strict as haskell.

I'd say to all intents and purposes you can't do FP with Java, or at least not leverage some of the advantages of doing do, because you simply don't know where in the libraries there might be some mutable state. In that sense, Java's greatest strength, its vast ecosystem, is a fundamental weakness. The same is true with other JVM languages such as Scala and Clojure as soon as you start to leverage third-party JARs.

With Haskell, you know that something that claims to be pure is.

Post reply on HN