18 ms·

Why study functional programming? (2012)

155 points by arkj 4y ago

serde111 4y ago
If you learn FP, in a real FP language, it will bring discipline into the way you write code. All code you write, once you "get it", functional or non-functional may become an order of magnitude better.
- poulsbohemian 4y ago
  I'm curious - would you also say, "If you learn OOP, in a real OOP language, it will bring discipline not the way you write code." And if you wouldn't say that, why not? And what language and learning tools would you recommend for this FP learning?
agentultra 4y ago
Because there is an essential complexity to programming in general that you cannot escape. Avoiding functional programming is like navigating a dark cave by bumping into obstacles when you have an assistive technology that can guide you.
yodsanklai 4y ago
Modern languages assimilate ideas from all paradigms. Besides, FP isn't some theoretical obscure stuff. I'd except most programmers to know some rudiment of Scheme or ML.
dbrueck 4y ago
In my mind, 'wustl.edu' will forever be one of best treasure trove FTP sites back in the late 90's. That is all.
dboreham 4y ago
Obvious reason to study FP is: when, inevitably, someone appears who believes they are smarter than you due to their love of FP, you can more effectively defeat them.
- filoleg 4y ago
  This is so true, it hurts. From my personal (and rather limited) experience, there are two kinds of people who are into FP. First are those who will act like christian missionaries or competitive vegans and tell you all about it in the most obnoxious way possible every time they see you. And the rest are those who you wouldn't even know are into FP. Obviously exaggerating for a comedic effect here, as there are a few people in the middle. But the median of my personal experiences is definitely very well described by just those 2 commonly present types above. You joke, but your "to shut the obsessed ones down easier" reasoning for getting into FP was one of my primary reasons for doing the same (along with just actually liking FP paradigms and learning quite a bit of cool stuff from it).
  - magicalhippo 4y ago
    Being self-taught, once we got internet back in the days I spent a lot of time on IRC for help with programming. As I grew more experienced I spent a lot of time on IRC helping others. After a decade or so, I formulated a theory based on my myself and those I helped on IRC. It seemed many (most?) programmers starting out followed a similar trajectory where, as they became competent programmers and grew confident in their skills, would latch on to some way as the way. Then, over time, as they got a lot more experience, they'd realize that often there are many different approaches with different merits and tradeoffs, and not get so dismissive to other approaches. Could it be your "two kinds" are those that just became good at FP, and those that have been good at it for a while and grown in experience? Anyway, not saying this is any profound insight, just something that struck me at some point during my journey. edit: Not all would grow beyond that initial stage. Some plateaued shortly after. But for myself and many of those I followed over time seemed to fit this.
    - q7xvh97o2pDhNrh 4y ago
      I learned a ton through IRC, too! And I'd give a strong +1 for this pattern. Personally, I think it applies generally to a lot of fields. Once someone has sufficient experience and wisdom, they inevitably come face-to-face with how little they truly know. Ideally, that humility is paired with a general sense of wonder and curiosity. I think, once you realize how little you know, it gets so much easier to (re)embody the childlike curiosity and desire to learn more. I don't think it's a given, though -- and sometimes (at the risk of arrogantly declaring myself to be humble), I find it pretty hard not to be overwhelmed by the massive volumes of reality that I'll never get to learn about. William Butler Yeats had a slightly different -- but far more beautifully phrased -- take on it in his poem, The Second Coming: [1] The best lack all conviction, while the worst Are full of passionate intensity. [1]: https://www.poetryfoundation.org/poems/43290/the-second-coming https://www.poetryfoundation.org/poems/43290/the-second-comi...
eatonphil 4y ago
I think the best reason to study FP is to get out of the OOP mindset. But ideally in the real world you don't go crazy with either. Objects are excellent for data but OOP is a mess for control flow. Immutability is great but everything-is-recursion is not. And so on. When performance comes up all of this goes out of the window, maybe. But I'm talking about good defaults for correct, readable programs.
- jrvarela56 4y ago
  | Objects are excellent for data Check out DOP https://blog.klipse.tech/dop/2022/06/22/principles-of-dop.html https://blog.klipse.tech/dop/2022/06/22/principles-of-dop.ht... and Rich Hikey's critique of OOP (~'objects are custom languages on top of data'; they force you to learn specific semantics to manipulate plain data structures and make it tough to reuse your code).
  - vkou 4y ago
    The semantics of objects are pretty straightforward, but the assurances that they provide on top of your data is their main value add in this context. Yes, things like protobufs, or equivalents thereof provide you with a list of auto-generated low-level assurances, but there are often bits of non-trivial business logic about data modification/reading that cannot be easily expressed outside of a object implementation in a Turing-complete language. They also clearly express a concept of, and when used correctly, boundaries for data ownership, which for non-ephemeral data can be important.
  - dkarl 4y ago
    > Objects are excellent for data Objects are great for modeling data as long as you still think of it as data, and you can write good data processing programs using OO language constructs. OOP as an approach to programming gets it backwards, though. OOP encourages you to think of the objects as primary and the data representing them (on the wire, in a datastore) as a secondary, inferior manifestation. This is the opposite of true. The software's value is created by its handling of data on the wire, reading data from other systems and writing data to other systems. OOP objects provide no value except by reading and writing data. If you start believing that the objects provide the value and the data exists to support the objects, as OOP encourages, then you start to suffer from all kinds of delusions.
