
The Humble Programmer - anacleto
http://c2.com/cgi/wiki?TheHumbleProgrammer
======
davnicwil
> program testing can be a very effective way to show the presence of bugs,
> but it is hopelessly inadequate for showing their absence.

Have seen this idea stated in various forms. In an absolute theoretical sense,
the idea is quite true, but I'm not sure what wisdom or value is supposed to
be imparted through expressing it - especially in the way it's phrased above.

The vast majority of programs exist to deliver net positive value in some
form. In this context, the value and even the concept of absolute correctness
become very fuzzy. Not all bugs are equal in terms of impact on that delivered
value. Beyond a certain threshold, what even is a bug? Is it a bug when the
program crashes when a user intentionally feeds it with extreme inputs, that
would never be used genuinely, to try and crash it? In a mathematical sense,
yes. In an engineering sense.. most likely not.

From this point of view, testing _will_ show an absence of bugs - not
categorically _all bugs_ , but _all bugs I care about_.

With testing I can show that my program performs a certain set of functions as
I want it to, with a certain set of inputs. That's a baseline, proved to be
bug-free. If that baseline provides the minimum value the program is written
to provide, then the program is by definition correct for its given purpose.

Whether it's correct in a pure, absolute, mathematical sense is a different
question (perhaps even a philosophical question) that it doesn't provide me
much value to answer. So where's the practical value in expressing this idea?

~~~
jhpriestley
Tests work because we don't use only tests - we use tests to support and
correct our logical reasoning. Even for a very simple task, if you literally
didn't think about how to solve it at all and just did the simplest thing to
make each test pass, you'd never accomplish it. E.g., "find the absolute value
of a number" would end up with a function like

    
    
        abs(n) {
            if(n == 1) return 1;
            if(n == -1) return 1;
            if(n == -3.5) return 3.5;
            ...
        }
    

This is why testing is not a substitute for logical reasoning, but a
complement; once we think we've solved a problem logically, we can test
several cases to check our reasoning.

This is also why no amount of testing will make up for a program with no
logical structure. For example, if you use unstructured GOTO as the only means
of control flow, then you won't be able to solve the resulting bugginess by
writing more tests.

~~~
jimmaswell
People actually do write tested and reliable "unstructured" code, eg pure
assembly. It's harder but it's not automatically impossible as is often
implied.

------
ak39

      The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague.
    

My very limited skull size balks when I see regex, IoC architectures, EAV data
modeling, fancy ORMs ... and, dare I say, ... functional programming.

~~~
adrianN
All those are tools that make certain jobs a lot less complex. I dare say you
either use them for the wrong job or you should try expanding the size of your
skull.

~~~
pekk
We demand actual proofs of program correctness, but for some reason we don't
even ask for proofs that practices actually work or even that they don't do
any harm. We just take it on intuition and faith, and propagate practices by
peer pressure. If it looks fancy, and people like it on HN, it must be better.
I don't know in what sense this is "engineering."

~~~
speedkills
Some people do actually gather evidence in this area. The best collection of
it I have found so far is the book Making Software: What Really Works and Why
We Believe It.

------
nnq
I find this easy-to-overlook and mostly-off-the-main-topic passage quite deep
and sadly truthful:

    
    
        There may also be political impediments. Even if we know how to educate tomorrow’s professional programmer, it is not certain that the society we are living in will allow us to do so.
        The first effect of teaching a methodology —rather than disseminating knowledge— is that of enhancing the capacities of the already capable, thus magnifying the difference in intelligence.
        In a society in which the educational system is used as an instrument for the establishment of a homogenized culture, in which the cream is prevented from rising to the top, the education of competent programmers could be politically impalatable.
    
    

...and the funny thing is that these "political" impediments have been driven
by nothing else than plain old month to month business objectives: by striving
for "replaceable programmers", or "reproducible performance" or "reducing the
buss factor" etc. we trowed away the most promising _" programmer brainpower
amplifiers"_, prevented "the cream" from rising too high by drowning it in
endless debugging and optimizations tasks that "needed to be done" because
"legacy", and we got a [C, C++ and Java] main-languages-combo instead of a
[some-low-level-ML, Lisp and Smalltalk] one.

 _But if you know that you can always fire your top programmer and still
