Should Functional Programming Be the Future of Software Development?

The CTO of a software company argues the software industry's current trajectory "is toward increasing complexity, longer product-development times, and greater fragility of production systems" — not to mention nightmarish problems maintaining code.

"To address such issues, companies usually just throw more people at the problem: more developers, more testers, and more technicians who intervene when systems fail. Surely there must be a better way," they write in IEEE Spectrum. "I'm part of a growing group of developers who think the answer could be functional programming...." Today, we have a slew of dangerous practices that compromise the robustness and maintainability of software. Nearly all modern programming languages have some form of null references, shared global state, and functions with side effects — things that are far worse than the GOTO ever was. How can those flaws be eliminated? It turns out that the answer has been around for decades: purely functional programming languages....

Indeed, software based on pure functions is particularly well suited to modern multicore CPUs. That's because pure functions operate only on their input parameters, making it impossible to have any interactions between different functions. This allows the compiler to be optimized to produce code that runs on multiple cores efficiently and easily....

Functional programming also has a solution to Hoare's "billion-dollar mistake," null references. It addresses that problem by disallowing nulls. Instead, there is a construct usually called Maybe (or Option in some languages). A Maybe can be Nothing or Just some value. Working with Maybe s forces developers to always consider both cases. They have no choice in the matter. They must handle the Nothing case every single time they encounter a Maybe. Doing so eliminates the many bugs that null references can spawn.

Functional programming also requires that data be immutable, meaning that once you set a variable to some value, it is forever that value. Variables are more like variables in math...

Pure functional programming solves many of our industry's biggest problems by removing dangerous features from the language, making it harder for developers to shoot themselves in the foot.... I anticipate that the adoption of pure functional languages will improve the quality and robustness of the whole software industry while greatly reducing time wasted on bugs that are simply impossible to generate with functional programming. It's not magic, but sometimes it feels like that, and I'm reminded of how good I have it every time I'm forced to work with a non-functional codebase.

No

[Anonymous Coward]

No

Re:No

[Anonymous Coward]

I agree. I was on board until I came across this nonsense:

"... requires that data be immutable, meaning that once you set a variable to some value, it is forever that value. "

That's not a description of a variable, that's a constant. Apparently someone doesn't understand the meaning of "variable".

Re:

[raynet]

I think they managed to somehow mess up the description. The point should be that variables cannot be modified, you just create new variables. X=1; Y = X+1; Z = function_foo(Y), etc. And that function should return the same thing for same parameters. Though I think that is for ideal functional languages, they all need to deal with side effects in order to talk to the real world.

Re:

[Anonymous Coward]

I think they managed to somehow mess up the description. The point should be that variables cannot be modified

And, once again, what you are describing is a constant, not a variable. You don't seem to understand the meaning of the word "variable" or why they exist.

The whole point of a variable is that you have something whose value changes or is expected to change, and you need to report the current value:

The current outside temperature
The speed of your car
etc...

A variable that does not change is pointless and useless. The fact that stupid programmers do stupid things doesn't eliminate the need for var

Re:

[Zarhan]

Well, there actually is a difference between constant and immutable variable - it's whether it's evaluated during compile time or not. Constants are more or less just inlined into the code by compiler. Immutable variables (e.g. in Rust) actually have a location in memory, so you can have references to it.

Re:

[Joce640k]

An immutable variable is no longer a variable.

Stop ratfucking words to try and make them mean what you want them to mean.

What if it's read from a configuration file on startup? It's a variable, but there should be no way to alter it after initialization.

Moron.

Re:

[DrXym]

In Rust a variable is a runtime binding to a value. The binding may or may not be mutable but it's still a variable in that the binding points at something in memory that was put there by code execution. A const in Rust is a value evaluated and inlined by the compiler so it is not a binding although it might be bound to a variable by assignment.

This is in contrast to C++ where const has overloaded uses, only one of which is for const variables.

Re:

[Shimbo]

And, once again, what you are describing is a constant, not a variable. You don't seem to understand the meaning of the word "variable" or why they exist.

Fortunately you're posting as AC, because you're just making yourself look ignorant. Yes, getting your head around FP is hard because it's rooted in mathematical principles that are alien to most programmers. You have to get beyond 'I do not understand this, so it must be wrong' though.

Re:

[account_deleted]

Comment removed based on user account deletion

