4 ms·
Functional programming means, that your program is composed out of functions. A function only depends on its input parameters and the effect of applying a funct
by _ph_ 9y ago
Functional programming means, that your program is composed out of functions. A function only depends on its input parameters and the effect of applying a function is the returned function result. By this definition, functions don't have side effects.
Why do functions and functional programming matter?
- Functions are a very nice abstraction. Looking at the input and output values gives you the complete information about the data flow. This makes functions very easy to reason about.
- With the absence of side effects, you also have no unintended side effects, which plague all code which modifies state.
- Functions are easily testable, they do not depend on an environment but just the function parameters.
- For the same input a function necessarily always returns the same result, this also makes reasoning about a programs behavior easier.
- As a consequence that they only depend on their inputs, functions usually are very composeable.
While for certain tasks, modifying a global state can be the most efficient way of performing a computation, functional programming does not have to be slow, and in many cases the resulting program might even be faster. There are several reasons for this:
- With the lack of side-effects, functional programs can be relatively easy parallelized.
- With only local state involved, compilers can optimize the code inside functions more aggressively.
There are pure functional languages, but most modern languages allow you to write your program in a functional style. So it is possible to mix functional with object oriented programming.
- wiz21c 9y ago>>> functions usually are very composeable This plus the fact that the "function" is also the most basic way to describe operation on data means that you can build any kind of operations, data structure, program construct as you please like lego. This is at the same time, imho, the weakness of the paradigm when used in industry : it gives so much freedom that two programmers will solve the same problem in different ways, making it harder to share code. Not everyone has the desire/patience to understand the many flavors of solutions proposed by the colleagues.
- _mhr_ 9y agoWhat do you think the solution is? Not being snarky here; I'm genuinely interested in the problem you've described, because this unbounded freedom bothers me too.
- b4ux1t3 9y agoNot who you replied to, but I, personally, think it boils down to trust. Using someone else's code, _especially_ if it's functional, should be the same as using the proverbial black box. You shouldn't need to understand their code in order to use it with your own. The same should be true of your own code, really. You shouldn't need to remember implementation details of a function you wrote in order to use it in elsewhere in your code. I know there's then the issue of security, freedom, openness. . .whatever. But if you're working on a project with someone else, and you don't trust them, the project's probably doomed to fail to begin with.
- Jtsummers 9y agoDiscipline. A lot of people dislike bondage and discipline languages like Ada. But one of the reasons for those languages was that it enforced discipline. This made it very compelling from a systems engineering perspective. Languages that permit more freedom for programmers require the programmers, themselves, to practice discipline. This requires attention to detail, up to date documentation, and effective communication. Those things require full-time staff, beyond just the programmers, to facilitate. And, really, you need to have systems architects/engineers to be making decisions or guiding decisions with a heavy hand.
- harrisi 9y agoMy immediate thought is specifying the requirements for the input and output desired. This is something I thought a small bit about when learning Haskell. It's easy enough to search on Hoogle[0] by type signature to at least narrow it down, but then you have to look through all sorts of functions to see if the semantics are correct. Then, one may think, perhaps having search functionality to pass a collection of inputs and outputs and run any relevant functions that have a valid type for the inputs and outputs. However, that could take longer to compute than just writing the function in the first place. It also gets complicated because perhaps what you need is a composition of functions (map reduce, filter map, etc.), so now how do you know when to stop composing functions to get the desired output? I'm not smart enough to know if there's a general solution to this (other than simpler cases of cycles). I would also really like more insights into this. I'm working on a toy project dealing with bytecode and being able to interpret the semantics of a series of instructions reliably would be very handy. I believe if the above has any practicality then it would help my problem. [0]: https://www.haskell.org/hoogle/ https://www.haskell.org/hoogle/
- mercer 9y agoI don't know if this relates or whether I'm misunderstanding, but one approach to impose a bit more structure on the functional approach that I rather like is 'behaviours' in Elixir (and Erlang?): https://elixir-lang.org/getting-started/typespecs-and-behaviours.html#behaviours https://elixir-lang.org/getting-started/typespecs-and-behavi...
- eighthnate 9y ago> - Functions are easily testable, they do not depend on an environment but just the function parameters. Think you overlooked closures. Environment is an important part of functional programming/languages.
- pacomerh 9y agoWorth mentioning that when you're dealing with pure functions that by definition avoid side effects, and your application somehow requires side effects. Most of the time you can solve this by pushing side effects from the pure code, so your functional code is decoupled and more manageable.