nnoitra 4y ago
So you can pretend to be smarter than you are solely based on the paradigm.
pharmakom 4y ago
Even if you don’t find it very interesting, functional programming can make you rich.
- nnoitra 4y ago
  How come, it's barely used in industry lol.
  - epgui 4y ago
    You don't become rich or great (and then maybe rich) by following the biggest crowd, so I don't see how your response is relevant.
  - pharmakom 4y ago
    Top paying languages are Clojure, F#, OCaml
  - kephasp 4y ago
    It's not used by many, but it's used by niche environments that have a lot of money, especially in Fintech. When you want your code to be extremely reliable while really fast, there's nothing like languages like OCaml or Haskell.
rekrsiv 4y ago
Because it allows you to compose anything from only functions and category theory.
clircle 4y ago
As an R user, FP seems like the norm. Working with data or stats without FP mechanics sounds unpleasant.
- epgui 4y ago
  As another R user and FP aficionado, most R code is non-FP. If you work somewhere where you need to use R, and FP patterns are the norm, you're lucky!
procavia 4y ago
At my university the first programming class that every CS major had to take was functional programming. Many people would come in with no experience and FP would be their first introduction to the field. It was a very controversial course among students due to its perceived usefulness (or lack thereof), but as someone who already was familiar with imperative languages I really enjoyed it.
tresqotheq 4y ago
Because Haskell is awesome, and if you want to code in Haskell, you need to grok functional programming.
mikewarot 4y ago
The recent focus on adapting functional programming is a reaction from the shift to the dangerous quadrant of the immutable-mutable/unshared-shared "Magic Quadrant" chart. Before multi-core, multi-threading, it didn't matter how or when you decided to update your local variables, they were YOUR local variables... unshared. With threading, and multiple cores, we all just blindly moved right to the mutable/shared quadrant... the one in bright red... which effectively changes the laws of physics of your programs. Effectively every piece of code now runs in it's own time and space, and if you don't coordinate things correctly, it's like killing your own grandparents. It took me a long time to understand why you'd want to refactor your code until everything was immutable[1], but now that I get the lesson, its something I won't forget. Functional programming avoids mutable data, and thus, intentionally or not, works well in a world of shared data. Because pure functions have no side effects, they are timeless - they need no synchronization. Spend a few nights watching everything Kevlin Henney has said in the last few years, and you'll have a much better handle on things. [1] - https://youtu.be/APUCMSPiNh4 [Edit] Incorporate wording suggestion from DonaldPShimoda
- DonaldPShimoda 4y ago
  Just a small nitpick about your comment: > Functional programming is a reaction from the shift to the dangerous quadrant of the immutable-mutable/unshared-shared "Magic Quadrant" chart. I might rather say "The recent focus on adapting functional programming is a reaction...". Functional programming itself is nearly as old as the modern computer (McCarthy's first LISP paper was published in 1960), but your phrasing kind of suggests that the entirety of FP is a recent innovation.
  - frostwarrior 4y ago
    Functional programming itself is really old. Practical functional programming for scale is the new trend. What's new is the scale of software being developed right now. Developers simply can't afford to create mutable and shared state as if their program was just another desktop program, executed on a computer disconnected from the internet. Sooner or later we learn that focusing on the human value of code (I mean, making the code clear, concise and simple to read) pays off way better on the long run rather than optimizing for CPU cycles or memory footprint.
tacone 4y ago
Simply put: to have one more option.
jjice 4y ago
It's the same reason to learn alternatives to anything: to have a wider breadth of knowledge. Your thought process becomes more open and can better way alternatives because you actually have alternatives. My compiler course in college was in SML and it was excellent for teaching more more than just compilers. It taught me a lot about recursion and the idea of composing a problem in terms of itself, which has been incredibly powerful in my career. Being exposed to other great concepts like algebraic data types (sum types/Rust's enums) just helps expand my way of thinking when I write PHP code at work. The idea of using a function as a fundamental building block for abstracting ideas has also been fantastic. Mostly in the form of using functions as arguments to alter behavior. As with everything, there's a balance. I don't write pure FP, nor do I want to, but the ideas are huge. Same with OOP. OOP has some good ideas, but I don't lean on the words of the GOF as if they were GOD. Pulling in the best of all worlds has been really huge for my life as an engineer.
- Banana699 4y ago
  Dijkstra once explained how his process for writing code is to state\solve the problem in the most obvious and natural language possible. If a compiler\interpreter existed for that language, then he's done, he now has an executable solution to the problem. If not, then he recursively solves the problem of translating each construct of this non-executable-but-convenient language down into other constructs, if those constructs are executable, well and good, if not, he has to break them down further. Learning new programming languages, paradigms, architectures, approaches and formalisms aids this process because it gives you more mental building blocks to use in your journey from non-executable specifications to executable implementations. Even if you never write haskell, learning it makes your brain evolve a haskell-like pseudocode in which to think and express problems, and this can come in handy when the problem is most naturally expressed in haskell. If a haskell implementation exist, great, if not, transform the haskell formulation gradually into whatever executable form available. This, for a certain class of problems - let us rather unimaginatively call them 'haskell problems' -, is better and more enlightening than attempting to directly solve them in executable format. ------ One common saying is "You Can Write Fortran In Any Language", another one is "Any Sufficiently Complicated C Program Contains An Ad-hoc Informal Implementation Of Common Lisp". The fundamental truth that both of those aphorisms hint at is that programmers are human compilers, the programming language they write in is their target language, the "assembly", and the description of of the problem they are solving is the source language they are compiling. Here's the thing though : just like actual compilers, programmers don't have to compile the source language all in one go. Machine compilers often go through several detours and meander through different intermediate representation of the code being translated before outputting the final target. The equivalent of this for programmers is the Dijkstra process, describe your problems in a hierarchy of languages that ends, not begins, with the programming language you happen to use. If the problem is best described as a Fortran program, write it (in your head) as a Fortran program then implement whatever necessary of Fortran in the actual available language to write the program. If the problem is best described as Common Lisp program, then think about it in your head as a Common Lisp program then implement the necessary parts of Common Lisp in C to write the program (The full quote is only saying this is bad insofar as it happens non-deliberately and haphazardly, if it's deliberate then it's just good design). Programming Languages are notations/pseudocode/ways of thought/mental models/semantic repositories of meaning, they can be useful even if there is not a single executable implementation of them in sight.
