12 (Really) Controversial Programming Opinions

http://www.billthelizard.com/2012/09/12-really-controversial-programming.html

by johndcook • 14 years ago

31 60 14 years ago

siloraptor• 14 years ago

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.

gnaritas2• 14 years ago

Wow, mostly terrible advice.

jamesbritt• 14 years ago

Can you elaborate?

warmwaffles• 14 years ago

I would also like to hear an explanation. I found many of the topics thought provoking, such as Single Entry Single Exit.

Silhouette2• 14 years ago

Well, some of the suggestions have been fairly thoroughly examined by now, and often with quite clear results.

For example, anyone who advocates writing only extremely short functions because they leave less room for bugs appears to be wrong in about the same way that someone who thinks that 2+2=5 or that a chainsaw is a good implement for brain surgery is wrong.

gnaritas2• 14 years ago

I find it odd that I have to, other than 7 and 10, which I'm not saying are necessarily always good advice, the rest are just terrible advice that I think are self evidently terrible advice. Experience has taught me nearly exactly the opposite; the advice strikes me as bad programmers who only know one language generalizing their poor procedural skills across domains they don't understand.

Of course, that's the point of the article, "Really" controversial. Seems most people voted those opinions down as poor advice, which they're correct in doing.

smartkids5• 14 years ago

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.

cruise02• 14 years ago

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.

smartkids5• 14 years ago

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.

prodigal_erik4• 14 years ago

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.

smartkids5• 14 years ago

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.

pilgrim6892• 14 years ago

>I don't think our species has produced even one nontrivial correct program

Off the top of my head: seL4, a correct microkernel...pretty nontrivial!

suresk3• 14 years ago

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.

tikhonj• 14 years ago

This is a narrow view of what software is supposed to do. Are styrofoam cups inferior or are their designers "incompetent" because they break easily? No! That's the whole point--they are cheap and disposable.

The same is true about most software people write--it is also cheap and disposable. Often, having something that works well enough now is better than having something that works well tomorrow. I'm not even talking about being impervious to skilled hackers; even breaking under normal use is not necessarily bad.

Sure, if your software would kill people or destroy things, you have an issue. If your software is very critical and usually above suspicion (like a compiler, say) this would also be a problem. But if you're just writing a web app to share cat pictures or some internal tools or really most any other type of software? It's most often better to be cheap and fragile than good and solid.

My laptop is probably my single most important possession. (Yeah, I'm a student so I don't really have much else :P.) Do I have a Tough Book which is nigh unbreakable? Nope. I have a laptop which is actually fairly easy to mess up. And it is in every practical sense the better choice.

This is, coincidentally, why I think the cynical view of "planned obsolescence" is somewhat shortsighted. Sure, in a sense it's bad that electronic gadgets fall apart after a couple of years. But there's no cynical force behind all this: the simple fact that you wouldn't pay twice as much for a phone which is only more sturdy--but not more capable--is what drives the markets. If you were really worried about it, you would have bought a purpose-built device that would hold up better; instead you bought something cheaper which will break sooner. And this is a perfectly reasonable compromise to make!

smartkids5• 14 years ago

Toughbook is hardware not software. Get an old Thinkpad. It's durable.

I take the opposite view. I like durable software. And that's how I build my systems. If they get trashed, they can be restored in minutes. I'd rather spend my effort preparing simple durable systems that can be restored easily than building complex, fragile systems that would be difficult to reconstruct if something goes wrong. I've heard that sometimes things can go wrong.

zachgalant• 14 years ago

I don't agree with many of the points, but having taught a lot of beginners while loops, they are often very confusing to people.

I usually end up explaining them like a repeat...until, which usually makes more sense to non-programmers.

structAnkit• 14 years ago

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.

Quarrelsome3• 14 years ago

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.

hackinthebochs2• 14 years ago

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

suresk3• 14 years ago

They don't necessarily force the developer to deal with the problem, unless you're talking about checked exceptions (which are a whole other controversial programming opinion). What they do accomplish, in my opinion, is more deterministic behavior and easier debugging.

If you rely solely on return codes to indicate an invalid state and the caller is free to ignore the error codes, it makes it much easier for the program to continue on doing invalid things - this is akin to wrapping everything with try/catch blocks and suppressing exceptions. Even more, when you do realize something is wrong, a system utilizing exceptions is generally much better at propagating information about the original problem.

Silhouette2• 14 years ago

Exceptions in general FORCE a developer to deal with the problem.

There are good arguments in favour of exceptions, but I don't think this is one of them. If Java has taught us anything, it is that trying to force someone to handle exceptions just causes a lot of code that says:

    catch (Exception e)
    {
        // silently ignore e
    }

mediocregopher• 14 years ago

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).

6ren• 14 years ago