Re: No

[reanjr]

But that's how math works. When a math book talks about the variable "x", they're not talking about a mutable value. The value "x" is what it is. It does not vary in the mathematical sense.

People are essentially getting confused between how programmers and math use the term "variable".

Re:

[angel'o'sphere]

A variable in math usually has no value.
It is a *Name* which stands for every value that reasonable can be used. It is most certainly not a constant.

https://math.fandom.com/wiki/G... [fandom.com]

First example, the variable is 'n'. You can write a function that calculates the resulting value for every n you desire. Inside of such a function, you could consider n a constant - a parameter that is not changed from the inside.

From outside, it is ofc a variable.

Perhaps a corner case ...

Re: No

[NagrothAgain]

The difference between a constant and an immutable variable, is that a constant is known at compile time, where an immutable variable is not known until runtime. Most of the time it's pointless to make any distinction between a regular variable and an immutable one.

Re:

[suutar]

Typically that means you're in a loop, which is something else that functional languages don't do much. They're much more likely to just invoke themselves recursively, at which point they're declaring a new variable with a new, up to the moment value, and acting on that.

Re:

[dfghjk]

Recursion is looping, and running out of stack is running out of memory.

Re: No

[suutar]

Tail call optimization is also a hallmark of functional languages for just that reason

Re:

[Alexey Nogin]

FP variables are const by default, and have to be explicitly made mutable.

Your code is actually a perfect example. In C:

const float X = Get_Current_Spped();
Display(X);

In an ML-style FP language:

let X Get_Current_Spped() in
Display(X)

In both cases, you are not changing X - you are creating a new X every time, keeping the previous X unchanged.

Re:

[musicmaker]

And thus demonstrating a spectacular misunderstanding of reality. The temperature doesn't "change". It is measured at a different value at one time index and another time index. For a given moment in time, the temperature _was_ the temperature. It didn't become different when indexed correctly. Your model of reality is, as with most programmers, the fundamental problem. it's missing at least one important axis. When you philosophically correct that missing axis, you end up with an immutable model. Because

Re:

[shmlco]

While I get your point, in reality most software exists to manipulate state. Take some form of input, manipulate it, and output that result.

A text file could exist as a function of every single keystroke logged into it and then painstakingly recreated... or it could exist as a piece of state upon which actions are performed. One could argue that the text could be immutable and typing into it gives yet another immutable text file... but something, perhaps call it a variable... must contain a reference to wha

Re: No

[D.McG.]

Take a banking system for example. Transactions are only ever added to the database. Any corrections/deletions are actually new transactions added with a full history of what happened; rather than just a variable representing the current balance. A balance is just the sum of all positive and negative transactions that have cleared by a specific time (the input parameter to this function). So your analogy to a text file should be more like how git version control works. Prior to commit, we rely on undo/redo

Re:

[shmlco]

Banking transactions are stored over time, true... but usually in turn manipulate numbers contained in a little piece of data called an "account" which has a mutable balance that's the current sum total of all of the aforementioned transactions.

Again, when a cash machine queries your account to obtain your current balance it grabs that number from the account. It doesn't attempt to recompute the sum total of all of your transactions since day one.

And, practically speaking, even the list of transactions is a

Re:

[caseih]

Even a single class in programming language theory (particularly lambda calculus) can clear up your confusion. In mathematics "variable" refers to a symbol that can represent a value, usually brought in from outside of the function. F(x) for example. x is a variable that is set to the value passed to the function and represents that value all throughout the function's body. Assigning to x makes a new variable; it does not mutate the original variable. This may seem to you to be a trivial distinction.

I c

Re: No

[maartz]

You donâ(TM)t seems to understand what immutability is. Whenever you set x = 1, in Erlang you canâ(TM)t say x = x + 1, mathematically it makes sense. Nevertheless, you can assign y to be x + 1. But the key is to pass the data as a parameter of your functions. After all, the data is what we care about. Say you have a function foo, it takes data and a modification function. Foo is pure, no side effects inside foo. Well you can reason about foo and known ahead of time what the output of foo will be.

Re: No

[ArmoredDragon]

I think that -- bottom line -- type hierarchy is evil. C++ programmers will shit bricks over this comment, but it's just fucking true. Inheritance in general is just a giant source of bugs, and makes your code a lot less readable.

