That made me laugh, thank you.

I initially started programming with C++, then did a bunch of scripting languages and then Rust and C#. I feel like there are pros and cons to strictness.

I don't like all scripting languages, but Python, for example, has a simple syntax and is easy and fast to learn and write. I think it also has a good standard library. Some things can be simpler because of the missing guardrails. But that's also the weakness and I wouldn't use it for large and complex software. You have to be more mindful to keep a good style because of the freedoms.

C++ and Rust are at the opposite end. Verbose to write and more difficult syntax. More stuff to learn. But in the end, that's the cost for better guarantees on correctness. But again, they don't fit all use cases as well as scripting languages.

I've experienced the good and the bad in both kind of languages. There are tradeoffs (what a surprise) and it's probably also subjective what kind of language one prefers. I think my _current_ favorites are Rust, C# and Python.

> Whenever I see methods with 5+ params

I don't see why that's a problem. If a function implements an algorithm with several parameters (e.g. a formula with multiple variables), those values have to be passed somehow. Does it make a difference if they're in a configuration object or as distinct parameters?

Personally I'd tweak your last sentence to "return statements in the middle of a function."

Early returns at the very top for things like None if you pass in an Option type don't increase the risk of bugs, but if you have a return nested somewhere in the middle it makes it easier to either write bugs up front or especially have bugs created during a refactor. I certainly have had cases where returns in the middle of a beefy function caused me headaches when trying to add functionality.

Side effecting computations that depend on the "real world" go into an IO monad. The game in Haskell is shifting as much of the codebase as possible into pure functions/non-side-effecting code, because it's easier to reason about and prove correct.

IORefs usually, which can only be manipulated within the IO monad, so they tend to only get used at the top level and passed down to pure functions as parameters.