silent_cal 4y ago
The problem with programming paradigms is that people tend to follow them obsessively, to the point where breaking from the paradigm seems automatically bad. For example, the four "pillars" of OOP are kind of arbitrary in my opinion, so I don't see an issue with breaking them, but sometimes writing a class is a better way to handle a collection of inter-related variables & functions. I don't think that makes me an OOP "adherent". It's not really possible to determine a priori if one theory will always be better than another when it comes to writing programs.
- danielvaughn 4y ago
  Agreed. My favorite example of this is domain-driven design. I love the core concepts - get everyone on the same language, make sure the code follows directly from business rules, etc. But you open the book and it's a flurry of absurd terminology that does nothing but obfuscate whatever the author is trying to talk about. Then that terminology gets tossed around by hardcore adherents, and you end up more confused about software development than before you learned about DDD. It's a shame.
  - silent_cal 4y ago
    It may be because programmers are often also attracted to mathematics, and so they think everything in programming must be very carefully defined, and everything must follow from axioms. In reality, programming has a lot more in common with a practical skill like carpentry - you use the best tools & methods available depending on the product you're trying to make.
    - edgyquant 4y ago
      Funny you chose carpentry which is very much a field where everything must be mathematically tested and proofed.
      - silent_cal 4y ago
        You use a bit of math in carpentry, but carpentry itself is not like mathematics. There's no deductive proof of the best way to make a chair out of oak.
deleted 4y ago
[deleted]
112233 4y ago
That lowly imperative programming: hard to prove your program is correct. Functional programming: easy to prove your program is correct, hard to prove its' execution will fit in the known universe. Functional programming IS math, so it's super satisfying to learn intellectually. It is also a spherical cow.
- kephasp 4y ago
  Why would it be hard to prove that functional code is actually runnable?
deleted 4y ago
[deleted]
globalise83 4y ago
I find it beautiful, especially recursion. The fact that you can just let the computer take care of the problem in some strange and invisible separate dimension is pretty magical to me.
orthecreedence 4y ago
I've been taking a kind of middle ground lately: build functional APIs. Move your side effects as far outward as possible and make your library's interface take everything it needs and return everything it computes. No HTTP calls, no database access, no random number generation. For example, don't have your library build the query and then run it, have it built the query and return it so it can be run at a higher-level. I know this seems obvious, but it was a breakthrough I had with organizing the way I built things a few years back and it has been serving me amazingly well. I think I originally stumbled onto the idea through a talk on domain-driven development. The result is that you get a lot of the benefits of functional (easy testing, portability, etc) but you don't have to deal with all the oddball patterns of recursion or currying or things that, yeah, sure, makes sense on some theoretical level but makes me want to gouge my eyes out when I try to read it. I've tried fully-fledged functional programming in a few cases and it doesn't click with me. I appreciate and understand that some love it, but in the end if your exposed public API is functional, the internals are less important. To me the important thing is the mindset: move your side effects as high up the chain as you can.
- i_hate_pigeons 4y ago
  this is what I learned is functional programming and I've also benefited greatly from it