I'm sure angel o' sphere will give us all an example, using linked lists, of why I'm wrong, but his level of expertise is so out of this world that it simply doesn't belong in this world.

Re:

[gtall]

C++ has a weak type hierarchy. In most functional languages with strong type systems, entire computations are typed. Use a function incorrectly with respect to its type and the compiler chucks out a hairball.

Re:

[sfcat]

Funny part is, FP languages are heavily typed these days. LISP and Clojure are not very popular at all. Also, I think the real problem is that in OOP languages we try to make all typing work through the idea of OO. Most types are not a thing that belongs in a heirarchy. However, there are plenty of things that do. The problem is trying to make 1 mathematical typing framework handle all the various ways that programmers will want to use types. It is the idea of the "one true thing" that is the problem.

Re:

[angel'o'sphere]

Modern OO languages are either an FP/OO mix, like OCaml or Scala, or are close enough to FP, that laymen don't know the difference. They key about FP is: functions are types, and values, aka objects, I suggest to google "higher order functions".

Neither the article/summary, nor any comentor above realy grasps what FP is, calling a function that only works on its argument, and has no side effects, wow: you can do that in any language. That is not the key of FP. The key is that functions are values, like 1, 2

Re:

[angel'o'sphere]

No, I don't give you examples.
Why would I?

Of course you are wrong.

If you had written your comment like this: Wrong used Inheritance in general is just a giant source of bugs, and makes your code a lot less readable.
You had a point. But you id not write it like that.

And side blows like this: I'm sure angel o' sphere will give us all an example, only makes you look like an asshole. Congratulations, you look like an asshole in the internet. I guess you managed that in every forum ...

Re: No

[dbialac]

One of those side effects is the complexity of multiple variations of functions needed to return a different value of an otherwise identical function. Also, there's the issue of the misleading claim that you spend less time programming. You do, but it's because it takes 10x as long to figure out what you're writing.

Re:

[JustAnotherOldGuy]

"No" is how I'd answer if someone asked me if you knew what the word "variable" means.

variable /verb()l/
1) not consistent or having a fixed pattern; liable to change.
2) able to be changed or adapted.
3) an element, feature, or factor that is liable to vary or change.

constant /känstnt/
1) a situation or state of affairs that does not change.
2) remaining the same over a period of time.
3) a number or value expressing a relation or property which remains the same in all circumstances

Re:

[rudy_wayne]

The author is supposedly the CTO of a software company with 40 years of experience. And yet here is his ridiculous example:

For example, to compute a formula, y = x2 + 2x – 11, you pick a value for x and at no time during the computation of y does x take on a different value. So, the same value for x is used when computing x2 as is used when computing 2x. In most programming languages, there is no such restriction. You can compute x2 with one value, then change the value of x before computing 2x.

In the formula y = x2 + 2x – 11 where does it change the value of X? It doesn't. This is a strawman argument of the worst kind. It's not even a strawman, it's just ... weird.

Re:

[Brain-Fu]

The reasons put forth in the article utterly fail to address the root causes of all the complexity being lamented here. The language isn't what is at-fault, it's the demands made by the clients.

Companies need to produce software quickly, or their clients will buy from other companies. Producing software quickly means taking a profit-in-the-short-run attitude. Engineers hate this with the passion of a thousand burning suns. It is in their DNA to take a long-term view and to want to write code that is wel

Re:

[angel'o'sphere]

So, we adopt agile development methodologies and just slop out barely-functional crap with a shiny coat of paint to make it look nice, and never ever go back to refactor anything (unless occasionally forced, in which case we do the bare minimum of refactoring necessary to get something barely functional again).
Then you are not agile.
I suggest to look up an agile method. XP (extreme programming) would be a start - Scrum an optional second.

Re: No

[zarr]

It's exactly what tends to happen in concurrent programs with mutable state. Another thread changes the value of x during the evaluation of the expression, you can fix it with locking, or just realize that immutable state is automatically thread safe.

Re:

[sfcat]

It's exactly what tends to happen in concurrent programs with mutable state. Another thread changes the value of x during the evaluation of the expression, you can fix it with locking, or just realize that immutable state is automatically thread safe.

This is true, however it is also very slow. So if you don't really care a lot about making your code fast, then this is the way to go. If you want your code to be efficient, then you have to use locking and reuse memory. That means writing to mutable memory (variables). The tradeoff is a 10x improvement in performance (and thus a 10x reduction in your cloud bill). It depends on what the use case is, if you are trying to make it cheap to write but expensive to operate, then what you say is correct. If

