Live data from Hacker News

The Applied Theory of writing bug-free code

sites.google.com

11–20 of 32 posts

Re: The Applied Theory of writing bug-free code

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

Re: The Applied Theory of writing bug-free code

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

Re: The Applied Theory of writing bug-free code

#13
post #7
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.…

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.

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.

Re: The Applied Theory of writing bug-free code

#14
post #12

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

Ouch.

Re: The Applied Theory of writing bug-free code

#16
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?

Re: The Applied Theory of writing bug-free code

#17
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…

You're right, I meant static and not strong typing.

Re: The Applied Theory of writing bug-free code

#18
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 doesn't necessarily mean type declarations, either. See OCaml. What it does mean is that the compiler knows the type of all variables at compile time, but it's OK if it figures that out for itself.

Re: The Applied Theory of writing bug-free code

#19
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 of compiler guys to make their work easier for them. It was claimed to have benefits for programmers at later date.

Re: The Applied Theory of writing bug-free code

#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.
Post reply on HN