- ledauphin 4y ago
  this is also known in some circles as "functional core, imperative shell." I agree that it's an excellent intermediate paradigm.
- mdcds 4y ago
  I tried learning Haskell for fun while working as a Python dev. Understanding importance of managing side-effects definitely influenced how I changed my approach to code organization at work.
- adamkl 4y ago
  The term for this that I have come across is "stratified design" and goes back to the book Structure and Interpretation of Computer Programs by Abelson and Sussman. I have no idea why this approach isn't more well known (especially compared to typical "layered" design approaches) as the benefits are so great! https://medium.com/clean-code-development/stratified-design-over-layered-design-125727c7e15 https://medium.com/clean-code-development/stratified-design-...
whitenickel08 4y ago
I miss Erlang-ish languages in the article.
tpoacher 4y ago
I have a feeling the term "functional programming" will be a negative term by the end of the decade. Not "functional aapproaches", just "functional programming". In the same way that now "Object-oriented programming" is a negative term (but OO techniques in isolation where appropriate by context are totally fine).
- jacquesm 4y ago
  > I have a feeling the term "functional programming" will be a negative term by the end of the decade. And what do you base this feeling on? Functional programming has been on a very slow and steady rise since... the 1950s. In fact the site that you are writing this on is written in a functional programming language.
  - baby 4y ago
    slow and steady doesn't win the race :p I think FP would have to get big before getting any bad rap, and I don't think it will
    - jacquesm 4y ago
      FP has a lot going for it and it is gaining traction bit by bit in all kinds of domains where previously this was not the case. I'm not sure if we should lump Erlang/Elixir in with functional programming (I think they should be but others may disagree because of the Prolog ancestry), but Clojure is definitely there as is Haskell, F# and so on. Reliability in software is rapidly becoming a key item, as more and more real world processes are directly influenced by software accidents have the potential to have very bad consequences, and functional programming is very good at completely avoiding certain classes of bugs. Couple that with mature eco systems and success stories such as WhatsApp and I think we are getting closer to seeing FP become mainstream. What really would move the needle is if software engineering were to be held to the same standard as regular engineering: liability. Sooner or later this industry will have to grow up and all the band-aids in the world won't help to achieve that if it isn't addressed at the foundation.
anonimamente 4y ago
Oftentimes we read a comment of the kind "bad or good code can be written in any language or paradigm" in response to writings of the ills or virtues of said language or paradigm. Thus implying that we really shouldn't care of the choice of tools but rather concern ourselves with the individuals using them? This seems like an easy out. Too easy. If it is bad code that we need to worry about, no matter what the syntax or semantics, then how do we do that? Is bad code, like porn, something that we only recognize when we see it, impossible to clearly define? If that's the case, then we really need to figure out some better way to guide us. The mention of Kevlin Henney is particular here in that he has made presentations specifically identifying examples of bad code and how they are made better. If no language or paradigm can help steer us in the right direction--a proposition that I do not believe--then there best be some clear way to tell us how to avoid the pitfalls other than "I know it when I see it."
rekrsiv 4y ago
Because writing functional code forces you to define your program in mathematical terms and this improves your ability to reason about your program. Imperative code is very convenient when you're describing processes that access a lot of shared global state at the lowest level, but it becomes difficult to keep track of everything when you have a lot, and math doesn't know how to handle that much complexity. But math can help with simpler things, like unary functions that aren't allowed side effects. And if you opt-in to only using unary functions without side-effects, you get to use most of category theory for free. Simplicity is the ultimate sophistication, and functional programming requires simplicity.
goto11 4y ago
Functional programming is at last mainstream. The most popular JavaScript frameworks React and Vue has adopted functional rather than OOP approaches. Before long we will see how functional programming fares when applied by average programmer under real-world constraints and the consequences for long term maintainability. Like when OOP hit the mainstream, I predict we will see some disappointment set in. Due to the laws of the hype-cycle, this will lead to embarrassment and backlash, but in the end expectations will stabilize, and functional will be considered a tool in the toolbox rather than a panacea.
alphanumeric0 4y ago
I think people care more about correctness, in general. I think we used to just be happy that code worked at all.
jononomo 4y ago
It seems to me that if you're going to use functional programming, then you do need to have a way to maintain state and manage threads if you're going to run genuinely useful software. So a platform oriented toward functional programming, such as Erlang's BEAM virtual machine, which gives you the thread management and architecture principles to really maximize the power of functional programming, makes the most sense to me.

