Why can C not be called functional programming? | SoloLearn: Learn to code for FREE!


Why can C not be called functional programming?

Lately in another post, swim pointed out that C is labeled 'procedural programming'. And although I have seen that the words are used that way, I don't quite get it. C has no built-in OOP, so basically everything is a function - even main is a function, although the return value seems to be rarely used. Okay, you might say, C also uses procedures... still unfair, isn't it? Both procedures and functions are 'subclasses' of routine, so why don't we say routine programming instead? Anyway, you can't say functional, because this seems to be reserved for languages like Haskell, or the techniques in other languages that emulate that sort of behaviour. I find the terminology a bit counterintuitive, so can someone maybe elaborate on the reasoning for these terms?

8/17/2019 1:39:37 PM


59 Answers

New Answer


Lots of good points throughout this thread. However, there are a few important points not yet mentioned that could to help fill in the gaps. 1. Functional programming predates the C language as LISP was created nearly 20 years earlier. 2. It seems that much confusion here is stemming from the fact that functions (as callable units) exist in both procedural and functional languages. However, the core differences reside in how functions are implemented in their respective paradigms. Procedural (imperative) functions involve a sequence of statements that can mutate state outside its current scope and could cause external side effects beyond the provided inputs. Functional (declarative) functions involve idempotent expressions with no side effects or dependencies beyond the provided inputs. There are several more differences, but these are what I consider the core concepts to focus on. (continued...)


The usage of function in both paradigms are valid. However, the resulting coding styles of the two variants is where the differences become obvious. Take a simple example for adding two integers: ---- Procedural: (Imperative style in C) ---- int add(int x, int y) { return x + y; } ---- Functional: (Declarative, not possible in C) ---- int add(int x, int y) => x + y ---- Both functions do the same exact thing with no side effects. However, the functional version involves defining only an expression while the procedural involves a statement. As subtle as these differences are, it becomes more obvious when the next set of instructions require looping or other logic. In the procedural, for loops, if statements, calls to other functions can occur. In functional, a chain of other functions are called where the results of the current are passed into the next... for example. Anyway, I would add better examples, but I've got to run and I think most in this discussion already know what I'm referring to. 😉