survive as a business, it was worth the cost of x-times programming
productivity reduction, right?_ (Plus the more global thing: anyone with less
money and training than you have, like some bunch of unknown 3rd world country
programmers, is very unlikely to overtake your business if most of the true
brainpower-amplifiers are thoroughly crippled, and you also have the "network
effects" part turned against them - read below)

And the _awesome_ part was that by doing this industry-wise, any competitive
advantage that could be had by the party-line-breakers choosing the x-times
tech was lost because of the network-effect-induced-handicaps: if they need to
take a week to rewrite that library in their smarter language/stack and
another week for the other one etc., that x-times advantage goes away pretty
fast ...except for a few that were _really smart_ and made all the right
micro-decision at all the right levels (and had some _pretty strong_ place and
time advantages too - like simply _being_ in SV around '95), like PG with
Viaweb and a few others.

...it's really sad to read and write this, seeing that despite someone really
smart like Dijkstra saw this a few decades earlier, it still went this way.

~~~
SZJX
This statement by Dijkstra sounds a bit determinist/elitist. Differences in
talent/"intelligence" is largely a myth while only accumulation of experience
matters. This kind of claim is dangerous in that it allows those higher up in
the ladder claim that they're "naturally gifted" to take their positions while
in fact they most likely just have had more resources growing up. The current
society is already inegalitarian and unmeritocratic enough and such claims
could only fuel the situation further.

I totally agree with the point on homogenization of programming. However this
is more likely just a ubiquitous feature of today's globalized capitalist
world. I don't think it has anything to do with so-called "difference in
intelligence" or whatsoever. More aspiring programmers will want to program at
higher levels, and it's a good thing, as long as they don't claim this is due
to them being superior intellectually than their other counterparts.

------
rootlocus
> To put it in another way: as the power of available machines grew by a
> factor of more than a thousand, society’s ambition to apply these machines
> grew in proportion, and it was the poor programmer who found his job in this
> exploded field of tension between ends and means.

I always thought that it was easier to be a programmer in the old days. Back
when you could assess the performance of a program by counting the number of
CPU cycles. All you had to learn was an assembly manual (a mere hundred
pages?) and you knew everything there was to know about programming for that
architecture. And there weren't that many architectures. Now we have non-
deterministic CPUs, hundreds of high level programming languages, multiple
operating systems, an entire jungle.

~~~
belenos46
We went from basically being mathematicians ("That solution is best, and
here's my proof") to engineers ("This solution works, and it works with the
parts you give me, and don't ask why there's cake") to "why does this posting
for a back end developer also require CSS fluency?" I grant that the last is
not as concise as mathematician or engineer, but I feel like we're just about
there.

------
wavegeek
Warning: this article is by Dijkstra.

You may remember him as the person after whom the unit of arrogance, the
nanoDijkstra, is named.

~~~
emirozer
Dutch directness has a side effect of coming across as arrogant, its merely a
difference in culture[0].

For example, if you are Dutch and your friends are Dutch, you don't go on and
ask "how are you?" to the people that aren't close to you.

The question "how are you?" is actually there for you to show genuine interest
in someone else's life at that moment. The polar opposite of it is the US
version i guess, where a "how are you?" results almost always with a "fine and
you?".

On another note, i think the main reason(i might be very wrong here) that they
had this clash is Alan Kay being a pioneer in object oriented programming. And
Dijkstra's counter-discourses against it and sometimes those discourses were
harsh[1]. (Although we can agree oop is garbage :D, that is certainly not the
best way to put it.)

[0]: Although i have met some Dutch people that were being rude and trying to
cover it with "Directness"

[http://www.iamexpat.nl/read-and-discuss/expat-
page/articles/...](http://www.iamexpat.nl/read-and-discuss/expat-
page/articles/perks-of-dutch-directness)

[1]:
[http://harmful.cat-v.org/software/OO_programming/](http://harmful.cat-v.org/software/OO_programming/)

~~~
nnq
> Although we can agree oop is garbage :D

Can we? The stuff that Alan Kay put forward in Smalltalk, with message-
passing, polymorphism, late binding etc.... was definitely NOT garbage imho!

What C++ an Java and all the all the languages that tried to copy them, and
also Javascript with its prototypal inheritance ended up with... it stinks
indeed.

But where Scala on one side, and Go and Rust on the other are going... that
will be interesting at least :)

Maybe Odersky is on to something with his whole "functional and oo are
orthogonal" thing... though the way macros are implemented in Scala _on top of
and USING the oo core_ instead of _separate and serving as the foundation for
oo (CL style)_ makes me wanna puke when reading the resulting code...

~~~
vezzy-fnord
Indeed, OO hatred is usually a sign of an inexperienced functional programmer.

~~~
Lawtonfogle
Hatred of most any language or set thereof is often a sign of inexperience.
The only exceptions I can think of are production use of most joke/esoteric
languages and Oracle Forms.

~~~
MichaelGG
Doesn't this mean that anything in production is beyond "hatred"?

------
omouse
Is there a new c2 wiki where programmers hang out? I know we have HN, proggit
(reddit/r/programming), and stackoverflow but where's the coder wiki where
dilbert comics are posted every day? :P

------
kungfooman
The humble Programmer can't handle the taco.