Re:

[angel'o'sphere]

This is true, however it is also very slow.
In general this is wrong.

The tradeoff is a 10x improvement in performance (and thus a 10x reduction in your cloud bill)
That is nonsense. You should once actually try functional programming.

If FP is better than standard structural programming, or opposite around, depends on the problem.
There is no general rule at this approach or that one leads to faster code. most of the time however FP is actually faster, as the compiler can use more straight forward optimizatio

Re:

[dfghjk]

The value of X doesn't change in the formula, but it may be changed in another piece of code. For example and event callback or an ISR or another thread.

It is not a straw man argument, just an attempt to explain something to you that failed.

Instead of X, call the variable clockCount. Hopefully now you can see how the count might change during the Y computation.

Re: No

[LindleyF]

Multithreading could change x during evaluation, and that would be a bug. There are other ways to avoid that than immutability, of course, but that would do it.

Re:

[gtall]

So the variables of mathematics are now constants?

Re: No

[gnasher719]

Thatâ(TM)s what other languages call immutable variables. For example in Swift, a mutable variable must be set at least once before being used, an immutable variable must be set _exactly_ once, in both cases in a way that the compiler can verify. Obviously an immutable field can have a different value each time a method is called, and an immutable object member can have a different value in each object, so âoeconstantâ is not appropriate in many cases.

Re:

[JustAnotherOldGuy]

"... requires that data be immutable, meaning that once you set a variable to some value, it is forever that value. "

Yes, I laughed when I read that.

He used the word "variable", but I do not think that word means what he thinks it means...

Re:

[allcoolnameswheretak]

Yes.

You need a while to grok it, but once you do, FP is awesome.
And you can use most of its principles in OOP languages like Java and C#, though FP really starts to shine once you use a pure FP language like Haskell.

You're not the first to ask this

[Anonymous Coward]

This idea comes up over and over again. Every time some n00b discovers functional programming.

Everyone should know what functional programming is and learn how to use it. The methods and ideas help when using any programming paradigm. It is not the answer for everything though. Not even most things.

Re:

[INT_QRK]

Agree. Anyway, the answer to everything is 42 as far as I know.

Re: You're not the first to ask this

[zarr]

Most mainstream programming languages are slowly drifting towards functional programming anyway. Look at the release notes for the new version of c# released just this week. Improved pattern matching (switch statement), and "generic math" (exemplified by a monoid implementation). Other recent examples are immutable record types, type inference and lambdas. They should just take the plunge and give us typeclasses. Java, python and typescript all moving in the same direction.

Jesus Christ

[backslashdot]

What is this Friday the 13th? This shit just won't die.

Why

[Tailslide]

It seems like there is always a lot of wishful thinking going on in software development that goes something like this: If I can find the right magical technology, I donâ(TM)t have to hire expensive people with skills and experience and somehow my project wonâ(TM)t turn into a giant mess.

Re:

[rudy_wayne]

Yes. It is the same thinking that is driving the development of "Artificial Intelligence". Although there are many legitimate uses for A.I., the primary driving force is pointy-haired bosses dreaming of a glorious A.I. future where all the work is done by A.I.-powered robots and they no longer have to pay any employees, allowing them to keep all the money for themselves.

Re:

[Dixie_Flatline]

I don't think you read the article, then.

The author doesn't think this will take no effort and zero training. He says it requires a shift in thinking, and there's a steep learning curve.

But he does think the tradeoffs are worth it. That you can write better code with fewer errors if you eliminate a huge source of the errors.

Maybe he's right; I'm not convinced. Storing state is awfully handy. Mutating variables usually makes more sense intuitively than modifying a stream of data in flight so you can pass it

Re:

[caseih]

I find Python generator expression to be very intuitive and allow a more functional approach to programming over imperative. A lot of times I can completely eliminate the need to store state for some tasks. Plus closures and lambda expressions have a real place. We can all benefit from functional principles and constructs without having to be purists. I have yet to understand how a monad is used.

Yeah, sure, let's all switch over to LISP

[Zarhan]

Obligatory xkcd, https://xkcd.com/297/ [xkcd.com]

