The Applied Theory of writing bug-free code • Hacker News Board

Re: The Applied Theory of writing bug-free code

#21

Post by clawrencewenham » Sun, Oct 11, 2009, 1:17 AM UTC

danbmil99 wrote: post #20

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.

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.

Re: The Applied Theory of writing bug-free code

#22

Post by silentOpen » Sun, Oct 11, 2009, 2:16 AM UTC

scotty79 wrote: post #19

swombat wrote: post #11

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 t…

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 o…

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.

Re: The Applied Theory of writing bug-free code

#23

Post by kscaldef » Sun, Oct 11, 2009, 3:43 AM UTC

danbmil99 wrote: post #20

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.

Wow, are we really that dominated by the startup culture here? You can't think of a single situation where correctness is more important than speed?

I've spent most of my career working on systems handling money, at jobs where we actually bought and sold things. When there are bugs in the code, we lose real, quantifiable money. Sometimes being first-to-market with a product or feature is more valuable than the cost of bugs. Sometime a buggy feature makes more money than it loses. But, it's not a given, and it's naive to say that speed is more important than correctness in all (or even most) situations.

Re: The Applied Theory of writing bug-free code

#24

Post by danbmil99 » Sun, Oct 11, 2009, 5:22 AM UTC

clawrencewenham wrote: post #21

danbmil99 wrote: post #20

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.

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 wit…

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.

Re: The Applied Theory of writing bug-free code

#25

Post by clawrencewenham » Sun, Oct 11, 2009, 5:35 AM UTC

danbmil99 wrote: post #24

clawrencewenham wrote: post #21

Earlier quoted context omitted.

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 wit…

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.

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.

Re: The Applied Theory of writing bug-free code

#26

Post by tetha » Sun, Oct 11, 2009, 11:16 PM UTC

silentOpen wrote: post #22

scotty79 wrote: post #19

Earlier quoted context omitted.

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 o…

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.

You are right, even though you have to give him the point that a lot of the existing static type systems around by now are bad. Haskell is approachig a really nice, hassle-free type-system, but take, e.g., Javas typesystem? Bleh.

Re: The Applied Theory of writing bug-free code

#27

Post by tetha » Sun, Oct 11, 2009, 11:20 PM UTC

berntb wrote: post #16

diN0bot wrote: post #2

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

>>a few times i will have a bug because i mispell a variable name Huh, that spelling problem would give me errors every page. Python have no warnings for uniquely created/used variables? There is no possibility to demand some declaration of existing variables? It is quite easy to parse Python(?), so the IDEs should catch this, at least?

Python requires you to initialize a variable before reading it, so:

  foo = object
  ofo.__call__()

will cause a (runtime) error. Thus, if you use your declared variables, errors will occur on mistypes (unless, of course, you have the typo declared, which would be a smell in itself (think of variable names being too close))

Re: The Applied Theory of writing bug-free code

#28

Post by scotty79 » Sun, Oct 11, 2009, 11:23 PM UTC

silentOpen wrote: post #22

scotty79 wrote: post #19

Earlier quoted context omitted.

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 o…

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.

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.

Re: The Applied Theory of writing bug-free code

#29

Post by berntb » Sun, Oct 11, 2009, 11:41 PM UTC

tetha wrote: post #27

berntb wrote: post #16

Earlier quoted context omitted.

>>a few times i will have a bug because i mispell a variable name Huh, that spelling problem would give me errors every page. Python have no warnings for uniquely created/used variables? There is no possibility to demand some declaration of existing variables? It is quite easy to parse Python(?), so the IDEs should catch this, at least?

Python requires you to initialize a variable before reading it, so: foo = object ofo.__call__() will cause a (runtime) error. Thus, if you use your declared variables, errors will occur on mistypes (unless, of course, you have the typo declared, which would be a smell in itself (think of variable names being too close))

OK, what if it is a flag variable that is either undefined or an integer? That is, do you need to initialize all variables?

Also, how about this?

  foo = 10
  ...
  if ...
    ofo = 20
  ...
  formula = bah * ( ... foo ... )

Edit: Please tell me the second case isn't as catastrophic as it looks? That would give at least me no ends of problems -- I thought modern languages left that kind of sh-t in the 1990s? Better have a good culture for testing!

Re: The Applied Theory of writing bug-free code

#30

Post by tetha » Mon, Oct 12, 2009, 8:25 AM UTC

berntb wrote: post #29

tetha wrote: post #27

Earlier quoted context omitted.

Python requires you to initialize a variable before reading it, so: foo = object ofo.__call__() will cause a (runtime) error. Thus, if you use your declared variables, errors will occur on mistypes (unless, of course, you have the typo declared, which would be a smell in itself (think of variable names being too close))

OK, what if it is a flag variable that is either undefined or an integer? That is, do you need to initialize all variables? Also, how about this? foo = 10 ... if ... ofo = 20 ... formula = bah * ( ... foo ... ) Edit: Please tell me the second case isn't as catastrophic as it looks? That would give at least me no ends of problems -- I thought modern languages left that kind of sh-t in the 1990s? Better have a good cul…

1) If you want to read the variable in some way, you need to initalize it. If you want to do weird things involving setting random attributes on an object and check if they exist.. well, you're on your own. Generally, I'd recommend for the flag variable to have a definite uninitialized value (say, None), as this is far easier to check.

2) The opinion of a lot of people on python is that the lack of such (impossible[1]) compiletime tests requires you to replace them with good unit-tests (which should be written anyway). So yes, it is as bad as it looks, but it is recommended to test such things :) Also, there are tools like pychecker and pyflakes, which do sanity-checks which would capture these errors (even though they might be an insane valid python program[1]).

[1] This is impossible, as it is possible to set variables in earlier stack-frames inside a nested call, or I might fiddle around in the locals of an earlier call to get data I want. Certainly, no one would do this (and whoever does such a thing should be stabbed multiple times if this hack persists longer than an hour (hey, I have built such a thing myself to debug a deadlock about resources, it printed the direct caller of the allocation- and deallocation-method, so I could quickly check for unmatched alloc-calls :) )), but it is possible, and thus, the compiler has to assume such things happen.