Design by committee

Back when I used to work with COBOL, there were jokes about “design by committee”. These days I’m not always sure that C++ isn’t going the same way. So many little bits and pieces have been stuffed into the language to make it more difficult for people to do “the wrong thing” that the code is becoming completely incomprehensible if they’re fully utilised. And there’s stuff that was added to the language not so long ago that is now at best deprecated or at worst illegal now. I think the time has come to stop fiddling, please?

I’ve had a situation this week where a package used by code I’m working on (which has to be compiled using C++20 standards) can’t be used because it’s C++14 (I think) and in C++20 mode the compiler throws it out. I can’t upgrade the package to a later version (which is C++20-compatible) because that would break other applications using the same package. I could carry around my own private copy of the newer version in my code, but then I become responsible for making sure that new releases of the application get made if, say, there’s an important bugfix in the package, or if there’s a security hole found that has to be fixed. I don’t want that. It’s just too much work. In this instance I can wait a while to see how things progress with the other dependent packages, but I could really do without the pain.

Come to think of it, I’ve been in the same sort of place before with Ruby which can really trap you in dependency hell before you know it’s happening. That one ended up with the application being abandoned and re-written. Not in Ruby.

This entry was posted in Computing and tagged . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *