7 ms·

I get the idea (doing fp for a living for 15 years) but the article lives in a bubble populated by mathematically pure unicorns: This strength/feature of fp ca

by jlg23 9y ago

I get the idea (doing fp for a living for 15 years) but the article lives in a bubble populated by mathematically pure unicorns: This strength/feature of fp can only weigh in where we have the mathematical formulas, arriving at those is the hard part in most programming jobs - most of the time those who "define" the product/spec cannot even do it in plain English (because they have to make up things as they go, no criticism, just acknowledgement of bizdev-reality).

maxxxxx 9y ago
I always envy people who can work on something that can be expressed with math or some other kind of consistent logic. Most company problems are inherently messy and you just end up with a litany of convoluted code.
- jjaredsimpson 9y ago
  Example please? Because I'm tempted to respond that there are no inherently messy problems, only insufficient solutions. What problem could possibly exist that only could be implemented in a convoluted way? Sounds more like: me and my team made trade offs that were, in retrospect, bad and now we don't know how to transform our code into a new program will fulfills the same requirements but is easier to inspect and understand.
  - dxhdr 9y ago
    > Because I'm tempted to respond that there are no inherently messy problems, only insufficient solutions. Really? There are entire industries which only work on "messy problems." ie game dev: implement a controller where jumping is both responsive and fun.
  - maxxxxx 9y ago
    In big companies requirements often change when strategy changes or some top manager has set his mind to something. So you are always behind the curve and you never get a set of stable requirements. Unfortunately that's reality in many companies. I pity people who have to work with SOAP or Salesforce.
    - beached_whale 9y ago
      Look at codifying legislation. It's all gray and nuanced. I have seen others use tools like JRules to help but people are kludgy
