12 (Really) Controversial Programming Opinions

I disagree with most of them and seemed to be biased towards a specific language the poster of the opinion liked/understood best or against one they disliked.

13. Most programmers think they know what they're doing but actually are "incompetent". (There are Usenet posts going back to 80's documenting this fact.) How am I defining "incompetent"? In my definition it means writing software that any reasonably skilled hacker can cause to "malfunction", i.e. not perform as expected by the programmer, which depending on the program may or may not present a security risk. The number of "competent" programmers i.e. those whose programs are immune to the acts of reasonably skilled hackers, is very small. They are a rare commodity. In sum, there's lots of reasonably skilled hackers and very few competent pogrammers. There is no licensing body for programmers. Anyone can call themselves a "professional programmer".

Note: If a programmer only writes programs for her own use, "competency", as defined above, is all but irrelevent. Whatever works.

Controversial, but true.

I do sort of agree with the try/catch criticism. I know what it achieves and why we need it but I don't agree that it's the best or even most intuitive error handling mechanism. I personally prefer returning error messages in place of or alongside expected data structure outputs, such as the common paradigm in JavaScript where async functions return error info (or null) as the first parameter in the supplied callback before returning the actual data (if no error) in the subsequent parameters.

I do somewhat agree with the OOP criticism as well. I find the best programming achievable is by mixing strategies and not adhering strictly to any one philosophy. Java's OOP is so inflexible and limiting that it takes a significant amount more effort to get basic work done. It may lead to a somewhat more manageable codebase at first, but I feel experience in your language of choice can bridge the gap between such a strict static-typed language vs a more elegant but potentially messier dynamic-typed language in this respect.

Finally I do agree that C should be taught before you learn any other programming language...but not to such a degree that you need to be able to build the best Javascript engine in the world from scratch before you move onto another programming language. The goal of programming is to build software that saves you time, after all - you aren't saving much time with as high a barrier to entry as mastering the fundamentals of C. It is important for theory discussion as well as learning the best way to code a lot of logic in many other languages, but I feel an abstracted language has failed if it hasn't done enough of the work for you to refactor your code properly in the first place. Loop unrolling, seriously? I like that I learned why it's important...but I shouldn't ever have to do that in any decently programmed higher level language.

One that really stood out to me:

6. The use of try/catch exception handling is worse than the use of simple return codes and associated common messaging structures to ferry useful error messages.

I think this really depends on the language. In erlang I absolutely hate exceptions because they don't really make sense in a functional language (which let's say erlang is for the sake of this argument). Threads run functions with only the function's parameters as state. It doesn't make sense to have to worry about a function stopping half way through, especially when most functions already pass up tuples looking like {error,E} or {success,S}. If you have to worry about exceptions as well, now you have to handle the error tuple and the exception case, and usually both cases are getting the same code so you have to go make a new function to call for that case. This gets messy. If a thread crashes it crashes, otherwise it should be passing up the error tuple; there's no reason for exceptions.

On the other hand I think exceptions make a lot of sense in python, and I think the python community has incorporated them in a standard way which makes sense, so that handling exceptions in python is actually easier then passing back different error codes and what-not (no atoms in python).

Knuth's code has bugs. NASA's code has bugs. I don't think our species has produced even one nontrivial correct program, much less a programmer who's competent (which I take to mean a large portion of their work is 100% correct). Our profession is passing through the mercury-and-leeches phase medicine once went through. Someday our descendants will look back from their error monad formal proofs or something and cringe at everything we did.