[mwattsun]

There is a principle which is a bar against all information, which is proof against all argument and which cannot fail to keep a man in everlasting ignorance. This principle is contempt prior to examination -- Herbert Spencer, 19th century English philosopher, scientist, and theologian

I've been attempting to train myself to be more open minded. For example, I have been skeptical of functional programming because my assumption was that it was an academic thing for those that didn't have to live in the real world of state and mutability. I thought it had to be less efficient.

Some investigation proved me wrong. Russ Olsen set me straight:

Functional Programming in 40 Minutes • Russ Olsen • GOTO 2018

https://www.youtube.com/watch?v=0if71HOyVjY

We don't have to copy a million element immutable array to change one element. We copy a section of it and keep the rest in a tree structure of changes (this happens under the covers). Secondly, manipulating the stateful world is easier to understand if we isolate those actions in Atoms and Actors.

Now I see the beauty of it so I'm glad I investigated.

[WastingMyTime89]

I was very puzzled by your argument until I skimmed the video. You are associating functional programming with avoiding side effects. That’s a very Haskell-ish view of things but that’s not the heart of it.

The key idea of functional programming is that it’s easier to think of program as a composition of functions rather than as a list of statements and therefore functions should be first class values. That used to be controversial but frankly the idea won. We have seen lambdas go mainstream in most major languages and programming is more and more functional by the day.

[mwattsun]

In this talk Erik Meijer surprised me by saying functional programming is not about immutability (at the end) which is talked about a lot by functional programmers and then refers to his paper, which lays out his thoughts in greater detail:

The Curse of the Excluded Middle: "Mostly functional" programming does not work by Erik Meijer

https://queue.acm.org/detail.cfm?id=2611829

[mwattsun]

Right, I understand where I wasn't clear. You're right, that idea has won and gone mainstream so I didn't think it was worth mentioning. I was emphasizing that I thought immutable data structures were inefficient and that it was the luxury of academics to abstract away stateful changes in the name of purity.

I've got a couple of other ideas that I need to do more research on (I'm watching Erik Meijer videos today)

1) Class objects with methods and data are like small programs, so I don't get why people go on and on about having data structures with functions as being superior to class objects, which are essentially data structures with associated functions.

2) Similarly, Joe Armstrong seems to hate object oriented programming but Erlang instances are essentially class objects, albeit running in their own process so they have more isolation

3) From reading Erik Meijer's Confessions of a Used Programming Language Salesman, I'm assuming that Async/Await that he help put in C# and Dart are his attempt to bring Haskell continuation monads to the imperative world

4) I'm assuming Clojure Atoms and Actors are like Haskell monads but don't know that. I watched Brian Beckman: Don't fear the Monad (https://www.youtube.com/watch?v=ZhuHCtR3xq8) but couldn't make heads or tails of it. Something about functions calling first order functions and pure first order effects with stateful second order effects, or something... That was a few years ago so I will give it another chance.

I'm probably wrong about these ideas but they're fun to think about and give me something to learn

[Zalastax]

My view on 2 is that you get into a quite different mindset when you program actors, compared to objects. For starters, since each actor is scheduled separately, it becomes routine to not assume too much about the internal state of the actor. So you won't see many getters + setters in Erlang, for example. You also need to structure your program to not communicate unnecessarily, since communication may fail and requires you to wait for the other actor to reply. This makes you to think about what state should belong to which actor. It is quite subtle and is best seen by experiencing it, but I think the programs turn out quite different, and in my view better. Actors are not perfect for everything but to me they are what object oriented programming should have been.

[mwattsun]

I realized additionally is that Armstrong has other complaints about OOP like inheritance. What I said above in that classes and functions are like a self-contained programs with structs and functions. I wasn't considering inheritance, but once you start inheriting it gets murky:

Joe Armstrong: Because the problem with object-oriented languages is they've got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle

But some of his other complaints don't feel as right to me:

http://harmful.cat-v.org/software/OO_programming/why_oo_suck...

I do love the implementation of Erlang and the reliability. I think it would fun to try actors and see if it changes how I view software engineering. I bet it would.