3 ms·
Yes and no. I think Stallman is right in that it's important to realise the relationships between components are often a bigger and more pernicious source of bu
by sgentle 12y ago
Yes and no. I think Stallman is right in that it's important to realise the relationships between components are often a bigger and more pernicious source of bugs than the components themselves. It's not a problem when you can pretend the components are actually one single component, which is obviously not possible with service architectures or proprietary code.
I'd expand that to say there's a kind of CAP theorem analogue for code, where if you want it to be sufficiently modular (partition-tolerant) you'll need to either sacrifice availability (before you know if it works you have to check its interaction with every other module) or consistency (you write code assuming the other modules work the way you expect and maybe they don't)
Unfortunately, beyond that core idea this article is just sort of befuddled. It is possible to understand the behaviour of a component without seeing its code (contracts, APIs, specs and tests are all examples of doing this). Further, it's a problem not at all specific to proprietary software. Even if you have access to every line of code ever written you're still not going to be able to understand the million interactions that could exist between all the things currently running on your computer in their various languages, frameworks, architectures and programming styles. And, to the extent that you can, it's probably not a very good use of your time compared with just emailing whoever wrote it and saying "hey, your software's not doing what I think it should do".
- qwerta 12y agoI upvote, but disagree. Studying source code is first step. There is difference between "full understanding", and fixing a bug when software crashes under very specific conditions. Modern IDEs (and hopefully unit tests with VCS history) are great, 1+ MLOC is not really a problem. Good luck with contacting original author, I usually give up after a few weeks. And even proprietary software can expose enough "source" without compromising its monopoly. Microsoft bundles debugging symbols, so you can debug their software and roughly understand whats going on.
- deleted 12y ago[deleted]
- ademarre 12y ago> It's not a problem when you can pretend the components are actually one single component, which is obviously not possible with service architectures or proprietary code. Yes. It seems Stallman is mostly trying to highlight a problem with closed-source software, and he's right, but this doesn't acknowledge that it's not always possible to treat a software system as one big component, even if everything is open source. If the APIs are no more complex than necessary, and do a good job of encapsulation, then it should be easy enough to identify the misbehaving component and submit a meaningful bug report without seeing the source. I believe that with distributed systems and service architectures, there are higher level design principles that we should be adopting. Many design patterns from other disciplines, for example OO APIs, can be applied to distributed components in large systems. These principles encourage encapsulation, which usually results in elegant communication protocols between distributed components.