wvlia5 9y ago
Hi! I appreciate your honesty. Of course arriving at the Mathematical formula is the hard part, that's what it means to actually solve the problem. I consider the fact that you can't code your solution in this style until you have done so as a feature: you can't write code if you haven't really understood and solved the problem. (As opposed to imperative style which let's you implement a half done solution with hidden bugs, not covering all corner cases)
- jlg23 9y ago
  Understood. Just to be clear: I am saying that in most scenarios nobody understands the problem; people figure it out on the go. Overall I really like the article because it spells what is an essential feature of fp for me much better than I could have. It is just that it is too far from reality of most programming jobs (unless you happen to be Peter Norvig, working on the Mars rover).
  - wvlia5 9y ago
    Thanks, (y)
  - ASipos 9y ago
    I would be interested in seeing some more examples of that kind of jobs
    - mort96 9y ago
      Well, say you're writing code to interface with a mostly undocumented hardware h264 video encoder. Partly through spotty documentation about general use of the video4linux system, partly through that one piece of example code which exists to interface with the particular encoder, you make something which, if given a buffer of a raw I420 video frame, produces a buffer of encoded h264 video frame. Now, you figure out that the decoder which will decode the video expects the video stream to look different (specifically: the encoder produces only one picture parameter set and sequence parameter set at the beginning of the stream, but the decoder only understands the video if every key frame contains its own copy of the PPS and SPS). After a mix of reading source code and talking to people online, you figure out that there's an (undocumented) way to configure the encoder to include a PPS and SPS with every key frame. You figure that this is really something which must be specified by the h264 specification, so either the decoder is breaking the specification, or the hardware's encoder is; but at the end of the day, it's your fault if the encoded video isn't displayed on the receiver. Then, you figure out that while you're trying to encode 1920x1080 video, the encoder is only able to encode 16x16 chunks, so the output image is actually 1920x1088. This isn't documented anywhere, but after speaking with the person who wrote the driver for the hardware encoder in IRC, you learn that there's no way to make the driver handle it properly, at least not yet. Therefore, you extract the picture parameter set produced by the encoder, make some changes to have it include information about how the picture should be cropped by the decoder, and splice the modified PPS into the buffer for the encoded frame. That is what I've been doing at work (with some modifications; the above example is derived from working with two separate hardware video encoders). Even if it was possible to obtain exact documentation on how the encoders worked, sitting down and thinking really hard about how to describe the problem mathematically before writing the code would've been really hard, but because nothing really is documented, I will go so far as to claim it's impossible.
HumanDrivenDev 9y ago
How do you mean? I don't find myself scribbling down mathematical equations when doing things like chaining promises in javascript or transforming sequences with LINQ or marking fields as const. I realise functional programming can go in very different directions to things less mundane, but the general principle of avoiding side effects has been a huge win for me when programming in any language, even C++. It's just easier to debug or write something when you can fix some constraints, ie "this method is referentially transparent". Those are pretty low hanging fruit, but they help a lot.
- jlg23 9y ago
  Yes, please pick those low hanging fruits wherever possible. If you do and I have to maintain your code later I'll send you a bottle of your favorite dram out of gratitude. But the article (and my criticism) is about the rather high hanging fruit of mathematical purity - of which "side-effect free" programming is just a side-effect (pardon the pun).
- skywhopper 9y ago
  Yeah as the other response said, side-effect free programming is great. And while it's a side effect of pure-functional programming, there's absolutely nothing that ties it to a functional approach.
  - tabtab 9y ago
    "Lab toy" examples often use simplistic or unrealistic requirements to demonstrate some grand catchy abstraction. But real-world problems often end up being difficult to shoe-horn into the needed patterns. Perhaps the best and brightest can reformulate real-world requirements to fit, but they haven't codified the techniques yet. The last part seems the hardest.
skywhopper 9y ago
It's not even always about "can we spec this?" or "do we even understand the problem?". But when you get into the real world on a non-isolated system, you have to deal with invalid data, unexpected input, network failures, hardware failures, software bugs, security probing, user errors, memory limitations, timing issues, remote system failures, corrupted data, network failures, data storage failures, network failures, network failures, and network failures. Did I mention network failures? Also, as beautiful as side-effect-free programming is, any non-trivial program will have side-effects outside the program itself. And your beautiful functional code must account for that.

by jlg23 9y ago

maxxxxx 9y ago

I always envy people who can work on something that can be expressed with math or some other kind of consistent logic. Most company problems are inherently messy and you just end up with a litany of convoluted code.

jjaredsimpson 9y ago
Example please? Because I'm tempted to respond that there are no inherently messy problems, only insufficient solutions. What problem could possibly exist that only could be implemented in a convoluted way? Sounds more like: me and my team made trade offs that were, in retrospect, bad and now we don't know how to transform our code into a new program will fulfills the same requirements but is easier to inspect and understand.
- dxhdr 9y ago
  > Because I'm tempted to respond that there are no inherently messy problems, only insufficient solutions. Really? There are entire industries which only work on "messy problems." ie game dev: implement a controller where jumping is both responsive and fun.
- maxxxxx 9y ago
  In big companies requirements often change when strategy changes or some top manager has set his mind to something. So you are always behind the curve and you never get a set of stable requirements. Unfortunately that's reality in many companies. I pity people who have to work with SOAP or Salesforce.
  - beached_whale 9y ago
    Look at codifying legislation. It's all gray and nuanced. I have seen others use tools like JRules to help but people are kludgy

wvlia5 9y ago

Hi! I appreciate your honesty. Of course arriving at the Mathematical formula is the hard part, that's what it means to actually solve the problem. I consider the fact that you can't code your solution in this style until you have done so as a feature: you can't write code if you haven't really understood and solved the problem. (As opposed to imperative style which let's you implement a half done solution with hidden bugs, not covering all corner cases)

jlg23 9y ago
Understood. Just to be clear: I am saying that in most scenarios nobody understands the problem; people figure it out on the go. Overall I really like the article because it spells what is an essential feature of fp for me much better than I could have. It is just that it is too far from reality of most programming jobs (unless you happen to be Peter Norvig, working on the Mars rover).
- wvlia5 9y ago
  Thanks, (y)
- ASipos 9y ago
  I would be interested in seeing some more examples of that kind of jobs
  - mort96 9y ago
    Well, say you're writing code to interface with a mostly undocumented hardware h264 video encoder. Partly through spotty documentation about general use of the video4linux system, partly through that one piece of example code which exists to interface with the particular encoder, you make something which, if given a buffer of a raw I420 video frame, produces a buffer of encoded h264 video frame. Now, you figure out that the decoder which will decode the video expects the video stream to look different (specifically: the encoder produces only one picture parameter set and sequence parameter set at the beginning of the stream, but the decoder only understands the video if every key frame contains its own copy of the PPS and SPS). After a mix of reading source code and talking to people online, you figure out that there's an (undocumented) way to configure the encoder to include a PPS and SPS with every key frame. You figure that this is really something which must be specified by the h264 specification, so either the decoder is breaking the specification, or the hardware's encoder is; but at the end of the day, it's your fault if the encoded video isn't displayed on the receiver. Then, you figure out that while you're trying to encode 1920x1080 video, the encoder is only able to encode 16x16 chunks, so the output image is actually 1920x1088. This isn't documented anywhere, but after speaking with the person who wrote the driver for the hardware encoder in IRC, you learn that there's no way to make the driver handle it properly, at least not yet. Therefore, you extract the picture parameter set produced by the encoder, make some changes to have it include information about how the picture should be cropped by the decoder, and splice the modified PPS into the buffer for the encoded frame. That is what I've been doing at work (with some modifications; the above example is derived from working with two separate hardware video encoders). Even if it was possible to obtain exact documentation on how the encoders worked, sitting down and thinking really hard about how to describe the problem mathematically before writing the code would've been really hard, but because nothing really is documented, I will go so far as to claim it's impossible.

HumanDrivenDev 9y ago

How do you mean? I don't find myself scribbling down mathematical equations when doing things like chaining promises in javascript or transforming sequences with LINQ or marking fields as const. I realise functional programming can go in very different directions to things less mundane, but the general principle of avoiding side effects has been a huge win for me when programming in any language, even C++. It's just easier to debug or write something when you can fix some constraints, ie "this method is referentially transparent". Those are pretty low hanging fruit, but they help a lot.

jlg23 9y ago
Yes, please pick those low hanging fruits wherever possible. If you do and I have to maintain your code later I'll send you a bottle of your favorite dram out of gratitude. But the article (and my criticism) is about the rather high hanging fruit of mathematical purity - of which "side-effect free" programming is just a side-effect (pardon the pun).
skywhopper 9y ago
Yeah as the other response said, side-effect free programming is great. And while it's a side effect of pure-functional programming, there's absolutely nothing that ties it to a functional approach.
- tabtab 9y ago
  "Lab toy" examples often use simplistic or unrealistic requirements to demonstrate some grand catchy abstraction. But real-world problems often end up being difficult to shoe-horn into the needed patterns. Perhaps the best and brightest can reformulate real-world requirements to fit, but they haven't codified the techniques yet. The last part seems the hardest.

skywhopper 9y ago

It's not even always about "can we spec this?" or "do we even understand the problem?". But when you get into the real world on a non-isolated system, you have to deal with invalid data, unexpected input, network failures, hardware failures, software bugs, security probing, user errors, memory limitations, timing issues, remote system failures, corrupted data, network failures, data storage failures, network failures, network failures, and network failures. Did I mention network failures? Also, as beautiful as side-effect-free programming is, any non-trivial program will have side-effects outside the program itself. And your beautiful functional code must account for that.