Date: 2024-05-12
+---
|
|
Functional programming is a new paradigm that has emerged
quite some time ago but only recently are people considering to
implement various features from these languages.
It has shown me one important thing. The less variables I had in my
code, the less buggy it was. Its eye-opening but also a bit weird,
and says a lot about us as humans. If we don't put restrictions upon
ourselves, we tend to err a lot more frequently than we are willing
to admit to ourselves.
That said, functional programming operates under the assumption
that the internal state of the program doesn't change. At least
the purest fprog. languages, like Haskell, operate under this
assumption.
This is not correct. At the very core, the processor inherently
modifies its stack, every time a function is called and every time
it returns from a function by virtue of push and poping the return
address on the stack.
Values are copied into registers, modified, and written back into
a memory location, modifying the value that was stored there
previously.
The claim that state can me immutable, is inherently not correct.
What these languages do, instead, is simulate and strongly enfore an
immutable environment. This is a concept being applied. But its not
backed up by hardware.
In order for something to be purely functional, and work the way it
is described by these languages, it would require a complete
re-invention of the processor.
And such a processor would still require a way to store and load
data, and even overwrite old data. Creating a new ROM chip evert
time a variable gets written to is an insanely dumb idea.
It is unlikely we will ever have processors that would sufficiently
satisfy the requirements for a 'pure functional programming
language.'
This is where OCaml comes in. OCaml is a functional programming
language, whose creators clearly understand that having mutable
state is necessary. While OCaml doesn't encourage the use of mutable
variables, it is possible to create them because many algorythms are
just invariably faster.
Consider for example any 2D or 3D game, where the players position
is tracked. Creating a new player object, every time their position
changes is extremely inefficent. One simply writes the new position
data into the player object and you're done. No unnecessary copying
of data is performed, because it is clear to anyone, that the
position is going to change, several times per second. Our world
changes constantly. Disks are written to, data changes, the contents
of RAM changes.
As such it is important for a language to be able to deal with this
change and not just pretend its not there because its 'not pure' or
not mathematically convinient.
So, the easiest way to change a players position, is to read in his
current position, change it, and write the new position back into
its original memory address. This operation is also the fastest,
making the complexity and size of the player object irrelevant in
terms of performance. But for functional programming, this becomes a
problem when the player object has many more variables that need to
be coppied into a new structure, and all old pointers to this data
need to be updated. And because updating these pointers also would
involve modifying them in-place, what pure functional languages do
is 'recreate' the whole game world from scratch, each frame.
Any larger game would choke and start dropping frames, lagging and
stuttering if this was adhered to.
For games that re-draw the screen (also a mutable operation, by the
way) 60 times per second, you have 0.016 seconds (16 ms) to perform
all necessary operations before the next frame. If this time-frame
is exceeded the game starts dropping frames to catch up.
Functional programming is usefull because it imposes restrictions
that help us write better code. It is necessary though, that we need
to be able to deal with mutable state, as that is the only real way
of making performant programs. The type system in OCaml helps reduce
errors but in case of need, also allows for writing for-loops and
changing state that is cruicaly mutable, so that the programs
performance becomes acceptable.
OCaml also offers the option to generate native code and even an
option to generate byte-code in C-style syntax format for direct
inclusion into other C programs. Hence, so far, it is the best
functional programming language I've been able to find to date.
(Maybe not the fastest, but I haven't really checked)
This article has gone on long enough, but I think I got my point
across clearly. Try OCaml, learn the language, see if it fits your
programming style. Its relatively niche, but it is worth checking
out.
You can checkout one of my programs written in it. I called it
bininject. Simple program that injects one binary file into another
with an extra feature to find a 'hole' in a binary to insert into.
It makes me quite confident that this program has no big bugs, since
its written with immutable state in mind. (It might still have bugs.
I just didn't find any)