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

41–50 of 129 posts

Re: Why I Prefer Functional Programming

#41

Post by mattmanser »

bachmeier wrote: post #24

Requiring a functional programming approach when you teach makes your life much easier. I teach a computationally-intensive course for advanced economics PhD students. These days I have them think carefully through their problem, set up a recursion, and make one call to reduce. The vast majority of problems fit into this framework. I no longer have to work my way through 500-line monsters that look like entries in an…

You can do this in any language, functional or not. Every language has recursion, every language has a simple one liner way to do reduce.

They have generally had them for over a decade now.

I don't know if it's the case any more as I mainly work alone, but I often saw new programmers had been taught about recursion, but didn't actually understand it. So they never used the concept until you pointed it out, even if it could vastly simplify their code.

Re: Why I Prefer Functional Programming

#42

Post by spekcular »

marcosdumay wrote: post #20
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…

Probability has surely morphed into an algebra, and what you study in modern introductory books is the conversion of the algebra into "everyday language" so that students don't get scared. It has very little similarity to what probability looked like when it was being developed. Also, you seem to be overstating the maturity of PDE (people are pretty much still trying to turn it into algebra, but it may not be possibl…

On what basis do you say that probability has "morphed into an algebra"? Consider all of the popular research topics today: the KPZ equation, Schramm-Loewner evolution, spin glasses, percolation and critical phenomena, rigorous statistical mechanics in general [1], random matrix theory, large deviations, stochastic analysis and (P)SDEs.

Obviously, I'm forgetting some, but none of these are primarily algebraic. Some algebraic methods are used (orthogonal polynomials in random matrix theory, and determinants and a whole host of other things to study integrable models in the KPZ universality class, etc.), but clearly groups/rings/fields are not playing a major role.

For a more systematic approach you could look at recent issues of Annals of Probability, Annals of Applied Probability, and similar journals. There's not going to be a lot of "modern algebra" (of the flavor you see in algebraic geometry) there.

The same comments apply to PDE and analytic number theory. Both are obviously mature fields (worked on for a long time by many people, with a lot of great discoveries), but again algebra does not play a central role in either. In particular I am not aware of any PDE specialists whose research agenda consists of "trying to turn it into algebra."

[1]: https://www.unige.ch/math/folks/velenik/smbook/

Re: Why I Prefer Functional Programming

#43

Post by willtim »

mattmanser wrote: post #41
bachmeier wrote: post #24

Requiring a functional programming approach when you teach makes your life much easier. I teach a computationally-intensive course for advanced economics PhD students. These days I have them think carefully through their problem, set up a recursion, and make one call to reduce. The vast majority of problems fit into this framework. I no longer have to work my way through 500-line monsters that look like entries in an…

You can do this in any language, functional or not. Every language has recursion, every language has a simple one liner way to do reduce. They have generally had them for over a decade now. I don't know if it's the case any more as I mainly work alone, but I often saw new programmers had been taught about recursion, but didn't actually understand it. So they never used the concept until you pointed it out, even if it…

> You can do this in any language, functional or not.

No, not in practice. For example, in an average imperative language, you'd have no tail-call optimisation, and so would run out of stack space pretty quickly. There'd also be no persistent collections, meaning you'd have to keep copying any sets of values for every recursive call with absymal complexity. And so on...

Re: Why I Prefer Functional Programming

#44

Post by jolux »

platinumrad wrote: post #33
jgilias wrote: post #25

Earlier quoted context omitted.

Yeah, but Rust isn't exactly a counter example, I think. It's heavily inspired by Haskell, its type system, as well as FP in general. So, it sort of inherits (pun not intended) its parallelization capabilities from that.

What? No. Rust has some influence from Haskell in terms of traits and such, but Rust's parallelization capabilities comes from its tracking of mutability. (No, Haskell did not invent caring about mutability.) Also, succinct expression of parallel algorithms isn't a particularly unique feature. Like half of the named algorithms in the C++ standard library can be parallelized by adding a single parameter.

That’s because the parallelization in the STL is encapsulated. In Haskell and Rust it’s explicit, it’s not just about adding a parameter to an existing function, it’s a general mechanism.

