3 ms·

Then again, the OO paradigms I learned (which did not include any Smalltalk ones) were both very hard (to get right) and I now think they are also very wrong.

by gruseom 17y ago

Then again, the OO paradigms I learned (which did not include any Smalltalk ones) were both very hard (to get right) and I now think they are also very wrong. Based on this and your other comments, I'd like to hear more about how you came to this conclusion. This isn't the right thread for it, though... perhaps, if you're interested in writing about it, you could make a new post?

hga 17y ago
I can put it simply: the only thing worse than an imperative style with side effects is one where the side effects are chained, in this case through a set of interacting objects. I came to it from the hard experience of doing it, e.g. think sequence diagrams; the methodology was OOSE. However lately I have been wondering about the utility of this approach for GUIs.
- gruseom 17y ago
  That's been my experience too. "Object model" almost always translates to "spaghetti". The promise of OO -- that objects would provide a flexible abstraction mechanism for writing software at the level of the domain while encapsulating low-level details -- has not been realized in practice.
  - hga 17y ago
    You left out that the promise of reuse doesn't seem to be borne out and is perhaps harder when doing OO than in other domains. Probably because side effects are more pervasive and it's damned hard to design good object hierarchies (and heaven help those who don't have the discipline to keep their class relationships in a directed acyclic graph). Modularity is a win and OO only superficially encourages it.
  - kls 17y ago
    I think the promise can be realized in pure UI and AI other than that it is much a-due about nothing. COCOA is a good example of pure UI, as well as some of the JavaScript UI kits. I.E Dojo or YUI. Given that UI objects are well encapsulated via OO is is a natural fit. When you get back to the service layer, you end up either writing overly complex OO stuff or butchering the language to make it functional. Thankfully Rich Internet Applications are cleanly separating these concerns and you can use an OO toolkit for pure UI and a functional language the stand up RESTful services. The days of bastardized JSP/HTML/TILES/STRUTS/Kitchen sink are numbered, for just that reason. Trying to shoehorn all of these technologies into a server side OO framework was becoming way to cumbersome.

by gruseom 17y ago

hga 17y ago

I can put it simply: the only thing worse than an imperative style with side effects is one where the side effects are chained, in this case through a set of interacting objects. I came to it from the hard experience of doing it, e.g. think sequence diagrams; the methodology was OOSE. However lately I have been wondering about the utility of this approach for GUIs.

gruseom 17y ago
That's been my experience too. "Object model" almost always translates to "spaghetti". The promise of OO -- that objects would provide a flexible abstraction mechanism for writing software at the level of the domain while encapsulating low-level details -- has not been realized in practice.
- hga 17y ago
  You left out that the promise of reuse doesn't seem to be borne out and is perhaps harder when doing OO than in other domains. Probably because side effects are more pervasive and it's damned hard to design good object hierarchies (and heaven help those who don't have the discipline to keep their class relationships in a directed acyclic graph). Modularity is a win and OO only superficially encourages it.
- kls 17y ago
  I think the promise can be realized in pure UI and AI other than that it is much a-due about nothing. COCOA is a good example of pure UI, as well as some of the JavaScript UI kits. I.E Dojo or YUI. Given that UI objects are well encapsulated via OO is is a natural fit. When you get back to the service layer, you end up either writing overly complex OO stuff or butchering the language to make it functional. Thankfully Rich Internet Applications are cleanly separating these concerns and you can use an OO toolkit for pure UI and a functional language the stand up RESTful services. The days of bastardized JSP/HTML/TILES/STRUTS/Kitchen sink are numbered, for just that reason. Trying to shoehorn all of these technologies into a server side OO framework was becoming way to cumbersome.