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

11–20 of 29 posts

Re: ICFP report on the use of Haskell at Google

#11

Post by moultano »

runT1ME wrote: post #5
edifice wrote: post #2

Good article. Mirrors my own experience in three ways: 1. Immutable datastructures make it a lot easier to reason about data flow and to write correct code. 2. Static typing helps write cleaner, more explicit APIs. 3. Programming effectively in a functional style is more difficult than banging out imperative code. I wonder why they didn't try Scala. With Google's extensive Java infrastructure that seems like a more l…

>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 it's fundamental. We don't go through our lives recursively. We do one thing, then we do another. When I was first starting writing ML, I found it convenient to assume my program already works, and then do the next step. I don't think this is something people are naturally very comfortable with doing.

Re: ICFP report on the use of Haskell at Google

#12

Post by iustin »

edifice wrote: post #9
jemfinch wrote: post #7

Earlier quoted context omitted.

Chalk me up as someone who disagrees. Personally, I find recursive transformations of immutable structures far easier to reason about than iterative modifications to mutable structures. At least in some cases, I think that's the expected result: consider the difficulty of reversing a singly linked list in-place and reversing it applicatively.

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 :)

Re: ICFP report on the use of Haskell at Google

#14

Post by silentbicycle »

runT1ME wrote: post #5
edifice wrote: post #2

Good article. Mirrors my own experience in three ways: 1. Immutable datastructures make it a lot easier to reason about data flow and to write correct code. 2. Static typing helps write cleaner, more explicit APIs. 3. Programming effectively in a functional style is more difficult than banging out imperative code. I wonder why they didn't try Scala. With Google's extensive Java infrastructure that seems like a more l…

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

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 system where 95% of it is functional, cool, you've eliminated 95% of the places where you have to double-check for dataflow/mutability-related bugs. (To heavily paraphrase jerf's comment: functional programming is about accepting restrictions that make debugging simpler.) Make the system as clean as feasible, but don't get bent out of shape trying to get the last 5% FP-approved. It's probably less trouble to just know that's the hairy part.

The big idea in functional programming is that working with immutable data structures makes a lot of annoying bugs go away, and goddamnit, they're right. Does that mean you need to go 100% immutable? No - it's just a good default.

FP-style programming without (generational) garbage collection is really awkward, though - immutability means you're going to be creating a lot of temporary data structures. Good language implementations will recognize this and just stack-allocate them or let them go in the first collection.

Re: ICFP report on the use of Haskell at Google

#15

Post by iustin »

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?

Re: ICFP report on the use of Haskell at Google

#16

Post by silentbicycle »

edifice wrote: post #6
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?

Good question. My opinion is that thinking in terms of recursive transformations of immutable datastructures is just fundamentally more difficult than the imperative equivalents. My earliest exposure to recursive algorithms was in AP computer science in high school and I remember a lot of the students really struggled with them, both those with previous imperative experience and without. This extra effort can pay off…

I think many programmers find it hard because experience with Algol-derived languages give them bad assumptions - they expect all of the conceptual baggage of mandatory stack allocation, so recursion seems ludicrous and complicated.

Recursive cases in languages with tail-call optimization are like inductive reasoning in mathematics - "How long is a list? If it's empty, zero, otherwise one (for the head) plus however long the rest is."

Re: ICFP report on the use of Haskell at Google

#17

Post by silentbicycle »

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 :)

Haskell's type system is unfortunate, because for most programmers, 80+% of the benefit comes from how it utterly nails the basics (checking variant type coverage in pattern matching, typeclasses), but the language community is focused on the cutting edge top .003%, because that's where the research papers are.

Re: ICFP report on the use of Haskell at Google

#18

Post by strait »

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 :)

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

Re: ICFP report on the use of Haskell at Google

#19

Post by nickik »

silentbicycle wrote: post #14
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?

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.

Re: ICFP report on the use of Haskell at Google

#20

Post by nickik »

edifice wrote: post #6
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?

Good question. My opinion is that thinking in terms of recursive transformations of immutable datastructures is just fundamentally more difficult than the imperative equivalents. My earliest exposure to recursive algorithms was in AP computer science in high school and I remember a lot of the students really struggled with them, both those with previous imperative experience and without. This extra effort can pay off…

He i think you are write but that is where the Language can help you. You don't have do the recursion every time by hand. You can have language constructs that are just as easy as normal loops but work like recursion in the compiler. If you really need to do the recursion you would have to do so in imperativ languages to.

(Node: I don't no haskell)

Post reply on HN