Re: Why I Prefer Functional Programming

#45

Post by ufo »

quickthrower2 wrote: post #39
caryd wrote: post #32

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

And also what is an 'object'? Haskell has a decent system for building up complex data structures. You can write functions for those. Those data structures + those functions are kind of "an object" from the OO world (data + methods). The differences are: * Inheritance - well Haskell has many kinds of polymorphism so it doesn't need it. * Hiding data - well Haskell can hide data using smart constructors, you don't nee…

> Those data structures + those functions are kind of "an object"

And in this setting, the type of that datastructure containing the functions can act as an interface.

A trap that OO programmers sometimes fall into with Haskell is to try to emulate OO interfaces using existential types + typeclass interfaces but that is a bit of an antipattern.

Re: Why I Prefer Functional Programming

#46

Post by platinumrad »

jolux wrote: post #44
platinumrad wrote: post #33

Earlier quoted context omitted.

What? No. Rust has some influence from Haskell in terms of traits and such, but Rust's parallelization capabilities comes from its tracking of mutability. (No, Haskell did not invent caring about mutability.) Also, succinct expression of parallel algorithms isn't a particularly unique feature. Like half of the named algorithms in the C++ standard library can be parallelized by adding a single parameter.

That’s because the parallelization in the STL is encapsulated. In Haskell and Rust it’s explicit, it’s not just about adding a parameter to an existing function, it’s a general mechanism.

Rayon literally works on iterators just like the C++ algorithm library.

Re: Why I Prefer Functional Programming

#47

Post by nendroid »

anon_d wrote: post #35
nendroid wrote: post #29

I disagree with the higher order functions thing. Writing functions that receive other functions as input can lead to over complicated code that's really hard to read. It's literally the same thing as dependency injection just with functions instead of objects. Use sparingly. I would avoid altogether except for common ones like map, reduce and filter. Functional programming promotes the idea of composition of morphis…

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 product types are standard and easy to reason about.

However an exponential type that takes in an exponential type and returns another exponential type leads to cardinalities and possibilities that are much harder to reason about.

Composition of combinators is a pattern promoted by point free programming that leads not only to higher readability but greater modularity due to the reduced cardinality. Additionally cardinality of the entire type can he reduced to only analyzing the the final result of the composition.

  F = A . B . C
The cardinality of F is all that needs to be known. The cardinality of the individual components can be ignored and you don't have to reason about this. This is not the case for higher order functions.

In general business problems that we deal with do not Require higher order functions. Higher order functions share isomorphisms with two concepts we are already familiar with: frameworks and metaprogramming.

Frameworks are programs that call your code and metaprogramming is code that writes and calls code. These things are no different then a function that takes another function in as a parameter and calls it. All three concepts are aspects of the same thing.

Therefore all the downsides of metaprogramming and all the downsides of frameworks are applicable to higher order functions.

Most of the programming problems we solve in the real world do not require metaprogramming. It can easily be avoided and solved with much more composition of combinators. Again, not saying to avoid the usage completely but the usage of higher order functions like metaprogramming should be minimal and used sparingly.

Re: Why I Prefer Functional Programming

#48

Post by centimeter »

darksaints wrote: post #27
jgilias wrote: post #25

Earlier quoted context omitted.

Yeah, but Rust isn't exactly a counter example, I think. It's heavily inspired by Haskell, its type system, as well as FP in general. So, it sort of inherits (pun not intended) its parallelization capabilities from that.

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 inspired by ML"?

Re: Why I Prefer Functional Programming

#50

Post by jgilias »

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…

After reading some of these comments I went around searching for info and found that in the Rust book it does feature SML and OCaml prominently as influences[0].

However, the things mentioned: algebraic data types, type inference, pattern matching could also easily be seen as influences from Haskell or FP languages in general.

At the end of the day though, it's not like this matters. I'm just happy that such flow of ideas happens, irrespective of where exactly each particular concept comes from.

[0] https://doc.rust-lang.org/reference/influences.html

Post reply on HN