HonFu [#GoGetThatBugChamp!] Indeed... I was where you are a long time ago until I forced myself to write functional code. It can be very awkward at first as the concepts are much different from imperative style programming. Here are a few links I just pulled that might help get your head wrapped around it quicker: https://www.pluralsight.com/guides/functional-style-programming-using-c https://medium.com/@cscalfani/so-you-want-to-be-a-functional-programmer-part-1-1f15e387e536 https://link.medium.com/RhpuzYQJ8Y http://loup-vaillant.fr/tutorials/from-imperative-to-functional https://pragprog.com/magazines/2012-08/functional-thinking-for-the-imperative-mind https://www.slideshare.net/mobile/SanderMak/scala-functional-programming-for-the-imperative-mind https://www.whoishostingthis.com/resources/functional-programming/ https://www.lucidchart.com/techblog/2017/11/29/functional-programming-principles-every-imperative-programmer-should-use/


* anxiously waiting for David Carroll second part * 😮😮😮


I've posted my update a couple threads up now. 😉 I forgot to add to my follow up response... Early on when I was trying to keep the differences clear in my head, I would consider the following... is the code defined using procedural / imperative statements within the function body or is the function being defined using expressions and used declaratively.


So basically the issue is that we're using the same word for two totally different things? 'Function' (in most cases) for the most common type of routine in programming, and 'functional' as the term is used in maths?


C language is procedural. While it can be used to apply it as a functional programming doesn't make it one. When it was developed, the concept of functional programming did not exist. 😊


In my simple way of thinking I think that C is not called a functional language as it maintains state and uses global variables as others have said. I believe they gave C functions that name to distinguish them from procedures which were used in other languages at the time to execute some code without returning a value. Taking multiple (sometimes optional) parameters and returning a value is pretty close to math functions for the creators to name such entities functions. The name was probably good enough even if the 'minor' detail that the output can also depend on global variables/state or conditions distinguishes them from pure mathematical functions. To rename functions in C as methods or something else would be too impractical, maybe even costly. Perhaps languages like Haskell should have been called Pure Functional languages (maybe that name is too long) or Declarative languages which begs another question. Are declarative languages a superset of functional languages or are they same?


Functional: programming paradigm that treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data. [Wikipedia] Put simply, everytimes we call a function with the same arguments the output is always the same. The function doesn't change the state of our program nor is affected by it. There are no states, no variables, we cannot change values, only constants. Why C is procedural? Because it's not functional, it has states. One key feature of functional paradigm is thread safety due to its immutable states and of data, thread safety is a bit difficult to achieve in c++ for example (or at least we have to take care) in pure functional languages like Haskell you are guaranteed to be thread safe. Now what's the point? Languages evolved in favor of functional paradigm , so they went multi paradigm , hence not pure.


Da2, in a way you have just confirmed what I already wrote. I know that it's a different programming paradigm, but I wonder how it comes that a language, that uses functions all the time and not much else never gets called functional. And then at some point a different idea comes around that uses a rather specialized definition of function, and that is called 'functional', and seemingly so uniformly that the definition is not even challenged.


Exactly! There is the traditional PROCEDURAL paradigm (C language) OOP - Object Oriented Programming (C++) Functional Programming


That "specialized definition of function" is the original definition. A function, as defined in mathematics, has the same output for the same set of inputs. In C, that's not necessarily the case because change in a global variable may affect the output. Variables are immutable in functional programming, even things like x = x + 1 are not okay.


HonFu [#GoGetThatBugChamp!] Problem is people are casually using one terminology in place of others. I guess as long as others can understand what they mean when they use one term in place of other, this will continue. Functional programming has it's origins in mathematical model where a function's output solely depends on input provided and produce the same result for same input no matter how many times a function is executed. Same output for same input can't be guaranteed in procedural languages, as local and global parameters/variable can change producing wrong results if the input has some dependency on those local or global parameters. This is the same type of use of(one terminology used casually in place of other terminology) as it happens when discussing oops (encapsulation/abstraction/data hiding)


Sonic Yes , they are very close.. But to be accurate they are two different things. Declarative is simply the opposite of imperative, the are a way to describe a paradigm so functional is typically declarative, but not strictly, that's all. Declarative means that you make declarations, and not statements, and in this sense functional is declarative, Template Meta Programming is declarative too. Declarative expresses the logic of a computation without describing its control flow. In short ask for something but don't care how it's made..(seems like abstraction but it's another thing ) Declarative is like say "give me something that behaves this way" without care what it is. They share immutability of data and doesn't have loops, conditionals with states. Typical declarative languages are HTML,CSS,SQL for example, Haskell is functional, JS is multi(with functional) paradigm. Note also that in functional you describe how to achieve a task and in this sense is a bit imperative..


this is one of the best Q&A threads i have ever followed, really learned alot, and thanks to David Carroll does links where really helpful clearing all doubts


Maybe I'll have to try learning a functional language in order to really understand... Only having expressions thought out to the extreme sounds to me like nothing could ever happen. At some point, something has to be actually *done*, no? The difference of => and return looks like pure syntax to me, not like anything fundamentally different is happening.


I have learned and am learning a lot about what functional programming means, although I originally asked about the terms only. Thanks, guys! 🙂 About that definition thing again: It seems my imagination was wrong. Functional programming goes back quite far, and as Sonic wrote, C looks like they designed it to be largely procedural, but allow functions, in a loose sense, as well. So, since OOP was not invented, C looks more like an allrounder language, doesn't it? And from this, a purely functional language will just have to call itself 'functional', because it limits itself to functions, just as an object-oriented language limits itself to classes (everything has to be in a class). I feel like the term makes more sense to me today. 😅


It seems that the issue is semantics. In programming, functions are components that perform an algorithm and pass parameters. Functional programming, on the otherhand, is a mathematical approach formulating solutions


Schindlabua I think it is this multi-paradigm support in C# that makes me love this language so much. Switching between LINQ, predicates, lambdas, etc and imperative code makes for a best of both worlds experience.


Hey, Kishalaya Saha, nice to see you! 🙂 Yes, maths is older than computer programming, so from a mathematician's standpoint it seems almost like a righting of a wrong, that 'functional' now means what it actually means, right? But that's often not how languages work. Someone makes a mistake, nobody realizes early enough, and suddenly everybody's already using it and it becomes inconvenient to switch back to the correct thing. And it often does no harm even! In the world of programming, when you say 'function', people will usually know what you're talking about. In programming, a function isn't necessarily pure, it doesn't even have to have parameters, if I get it right. So in that context, the pure function - actually the original, the real deal - suddenly becomes a specialization. The 'correctness' of the term functional programming seems to carry an ambiguity into the programming world that could have been easily prevented, even if mathematicians wouldn't be pleased.