3 ms·

>> Write programs that do one thing and do it well. > Putting things together from a kit of parts isn't necessarily the optimal way to do many things. In many

>> Write programs that do one thing and do it well. > Putting things together from a kit of parts isn't necessarily the optimal way to do many things. In many cases tight integration actually produces superior results, and debugging a system made from many cooperating bits isn't necessarily any easier. Define "optimal" here. Without a definition this is a meaningless statement. But even if your definition of "optimal" is "easiest to debug", I'd have to disagree. Tightly coupled systems are nigh impossible to debug because you have to have the whole system composed together to debug anything. Loosely coupled systems allow you to debug each part separately, and small components mean they have little you have to debug. The next part of debugging is the interaction points, but that's easily constrained with a moment's thought when designing and developing a system. If "optimal" is about performance, that's a debatable thing. The tightly coupled shit some people put together at my office is terrible with respect to performance. It's bordering on negligence the way they designed it and trying to fix the performance issues is almost impossible again because of the tight coupling of different components. Regarding text streams: Ok, one weak point in some definitions/descriptions of it. The idea of utilizing a more universal data format though still stands. 1 million or so different binary formats isn't much better.

dale_glass 4y ago
That is kind of the point, you have to define the problem and the tradeoffs involved. Then sometimes one approach better than another. That determination should be made on a case-by-case basis, rather than as a religious matter. So for instance stringing too many things together also leads to confusion due to the many interactions between disparate bits. At some point you can end up too much parsing/serialization in the mix, too much accumulation of startup costs, or dealing a system that has components written in shell script, Perl, Python, C, C++ and Rust making the whole system difficult for any random person to comprehend fully.

dale_glass 4y ago

That is kind of the point, you have to define the problem and the tradeoffs involved. Then sometimes one approach better than another. That determination should be made on a case-by-case basis, rather than as a religious matter. So for instance stringing too many things together also leads to confusion due to the many interactions between disparate bits. At some point you can end up too much parsing/serialization in the mix, too much accumulation of startup costs, or dealing a system that has components written in shell script, Perl, Python, C, C++ and Rust making the whole system difficult for any random person to comprehend fully.