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

81–90 of 129 posts

Re: Why I Prefer Functional Programming

#81

Post by nimish »

nendroid wrote: post #56
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…

Not all aspects of programming can be described by math. Mutations and IO are very critical parts of programming and the two areas where FP breaks down. Even the IO Monad leaks the imperative nature of the program over to the programmer. The only way pure FP can sort of work is if there are heavy frameworks abstracting IO and mutation away from the programmer. If you're not doing IO or mutating something then your ca…

The io monad is fully pure.

The interpretation of the io monad? That's another story.

Once you realize that mutation itself is a side effect then why not use the single most powerful idiom we have for abstraction over side effects? (Monads with do notation; for blocks in f#)

For the record io is st with an opaque realworld type. And st is fully pure with a neat type trick to prevent leaking of st references.

Re: Why I Prefer Functional Programming

#82

Post by hobby-coder-guy »

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…

Why isn’t anything of value actually made in Haskell if it is so much better?

Re: Why I Prefer Functional Programming

#83

Post by nendroid »

nimish wrote: post #81
nendroid wrote: post #56

Earlier quoted context omitted.

Not all aspects of programming can be described by math. Mutations and IO are very critical parts of programming and the two areas where FP breaks down. Even the IO Monad leaks the imperative nature of the program over to the programmer. The only way pure FP can sort of work is if there are heavy frameworks abstracting IO and mutation away from the programmer. If you're not doing IO or mutating something then your ca…

The io monad is fully pure. The interpretation of the io monad? That's another story. Once you realize that mutation itself is a side effect then why not use the single most powerful idiom we have for abstraction over side effects? (Monads with do notation; for blocks in f#) For the record io is st with an opaque realworld type. And st is fully pure with a neat type trick to prevent leaking of st references.

I never said it's not pure. Just like how a SQL string in haskell is fully pure. Doesn't change the fact that you're using pure primitives to control a process that is fundamentally unpure. The concept leaks across the boundary.

Re: Why I Prefer Functional Programming

#84

Post by nimish »

nendroid wrote: post #83
nimish wrote: post #81

Earlier quoted context omitted.

The io monad is fully pure. The interpretation of the io monad? That's another story. Once you realize that mutation itself is a side effect then why not use the single most powerful idiom we have for abstraction over side effects? (Monads with do notation; for blocks in f#) For the record io is st with an opaque realworld type. And st is fully pure with a neat type trick to prevent leaking of st references.

I never said it's not pure. Just like how a SQL string in haskell is fully pure. Doesn't change the fact that you're using pure primitives to control a process that is fundamentally unpure. The concept leaks across the boundary.

It doesn't. That's the whole point of the io monad.

Outside of the io monad you cannot (modulo some exceptions) indicate io.

Re: Why I Prefer Functional Programming

#85

Post by nendroid »

nimish wrote: post #84
nendroid wrote: post #83

Earlier quoted context omitted.

I never said it's not pure. Just like how a SQL string in haskell is fully pure. Doesn't change the fact that you're using pure primitives to control a process that is fundamentally unpure. The concept leaks across the boundary.

It doesn't. That's the whole point of the io monad. Outside of the io monad you cannot (modulo some exceptions) indicate io.

It does. You're completely and utterly wrong. You don't understand.

I'll reiterate my example a SQL string is pure. Just like the IO monad is pure. However when you're coding the sql string in your "pure" haskell program you have to account for imperative side effects related to the SQL itself.

   sqlString = "UPDATE X SET X.Y=2 WHERE X.Z = 1"
sqlString is technically "pure" but that doesn't mean you can treat the UPDATE command in the string as a pure concept.

It doesn't matter how "pure" your language or sqlString is... the concept of a mutation leaks over into the language and the programmer still has to deal with the concept.

Like you're original post said. The interpretation of the monad is different, and the programmer still needs to account for this in how he composes things together. The concept leaks across boundaries.

edit>>this whole karma thing is unfair. Posters can't vote down responses. I simply state my opinion the person responds then votes me down because he disagrees. What's the point of even having a discussion?

Re: Why I Prefer Functional Programming

#86

Post by lptk »

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…

> 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.

I don't think parallelism is the word for that. More like concurrency

Parallel computing is closely related to concurrent computing—they are frequently used together, and often conflated, though the two are distinct: it is possible to have parallelism without concurrency (such as bit-level parallelism), and concurrency without parallelism (such as multitasking by time-sharing on a single-core CPU).[5][6] In parallel computing, a computational task is typically broken down into several, often many, very similar sub-tasks that can be processed independently and whose results are combined afterwards, upon completion. In contrast, in concurrent computing, the various processes often do not address related tasks; when they do, as is typical in distributed computing, the separate tasks may have a varied nature and often require some inter-process communication during execution.

https://en.wikipedia.org/wiki/Parallel_computing

What you're describing sounds like it would be solved by primitives such as the actor model, not by Haskell-style FP.

Re: Why I Prefer Functional Programming

#87

Post by lptk »

jgilias wrote: post #78
darksaints wrote: post #65

Earlier quoted context omitted.

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

(I'm not the person you were asking, but:)

The power of Haskell's type classes comes from two things:

* Implicit composition of instances: you can write `show [True, False]`, which will automatically/implicitly compose the `Show` instances of lists and booleans. With modules or interfaces, you'd have to build and use a "BoolListShow" manually.

* Higher-kinded types, to abstract over type constructors. This enables the use of abstractions like monads.

Rust only has the first of these two.

Scala uses OOP interfaces instead, but by augmenting them with both capabilities (implicit composition and higher-kinded types), it achieves the same expressiveness as Haskell.

Re: Why I Prefer Functional Programming

#88

Post by antonvs »

dudul wrote: post #60
caryd wrote: post #32

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

When do you need objects? What problem can you only solve with objects?

The problem of providing a language that people stuck in a traditionally object-oriented mindset are comfortable with.

Re: Why I Prefer Functional Programming

#89

Post by nerdtime »

nimish wrote: post #81
nendroid wrote: post #56

Earlier quoted context omitted.

Not all aspects of programming can be described by math. Mutations and IO are very critical parts of programming and the two areas where FP breaks down. Even the IO Monad leaks the imperative nature of the program over to the programmer. The only way pure FP can sort of work is if there are heavy frameworks abstracting IO and mutation away from the programmer. If you're not doing IO or mutating something then your ca…

The io monad is fully pure. The interpretation of the io monad? That's another story. Once you realize that mutation itself is a side effect then why not use the single most powerful idiom we have for abstraction over side effects? (Monads with do notation; for blocks in f#) For the record io is st with an opaque realworld type. And st is fully pure with a neat type trick to prevent leaking of st references.

He's not talking about that. You're ignorant.

Re: Why I Prefer Functional Programming

#90

Post by przemo_li »

twic wrote: post #57
WJW wrote: post #38

Earlier quoted context omitted.

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…

Meh. var colours = coordinates.stream().map(this::computeColour).collect(toList()); var colours = coordinates.stream().parallel().map(this::computeColour).collect(toList()); Java doesn't do as much (well, anything) to help you make sure the implementation of computeColour is suitable for parallelisation, but that comes with the territory. On the other hand, it will automatically split the stream up appropriately for…

You have just started that Java isn't as good but since it isn't, it shouldn't be judged so hardly and thus concluded that Java is as good as any (when using softer requirements just for Java)

I also think that explicit threadpool isn't the same thing as implicit one. But that's very minor issue here easily solvable by different api for parallel method

Post reply on HN