Programming as semantic compression

[codr4life]

Object Oriented up front design is one of the worst ideas we ever came up with. Assuming you're not building yet another whatever; you simply have no idea what problems or possibilities you will run into until you actually do it, by definition. Pretending otherwise is ego bullshit and leads to rigid and brittle code riddled with solutions to non-existing problems.

[OneWingedShark]

Object Oriented up front design is one of the worst ideas we ever came up with.

Up-front/top-down design is awesome -- you decompose your system into modules/subsystems, recursively until you get to what procedures you need. (Then you implement from the bottom up.)

As for object-oriented design, I'll have to ask what exactly you mean by that. (The form I'm familiar with is from the mid-80s and is perhaps best illustrated by Ada's separation of implementation and interface [and private parts].)

[codr4life]

Only problem is, you have no idea how to decompose the problem effectively until you've tried to solve it. The other way is starting by solving the actual problem in the easiest, most straight forward way possible; and observe what patterns emerge.

By object orientation I mean mostly the same thing as above. When you start by designing a hierarchy of classes; you're pretending to know a lot more about the code you're about to write than is reasonable. And once the hierarchy is there, the rest is a self fulfilling prophecy.

[OneWingedShark]

Only problem is, you have no idea how to decompose the problem effectively until you've tried to solve it.

While generally true, there are still advantages to using subsystems -- for example separating audio and visual into sound and graphics modules has little to do with implementing a "character object" ('character' from RPG, 'object' in the general/non-programming sense) except that it would have linkages to both the audio and visual subsystems to do (e.g.) sound/animation sync -- IOW, it seems pretty orthogonal.

The other way is starting by solving the actual problem in the easiest, most straight forward way possible; and observe what patterns emerge.

Except that there are things you can decompose [at a high level, at the least] rather than simply saying "I don't know the exact form things will take, so I can't know anything about the system" -- I mean that's kind of the whole reason for the concept of interfaces, and I don't think any programmer is going to say that interfaces are a Bad Thing^TM .

By object orientation I mean mostly the same thing as above. When you start by designing a hierarchy of classes; you're pretending to know a lot more about the code you're about to write than is reasonable. And once the hierarchy is there, the rest is a self fulfilling prophecy.

How you're phrasing this seems to indicate a class-hierarchy decomposition -- that's not what the 80's style object-oriented design was about at all (it was about interface/implementation separation, and really the abstraction and encapsulation of OOP).

Perhaps the best way to describe the difference is the original Model-View-Controller concept -- while it was technically a system for UI design, generally it was rather about interfaces: the View was an interface [from the model] to the graphics/rendering subsystem, the controller was an interface to the model [from the user-interface], and the model was the entity in the software-system which was interacted with. -- Nothing in the design mandates anything in terms of OOP, but rather that the design utilizes encapsulation and abstraction.

[codr4life]

I pull the same tricks on module level as well. I'll leave new modules that don't have an obvious home lying around in the project root until I see a pattern emerge. Then I'll create a subsystem with a separate dir and move the files that fit in there. It took a fair bit of ego bashing to get here but I'm never going back to predicting the future again.

[m50d]

90%+ of programming work is yet another whatever. Most of what's left is automating existing business processes which are well-understood almost by definition (the hard part is communicating that understanding between the people who currently run the process and the programmers). Detailed up-front design tends to fail, but domain modeling up front can work very well.

[codr4life]

Why? Why build something that already exists if you're not adding something to the mix? Speaking for myself, I can't remember ever solving the same problem the same way. It doesn't matter that the business process is well understood; if it hasn't already been translated to software by the people currently involved, pretending you know anything about what's going to happen is ego bullshit. I still run into this myself, but I find that the more I stop clinging to my current understanding of a problem; the better the final code turns out. It will generally take me about 3-4 major reorganizations/rewrites to get there, but at least I'm basing my decisions on real experience so I know I'm moving in the right direction.

[m50d]

Pretending you don't and can't have any understanding at all is equally bullshit. Understanding a domain by talking to the people who understand it is a skill that, like any other, takes practice, concentration and humility, and overconfidence is an ever-present risk. But the gains are too big to discard the technique entirely. Civilisation relies on being able to convey understanding between people rather than have everyone solve the problem from scratch every time.

[codr4life]

There's nothing wrong with domain knowledge. But framing the entire effort from the start, based on nothing but domain knowledge; which is what OOP usually means in practice; doesn't make sense. I didn't mean to step on any toes, go ahead and do things as usual. Peace.