Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

Girl ♥ Haskell

Name: The Haskell Programming Girl 2012-06-23 6:37

Haskell and I have a lot in common: we are both advanced, purely-functional, and open-sourced; we both have twenty years of cutting-edge research experience, can develop robust, concise, correct software rapidly; we both have strong support for integration with others; we both have built-in concurrency and parallelism; we are both great debuggers and profilers; we both love our rich libraries and our active community; we both produce flexible, maintainable, high-quality software.

My love for Haskell is an infinite and uncountable monad, a Cartesian closed category if you will. If you lack the sophistication to appreciate my immutable passion, you can D.I.A.F.

http://girlloveshaskell.com/

Name: Anonymous 2012-06-23 8:21

I dislike so-called “functional programming”. Not only is imperative programming a strict superset of it, but it also is much more powerful and flexible.
A common fallacy says they are equivalent. Altough the machine (be it virtual or not) on which an imperative program runs can easily be viewed as a purely functional tail-recursive interpretation function, it doesn't mean they are equivalent, because your program is not the machine and only imperative programming gives you full access to the parameters of that function. In effect, this means that functional programming can't do, for instance, hash tables efficiently. Monads are meant to solve this, but there's a big price to pay: your program becomes a lot more complex and slow.
What about another frequent argument, is functional programming really easier to manage? Referential transparency is a good thing but in some cases it can be better to break that convention and imperative style allows you to do it very cleanly without cluttering your code with monads. Another advantage of imperative programming is that it easily allows you to encapsulate an impure but referentially transparent function and this is something sole functional programming can't provide without kludges.
Advances in optimisation technology are progressively making functional programs faster, but I don't want to use a lower-level language without any performance or consistency gain. Purely functional programming is a crippled technique and just not worth it.

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List