Forget Imperatives, Use Immediates Instead: What is an immediate? (part 1): a blog around imperative programming vs. functional programming
The description of this post from my friend Graham Hutton is “a blog around imperative programming vs. functional programming”. I find that the discussion of the difference between those approaches to software development has been recently low, specially for the number of people working on functional languages and considering functional concepts in their day-to-day work. The aim of this post is to introduce the concept of immediacy, which is an attempt to explain how we can consider both approaches to program design at the same time and still leverage the benefits of each one.
The best way to understand immediates is to start with a concrete example. This post introduces some core ideas from the concept, but a more general introduction will have to wait for another post.
Immediates are not a new idea. They are existing concepts that have been slightly modified in order to be used in a different context. I would say that they are like Lego bricks; take them apart, put them together again and you get something new out of it!
The notion of immediacy has its roots in an important paper called Purely Functional Data Structures by Chris Okasaki
One of the first things you learn in C programming is “for loop.” We all learned how to write for loops. But, how many of us really understand what a for loop is? When I say “understand”, I mean not only it’s syntax and semantics, but also the details about how a for loop works at a lower level.
In this article, we discuss about for loops. The following topics are discussed:
1.What is a for loop?
2.for loop vs while loop
3.How does a for loop work?
4.Imperative vs Functional Programming
5.Immediates or First Class Values
6.Forget Imperatives, Use Immediates Instead: What is an immediate? (part 2)
In this article, we will focus on the notion of imperative programming and the concept of immediates. We will discuss what is an immediate, how can you use them, and when should you use them.
Imperatives are instructions that tell a computer what to do step-by-step. Many popular languages, such as C, Python, Java and Ruby are imperative programming languages. When you write an imperative program, you tell the computer what to do and how to do it. For example:
In imperative programming, we use variables to store values and reuse them. For example:
int x = 3;
int y = x + 4;
x = x * y;
What will be the value of x? It turns out that the value of x is 21. We can see that by following the execution step-by-step. So what if we want to know what happens when we take a similar approach in functional programming? In functional programming, we do not have variables as such. When we initialize something, it is actually a constant. Let’s see how it would work in an FP language like Haskell:
f x y = 3 * x + 4*y
g = f 5 6
What will be the value of g? It turns out that the answer is 42. But again, we are forced to follow the execution step by step to get this answer. What about the following question? What if we want to know the value of f (g+1) (g+2) without executing it step-by-step? This leads us to a new concept called immediates. An immediate is a data structure evaluated at compile time instead of runtime. In other words, an immediate is evaluated before being passed as an argument
“What is an immediate? A constant value that we can specify in the source code. Most common example of an immediate is a literal:
int a = 7; // a is an immediate which has the value 7
Now, you might say that this is not very different from writing:
int a; a = 7; // still, it’s an assignment statement, right?
Yes, indeed. But here’s the catch – in functional programming languages we don’t write assignments like this. In functional programming languages, we use immutability. We don’t have any mutable data and we don’t have any assignment statements. So instead of assigning values to variables, we use function calls to create new bindings (i.e., name-value associations). In essence, we are saying: “The variable ‘a’ should be bound to the value 7.” ”
Imperative programming is a programming paradigm that uses statements instead of expressions. It focuses on describing how a program operates. In simple words, imperative programs are a sequence of statements to perform specific task. This is the most common programming paradigm that people learn and use in their day-to-day life. Most of the languages today support imperative style of programming like C, C++, Java, Python, etc.
On the other hand, functional programming is a paradigm that defines computation as the evaluation of mathematical functions and avoids state and mutable data. Functional programs are made up of functions which take input and return outputs.
The two paradigms have both pros and cons. Imperative programs are often easier to understand but it is hard to debug or extend them because it involves a lot of low-level details. Functional programs are compact, elegant and easy to debug or extend but they can be difficult to reason about since they do not have familiar control flow structures like loops or if-then-else statements (I am not saying that functional languages do not have these constructs, but you can write functional programs without using any).
So, should we choose one over the other? No! We can learn from both paradigms and create better solutions for complex problems such
Imperative programming is to functional what assembly is to high level languages. Sure, imperative programming is a lot closer to the hardware than are high level languages, but the hardware is more complex and more difficult to understand than most high level languages.
So, why use assembly when you can use programming languages instead? Why write code that tells the computer what to do, when you can write code that says what you want it to do? It’s like telling someone how to drive somewhere, vs. telling them where you want to go.
Programming imperatively is like driving stick shift. It’s easy once you figure out how to operate the clutch and shift gears properly, but it takes more time and effort than driving automatic. Also, if you drive stick shift long enough, you’ll have cramps in your left hand from constantly shifting gears.