3 ms·
From the post: "if the reusable code is already suitable, you just use it, but if it’s not, you decide whether or not you should modify how it works, or whether
by jstimpfle 4y ago
From the post: "if the reusable code is already suitable, you just use it, but if it’s not, you decide whether or not you should modify how it works, or whether you should introduce a new layer on top of or underneath it."
I'm having a really hard time interpreting this as "you should design / program bottom-up".
If you go to Wikipedia, bottom-up design is roughly defined as taking the existing stuff and building new things on top. I still fail to see where the compression part comes in here.
Neither of the two directions will look back at the mess they've made and compress it. They're just ways to develop the system by adding to it incrementally.
But then, these terms are generally poorly understood (as evident from various discussions I've had) and I don't want to claim to have the perfect understanding either. Nor do I want to be "Look"'ed any more. So, whatever.
- overgard 4y agoHonestly mate, I just don't really understand the point you're trying to make. Originally it was that it doesn't matter if the line-by-line code is understandable because the high level design is what's important. I think the line by line clarity is important, because if that's confusing in my experience the design tends to be muddled also. But then you have these definitions of bottom up and top down that are very confusing and seem to exist mostly to you. I'll simplify what my definition is: bottom up programming means you write the code without any abstractions first, and then you generate the abstractions as you find commonalities and repeated patterns. I find this to be superior to the other approach, of generating abstractions first and then filling in the code. That is my opinion, I know other's believe differently. And "look" is not an insult.
- deleted 4y ago[deleted]