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

71–80 of 129 posts

Re: Why I Prefer Functional Programming

#71

Post by amw-zero »

dragonwriter wrote: post #69
amw-zero wrote: post #67

Earlier quoted context omitted.

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.

Computation cannot be reduced to simply functions, that’s why we need something like the lambda calculus to express computation. There are functions within the calculus, but to say that “computation is a function” is not correct.

Re: Why I Prefer Functional Programming

#72

Post by bitdizzy »

spekcular wrote: post #42
marcosdumay wrote: post #20

Earlier quoted context omitted.

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 a…

I know vaguely from a few friends that there is some cross pollination between algebraic geometry and PDE's but both fields are so huge that this doesn't characterize either field. I think the gist of it is that the moduli space of PDE solutions are frequently interesting as varieties.

There's this rare unclosed survey-like mathoverflow question that highlights some of these points: https://mathoverflow.net/questions/66046/which-nonlinear-pde...

Re: Why I Prefer Functional Programming

#73

Post by nendroid »

Twisol wrote: post #61
nendroid wrote: post #47

Earlier quoted context omitted.

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, t…

I refer to business problems but in reality what I said applies to all problems.

Re: Why I Prefer Functional Programming

#74

Post by joshsyn »

I prefer functional first languages that allows mutability where needed. Ocaml, F# and scala for me.

You have to go through great lengths to avoid mutability in Haskell, which is why they are developing linear types. I tried it for a few months was like nope.

Re: Why I Prefer Functional Programming

#75

Post by adwn »

kenjackson wrote: post #36
adwn wrote: post #22

Earlier quoted context omitted.

> In particular, a few years ago it seemed like the people implementing parallel Haskell features didn't understand or care about fundamental things like cache locality. That's the main issue which FP-for-parallel-execution proponents don't seem to get: Identifying independent (and therefore parallelisable) computations isn't the hard part, but planning the data layout and partitioning so that all your parallelism is…

I think it may be more accurate to say they are both hard problems. It is still open if P=NC.

That is misleading. Although you're technically correct [1], the computational models on which computational complexity classes are based are so abstract and idealized, that they offer almost no information whether your program could make efficient use of an actual, physical 8-core CPU.

The NC complexity class assumes a PRAM machine, in which all processors can access all locations of a central memory in constant time. That's not how a multi-core CPU works in practice: If your parallel algorithm doesn't make proper use of cache-locality, you've already lost.

[1] (the best kind of correct)

Re: Why I Prefer Functional Programming

#76

Post by jjav »

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…

> algebraic sense of wonder

I strongly identify with this view. Have always loved math. I remember writing a paper in middle school on how all of nature is built on math which ties closely with this quote "algebraic sense of wonder". My B.S. degree is in mathematics and I loved it.

And yet... I very strongly - no, extremely - dislike functional programming. When building concrete things, I love pragmatism above all else and to me functional is the diametrical opposite of that. A CPU has registers, instructions and addressable memory. Any abstraction that strays too far from that reality is a distraction (and maintenance burden) I don't want to deal with.

Re: Why I Prefer Functional Programming

#77

Post by loxs »

dudul wrote: post #62
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.

Yeah, with Rust lifetimes it's much easier to reason about, compared to eg Java. Also, in something like Haskell it's not that your data does not change. It does change and people employ really complex idioms to facilitate that. It might be "easy to reason about", but it's definitely not easy to grasp. Lots of people find it much easier to just mutate something (hence the popularity of imperative languages).

Rust takes best of both worlds. You can both mutate, and you are sure that this is compile-time guaranteed, so you can't just try to mess with a value that this part of the code does not own.

Re: Why I Prefer Functional Programming

#78

Post by jgilias »

darksaints wrote: post #65
centimeter wrote: post #48

Earlier quoted context omitted.

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 Ha…

Thanks a lot for the in-depth explanation! May I pick your brain a bit more on this topic?

1. Do you know what were the main arguments for and against using typeclasses vs modules for abstraction? It's interesting to read that traits wound up in the language against Graydon's preferences.

2. There's another commenter on this thread suggesting that 'Typeclasses are just OOP interfaces' who has gotten a bit downvoted. To me they seem kind of the same thing, yet at the same time there's this feeling that I'm overlooking something and typeclasses are likely 'so much more powerful'. I just can't figure out what that may be. So, are there any major differences between what interfaces are in OOP and what typeclasses/traits are?

Re: Why I Prefer Functional Programming

#80

Post by adwn »

WJW wrote: post #38
adwn wrote: post #23

Earlier quoted context omitted.

> To this day it has the best implementation of parallelism; one can achieve a 7x speedup on 8 cores by adding a handful of lines to a program. Eh, you can achieve the same in Rust using rayon, this isn't exclusive to Haskell or FP. Do you have an example in Haskell, where you get an effortless speedup which wouldn't be easy in another language?

From the article at https://medium.com/@s.nawaz/optimizing-ray-tracing-in-haskel... : > let colors = fmap computeColor coordinates to > let colors = fmap computeColor coordinates `using` parListChunk 32 rseq So half a line added to parallelize the mapping a pure computation including using a sensible threadpool implementation. How impressive you find this depends on how you define "easy in another language". Rayon co…

Ray-tracing is absolutely trivial to parallelize, because every pixel is computed independently of all others. That would even be trivial to parallelize in C, and that's saying a lot!
Post reply on HN