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)

.