Why I Prefer Functional Programming • Hacker News Board

Re: Why I Prefer Functional Programming

#101

Post by phizy » Mon, Nov 02, 2020, 7:12 PM UTC

nerdtime wrote: post #100

phizy wrote: post #99

Earlier quoted context omitted.

Mathematicians have no trouble modeling change. There are many ways to do so. Some are algebraic, some are not. There is nothing wrong with modelling mutability using immutable structures: that is how you probably think about history, after all. Either way, it is unclear what you're actually trying to say. Haskell has methods for modelling change of state through pure objects, but you're talking about that as though…

>but you're talking about that as though it were an inherently flawed or invalid approach, This is just your bias. I never said this. I feel some people worship a paradigm so much that they see everything as an attack. FP is great however it is not a one size fits all solution. There are limitations. This is literally what I said. >Mathematicians have no trouble modeling change. There are many ways to do so. Some are…

You said FP "breaks down" when handling mutability, and you attributed that to some vague sense in which "mathematics" is the cause of it.

I have no bias for FP. I just don't understand what you're getting at.

>the purity of haskell does not remove the necessity of mutating data in that database.

That's great, because the purity of Haskell does not inhibit mutability. It just constrains it to lie within some mutable context.

>Modelling mutation with purity does not eliminate the problem it only moves the problem to another location.

Location? What is a location? It's like you're saying you can't truly add 3 + 3, because someone still has to add 1s under the hood. It's just a different model of the same problem.

Honestly, it sounds to me like you've never used the language, and your criticisms come off a bit like standing on an aircraft carrier shouting about how iron boats will never float.

Re: Why I Prefer Functional Programming

#102

Post by AnimalMuppet » Mon, Nov 02, 2020, 7:33 PM UTC

przemo_li wrote: post #90

twic wrote: post #57

Earlier quoted context omitted.

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

Java's type safety in general is less than Haskell's. That's a separate topic from ease of parallelization in Java and Haskell.

Re: Why I Prefer Functional Programming

#103

Post by nerdtime » Mon, Nov 02, 2020, 7:46 PM UTC

phizy wrote: post #101

nerdtime wrote: post #100

Earlier quoted context omitted.

>but you're talking about that as though it were an inherently flawed or invalid approach, This is just your bias. I never said this. I feel some people worship a paradigm so much that they see everything as an attack. FP is great however it is not a one size fits all solution. There are limitations. This is literally what I said. >Mathematicians have no trouble modeling change. There are many ways to do so. Some are…

You said FP "breaks down" when handling mutability, and you attributed that to some vague sense in which "mathematics" is the cause of it. I have no bias for FP. I just don't understand what you're getting at. >the purity of haskell does not remove the necessity of mutating data in that database. That's great, because the purity of Haskell does not inhibit mutability. It just constrains it to lie within some mutable…

>That's great, because the purity of Haskell does not inhibit mutability. It just constrains it to lie within some mutable context.

Haskell does inhibit mutability within your haskell program. Your haskell program does not mutate. What it does is it that it does IO operations and the mutations happen externally. It can also model mutation without doing actual mutation but in the end there's no point in a program modelling mutation if the program can't actually do mutation or IO.

>Location? What is a location? It's like you're saying you can't truly add 3 + 3, because someone still has to add 1s under the hood. It's just a different model of the same problem.

Location meaning outside of haskell. Like your database. I'm saying within haskell you have a variable.

  x = 3

You can never mutate that variable in haskell. However you can mutate the state of the console without ever mutating any state within haskell.

    print "hello"

The above triggers no mutation in haskell. A runtime outside of the haskell universe analyzes the IO instructions and mutates the console. What I am saying is that the thing that mutates the console has to do mutation. Whoever wrote that thing HAS to write imperative primitives. They are moving the imperative nature of programming INTO a framework. They are not eliminating the problem.

This is the same thing as a database string. UPDATE. You are moving all the imperative errors that have to deal with threading and mutations to the database. But your haskell sql string is still pure.

Again my argument is just saying that this thing that is doing the UPDATE or mutating the console cannot be built using haskell style code or immutable algebraic concepts. Imperative primitives need to exist and someone needs to use those primitives to do the actual mutations.

The OP is basically saying algebra is the future and it can replace everything. I'm saying it CAN'T.

>Honestly, it sounds to me like you've never used the language, and your criticisms come off a bit like standing on an aircraft carrier shouting about how iron boats will never float.

And honestly you sound like the guy standing on the iron boat. The person I'm shouting at is you, but you're just dismissing me.

Re: Why I Prefer Functional Programming

#104

Post by AnimalMuppet » Mon, Nov 02, 2020, 7:55 PM UTC

nendroid wrote: post #92

nimish wrote: post #91

Earlier quoted context omitted.