155 points by arkj 4y ago

If you learn FP, in a real FP language, it will bring discipline into the way you write code. All code you write, once you "get it", functional or non-functional may become an order of magnitude better.

poulsbohemian 4y ago
I'm curious - would you also say, "If you learn OOP, in a real OOP language, it will bring discipline not the way you write code." And if you wouldn't say that, why not? And what language and learning tools would you recommend for this FP learning?

agentultra 4y ago

Because there is an essential complexity to programming in general that you cannot escape. Avoiding functional programming is like navigating a dark cave by bumping into obstacles when you have an assistive technology that can guide you.

yodsanklai 4y ago

Modern languages assimilate ideas from all paradigms. Besides, FP isn't some theoretical obscure stuff. I'd except most programmers to know some rudiment of Scheme or ML.

dbrueck 4y ago

In my mind, 'wustl.edu' will forever be one of best treasure trove FTP sites back in the late 90's. That is all.

dboreham 4y ago

Obvious reason to study FP is: when, inevitably, someone appears who believes they are smarter than you due to their love of FP, you can more effectively defeat them.

filoleg 4y ago
This is so true, it hurts. From my personal (and rather limited) experience, there are two kinds of people who are into FP. First are those who will act like christian missionaries or competitive vegans and tell you all about it in the most obnoxious way possible every time they see you. And the rest are those who you wouldn't even know are into FP. Obviously exaggerating for a comedic effect here, as there are a few people in the middle. But the median of my personal experiences is definitely very well described by just those 2 commonly present types above. You joke, but your "to shut the obsessed ones down easier" reasoning for getting into FP was one of my primary reasons for doing the same (along with just actually liking FP paradigms and learning quite a bit of cool stuff from it).
- magicalhippo 4y ago
  Being self-taught, once we got internet back in the days I spent a lot of time on IRC for help with programming. As I grew more experienced I spent a lot of time on IRC helping others. After a decade or so, I formulated a theory based on my myself and those I helped on IRC. It seemed many (most?) programmers starting out followed a similar trajectory where, as they became competent programmers and grew confident in their skills, would latch on to some way as the way. Then, over time, as they got a lot more experience, they'd realize that often there are many different approaches with different merits and tradeoffs, and not get so dismissive to other approaches. Could it be your "two kinds" are those that just became good at FP, and those that have been good at it for a while and grown in experience? Anyway, not saying this is any profound insight, just something that struck me at some point during my journey. edit: Not all would grow beyond that initial stage. Some plateaued shortly after. But for myself and many of those I followed over time seemed to fit this.
  - q7xvh97o2pDhNrh 4y ago
    I learned a ton through IRC, too! And I'd give a strong +1 for this pattern. Personally, I think it applies generally to a lot of fields. Once someone has sufficient experience and wisdom, they inevitably come face-to-face with how little they truly know. Ideally, that humility is paired with a general sense of wonder and curiosity. I think, once you realize how little you know, it gets so much easier to (re)embody the childlike curiosity and desire to learn more. I don't think it's a given, though -- and sometimes (at the risk of arrogantly declaring myself to be humble), I find it pretty hard not to be overwhelmed by the massive volumes of reality that I'll never get to learn about. William Butler Yeats had a slightly different -- but far more beautifully phrased -- take on it in his poem, The Second Coming: [1] The best lack all conviction, while the worst Are full of passionate intensity. [1]: https://www.poetryfoundation.org/poems/43290/the-second-coming https://www.poetryfoundation.org/poems/43290/the-second-comi...

eatonphil 4y ago

I think the best reason to study FP is to get out of the OOP mindset. But ideally in the real world you don't go crazy with either. Objects are excellent for data but OOP is a mess for control flow. Immutability is great but everything-is-recursion is not. And so on. When performance comes up all of this goes out of the window, maybe. But I'm talking about good defaults for correct, readable programs.

jrvarela56 4y ago
| Objects are excellent for data Check out DOP https://blog.klipse.tech/dop/2022/06/22/principles-of-dop.html https://blog.klipse.tech/dop/2022/06/22/principles-of-dop.ht... and Rich Hikey's critique of OOP (~'objects are custom languages on top of data'; they force you to learn specific semantics to manipulate plain data structures and make it tough to reuse your code).
- vkou 4y ago
  The semantics of objects are pretty straightforward, but the assurances that they provide on top of your data is their main value add in this context. Yes, things like protobufs, or equivalents thereof provide you with a list of auto-generated low-level assurances, but there are often bits of non-trivial business logic about data modification/reading that cannot be easily expressed outside of a object implementation in a Turing-complete language. They also clearly express a concept of, and when used correctly, boundaries for data ownership, which for non-ephemeral data can be important.
