[Oberon] Functional programming and Oberon

[Lars]

> On 12/14/2016 11:17 PM, Srinivas Nayak wrote:
>
>> These days I see, every programming language is behind functional
>> programming! Say, C++ or Java or C# or Javascript... recent trend is the
>> old fashion! The fashion of Lambda and Closure!
>> How far is Oberon from functional programming?
>>
>>
>> Surprisingly we already have all the necessary stuffs in Oberon:
>> 1. nested procedures
>> 2. procedure variable
>> 3. scoping of procedure local variables
>> etc.
>>

But as Niklaus Wirth put in one of his articles (Through the Looking
Glass? Or another article he wrote)... "Why?"

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 a
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, ...

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

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).

>> But only thing we need is: a way to preserve dynamic state of a
>> procedure and unnamed procedures! What else?
>>
>>

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 that does not do anything at all with
regards to printing to the screen, it just purely calculates something.
Then, create a separate module that takes this 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.

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, 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.

Heck, I just wrote a parody website of functional programming: this is an
email, but I wrote an entire website article in my email above. Maybe I'll
convert it and open up a parody domain name.

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).