8 ms·

As far as I can tell, the argument is that allowing side effects inside functions allows programmers to make mistakes, and therefore "mostly functional" program

by RyanZAG 11y ago

As far as I can tell, the argument is that allowing side effects inside functions allows programmers to make mistakes, and therefore "mostly functional" programming is broken. I'll happily extend this: "fully functional" programming does not work because I can define a mathematical function that divides by 0, and therefore does not work. I'd go a step further even: all programming does not work, because I can solve a problem in the wrong way if I make a mistake.

spdionis 11y ago
Your way of thinking is not really helping though. The goal is to minimize the amount of mistake, not eliminate them (because it is impossible). You can either think that everything is broken or nothing is broken, or you can try to make everything the least broken possible.
- reitanqild 11y ago
  > Your way of thinking is not really helping though. RyanZAG does not think that way, just tries to point out that the premise of the article seems broken.
- hawleyal 11y ago
  The article is proposing these points.
- laumars 11y ago
  His point was you cannot fix against bad programmers. While I'm sure we'd all agree that it's preferable that languages enable developers by throwing up the least amount of hidden traps, at some point we need to stop blaming our tools like the proverbial bad workman.
TazeTSchnitzel 11y ago
Mostly functional programming is broken because it cannot solve the problem it sets out to, namely controlling side effects. Because the language type system does not control them, "mostly functional" programming is no more useful than standard imperative programming.
- viraptor 11y ago
  I feel like the author makes it easy for himself, by both defining what other languages try to achieve by being mostly functional and how they fail to achieve that. I don't believe he's right with his assumptions. It's not like linq, Erlang, f#, ocaml, or even python func/itertools designers said - we're going to be as pure as possible and functional to get that almost-purity. Some problems are just easier to solve with functional-like approach. Whether you're doing it in a pure way or not doesn't matter. Some languages give you a way to write that functional-like solution. I doubt many think of purity while using them, but problems get solved. And we're still better off than writing nested loops instead. For example I'm happy with write: items.filter(f1) .map(f2) .map(f3) .reduce(... and I really really don't need or want an IO monad to be returned from f2 if it happens to need to log some warnings. It would be completely counterproductive.
  - pka 11y ago
    Just FYI, the author is one of the designers of LINQ.
  - TazeTSchnitzel 11y ago
    > and I really really don't need or want an IO monad to be returned from f2 if it happens to need to log some warnings. It would be completely counterproductive. Are you sure you don't? This means that anything calling your function now produces log entries, but it's not obvious without reading its code. Allowing side-effects saves you time now, but you might hate yourself later when trying to figure out why code in one part of your codebase is magically affecting code in another part.
    - viraptor 11y ago
      Why should anything calling f2 care whether it can produce a warning or not? If the contract is simple - return a value, then that's all we normally care about. If logs are not convincing, then think about profiling. One day you want to know what kind of values are computed by some function. Same story: impure adds stats.record(x), pure requires IO redesign.
calpaterson 11y ago
Nonsense! That works fine in Haskell: cal@hp-elitedesk ~/s/b/i/ops> ghci GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> 1/0 Infinity
- da_chicken 11y ago
  Well done, Haskell. You're not even wrong.
- RyanZAG 11y ago
  1/0 is not infinity, it is undefined. The limit as x tends to 0 of 1/x is infinity, but there is no value for 1/0, which is why doing a calculation that involves a divide by 0 is mathematically invalid. That Haskell let's you do it and gives an approximate answer is OK, but if it was in a calculation for the number of apples you can eat, it would be a useless answer. You could end up with that if you made a mistake in defining your logic. In the same way, you can make a mistake when doing all manner of other things such as using a non-pure function or adding instead of subtracting. They're all forms of logic error that are either allowed or disallowed by tools. The tool isn't broken if it let's you make mistakes though. A power drill will let you drill a nail into your leg. That doesn't make power drills broken. A smart drill that turned off the drill if your leg was in front would be better - but we still use drills without that function because there are trade offs when you make your drill do that. There are trade offs in functional languages too. That doesn't make C# "broken" for being a tool that let's you drill into your leg if you point your drill there.
  - thoth 11y ago
    Well then your formula which contains a division by zero is mathematically invalid as well. What do you think is valid - a floating point exception? That's how the hardware handles it. I think you're being overly pedantic on this specific example, division by zero is a special case. Floating point numbers on all architectures are only approximate - 1/7 times 7 is seldom exactly equal to 1, in any language, but that doesn't mean floating point math on a computer is useless.
NoGravitas 11y ago
a) All programs include at least one bug. b) All programs can be reduced by at least one line of code without affecting their behavior. Therefore: All programs can be reduced to a one-liner, which doesn't work.
agumonkey 11y ago
> "fully functional" programming does not work because I can define a mathematical function that divides by 0, and therefore does not work. Unless you have wheels : http://www2.math.su.se/reports/2001/11/2001-11.pdf http://www2.math.su.se/reports/2001/11/2001-11.pdf

