You think that efficiency and elegance is more important than maintainability and extensibility? If it’s maintainable and extensible, then you can always fix it to make it faster. I think it’s better to have a well-written and well-documented library in Python than to have a blazing-fast assembly language implementation.

As for elegance, I think that if code is maintainable and extensible, it has no need to be “elegant”.

It really should be looked at where each aspect is as dependent as possible on the ones below it. You need it to function above all, then you need it to function well (reliability/efficiency), then you need it to be useful and flexible to others (maintainable and extensible).

Code that behaves as expected is obviously important, as is documentation. I think this falls outside of this hierarchy though; the library code should also be built according to the hierarchy, and the “honesty” you’re talking about is really the functionality of the library. And documentation doesn’t really seem to have a spot in this hierarchy…not sure where it should go.

I agree that the line between functionality and reliability is a fuzzy one, but certainly there is software that “works” while not being especially reliable. For example, I don’t think it’s correct to say that Windows 95 wasn’t functional — it just wasn’t particularly reliable. Likewise, I’ve tried lots of programs that do the job they were intended to do, but choke on any unexpected input.

Code has to behave the way you expect it to. There are very few scenarios where a programmer is building from the metal up. If you’re relying on anyone else’s machinery, that machinery has to behave the way you expect it to. If code is too complex to understand quickly, it needs documentation. If there is documentation then it has to be accurate, and provide a rough idea of what the code actually does.

I wouldn’t separate functionality and reliability. If there are (say) threading issues in code, but it works well 95% of the time, it isn’t functional.