On Friday, 10 August 2012 at 08:38:18 UTC, Walter Bright wrote:
> Take a look at bearophile's list of Ada features advertised as making Ada code less buggy. Then look at, for example, dmd's bugzilla list.
>
> How many of those bugs would have been prevented by Ada's features?
>
> I'd say about 0.

It's a good point.

I'd say it's about the same in my line of work (making games with C++).

Here's what I perceive to be the most common causes of bugs in things I write:

1. Unconsidered use cases.
- e.g. User did X, but I had forgot to consider X when writing the code, or X was considered by poorly tested.

2. Poor knowledge of a system.
- e.g. Wrote the code expecting it to do something, but it didn't do all the things I expected, or my code had unintended side-affects in another part of the system.

3. Uninitialised variables.
- These are relatively rare, but consume a lot of time as they can be hard to reproduce and only appear in release builds.

4. NaN's.
- Quite common in any sort of physical simulation code, and difficult to track down.

5. Threading issues
- Quite rare, but difficult to track down.


I'd say #1 is by far the most common cause of bugs in any project (certainly DMD), and #2 gets more and more common as the number of developers on a project increases (as well as the number of lines of code). DMD is quite small, and you (who has full knowledge of DMD) checks every change list, so #2 is quite rare in DMD.

#3 is solved by D, and #5 as well.

#4 is hard to solve, especially when SIMD comes into the picture (as it often does in that sort of code).

#2 is interesting because you could arguably say that it is partially solved by things like functional programming, which makes some kinds of code simpler, meaning people are less likely to misunderstand how your system works. I have no doubt that it's true, but it's hard to argue that objectively. I don't believe there is any silver bullet for simple code.

On 8/11/2012 5:48 AM, Peter Alexander wrote:
> Here's what I perceive to be the most common causes of bugs in things I write:

It's a good list. I know that the kinds of bugs my own code has has changed over the years, clearly due to experience. I'm just not so plagued with low level mistakes like I used to be, because I've learned to avoid them. The problems I'm left with are:

1. incomplete understanding of the problem I'm trying to solve

2. changes in the design breaking the existing code's assumptions

I don't really know what to do about (1). But with (2), I'm thinking that a design that focuses better on encapsulation and compartmentalization should fare better, hence my interest in those features of D that facilitate this.

Walter Bright:

> The problems I'm left with are:
>
> 1. incomplete understanding of the problem I'm trying to solve
>
> 2. changes in the design breaking the existing code's assumptions
>
> I don't really know what to do about (1). But with (2), I'm thinking that a design that focuses better on encapsulation and compartmentalization should fare better, hence my interest in those features of D that facilitate this.

Haskell folks say that their strong types help clear up a bit the meaning of the parts of the problem ("if it compiles it's right" is one of their mottos); and they also say those strong types help avoid introducing some bugs caused by changes in the design, because they cause type errors. They generally suggest to move as many assumptions as possible into the types.

I have programmed in Haskell, but not enough yet to see those qualities a lot.

Bye,
bearophile

>> And how many of those bugs would have been prevented with D's const system?
>
> Probably several. David Held has been reviewing the source code, and has found interactions between subsystems of the compiler that shouldn't be there, and would have been detected if const was used properly.
>

A concrete example would really be nice here ...

On Sat, Aug 11, 2012 at 12:12 PM, Paulo Pinto <pjmlp@progtools.org> wrote:

>
> I have been watching the videos of this year's Assembly 2012 ( http://archive.assembly.org/**2012 <http://archive.assembly.org/2012>), surprisingly the majority of the games created in the game development competition track, have been done in C# with Unity or XNA.
>
>
>
I don't find it surprising at all. Remember that game developers have to be
extremely pragmatic to be able to get somewhere with their work, because
mixing so much technologies to build such complex experiences requires to
remove as much problems as possible from the final user in a way that is
surprisingly pragmatic.
And as I already said, not all games require really high performance.
A lot of new game developers will use tools that are available, free and
let them focus on making games, not tech (if the game isn't about tech).

It's about tools, not "languages". We choose tools that match the needs coming from the design of the game, not the language we prefer.


Joel Lamotte

On 8/12/2012 5:00 AM, Araq wrote:
> A concrete example would really be nice here ...

Inappropriate use of Outbuffer's internal data.

> Haskell folks say that their strong types help clear up a bit the meaning of the parts of the problem ("if it compiles it's right" is one of their mottos); and they also say those strong types help avoid introducing some bugs caused by changes in the design, because they cause type errors. They generally suggest to move as many assumptions as possible into the types.

A recent nice blog post, discussed on Reddit, shows some basic examples:

http://tomasp.net/blog/type-first-development.aspx

http://www.reddit.com/r/programming/comments/yad16/why_typefirst_development_matters/

In Haskell/Scala you sometimes see rather more refined examples.

Bye,
bearophile

Some integer overflow, use-after-free and out-of-bounds writes bugs in the Abobe PDF viewer:
http://gynvael.coldwind.pl/?id=483

To find them maybe they have used the ideas shown here:
http://taviso.decsystem.org/making_software_dumber.pdf

Bye,
bearophile