Wow, mostly terrible advice.
Can you elaborate?
12 (Really) Controversial Programming Opinions
11–20 of 61 posts
Re: 12 (Really) Controversial Programming Opinions
#1213. 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 num…
If you go through the answers on Stack Overflow, the point that "most programmers are incompetent" was made quite frequently. Those that made an effort to support their opinion were highly upvoted (so not that controversial), but many others didn't so they just sat at 0-1 upvotes.
I hate writing what I just wrote because I know it might offend some people. I'm OK with the "incompetence" (I'm sure I qualify myself), but it's the fact that many of these programmers think they know what they're doing that bugs me. And they are writing software that will be used by other people.
They don't want to admit their mistakes or that someone else might understand things they don't. They actually think they are being smart when they are really being stupid.
Certainly not looking for "votes" with this one. Although I did get an upvote immediately, then a downvote from, who would have guessed, a closed source developer.
I'm not a fan of StackOverflow. There is a lot of stupidity and herd mentality there. It's not where I would look for "competent programmers". Like finding a needle in a haystack.
Re: 12 (Really) Controversial Programming Opinions
#1313. 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 num…
I agree with the assertion that few (probably close to 0) programmers routinely write bug-free code, but I think "incompetent" is a bit harsh - "imperfect" is more apt, I think.
Very, very few non-trivial pieces of code are completely bug-free, and building anything interesting under normal time constraints is really difficult and expensive to prove 100% correct.
So, I guess that point is true, but ultimately not very useful.
Re: 12 (Really) Controversial Programming Opinions
#14Mostly opinions of an angry C programmer. Disagree with all of them. Too context specific. For example, testing. It is generally a good idea, but you don't always want to invest the time if it will have a negative return. Small projects or throw away work are two conditions where this would be true.
Re: 12 (Really) Controversial Programming Opinions
#1513. 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 num…
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 cring…
Yes. This is why I defined "incompetence" quite carefully.
Finding bugs in Knuth's or NASA's code might be beyond "a reasonably skilled hacker". To find bugs in that code you would likely have to be "highly skilled", above average.
Everyone makes mistakes. Even professionals who are licensed. The idea is to minimise them to achieve a reasonable, expected level of "correctness". Competent does not mean "perfect". It means no stupid mistakes.
In my biased opinion, there's a high tolerance for stupid mistakes in software.
Re: 12 (Really) Controversial Programming Opinions
#16guys,
>The first language should NOT be the easy one, it should be >one that sets up the student's mind and prepare it for >serious computer science. >C is perfect for that, it forces students to think about >memory and all the low level stuff,
as one low-level programmer to another, I hate to break it to you, but "low level programming" is not "serious computer science". the two have very little to do with each other.
Re: 12 (Really) Controversial Programming Opinions
#17I 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…
I don't. Exceptions in general FORCE a developer to deal with the problem. They can slap a developer in the face if they're abusing the API.
Error codes on the other hand can be ignored.
PutLionInCage();
PokeLionWithStick();
I'd rather PutLionInCage() throws if there is a problem.
Re: 12 (Really) Controversial Programming Opinions
#18I 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…
I don't. Exceptions in general FORCE a developer to deal with the problem. They can slap a developer in the face if they're abusing the API. Error codes on the other hand can be ignored. PutLionInCage(); PokeLionWithStick(); I'd rather PutLionInCage() throws if there is a problem.
If you need an exception here, you're just a bad programmer. It's your fault you didn't explicitly check that the lock was functional before poking that lion! /s
Re: 12 (Really) Controversial Programming Opinions
#19Re: 12 (Really) Controversial Programming Opinions
#20Earlier quoted context omitted.
I don't. Exceptions in general FORCE a developer to deal with the problem. They can slap a developer in the face if they're abusing the API. Error codes on the other hand can be ignored. PutLionInCage(); PokeLionWithStick(); I'd rather PutLionInCage() throws if there is a problem.
If you need an exception here, you're just a bad programmer. It's your fault you didn't explicitly check that the lock was functional before poking that lion! /s
But sometimes it's not just the programmer that gets bitten, it's all the other people at the zoo, too. Exceptions help protect everyone.