You can make your point without the theatrics. This is a philosophical distinction, not an objective fact. I do not consider sqlString to be impure. It’s a perfectly valid string. I consider `executeQuery sqlString :: IO Result` to be an indication of impurity, since I can do `let x = executeQuery sqlString in “bar”` as a valid bit of Haskell but it’s clearly 100% pure. If you want to think that sqlString is “impure”…

>I think you’re getting downvoted (I can’t) because of your first statement. nobody is reading this stuff anymore. It's just you and me. You have over 800 karma. You CAN downvote and you ARE. There is no theatrics, you're just voting me down, stop. >I do not consider sqlString to be impure. It's not "impure." But it doesn't change the fact the way you you write your SQL has imperative side effects within the database…

I have over 14,000 karma. I can't downvote (direct) replies to my posts. So as far as HN mechanics go, you are falsely accusing nimish.

Other people - not nimish - are downvoting you. And they're doing so because you're starting to cross the line from "disagreeing" to "aggressive and rude".

Now for what it's worth, I'm kind of on your side of the actual dispute. I just think you're pushing the line in trying to be more, um, "expressive".

Re: Why I Prefer Functional Programming

#105

Post by phizy » Mon, Nov 02, 2020, 8:21 PM UTC

nerdtime wrote: post #103

phizy wrote: post #101

Earlier quoted context omitted.

You said FP "breaks down" when handling mutability, and you attributed that to some vague sense in which "mathematics" is the cause of it. I have no bias for FP. I just don't understand what you're getting at. >the purity of haskell does not remove the necessity of mutating data in that database. That's great, because the purity of Haskell does not inhibit mutability. It just constrains it to lie within some mutable…

>That's great, because the purity of Haskell does not inhibit mutability. It just constrains it to lie within some mutable context. Haskell does inhibit mutability within your haskell program. Your haskell program does not mutate. What it does is it that it does IO operations and the mutations happen externally. It can also model mutation without doing actual mutation but in the end there's no point in a program mode…

> Your haskell program does not mutate.

Then it doesn't work. Every Haskell program does nothing, because mutation of program state does not occur.

You're just trolling at this point. Please reconsider your confidence in this material, because you are egregiously mistaken.

Re: Why I Prefer Functional Programming

#106

Post by AnimalMuppet » Mon, Nov 02, 2020, 8:48 PM UTC

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.

If I have a "known" function, map() for instance, and I pass a function into it, that's fine, because I already know what map() does. But if I have a function foo() that takes another function bar(), and I don't know what either one does, then I have to look at both foo() and bar() to understand what is going on. I have to look at two places, not just one.

But this is not unique to FP. If I'm using OOP, I can do the same thing with virtual functions. In UI frameworks I can do the same thing with callbacks.

Frankly, I don't like it, whether it's FP or not.

Re: Why I Prefer Functional Programming

#107

Post by nerdtime » Mon, Nov 02, 2020, 9:30 PM UTC

phizy wrote: post #105

nerdtime wrote: post #103

Earlier quoted context omitted.

>That's great, because the purity of Haskell does not inhibit mutability. It just constrains it to lie within some mutable context. Haskell does inhibit mutability within your haskell program. Your haskell program does not mutate. What it does is it that it does IO operations and the mutations happen externally. It can also model mutation without doing actual mutation but in the end there's no point in a program mode…

> Your haskell program does not mutate. Then it doesn't work. Every Haskell program does nothing, because mutation of program state does not occur. You're just trolling at this point. Please reconsider your confidence in this material, because you are egregiously mistaken.

>You're just trolling at this point. Please reconsider your confidence in this material, because you are egregiously mistaken.

Why the heck would I run such a long expose and troll you and be mistaken at the same time.

>How does this Haskell program write to stdout if it doesn't mutate memory?

Let's not be stupid here. Every program on the face of the earth must mutate memory because that's how computers work. Assembly instructions mutate things. We're not even talking about that. We're talking about application level programming where we only deal with primitives that the application programmer is aware about. I am saying that at the application level within the category of Hask nothing is mutated.

In your example tell me what haskell primitive.... What variable or data was mutated within haskell? That is what I'm referring to.

Try to implement IO or ST in another lang using only purely functional primitives. Use your algebra to make it work. You'll find it's impossible. What this means is that imperative primitives must exist for any programming to work.

>Then it doesn't work. Every Haskell program does nothing, because mutation of program state does not occur.

Obviously I'm operating on a certain layer of abstraction here. In X = 6, X is obviously immutable in haskell. A runtime is obviously executing your haskell program and mutating the console but your haskell code itself is pure. But you know this. It's quite obvious you're the one that's trolling.

Re: Why I Prefer Functional Programming

#108

Post by nerdtime » Mon, Nov 02, 2020, 9:47 PM UTC

AnimalMuppet wrote: post #104

nendroid wrote: post #92

Earlier quoted context omitted.