by RyanZAG 11y ago

spdionis 11y ago

Your way of thinking is not really helping though. The goal is to minimize the amount of mistake, not eliminate them (because it is impossible). You can either think that everything is broken or nothing is broken, or you can try to make everything the least broken possible.

reitanqild 11y ago
> Your way of thinking is not really helping though. RyanZAG does not think that way, just tries to point out that the premise of the article seems broken.
hawleyal 11y ago
The article is proposing these points.
laumars 11y ago
His point was you cannot fix against bad programmers. While I'm sure we'd all agree that it's preferable that languages enable developers by throwing up the least amount of hidden traps, at some point we need to stop blaming our tools like the proverbial bad workman.

TazeTSchnitzel 11y ago

Mostly functional programming is broken because it cannot solve the problem it sets out to, namely controlling side effects. Because the language type system does not control them, "mostly functional" programming is no more useful than standard imperative programming.

viraptor 11y ago
I feel like the author makes it easy for himself, by both defining what other languages try to achieve by being mostly functional and how they fail to achieve that. I don't believe he's right with his assumptions. It's not like linq, Erlang, f#, ocaml, or even python func/itertools designers said - we're going to be as pure as possible and functional to get that almost-purity. Some problems are just easier to solve with functional-like approach. Whether you're doing it in a pure way or not doesn't matter. Some languages give you a way to write that functional-like solution. I doubt many think of purity while using them, but problems get solved. And we're still better off than writing nested loops instead. For example I'm happy with write: items.filter(f1) .map(f2) .map(f3) .reduce(... and I really really don't need or want an IO monad to be returned from f2 if it happens to need to log some warnings. It would be completely counterproductive.
- pka 11y ago
  Just FYI, the author is one of the designers of LINQ.
- TazeTSchnitzel 11y ago
  > and I really really don't need or want an IO monad to be returned from f2 if it happens to need to log some warnings. It would be completely counterproductive. Are you sure you don't? This means that anything calling your function now produces log entries, but it's not obvious without reading its code. Allowing side-effects saves you time now, but you might hate yourself later when trying to figure out why code in one part of your codebase is magically affecting code in another part.
  - viraptor 11y ago
    Why should anything calling f2 care whether it can produce a warning or not? If the contract is simple - return a value, then that's all we normally care about. If logs are not convincing, then think about profiling. One day you want to know what kind of values are computed by some function. Same story: impure adds stats.record(x), pure requires IO redesign.

calpaterson 11y ago

Nonsense! That works fine in Haskell: cal@hp-elitedesk ~/s/b/i/ops> ghci GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> 1/0 Infinity

da_chicken 11y ago
Well done, Haskell. You're not even wrong.
RyanZAG 11y ago
1/0 is not infinity, it is undefined. The limit as x tends to 0 of 1/x is infinity, but there is no value for 1/0, which is why doing a calculation that involves a divide by 0 is mathematically invalid. That Haskell let's you do it and gives an approximate answer is OK, but if it was in a calculation for the number of apples you can eat, it would be a useless answer. You could end up with that if you made a mistake in defining your logic. In the same way, you can make a mistake when doing all manner of other things such as using a non-pure function or adding instead of subtracting. They're all forms of logic error that are either allowed or disallowed by tools. The tool isn't broken if it let's you make mistakes though. A power drill will let you drill a nail into your leg. That doesn't make power drills broken. A smart drill that turned off the drill if your leg was in front would be better - but we still use drills without that function because there are trade offs when you make your drill do that. There are trade offs in functional languages too. That doesn't make C# "broken" for being a tool that let's you drill into your leg if you point your drill there.
- thoth 11y ago
  Well then your formula which contains a division by zero is mathematically invalid as well. What do you think is valid - a floating point exception? That's how the hardware handles it. I think you're being overly pedantic on this specific example, division by zero is a special case. Floating point numbers on all architectures are only approximate - 1/7 times 7 is seldom exactly equal to 1, in any language, but that doesn't mean floating point math on a computer is useless.

NoGravitas 11y ago

a) All programs include at least one bug. b) All programs can be reduced by at least one line of code without affecting their behavior. Therefore: All programs can be reduced to a one-liner, which doesn't work.

agumonkey 11y ago

> "fully functional" programming does not work because I can define a mathematical function that divides by 0, and therefore does not work. Unless you have wheels : http://www2.math.su.se/reports/2001/11/2001-11.pdf http://www2.math.su.se/reports/2001/11/2001-11.pdf