4 ms·
I don't think so. Pattern matching and the like are just window dressing. The two true distinguishing features of Haskell are that it's lazy, and the compiler e
by mumblemumble 7y ago
I don't think so. Pattern matching and the like are just window dressing. The two true distinguishing features of Haskell are that it's lazy, and the compiler enforces referential transparency. Neither of those is something you can get by simply adding features to an existing language.
And, if you aren't working within those strictures, you're still just not even in the same universe. No matter how many variables you make immutable, you'll still be able to log events by just executing a log statement, and you'll still be able to create a function that talks to a remote service, and call it from anywhere. So, you might use a few functional-inspired features when they're convenient, but the actual structure of your program is probably still imperative to the core.
- cultus 7y agoHaskell still doesn't have real referential transparency. It's all a matter of degrees and no language is pure, even Agda or Coq. The concept of IO as a world state you pass around is deeply flawed, especially with multiple cores. You cannot be in control of the world, so you don't really have equational reasoning. At any rate, there can be unsafePerformIOs lurking anywhere. I really think delimited-continuation based algebraic effects are the way to go.
- damnyou 7y agoIt turns out that that "window dressing" is by far the most practically useful part of functional languages.
- mumblemumble 7y agoI keep wondering what it would be like to work in a language that gave some compiler support for ensuring that functions remain mostly pure. Like, perhaps mutating variables that are visible outside the function or getting input from external sources are disallowed, but logging and writing debug output are still permitted.
- cylon13 7y agoHaskell is like that with System.IO.Unsafe and Debug.Trace.
- sweeneyrod 7y agoBy this standard OCaml and Lisp aren't functional either.
- mumblemumble 7y agoI wasn't intending to imply that they aren't. The standard being proposed when I originally wrote my comment was just "Haskell"; I think the "ocaml, etc" was a later edit.