- dkarl 4y ago
  > Objects are excellent for data Objects are great for modeling data as long as you still think of it as data, and you can write good data processing programs using OO language constructs. OOP as an approach to programming gets it backwards, though. OOP encourages you to think of the objects as primary and the data representing them (on the wire, in a datastore) as a secondary, inferior manifestation. This is the opposite of true. The software's value is created by its handling of data on the wire, reading data from other systems and writing data to other systems. OOP objects provide no value except by reading and writing data. If you start believing that the objects provide the value and the data exists to support the objects, as OOP encourages, then you start to suffer from all kinds of delusions.

nnoitra 4y ago

So you can pretend to be smarter than you are solely based on the paradigm.

pharmakom 4y ago

Even if you don’t find it very interesting, functional programming can make you rich.

nnoitra 4y ago
How come, it's barely used in industry lol.
- epgui 4y ago
  You don't become rich or great (and then maybe rich) by following the biggest crowd, so I don't see how your response is relevant.
- pharmakom 4y ago
  Top paying languages are Clojure, F#, OCaml
- kephasp 4y ago
  It's not used by many, but it's used by niche environments that have a lot of money, especially in Fintech. When you want your code to be extremely reliable while really fast, there's nothing like languages like OCaml or Haskell.

rekrsiv 4y ago

Because it allows you to compose anything from only functions and category theory.

clircle 4y ago

As an R user, FP seems like the norm. Working with data or stats without FP mechanics sounds unpleasant.

epgui 4y ago
As another R user and FP aficionado, most R code is non-FP. If you work somewhere where you need to use R, and FP patterns are the norm, you're lucky!

procavia 4y ago

At my university the first programming class that every CS major had to take was functional programming. Many people would come in with no experience and FP would be their first introduction to the field. It was a very controversial course among students due to its perceived usefulness (or lack thereof), but as someone who already was familiar with imperative languages I really enjoyed it.

tresqotheq 4y ago

Because Haskell is awesome, and if you want to code in Haskell, you need to grok functional programming.

mikewarot 4y ago

The recent focus on adapting functional programming is a reaction from the shift to the dangerous quadrant of the immutable-mutable/unshared-shared "Magic Quadrant" chart. Before multi-core, multi-threading, it didn't matter how or when you decided to update your local variables, they were YOUR local variables... unshared. With threading, and multiple cores, we all just blindly moved right to the mutable/shared quadrant... the one in bright red... which effectively changes the laws of physics of your programs. Effectively every piece of code now runs in it's own time and space, and if you don't coordinate things correctly, it's like killing your own grandparents. It took me a long time to understand why you'd want to refactor your code until everything was immutable[1], but now that I get the lesson, its something I won't forget. Functional programming avoids mutable data, and thus, intentionally or not, works well in a world of shared data. Because pure functions have no side effects, they are timeless - they need no synchronization. Spend a few nights watching everything Kevlin Henney has said in the last few years, and you'll have a much better handle on things. [1] - https://youtu.be/APUCMSPiNh4 [Edit] Incorporate wording suggestion from DonaldPShimoda

DonaldPShimoda 4y ago
Just a small nitpick about your comment: > Functional programming is a reaction from the shift to the dangerous quadrant of the immutable-mutable/unshared-shared "Magic Quadrant" chart. I might rather say "The recent focus on adapting functional programming is a reaction...". Functional programming itself is nearly as old as the modern computer (McCarthy's first LISP paper was published in 1960), but your phrasing kind of suggests that the entirety of FP is a recent innovation.
- frostwarrior 4y ago
  Functional programming itself is really old. Practical functional programming for scale is the new trend. What's new is the scale of software being developed right now. Developers simply can't afford to create mutable and shared state as if their program was just another desktop program, executed on a computer disconnected from the internet. Sooner or later we learn that focusing on the human value of code (I mean, making the code clear, concise and simple to read) pays off way better on the long run rather than optimizing for CPU cycles or memory footprint.

tacone 4y ago

Simply put: to have one more option.

jjice 4y ago

It's the same reason to learn alternatives to anything: to have a wider breadth of knowledge. Your thought process becomes more open and can better way alternatives because you actually have alternatives. My compiler course in college was in SML and it was excellent for teaching more more than just compilers. It taught me a lot about recursion and the idea of composing a problem in terms of itself, which has been incredibly powerful in my career. Being exposed to other great concepts like algebraic data types (sum types/Rust's enums) just helps expand my way of thinking when I write PHP code at work. The idea of using a function as a fundamental building block for abstracting ideas has also been fantastic. Mostly in the form of using functions as arguments to alter behavior. As with everything, there's a balance. I don't write pure FP, nor do I want to, but the ideas are huge. Same with OOP. OOP has some good ideas, but I don't lean on the words of the GOF as if they were GOD. Pulling in the best of all worlds has been really huge for my life as an engineer.

