Publication : is functional programming a hoax

Article Publishing

~ is functional programming a hoax

You can do functional programming in any language if you try hard enough....

You can nest functions in functions in functions and pass things in with
pointers to emulate functional programming, but the question is why?

I always find "dumb programs" easier to understrand than clever tricks up
sleeves.

I've always found functional programming to be one gigantic clever trick,
inside clever tricks... And I have always seen procedural programs to be
these utterly dumb, boring, top to bottom programs that look like an
easy to understand cooking recipe.

  First set the oven to 350 degrees.
  Mix the flour with the baking soda.
  Add water.
  Put cake in oven.

No clever tricks... just a set of simple instructions from top to bottom...

Then you've got people claiming that MS LINQ project is somehow adding
functional programming to our existing languages, but is it really?
Relational != functional.
All relational databases are side effects machines. Every time you add any
data to a database you have side effects of all sorts. Only when you do a
read only view of the database are you doing side effects free
programming.

Now, I suppose if you aren't baking a cake with a set of simple
instructions and you are doing some super complex mathematics to calculate
something... maybe this is a use case for functional programming?

I've always thought that Lisp was never a functional language at all but
rather a procedural language with a strange syntax... After all, to print
to stdout you have to do a print call in lisp, or something similar, which
goes back to the "Bake the cake" style programming... As printing
something to a screen is still a procedural imperative call, full side
effect... What's the side effect, you ask? Printing to the fucking screen..

I watched some youtube videos of a guy doing Game Programming in Haskell,
and I kept asking the same question as Niklaus Wirth did in his article. Why? What
problem is actually being solved? Is it pure mental masturbation?

The Niklaus Wirth article, AFAIR, was Through The Looking Glass or one of
his others.

On the other hand I'm still open minded enough, to find a use case for
functional programming, if there is even such a thing as functional
programming, because I have no idea what functional programming even is.

I've researched functional programming on and off, for about 12 years now,
and never truly had anyone explain properly what functional programming
is. The side effects free claims are all bogus, because a hello world
program has a side effect... I've narrowed it down to "isolating side
effects as much as you can", but no one actually ever said this was what
functional programming was until I said it myself... (i.e. I'm likely the
only person who really came up with a definition of what functional
programming is, because one one else could).

How can we try functional programming, in Plain C, or C++, or GoLang,
or Oberon?

You might need to make a function that has zero side effects, or rather
isolated side effects like how Monads (rhymes with Gonads) works.

Niklaus Wirth claimed, in his article, that Object Orientation was a
better way in his opinion to isolate side effects by privatizing things
instead of the old plain C public everything way of programming.

I'm even skeptical of Wirth's claim that OOP is the answer to side effects
isolation.

So to answer the Monads (with your gonads) question, try writing a
Component Pascal or oberon program, or GoLang program, or Plain C program,
that does not do anything at all with regards to printing to the screen, it just
purely calculates something. But even if you don't print to the screen
try removing state modification in the plain C (or your language of
choice) program... such as trying as hard as you can to not do a
mem alloc call and then stuff some characters into a string... or
stuff integers into an array or list...

Then, create a separate module that takes this grand math calculation and
then isolates it in such a way that it can print to screen. That's kind of what
Monads are. But always ask yourself "why am I even doing this in the first
place?". It's definitely an interesting academic exersize... or maybe
it's just boring, I don't know. Maybe it is masochism.

Functional programmers seem to think their programs are one gigantic
calculation, and then you isolate that calculation from side effects, like
GUI calls, Print screen calls, variable states in memory or on the disk,
etc.

That's certainly not what Lisp is since Lisp is riddled with side effects all
over the place throughout its programs..... But Haskell Wheenies seem
to think their program is a big Math problem being solved without any
side effects, and then when you absolutely have to do something useful
like print to a screen, you isolate it so it's less dangerous.

Maybe it is like baking a cake in your head first, calculating what the
cake will be baked like if it is at a certain temperature in the oven (but
DO NOT turn on the oven as that is dangerous).... Then after you've done
millions of calculations about the entire baking cake process (mental
masturbating), finally at the end of all your calculations, figure out a
way to turn on the oven with a fire extinguisher in hand.

But obviously functional programming has provided us some useful insights
such as garbage collection, which came heavily from lisp. But IMO, lisp
was never a true functional language, so even if we stole garbage
collection from lisp, it really wasn't functional anyway, so you'd be
stealing garbage collection from an imperative language with a weird
syntax (IMO that's what lisp is).

In short: dumb stupid programs are superior to clever tricks.
If you are reading an instruction set on how to fix a car and they
have made it so stupid and dumb that a monkey could almost do
it, this is far better than some clever trick puzzle encrypted in all
sorts of bizarre mathematics... I.e. Dumb Simple Programs is why
people bought Paul Graham's Yahoo Store code written in Lisp
and converted it to a procedural/oop language.. Because no one
could handle all the clever tricks up Paul Grahams sleeves..

To be fair, OOP (object orientation) has too many tricks up its
sleeves too, as do plain C pointer tricks.. and as does Perl with
it's strange idea of using symbols instead of words, to do majority
of programming... i.e. all paradigms eventually have tricks up
their sleeves. Which is why people are choosing simpler languages
like GoLang or Python. We have even seen a lot of the clever
trick fans in the Ruby community intrigued by the simplicity of
GoLang, and go running to it...

But let's even be more fair, GoLang has some tricks too, like
being able to declare functions anywhere inside other functions
instead of like in plain C where you just declare one function
separate from all other functions, keeping things simple. But
IMO golang has a limited number of tricks, whereas Lisp and
maybe even Haskell, are tricks galore everywhere.