

The Applied Theory of writing bug-free code - clawrencewenham
http://sites.google.com/site/yacoset/Home/how-to-avoid-writing-bugs

======
swombat
I stopped reading at "strong typing". (well, not really... but I started
typing this comment roundabout there)

First of all, what he describes is not called strong typing, it's called
static typing. Ruby, for example, has strong typing (every object is one type
and one type only), but not static typing (you don't declare the type of an
object when you declare a variable).

Secondly, there are many powerful languages that don't have static typing. Is
the author implying that those languages are inherently buggy?

Thirdly, the author is not advocating what he declares in the title. He
proposes methods to catch bugs, not to avoid them. His methods are also flawed
in that redundancy does not ensure bug-free code - only that you haven't made
any silly mistakes in your coding. Bugs come from all sorts of sources, and
"code typos" are only one minor source. Other sources include: maintenance
changes (which cause unforeseen effects that were not previously covered by
tests), design flaws, and changed external circumstances. None of those are
covered by the technique he lists.

Sorry, but this is just a poor attempt to capitalise on a catchy title.
Nothing to see.

~~~
scotty79
Static typing gives you 'redundancy of meaning' solution for a fairly rare and
not especially harmful, or hard to detect by other means, error of holding
some data types under identifier that you meant to hold values of different
type.

It's a hard solution (vide generics and all the redundant typing) for minor
problem and it cannot justify its existence on such basis.

For me static typing is just a hack on the side of compiler guys to make their
work easier for them. It was claimed to have benefits for programmers at later
date.

~~~
silentOpen
Have you written in anything from the ML family? I strongly recommend you take
a look at OCaml or Haskell. I believe you will find that static typing, when
done right, is immensely helpful.

~~~
scotty79
I'm using language without static typing for most of my work and I can hardly
remember any bug that was caused by having wrong type of data in unexpected
place. I remember very well redundancy of using language with static typing, I
know how much boilerplate code is needed in languages such as java, and how
complicated can generics become in C# if you want to achieve fairly simple
architectural things that can be concisely expressed in dynamically typed
languages.

~~~
silentOpen
Ok. Those languages do static typing incorrectly. Try a language that sports
type inference. It isn't redundant. There isn't boilerplate. The type system
is far more powerful than in Java or C# (polymorphic types, polymorphic
variant types, algebraic types and constructors, functors, etc).

You owe it to yourself to learn these systems. In many cases, there are type-
side symptoms of logic-side bugs. If Haskell's laziness and purity scare you,
try OCaml -- it's fast and straightforward.

------
anatoly
I'm forever intrigued by the mind's ability to discern patterns. Today I
realized that just from the few examples that appeared on HN, my mind has -
quite unconsciously - locked on the combination of google.com in the site slot
and a title about programming and its methodology. "Oh, it's that yacoset
person", my mind tells itself without words, and I feel a little jolt of
recognition-cum-disappointment (for the pieces are usually fluffy and fussy).
I distrust myself, and so I hover over the link to make sure, yet so far the
pattern has held without fail.

~~~
clawrencewenham
Ouch.

------
russell
What he is really arguing for is more redundancy in programming. Strong typing
(he really means static typing), so you can type (with your fingers) thing
more than once and you can put constraint enforcing wrappers around your
values. Assertions an method contracts, TDD and unit tests, and finally NASA
style parallel development.

Except for unit testing, I question most of it. The problem with too much
redundancy is that it slows you down. If you create too much ceremony, it
takes 20 mediocre programmers to do poorly what 5 good programmers can do
well.

I would much prefer good tools to redundancy, for example type inference over
Java style type repetition. Maybe you can use asserts as a programming aid,
but not in production. If you may get null values, deal with them; try not to
create an exception for someone else to deal with. And if we used NASA style
coding, it would take 5 years to get a web site up.

~~~
diN0bot
this might be appropriate for NASA level programs, which i suspect are
_heavily_ spec'd and designed before any code is written, and then they want
the code to work, probably without much iteration. i'm not sure if this is
completely wise, since iteration on implementation can be useful, but if the
_client_ 's specs don't change and you have very experienced coders, then
iteration may not be that useful. very correct code is.

on the other hand, for (young) programmers learning the latest web 2.0 tools
andtweaking if not changing the product frequently, iteration, and thus speed
is incredibly useful.

i think both approaches, heavily simplified here, could work--assuming the
folks involved aren't just following a recipe but engaging with the process
and committed to making it work for their particular circumstance.

~~~
WinterAyars
NASA has some rather particular requirements, though. If their systems fail
their spaceships crash and explode. Possibly killing people.

It's a much stricter requirement than most people will ever deal with, but wow
do you not ever want to get that wrong.

------
diN0bot
i don't know. in college i wrote static and dynamic program analyzers, and was
in a very pro-java-typing group. when i moved to python i was sure the lack of
typing would be problematic.

the lack of static typing has NEVER caused a bug. a few times i will have a
bug because i mispell a variable name, thereby inadvertantly creating a new
variable, but i have always found those problems on the next run of the
program.

vastly more useful are creating tests and using them often.

to be fair to my college days, i still create object models (ish...i have my
own version) and other diagrams, which i find crucial for design and frequent
reference aftewards.

the whole "type" thing must be important for other problem domains.

~~~
derefr
Pretend there was a type "numbers between 1 and 4." Then, when you try to cast
a 5 to that type, it would fail. Types are just sets of possible instance
values; that most languages limit them to reasoning only about the outermost
features of the type (e.g. capacity of 1 vs N, mutability, signedness or
realness) makes them orders of magnitude less useful than they could be.

~~~
omouse
_Pretend there was a type "numbers between 1 and 4."_

Pascal and Ada have this I think. I think Eiffel has contracts to enforce that
type of thing instead.

------
danbmil99
the implicit assumption in all of these arguments is that it's more important
to ship bug-free (or as close as you can get to bug-free) code than to ship
quickly. In the real world, that is almost never the case. In fact, I can't
think of a single situation in which it is ever the case.

~~~
clawrencewenham
No that isn't the assumption. And when the article does discuss project
deadlines it most certainly--and with cited references--talk about the trade-
offs present in the real world.

The article was written to discuss ways of reducing bugs independent of any
other need.

Furthermore, although you "can't think of a single situation in which it is
ever the case", I myself actually picked one where a $4 billion machine with
six lives at stake was an excellent example of when it DOES matter what the
quality of the software is.

~~~
danbmil99
ok then, in 99.999% of all applications I would claim that shooting for
virtually bug-free code is a sure-fire prescription for business failure.

BTW why did Nasa downgrade their redundancy to 2 systems in the Shuttle? I
recall reading that during the lunar missions, they had 5 computers on board,
all independent implementations of the same spec.

~~~
clawrencewenham
I understand your hyperbole, but the stress isn't necessary. The market will
reveal where it wants quality and where it doesn't.

Also, the Shuttle has always had 2 independently written systems, never five.
There are five _computers_ running software written to the same spec, but the
physical redundancy wasn't the scope of the article.

------
rgiar
the redundancy idea scales as much as you want it to; this post remixed:
[http://socialfact.com/reader/seemore-how-much-are-you-
willin...](http://socialfact.com/reader/seemore-how-much-are-you-willing-to-
pay-for-software-perfection-1)