Functional programming languages definitely have their use cases, but the article in this case is not all that convincing to use that *everywhere*.

Re:

[znrt]

well, if it weren't for the headline! betteridge rarely fails.

i usually rtfa, but with these headlines ... there is no point in wading through any ramblings attempting to justify such an utterly stupid headline, the author has made it bloody obvious from the start that he has no clue whatsoever about software. 99.999999% probability of bullshit that most likely isn't even funny.

My 1980+ Experience Says Modern Languages Suck

[Slicker]

I noticed the trend of increasing complexity around the year 2000 and have been horrified by surprisingly increased measures each year, ever since.

It truly seems that most frameworks, libraries, and tools nowadays make work much harder, less reliable, and slower. At first, I migrated form C to C++ and became a big advocate of OOD and OOP but gradually came to accept that it failed in every objective. I do like OO in Javascript better and think it gives clues as to how a far better mechanism could be created. The .Net library is also overly complicated and breaks backward compatibility with each major upgrade. Strict data types and objects as parameters make for huge headaches and complexities trying to tie things together, even in the same language. How many kinds of null do you have to work with in C# and T-SQL for example? many.. why?? Why do I have to hunt through various class files to find all the required parameters to a method and ready an encyclopedia to understand what it returns?

I strongly blame the tendency of trying to make other coders better by restricting them, in various ways. Why strict data types? Why private/public/protected, etc. classes?

On the other hand, I don't advocate functional languages like GO, as the solution, even if it is a lot better to work with. Safe strings are great and its approach to errors and multiprocessing are great (although the V language has an even better approach to dealing with exceptions and Rust has a terrible way).

I think Javascript was a stroke of accidental genius. It was supposed to be a simple learning language without strict types and complex classes/interfaces, etc. Those things the inventors of Java throught we advanced and lead to better software were huge mistakes and the opposite is the direction I wish we would go. In 99% of cases, the compiler will be better at determining underlying data types than you. Reflection on data structures allows for quick and easy checking of what objects look like and, can even allow you to behave different based on it, leading to easy to produce backward compatibility in libraries, among other things. Also, you don't need lambdas with anonymous functions and functions being passable objects. You have reusability in that an object's "this" will refer to whatever its under. Furthermore, it's much faster executing than classical OO that has to do gazillions of memory allocations when instantiating a class -- not to mention the underlying factor code required to do that bloating your binary.

I think the best language would be similar to Javascript with aspects of ADA, GO, and V. ADA's ability to add constraints on data types for safety makes sense, as an option but not the rule. As a rule, it should be typeless (determined intelligently by the compiler). It should use V's method of exceptions (implicit in the return from any function), and GO's approach to multiprocessing and small vocabulary (also true with V) -- but get rid of := (it's ugly). And objects should be as they are in Javascript (vastly superior to C/C++/java/GO/V structs and so on). However, we could improve in some ways. For example, cascading prototypes and make every function a true and complete object and vice-versa.

If you just go functional like in GO, then you will come to realize that its just objects in the form of packages. In effect, a different syntax without inheritance, etc.. just really basic object-based, in effect... not object oriented but still. Packages are the most annoying part of GO, for me. Inflexible weak structures are the most unfortunate part, for me. Everyone has opinions, of course.

Above all -- a language should make your work easier... and reduce your work... lead to fewer bugs. Strictness and authoritarianism sound like they would do that but in practice, they do the opposite.

Re:

[Artenzio]

I think Javascript was a stroke of accidental genius

As a rule, great projects never start out by someone thinking "I'm going to make a great project"

Re:

[Anonymous Coward]

Corollary: great projects never start (or end) with javascript.

Re:

[DrSpock11]

The .Net library is also overly complicated and breaks backward compatibility with each major upgrade. Strict data types and objects as parameters make for huge headaches and complexities trying to tie things together, even in the same language.

Are you sure you've ever actually used .NET? This couldn't be father from the truth. Microsoft is terrible at many things, but backwards compatibility is one of their few strengths. New .NET versions are extremely backwards compatibility. You could have a .NET Framework 1.0 program written in 2002 and compile it and run it with the latest bits with no problem whatsoever.

How many kinds of null do you have to work with in C# and T-SQL for example? many.. why??

Again, no idea what you're talking about. C# and T-SQL both have exactly one null type. On the contrary, the language that you claim to enj

Re:

[MobyDisk]

