17 ms·

Functional programming should be the future of software

• jll29 4y ago
  > The first purely functional language to become popular, called Haskell, was created in 1990. Nope: LISP - 1958. Stopped reading there.
  • shepherdjerred 4y ago
    LISP is not purely functional
• fedeb95 4y ago
  Software should be the future of functional programming.
• halfmatthalfcat 4y ago
  The article picks on Javascript (of course) however you can write almost exclusively functional code in Javascript with the help of Rambda, fp-ts or the like. Yes, there is no "compiler" (outside of tsc) that will help you (yet) but stylistically, it's possible.
  • dmitriid 4y ago
    Javascript is already functional enough without these libraries. Rambda et al make simple code unnecessarily complex or verbose, and complex code unreadable
  • chrisseaton 4y ago
    You can write exclusively functional code in pretty much any language can't you?
    • spion 4y ago
      Go is probably one popular exception.
      • dottedmag 4y ago
        You still can if you wish to. First-class functions are there.
        • brabel 4y ago
          It used to be impossible to do anything remotely like FP in Go before generics, but now I believe it's indeed quite possible.
          • chrisseaton 4y ago
            But everything you can do with generics you can do manually by copying and pasting code?
            • brabel 4y ago
              Oh that's true. But you're a terrible masochist if you consider that an option.
              • spion 4y ago
                Lets take `map` for example. Before generics, you would have to reimplement map for every type combination. Each implementation would be done with a for loop. Now, while I'm willing to look over having one `map` implementation being done in imperative code and then everything else using that, I'm not exactly comfortable calling reimplementing map with imperative code for every type combination functional programming.
              • spion 4y ago
                Or lets look at persistent data structures, a staple of functional programming: https://github.com/tobgu/peds https://github.com/tobgu/peds Notice how you'd need to generate the DS for every type you'd like to use it with, which is not the case with built in mutable maps and slices. To make them type-safe, you need to generate them for every type you use. While this is technically possible, it does make the language quite hostile towards functional programming. With generics, this is rectified but the problem with non-composable multi-return-value functions still remains
    • nuclearnice1 4y ago
      Reminds of https://en.m.wikipedia.org/wiki/Greenspun%27s_tenth_rule https://en.m.wikipedia.org/wiki/Greenspun%27s_tenth_rule > Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.
  • jvanderbot 4y ago
    There is nothing magical about functional programming, it is the elimination of non functional programming features that is important. A language that can do either is exactly the wrong thing, from the perspective of TFA
    • jve 4y ago
      > There is nothing magical about functional programming How come not? I read that F# gives you compiler exception when you didn't match all possible values. Or when you didn't handle __maybe__ cases. JS even doesn't mind comparing strings with ints and incorrectly summing them together and not throwing a runtime exception less alone a compiler complaint. "1" == 1 true "1" + 1 '11'
      • innocentoldguy 4y ago
        I view this as one of JavaScript’s myriad flaws. Adding “1” to 1 is nonsensical and the result of “11” is even more so.
      • dmitriid 4y ago
        These are peculiarities of type systems, not of functional or non-functional programming.
        • jve 4y ago
          Well, we are talking about functional programming improving program correctness. Such behavior doesn't help. Better choose another language that is a fit for it.
      • jvanderbot 4y ago
        You can add error checking (e.g., compiler exceptions), but you cannot remove the parts of JS/other languages that cause that error checking to be important in the first place, not without fundamentally breaking the language/existing libraries. TFA describes a paradigm where those features don't exist, and so the error checking is not important. That's a truly safe language. It's also hypothetical at this point, IMHO.
  • ramesh31 4y ago
    You don't need any libraries to write functional JS. Modern React development is almost entirely purely functional.
• skohan 4y ago
  Imo functional programming is one of those things that makes sense from a theoretical perspective, but comes with compromises when it comes to reality. The thing about functional programming is that the confidence you get from immutability comes at the cost of increased memory usage thanks to data duplication. It's probably going to create a ceiling in terms of the absolute performance which can be reached. There are just other ways to solve the problems like NPE's and memory safety, like ADT's and ownership rules, which don't come at the same costs as FP.
  • narrator 4y ago
    The other problem with functional programming is it's harder to look at code and figure out the time complexity. At least with non-functional languages I can easily figure out why there are performance problems with it. Stuff like lazy evaluation may seem cool, but it's not when you have to figure out why something's slow.
    • brmgb 4y ago
      That's an Haskell issue not a functional programming issue. Haskell is pretty much the only functional programming language which is lazy by default. It's the sole one for the reason you give. Every other ones are eager by default and you can opt in to lazy evaluation when needed.
    • tasuki 4y ago
      This is lazy vs strict, not functional vs whatever. I'm a fan of functional programming, not so much a fan of lazy evaluation. Look at PureScript or Idris perhaps?
    • nequo 4y ago
      In addition to sibling’s recommendations, consider OCaml too for a strict language that is vaguely similar to Haskell and performs similarly well in benchmarks: https://cs3110.github.io/textbook/cover.html https://cs3110.github.io/textbook/cover.html
  • simion314 4y ago
• antihipocrat 4y ago
  This article would have benefited a lot by including a few examples of functional expressions and how they compare with other paradigms.
• le-mark 4y ago
  It would be helpful if the article started off defining what a functional language is. A lot of languages have functional features but are not “purely” functional. I think most would agree there’s a spectrum; dynamic vs static, eager vs lazy, mutable vs immutable. So what flavor of functional programming one might ask, since javascript is a dynamically typed flavor that is ubiquitous nowadays? The fine article suggests drum roll... Haskell! The author believes a statically typed and lazily evaluated language is what we all should be using. Unlike the various other dynamicaly typed options like small talk or scheme or lisp. Standard ML and Ocaml being statically typed are eagerly evaluated. Most popular languages have added a lot of functional features in recent years so it’s clear the world is moving that way, imo.
  • dmitriid 4y ago
    To quote "Stop Writing Dead Programs" [1]: "If what you care about is systems that are highly fault tolerant, you should be using something like Erlang over something like Haskell because the facilities Erlang provides are more likely to give you working programs." [1] https://www.youtube.com/watch?v=8Ab3ArE8W3s https://www.youtube.com/watch?v=8Ab3ArE8W3s
    • throwaway1492 4y ago
      That quote is absurd because the vast majority of applications on the planet are not written in Erlang and work just fine. Working and fault tolerance are in no way related. Being generous the majority of applications with very high uptime are also not written in Erlang.
      • throwawaymaths 4y ago
        And also the vast majority of "working" applications have a full devops team, legions of highly paid senior developers, etc. "You" do not.
        • throwaway1492 4y ago
          Ok so we’re adding “developer productivity” on to the list. Aside from moving the goal, one does not have faith a lot faith in the knowledge of people making these claims, like where’s the proof? Hint read Joe Armstrong’s dissertation.
• AlexanderDhoore 4y ago
  ML language != functional programming. There is more out there than Haskell. The article doesn't even mention OCaml, the second most popular ML-derived language on Github. Makes me suspect the article is not very well researched.
  • cosmic_quanta 4y ago
    While the title doesn't specify this, the article is about pure functional programming. I don't think OCaml fits this bill exactly.
    • xjm 4y ago
      It doesn't fit "pure", but it solves the same problems the article is talking about, as other functional programming languages do. In fact the article is excluding most functional languages by saying "pure", and then goes on with "Of the top dozen functional-programming languages, Haskell is by far the most popular" under the graph, which is wrong because it's missing "pure", a feature that is _not_ required to solve the problems that are being talked about. So I agree on the initial point "Makes me suspect the article is not very well researched."
      • tankorsmash 4y ago
        Which part of Haskell is impure?
