Add blog post "A Critique of Functional Programming"
This commit is contained in:
parent
d9403dfc57
commit
32b7531558
5
blog/posts/0151-critique-of-functional-programming.cfg
Normal file
5
blog/posts/0151-critique-of-functional-programming.cfg
Normal file
@ -0,0 +1,5 @@
|
||||
filename = 2022-05-27-critique-of-functional-programming.html
|
||||
title = A Critique of Functional Programming
|
||||
description = After some time working with the Rust programming language, and having to adjust myself to the functional paradigm, I've decided to write down my overall impression.
|
||||
created = 2022-05-27
|
||||
updated = 2022-05-27
|
128
blog/posts/0151-critique-of-functional-programming.html
Normal file
128
blog/posts/0151-critique-of-functional-programming.html
Normal file
@ -0,0 +1,128 @@
|
||||
<p>I've been using Rust for a while now, particularly on my pet project,
|
||||
Indivisible,<sup><a href="#r1" >[1]</a></sup> and one very key feature of Rust
|
||||
is that it's designed to be used primarily with the functional programming
|
||||
paradigm<sup><a href="#r2" >[2]</a></sup> (as opposed to the imperative
|
||||
paradigm<sup><a href="#r3" >[3]</a></sup>). I noticed this especially when I
|
||||
wanted to use a given library for parallelization in Rust, which was only
|
||||
available using this functional paradigm, therefore forcing me to adopt it. I've
|
||||
had a little exposure to this paradigm before, but I haven't had to use it
|
||||
extensively. After this I thought I would write about my experience on the
|
||||
matter.</p>
|
||||
|
||||
<p>I will admit I went into this quite critically. I've had bad experiences with
|
||||
this paradigm in the past, and I'm not fond of change. I'm a very classical
|
||||
person who is very used to C/C++ programming, and quite fond of assembly. Even
|
||||
so, I was willing to give Rust and functional programming a try. So I'm simply
|
||||
going to list off the pros and cons I've found with this paradigm.</p>
|
||||
|
||||
<h2>Pros</h2>
|
||||
|
||||
<h3>(Generally) More Optimal Code</h3>
|
||||
|
||||
<p>One of the benefits of using something like a library - which is basically
|
||||
what you do when you follow a functional paradigm - is that someone else way
|
||||
smarter than you has written the complicated bits, and probably in a more
|
||||
optimal manner. Instead of you typing down the first algorithm that comes to
|
||||
your head, someone has (hopefully) studied the different algorithms and their
|
||||
time complexity and chosen those which are most optimal for solving each
|
||||
different issue.</p>
|
||||
|
||||
<p>Now, although this can also apply to the imperative paradigm whenever one
|
||||
uses a library for any given task, it's true that the imperative paradigm is not
|
||||
characterized by passing the result of one function to another within the
|
||||
library, so there's less of a robust variety of functions to solve different
|
||||
(and often common) problems.</p>
|
||||
|
||||
<p>This being said, I have put down the caveat "generally", as this isn't always
|
||||
the case, mostly because you (the unintelligent developer) still have some part
|
||||
in the programming process, and if you don't know how to use these functions
|
||||
properly, you may even make something that's even less efficient than if you
|
||||
were to program it all manually.</p>
|
||||
|
||||
<h3>Less Code</h3>
|
||||
|
||||
<p>Less code doesn't necessarily mean better code, but it's still nice. Reason
|
||||
being that it typically makes it faster to read through, and faster to develop.
|
||||
Instead of having to manually type down all these different loops and filters,
|
||||
you simply call these preprogrammed functions. Take the two examples of Rust
|
||||
code that follow as an example:</p>
|
||||
|
||||
<figure>
|
||||
<code>
|
||||
// functional<br />
|
||||
let prime = !(start..end).step_by(2).any(|x| n % x == 0);<br />
|
||||
// imperative<br />
|
||||
let mut prime = true;<br />
|
||||
for i in (start..end).step_by(2)<br />
|
||||
{<br />
|
||||
if n % i == 0<br />
|
||||
{<br />
|
||||
prime = false;<br />
|
||||
}<br />
|
||||
}<br />
|
||||
</code>
|
||||
<br />
|
||||
<figcaption>
|
||||
Code block 1. Functional versus imperative code comparison.
|
||||
</figcaption>
|
||||
</figure>
|
||||
|
||||
<h2>Cons</h2>
|
||||
|
||||
<h3>Cryptic Code</h3>
|
||||
|
||||
<p>Perhaps my most pressing complaint about the functional paradigm is that it's
|
||||
extremely cryptic to read. You can often end up with these very long chains of
|
||||
functions with strange names doing very abstract tasks, all the while with a web
|
||||
browser open next to it with the documentation to make sure you're understanding
|
||||
what's going on correctly. You get these very strange syntactical structures
|
||||
that you're not quite sure how they're working, but you go along with it
|
||||
anyways.</p>
|
||||
|
||||
<p>The consequence of this is that, even though there may be less code to read,
|
||||
it's actually harder to understand what the code does exactly. Even when writing
|
||||
the code I've often found myself having to look over it several times to make
|
||||
sure it was going to do what I wanted it to.</p>
|
||||
|
||||
<h3>Extensive Familiarity Required</h3>
|
||||
|
||||
<p>When we work with any kind of library you generally have to familiarize
|
||||
yourself with it, and in using the functional paradigm this isn't any different.
|
||||
However, because functional programming <em>depends on</em> a library for its
|
||||
proper usage, you must familiarize yourself with all these very specific
|
||||
functions to make sure you're using the most optimal function for the task. If
|
||||
not, you can actually end up making very inefficient code.</p>
|
||||
|
||||
<h2>Conclusion</h2>
|
||||
|
||||
<p>Ultimately it's a question of what you're used to and what you care about. I
|
||||
fully understand that in most enterprise settings, where the objective is simply
|
||||
to get a product out to market as soon as possible, that many companies would
|
||||
prefer a functional paradigm language to get this done faster, and even get new
|
||||
employees up-to-speed as quickly as possible. But I'm not as convinced that it
|
||||
creates good code, as much as it creates lazy and inexperienced programmers. It
|
||||
also distances the developers more from the actual functionality of their code
|
||||
as well as the algorithms behind it.</p>
|
||||
|
||||
<p>Use whatever you're comfortable with, but I still prefer good ol' imperative
|
||||
programming.</p>
|
||||
|
||||
<h2>References</h2>
|
||||
|
||||
<ol class="refs">
|
||||
<li id="r1" >
|
||||
<a href="https://gitlab.com/naortega/indivisible" >
|
||||
Indivisible project on GitLab
|
||||
</a>
|
||||
</li>
|
||||
<li id="r2" >
|
||||
<a href="https://en.wikipedia.org/wiki/Functional_programming" >
|
||||
"Functional programming" on Wikipedia
|
||||
</a>
|
||||
</li>
|
||||
<li id="r3" >
|
||||
<a href="https://en.wikipedia.org/wiki/Imperative_programming" >
|
||||
"Imperative programming" on Wikipedia
|
||||
</a>
|
||||
</li>
|
||||
</ol>
|
Loading…
Reference in New Issue
Block a user