100% agreed. I can't figure out what language they are referring to, but it sure isn't .NET.

Re:

[Some Guy]

I noticed the trend of increasing complexity around the year 2000 and have been horrified by surprisingly increased measures each year, ever since.

Agreed.

...I don't advocate functional languages like GO...

Ummm... go's not a functional language - it's imperative.

Re:

[MobyDisk]

I must chime-in with the others who are pointing out that nothing in that post makes any sense at all. Every paragraph is just backwards from reality.

• * .NET has almost perfect backwards compatibility from version-to-version. This is one if its strengths, not weaknesses.
• * GO is not a functional language.

The Javascript part is the most thoroughly confusing:

• * Javascript is not a strong OOP language. The OO features were only bolted-on in recent years. That is a big part of the motivation for many lan

Re:

[ScooterBill]

Don't disparage the boomer. I'm a boomer too. I was a hotshot programmer in the 80s. C, C++, Pascal and my favorite Assembly.
After retiring I decided to try some software/hardware projects to amuse myself. At first I thought software development had gotten overly complicated. I didn't think any real progress had been made.
Fast forward a bit and I see there has been progress. Just working with Python and ROS, you can actually enjoy writing code for your robot. The IDEs have improved too. That said, I

No Language is Best at Everything

[Flwyd]

No single programming language, or programming paradigm, is the best choice for solving all problems. There's a reason most operating systems and device drivers are written in C, despite fifty years of null pointer and buffer overflow errors.

"Side-effect free" and "functional programming" are different concepts, and one does not imply the other. Many LISP dialects allow side-effects like setting a value in an array. And many languages with an imperative core allow programming in a functional style, taking Kotlin and Ruby as just two examples.

Furthermore, "no side effects" isn't actually what I want in a programming language. If it doesn't have any side effects, why am I running the code? Data needs to be saved, logs need to be written, remote APIs need to be called, payments need to be debited and credited, emails need to be sent. I don't want a programming language that makes it difficult to produce a side effect, I want a programming language that makes it easy to reason about all the side effects my program produces. Functional languages may or may not do a good job of that, just as some imperative languages are better or worse at that.

The solutions to the author's problem of "increasing complexity, longer product-development times, and greater fragility of production systems" are to separate components (e.g. via microservices) so that it's easy to reason about, test, deploy, and fix failures in an individual piece of the overall system. Given the choice of a million lines of C++ code split into 200 independent services or a million lines of Haskell in a monolithic binary I'll take the -crab juice- C++ any day.

Re:

[hackertourist]

Furthermore, "no side effects" isn't actually what I want in a programming language. If it doesn't have any side effects, why am I running the code?

It seems to me you're conflating intended effects with side effects. 'save some data to a file' is something you intend to do, not a side effect.

Where it works, great...

[Junta]

Functional principles are good to be aware of and to take time to consider how they apply to the current scenario if reasonable.

However, like everything else, it's not the inherently better way, and in some cases trying to go functional can be maddening. The caller ends up having to own a lot more of the logistics, and while that makes for some more disciplined resource handling and fewer surprise side-effects, it also makes the task frequently far more tedious to carry out. Sometimes it's very awkward to burden the caller with a concern that normally the implementation would transparently handle, and it's hard to avoid that scenario in an absolute functional programming strategy.

Always has been, always will be.

[Serif]

I've been programming in various functional languages for over 30 years. Depending on the application area they can have big advantages or be a real pain to work with. Proponents have pushed a number of features over the years that continually resurface in slightly different forms, two of which are their suitability for large scale concurrency and formal correctness proofs. Both of these are possible using non-functional languages. I would still use a functional language, or at least use the functional feat

I'd settle for proof of correctness ...

[davidwr]

... type-safety, memory-safety, and all the other goodness that makes it very hard for me to overlook something dangerous.

Except of course in the real world sometimes you need to "be unsafe" for the sake of efficiency, and sometimes there's no useful provably-correct algorithm to solve a given problem.

So how about this: "By default" use languages and language features that make it easy for the computer to enforce various safeties and which make it easy to do a proof-of-correctness if one is possible.

BUT ha

Betteridge has you covered

[Bu11etmagnet]

I'll just leave this here:
https://en.wikipedia.org/wiki/... [wikipedia.org]

"Billion Dollar Mistake"

[DrSpock11]

