4 ms·
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
by 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.