4 ms·

Functional programming is magical. The majority of people who works with magical frameworks tend to agree that having libraries doing simple predictable things

by fiatjaf 10y ago

Functional programming is magical. The majority of people who works with magical frameworks tend to agree that having libraries doing simple predictable things is better than magic. At the same time, everybody seems to think functional languages are awesome.

dustingetz 10y ago
fp is the opposite of magical because it is essentially math, 100% predictable (follows laws) and all things composed of simple primitives
- Royalaid 10y ago
  I think the OP of this thread means performance is obscured and as a result requires tuning which can be finicky and difficult
- user837387 10y ago
  I'll jump into the flame war and say that every single programming language we use with computers is math. It may just not be expressed in a way you are comfortable with. And they are all as 100% predictable as FP.
  - eof 10y ago
    There is a difference though. In a (strict) functional language, foo(bar) always returns the same way and always has the same affect. In almost every non-strict language foo(bar) can do anything, and can always be different based off some state not contained in foo or bar, but only the scope of the program. So while mathematically they may both be equally as predictable at the physical level, given only a function its parameters, a strict functional language is predictable while a 'traditional' language is not
    - clusmore 10y ago
      I don't think that this is because of functional vs other, but because of the assignment operator and mutable primitives (which functional languages tend to omit). Consider \x y -> g (f x) (f y) We have no way of knowing what this function will do, because f and g are free variables with respect to the function. But we assume they are constant, so we're happy. And if you zoom out far enough eventually you'll find the binding locations. Instance members and globals are just the imperative version of free variables, and if it weren't for that pesky assignment operator or mutable primitives, they'd be constant and hence completely harmless too. You could imagine an OO language without assignment or mutable primitives that would have all the advantages of "functional" languages but that would still feel different enough in style that we wouldn't call it one.
- fiatjaf 10y ago
  A computer does not work by means of "essentially math". It is a sequence on instructions. How does "pure math" translate into a sequence of instructions? No one knows! Magic!
wyager 10y ago
This is the opposite of the truth; the semantics of functional languages are vastly simpler than the semantics of your average imperative language. This is why C(++) is chock full of undefined behaviors, whereas a language like Haskell (built on extremely simple primitives like lambda-abstraction) have almost none. The only interesting undefined behaviors in Haskell are weird things with strictness that no one ever really runs into and typically don't have any impact on your program unless you're doing something strange with IO-based exception handling. And for any such case, there's a library that exports a version of whatever you're trying to do that has well-defined behavior on any compiler. One thing that I'll agree is more "magical" for functional language is the transformation from functional code to efficient machine code. It's not obvious how Haskell can achieve such high performance when it makes almost no concessions to the underlying architecture of the computer. On the other hand, it's usually pretty clear what kind of assembly your C will turn into. This can make performance estimation more difficult.
- dispose13432 10y ago
  > the semantics of functional languages are vastly simpler than the semantics of your average imperative language. This is why C(++) is chock full of undefined behaviors, whereas a language like Haskell (built on extremely simple primitives like lambda-abstraction) have almost none C(++) has undefined behavior because it's meant to run close to metal, and there's no official standard of CPU design. If anything, a C compiler could always insert an "if" in a non-standard arch on every signed addition to get it to overflow the "right way". The thing is that it would ruin performance. And the proof is that Java, which was quite imperative, doesn't have nearly as much undefined behavior as C.
  - wyager 10y ago
    > Java, which was quite imperative, doesn't have nearly as much undefined behavior as C. You're right, but Java is still orders of magnitude less predictable than Haskell. A few good links here. http://stackoverflow.com/questions/376338/what-are-the-common-undefined-behaviours-that-java-programmers-should-know-about http://stackoverflow.com/questions/376338/what-are-the-commo... It essentially boils down to a combination of unsound type systems and underspecified semantics. Java was not created on a sound theoretical basis - it's quite ad-hoc.

by fiatjaf 10y ago

dustingetz 10y ago

fp is the opposite of magical because it is essentially math, 100% predictable (follows laws) and all things composed of simple primitives

Royalaid 10y ago
I think the OP of this thread means performance is obscured and as a result requires tuning which can be finicky and difficult
user837387 10y ago
I'll jump into the flame war and say that every single programming language we use with computers is math. It may just not be expressed in a way you are comfortable with. And they are all as 100% predictable as FP.
- eof 10y ago
  There is a difference though. In a (strict) functional language, foo(bar) always returns the same way and always has the same affect. In almost every non-strict language foo(bar) can do anything, and can always be different based off some state not contained in foo or bar, but only the scope of the program. So while mathematically they may both be equally as predictable at the physical level, given only a function its parameters, a strict functional language is predictable while a 'traditional' language is not
  - clusmore 10y ago
    I don't think that this is because of functional vs other, but because of the assignment operator and mutable primitives (which functional languages tend to omit). Consider \x y -> g (f x) (f y) We have no way of knowing what this function will do, because f and g are free variables with respect to the function. But we assume they are constant, so we're happy. And if you zoom out far enough eventually you'll find the binding locations. Instance members and globals are just the imperative version of free variables, and if it weren't for that pesky assignment operator or mutable primitives, they'd be constant and hence completely harmless too. You could imagine an OO language without assignment or mutable primitives that would have all the advantages of "functional" languages but that would still feel different enough in style that we wouldn't call it one.
fiatjaf 10y ago
A computer does not work by means of "essentially math". It is a sequence on instructions. How does "pure math" translate into a sequence of instructions? No one knows! Magic!

wyager 10y ago

This is the opposite of the truth; the semantics of functional languages are vastly simpler than the semantics of your average imperative language. This is why C(++) is chock full of undefined behaviors, whereas a language like Haskell (built on extremely simple primitives like lambda-abstraction) have almost none. The only interesting undefined behaviors in Haskell are weird things with strictness that no one ever really runs into and typically don't have any impact on your program unless you're doing something strange with IO-based exception handling. And for any such case, there's a library that exports a version of whatever you're trying to do that has well-defined behavior on any compiler. One thing that I'll agree is more "magical" for functional language is the transformation from functional code to efficient machine code. It's not obvious how Haskell can achieve such high performance when it makes almost no concessions to the underlying architecture of the computer. On the other hand, it's usually pretty clear what kind of assembly your C will turn into. This can make performance estimation more difficult.

dispose13432 10y ago
> the semantics of functional languages are vastly simpler than the semantics of your average imperative language. This is why C(++) is chock full of undefined behaviors, whereas a language like Haskell (built on extremely simple primitives like lambda-abstraction) have almost none C(++) has undefined behavior because it's meant to run close to metal, and there's no official standard of CPU design. If anything, a C compiler could always insert an "if" in a non-standard arch on every signed addition to get it to overflow the "right way". The thing is that it would ruin performance. And the proof is that Java, which was quite imperative, doesn't have nearly as much undefined behavior as C.
- wyager 10y ago
  > Java, which was quite imperative, doesn't have nearly as much undefined behavior as C. You're right, but Java is still orders of magnitude less predictable than Haskell. A few good links here. http://stackoverflow.com/questions/376338/what-are-the-common-undefined-behaviours-that-java-programmers-should-know-about http://stackoverflow.com/questions/376338/what-are-the-commo... It essentially boils down to a combination of unsound type systems and underspecified semantics. Java was not created on a sound theoretical basis - it's quite ad-hoc.