I'm planning on doing a couple of posts on the language Elm and why it may be better than JS, but to fully understand what happens in Elm you need to know some things about the functional paradigm - a clean view on what programming is, designed with mathematical perfection.
As the name implies functional programming is all about functions. Everything is done using them, and applying the function to a parameter is the fundamental operation. In imperative languages like Python, C++ or JS, to apply a function
x you use parenthesis:
foo(x), but in functional languages it's sufficient to write the function next to the value:
foo x. Parenthesis come up when applying a function to another function's result. For a bigger example:
# Imperative: foo(x, bar(y), baz)
-- Functional: foo x (bar y) baz
This syntax is cleaner and more readable when most of the program is function application: not even commas are required to separate arguments.
Everything in the functional paradigm is a function. Even normal operators like
* are considered functions. In most functional languages you can put parenthesis around them and apply them like any other function:
(x + y) = (+) x y (x * y) = (*) x y
Functions can be passed as arguments and assigned to variables. This allows for some powerful operators that I will discuss in later posts.
No side effects allowed
Functional languages deal with pure functions, which are not allowed to alter any internal or external state. This means a pure function's output can only depend on its inputs, not on time of execution or randomness. It can also not affect outcomes of other operations in any way other than through returning values.
This may seem as overly restrictive: after all the screen is an external state, and how are we supposed to write an application that doesn't depend on time? Most functional languages have their mechanisms for dealing with those problems, usually behind the scenes, without introducing impurity to the programmer's code.
Purity has its benefits: a pure function for a given input will always return the same output, so there may not be a need to recalculate it later. The execution of a part of the program never depends on anything outside of it. This opens opportunities for optimizing compilation and makes thinking about code way easier.
Like in C or Java, but good.
Another property of most functional languages is that they are strongly typed. What this means is that all data flowing through the program has to be assigned a type, like
Float. Every value traveling along some path in the program has to always have the same type.
In languages like C++ or Java this leads to a ton of unnecessary type annotations that are annoying and obscure the meaning of the code. In functional programs types can almost always be inferred from their surroundings, lifting the burden of attaching labels to everything from the programmer.
Type inference means that from knowing what type the basic literals are (like
"Hello"), and what types the basic operators take and return the compiler can reason about types of other values and functions, in theory requiring almost no type annotations. It's still a good practice to annotate your function definitions so that the compiler can warn you when the type you want doesn't match what is inferred.
We need to go deeper...
In imperative languages data types reflect how a value is stored in computer memory:
int is a four byte number,
string is an array of bytes and
float is a floating point number as described by The Standard. In functional languages data types reflect what the value represents. You have basic types that all have some implementation-defined representation in memory, but you can also define your own types, usually on top of existing ones.
Types are defined with constructor functions. For example
Boolean may be defined as:
type Boolean = True | False
This means the
Boolean type can be constructed by either
False constructors. Neither of them take any arguments, so they always return the same values which can later be interpreted as "true" and "false". A more complex example that uses arguments is:
type Webpage = Loading | Loaded Html | LoadingError String
This represents the fact that a
Webpage may be one of three:
Loading, in which case no additional info about it is available,
Loaded, in which case it has a value of type
LoadingError, in which case there's an error message available describing what went wrong. This allows for precise modelling of what your data means and can possibly be.
Algebraic types naturally represent options available to a given value, so the most used conditional construction in functional programming is one that branches based on the constructor. The usual syntax looks like this:
case value of Some pattern -> result Other pattern -> different result
Going with the
Webpage example we could construct a function that takes a
Webpage value and returns a rendered view like this:
renderPage : Webpage -> Rendered renderPage page = case page of Loading -> renderText "Loading..." Loaded html -> renderHtml html LoadingError message -> renderText message
This may be a bit to take in, so let's go through it line by line:
renderPage : Webpage -> Rendered
This is how type annotations look like for functions.
renderPageis a function that takes a
renderPage page =
Start of the function definition.
pageis the function argument.
case page of
Start of a
Loading -> renderText "Loading..."
pagewas made with the
Loadingconstructor display the loading text.
Loaded html -> renderHtml html
pagewas made with the
Loadedconstructor render it's parameter as HTML.
LoadingError message -> renderText message
pagewas made with the
LoadingErrorthen display the error message.
You can see how a
case expression can be used to deconstruct the value and assign its contents to variables (
message in the example). This way of branching can also make sure that the program never breaks, because every possibility has to be accounted for. Any errors have to be explicit (like
LoadingError in the example) and passed around openly as values.
Sidenote: Type theory
Very rough explanation.
Algebraic data types are such a powerful concept that you don't need any builtin types to make programs. You can define numbers and lists and operate on them without referencing any existing types. I have already shown the easiest example, the
Boolean type, but let me explore this further.
The second simplest example is natural numbers. If you think about it, any natural numbers can be defined as either zero, or a successor of some other number. This translates to:
type Nat = Zero | Succ Nat
This type is defined recursively, which lets us define an infinite amount of numbers with a finite set of symbols. With this whenever you encounter a number you can split the logic into two
cases: a simple one when the number is zero, and a recursive one when it isn't. For example addition would work like:
add : Nat -> Nat add x y = case x of Zero -> y Succ x' -> add x' (Succ y)
When adding zero to
y the answer is just
y, and when adding a successor of something the
Succ can be "moved" to
x which guarantees that it finally reaches the base case.
As a closing remark I will add an example of a
List type with a
map function that transforms each element of the list. This example has some more advanced notation, so don't worry if you don't get it.
type List a = Empty | Cat a List map : (a -> b) -> List a -> List b map func list = case list of Empty -> Empty Cat head tail -> Cat (func head) (map func tail)
I'm back to writing!
I hope this gave you a vague idea of what you could stumble upon when dealing with functional languages. If you want some more concrete and in-depth examples look forward to my series on the programming language Elm. I barely have any formal education in functional programming and category or type theory, so if you spot any mistakes please notify me in the comments. See you soon!
Top comments (0)