Why I Prefer Functional Programming
haskellforall.com
haskellforall.com
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. Once one has this experience, one cannot imagine thinking any other way. In the case of functional programming, programs written in other languages feel like ad hoc pre-civilization constructions, doing arithmetic by counting pebbles.
Advocates of Haskell don't tend to express this, because from the outside it can come off like trolling, but this algebraic sense of wonder is at the core of many Haskeller's experiences. We all have the example of Lisp in our minds, its "we found God" advocacy did much to hinder its adoption. Nevertheless, understanding this explains much about Haskell. The real point of lazy evaluation is that it best supports this algebraic reasoning, as carbon best supports life. The 47,000 compiler options reflect a primary goal of being a research bed for language constructs derived from mathematical category theory, despite its success as a practical language for those free to choose it.
The killer app for Haskell is parallelism. 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. This ease is a consequence of the functional model, and of considerable effort by Haskell's developers.
Idris 2 is itself a joy to learn, if one wants a smaller, cleaner Haskell without the 47,000 compiler options. One gets to learn dependent types. Alas, it doesn't offer commercial-grade parallelism.
It's funny, because I think this metaphor cuts exactly the opposite direction -- code reaching sufficient complexity, the pure math approach doesn't survive an encounter with the real world.
I love static analysis and think that there are core business domains that are best expressed with a rich type system, but there is a whole world of absolutely critical programming that cannot simply eliminate messiness, due to interfacing with humans and our flawed practices.
With sufficient time and an expressive enough type system, even the messiest business process can be represented, but I'm not convinced that's an example of beauty but rather stubbornness.
I understand what you're saying, but I don't think you'll find many programmers that will argue that a programmer shouldn't use the best tool for the job.
Booch: That’s a problem you wrestled with for literally years.
Backus: Yeah, and unsuccessfully.
http://archive.computerhistory.org/resources/access/text/201...
Functional Reactive Programming seems promising. (Elm ditched it in favor of some simpler metaphor on didactic rather than technical grounds, I think.)
> Idris 2 is itself a joy to learn, if one wants a smaller, cleaner Haskell without the 47,000 compiler options.
From a conceptual point of view, Idris makes Haskell look similarly crude.
Hi, this seems wrong to me.
First, as far as I can tell, such a saying does not exist. I've never heard it, despite having a fair amount of experience with mathematics (though not as much as you), and I can't find it through Googling.
Second, and more substantively, it is not the case that mathematical fields inevitably turn into algebra. One only has to look at PDE, probability, and analytic number theory to see this is the case (to give just a few examples). All are highly mature fields and essentially non-algebraic. This is not to say that ideas from algebra are not occasionally useful, just that it should be obvious to anyone who opens an introductory graduate text in PDE that the subject has not "turn[ed] into algebra."
> The killer app for Haskell is parallelism. 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. This ease is a consequence of the functional model, and of considerable effort by Haskell's developers.
I don't think this statement is entirely wrong, but I don't think it's entirely right either. There are plenty of languages where one can get parallelism with just a few extra lines of code; Julia comes to mind immediately. Easy parallelism is hardly a Haskell-specific, or even FP-specific, feature. I would of course agree that designing things without mutable state makes writing parallel code easier, but this can be done in many high-level languages these days.
But that is a nitpick. A more substantive objection is that the sole purpose of parallelism is performance, and idiomatic Haskell is generally speaking slower, sometimes a lot slower, than the same algorithm written in C++ or similar languages. (The adjective idiomatic is important here – I'm aware that one can with enough contortions write C-like code in Haskell, but this response undercuts of the point of highlighting Haskell-specific features like immutability, laziness, etc.) 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. Maybe this has changed?
There is also an amusing story about the "ease" of writing parallel quicksort in Haskell [1].
> The real point of lazy evaluation is that it best supports this algebraic reasoning, as carbon best supports life.
It's worth noting that Simon Peyton Jones is on record as saying that any "Haskell 2" should not be lazy [2].
[1] https://sudonull.com/post/75314-Parallel-quick-sort-on-Haske...
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 possible) and number theory (that's an active research area).
I have never seen that saying either, but it seems quite correct, with the exception of the areas where an algebra is impossible, so the field matures without becoming one.
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."
There's this rare unclosed survey-like mathoverflow question that highlights some of these points: https://mathoverflow.net/questions/66046/which-nonlinear-pde...
Julia is a multi-paradigm language, but it is heavily Erlang inspired (another multi-paradigm language, but primarily functional.)
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 isn't eaten up by synchronization and data movement between cores.
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)
To expand on your main point: A loose, but appropriate analogy is that FP appeals to programmers in the way analytic solutions appeal to mathematicians and scientists: Neat, ideal, beautiful... but a poor fit for many practical problems.
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 get literal algebraic topology, which captures useful and interesting properties of individual topological spaces effectively.
> A more substantive objection is that the sole purpose of parallelism is performance.
I disagree a lot more strongly here, though I will twist your words a little bit. Yes, parallelizing a program is about making it run faster; 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.
Abstracting over the speed-up aspects of parallelism gets you to concurrency -- the independence of knowledge held by distinct agents that is not directly knowable by others -- which is far more fundamental than simply making programs run faster. In my experience, most properties of modular systems can be stated in terms of concurrency. Parallelism is an exploitation of that concurrency structure to schedule things efficiently, but it is by no means the only application.
The fact that "one can achieve a 7x speedup on 8 cores by adding a handful of lines to a program" tells me that Haskell is extremely good at letting you expose the concurrent structures of your problem domain.
> Yes, parallelizing a program is about making it run faster; 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.
Maybe I should say what I meant more clearly. The claim "one can achieve a 7x speedup on 8 cores by adding a handful of lines to a program" implicitly has a "and this is good because being fast is good" at the end. Why care about a speedup if you don't care about speed in the first place?
It follows that when evaluating a language's ability to gain speed through parallelization, we should also evaluate how fast that language is in the first place. If you can get a 7x speedup on 8 cores from a few lines of code, but the original algorithm is, say, 10x slower than a similar implementation in C/Rust/Go on one core, then who cares? The ultimate criterion is always absolute speed, not relative improvement.
I agree that being able to deal with concurrency is important, but as the Go people always remind me, concurrency and parallelism are distinct concepts.
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.
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?
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.
How could you have not mentioned OCaml? The original Rust compiler was implemented in it. By this, Rust has a very clear (OCa)ML heritage.
It's meaningless to argue, whether Rust got ADTs from Haskell or OCaml, because the author (Graydon Hoare) had been clearly familiar with both and both got ADTs from ML, which is much older than either of them.
On the other hand, traits are a different story, those just Type classes with a different name, and that is a Haskell thing.
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 Haskell brought. In particular, he hated how Haskell took mutability from "not the default" to "practically impossible". He hated the effect system and how overly intrusive it was (although he was open to the idea of a fine grained effect system that was not tied to some all powerful Monad typeclass). He hated lazy evaluation. He hated the syntax...even the convention toward snake-case vs camel-case is an homage to OCaml. He didn't even care much for typeclasses, preferring the more strict encapsulation of modules, and only bringing them in after a lot of contributors pushed for them.
Basically, apart from typeclasses (which werent really unique to Haskell, as they had been known as interfaces within OOP for a few years), Graydon viewed Haskell quite a bit like an old atheistic refrain about religion: that which is good about it is not unique, and that which is unique about it is not good.
BTW, Rust's ADTs as well as Haskell's ADT's came from ML. They've been around since 1973, 13 year before Miranda, and 17 years before Haskell's first release. You don't get to claim that Rust got it's ADTs from Haskell any more than you get to say that Java got it's Optionals from Scala.
EDIT: see this comment from Graydon himself, made about a year ago on the rust subreddit:
> That said: back then Rust was much more OCaml-y. We did not start with traits / typeclasses; we started with modules (for a while: first-class, though quite badly broken due to my lack of knowhow). I was and am unapologetically more of an OCaml fan than a Haskell fan. This opinion is not made from a lack of information about either, and I am not especially interested in having a Haskell-vs-OCaml argument here. I don't even think of them as being especially different languages from a family-lineage perspective. But insofar as I think eager is a better default evaluation strategy than lazy, and modules are a better abstraction mechanism than typeclasses, I am more in the OCaml camp. Other folks later in Rust's development argued for (and eventually won) the typeclasses / traits thing, against my earlier preferences.
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?
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.
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.
> 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 comes pretty close but you can encode some properties about your computation in the Haskell type system that Rust does not yet support and so the safety of some computations can be statically proven in Haskell but not in Rust.
var colours = coordinates.stream().map(this::computeColour).collect(toList());
var colours = coordinates.stream().parallel().map(this::computeColour).collect(toList());
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
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 caching framework, database or Haskell runtime is doing it for you. Additionally like I said earlier, Even if your database is handling mutation for you, you still end up embedding mutation commands into the strings of your pure FP function. Updating a database in haskell still necitates the haskell user to place the mutation command in a SQL string.
My point is, that math is not the complete solution to the programming problem. What FP allows the programmer to do is to use the framework to segregate combinatorial logic away from mutation and IO. Your combinators will always be more composeable and modular but your IO and mutation functions will be less modular but they still have to exist.
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.
Outside of the io monad you cannot (modulo some exceptions) indicate io.
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"
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?
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” 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?)
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 "
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.
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".
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.
I'm trying to help you. You're not listening.
I've experimented a lot. Without changing tone just disagreeing with a popular opinion is all that you need to get voted down. I've even experimented with emotionally charged impolite popular opinions. People will vote you up just because they agree.
If I wanted a shitload of karma. I know how to get it. Removing one or two of the more "expressive" sentences above will in my experience not do much for a thread that is very very biasedly supporting FP. FP is great, I prefer it but most people cannot maintain such neutrality for their favorite paradigm. Or favorite anything for that matter.
Not to mention if you recall a while back someone posted a GPT-3 AI generated story that got voted to the front page. Most commenters didn't realize it was AI generated. A select few were able to figure it out and they posted comments that were vehemently voted down for not being in agreement with the general sentiment. HN is a technical crowd but they are not above common mob behavior.
https://www.theverge.com/2020/8/16/21371049/gpt3-hacker-news...
Scroll down to the picture. The person stated facts but his facts were misinterpreted to be attacks and he was told to be civil by someone who thought of himself as level headed. The reality is that the levelheaded person is as biased as one can get.
You think you're helping me. You think I'm putting up stubborn resistance to your help. Is that the case or am I just simply describing to you some of the insight I've gotten from messing around with HN for over a decade? Did I in fact put up stubborn resistance or am I just conversing with you and stating a disagreement? Hard to say.
Your immediate assumptions are no different than the "levelheaded" dude from earlier. Let's just be clear, I'm fully aware of the "expressive" areas in my posts.
You will also note that many of the posters assumed I'm attacking FP and that I don't have much experience with FP. All wrong assumptions. I have lots of experience and I prefer FP over other paradigms. I am simply stating that I disagree with the fact that algebra is the future of programming and can replace all imperative programming.
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.
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.
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 it were an inherently flawed or invalid approach, rather than one of many equally valid approaches to modelling state transformations.
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.
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.
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
print "hello"
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.
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.
Haskell is a pretty awesome language, but it doesn't make it easy to incrementally optimize programs.
This is also the same reason why I like SQL, it describes properties of the result set--if your thinking of it as procedural steps it's more difficult. When it comes down to performance tuning however, you do have to consider what really happens in terms of index choices, loop nesting, etc. I never got into FP problems large/complex enough to hit this point where I have to understand how FP sausages are made.
To go into another timeless paradigm, logical programming is famous for unexpected exponential execution times. It's rare that those get past tests, but it's something that developers are constantly having to fix (this or ensuring the type system detects determinism). SQL has a much milder version or this with underspecified joins.
Getting ride of time makes a lot of things easier, but is not trouble-free.
Non-buggy performance follows different rules.
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.
I have never heard of those famous "unexpected exponential times" in logic (not "logical") programming. Could you please give an example of what you mean?
I'm also not sure what you mean by "this or ensuring the type system detects determinism". What logic programming languages with a type system do you mean? Why would a type system be required to detect determinism?
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.
All of computation provably can, but not everything computers do, despite the name, is computation.
(1) As mentioned in the article, values are immutable and side effects are reified so you do not have to reason about time. Instead, you can reason equationally, which unlocks some nice benefits related to refactoring, reasoning about correctness and concurrency, testing, reproducibility, etc.
(2) Functional programming is based on well-behaved mathematical foundations and so is more stable than the other programming paradigms. Object-oriented programming is a constantly moving target because it doesn't have a principled formal foundation (despite many attempts to establish one on an ex post facto basis), whereas functions are "timeless" in the sense that they're here to stay.
It's not without tradeoffs of course, but if you're willing to have an open mind about how computers should be programmed and forego some things that are so pervasive in traditional programming (e.g., unrestricted side effects), the payoff is huge.
While I too mostly prefer functional programming principles, the argument seems weak to me. Even if those features are timeless and programs written with those can be ported to most other languages, it doesn't follow that an extra feature (even if invented in the future) won't make you 10x more productive thus desirable.
I prefer the functional programming style (in a non-FP language) for the productivity gains. I move faster, the codebase has a smaller footprint 'in my brain', it's easier to reason about it, so overall I'm more productive when using it.
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.
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...
To add, I find the strong push for purity of functions helps free up the part of my mind which seems to constantly worry about potential problems or unknown/unexpected behaviors. With that background noise out of the way, I can create more elegant (by my own judgement :) ) solutions to needs. I also sleep better.
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 imperative/mutable world.
Otherwise Rust is very much functional in all the great ways explained in the article.
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.
To first order, Haskell users self-select as uninterested in writing useful programs. Anybody who would like Haskell to be seen as a language that is useful for writing useful programs would better publish programs in Haskell that do useful things than explain what they like about monads.
I can confidently advise against choosing to add to the list of IRC clients, window managers or greps, or stuff only Haskell coders use. A program that does something no other program does, as pandoc does, that is badly needed, as pandoc was, would be the best choice.
A second course would be to find ways to make Haskell code run fast without need to jump through hoops that corrupt the design of the program. (It might be that it is too late for Haskell to move in this direction.) There appears to be room in the world for slow languages (Python, PHP), so slowness is not deadly, but it does limit a language's appeal. Haskell doesn't need that. Prima facie, Haskell should not need to be slow.
A Haskell program that generates a program in (e.g.) LLVM IR to do a useful thing quickly would serve in lieu of an actually fast program. FFTW is a fast C library for evaluating FFTs generated by an OCaml program that does not need to be very fast.
FFTW relies for its speed on a cache-oblivious array traversal order (re-)invented[0] by Todd Veldhuizen for use in a C++ template library Blitz++ that, in effect, generates programs that perform matrix operations. In Veldhuizen's library, the program was in (pretty slow) C++ template meta-language that ran during compilation of the user's program, but by generating C++ in place it produced a fast program in one step.
A Haskell or descendant not dependent on GC could find use in places where present Haskell is not welcome today.
[0] Cache-oblivious traversal was, apparently, originally invented in the '70s to speed database operations where the the storage cached in main memory ("core") was on disk and tapes, and was then mostly forgotten. It may be re-invented again, in another generation.
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.
Flax is currently by far my favorite neural net library, despite being pretty small, because it lets you write a neural net module as a function and decorate that with @nn.module — the decorator wraps your function in a class instance to manage the params and state. This can shave 10 lines per module, and if you’re like me, you have like 50 bajillion ideas for different neural net modules, it really adds up.
TLDR: Check out Flax if you like functional programming and neural networks!
Monads... they're just a way of remaining pure (meaning immutable) but still doing imperative-ish stuff. You don't need monads to make software: both pure-FP and imperative languages can be Turing-complete, so you can do it all. For doing IO you can just use an imperative shell [1], that "calls" the main function of your pure-FP program (aka: a runtime).
Monads for IO make it easier to communicate with this "imperative shell" while still remaining pure. It communicates with it by requiring you to return an IO object all the way to your main function.
But Monads can also be used for other things that don't need IO, like "internal mutable state", "maybe monad" or even for simulating an exception system. Those don't require you returning anything.
Monads are nothing special for real... but you have to use to understand them, since most explanations just make it harder to understand, so I won't attempt one.
[1] https://www.destroyallsoftware.com/screencasts/catalog/funct...
HTML DOM as a crude example, is a big 'tree of state' whereupon OO would lend well to the nature of the noes on that tree for example.
When you're crunching data and the entire process is literally some kind of transform FP I think more intuitively maps to the situation.
On the DB side, there is a niche of OODBs that exist and used particularly in networking because the persisted state there is really topological, in which case it doesn't always lend well to RDBMS.
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 need an explicit private keyword
* Interfaces - covered by typeclasses but they do a lot more!
Also without any of the above you can create object-like things with just closures. If a scope has access to 3 variables in scope, it's "kinda" like an OO object with 3 member variables. You can create new scopes in a for loop, which is like creating many new object. It's a stretch but the underlying concept of something owning other things is still there.
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.
pos = pos.moveBy(x,y)
vs
pos = moveBy(pos, x, y)
Use sparingly. I would avoid altogether except for common ones like map, reduce and filter.
Functional programming promotes the idea of composition of morphisms and point free programming. I would use this in place of Object composition/dependency injection/higher order functions or whatever you want to call it.
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.
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
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.
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, to head off the "in general", there is a long tail of unique problem domains. Each individually doesn't get as much press as, say, a CRUD app, but that doesn't mean that simpler problem domains are necessarily in the majority.
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.
As a silly made up example, you pass a callback to an XML parser to tell you when a node has been parsed, so you can pass in a callback to call an API to let it know. Doing something like that just pollutes the XML parser code for no good reason, and you then debug and find you get a 400 error when trying to parse something and 'wtf' and you have to untangle the callbacks.
I'm having a hard time summing it up right now, but I think if you try to "libraritize" "specific code", i.e. make something that does a very specific job, too generic it causes confusion.
That example has 1 callback but believe me some developers want to stack 'em high.
Although your opinion is more extreme than I can get behind, I don't entirely disagree. I find monads and applicative functors are far easier to understand when presented in their non-higher-order formulation -- that is, "flatten" instead of "bind", and "merge" instead of "ap". You still need to understand "map", but that's an incredibly common pattern that you can get a lot out of for putting in just a little.
I wrote a little comment on this earlier this week.
https://news.ycombinator.com/item?id=24894849
I also agree with your opinion elsewhere about preferring combinators instead of directly passing higher-order functions, but I suspect that's much more of a style and design issue than a language feature distinction. You still need higher-order functions (and I'm frustrated weekly by Java's lack of higher-kinded types or pleasant existential types) as the basement layer to expose a beautiful API in more natural terms.