The nihilist programmer takes as axiomatic that their product is already broken. It is in constant flux, poorly defined, the product of compromise in design, and inevitably compromised in implementation. Even more, that it will remain this way, by its nature, forever. The nihilist programmer starts from these axioms and then decides what to do. What to do? The least amount of change possible. Limit exposure, limit effect. Get to the next checkpoint.
The particular medicine isn’t a bad one, per se. There’s value in those limits. What’s bad, I think, is the ethos. If a thing is undefinable, you will naturally resist efforts to define it. If a thing is forever in flux, you will resist efforts to freeze it. If a thing is composed exclusively of compromise, you will resist efforts to make decisive decisions. And if a thing will never be good, you will resist efforts to make it good.
.. The optimist programmer assumes the thing can be good, and constantly initiates to make it good. That the thing shouldn’t contain compromise, and should reflect clear decisions. That the thing should be defined and then built, and not rock forever on a sea of changing assumptions. That the thing ought rightly be defined, that its true form is definitional.
.. Successful projects live somewhere in the middle. But I think all good software is fundamentally optimistic. Not that it won’t contain compromise, or technical debt to be repaid, but that it doesn’t start from the assumption that nothing is definite and all hope is lost. Optimistic software makes decisive claims, executes on them, and owns the compromises it makes.
Since the days of the character mapped display, programmers have argued over whether tabs or spaces should be used to line up text. While both strategies can be used if all of a project’s programmers can agree on how many spaces wide a tab should be, experience has taught us that this is not always the case. Even if all of the programmers working on a project are diligent enough to stick to only using tabs or spaces and have tabs set to the agreed number of spaces, there is still a problem if any programmers wish to use modern proportional fonts (because a space is no longer the same width as every other character).
The reason why we have not yet settled conclusively on either tabs or spaces is that both camps can point to problems in the others’ approach. The truth is that both are right to be critical
I’m no data scientist, but to me it’s pretty obvious that Python has, by a very large margin, the greatest positive slope (future?). In fact, it appears to be only one of two languages listed here that even has a positive slope (R is the other one, and it looks like Assembly is low but pretty steady).
Search by language, framework, and toughness