Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I Prefer Functional Programming

haskellforall.com

Post reply on HN
Print view View original

61–70 of 129 posts

Re: Why I Prefer Functional Programming

#61

Post by Twisol »

nendroid wrote: post #47
anon_d wrote: post #35

Earlier quoted context omitted.

Writing functions that receive other functions as input can lead to over complicated code that's really hard to read. I work in FP languages, and I find this type of code extremely intuitive and easy to understand. I suspect that you are just not used to thinking this way, and that with more familiarity, you would not have this opinion.

So you like writing functions that take 3 functions as input parameters and returns a new function that also takes a function as an input parameter and returns another function? In general excessive use of this at great depth leads to code that is not only less readable but less modular. The complexity of higher order functions can easily be reasoned about by looking at the cardinality of the type. Sum types and prod…

> In general business problems that we deal with do not Require higher order functions.

I cannot agree here, being currently involved in modeling and simulation work that would heavily benefit from more advanced type systems. A user would usually prefer to interact with a system with basic elements, but the interactions of the underlying domain concepts really do want to be captured with a richer set of tools.

And, to head off the "in general", there is a long tail of unique problem domains. Each individually doesn't get as much press as, say, a CRUD app, but that doesn't mean that simpler problem domains are necessarily in the majority.

Re: Why I Prefer Functional Programming

#62

Post by dudul »

loxs wrote: post #10

I agree to a great extent with the article, except for the dislike for mutability. I used to be like this (dislike it), then I found Rust. Now I prefer imperative, eager computation with (safe) mutability and even some lightweight OOP (the way Rust does it with Traits/Type-classes). It seems that it much better reflects the real world. Rust makes the mutability concerns obsolete, as you can have safety in the imperat…

Immutability is not about safety (not only i guess). It is about having code that is easier to reason about.

Re: Why I Prefer Functional Programming

#63

Post by YeGoblynQueenne »

marcosdumay wrote: post #4
karmakaze wrote: post #3

I like FP's other "timeless" feature, you can think of the operations without respect to time, there isn't a sequence of operations, it's just a relation between the input and output. It may be described sequentially in parts but there is no mixing of output with input so can be thought of happening instantaneously. This is also the same reason why I like SQL, it describes properties of the result set--if your thinki…

Haskell is famous for having problems with space leaks, where the runtime just refuses to evaluate your code and keeps storing more of it to run later. It's not usually a problem because people will teach you how to avoid most of it on any introductory text (usually, it's not hard), but if no care is taken, it will happen. To go into another timeless paradigm, logical programming is famous for unexpected exponential…

>> To go into another timeless paradigm, logical programming is famous for unexpected exponential execution times.

I have never heard of those famous "unexpected exponential times" in logic (not "logical") programming. Could you please give an example of what you mean?

I'm also not sure what you mean by "this or ensuring the type system detects determinism". What logic programming languages with a type system do you mean? Why would a type system be required to detect determinism?

Re: Why I Prefer Functional Programming

#64

Post by discreteevent »

carapace wrote: post #14
Syzygies wrote: post #8

Functional programming appeals to many of us for reasons other than these practical considerations: Functional programming feels like reasoning in algebra. As in Modern Algebra for math majors (groups, rings, fields) and beyond. There's a saying in mathematics that when any field matures it turns into algebra. Life crossed a threshold from chemistry to biology on Earth, and developed exponentially from there. Order i…

Backus emphasized the algebra of programs in his Turing Award lecture: "Can Programming Be Liberated From the von Neumann Style? A Functional Style and its Algebra of Programs" https://amturing.acm.org/award_winners/backus_0703524.cfm https://dl.acm.org/doi/10.1145/359576.359579

Backus: Well, because the fundamental paradigm did not include a way of dealing with real time. It was a way of saying how to transform this thing into that thing, but there was no element of time involved, and that was where it got hung up.

Booch: That’s a problem you wrestled with for literally years.

Backus: Yeah, and unsuccessfully.

http://archive.computerhistory.org/resources/access/text/201...

Re: Why I Prefer Functional Programming