>I think you’re getting downvoted (I can’t) because of your first statement. nobody is reading this stuff anymore. It's just you and me. You have over 800 karma. You CAN downvote and you ARE. There is no theatrics, you're just voting me down, stop. >I do not consider sqlString to be impure. It's not "impure." But it doesn't change the fact the way you you write your SQL has imperative side effects within the database…

I have over 14,000 karma. I can't downvote (direct) replies to my posts. So as far as HN mechanics go, you are falsely accusing nimish. Other people - not nimish - are downvoting you. And they're doing so because you're starting to cross the line from "disagreeing" to "aggressive and rude". Now for what it's worth, I'm kind of on your side of the actual dispute. I just think you're pushing the line in trying to be mo…

No it's not that. Even in posts where I just state logical reasons for disagreement I get voted down in this thread.

People vote down what they disagree with, if they agreed with me, most peoples' biases would usually find my attitude appropriate.

If I said something like logically I feel a certain race is inferior genetically. People will vote that statement down purely out of disagreement and misinterpret it as an emotionally charged statement and illogical.

It's just a statement with no logic behind it. It's dead pan with nothing. You can't even find erroneous logic with it because the logic wasn't even spelled out. You can only technically disagree with the statement. But people will subconsciously add all sorts of embellishment.

That's how people work. Maybe Nimish didn't vote me down, but they certainly aren't voting me down because I'm crossing some sort of line. They're voting me down because they disagree. That's the majority of it.

You'll find that more than anything the majority of what I write are just dead pan responses with like 5% of the sentences being "expressive." In fact a great number of stuff that I write that gets voted down is just dead pan responses with zero "expressiveness."

It's because people can't tell the difference between someone disagreeing with them and an actual attack. That's human nature. We all think we're above it, but basically none of us are. You'll find that even you are like this.

The reason why I get voted down is because my opinions tend to be different than most people. So people interpret this disagreement as an attack.

Re: Why I Prefer Functional Programming

#109

Post by AnimalMuppet » Mon, Nov 02, 2020, 9:55 PM UTC

nerdtime wrote: post #108

AnimalMuppet wrote: post #104

Earlier quoted context omitted.

I have over 14,000 karma. I can't downvote (direct) replies to my posts. So as far as HN mechanics go, you are falsely accusing nimish. Other people - not nimish - are downvoting you. And they're doing so because you're starting to cross the line from "disagreeing" to "aggressive and rude". Now for what it's worth, I'm kind of on your side of the actual dispute. I just think you're pushing the line in trying to be mo…

No it's not that. Even in posts where I just state logical reasons for disagreement I get voted down in this thread. People vote down what they disagree with, if they agreed with me, most peoples' biases would usually find my attitude appropriate. If I said something like logically I feel a certain race is inferior genetically. People will vote that statement down purely out of disagreement and misinterpret it as an…

I've been here for seven years. You've been here for a month (at least with these accounts). And you're telling me why you're getting downvoted.

I'm trying to help you. You're not listening.

Re: Why I Prefer Functional Programming

#110

Post by phizy » Mon, Nov 02, 2020, 9:56 PM UTC

nerdtime wrote: post #107

phizy wrote: post #105

Earlier quoted context omitted.

> Your haskell program does not mutate. Then it doesn't work. Every Haskell program does nothing, because mutation of program state does not occur. You're just trolling at this point. Please reconsider your confidence in this material, because you are egregiously mistaken.

>You're just trolling at this point. Please reconsider your confidence in this material, because you are egregiously mistaken. Why the heck would I run such a long expose and troll you and be mistaken at the same time. >How does this Haskell program write to stdout if it doesn't mutate memory? Let's not be stupid here. Every program on the face of the earth must mutate memory because that's how computers work. Assemb…

>What variable or data was mutated within haskell?

The stdout buffer.

Just because mutation isn't explicit doesn't mean it isn't there. Programming languages are not syntax devoid of meaning: they have semantics. What happens at runtime is part of what a programming language does. (Arguably, that is the most important part of what they do.)

>What this means is that imperative primitives must exist for any programming to work.

That's completely untrue. Imperative languages can be implemented as a subset of functional ones[1] and vice versa. Again, they're just different models. No language can do anything if it isn't implemented in a machine. A machine isn't "imperative"[2], it's a pile of atoms that do what atoms do, without paradigm or instruction. You absolutely could implement a pure functional assembly language. The reason nobody has, is because it doesn't matter: any Turing complete language can be used to implement any other language[3].

Try to implement `volatile` in C without using another language. Does that mean C fails to model real hardware? No, because it has `volatile` to get volatile semantics! Just like Haskell has IO to get I/O side-effects. Or ST to get mutation semantics.

> Use your algebra to make it work. You'll find it's impossible.

Don't assert it, Prove it. Show me one computable function that cannot be computed using boolean algebra.

[1] https://www.microsoft.com/en-us/research/wp-content/uploads/... [3] https://en.wikipedia.org/wiki/Lisp_machine [2] https://en.wikipedia.org/wiki/Turing_completeness