To be perfectly honest I ignored the “multi-paradigm” requirement because in my mind it’s largely academic. While James O. Coplien makes a compelling case for multi-paradigm design his advice has been largely ignored and in reality “multi-paradigm” often turns into a liability.
- Putting its OCaml heritage aside being functional and on the CLR destined F# to be labelled as “multi-paradigm” as it needed interact with the objects in its environment and those created by other CLR languages.
- One could argue that being “multi-paradigm” didn’t do Scala much good. To a certain extent the same could be said about C++.
- “multi-paradigm” is supposed to allow the selection of the optimal paradigm for solving the problem in the domain and expressing the solution in an effective manner. More often than not “multi-paradigm” simply allows developers to stay in their own comfort zone - regardless of whether the applied paradigm actually “fits” the problem. Hence the use of Scala as a “better Java” and C++ as a “better C”.
Sometimes it is just better to choose a tool with the “right constraints” - though it is possible to go off the deep-end - like Java being dogmatically class-oriented.
I’m not hating on F# - it would be my language of choice on the the CLR.
