4 ms·

I argued recently that the core to functional programming is composition, rather than specific language features. This goes many ways, such as functional compos

by ddek 5y ago

I argued recently that the core to functional programming is composition, rather than specific language features. This goes many ways, such as functional composition (using currying, higher order functions etc) and type composition (using algebraic types). Functional polymorphism using HKT's and typeclasses are also compositional. Pattern matching, for example, is not itself 'functional programming', and never has been. It's a feature common in functional languages because it compliments algebraic types. OO/Imperative languages (C# and Rust) getting pattern matching is useful but doesn't make them functional languages. C# and Rust are compositional in the sense types may implement interfaces (or traits), but with varying degrees of power. However, C# can't have HKT's until some work on the CLR is done, Rust is much closer. Programmers (particularly web programmers) these days don't really consider the computational cost of their actions, so pure functions with immutable data types are now possible, despite the unnecessary allocation. Almost all popular OO architectures now are some variant of 'functional core, imperative shell'. There is definitely a 'functional shift'. It makes me a little sad tbh, to see OO languages embrace FP principles. I just like writing tiny functions and types, gluing them together somehow (not how Haskell does it*), and building up to a bigger system. You can follow that approach in F# or OCaml, but it's not really possible in an OO language, regardless of how 'functional' it now is. * Haskell is cool, but trying to explain to someone the difference between `.`, `$`, `<|>`, `|>`, `<$>`, `>>=` and more is quite painful.

m_arnold 5y ago
>Haskell is cool, but trying to explain to someone the difference between `.`, `$`, `<|>`, `|>`, `<$>`, `>>=` and more is quite painful. For those who aren't familiar, I'll explain: First of all, these are all infix operators, meaning they take two parameters: one before the symbol, and one after. You already know many infix operators: +, -, %, etc. I'll be surrounding them in parentheses, as that's idiomatic when they're not being used in the infix position. (.) is compose: run one function, then feed its result into the other. ($) is just a tool for avoiding parentheses. It means "wrap everything after this in a set of parens". (<|>) is alternative. Try one computation that can fail. If it doesn't work, try the other. (|>) is either snoc (the opposite of cons) or pipe--as in bash--depending on what you have imported. (<$>) is the general form of map, called fmap in Haskell (since map is just for lists). Given a function and a value inside a container, return the function applied to the value, inside the container. (>>=) ah, bind. One half of the interface to the famously difficult monad. It's really not that hard, conceptually: run a computation, then use the result of that to run another computation. You might say "that sounds like compose!" and you'd be right. The difference is that a "computation" (or "action", or whatever your local monad tutorial calls it) is a function in a context. That context can be "it might not exist", which is called Maybe, or "there are a lot of values in order", which is called List, or "it can do side effectful IO", which is called, well, IO. If you want to compose those kinds of computations, you need to also "compose" their contexts as well. The implentation of that composition varies from context to context, but the interace is the same: (>>=), or bind. Of course, conceptually is the easy part. This is the one operator in your list that can be a little difficult to gain an intuition for.

by ddek 5y ago

m_arnold 5y ago

>Haskell is cool, but trying to explain to someone the difference between `.`, `$`, `<|>`, `|>`, `<$>`, `>>=` and more is quite painful. For those who aren't familiar, I'll explain: First of all, these are all infix operators, meaning they take two parameters: one before the symbol, and one after. You already know many infix operators: +, -, %, etc. I'll be surrounding them in parentheses, as that's idiomatic when they're not being used in the infix position. (.) is compose: run one function, then feed its result into the other. ($) is just a tool for avoiding parentheses. It means "wrap everything after this in a set of parens". (<|>) is alternative. Try one computation that can fail. If it doesn't work, try the other. (|>) is either snoc (the opposite of cons) or pipe--as in bash--depending on what you have imported. (<$>) is the general form of map, called fmap in Haskell (since map is just for lists). Given a function and a value inside a container, return the function applied to the value, inside the container. (>>=) ah, bind. One half of the interface to the famously difficult monad. It's really not that hard, conceptually: run a computation, then use the result of that to run another computation. You might say "that sounds like compose!" and you'd be right. The difference is that a "computation" (or "action", or whatever your local monad tutorial calls it) is a function in a context. That context can be "it might not exist", which is called Maybe, or "there are a lot of values in order", which is called List, or "it can do side effectful IO", which is called, well, IO. If you want to compose those kinds of computations, you need to also "compose" their contexts as well. The implentation of that composition varies from context to context, but the interace is the same: (>>=), or bind. Of course, conceptually is the easy part. This is the one operator in your list that can be a little difficult to gain an intuition for.