6 ms·

2 years from now: "we got rid of all the functional bullshit and we're now using ifs and for loops all over the place; reminds us of our fixie bicycles and othe

2 years from now: "we got rid of all the functional bullshit and we're now using ifs and for loops all over the place; reminds us of our fixie bicycles and other aspects of our hipster lifestyle". Over the past two decades I've internalized the value of writing code that's very easy to understand. Otherwise 6 months later I can't figure things out myself. This Java style reminds me very much of Scala which seemed like a decent language until I saw how people actually use it in practice. Noped right out of that in a hurry.

eveningcoffee 10y ago
I think what you are describing is a replacement of widely known constructs (if, for etc) with an unknown API. If this API is not understood then the code feels convoluted. Therefore such projects have to contain a document that will explain the most common usage of the API to the newcomer. I think that this would remove most of the confusion. Naturally it would be good if we had one most widely standardized API that most of the people are familiar with (like they are with if and for).
- cel1ne 10y ago
  Reading an API's documentation doesn't mean that the mental overhead when using it is gone. You still have to think about how the pieces fit together, how to get from generic examples to your specific case etc. I can dream up APIs which will keep confusing you, no matter how long you use them (hello Android SDK!). Or which have difficult to memorize syntax (hello Bash!).
- AnonymousPlanet 10y ago
  I think this has to do with implicit behaviour vs. explicit statements. Using Optionals introduces an implicit layer that is much "thicker" than even the most tricky for syntax out there. There is a strong case for keeping all involved parts as simple as possible. And this assumes there are no implicit caveats and exceptions in the overall behaviour of the type, or that any one decides to subtly move the goal posts behind the scenes five years down the road.
- ahoka 10y ago
  Map, filter, fold, etc. are pretty much standard constructs and any decent programmer should be familiar with them. There are subtle variations in naming like Java's Map is Select in C# because Microsoft modeled its functional API on SQL, but you have the same differences for iteration and selection (the things you are referring to for and if). For example you have 'for (int i = 0; i < n; i++)' in C, but you don't have the exact same way of doing it in Python, where you have to use a range: 'for num in range(0, n):' or you can write a 'while' loop in Java but not in Go where it's a 'for' with a single expression. I would choose a functional version over a three level nested for loop monster any day.
  - reitanqild 10y ago
    Let me be the one: I'm a fairly decent programmer and I never worked with map or flatmaps outside of examples. I have however significantly simplified two significant code bases, made and maintained for years a webapp that users loved etc. Very often I feel it is just people wanting to sell something and it wouldn't surprise me if many of the people who sell functional are the same who sold object oriented back in the day. This article was actually a bit refreshing IMO.
    - kaeluka 10y ago
      As programmers, we often confuse the means with the ends. We tend to over-emphasise the way in which code is written and we tend to forget about whether the code is doing the right thing. That being said, I love map/filter/flatMap. Look at them as higher level loops. For example: A while loop is very general, you can implement any kind of loop with it. This makes it harder to understand the meaning of the loop. Therefore, when you want to iterate a constant number of times, you'll likely use a for loop. It expresses your intent better. Map, filter, and flatMap are just extending this principle to more specialised use cases. The advantage for a reader is that the one word "map" already tells them a lot about what the loop body is good for.
      - heisenbit 10y ago
        Maybe it is a higher level of looping and certainly looks pleasing. However when it comes to using a debugger I have not found a way to avoid a higher level of effort.
- fauigerzigerk 10y ago
  I think this is replacing a formalism closer to natural language with one that is more abstract. It's often justified to do that. For instance, we model stuff as matrices or graphs to gain access to their mathematical properties or because we have specialized hardware for matrix operations. The big debate right now is whether the mathematical properties of functional programming are useful enough to move further away from natural language for general purpose programming. We probably think something like this: Parse and validate the request If that fails then return 400, "invalid request: " + err Run business logic to get a result If that fails then return 500, "logic failed: " + err return 200, result as JSON So should we use a formal language that looks similar to that or are there good reasons to use a chain of map and flatMap calls to hide the branching logic?
  - deleted 10y ago
    [deleted]
