ICFP report on the use of Haskell at Google
1–10 of 29 posts
Re: ICFP report on the use of Haskell at Google
#2Good 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 logical choice. Certainly the problems they discuss with Haskell's string handling and debugging support wouldn't be issues in Scala.
Re: ICFP report on the use of Haskell at Google
#3Good 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…
As I tried to explain in the paper, this started as an experiment, and not "let's write this in Haskell and use it in production".
But aside from that, the cluster balancer runs in just 5MB of RAM (RSS). I'm not familiar with Scala, but I doubt any JVM can run in just that; and the way we deploy this software, we like it to use as few memory as possible.
Re: ICFP report on the use of Haskell at Google
#4Good 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…
As I tried to explain in the paper, this started as an experiment, and not "let's write this in Haskell and use it in production". But aside from that, the cluster balancer runs in just 5MB of RAM (RSS). I'm not familiar with Scala, but I doubt any JVM can run in just that; and the way we deploy this software, we like it to use as few memory as possible.
That's true. Scala can be pretty fast but it needs a lot of ram.
Thanks for taking the time to write this up. Detailed descriptions of real-world applications of FP languages are always welcome.
Re: ICFP report on the use of Haskell at Google
#5Good 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?
Re: ICFP report on the use of Haskell at Google
#6Good 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?
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 over time though because it makes the overall program easier to understand and incurs fewer bugs than the imperative style. You can also avoid a lot of this if you express your functions in terms of other elemental sequence functions (map, reduce etc) instead of explicit recursion.
Doubtless others will disagree though. Maybe we don't all have the same mental strengths and weaknesses.
Re: ICFP report on the use of Haskell at Google
#7Earlier 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…
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.
Re: ICFP report on the use of Haskell at Google
#8Earlier quoted context omitted.
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…
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.
Perhaps the difficulty is in designing the appropriate data structures and identifying the correct transformation functions. In other words, designing a good FP program is difficult just like designing a good OO program is difficult.
Re: ICFP report on the use of Haskell at Google
#9Earlier quoted context omitted.
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…
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.
Re: ICFP report on the use of Haskell at Google
#10Good 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 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 "new functional" and "old functional", but despite superficial similarities they are diametrically philosophically opposed. Old functional, embodied by Lisp, works by trying to empower the programmer, and builds on that; new functional works by restricting the programmer and building on what guarantees we get from those restrictions. Haskell and Lisp may share some terminology when it comes to list manipulation but I would actually put them very, very far apart in my grand map of programming languages; they take one step together, the first lambda calculus step, and then immediately begin sprinting in opposite directions.)