4 ms·

OO suffers from the design pattern kind of abstraction as well as the explosion of nouns kind of abstraction because of trying to model everything as analogies

by jules 11y ago

OO suffers from the design pattern kind of abstraction as well as the explosion of nouns kind of abstraction because of trying to model everything as analogies to real world concepts rather than focusing on what the program is meant to do. Functional programming suffers from a different kind of gratuitous abstraction, namely the category theory abstract nonsense kind. I think the main source of overabstraction is the idea that abstraction is a virtue in itself rather than only a tool to accomplish a task. This often takes the guise of different artificial value systems like "testability", "decoupling", and "reusability". These can be good things, but only as a means to an end. People lose track of that sometimes.

seanmcdirmid 11y ago
I don't think that is an accurate portrayal of OO. There are plenty of nouns out there that do not model real world concepts. I can create an "expression" class/object in a OO program (and do all the time!) to represent parts of an abstract syntax tree. As far as I know, expressions don't exist in the real world. Human language is quite powerful like that. Overabstraction is often simply a matter of poor problem understanding. Sometimes you don't really know how to solve a problem right, so you bite off parts of it, work your way through many layers until it is solved. The abstractions are not ideal, because not much planning was involved, and you didn't actually have the experience to generalize appropriately but...you needed some way to decompose the problem. Abstraction is a tool. It has a cost, but sometimes you need to pay it and sometimes you are better off not. We really need better ways of abstracting and, when necessary, unabstracting.
- jules 11y ago
  I think that's right, especially the second paragraph about the cause of the explosion of nouns. A common approach to OO programming is to take the problem and identify the nouns in the problem, and then make a class for each of those nouns before having a clear idea of how the program is going to work. This is especially prevalent in combination with TDD. This is a recipe for disaster if you ask me. A good example of this is when Ron Jeffries tried to write a sudoku solver.
  - zamalek 11y ago
    Agreed. > identify the nouns in the problem This is what I was getting at by mentioning education as a possible culprit. You get out of university with this bad habit right off the bat, instead of the correct one: Identify the responsibilities in the solution. Identifying all the nouns in the problem sets you up for failure because you are implementing a solution before you know what the solution actually is. Said another way: you are in a very literal way implementing the problem and not the solution.
    - seanmcdirmid 11y ago
      What is so wrong about that? You have to understand the problem in some way. Perhaps we could spend a lot of time at the whiteboard understanding the problem waterfall style before we design the actual program? Realistically, this isn't very effective either.
  - seanmcdirmid 11y ago
    There is nothing wrong about noun identification in itself, you have to solve the problem in some way. The functional approach avoids the nouns, the solutions can be more elegant, but man, coming up with those solutions is much harder. Decomposing a problem without nouns is like doing...math: it is much more difficult than just talking about it! Once you have done the math, you really understand the problem, but that is a very steep mountain to climb. I keep coming back to RPG's "worse is better" essay. The problem is that while the artifacts that we create might be horribly messy, they are better than the artifacts that are never created at all. Evaluating at a program purely by its end resulting state does not capture the entire, or even most, essence of what it means to write a program.
    - wnoise 11y ago
      > Once you have done the math, you really understand the problem, but that is a very steep mountain to climb. s/really/actually/ And yes, it is hard, but it actually works.
      - 11y ago
- deleted 11y ago
  [deleted]

by jules 11y ago

seanmcdirmid 11y ago

I don't think that is an accurate portrayal of OO. There are plenty of nouns out there that do not model real world concepts. I can create an "expression" class/object in a OO program (and do all the time!) to represent parts of an abstract syntax tree. As far as I know, expressions don't exist in the real world. Human language is quite powerful like that. Overabstraction is often simply a matter of poor problem understanding. Sometimes you don't really know how to solve a problem right, so you bite off parts of it, work your way through many layers until it is solved. The abstractions are not ideal, because not much planning was involved, and you didn't actually have the experience to generalize appropriately but...you needed some way to decompose the problem. Abstraction is a tool. It has a cost, but sometimes you need to pay it and sometimes you are better off not. We really need better ways of abstracting and, when necessary, unabstracting.

jules 11y ago
I think that's right, especially the second paragraph about the cause of the explosion of nouns. A common approach to OO programming is to take the problem and identify the nouns in the problem, and then make a class for each of those nouns before having a clear idea of how the program is going to work. This is especially prevalent in combination with TDD. This is a recipe for disaster if you ask me. A good example of this is when Ron Jeffries tried to write a sudoku solver.
- zamalek 11y ago
  Agreed. > identify the nouns in the problem This is what I was getting at by mentioning education as a possible culprit. You get out of university with this bad habit right off the bat, instead of the correct one: Identify the responsibilities in the solution. Identifying all the nouns in the problem sets you up for failure because you are implementing a solution before you know what the solution actually is. Said another way: you are in a very literal way implementing the problem and not the solution.
  - seanmcdirmid 11y ago
    What is so wrong about that? You have to understand the problem in some way. Perhaps we could spend a lot of time at the whiteboard understanding the problem waterfall style before we design the actual program? Realistically, this isn't very effective either.
- seanmcdirmid 11y ago
  There is nothing wrong about noun identification in itself, you have to solve the problem in some way. The functional approach avoids the nouns, the solutions can be more elegant, but man, coming up with those solutions is much harder. Decomposing a problem without nouns is like doing...math: it is much more difficult than just talking about it! Once you have done the math, you really understand the problem, but that is a very steep mountain to climb. I keep coming back to RPG's "worse is better" essay. The problem is that while the artifacts that we create might be horribly messy, they are better than the artifacts that are never created at all. Evaluating at a program purely by its end resulting state does not capture the entire, or even most, essence of what it means to write a program.
  - wnoise 11y ago
    > Once you have done the math, you really understand the problem, but that is a very steep mountain to climb. s/really/actually/ And yes, it is hard, but it actually works.
    - 11y ago
deleted 11y ago
[deleted]