
12 (Really) Controversial Programming Opinions - johndcook
http://www.billthelizard.com/2012/09/12-really-controversial-programming.html
======
nahname
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
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.

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

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

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

~~~
killahpriest
Not an algorithm, but used in many. Pointers.

~~~
mistercow
Emulating pointers in JS is pretty easy; you just wrap the values in objects
or arrays.

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

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

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

~~~
Silhouette
_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
        }

~~~
suresk
Actually, the correct comment for an empty catch block is:

// This should never happen.

(Until it does)

I have mixed feelings about checked exceptions. They seem like a great idea in
theory - if there are known error states, then making them explicitly known
and forcing the consumer to acknowledge them in some way seems reasonable. In
practice, a lot of the time the only response to a checked exception is "let
it propagate up - there isn't anything useful I can do", which leads to extra
code and can be annoying.

Even though I don't have quite the negative feelings toward them others do, if
I were involved in designing a new language today, I'd probably vote against
including them. It would possibly be nice if a method could explicitly declare
which exceptions it was likely to throw, and then an IDE or static analysis
tool could use those to aid consumers of the API, without forcing them to deal
with every single one.

Interestingly enough, I view Scala's _Option_ construct as being somewhat
similar - forcing the consumer to acknowledge that a particular call could
return a null value - but it doesn't seem to provoke the same negative
visceral reactions that checked exceptions do.

------
6ren
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

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

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

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

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

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

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

~~~
pilgrim689
>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!

~~~
prodigal_erik
Wow, I'm pleased to see that's no longer totally beyond us, though the price
is still very high (LtU says fifty dev-years!)

~~~
pilgrim689
It was actually about 28 py, but that number would come down to 10 if they
were to do it again.

source: <http://ertos.nicta.com.au/research/l4.verified/numbers.pml>

~~~
smartkids
This is nothing compared to the number of py spent writing crapware. Think of
how much effort has been spent writing lousy software. It is enormous. (But
then most consumers of software don't know any better, so from a sales
perspective, maybe writing crapware makes perfect sense.)

IMHO, these guys are heros merely for undertaking the task, let alone
completing it.

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

------
gnaritas
Wow, mostly terrible advice.

~~~
jamesbritt
Can you elaborate?

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

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

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

------
briandear
Was this article just one big troll?

