Hacker News new | past | comments | ask | show | jobs | submit login

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.



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.


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.


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.


> 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.


Right, and in the meantime your competitors have shipped and taken over the market with their sub-optimal understanding of the problem, and you can't sell your solution even though it is perfect.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: