|
"He talks about using OOP to remove "accidental difficulty" from the process, “allowing the designer to express the essence of the design without having to express large amounts of syntactic material that add no information content”… "…but he stops at OOP? Makes me think that he was not very informed about functional programming, given that OOP is (1) trivial to add to functional programming languages, (2) dissed by all the greats as uninteresting – or worse." Here's my take: OO may be a decent way of managing complexity, but it introduces a (noticably high) complexity floor that negates many of the benefits. It works very well for some things, specifically windowed guis, and less well for almost everything else. Rule of thumb: if you are modeling the "problem domain" and not the "solution domain," you are doing it wrong. However, for better or worse, every programmer in the last 30 years has been trained on OOP; most simply cannot conceive of not using a "class" keyword. On the other hand, almost no one does OOP itself anymore. Objects, classes, are treated as a module system, which is noticably missing, or at least very limited, in most programing environments. All problems have some level of essential complexity, although often it is lower than both the floor demanded of both the programing environment and the programmer's self esteem. (It's difficult for many to admit that what they are being asked to do is trivial, so they look for ways to make it more difficult, including introducing bizarre monstrosities into their environment.) On the other hand, exactly no one wants to grapple in hand to hand combat with any moderately complex problem (and many problems do have sudden, steep, complexities) as Dijkstra would have preferred. Or, some problems cannot be solved in the necessary resource constraints, including the brain power of the programmer. As a result, more complexity is pushed down stream---and modern systems have very long tributaries. So, what can ya' do? |
Hmm...I'd say Smalltalk is about as simple as things get.
For anything more than a few functions/methods, you want some sort of scoping/module concept, and I think you're right that that's one way classes are used. Might as well be classes as they are lightweight, provide a convenient metaphor and other benefits.
I would say that true OO programming is rare. Most I've seen in industry is scoped procedural with little to no polymorphism. Or paraphrasing Alan Kay: "Before you dismiss OO, you should at least try it once".