• bitwize 4y ago
  FP is a thing that's come and gone. All the smart kids have moved on to Rust, where you get to play with types like a Haskell programmer but still have imperative constructs and no GC.
  • timbit42 4y ago
    Rust is the industry's next incremental step toward functional programming. Eventually, more and more non-functional features will be removed from languages.
• mmargerum 4y ago
  Doesn't include Clojure in GitHub repo count. "Functional programming also requires that data be immutable" Not true
  • munchler 4y ago
    Pure functional programming does require immutable data. There are lots of FP languages that aren't pure, though.
    • thinkharderdev 4y ago
      No, it doesn't. Pure FP is about pure functions, meaning only that they don't have side-effects (essentially just that you could replace the function call with it's return value without changing the semantics of the program). If a function mutates some global state then that would certainly make it impure but a function which takes an input, mutates it and returns the mutated value is absolutely pure.
  • victorvosk 4y ago
    Not to mention you can use just about any language provided you adhere to FP standards. It doesn't need to be forcibly "baked in".
  • waselighis 4y ago
    The D programming language is a good example which defines pure functions, not as strictly operating on immutable data, but simply as functions without side effects. So pure functions can still have local mutable variables, but cannot mutate any shared or global state. It goes further with "weakly pure" functions which can have mutable parameters/arguments, but still cannot mutate any global variables.
• zamalek 4y ago
  Functional programming won't succeed until the tooling problem is fixed. 'Tsoding' said it best: "developers are great at making tooling, but suck at making programming languages. Mathematicians are great at making programming languages, but suck at making tooling." This is why Rust is such a success story in my opinion: it is heavily influenced by FP, but developers are responsible for the tooling. Anecdotally, the tooling is why I gave up on Ocaml (given Rust's ML roots, I was seriously interested) and Haskell. I seriously couldn't figure out the idiomatic Ocaml workflow/developer inner loop after more than a day of struggling. As for Haskell, I gave up maybe 20min in of waiting for deps to come down for a Dhall contribution I wanted to make. Institutionally, it's a hard sell if you need to train the whole team to just compile a project, vs. `make` or `cargo build` or `npm install && npm build`.
  • sandruso 4y ago
    The npm install experience should be baseline for newer languages. Simply let me get into hacking fast. This is one of the top reason I like tinkering with JS because it just works. (Yes, I know all weaknesses of JS ecosystem, but getting is really easy)
    • intrasight 4y ago
      I do agree. I think .Net has got it right. And dotnet-script [https://github.com/dotnet-script/dotnet-script https://github.com/dotnet-script/dotnet-script] has been a game-changer for me with a REPL-like experience for unit testing and writing command-line utilities.
    • toastal 4y ago
      Please, no. Node tooling is such a mess and I can almost never get anything running easily on Nix because Node developers download binaries from the internet without understanding the system. All of these executables fail because of linked libraries. If instead they told you what libraries and executables you'd need instead loosy-goosy installing garbage all over my system, more things might work.
      • 4y ago
• victorvosk 4y ago
  Love the dubious github repo chart.
• azangru 4y ago
  Oh! From Hacker News trends, I thought the future of programming was going to be Rust...
  • gpderetta 4y ago
    wrong week.
  • timbit42 4y ago
    Near future vs. farther future.
• misja111 4y ago
  Very odd that this article states that functional programming is the solution to the null reference problem. Yes as far as I know all functional languages have some kind of Optional or Maybe type as a solution, but there are non-functional languages with this solution as well.
  • munchler 4y ago
    Perhaps, but those are still FP solutions that have been added to non-FP languages.
  • chriswarbo 4y ago
    > Yes as far as I know all functional languages have some kind of Optional or Maybe type as a solution, but there are non-functional languages with this solution as well. Optional/Maybe values are tedious if we don't have functions/methods like map, flatMap, etc. which take functions as arguments. That requires first-class functions, which pushes things further in the direction of FP. I think of things on a spectrum, e.g. more-functional/less-functional, rather than having a hard cutoff of "this is FP" or "this isn't FP".
• waselighis 4y ago
  I like the philosophy of Rust (and some other languages) of "safe by default". Rust variables are immutable by default, but can be made mutable using "let mut". Rust is memory safe by default, but can be made unsafe using the drumroll "unsafe" keyword. As for null references, other languages still have them but enforce "strict null checking", such as Kotlin and TypeScript. They force you to verify a reference is not null before using it, but without the verbosity of an Optional or Maybe type. Functional programming is great, but it's far from optimal in many situations. For example, implement a self-balancing binary search tree using a common imperative language with mutability. Then try implementing it again but using pure functional programming. Certainly very possible but also requires a lot more work when you're not allowed mutability.
  • douglasisshiny 4y ago
    You're allowed mutability, even in languages like Haskell.
  • poorlyknit 4y ago
    A note regarding your binary tree example: I'd argue that FP is actually great for working with tree-like data structures. For example, the common implementations for sets and maps are based on balanced trees. IME it's graph-like or array-based stuff where the paradigm struggles.
    • savingsPossible 4y ago
      Pay a log(n) slowdown and you have arrays in all their glory (and more!) https://hackage.haskell.org/package/containers-0.6.5.1/docs/Data-Sequence.html https://hackage.haskell.org/package/containers-0.6.5.1/docs/...
      • poorlyknit 4y ago
        If we really need to we can just actually use arrays tho: https://hackage.haskell.org/package/primitive-0.7.4.0/docs/Data-Primitive-ByteArray.html#v:ByteArray https://hackage.haskell.org/package/primitive-0.7.4.0/docs/D... That's what I meant: You can mostly use tree-like log(n) data structures rather nicely but you'll have to isolate your mutating code into stuff like PrimMonad, see: https://hackage.haskell.org/package/primitive-0.7.4.0/docs/Data-Primitive-ByteArray.html#v:writeByteArray https://hackage.haskell.org/package/primitive-0.7.4.0/docs/D... I like Haskell because it lets me write clean interfaces at a high level but fall back to byte-level stuff when needed.
• nu11ptr 4y ago
  I personally think Rust should be included in this group. It isn't technically a functional language, but it has a "functional flair" with many of the same benefits as functional programming provides, and with some of the features (pattern matching, sum types, etc.). It takes a different approach to mutability, but the net benefit I think is about the same.
• nayroclade 4y ago
  It's strange to me that this article focusses so much on nullability, which seems like a tangental issue. There's nothing stopping an imperative language from enforcing nullability checks. Indeed, with full strictness enabled TypeScript will do just that, including requiring you check every indexed access to an array.
  • klysm 4y ago
    This is a good point and I agree it buys you similar safety. The annoying part is it isn’t a monadic data structure. You usually get some syntactic sugar for a limited subset of mapping (optional chaining), but a lot of the time that’s insufficient and you get imperative code.
    • stiiv 4y ago
      Speaking as someone who recently switched from F# to TypeScript: yes, "annoying" is just what it is. Until TypeScript at least has pattern matching you'll be writing at least 50% more code, maybe more. Chaining would be a godsend, but without auto-currying, it's unsightly. Computation expressions would be better, and would probably be easier to implement if, say, TypeScript included a "native" `Option`, `Result`, or `Async`.
  • discreteevent 4y ago
    Not only that but directly under the heading "Nullifying problems with null references" they start to describe problems with global variables. The article is all over the place. There may be arguments for functional programming but I wouldn't trust this writer because their thinking is so sloppy. Also: "But many functions have side effects that change the shared global state, giving rise to unexpected consequences. In hardware, that doesn’t happen because the laws of physics curtail what’s possible." The laws of physics? That's complete waffle. What happens when one device trips a circuit breaker that disables all other devices? What happens when you open the door to let the cat out but the dog gets out as well?
  • yxhuvud 4y ago
    Yes, enforced nullability checks is just a type system feature. Another example that has it is Crystal, which is an OOP language.
• agomez314 4y ago
  It's not just about FP, it's about creating a language that will allow you to think more clearly about the problem. If we cannot graduate our primitives to the level of abstraction that's required for the problem then codebases will be fragile, projects will run over-budget and complexity will forever increase.
• munchler 4y ago
  Good article, but the chart of FP languages is way off. There are only 8,752 public Haskell repositories in GitHub (not 126,990, as claimed). Numerous other popular FP languages aren't even listed (e.g. Scala: 13,224, F#: 1,960).
• kstenerud 4y ago
  I immediately distrust any article that makes sweeping claims about one-paradigm-to-rule-them-all. The reason why multiple paradigms exist is because here in the real world, the competing issues and constraints are never equal, and never the same. A big part of engineering is navigating all of the offerings, examining their trade-offs, and figuring out which ones fit best to the system being built in terms of constraints, requirements, interfaces, maintenance, expansion, manpower, etc. You won't get a very optimal solution by sticking to one paradigm at the expense of others. One of the big reasons why FP languages have so little penetration is because the advocacy usually feels like someone trying to talk you into a religion. (The other major impediment is gatekeeping)
  • tylerdinner 4y ago
    Totally agree. As a Javascript dev I got functional code pushed on me in 2016. It's definitely good practice for devs to learn some of the pitfalls that FP prevents and solves, but implementing it on a massive scale front-end application just seems impractical. Having worked on a large streaming service and considering the author's 3 MONTH struggle after his 40 YEARS experience, I'd estimate that a re-write of our codebase there would have taken our 20 devs over a decade.
    • karmakaze 4y ago
      > implementing it on a massive scale front-end application just seems impractical. That's true if a team was trying to do so from scratch in js or ts. However React borrows a lot from FP and works at scale. A better example would be Elm.
    • kstenerud 4y ago
      I'm actually all for the FP things that have been added to imperative languages, which increase their power tremendously and make a lot of tasks a helluva lot easier. But like any tool, it has its place. I'd be equally leery of a pure imperative solution as I would be a pure FP solution.
    • eyelidlessness 4y ago
      > implementing it on a massive scale front-end application just seems impractical. I was using Clojure/ClojureScript around the same time. I’ve since worked primarily in TypeScript/JavaScript. I’m sure the FP experience influenced my opinion, but it seems impractical to me not to use FP techniques for a large scale frontend application. The applications I inherited and maintain now, which were certainly not originally implemented with FP techniques, have been gradually becoming much more maintainable as I’m able to eliminate or at least ruthlessly isolate mutations. Not only because the code itself is easier to reason about, but also because it’s easier to reason about dependencies between different parts of the systems—even parts which haven’t changed.
• cafard 4y ago
  Functional programming: the future of computing since 1977. (Dating it from John Backus's Turing Award lecture.)
  • throwaway17_17 4y ago
    Is that really a fair date to use? The functional programming Backus is talking about bears little resemblance to the functional programming which is being discussed now(and in the article). I think an interesting discussion can be had about what defines functional programming (and I’m not really trying to argue with you), but Backus’s FP doesn’t fit the definition the article or other posters are using (or implying).
• deleted 4y ago
  [deleted]
• abird198 4y ago
  I doubt so. Mutation is incredibly powerful. Problem is that we don't understand it.
  • exyi 4y ago
    They don't claim that pure FP is the future. Immutable is better default IMHO, make it explicitly mutable if you need it and know what you are doing.
• zzzeek 4y ago
  The first text sums it up: It’s hard to learn Which is refreshing to see just stated up front: FP is for smart people who have some motivation to learn something hard, even when there's a whole world of alternatives that are not "hard" to learn. in this writer's case, it appears to be they own a company and they've mandated everything be written in Haskell or PureScript, which will select for employees that are willing / able to do that, etc. as long as humans are employed to write the code directly, "hard to learn" is a non starter for being the "future".
  • ch4s3 4y ago
    You should give elixir a try. It’s easy to learn, the tooling is really good, and the community is super friendly. I’ve found the mix of immutability and dynamic/structural typing to be great in practice.
  • rileyphone 4y ago
    Specifically, FP requires expansive working memory, which is a normally distributed trait across the population. Meanwhile, in OOP one can reason from the perspective of the object and the interfaces it's interacting with, easing the burden on programmers, but there are obviously drawbacks there as well.
    • ParetoOptimal 4y ago
      > Specifically, FP requires expansive working memory, What? FP increases local reasoning! > in OOP one can reason from the perspective of the object In FP one can reason from the perspective of the function?
• photochemsyn 4y ago
  Hybridization of object-oriented and functional approaches seems like a decent approach to theses problems. > "Nearly all modern programming languages have some form of null references, shared global state, and functions with side effects..." Which is to say, code is organized into discrete classes, instantiated as objects, but those objects only use the functional paradigm with respect to their bound functions, i.e. no side effects, no shared global state. Some sort of input validation and screening can be used with each to sanitize values and avoid null references. Then you have a collection of discrete modular elements which can be reasoned about or debugged independently. Such classes would be essentially 'stateless' but you could have other classes that stored mutable state and were queried by the functional types, much like the application-database model: > "The trend has been to keep stateless application logic separate from state management (databases): not putting application logic in the database and not putting persistent state in the application. As people in the functional programming community like to joke, “We believe in the separation of Church and state”" https://ebrary.net/65011/computer_science/separation_application_code_state https://ebrary.net/65011/computer_science/separation_applica...
  • brmgb 4y ago
    Someone should bolt object-oriented features on top a functional programming language to see what it would look like. That would be an interesting research project. They could call it O-something and do a pun with an animal name.
    • metaltyphoon 4y ago
      Don’t need to, look at F#. Its functional first and OO is bolted on.
      • brmgb 4y ago
        Now I'm stuck wondering if you missed the joke or are one upping me. Well done if it's the case.
  • ParetoOptimal 4y ago
• unnouinceput 4y ago
  Me to Charles Scalfani (article's author): "Who's an edgy boy? Who's an edgy boy! Oh, you're such an edgy boy today. Good boy!" /s
• jmartin2683 4y ago
  At the end of the day, functional programming isn’t fun (to me). None of the qualities touched on in the article are unique to it, either. So… I’ll keep not doing it.
• zelphirkalt 4y ago
  Functional programming (FP) is great, no question. However, we who know about FP should not forget, that there are other worthwhile paradigms out there. Just think of Prolog-like things or programming in relations (for example minikanren) for example. The good thing is though, that mostly-FP/FP languages can be used to make DSLs, which in turn enable such kinds of paradigms, so that we are not limited to FP itself.
• loonginthetooth 4y ago
  Gonna be honest, this guy lost me at 'I decided to learn Haskell—and needed to do that on a business timeline. This was the most difficult learning experience of my 40-year career...' like, really?
• coldacid 4y ago
  The self-righteous attitude of the article is very much offputting. I'd love to have something to wave around at my boss and co-workers to convince them of the usefulness of the FP paradigm (to at least encourage FP-like practices in our heaps and heaps of existing code) but this article is certainly not it.
• Ciantic 4y ago
  Lot of the time arguments for Functional Programming seem to describe some form of total programming and avoiding partial functions. Like enforcing null checking or exhaustive matching, avoiding panics etc. When I was going through Functional Programming classes in Haskell, the teacher tried to separate total programming and functional programming. For instance Rust programs rarely use function composition compared to Haskell. He didn't consider Rust as very good functional programming language for that very reason. But at the same time Rust has good total programming tools like exhaustive checking, Option, Result etc. Does anyone else try to separate functional programming and total programming?
  • chriswarbo 4y ago
    Totality can be split into two separate properties: - All programs are defined for all inputs (exhaustive) - All programs terminate/coterminate The former is becoming more common (like your Rust example), but the latter isn't very widespread. For example, most would consider a function like this to be exhaustive, even though it loops forever when both Ints are non-zero: foo : (Int, Int) -> Int foo (0, y) = y foo (x, y) = foo (y, x) Proving termination is hard, and often undesirable; e.g. we want servers and operating systems to keep running indefinitely. However, co-termination can be quite easy, e.g. if we define a Delay (co)datatype: data Delay t where Now : t -> Delay t Later : Delay t -> Delay t Wrapping recursive calls in 'Later' allows infinite processes, at the cost of some boilerplate (Delay is a monad, if you know what that is): foo : (Int, Int) -> Delay Int foo (0, y) = Now y foo (x, y) = Later (foo (y, x))
  • ben7799 4y ago
    Arguments from academic and mathematicians will/may favor provability. Pure Functional where everything is function composition have more hope of producing a valid mathematical proof for a block of code. CS/Math will favor this over the aspects that get grouped into total programming, which often don't help provability.
• FpUser 4y ago
  We should have less priests and more practical people. Mine is the only true approach is the shortest path to being told to fuck off.
• shubhamjain 4y ago
  Functional programming proponents like the blog's author remind of Linux users who sweared by it as a user-friendly OS, thought of everyone else as idiots, and refused to admit its serious flaws as a general-purpose OS. I am not criticizing FP. It has great ideas and many of them have been actively borrowed into other languages. But it's just annoying to see bad analogies that get repeated again and again, like these: > Now, imagine that every time you ran your microwave, your dishwasher’s settings changed from Normal Cycle to Pots and Pans. That, of course, doesn’t happen in the real world, but in software, this kind of thing goes on all the time. > Let me share an example of how programming is sloppy compared with mathematics. We typically teach new programmers to forget what they learned in math class when they first encounter the statement x = x + 1. In math, this equation has zero solutions. But in most of today’s programming languages, x = x + 1 is not an equation. It is a statement that commands the computer to take the value of x, add one to it, and put it back into a variable called x. Deja vu! I read exact same arguments 10 years ago. Maybe if FP did reduce the bugs, you'd have some stats and successful projects to back them up. I worked at a company where FP was heavily used. It didn't magically reduce the number of issues we had to fix. Possibly increased them because of number of things we had to build from scratch. The company is default dead[1], now. Maybe bugs are not a symptom of the paradigm, but how strongly the systems and teams are architectured to prevent them. [1]: http://www.paulgraham.com/aord.html http://www.paulgraham.com/aord.html
  • pessimizer 4y ago
    Did you mean to comment on the analogies you quoted other than to say that they are often used? Is being useful a problem for an analogy? > But in most of today’s programming languages, x = x + 1 is not an equation. It is a statement that commands the computer to take the value of x, add one to it, and put it back into a variable called x. This is on page 1 of every basic programming book when it's explaining how "variable" differs between math class and programming class. I can't for the life of me see what upsets you about it.
    • shubhamjain 4y ago
      They are stupid because they don't address the fact that most procedural languages themselves have features to prevent re-assignments and mutable states (like, const). Also, variables reflect the state of the program, while microwave settings are inputs. The switching of settings doesn't make a whole lot of sense. > This is on page 1 of every basic programming book when it's explaining how "variable" differs between math class and programming class. I can't for the life of me see what upsets you about it. I never had a problem grasping the concept. I never equated "=" in programming to "=" in Math. It's just a symbol. Replacing "=" with "<-" would mean the same thing.
• deviantbit 4y ago
  I believe functional programming is interesting, and fun. But it is not going to replace the world. My background has spanned from working on AAA games, to simulations for the DoE, to owning my own business developing embedded products, and graduate school (yes, I went back as a gray haired, and did that late). I fell in love with Lisp many years ago on a TI Explorer. Functional languages are inherently difficult to develop applications that require state to change in non-deterministic ways. In fact, I challenge you to develop a first-person shooter in Haskell (Have fun). There are many types of applications where functional languages are perfect, but there are more that it would be a disaster. To make broad sweeping claims, such as this article, just encourages unnecessary discourse, and shows the ignorance of the author, and his limited understanding of the domain of problems that functional languages will benefit from, and the larger domain of problems that will not benefit from them. As an employer, I don't hire people for their functional programming skills. If they have them, the better, but we have over 3 millions lines of code in C++, and close to a million in Java. We are not starting over, and new projects will leverage existing code.
  • thrown_22 4y ago
    >Functional languages are inherently difficult to develop applications that require state to change in non-deterministic ways. In fact, I challenge you to develop a first-person shooter in Haskell (Have fun). Don't know about Haskell but it would be very fun to do it in Lisp. Performance sold separately.
    • deviantbit 4y ago
      Then try it.
    • mikedelago 4y ago
      Common lisp has a "pretty OK" story for calling C code whenever some speed is needed [0,1]. In my opinion, they suffer from some of the documentation/quick start problems that common lisp has, but they're otherwise usable. Some of Naughty Dog's late 90's/early 2000's games (Jak and Daxter, Jak II) were written in a lisp called GOAL, Game Oriented Assembly Lisp [2] [0] https://github.com/rpav/cl-autowrap https://github.com/rpav/cl-autowrap [1] https://github.com/cffi/cffi#cffic2ffi https://github.com/cffi/cffi#cffic2ffi [2] https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp
• dec0dedab0de 4y ago
  I don't know any purely functional languages[], so my viewpoint is skewed here. Whenever I have seen a python developer drink the functional kool-aid they end up either storing state in global variables, environment variables or in a dictionary they end up passing to every function. I then have to explain to them that passing a dictionary around and expecting variables to be in it is just half-assed OOP. My rule of thumb is anything that needs state should be in a class, and anything that can be run without state or side effects should be a function. It is even good to have functions that use your classes, as long as there is a way to write them with a reasonable set of arguments. This can let you use those functions to do specific tasks in a functional way, while still internally organizing things reasonably for the problem at hand. The minute people start trying to force things to be all functional or all OOP, then you know they've lost the plot. [] I have been wanting to learn lisp for over a decade, I just never get around to it.
  • ahartmetz 4y ago
    I strongly agree. Rule one: avoid and simplify state (e.g. recalculate data if it's cheap instead of updating it when any of its inputs change). Rule two: if you need state, keep it coherent by tightly managing it (go through functions that maintain the invariants) and exposing as little as possible. That is where classes come in.
    • valenterry 4y ago
      Pure functional programming is orthogonal to that. In other words: you can have your class that contains a maximum simplified state, no problem. Extending this to be pure functional means that in addition to everything else that you said, the calls to the class that manages the state are now considered as needing "special treatment" in the sense that you can't merely call them, you have to also explain what should happen if there are multiple calls. I.e. the order of execution is not depending on the order of lines of code anymore, but it is defined through the means/syntax that the programming language gives you.
      • bart_spoon 4y ago
• VBprogrammer 4y ago
  One could almost say that functional programming will always be the future of software.
  • JoachimS 4y ago
    Linux on the desktop - written in a functional programming language. Executed on the Mill CPU. Powered by a fusion reactor.
• znafelrif 4y ago
  The properties mentioned in the article are not really tied to functional programming. - Not allowing null-references can be done with any paradigm. For example with object-oriented programming there really is no reason why it wouldn't work to not allow null references. - Immutability can also be done with every paradigm. The Java String for example is both object-oriented and immutable. I think the paradigm is actually irrelevant. The real advantage is not gained by using a functional programming language. It is gained by using a language that prevents null-references and makes it easy to write and use immutable data structures.
  • ParetoOptimal 4y ago
    Tis doesn't give you 1) ease of use and 2) composability.
    • znafelrif 4y ago
      The article actually mentions ease-of-use as the major downside of functional programming ("Functional programming has a steep learning curve")
• JoachimS 4y ago
  The article states: "More important, developers need to learn a new way of thinking. At first this will be a burden, because they are not used to it. But with time, this new way of thinking becomes second nature and ends up reducing cognitive overhead compared with the old ways of thinking. The result is a massive gain in efficiency." In my experience from University CS education and later on in industry, a quite large group of students or engineers, programmers never grasp the functional way of thinking. It don't just take longer time, it doesn't happen. For this reason I'm skeptical that FP will ever be able to replace imperative (and object oriented) programming.
• jmull 4y ago
  Functional programming fixes what ails you! How do I know? A thought leader told me so! Nothing against functional programming, which certainly has its uses and advantages, but this article is basically substance-free. I guess it's really an ad for the author's company and book? Considering the shear number of things conflated with functional programming here, I'm not sure it would be worth the time.
• anfelor 4y ago
  Even though this article comes from a reputable source, it should be pointed out that the author is not a researcher in the area -- and the decision not to include various MLs, OCaml, Scala, or F# in the chart of functional languages seems controversial. So this article does not speak for the community. If you want to read more about using Functional Programming in Industry, I would recommend Yaron Minsky's https://queue.acm.org/detail.cfm?id=2038036 https://queue.acm.org/detail.cfm?id=2038036 instead. Why did the GOTO statement fall out of favor with programmers? If you look at Knuth's famous article weighting the importance of GOTO (https://pic.plover.com/knuth-GOTO.pdf https://pic.plover.com/knuth-GOTO.pdf) you can see many calculations where the GOTO statement can save you a tiny bit of runtime. Today, these matter far less than all of the other optimizations that your compiler can do (e.g. loop unrolling, inserting SIMD instructions etc). Similarly, in some domains the optimizations that functional compilers can do matter more than the memory savings mutation could bring. Personally, I believe that with in the next decades memory usage will matter more, but even then functional programming languages can do well if they can mutate values that only they reference(https://www.microsoft.com/en-us/research/uploads/prod/2020/11/perceus-tr-v4.pdf https://www.microsoft.com/en-us/research/uploads/prod/2020/1...). This does not break the benefits of immutability, as other program parts can not observe this mutation. I disagree with the articles premise that it is "hard to learn".. it might be today but it doesn't have to be. Monads are usually difficult for beginners, but algebraic effects are almost as powerful while being much simpler. They have slowly become mainstream (and might even make it into WASM!). It is an exciting time for functional languages and many people are working to make them even better!
  • thoradam 4y ago
    > the decision not to include various MLs, OCaml, Scala, or F# in the chart of functional languages seems controversial I don't know why that would be controversial. There's a very clear distinction between (MLs, OCaml, Scala, F#) and (Haskell, Elm, PureScript, etc.).
    • anfelor 4y ago
      Sure, they are in different language families. But a chart showing the "top dozen functional-programming languages" should include all languages that were given a separate workshop at the International Conference on Functional Programming (https://icfp22.sigplan.org/ https://icfp22.sigplan.org/): Haskell, ML, OCaml, Scheme, Erlang, miniKanren (the last two are arguably specialised enough that they could be excluded to put more focus on general-purpose languages).
• agumonkey 4y ago
  Oh, scalfani, he was quite invested in FP talks too. It's funny, I'm calling cover effect (forgot the idiom, but basically when big medias put you up, your uptick is over) on simple FP. I think mainstream absorbed most of the idioms (map filter reduce, decorators, composability, lazy streams etc) and there's nothing else in that bag to push. That said, I do believe that FP as an abstract multi stage modeling language is still gonna help in the future because it raises provability which is something that I personally miss every day in most mainstream languages. You're never too sure about anything and it's tiresome.
• scabel 4y ago
  As someone who uses Scala on a daily basis, I might be biased. However, functional programming is truly the future because of its mathematical guarantees. Pure functions give us referential transparency i.e. we can substitute a piece in a large layer and still expect the entire thing to work as long as it has no side-effects. This has so much relevance to software maintainability. The downside is that, to take advantage of this mathematical guarantee the code has to be pure through and through. A single side-effect can spoil everything. Immutability, is another aspect of pure functions i.e. a pure function wouldn't mutate its inputs.
• DeathArrow 4y ago
  Functional or procedural or whatever, it doesn't matter much for me as long as the paradigm is not OOP. I strongly believe that data should live separate from the actions performed on it. I also believe that inheritance is a bad thing as there are other, better means to achieve polymorphism. I do believe in a data oriented programming where we waste as little CPU cycles as possible and introduce as little abstractions as possible.
  • GaryPalmer 4y ago
    I am working on a java game where I threw all OOP knowledge out the window and use C-style pure data-classes with public fields and no methods. It's pretty refreshing to work this way compared to the design pattern madness you see in enterprise applications - but I guess it's not very safe if multiple people are working on this and some don't know what they are doing. There has to be some middle ground, I think people have been going way overboard with OOP in the last two decades.
    • DeathArrow 4y ago
      Me too, I use .NET but try to use in the least OOP way as possible. Of course, for interviews I can recite all things about OOP, countless patterns and their "advantages", SOLID, DDD done OOP way and most of the Uncle Bob "wise" teachings.
  • balefrost 4y ago
    I dunno, even in C codebases, it's not uncommon to have data structures containing function pointers. Polymorphism isn't inherently bad and trying to achieve it using, say, enums and big switch statements isn't particularly maintainable.
• Existenceblinks 4y ago
  Just don't include non-sense jargon in languages we are good to go. Elixir | Elm is dead simple FP you barely care about "FP", it's just module and functions. No monad, typeclass, lens(I still don't know this one, what it is).
• paradite 4y ago
  JavaScript is functional if you write in functional. There's nothing stopping you from writing pure functional code in JavaScript or TypeScript.
  • mikedelago 4y ago
    I think this is something a lot of people overlook too quickly, too. It's pretty easy to get some of the benefits of FP without using Haskell/Scheme/ML/whatever in a lot of languages: - Write pure functions - Postpone side effects until necessary (as in, set up the side effect in a way that the side effects inputs are testable) - Return things when possible, in order to increase the expressiveness of your code It's also important to not fight the language you're working in. If you're constantly breaking idioms and your teammates can't read your code, FP isn't providing any benefit.
  • ParetoOptimal 4y ago
    > Contemporary imperative languages could continue the ongoing trend, embrace closures, and try to limit mutation and other side effects. Unfortunately, just as "mostly secure" does not work, "mostly functional" does not work either. https://m-cacm.acm.org/magazines/2014/6/175179-the-curse-of-the-excluded-middle/abstract https://m-cacm.acm.org/magazines/2014/6/175179-the-curse-of-...
• jokoon 4y ago
  As long as I can avoid the mess of oop and inheritance, I'm happy. Good oop is only found in a very small amount of libraries. In don't want "reusable oop code", i want fonctions that returns data. Side effects are impossible to keep track. Of course you can't use fp everywhere, but oop should not be the default.
• agentultra 4y ago
  Maybe it ought to be but it definitely isn't if you look at success as industry adoption. The author seems to have good intentions and covers all the talking points a new convert will discover on their own. However I'm afraid an article like this will do more harm than good in the end. There are too many network effects in play that go against a new paradigm supplanting the mainstream as it is. And the benefits of functional programming pointed out in this article haven't been convincing over the last... many decades. Without large, industry success stories to back it up I'm afraid any amount of evangelism, however good the intention of the author, is going to fall before skeptical minds. It doesn't help that of the few empirical studies done none have shown any impressive results that hold up these claims. Granted those studies are few and far between and inconclusive at best but that won't stop skeptics from using them as ammunition. For me the real power of functional programming is that I can use mathematical reasoning on my programs and get results. It's just the way my brain works. I don't think it's superior or better than procedural, imperative programming. And heck there are some problem domains where I can't get away from thinking in a non-functional programming way. I think the leap to structured programming was an event that is probably only going to happen once in our industry. Aside from advances in multi-core programming, which we've barely seen in the last couple of decades, I wouldn't hold out for functional programming to be the future of the mainstream. What does seem to be happening is that developments in pure functional programming are making their way to the entrenched, imperative, procedural programming languages of the world. A good talk, Why Isn't Functional Programming the Norm? https://www.youtube.com/watch?v=QyJZzq0v7Z4 https://www.youtube.com/watch?v=QyJZzq0v7Z4
• JackFr 4y ago
  > The biggest problem with this hybrid approach is that it still allows developers to ignore the functional aspects of the language. Had we left GOTO as an option 50 years ago, we might still be struggling with spaghetti code today. This is demonstrably false, as C has always had a goto and its use by custom and in practice is greatly circumscribed.
• UltraViolence 4y ago
  Can I state for the record that almost every C compiler still supports GOTO? Rust supports the best traits of both Functional and Imperative languages. Ergo: The future is Rust. Rust is the future.
• insane_dreamer 4y ago
  Arguably the single most determining factor in using a language is the size of the ecosystem relative to the use case. If I'm writing a data science app I'll probably use Python because I can access a large number of well-tested libraries in the space, not because Python is a superior language itself. Same argument for Java (come on, who actually enjoys Java?) Whether it's OO or FP isn't going to be a major consideration. I enjoy Ruby over any other language, but don't use it much at work because ... ecosystem.
• wheelerof4te 4y ago
  The programming world peaked with structured and modular styles. Everything else is random noise. Keep your programs nicely structured and easy to follow. No code "architecture" nonsense, please.
• commandlinefan 4y ago
  Functional programming, as a paradigm, is way better than object-oriented programming, and also equally more complicated than object-oriented programming. My observation, over the past 30 years, is that 90+% of programmers aren't even capable of doing object-oriented programming - so getting them to do functional programming is a pipe dream.
  • kleene_op 4y ago
    > getting them to do functional programming is a pipe dream I don't know if that was intentional but I'm upvoting!
  • feoren 4y ago
    > 90+% of programmers aren't even capable of doing object-oriented programming Similar to other takes I've seen in this thread. But isn't it flawed to talk about being "capable of object-oriented programming" when object-oriented programming is itself an ill-defined, flawed idea? (I'm talking C++/Java/C#/textbook OO, not Smalltalk.) I spend a majority of my time in C#, and I'm not really sure I'm doing object-oriented programming either. Learning curves are never linear, but if it were, the curve for OO in C# would look something like: Level 0: God-classes, god-methods. Puts the entire program in the "Main" method. Level 1: Most of the logic is in "Main" or other static methods, with some working, mutable data stored in classes. No inheritance. Level 2: Logic and state are starting to get distributed between classes, but lumpily -- some classes are thousands of lines long and others are anemic. Inheritance is used, badly, as a way to avoid copy/pasting code. Short-sighted inheritance based on superficial similarities, like "Dog : Animal". No clear separation of responsibilities, but "private" is starting to make an appearance. If design patterns are here, they're used arbitrarily. Still lots of mutability around. This is "OO Programming" as taught in early textbooks. It's bad. Level 3: Methods and classes are starting to ask for contracts/abstractions instead of implementations. Inheritance hierarchies are getting smaller, include abstract classes, and are starting to be organized by need and functionality, rather than by superficial similarity; things like "TextNode : Node". Classes are clearly articulating their public surface vs. private details, with logic behind which is which. Generics are used, but mostly just with the built-in libraries (e.g. IEnumerable<T>). Design patterns are used correctly. Mutability is still everywhere. If interfaces are used, it's in that superficial enterprisey way that makes people hate interfaces: "Foo : IFoo", "Bar : IBar", for no discernable reason. This is "OO Programming" as taught in higher-level textbooks. Level 4: No more "Dog : Animal". If inheritance is used at all, it's 1 layer deep (not counting Object), and the top layer is abstract. Code de-duplication is done via composition, not inheritance. Fluent/LINQ methods like .Select() [map] and .Where() [filter] have mostly replaced explicit loops. A large percentage of the code is "library" code -- new data structures and services for downstream use. Generics are everywhere, and not just with standard-library classes. Interfaces are defined by the needs of their consumers, not by their implementations -- you may not even see an implementation of an interface in the same project it's defined (this is a code-fragrance; a good smell!). Liberal use of Func<> and Action<> has eliminated almost all of the explicit design patterns and superficial inheritance that used to exist. Mutable state is starting to be contained and managed, perhaps via reactive programming or by limiting the sharing of mutable objects. This doesn't look much like OO as taught in textbooks. Level 5: Almost all code is library ("upstream") code, with a clear, acyclic dependency graph. Inheritance is virtually absent; an abstract class may show up occasionally, but only because it hasn't been replaced with something better yet. Most code is declarative using fluent/functional-style methods on immutable data structures, like .Select() and .Where(). Where Level 4 may have abandoned that style at the limit of the "out of the box" data structures, Level 5 just writes their own immutable fluent/functional data structures when they need to. This means heavy use of interfaces, Func, and generics, including co- and contra-variance. It also means adapting ideas from the functional world, such as Monoids and the "monadic style" (but not an explicit Monad type, both due to the lack of higher-kinded types and due to the fact that Monad is a red-herring abstraction that is not useful on its own). Most code looks like it's written in a mini domain-specific language, whose output is not a result, but a plan (i.e. lots of lazy evaluation, but with sensible domain-specific data structures, not with raw language elements like LISP). Data is largely organized via relational concepts (see: Out of the Tar Pit), regardless of the underlying storage layer. Identity and state are separated. Data and function blend seamlessly. Mutability is almost exclusively relegated to the internals of an algorithm, mostly in said data structures. Virtually no mutable state is shared unless it's intrinsically necessary. If it is necessary, it's tightly controlled via reactive programming or something similar. A few performance-critical loops look almost like C, with their own memory models, bit twiddling, and other optimizations, but these are completely internal, private details, well commented and thoroughly tested. This looks nothing like OO Programming as taught in textbooks. It looks a lot more like functional programming (with some procedural sprinkled in) than OO. If there's a Level 6, I'm not there yet, nor have I seen it (or known what I was looking at if I did). So when I see someone say "programmers aren't doing OO programming", I don't know what that means. Only Levels 2 and 3 above look much like "object-oriented programming". If nobody told you C# was supposedly an "object-oriented language", and all you saw was Level 5 code, would you know OO was supposed to be the overriding paradigm? Are people avoiding OO programming because they can't do it, or because they evolved past it? To someone stuck at Level 3, Level 5 code might look unnecessary, overly complicated, whatever. It might look like code written by someone who doesn't know how to do OO.
• ChrisMarshallNY 4y ago
  I like and agree with much of the advantages of FP, but I’ve never used it exclusively. A number of years ago, we worked with a startup that was based around a new FP language, focused on image processing pipelines[0]. It’s actually quite cool. We came from a C++ background. Learning the language was difficult, but our team was very capable, and very experienced. We did it. But it was just too limited, and the advantages never appeared for us. We were doing it for an embedded implementation. It was a really neat experience, but ended up as a failure. I am sorry for that, as I actually thought they had the right idea, and I think that management failure was as much to blame as technical hurdles. The language had many limitations, but we were still able to work with it. That’s what you get, with a highly capable team. The startup we worked with, had some real rockstars. These days, I program in Swift, which has many FP features. I enjoy it. Nonetheless, I think that many of these “new paradigms” are built around the premise that most programmers suck, and need to be forced to write good code, which never seems to work. Companies seem to be desperate to hire crappy engineers, and get them to write good code, as opposed to hiring decent engineers, in the first place, who can write good code, regardless of the tools. [0] https://halide-lang.org/ https://halide-lang.org/
• IceHegel 4y ago
  I have found OOP better for thinking abstractly about complex systems.
• caporaltito 4y ago
  No.
• ArcMex 4y ago
  All this article has done is reinforce my desire to always consider the best paradigm for my use case.
• KingOfCoders 4y ago
  I wish this all was based on some kind of science.
• markdog12 4y ago
  Tangent: article has a useless 13.2MB gif at the top, with a "high" fetch priority.
• taeric 4y ago
  I find this an amusing take. I'd more fully accept "declarative should be the future of software." In that, at large, I'd rather larger chunks of the software I am responsible for to be declarations of intent, if at all possible. That said, the rubber still hits the road somewhere, such that the abstraction should be tailored to fit the domain, if you can. As a fun challenge, look at the definition of pretty much any fractal. It is a mathematical construct that is almost certainly not equivalent to what most "functional programming" environments let you do. Indeed, most definitions are imperative by nature, that I recall, and yet they work remarkably well. Really, anything from the book Turtle Geometry would have a challenging time in a lot of functional languages. Which is not that most functional languages are bad. Just they don't usually even try to abstract over the graphical. I hate that folks see how well the abstract over functions and assume that is all programming is.
  • BoiledCabbage 4y ago
    > Really, anything from the book Turtle Geometry would have a challenging time in a lot of functional languages. https://github.com/sergv/turtle-geometry https://github.com/sergv/turtle-geometry Is an implementation of the book Turtle Geometry in Scheme. A Lisp dialect. > Which is not that most functional languages are bad. Just they don't usually even try to abstract over the graphical. I hate that folks see how well the abstract over functions and assume that is all programming is. There is an entire section of SICP dedicated to graphical abstraction using functions and function composition.
    • taeric 4y ago
      Yeah, that isn't surprising, in that the book even mentions using LISP. However, this is a touch of a goal post shift with what folks typically mean by modern functional programming. (Which, to be fair, was always far more nebulous than folks admitted.) Specifically, though, this is my point. The turtle geometry abstraction is very imperative, by nature. It is still declarative, at a high level. But it is not functional. Despite that, it can be implemented in one of the classic functional languages. (Though, lisp's origins are far more imperative than you would think.)
• aryehof 4y ago
  I'm reminded of the following quote by the co-author of SICP - Gerry Sussman... "Remember a real engineer doesn't want just a religion about how to solve a problem, like object-oriented or functional or imperative or logic programming. This piece of the problem wants to be a functional program, this piece of the program wants to be imperative, this piece wants to be object-oriented, and guess what, this piece wants to be logic feed based and they all want to work together usefully. And not because of the way the problem is structured, whatever it is. I don't want to think that there's any correct answer to any of those questions. It would be awful bad writing a device driver in a functional language. It would be awfully bad writing anything like a symbolic manipulator in a thing with complicated syntax."
  • Rochus 4y ago
    A refreshingly pragmatic position for an academic. Where did you get that quote?
    • sk0g 4y ago
      From a quick google, likely from a talk on Youtube. Matching section timestamped - https://youtu.be/O3tVctB_VSU?t=2346 https://youtu.be/O3tVctB_VSU?t=2346
      • Rochus 4y ago
        Thanks. Very impressive to hear this from the Scheme pope himself. This should make all dogmatists think.
      • swyx 4y ago
        isn't it amazing in this day and age we can just google a 7 year old quote and basically pull up the actual video of it instantly and send it around timestamped? some days technology sucks, but other days its a wonder it works as well as it does
    • DonaldPShimoda 4y ago
      > A refreshingly pragmatic position for an academic. There are plenty of pragmatic academics. It just happens that academia is about the only place that the non-pragmatic people can find long-term career success, but that doesn't mean there aren't many pragmatic people in the same space.
• ww520 4y ago
  Functional programming helps because the lack of mechanisms in languages to manage state mutability. FP brings in the big ban, keeping things immutable, to make state management easier. When new languages like Rust that can automatically track state ownership, state management and mutability are much easier. You don't need to enforce immutability all the times, though it still helps. The need for FP's practices is actually lessen.
• AtNightWeCode 4y ago
  To have a program crash on null is a feature. There was a trend in OO caused by you know who that made people always initiate variables and return stupid things like empty lists instead of null. Among the worst APIs to work with are the ones where you never can tell when you get an empty list if something went south or if it is a correct state.
• dukeofdoom 4y ago
  Would be nice to have a functional language to construct images for something like midjourney
• rcarr 4y ago
  Functional programming people are the vegans of coding, change my mind
• water8 4y ago
• adamwk 4y ago
  This article reads like something from 2010. Other than Go, new languages no longer have null references and you don’t need a purely functional language to do so. I kept waiting for more examples for why we need FP but the article yada-yada-yada’d the rest I think FP came and showed everyone how to design expressive types, how to define flatMap on more than arrays, and that’s it. It turns out you don’t need Haskell, you can incorporate those features in imperative languages like Rust and Swift.
  • cheriot 4y ago
    The "blue collar" approach to functional programming is a fruitful one. Written about Scala, but applies to any language: https://www.lihaoyi.com/post/StrategicScalaStylePracticalTypeSafety.html https://www.lihaoyi.com/post/StrategicScalaStylePracticalTyp... In doing this, program organization starts to change in interesting ways. Modeling error states as regular data cleans up a lot of complexity.
  • siknad 4y ago
    > I kept waiting for more examples for why we need FP Dependent types, allow a lot more type safety (ex. shader program type parametrized by description of its uniform variables, getting rid of `INVALID_OPERATION` on wrong uniform location/type). > you can incorporate those features in imperative languages like Rust and Swift Incorporating dependent types into imperative languages with unrestricted effects is hard (impossible?).
• begueradj 4y ago
  Quoted: "OOP has, however, been wildly successful. It may be that this success is a consequence of a massive industry that supports and is supported by OOP." Link: https://stackoverflow.blog/2020/09/02/if-everyone-hates-it-why-is-oop-still-so-widely-spread/ https://stackoverflow.blog/2020/09/02/if-everyone-hates-it-w...
• z9znz 4y ago
  At the last two places I worked, I gradually led my teams from traditional OOP Ruby or Python behaviors to at least partially functional (if you'll pardon the pun). The immediate value I was able to demonstrate was in testing. Three basic (not too scary) principles can get you a long way: 1. push mutations and side effects as far toward the edges as possible (rather than embedded in every method/procedure) 2. strive for single responsibility functions 3. prefer simple built-in data structures (primarily hashes) over custom objects... at least as much as possible in the inner layers of the system If these steps are taken, then tests become so much simpler. Most mocking and stubbing needs evaporate, and core logic can be well tested without having to touch the database, the api server, etc. Many of the factories and fixtures go away or at least become much simpler. You get to construct the minimal data structure necessary to feed to a test without caring about all the stuff that you normally would have to populate to satisfy your ORM rules (which should be tested in their own specific tests). Once devs see this, they often warm up quickly to functional programming. Conversely, the quickest way to get an OOPist to double down and reject any FP is to build complex chains of collection operations which build and pass anonymous functions everywhere. Those things can be done where appropriate, but they don't provide as much early bang for the buck... and they likely prevent FP from getting a foot in the door to that team. The only real downside is that naming things is hard, and good single responsibility practices result in a lot more functions that need good names.
  • blep_ 4y ago
    > prefer simple built-in data structures (primarily hashes) over custom objects I've found this is actually one of my biggest problems with functional code as currently written: people seem afraid to just declare a struct/record, in lots of cases where it's obviously the right thing. If everything is a hash, you've just made all arguments optional and now you've invented a bad type system inside your good type system. If everything is a tuple (more common in my experience, from reading Haskell), now you know (int, int) is actually a pair of ints, but you've thrown away variable names and nominal typing: is it a 2D vector, a pair of indices into an array, or something else entirely? Defining custom types is the elegant solution to this: you have `struct range { start: int, end: int }` and now your functions can take a range and everything is great.
• 60secs 4y ago
  “Kindly let me help you or you will drown said the monkey putting the fish safely up a tree.” ― Alan W. Watts
• martin1975 4y ago
  Hammers ought to be used to solve every problem.
• pie_flavor 4y ago
  In a world where your two options are object-oriented and functional, functional is naturally superior. But just because the last twenty years have had all the oxygen sucked up by object-oriented does not mean there are no alternatives to it other than functional. Like all good IEEE articles, it's seven years out of date: Rust is one of the most maintainable languages around, simply by embracing good old fashioned procedural programming. And the only practical example they give, null pointers, have been a solved problem outside FP for an even longer time.
• plgonzalezrx8 4y ago
  No.
• rcgorton 4y ago
• revskill 4y ago
  Yes, in my production code, the real work is implemented by functions. Class method is just a proxy to the external world only.
• aappleby 4y ago
  Naah. ;)
• deterministic 4y ago
  Show us the commercially successful wonderfull code you wrote using functional programming and you will be 1000x more convincing than anything you claim in an article or religious face-to-face debate. For example, there are hundreds of glowing articles written about Lisp, making all kinds of amazing claims about the superiority of the language and the superior intelligent of people using it. However very little commercially successful software is written in Lisp. Making those claims laughable and not convincing at all. Less talking more walking!
• bob1029 4y ago
  I'd strongly recommend checking this paper out: Out of the Tar Pit - http://curtclifton.net/papers/MoseleyMarks06a.pdf http://curtclifton.net/papers/MoseleyMarks06a.pdf I agree that functional programming is part of the future. I believe that the relational model is the other part. In this space, imperative programming exists primarily to bootstrap a given FRP domain. We've built a functional-relational programming approach on top of SQLite using this paper as inspiration. Been using this kind of stuff in production for ~3 years now. Remember - Your user/application defined functions in SQL do not need to be pure. You can expose your entire domain to SQL and build complete applications there, with the domain data & relational model serving as first-class citizens. With special SQL functions like "exec_sql()" and storing your business rule scripts in the very same database, you can build elegant systems that can be 100% encapsulated within a single .db file.
• fulafel 4y ago
  The article discounts dynamic FP languages that most real world delivered FP code is written in (Erlang/Elixir, Clojure, etc). The claimed "the top dozen functional-programming languages" list is also missing Scala, Ocaml/ReasonML, etc. I can understand wanting to focus on your preferred FP subdisciplines (statically typed purely functional languages) but it seems eliding any mention of this will be confusing the readership since IEEE Spectrum is targeted at a general engineering audience.
• DeathArrow 4y ago
  >Functional programming has a steep learning curve Not really. Learning and using F# is not hard. Same for using JS in a functional manner. >To reap the full benefits of pure functional programming languages, you can’t compromise. You need to use languages that were designed with these principles from the start. Yes and no. F# was designed with functional principles, but you can compromise and you don't have to write 100% functional code.
• axilmar 4y ago
  I will certainly be downvoted for this, but I want to be honest so here it is anyway: In all my programming years, 20+ years that is, I've met hundreds of programmers, and 95%+ of them handled imperative programming languages just fine, with very few actual bugs coming from each one. Each time there is such a conversation, I have yet to see some actual concrete proof that functional programming provides a substantial increase in productivity over well-implemented imperative code. In other words, I am still not convinced about the merits of functional programming over imperative programming. I want some real proof, not anecdotal evidence of the type 'we had a mess of code with C++, then we switched to Haskell and our code improved 150%". Lots and lots of pieces of code that work flawlessly (or almost flawlessly) have been written in plain C, including the operating system that powers most of Earth (I.e. Unix-like operating systems, Windows etc). So please allow me to be skeptical about the actual amount of advancement functional programming can offer. I just don't see it.
  • urthor 4y ago
    I agree fully. My viewpoint, as a functional programmer, is software is a young field. We don't know much of anything about it. We're living in the first 100 years after the Gutenberg printing press. All I know is NLP code generation will be a dramatic change. Everything else, we are still figuring out.
  • ronanyeah 4y ago
    I think personal experience with multiple paradigms is essential for a developer to decide which one they prefer. The opinions of programmers who have only used one paradigm are less than worthless, since they are demonstrating a basic lack of curiosity and lack of willingness to invest in their craft. You can always find excuses not to learn.
• Freebytes 4y ago
  The goto statement exists in most modern languages. Even C# has a goto statement, and while I have only used it once or twice in the past 10 years, it still has a purpose -- effectively breaking out of multiple loops if you are within more than one. That is, break will only break out of the inner most loop. It can save a lot of resources sometimes to break out of both. Normally you would not want to put yourself in such a position, but it happens and comes in handy.