#65

Post by darksaints »

centimeter wrote: post #48
darksaints wrote: post #27

Earlier quoted context omitted.

Heavily? It's actually heavily inspired by ML (SML/OCaml), not Haskell. Most of its functional programming attributes originated in SML, and has avoided most of the things that make Haskell unique. Really it is just type classes that came from Haskell.

I was around in the very early days of rust, and it was explicitly stated in many places in the docs that the trait system, ADTs, etc. were all inspired by Haskell experience. I don't think we ever mentioned OCaml or SML. The trait system in Rust has nothing whatsoever to do with SML or OCaml and everything to do with Haskell's typeclass system. So between that and ADTs, on what grounds do you think it was "heavily i…

I too was around in the very early days ...at least early enough that there wasn't a rust "team", but rather just Graydon.

And to wit the only mentions I read about Haskell as an influence were a) the trait system, and b) to criticize and explicitly refute the Haskell approach to a given problem. There was a reason Graydon wrote the compiler on OCaml and not Haskell. He was very critical of a lot of the ideas that Haskell brought. In particular, he hated how Haskell took mutability from "not the default" to "practically impossible". He hated the effect system and how overly intrusive it was (although he was open to the idea of a fine grained effect system that was not tied to some all powerful Monad typeclass). He hated lazy evaluation. He hated the syntax...even the convention toward snake-case vs camel-case is an homage to OCaml. He didn't even care much for typeclasses, preferring the more strict encapsulation of modules, and only bringing them in after a lot of contributors pushed for them.

Basically, apart from typeclasses (which werent really unique to Haskell, as they had been known as interfaces within OOP for a few years), Graydon viewed Haskell quite a bit like an old atheistic refrain about religion: that which is good about it is not unique, and that which is unique about it is not good.

BTW, Rust's ADTs as well as Haskell's ADT's came from ML. They've been around since 1973, 13 year before Miranda, and 17 years before Haskell's first release. You don't get to claim that Rust got it's ADTs from Haskell any more than you get to say that Java got it's Optionals from Scala.

EDIT: see this comment from Graydon himself, made about a year ago on the rust subreddit:

> That said: back then Rust was much more OCaml-y. We did not start with traits / typeclasses; we started with modules (for a while: first-class, though quite badly broken due to my lack of knowhow). I was and am unapologetically more of an OCaml fan than a Haskell fan. This opinion is not made from a lack of information about either, and I am not especially interested in having a Haskell-vs-OCaml argument here. I don't even think of them as being especially different languages from a family-lineage perspective. But insofar as I think eager is a better default evaluation strategy than lazy, and modules are a better abstraction mechanism than typeclasses, I am more in the OCaml camp. Other folks later in Rust's development argued for (and eventually won) the typeclasses / traits thing, against my earlier preferences.

Re: Why I Prefer Functional Programming

#66

Post by ratww »

LockAndLol wrote: post #49

I'm sure it has its problem domains, but does FP work well when interfacing with non-FP languages? Is that where monads / imperative language wrappers come in?

I did a lot of stuff with F# and C# together. Calling FP from imperative is nothing special. Calling imperative from FP only requires external purity in the imperative functions (if you want FP to remain pure, of course). Not different from using pure functions in an imperative language.

Monads... they're just a way of remaining pure (meaning immutable) but still doing imperative-ish stuff. You don't need monads to make software: both pure-FP and imperative languages can be Turing-complete, so you can do it all. For doing IO you can just use an imperative shell [1], that "calls" the main function of your pure-FP program (aka: a runtime).

Monads for IO make it easier to communicate with this "imperative shell" while still remaining pure. It communicates with it by requiring you to return an IO object all the way to your main function.

But Monads can also be used for other things that don't need IO, like "internal mutable state", "maybe monad" or even for simulating an exception system. Those don't require you returning anything.

Monads are nothing special for real... but you have to use to understand them, since most explanations just make it harder to understand, so I won't attempt one.

[1] https://www.destroyallsoftware.com/screencasts/catalog/funct...

Re: Why I Prefer Functional Programming

