Dr Darren says:
I could go one-by-one through the painful details, or I could just say what I think. I'll say what I think. The lack of fully-fledged, vendor-supported OO in the otherwise mostly awesome Mathematica is ridiculous. There is not one of the external links here (provided below) that demonstrates that somehow Associations are a replacement for decent OO, that the Entity system is a replacement for decent OO, that valiant user-contributed efforts like the (already old and seemingly unsupported) MTools are replacements for full OO, that the many old academic investigations into how to "hack" the Wolfram Language to make it act a bit like decent 00 are convincing, or that "Using" "Strings" as "Keys" in Associations (without any usable IDE-awareness of which keys are valid) is useful, fun, clever, or efficient.
Oh how I just "Love" "Typing" "Those" "String" "Keys". No I don't.
Functional is NOT a replacement for object-orientation. I suspect that the otherwise wonderful Mathematica is losing lots of potential new customers (and many very bright younger ones) because of the lack of decent vendor-supported OO. For anyone who has used real OO languages in dedicated powerful modern IDEs (noting Wolfram Workbench does not even come close to being one yet) working with Mathematica when it comes to hierarchical data structures (AND methods) is a complete pain.
"But OO is not the Mathematica way!" (a typical Mathematica zealot thinks)
Aaaarrrrggghhhh!!!!!! Once upon a time, somewhere at Wolfram Research, a long time ago, there was a meeting something like this:
... but we don't need vendor-supported OO because for decades we did not use OO then we introduced Associations surely that's enough we use "the MMA way" the people who want OO are not using "the MMA way" we never hear from them because they stop using MMA we don't even know about them we have the impression they don't exist because they get completely discouraged by the lack of vendor support for OO but that does not matter they do not exist we don't hear from them because they go elsewhere we only hear from people who do things "the MMA way" we are very bright and know about the selection effect but ignore the selection effect when it comes to customers most of our existing older customers have lived without vendor-supported OO in MMA they do things "the MMA way" because we don't have OO so they don't use OO so clearly nobody needs it and you can do OO in MMA anyway if you are really, really smart and don't mind typing a lot all the time and remembering every function name argument and structure key because there is no context-aware prompting for OO in our IDEs so bad luck if you want it to be easy and integrated in a modern OO-aware IDE. So blah do it "the MMA way" blah. "The Mathematica way".
You, dear reader, now have a choice:
- You are an "academic", you don't count time, you get paid anyway, it does not really matter whether you get something done in the real world, it does not matter whether what you do is vendor-close or not, or whether it is documented with plenty of thorough vendor examples, you enjoy reading for days about dozens of different strategies for doing something the vendor (Wolfram) could instead do once and for all. And you really enjoy doing things the hard way with clever tricks to show your colleagues how smart you are. By all means enjoy the external links below!
- You identify as a consultant or employee doing actual work in the real world on a real system for a paying end-client, you are used to integrated, documented, robust OO systems, you want to get useful work done on a real world system, and you rightly hesitate to offer up something based on hacks and home-backed solutions. You are time-aware and you use time-sheets, so convenient, fully integrated, context-aware IDE support is critical. All you can really do here is shake your head and wonder what on earth Wolfram Research as a company does not understand about OO.