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.<p>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.<p>Most popular languages have added a lot of functional features in recent years so it’s clear the world is moving that way, imo.
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.<p>Anecdotally, the tooling is why I gave up on Ocaml (given Rust's ML roots, I was seriously interested) and Haskell. I <i>seriously</i> 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.<p>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`.
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.<p>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.<p>The minute people start trying to force things to be all functional or all OOP, then you know they've lost the plot.<p>[] I have been wanting to learn lisp for over a decade, I just never get around to it.
Imo functional programming is one of those things that makes sense from a theoretical perspective, but comes with compromises when it comes to reality.<p>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.<p>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.
I will certainly be downvoted for this, but I want to be honest so here it is anyway:<p>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.<p>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.<p>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%".<p>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).<p>So please allow me to be skeptical about the actual amount of advancement functional programming can offer. I just don't see it.
I immediately distrust any article that makes sweeping claims about one-paradigm-to-rule-them-all.<p>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.<p>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.<p>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)
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.
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:<p>> 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.<p>> 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.<p>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.<p>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.<p>[1]: <a href="http://www.paulgraham.com/aord.html" rel="nofollow">http://www.paulgraham.com/aord.html</a>
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.<p>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).<p>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.<p>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.
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).<p>The immediate value I was able to demonstrate was in testing. Three basic (not too scary) principles can get you a long way:<p>1. push mutations and side effects as far toward the edges as possible (rather than embedded in every method/procedure)<p>2. strive for single responsibility functions<p>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<p>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).<p>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.<p>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.
Functional or procedural or whatever, it doesn't matter much for me as long as the paradigm is not OOP.<p>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.<p>I do believe in a data oriented programming where we waste as little CPU cycles as possible and introduce as little abstractions as possible.
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.
Maybe it ought to be but it definitely isn't if you look at success as industry adoption.<p>The author seems to have good intentions and covers all the talking points a new convert will discover on their own.<p>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.<p>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.<p>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.<p>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.<p>A good talk, <i>Why Isn't Functional Programming the Norm?</i><p><a href="https://www.youtube.com/watch?v=QyJZzq0v7Z4" rel="nofollow">https://www.youtube.com/watch?v=QyJZzq0v7Z4</a>
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.<p>When I was going through Functional Programming classes in Haskell, the teacher tried to separate total programming and functional programming.<p>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.<p>Does anyone else try to separate functional programming and total programming?
I'm reminded of the following quote by the co-author of SICP - Gerry Sussman...<p>"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."
I'd strongly recommend checking this paper out:<p>Out of the Tar Pit - <a href="http://curtclifton.net/papers/MoseleyMarks06a.pdf" rel="nofollow">http://curtclifton.net/papers/MoseleyMarks06a.pdf</a><p>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.<p>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.<p>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.
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.
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.
> 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.<p>This is demonstrably false, as C has always had a goto and its use by custom and in practice is greatly circumscribed.
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 <a href="https://queue.acm.org/detail.cfm?id=2038036" rel="nofollow">https://queue.acm.org/detail.cfm?id=2038036</a> instead.<p>Why did the GOTO statement fall out of favor with programmers? If you look at Knuth's famous article weighting the importance of GOTO (<a href="https://pic.plover.com/knuth-GOTO.pdf" rel="nofollow">https://pic.plover.com/knuth-GOTO.pdf</a>) 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.<p>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(<a href="https://www.microsoft.com/en-us/research/uploads/prod/2020/11/perceus-tr-v4.pdf" rel="nofollow">https://www.microsoft.com/en-us/research/uploads/prod/2020/1...</a>). This does not break the benefits of immutability, as other program parts can not observe this mutation.<p>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!
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 <i>drumroll</i> "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.<p>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.
I like and agree with much of the advantages of FP, but I’ve never used it exclusively.<p>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.<p>Learning the language was difficult, but our team was very capable, and very experienced. We did it.<p>But it was just too limited, and the advantages never appeared for us. We were doing it for an embedded implementation.<p>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.<p>These days, I program in Swift, which has many FP features. I enjoy it.<p>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.<p>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.<p>[0] <a href="https://halide-lang.org/" rel="nofollow">https://halide-lang.org/</a>
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).
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<p>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.
ML language != functional programming. There is more out there than Haskell.<p>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.
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.<p>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.<p>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.
The first text sums it up:<p><pre><code> It’s hard to learn
</code></pre>
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.<p>as long as humans are employed to write the code directly, "hard to learn" is a non starter for being the "future".
Hybridization of object-oriented and functional approaches seems like a decent approach to theses problems.<p>> "Nearly all modern programming languages have some form of null references, shared global state, and functions with side effects..."<p>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.<p>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:<p>> "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”"<p><a href="https://ebrary.net/65011/computer_science/separation_application_code_state" rel="nofollow">https://ebrary.net/65011/computer_science/separation_applica...</a>
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.
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.
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.
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.
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.
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."<p>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.
Oh, scalfani, he was quite invested in FP talks too.<p>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.<p>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.
The properties mentioned in the article are not really tied to functional programming.<p>- 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.<p>- Immutability can also be done with every paradigm. The Java String for example is both object-oriented and immutable.<p>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.
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 <i>only</i> practical example they give, null pointers, have been a solved problem outside FP for an even longer time.
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 <i>actually</i> 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.
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.<p>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.
>Functional programming has a steep learning curve
Not really. Learning and using F# is not hard. Same for using JS in a functional manner.<p>>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.
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.
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."<p>Link: <a href="https://stackoverflow.blog/2020/09/02/if-everyone-hates-it-why-is-oop-still-so-widely-spread/" rel="nofollow">https://stackoverflow.blog/2020/09/02/if-everyone-hates-it-w...</a>
JavaScript is functional if you write in functional.<p>There's nothing stopping you from writing pure functional code in JavaScript or TypeScript.
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.
As long as I can avoid the mess of oop and inheritance, I'm happy.<p>Good oop is only found in a very small amount of libraries.<p>In don't want "reusable oop code", i want fonctions that returns data. Side effects are impossible to keep track.<p>Of course you can't use fp everywhere, but oop should not be the default.
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.
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...'<p>like, really?
The programming world peaked with structured and modular styles. Everything else is random noise.<p>Keep your programs nicely structured and easy to follow. No code "architecture" nonsense, please.
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.
Can I state for the record that almost every C compiler still supports GOTO?<p>Rust supports the best traits of both Functional and Imperative languages.<p>Ergo: The future is Rust. Rust is the future.
Functional programming fixes what ails you!<p>How do I know? A thought leader told me so!<p>Nothing against functional programming, which certainly has its uses and advantages, but this article is basically substance-free.<p>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.
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).
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.<p>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.<p>Less talking more walking!
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
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.