There can only be controversy when either the truth isn't clear, or it doesn't matter. If we knew the answer, and it mattered, everyone would do it that way (and those who didn't would lose to those who did). e.g. religious wars:

  vi vs emacs
  OO vs fp

javert3• 14 years ago

I don't agree at all. I don't think Galileo would agree, either.

nahname• 14 years ago

Mostly 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.

epsylon• 14 years ago

These are NOT his opinions but the opinion of several different people who answered the original StackOverflow question.

The first one, for example, is obviously a joke.

munin2• 14 years ago

guys,

>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.

lucisferre4• 14 years ago

Ironically C is technically a high level language anyways.

heretohelp2• 14 years ago

'ish.

C exists in the middle territory between high (colloquially right now) and "original" low-level programming.

By all accounts, virtually any language that operates relatively close to the semantics of the machine in terms of operations and memory (pointers are a standard abstraction in assembler) is a low-level language.

The only things that detract from C's low-level credentials are that it is more of a hybrid attempt at grafting a harvard machine onto von neumann machines and its functions. The functions/stack are a bit of an abstraction depending on which architecture you're using.

Calling C high level isn't accurate or descriptive, but I'd be willing to concede that it's not truly low-level either if you know enough C to explain why.

You don't, though.

RonPaul2012• 14 years ago

Not if you live in the 2012

javert3• 14 years ago

That's pretty true. However, in C, you can actually write interesting data structures and algorithms that come up in computer science. I think that makes for good "theory meets practice"-based learning.

I'm not saying all algorithms classes should incorporate writing C code all the time. But probably every budding computer scientist or software engineer should take at least one such class.

I'm also not saying C is the only language for which this is true. But it's definitely not generally true for interpreted languages.

Also, C is pretty much the language everything higher-level is implemented in. So once again, at least some exposure to C can help someone conceptualize what's happening on the computer at every level.

mistercow4• 14 years ago

Hmm, can you give an example of a typical "learning CS" level algorithm that you can't implement in, say, JavaScript?

munin2• 14 years ago

absolutely! C is so widespread that you should be conversant in it as a software practitioner, whether as a programmer shipping code or a scientist making tools and working with others tools.

however you can explore what computer science has to offer without subjecting yourself to C. I think that "computer science" has more to do with "optimizing algorithms for efficiency" and less to do with "staring at stack traces and wondering why gdb is so bad"

snogglethorpe• 14 years ago

I like this quote from Knuth: "People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird."

C is only marginally closer to the hardware than other languages, and programmers really should be aware of even lower level concepts, but I think learning C is a hugely useful and relatively digestible step towards really understanding what's going on.

shaggyfrog• 14 years ago

A linkbait, "N Ys that X" content-farmy headline that seems just tailor-made for getting on HN.

lucisferre4• 14 years ago

Actually I think that it's a more ironic take on the meaningless links that made the front page (twice I believe) a while ago about some (not so) controversial opinions on software development. I certainly hope no one thought any of these were opinions to be taken seriously.

ScottBurson• 14 years ago

Really surprised at the amount of hate for Python significant indentation. I've only used Python a little, and I expected to hate that too, but found it wasn't really so bad. I thought my experience was pretty common, and that by now most people either thought it was a great idea or at least found it tolerable. But "it was a bad idea" is currently favored 43 to 5. Maybe not many Pythonistas have seen this page yet.

gitarr• 14 years ago

In my opinion not many Python programmers care for places like stackoverflow, as the language itself has excelent infrastructure to deal with problems and to get ones questions answered quickly without bothering other people. Maybe that's why the vote is so high there.

Everyone working with Python a little while won't even think about indentation anymore, it just comes natural. It's not a big deal.

Python is often made out in discussions like that to be for begginners only and only amateurs would use it because its slow, not concurrent etc... The truth though is that YouTube, Reddit, Dropbox, Spotify, Discuss, Google, Nasa and many other "real" professionals use Python in a big way.

I tend to ignore such trolls.

mongol• 14 years ago

One opinion of mine is "code is also configuration". If you structure the code right, I see nothing wrong with putting stuff that many people see as configuration in the code. I do Java programming, and I think that frameworks like Spring are overrated. There is nothing very different from stitching together dependency injection with XML than with Java code. It is a pattern, not a framework. But the Spring trend is hard to walk against, it is so strong. I am getting tired of this occupation.

prodigal_erik4• 14 years ago

I err on the side of http://en.wikipedia.org/wiki/Rule_of_least_power. While it's true that code is data, arbitrary code is a form of data that's exceptionally hard to analyze or repurpose. Text config rules out stuff like dynamically-composed names of objects and properties (which you can't search-and-replace).

briandear• 14 years ago

Was this article just one big troll?

12 (Really) Controversial Programming Opinions

Related Stories