#67

Post by amw-zero »

karmakaze wrote: post #3

I like FP's other "timeless" feature, you can think of the operations without respect to time, there isn't a sequence of operations, it's just a relation between the input and output. It may be described sequentially in parts but there is no mixing of output with input so can be thought of happening instantaneously. This is also the same reason why I like SQL, it describes properties of the result set--if your thinki…

This mapping of inputs to outputs is only superficial and hides that fact that computation is inherently “sequential” as you say. That’s why the even lambda calculus requires reductions.

Of course I prefer writing in a functional style, because pure functions are just simpler. But all of computation can’t be reduced to just pure functions, which is why even Haskell has to call out to its runtime eventually.

Re: Why I Prefer Functional Programming

#68

Post by jariel »

josephcsible wrote: post #37
caryd wrote: post #32

I think it all comes down to one question, do you need objects or not?

What functionality can you only get with objects, and not with anything that is part of the FP paradigm?

For things that naturally have complex statefulness ... like User Interfaces.

HTML DOM as a crude example, is a big 'tree of state' whereupon OO would lend well to the nature of the noes on that tree for example.

When you're crunching data and the entire process is literally some kind of transform FP I think more intuitively maps to the situation.

On the DB side, there is a niche of OODBs that exist and used particularly in networking because the persisted state there is really topological, in which case it doesn't always lend well to RDBMS.

Re: Why I Prefer Functional Programming

#69

Post by dragonwriter »

amw-zero wrote: post #67
karmakaze wrote: post #3

I like FP's other "timeless" feature, you can think of the operations without respect to time, there isn't a sequence of operations, it's just a relation between the input and output. It may be described sequentially in parts but there is no mixing of output with input so can be thought of happening instantaneously. This is also the same reason why I like SQL, it describes properties of the result set--if your thinki…

This mapping of inputs to outputs is only superficial and hides that fact that computation is inherently “sequential” as you say. That’s why the even lambda calculus requires reductions. Of course I prefer writing in a functional style, because pure functions are just simpler. But all of computation can’t be reduced to just pure functions, which is why even Haskell has to call out to its runtime eventually.

> But all of computation can’t be reduced to just pure functions, which is why even Haskell has to call out to its runtime eventually.

All of computation provably can, but not everything computers do, despite the name, is computation.

Re: Why I Prefer Functional Programming

#70

Post by spekcular »

Twisol wrote: post #52
spekcular wrote: post #18

Earlier quoted context omitted.

> There's a saying in mathematics that when any field matures it turns into algebra. Life crossed a threshold from chemistry to biology on Earth, and developed exponentially from there. Order in mathematics crosses a similar threshold, as it becomes sufficiently structured to support algebraic reasoning. The subjective experience is like ice melting into a churning liquid, or a land-locked creature learning to fly. O…

> Second, and more substantively, it is not the case that mathematical fields inevitably turn into algebra. Not to fully justify the OP (though it rings both true and not quite true to me), but I think topology is a good positive example. It's impressive how much of continuity can be captured purely algebraically. For example, topologies are a kind of lattice, which cross both algebra and order theory. And then you g…

Certainly, algebraic topology is a huge win for algebraization!

> Yes, parallelizing a program is about making it run faster; but parallelism is also a base fact of many problem domains, where you have multiple agents (up to and including humans) collaborating and interacting simultaneously.

Maybe I should say what I meant more clearly. The claim "one can achieve a 7x speedup on 8 cores by adding a handful of lines to a program" implicitly has a "and this is good because being fast is good" at the end. Why care about a speedup if you don't care about speed in the first place?

It follows that when evaluating a language's ability to gain speed through parallelization, we should also evaluate how fast that language is in the first place. If you can get a 7x speedup on 8 cores from a few lines of code, but the original algorithm is, say, 10x slower than a similar implementation in C/Rust/Go on one core, then who cares? The ultimate criterion is always absolute speed, not relative improvement.

I agree that being able to deal with concurrency is important, but as the Go people always remind me, concurrency and parallelism are distinct concepts.

Post reply on HN