Why I Prefer Functional Programming

>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. You can trigger a deadlock in the database from within your pure haskell code if you wanted to.

It's not a philosophical thing. You absolutely have to consider imperative side effects even in your pure program.

That is reality. The philosophical part is whether you can call it "pure" or "impure."

>If you want to think that sqlString is “impure” outside of the context of execution (i.o.w. a Monad...) then sure, that’s valid, but so is my assertion that it is pure since it is referentially transparent. It exists in the void as just another string until the programmer decides to make it into an IO value that’s executed for its impure side effects (the only reason we do anything in computing, right?)

Yeah so? I never said your assertion was wrong. I never said that it was "impure." But I did say that you have to account for side effects in your program. Example:

   sqlString = "SELECT * FROM ASKDLSADSA DFLDSJFL DLSKFJSDLKFD SDLFKSDJF DSLKFJSDF SDFKLSDFJ "

Is a valid "pure" string, but will trigger a syntax error in your database. You have to account for all of this within your "pure" program. Haskell eliminates side effects in the category Hask but does not actually eliminate the need for YOU to deal with those side effects. This part is an objective fact.

Here's a better way to put it. For this specific example, the impurity of the real world leaks into your pure haskell program by affecting the contents of the string. The type itself can be seperate from the real world but the contents of the string reflects knowledge and impurity from the real world.

Is time better? My experience with Haskell went like this.

1. Interested in Haskell. Learn the language, read papers, enjoy the PL concepts and interesting academic work.

2. Does it scale? Implement small program in in C++ and Haskell. Optimize as best I can. Talk to people who work on ghc who happen to be in my lab. Further optimize. Everybody agrees, no further clear way to optimize the Haskell program.

C++ implementation remains several orders of magnitude faster.

If it were a time and space trade off, laziness would lead to good performance. But it doesn’t. It tends to produce stupendously bad cache behavior.

Haskell is a lovely platform for understanding some recent PL theory. It is possible to write the sort of obviously correct programs that make it so desirable.

It isn’t resource efficient. Worse, laziness means that performance tends to be chaotic. Small seemingly unrelated changes can change the execution order and change your profile a lot. Similar challenges exist in logical programming.

>Not all aspects of programming can be described by math.

This is completely untrue. You may not be familiar with the math, but that doesn't mean it doesn't exist. If you can model something well enough to understand it, then you can model it mathematically. There really isn't any domain of knowledge that math is unsuitable for, excepting if you don't know any relevant math to do.

Technically everything in the universe can be modelled by math. If it isn't modelled yet we can make something up to model it. Math is just axioms and theorems so yeah, you're not wrong.

I'm speaking in less technical terms. For example in general mathematical equations or axioms represent immutable concepts. In programming, variables mutate and change... very different from what math traditionally represents. Haskell is an attempt to segregate the immutability (the math part) away from the less "mathy" part (the mutations/IO).

Maybe math is too broad of a term. I probably meant to say "algebra" can't model all of programming, or whatever more suitable word that may or may not exist.

>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 algebraic, some are not. There is nothing wrong with modelling mutability using immutable structures: that is how you probably think about history, after all.

You can model change with purity but the program in the end actually has to conduct the change without the modelling. The application has to eventually perform real world actions and the purity of your program cannot protect you from potentials pitfalls of imperative style errors/mistakes.

You have a database. The purity of haskell does not remove the necessity of mutating data in that database.

What you can do is segregate dealing with mutation/IO to a framework or external service. This is what haskell does, but you see this is just shifting the problem to somewhere else. Someone somewhere still had to deal with the issue of mutation. Modelling mutation with purity does not eliminate the problem it only moves the problem to another location.

Segregation of mutation/IO into a framework is a good thing. It makes it so that the problem can be solved one time, rather then a problem solved many times. However the main point of my post is to say that "math" or "algebra" is not a one size fits all solution. You cannot model everything this way, moving the problem into a framework does not make the problem disappear. Someone still had to use imperative primitives to deal with the issue. Think about the complexity of a SQL database.