>> JS is a "mono-typed" language and there is therefore only one type of things you can operate on and return as a result. >Javascript has a type system that i

>> JS is a "mono-typed" language and there is therefore only one type of things you can operate on and return as a result. >Javascript has a type system that is enforced at run-time. Nobody questions that JS has "runtime type-checks". But that's irrelevant to my point. I've referenced of course this here: https://existentialtype.wordpress.com/2011/03/19/dynamic-languages-are-static-languages/ https://existentialtype.wordpress.com/2011/03/19/dynamic-lan... >Monoids are very simple and well defined. Sure. Just define an instance for a type that models a JS runtime-object, let's see what happens… ;-) But I see, my point is still not explained well: What I'm trying to say is that using abstractions that are so powerful that the resulting code can operate on (almost) arbitrary "unrelated" things using that code will lead to the same kind of puzzling outcomes as "JS Watman". (And like I said, a deep mathematical relation doesn't make things "related" in a practical sense automatically. For example when it comes to "correct" domain modeling of business cases where you explicitly want to treat different parts of your system separately; as this results in a less "entangled" architecture. Gluing together parts that are unrelated through clever code on the other hands side creates maintenance hell where everything depends on everything, but you can't even see what depends on what as everything is generic; that's the opposite of good software engineering, imho. To throw a few phrases: "Divide and conquer!" "Use the right tool for the job!" "Use the least powerful tool that gets the job done well!").