I wish the industry would get over this "billion dollar mistake" nonsense. The concept of a nothing/unknown value must exist to model the real world. Whether you call that null or Maybe is meaningless. The only real difference I've seen in language implementations is whether it is an error to call method on a null value or not. There are pros and cons to having it both ways.

The past decade has seen several major languages either be non-null by default, or introduce nullability tracking on type of their existing type systems. As far as I know, there have been no studies indicating major reduction in bugs or development time from introducing these features.

Re:

[sfcat]

It is worse than that. Calling null the BDM is to completely misunderstand what Tony was saying. He wasn't saying nulls were the problem, it is segmentation faults which are the problem he was discussing in that quote. Also, the idea of fail fast programs instead of making programs resilient to failures. So basically they are twisting what someone who is dead (and thus can't correct their mistake) said into something that benefits their marketing. FP is useful, but it is normally only used in places wh

Null objects

[gnasher719]

You donâ(TM)t need functional languages to avoid null pointers. Swifts optional values do this very efficiently. And they allow everything to be optional. And since optionals are just syntactic sugar for an enum, for every type we can have any number of different cases.

Re: Null objects

[zarr]

Most advances in mainstream programming languages these days are concepts pilfered from functional languages. Optional is just Haskell's Maybe.

Functional programming != Optional pattern

[peppepz]

What does the "optional" pattern has to do with functional programming? They are two distinct topics but the summary seems to conflate them together.

Worse than GOTO? Not if you value your life.

[fahrbot-bot]

... things that are far worse than the GOTO ever was.

I don't know about that [xkcd.com].

The Future is Now

[burni2]

We have Excel, Question answered, Problem not solved.

No because I had to resit it

[Growlley]

at Uni

I got yer functional programming right here

[Jeremi]

function AnswerToTheQuestionInTheHeadline()
{
        return false; // Betteridge's algorithm
}

Re:

[null etc.]

Code review nit: The function name would be clearer if reworded to be descriptive of what the function does: e.g. "getAnswerToHeadlineQuestion"

Data point: less bugs? Not really.

[mveloso]

I worked with a team that wrote in Scala. Did they have less bugs than other software? Not really.

One data point, but the promise of functional is like the promise of anything: it depends how you use it.

The author has a book to sell

[jma05]

That should have been in the summary.
A functional programming book author thinks it should be more popular.
Most of us who tried them would agree.
PureScript, which his book covers, has a reputation as an approachable Haskell.

They only think they do it

[Gabest]

I've seen many projects where object oriented programming was simply banned, pure c, and then every function's first argument was a structure, basically a pointer to "this".

GOTO is still everywhere

[GM]

The authors believes that GOTO disappeared in the 1960. He is deeply wrong. Even in Go, you will find a GOTO (check the keywords). CS Teachers, thanks to Dijkstra, just avoid to teach it.

But you have also many variations on the GOTO theme (jumping elsewhere in the code)
In Rust, there is no GOTO but you will find loop labels.
In many languages, including purely functionals, you will find exception handling that happily setjmp/longjmp in the stack.

Sometimes

[istartedi]

Having never actually used a functional programming language for anything major, but having studied them I can say "sometimes". I think I became a better programmer from understanding a bit about functional programming languages and what they're trying to achieve. I adopted some constructs that might be considered more functional, such as a preference for C's ternary operator where it makes sense as opposed to if-else and assignments.

However, another thing you find in functional programming is that becaus

Good for Bash

[See Attached]

Using functions (for most things ) can make bash methods a lot more readable, better flow. easier to debug and document. Got a kick out of the loss of Goto from Basic many moons ago.

Side-effect free

[bradley13]

He wants software free of side-effects? I agree that side-effects mar the beauty of pure computation, but: side-effects are the entire point of software.

Communicate with a user? That's a side-effect. Store data in a database? Side-effect. Interact with another program? Or a piece of hardware? Side-effects.

I enjoy functional programming. Logic programming is even more fun, and I've written real software in Prolog. But it was niche stuff, with little user interaction. That's not the real world for most programmers.

Certainly works in some cases

[DrXym]

I use functional programming for working with collections in Rust and Java. It's a reliable, concise and safer way to iterate a collection than writing the same code by hand. From experience perhaps 90% of loops where you are looking for something or turning something into something else are better using functional means. Although there is that 10% where you are doing something gnarly, like nested loops or are worried about memory efficiency (e.g. a long collection being reduced to a small one) where it mig

