Functional programming is not new. OOP still exists only because of institutionalization. Outside of embedded systems there is no other good reason to continue

Functional programming is not new. OOP still exists only because of institutionalization. Outside of embedded systems there is no other good reason to continue OOP for new applications at this point. OOP was invented with SIMULA76 in 1976 but was popularized with C++ in 1982. The primary benefit of OOP allows developers to scale applications via inheritance which conserves memory. The idea is to instantiate an object in memory and extend that object as necessary on child instances with memory duplication. At that time, 1982, memory was about $1700 per meg and most computers were operating with 128kb total memory. Most modern languages use garbage collection: Java, JavaScript, Go, C#, and many more. In a garbage collected environment you, the programmer, are completely removed from memory management. Modern languages also prioritize speed over memory conservation because modern computer have tremendous amounts of available memory. OOP increases complexity compared to functional programming. Complex means many, not challenging. This is objectively provable by counting. The reason why OOP remains popular is because it is taught by universities and most programmers are produced by universities. Universities continue to teach OOP primarily in response to a broken feedback loop. Universities produce developers primarily reliant upon OOP because that’s what industry says it needs because that’s what’s available from the universities. There is no motivation for universities to prioritize other programming paradigms when their stature is determined by ratings based upon industry demand. Ratings, and thus rankings, determine how much money a university can generate. Although most universities are nonprofit organizations revenue remains a primary consideration of all activities both athletic and academic. It is nearly impossible to impose functional considerations as first principles in the work place. In open source or personal projects the owner of risk is the person writing the code. At work it’s all about hiring flexibility and least common denominator.