- mpweiher 10y ago
  > If this API is not understood then the code feels convoluted. I think there is more going on here. For the sake of eliminating an if, you are lifting everything else into what is effectively a separate language with the original code embedded in that language. Overall, that doesn't look like a win to me. After all, what is the actual domain logic? Is it flatMap().map().flatMap().map()? Or is it validate().businessLogic().generate() ? That doesn't mean that what is going in isn't useful, but it seems to me we need to have a way to specify the lifting without writing it down everywhere, so that the actual code can be expressed at the base level again.
  - Zak 10y ago
    I think replacing common usage patterns of generic control structures with named constructs adds clarity: for(blah blah blah) tells the reader nothing more than there's going to be a loop, but map(blah blah blah) tells the reader one sequence is going to be transformed into another by applying a function to each item. That's more informative to the reader if used for its intended purpose. It has the opposite effect if abused to repeatedly call a function mainly for its side-effects. All programming techniques should be viewed as means to write code that's some combination of readable, reliable and performant, not as ends themselves.
    - jghn 10y ago
      Right. I find that the easiest code to read is code written in a data flow style such that it's a series of transforms on data.
      - mercer 10y ago
        I'm not a functional purist, but I find that the functional 'principles' that I benefit the most from, in any context, are 1) massaging my data into the right shape with as few transforms as possible/practical/legible, 2) using pure functions whenever possible (in practice this often means accepting a few extra parameters in lieu of writing the code as a method; avoid 'this' in js, for example), and 3) starting with the data structures and seeing my app as, to a large degree, just a set of transformations on that (which usually is appropriate for the type of stuff I build). I don't use partial application/currying that much, but more and more over time. All in all I feel that doing these things have greatly improved my code and efficiency, and I'm kind of waiting for some downtime to get back into learning the more 'hardcore' functional languages.
jghn 10y ago
I went from java to scala precisely because of the functional stuff. This was in the java 6 days so dunno if that's still be true if I were a java guy today
deleted 10y ago
[deleted]
deleted 10y ago
[deleted]

eveningcoffee 10y ago

I think what you are describing is a replacement of widely known constructs (if, for etc) with an unknown API. If this API is not understood then the code feels convoluted. Therefore such projects have to contain a document that will explain the most common usage of the API to the newcomer. I think that this would remove most of the confusion. Naturally it would be good if we had one most widely standardized API that most of the people are familiar with (like they are with if and for).

cel1ne 10y ago
Reading an API's documentation doesn't mean that the mental overhead when using it is gone. You still have to think about how the pieces fit together, how to get from generic examples to your specific case etc. I can dream up APIs which will keep confusing you, no matter how long you use them (hello Android SDK!). Or which have difficult to memorize syntax (hello Bash!).
AnonymousPlanet 10y ago
I think this has to do with implicit behaviour vs. explicit statements. Using Optionals introduces an implicit layer that is much "thicker" than even the most tricky for syntax out there. There is a strong case for keeping all involved parts as simple as possible. And this assumes there are no implicit caveats and exceptions in the overall behaviour of the type, or that any one decides to subtly move the goal posts behind the scenes five years down the road.
ahoka 10y ago
Map, filter, fold, etc. are pretty much standard constructs and any decent programmer should be familiar with them. There are subtle variations in naming like Java's Map is Select in C# because Microsoft modeled its functional API on SQL, but you have the same differences for iteration and selection (the things you are referring to for and if). For example you have 'for (int i = 0; i < n; i++)' in C, but you don't have the exact same way of doing it in Python, where you have to use a range: 'for num in range(0, n):' or you can write a 'while' loop in Java but not in Go where it's a 'for' with a single expression. I would choose a functional version over a three level nested for loop monster any day.
- reitanqild 10y ago
  Let me be the one: I'm a fairly decent programmer and I never worked with map or flatmaps outside of examples. I have however significantly simplified two significant code bases, made and maintained for years a webapp that users loved etc. Very often I feel it is just people wanting to sell something and it wouldn't surprise me if many of the people who sell functional are the same who sold object oriented back in the day. This article was actually a bit refreshing IMO.
  - kaeluka 10y ago
    As programmers, we often confuse the means with the ends. We tend to over-emphasise the way in which code is written and we tend to forget about whether the code is doing the right thing. That being said, I love map/filter/flatMap. Look at them as higher level loops. For example: A while loop is very general, you can implement any kind of loop with it. This makes it harder to understand the meaning of the loop. Therefore, when you want to iterate a constant number of times, you'll likely use a for loop. It expresses your intent better. Map, filter, and flatMap are just extending this principle to more specialised use cases. The advantage for a reader is that the one word "map" already tells them a lot about what the loop body is good for.
    - heisenbit 10y ago
      Maybe it is a higher level of looping and certainly looks pleasing. However when it comes to using a debugger I have not found a way to avoid a higher level of effort.