Banana699 4y ago
Dijkstra once explained how his process for writing code is to state\solve the problem in the most obvious and natural language possible. If a compiler\interpreter existed for that language, then he's done, he now has an executable solution to the problem. If not, then he recursively solves the problem of translating each construct of this non-executable-but-convenient language down into other constructs, if those constructs are executable, well and good, if not, he has to break them down further. Learning new programming languages, paradigms, architectures, approaches and formalisms aids this process because it gives you more mental building blocks to use in your journey from non-executable specifications to executable implementations. Even if you never write haskell, learning it makes your brain evolve a haskell-like pseudocode in which to think and express problems, and this can come in handy when the problem is most naturally expressed in haskell. If a haskell implementation exist, great, if not, transform the haskell formulation gradually into whatever executable form available. This, for a certain class of problems - let us rather unimaginatively call them 'haskell problems' -, is better and more enlightening than attempting to directly solve them in executable format. ------ One common saying is "You Can Write Fortran In Any Language", another one is "Any Sufficiently Complicated C Program Contains An Ad-hoc Informal Implementation Of Common Lisp". The fundamental truth that both of those aphorisms hint at is that programmers are human compilers, the programming language they write in is their target language, the "assembly", and the description of of the problem they are solving is the source language they are compiling. Here's the thing though : just like actual compilers, programmers don't have to compile the source language all in one go. Machine compilers often go through several detours and meander through different intermediate representation of the code being translated before outputting the final target. The equivalent of this for programmers is the Dijkstra process, describe your problems in a hierarchy of languages that ends, not begins, with the programming language you happen to use. If the problem is best described as a Fortran program, write it (in your head) as a Fortran program then implement whatever necessary of Fortran in the actual available language to write the program. If the problem is best described as Common Lisp program, then think about it in your head as a Common Lisp program then implement the necessary parts of Common Lisp in C to write the program (The full quote is only saying this is bad insofar as it happens non-deliberately and haphazardly, if it's deliberate then it's just good design). Programming Languages are notations/pseudocode/ways of thought/mental models/semantic repositories of meaning, they can be useful even if there is not a single executable implementation of them in sight.

silent_cal 4y ago

The problem with programming paradigms is that people tend to follow them obsessively, to the point where breaking from the paradigm seems automatically bad. For example, the four "pillars" of OOP are kind of arbitrary in my opinion, so I don't see an issue with breaking them, but sometimes writing a class is a better way to handle a collection of inter-related variables & functions. I don't think that makes me an OOP "adherent". It's not really possible to determine a priori if one theory will always be better than another when it comes to writing programs.

danielvaughn 4y ago
Agreed. My favorite example of this is domain-driven design. I love the core concepts - get everyone on the same language, make sure the code follows directly from business rules, etc. But you open the book and it's a flurry of absurd terminology that does nothing but obfuscate whatever the author is trying to talk about. Then that terminology gets tossed around by hardcore adherents, and you end up more confused about software development than before you learned about DDD. It's a shame.
- silent_cal 4y ago
  It may be because programmers are often also attracted to mathematics, and so they think everything in programming must be very carefully defined, and everything must follow from axioms. In reality, programming has a lot more in common with a practical skill like carpentry - you use the best tools & methods available depending on the product you're trying to make.
  - edgyquant 4y ago
    Funny you chose carpentry which is very much a field where everything must be mathematically tested and proofed.
    - silent_cal 4y ago
      You use a bit of math in carpentry, but carpentry itself is not like mathematics. There's no deductive proof of the best way to make a chair out of oak.

deleted 4y ago

[deleted]

112233 4y ago

That lowly imperative programming: hard to prove your program is correct. Functional programming: easy to prove your program is correct, hard to prove its' execution will fit in the known universe. Functional programming IS math, so it's super satisfying to learn intellectually. It is also a spherical cow.

kephasp 4y ago
Why would it be hard to prove that functional code is actually runnable?

deleted 4y ago

[deleted]

globalise83 4y ago

I find it beautiful, especially recursion. The fact that you can just let the computer take care of the problem in some strange and invisible separate dimension is pretty magical to me.

orthecreedence 4y ago

I've been taking a kind of middle ground lately: build functional APIs. Move your side effects as far outward as possible and make your library's interface take everything it needs and return everything it computes. No HTTP calls, no database access, no random number generation. For example, don't have your library build the query and then run it, have it built the query and return it so it can be run at a higher-level. I know this seems obvious, but it was a breakthrough I had with organizing the way I built things a few years back and it has been serving me amazingly well. I think I originally stumbled onto the idea through a talk on domain-driven development. The result is that you get a lot of the benefits of functional (easy testing, portability, etc) but you don't have to deal with all the oddball patterns of recursion or currying or things that, yeah, sure, makes sense on some theoretical level but makes me want to gouge my eyes out when I try to read it. I've tried fully-fledged functional programming in a few cases and it doesn't click with me. I appreciate and understand that some love it, but in the end if your exposed public API is functional, the internals are less important. To me the important thing is the mindset: move your side effects as high up the chain as you can.

