[frfl]

On a more serious note.

What is the alternative to the OOP IOC SOLID multiple layers of abstraction way of doing things? Is this really the go to architecture for enterpire - or more appropriately, large projects? Why is it the go to architecture -- what are the alterntives? Suppose we're discussing a project in a non-typical OOP language (not Java/C#/C++), what is the architure of choice there?

Asking this as a junior developer

[jcelerier]

> Is this really the go to architecture for enterpire - or more appropriately, large projects?

You have to understand that the context in which this kind of architecture is needed is high-turnovers environments. Basically, in the 90's, managers at big corps - IBM, ATOS, etc... asked the question : "how can we fire a whole team, hire a whole another team and put them in front of the fired team's code and have them be productive in a few days ?".

The answer to this is to heavily compartimentalize everything. Your manager tells you that you must implement a very particular behaviour in a very particular class ; you aren't meant to know what's happenning in other parts of the system.

[charleslmunger]

I'd like to reframe this a bit:

> "how can we fire a whole team, hire a whole another team and put them in front of the fired team's code and have them be productive in a few days ?".

What's really happening here is "how can we fire a whole team, hire a whole another team and have the new team be as productive as the old team was?"

You might think documentation, clean architecture, avoid feature creep etc... but what's really happening is that the old team is not productive by any absolute measurement.

[davidgrenier]

I'd give a shot at this: https://fsharpforfunandprofit.com/

Pick the programming language of your choice.