fauigerzigerk 10y ago
I think this is replacing a formalism closer to natural language with one that is more abstract. It's often justified to do that. For instance, we model stuff as matrices or graphs to gain access to their mathematical properties or because we have specialized hardware for matrix operations. The big debate right now is whether the mathematical properties of functional programming are useful enough to move further away from natural language for general purpose programming. We probably think something like this: Parse and validate the request If that fails then return 400, "invalid request: " + err Run business logic to get a result If that fails then return 500, "logic failed: " + err return 200, result as JSON So should we use a formal language that looks similar to that or are there good reasons to use a chain of map and flatMap calls to hide the branching logic?
- deleted 10y ago
  [deleted]
mpweiher 10y ago
> If this API is not understood then the code feels convoluted. I think there is more going on here. For the sake of eliminating an if, you are lifting everything else into what is effectively a separate language with the original code embedded in that language. Overall, that doesn't look like a win to me. After all, what is the actual domain logic? Is it flatMap().map().flatMap().map()? Or is it validate().businessLogic().generate() ? That doesn't mean that what is going in isn't useful, but it seems to me we need to have a way to specify the lifting without writing it down everywhere, so that the actual code can be expressed at the base level again.
- Zak 10y ago
  I think replacing common usage patterns of generic control structures with named constructs adds clarity: for(blah blah blah) tells the reader nothing more than there's going to be a loop, but map(blah blah blah) tells the reader one sequence is going to be transformed into another by applying a function to each item. That's more informative to the reader if used for its intended purpose. It has the opposite effect if abused to repeatedly call a function mainly for its side-effects. All programming techniques should be viewed as means to write code that's some combination of readable, reliable and performant, not as ends themselves.
  - jghn 10y ago
    Right. I find that the easiest code to read is code written in a data flow style such that it's a series of transforms on data.
    - mercer 10y ago
      I'm not a functional purist, but I find that the functional 'principles' that I benefit the most from, in any context, are 1) massaging my data into the right shape with as few transforms as possible/practical/legible, 2) using pure functions whenever possible (in practice this often means accepting a few extra parameters in lieu of writing the code as a method; avoid 'this' in js, for example), and 3) starting with the data structures and seeing my app as, to a large degree, just a set of transformations on that (which usually is appropriate for the type of stuff I build). I don't use partial application/currying that much, but more and more over time. All in all I feel that doing these things have greatly improved my code and efficiency, and I'm kind of waiting for some downtime to get back into learning the more 'hardcore' functional languages.

jghn 10y ago

I went from java to scala precisely because of the functional stuff. This was in the java 6 days so dunno if that's still be true if I were a java guy today

deleted 10y ago

[deleted]

deleted 10y ago

[deleted]