The Applied Theory of writing bug-free code
sites.google.com
The Applied Theory of writing bug-free code
1–10 of 32 posts
Re: The Applied Theory of writing bug-free code
#2i 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.
Re: The Applied Theory of writing bug-free code
#3What 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.
Re: The Applied Theory of writing bug-free code
#4What 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…
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.
Re: The Applied Theory of writing bug-free code
#5What 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…
He begins with an argument for redundancy in such a general sense that it's almost a truism. One way or another, since you don't know for certain that your code works, you should add code (ie checks) to make sure that it does.
BUT, that general argument, in and of itself, doesn't say testing or strong-typing or asserts whatever is the answer. It seems to me that what is needed is checks that are highly tuned to the situation at hand. Just as simple unit tests are limited, Strong typing is limited to catching a small portion of bugs. I want a language in which I can add only verifications that I need, when I need them and skip the rest. I've never tried it myself but the automatic typing of some functional languages seems like the appropriate next step (and I'm currently programming in a strongly-typed language that is generally a pain in that way).
Re: The Applied Theory of writing bug-free code
#6i 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.…
the type thing is important to the kinds of people who get a woody thinking about the maths that deal not in numbers.
Re: The Applied Theory of writing bug-free code
#7i 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.
Re: The Applied Theory of writing bug-free code
#8What 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…
In my view, contracts can do the "redundancy" thing much better than typing can. It's explicit, it's optional, it's a better guarantee that you're getting what you want, it's more flexible, etc. Contracts and TDD are my favorites right now, i guess.
TDD is particularly great, though, as it's an in-code description of what the program should do. If it doesn't pass the tests it doesn't do what you thought it should do--ie, there are bugs.
(Of course, then we have to figure out how to write the tests... but hey...)
Re: The Applied Theory of writing bug-free code
#9What 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…
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 cod…
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.
Re: The Applied Theory of writing bug-free code
#10i 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.…
I've written a lot of Java, C++, and C#. I currently write a lot of MSBuild (not by choice) and Python. Static vs dynamic typing is neither a mutually exclusive choice, nor a choice which can occur in a vacuum. Use the right tool for the job, or else one of these things will happen:
Java/Swing: You will be woefully unequipped for the natural cascading property nature of GUI applications; forcing you to jump through giant hoops to get anything to not look awful.
C++/COM: You'll cast IUnknown to ISomethingElse so many times that it will lose meaning.
MSBuild: You will make a typo in a parameter name, but won't find out until two hours into your build when you get an error that could have been caught by a compiler.
--
Static typing works for problems that demand rigor, but may be hard to unit test. That includes most larger projects worked on by companies of overworked and slightly disinterested developers.
Dynamic typing works when you can iterate as fast as you can refresh the browser, or when your application is small enough that it is reasonable to full text search the entire thing anytime you refactor anything.
You can build dynamic type systems on top of static ones, but it is ugly. Don't be WPF's DependencyObject system cringe. It is safe, however, to layer dynamic code above static code. Feel free to use a dynamic language for scripting a statically build application.
You can build static type systems on top of dynamic ones, but they will leak. It is also awkward to layer static code above dynamic code. Odds are your code will be dynamic, but more verbose because of the type system getting in your way.