i_hate_pigeons 4y ago
this is what I learned is functional programming and I've also benefited greatly from it
ledauphin 4y ago
this is also known in some circles as "functional core, imperative shell." I agree that it's an excellent intermediate paradigm.
mdcds 4y ago
I tried learning Haskell for fun while working as a Python dev. Understanding importance of managing side-effects definitely influenced how I changed my approach to code organization at work.
adamkl 4y ago
The term for this that I have come across is "stratified design" and goes back to the book Structure and Interpretation of Computer Programs by Abelson and Sussman. I have no idea why this approach isn't more well known (especially compared to typical "layered" design approaches) as the benefits are so great! https://medium.com/clean-code-development/stratified-design-over-layered-design-125727c7e15 https://medium.com/clean-code-development/stratified-design-...

whitenickel08 4y ago

I miss Erlang-ish languages in the article.

tpoacher 4y ago

I have a feeling the term "functional programming" will be a negative term by the end of the decade. Not "functional aapproaches", just "functional programming". In the same way that now "Object-oriented programming" is a negative term (but OO techniques in isolation where appropriate by context are totally fine).

jacquesm 4y ago
> I have a feeling the term "functional programming" will be a negative term by the end of the decade. And what do you base this feeling on? Functional programming has been on a very slow and steady rise since... the 1950s. In fact the site that you are writing this on is written in a functional programming language.
- baby 4y ago
  slow and steady doesn't win the race :p I think FP would have to get big before getting any bad rap, and I don't think it will
  - jacquesm 4y ago
    FP has a lot going for it and it is gaining traction bit by bit in all kinds of domains where previously this was not the case. I'm not sure if we should lump Erlang/Elixir in with functional programming (I think they should be but others may disagree because of the Prolog ancestry), but Clojure is definitely there as is Haskell, F# and so on. Reliability in software is rapidly becoming a key item, as more and more real world processes are directly influenced by software accidents have the potential to have very bad consequences, and functional programming is very good at completely avoiding certain classes of bugs. Couple that with mature eco systems and success stories such as WhatsApp and I think we are getting closer to seeing FP become mainstream. What really would move the needle is if software engineering were to be held to the same standard as regular engineering: liability. Sooner or later this industry will have to grow up and all the band-aids in the world won't help to achieve that if it isn't addressed at the foundation.

anonimamente 4y ago

Oftentimes we read a comment of the kind "bad or good code can be written in any language or paradigm" in response to writings of the ills or virtues of said language or paradigm. Thus implying that we really shouldn't care of the choice of tools but rather concern ourselves with the individuals using them? This seems like an easy out. Too easy. If it is bad code that we need to worry about, no matter what the syntax or semantics, then how do we do that? Is bad code, like porn, something that we only recognize when we see it, impossible to clearly define? If that's the case, then we really need to figure out some better way to guide us. The mention of Kevlin Henney is particular here in that he has made presentations specifically identifying examples of bad code and how they are made better. If no language or paradigm can help steer us in the right direction--a proposition that I do not believe--then there best be some clear way to tell us how to avoid the pitfalls other than "I know it when I see it."

rekrsiv 4y ago

Because writing functional code forces you to define your program in mathematical terms and this improves your ability to reason about your program. Imperative code is very convenient when you're describing processes that access a lot of shared global state at the lowest level, but it becomes difficult to keep track of everything when you have a lot, and math doesn't know how to handle that much complexity. But math can help with simpler things, like unary functions that aren't allowed side effects. And if you opt-in to only using unary functions without side-effects, you get to use most of category theory for free. Simplicity is the ultimate sophistication, and functional programming requires simplicity.

goto11 4y ago

Functional programming is at last mainstream. The most popular JavaScript frameworks React and Vue has adopted functional rather than OOP approaches. Before long we will see how functional programming fares when applied by average programmer under real-world constraints and the consequences for long term maintainability. Like when OOP hit the mainstream, I predict we will see some disappointment set in. Due to the laws of the hype-cycle, this will lead to embarrassment and backlash, but in the end expectations will stabilize, and functional will be considered a tool in the toolbox rather than a panacea.

alphanumeric0 4y ago

I think people care more about correctness, in general. I think we used to just be happy that code worked at all.

jononomo 4y ago

It seems to me that if you're going to use functional programming, then you do need to have a way to maintain state and manage threads if you're going to run genuinely useful software. So a platform oriented toward functional programming, such as Erlang's BEAM virtual machine, which gives you the thread management and architecture principles to really maximize the power of functional programming, makes the most sense to me.