3 ms·

In terms of code complexity, I honestly can't decide whether the difference is objective or subjective. The functional version sure feels complex to me, but ye

by kentonv 13y ago

In terms of code complexity, I honestly can't decide whether the difference is objective or subjective. The functional version sure feels complex to me, but yeah, it may just be because that's not what I'm used to. That said, given my knowledge of how the hardware actually works, the purely-functional approach makes my efficiency sense tingle. A lot. Of course, whether or not it's a good idea to scratch it is something we've been debating for decades...

rybosome 13y ago
This is kind of a strawman, but if you were to use a similar pseudo-API, what would the imperative code look like? Very fair point about efficiency; for all my love of the FP style, I'll never claim it to be faster or leaner w.r.t memory usage. I'd be curious to see if the simple parallelization made possible by the functional approach could close that performance gap, though. ...and I'm almost positive the difference is subjective. =) Reading over your website, it's clear that you are a very talented engineer, especially in areas where C++ shines. Given this plus your experience at Google developing Protobuf, I'd hazard a guess that you have a significant amount of experience writing OO or imperative code, and probably somewhat less writing in the functional style.
DannoHung 13y ago
Unfortunately, non-strictness is the biggest hindrance to understanding operational semantics of Haskell. To my knowledge, people using Haskell in serious production use strictness annotations like there's no tomorrow.
- enigmo 13y ago
  I did a simple survey of our codebase... as I think we meet your requirements for serious production Haskell. Here's the terribly inaccurate and probably misleading results: Raw line count: destroyer:alphaHeavy$ find . -name "*.hs" | xargs wc -l | tail -1 132272 total Things that look like bang patterns or strict fields: destroyer:alphaHeavy$ grep "\!" -rI . --include "*.hs" | egrep -v "\\$\!|\.\!|\!\?|\!\!" | wc -l 1344 Strict returns: destroyer:alphaHeavy$ grep "\\$\!" -rI . --include "*.hs" | wc -l 762 Unboxed fields: destroyer:alphaHeavy$ grep UNPACK -rI . --include "*.hs" | wc -l 298
- Peaker 13y ago
  Strict fields in records are probably a better default than lazy fields. So you indeed see lots of strictness annotations in data structures. It also helps with unpacking/unboxing. However, strictness annotations in functions is a relatively rare thing.

by kentonv 13y ago

rybosome 13y ago

This is kind of a strawman, but if you were to use a similar pseudo-API, what would the imperative code look like? Very fair point about efficiency; for all my love of the FP style, I'll never claim it to be faster or leaner w.r.t memory usage. I'd be curious to see if the simple parallelization made possible by the functional approach could close that performance gap, though. ...and I'm almost positive the difference is subjective. =) Reading over your website, it's clear that you are a very talented engineer, especially in areas where C++ shines. Given this plus your experience at Google developing Protobuf, I'd hazard a guess that you have a significant amount of experience writing OO or imperative code, and probably somewhat less writing in the functional style.

DannoHung 13y ago

Unfortunately, non-strictness is the biggest hindrance to understanding operational semantics of Haskell. To my knowledge, people using Haskell in serious production use strictness annotations like there's no tomorrow.

enigmo 13y ago
I did a simple survey of our codebase... as I think we meet your requirements for serious production Haskell. Here's the terribly inaccurate and probably misleading results: Raw line count: destroyer:alphaHeavy$ find . -name "*.hs" | xargs wc -l | tail -1 132272 total Things that look like bang patterns or strict fields: destroyer:alphaHeavy$ grep "\!" -rI . --include "*.hs" | egrep -v "\\$\!|\.\!|\!\?|\!\!" | wc -l 1344 Strict returns: destroyer:alphaHeavy$ grep "\\$\!" -rI . --include "*.hs" | wc -l 762 Unboxed fields: destroyer:alphaHeavy$ grep UNPACK -rI . --include "*.hs" | wc -l 298
Peaker 13y ago
Strict fields in records are probably a better default than lazy fields. So you indeed see lots of strictness annotations in data structures. It also helps with unpacking/unboxing. However, strictness annotations in functions is a relatively rare thing.