4 ms·

What he means there by saying "bottom-up", as far as I can tell, is that you "compress as you go", i.e. it is bottom-up compression, in a similar way to how you

What he means there by saying "bottom-up", as far as I can tell, is that you "compress as you go", i.e. it is bottom-up compression, in a similar way to how you can also write bottom-up parsers. It's not stating that you should start by creating lots of little artifacts before you have a great plan (bottom-up design) nor that you should start implementing the "non-functional requirements" (another confusing term) on a high level before you know the platform and other functional requirements, which is top-down design. So that's perhaps a justification why I said earlier that these terms are misleading :-) As to the other thing that I said, that bottom-up tends to create things you don't actually need, it's almost immediately following the definition of bottom-up. You can even find this on the Wikipedia page, which states that in practice, software-development typically uses a combination of bottom-up and top-down for that reason. (In other words, always strive to know as much as possible about requirements both at the "top" as well as at the "bottom", as early as possible. Or the risk is that the design won't fit some part of the requirements and large parts need to be redone). I still don't see the connection with what I originally wrote, in any case.

overgard 4y ago
> It's not stating that you should start by creating lots of little artifacts before you have a great plan (bottom-up design) Look, you can disagree with his conclusion, but that is exactly what he's saying. The post is long but it's very clear and methodical about how he's suggesting code should be designed and written. I happen to agree with him.
- deleted 4y ago
  [deleted]
- 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 ago
    Honestly 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]

overgard 4y ago

> It's not stating that you should start by creating lots of little artifacts before you have a great plan (bottom-up design) Look, you can disagree with his conclusion, but that is exactly what he's saying. The post is long but it's very clear and methodical about how he's suggesting code should be designed and written. I happen to agree with him.

deleted 4y ago
[deleted]
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 ago
  Honestly 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]