3 ms·

Your assertion that dependencies are the cause of the bloat is only trivially acceptable if, at least, every dependency actually contributed into the binary siz

Your assertion that dependencies are the cause of the bloat is only trivially acceptable if, at least, every dependency actually contributed into the binary size, nevertheless in a significant manner. Thus it is a counterpoint. That makes zero sense. That's like saying your luggage can't be too heavy because it contains a feather. Think about this super hard. So I'm asking for actual proof, like a disassembly, or analysis through other tooling. You think you need disassembly to see file sizes?

fluffybucktsnek 6mo ago
> That's like saying your luggage can't be too heavy because it contains a feather. Think about it super hard. There's nothing to think here. This analogy is stupid at best, profoundly ignorant at worst. We both agree that the binary is 50MB (the weight), so the "luggage can't be too heavy" is already nonsense. > You think you need disassembly to see file sizes? I mean the cause for the 50MB, if that wasn't clear (somehow).
- CyberDildonics 6mo ago
  This analogy is stupid at best, profoundly ignorant at worst. No it isn't. If you could explain why you would have already. Saying that some dependencies aren't heavy so the problem isn't dependencies doesn't make any sense. Huge bloated binaries are from lots of bloated dependencies because people aren't actually writing 50 MB of stuff to do what they need.
  - fluffybucktsnek 6mo ago
    > If you could explain why you have already. I have my suspicions. But I rather speak with certainty rather than spout unfounded hypotheses as facts. > Saying that some dependencies aren't heavy so the problem isn't dependencies doesn't make sense. If I did say that. I said that isn't necessarily dependencies, because you have yet to prove it. If you do prove it, then that is that. As of now, all you've shown is that thread. > Huge bloated binaries are from lots of bloated dependencies because people aren't actually writing 50MB of stuff to do what they need. Restating what I've said prior, you are just asserting this, but have yet to prove it. For starters, what are the specific bloated dependencies? How much space does each dependency actually occupy in the final binary? A disassembly would answer those really quickly.
    - CyberDildonics 6mo ago
      what are the specific bloated dependencies? Not a single data structure, that's for sure. Have you ever programmed before?
      - fluffybucktsnek 6mo ago
        > Not a single data structure, that's for sure. Even though you have to actually substantantiate this, for the sake of brevity, let's go with it. All you have crossed is a single potential cause, not proven a particular one. > Have you ever programmed before? Let's say I haven't. How would it impact your argument? Whether I'm a programmer or not won't magically substantiate your position.
        CyberDildonics 6mo ago
        Let's say I haven't. That explains why what you're saying and focusing on doesn't seem to really make sense. Even though you have to actually substantantiate this, Data structures are parts of programs that hold data. Have you made a data structure before?
        fluffybucktsnek 6mo ago
        > That explains why what you're saying and focusing on doesn't seem to make sense. Or it could be just you. Even presuming you're a good programmer, that wouldn't make your arguments good by default. > Data structures are parts of the program that hold data. Not according to Wikipedia: > In computer science, a data structure is a data organization and storage format that is usually chosen for efficient access to data. ECS doesn't stipulate any storage format, as shown by the previous definitions, only that your application will be architected around Entities, Components and Systems. How they are stored/managed is up to the programs/frameworks/engines to decide, and this storage is just one concern an implementation may have, just like how storing ViewModels is just one concern of a MVVM framework, but not all. I'm no stranger to using unorthodox definitions, but I would prefer if you were upfront that your definitions are unconventional, rather than pretend that they are common sense without citing any third party authority.

fluffybucktsnek 6mo ago

> That's like saying your luggage can't be too heavy because it contains a feather. Think about it super hard. There's nothing to think here. This analogy is stupid at best, profoundly ignorant at worst. We both agree that the binary is 50MB (the weight), so the "luggage can't be too heavy" is already nonsense. > You think you need disassembly to see file sizes? I mean the cause for the 50MB, if that wasn't clear (somehow).

CyberDildonics 6mo ago
This analogy is stupid at best, profoundly ignorant at worst. No it isn't. If you could explain why you would have already. Saying that some dependencies aren't heavy so the problem isn't dependencies doesn't make any sense. Huge bloated binaries are from lots of bloated dependencies because people aren't actually writing 50 MB of stuff to do what they need.
- fluffybucktsnek 6mo ago
  > If you could explain why you have already. I have my suspicions. But I rather speak with certainty rather than spout unfounded hypotheses as facts. > Saying that some dependencies aren't heavy so the problem isn't dependencies doesn't make sense. If I did say that. I said that isn't necessarily dependencies, because you have yet to prove it. If you do prove it, then that is that. As of now, all you've shown is that thread. > Huge bloated binaries are from lots of bloated dependencies because people aren't actually writing 50MB of stuff to do what they need. Restating what I've said prior, you are just asserting this, but have yet to prove it. For starters, what are the specific bloated dependencies? How much space does each dependency actually occupy in the final binary? A disassembly would answer those really quickly.
  - CyberDildonics 6mo ago
    what are the specific bloated dependencies? Not a single data structure, that's for sure. Have you ever programmed before?
    - fluffybucktsnek 6mo ago
      > Not a single data structure, that's for sure. Even though you have to actually substantantiate this, for the sake of brevity, let's go with it. All you have crossed is a single potential cause, not proven a particular one. > Have you ever programmed before? Let's say I haven't. How would it impact your argument? Whether I'm a programmer or not won't magically substantiate your position.
      - CyberDildonics 6mo ago
        Let's say I haven't. That explains why what you're saying and focusing on doesn't seem to really make sense. Even though you have to actually substantantiate this, Data structures are parts of programs that hold data. Have you made a data structure before?
        fluffybucktsnek 6mo ago
        > That explains why what you're saying and focusing on doesn't seem to make sense. Or it could be just you. Even presuming you're a good programmer, that wouldn't make your arguments good by default. > Data structures are parts of the program that hold data. Not according to Wikipedia: > In computer science, a data structure is a data organization and storage format that is usually chosen for efficient access to data. ECS doesn't stipulate any storage format, as shown by the previous definitions, only that your application will be architected around Entities, Components and Systems. How they are stored/managed is up to the programs/frameworks/engines to decide, and this storage is just one concern an implementation may have, just like how storing ViewModels is just one concern of a MVVM framework, but not all. I'm no stranger to using unorthodox definitions, but I would prefer if you were upfront that your definitions are unconventional, rather than pretend that they are common sense without citing any third party authority.