Ah, a CTO...

[SpaghettiPattern]

Once had a stint at a startup. The CTO position was filled because there was a vacancy. There was one candidate willing to work the position at a loss and I assume he built his CV around that.

Dude had a significant degree in field where programming was utilitarian and not the main discipline. Yet he proclaimed a lot. Mostly about his hate for boiler plate. And any program he didn't write. Never got stable code from him and we lost the few opportunities we had because of his code not being properly teste

no wtf

[Torvac]

no

Re:

[HiThere]

It's worse than that. In my experience functional languages tend to be harder to read and understand than more ordinary languages. They also tend to be more poorly documented, and worse at being documented. They aren't up in the "obfuscated C" category, because they aren't trying to be there, but they have natural skills in that direction.

There's a subset of use cases where functional is a good fit, but it's a rather small subset. Even Lisp and Erlang couldn't manage as pure functional languages. List

Re:real world

[Entrope]

Mutable state for those clients is trivially handled in a functional paradigm by capturing the lambda monoid in a Kleisi triple [wikipedia.org] to bind the combinator in a right-identity so it can be used in a continuation-passing style of programming.

(/s, the jargon is all from FP but probably used incorrectly in that sentence)

Re:

[Briareos]

BINGO!!!1!eins

Re:

[null etc.]

You forgot to mention functors.

Re:

[BitterOak]

Mutable state for those clients is trivially handled in a functional paradigm by capturing the lambda monoid in a Kleisi triple [wikipedia.org] to bind the combinator in a right-identity so it can be used in a continuation-passing style of programming.

Ah, yes, of course. Thank you for clearing that up for us!

Re:

[bcboy]

Not sure what your concern is, but there are very many real-world examples to choose from. Look into any functional programming language for web server and database examples. A few specific ones that might be worth a look are the datomic database, the clojurescript "om" framework, the react "redux" state management framework, and more generally the notion of "single atom state".

Re: real world

[zarr]

In the real world, if your application code has mutable state, it's almost always a bug. Your state should be in the database (or a dedicated caching layer), otherwise it will either not be visible to the other clients when it should, or writeable by other clients when it shouldn't. Put it in the database, and use transactions.

Re:

[bcboy]

Ah, gotcha. A slashdot post is not really sufficient to introduce the topic. Typically you use immutable data structures, which are often built over a mechanism called a "path copy". Basically, your app state is stored in a data structure, and when state is updated, you create a new data structure representing the new state, using purely functional code. People often think this is slow, but it's very fast, often faster than mutable code, except in very hot loops. The bit where you update the reference to th

Re:

[pixelpusher220]

As with most anything, it's about minimizing the problem surface area. Functional Core Imperative Shell is an interesting adaptation.

Re:

[TuringTest]

How do they propose to deal with state changes in the real world? For instance, you have a computer running a web server with database, attached to 1000 parallel clients all firing requests at it.

The other reply is joking, but you can represent state changes in functional code, and it is not conceptually difficult. There's a common misconception that functional programming can't represent changes of state, when the truth is that it just force you to handle them where they can happen, just like you would need to handle subroutines throwing exceptions.

It's the same technique you use to represent movement with a mathematical formula: you include a time parameter, so that each function result depends on

Re:

[rudy_wayne]

I've found that most tasks can be handled easily in VBA within Excel

I think you meant to post that in the Comedy Forum on Reddit.

Re:

[ceoyoyo]

r/AccountingDepartment

Re:

[RitchCraft]

Well I certainly ROFLOL'd when I read that.

Re:

[Briareos]

So Quake was the original Functional Programming Shooter?

Re:

[willkane]

Forgot to mention that another justification given by the author to use Functional Programming is that has its roots in Math:

Unlike most languages, functional programming languages are deeply rooted in mathematics. It’s this lineage in the highly disciplined field of mathematics that gives functional languages their biggest advantages. Why is that? It’s because people have been working on mathematics for thousands of years. It’s pretty solid. Most programming paradigms, such as object-oriented programming, have at most half a dozen decades of work behind them. They are crude and immature by comparison.

Just that reveals that the author is putting up a shop for his products. He is doing what the social sciences did in the 19th century to be treated seriously, use the jargon of the hard sciences.