Hi everybody,

I was just reading this:

http://www.laputan.org/metamorphosis/metamorphosis.html#SoftwareTectonics

(a thing about software architectures).

The text opens with...:

"We like it when people always want more! Otherwise, we'd be out of the upgrade business. Sometimes, people ask me what I will do when the compiler is done. Done? No software program that is selling is ever done!
-- Walter Bright, C++ compiler architect"

So... the question is: does that quote also applies for dmd? :)

On Tuesday, 22 January 2013 at 13:54:08 UTC, eles wrote:

> The text opens with...:
>
> "We like it when people always want more! Otherwise, we'd be out of the upgrade business. Sometimes, people ask me what I will do when the compiler is done. Done? No software program that is selling is ever done!
> -- Walter Bright, C++ compiler architect"
>
> So... the question is: does that quote also applies for dmd? :)

 It's been quoted that for every 10 lines of code there's a bug. There are programs with tens of thousands of lines of code, so finding every bug is probably impossible for large programs (above 1000 lines). But that doesn't mean they can't run very very well. A number of the bugs for unchecked work is addition for example, perhaps simplest of operations; Are you going to check after every little + that you didn't have an overflow? Without a lot of extra work are you going to include checks that ensure they can't break?

C example:

  //code looks okay
  void* getMemory(int a, int b) {
    return malloc(a + b);
  }

  //becomes negative due to overflow. it can happen
  //probably returns NULL. I don't know..
  void* ptr = getMemory(0x7fffffff, 0x7fffffff);

  //overflow free version?
  void* getMemory(unsigned int a, unsigned int b) {
    //max name may be wrong, but you get the idea.
    //don't remember, need third cast?
    assert(((long long) a) + ((long long) b) <= UNSIGNED_INT_MAX);
    return malloc(a + b);
  }

  //should assert now
  void* ptr = getMemory(UNSIGNED_INT_MAX, UNSIGNED_INT_MAX);


 Since part of the process is not only fixing bugs and improving the compiler, but there's also new features that may be requested that you find necessary yet never needed before you thought about it.

 Consider: A recent project of mine that I hadn't updated in over a year and a half seemed to have a bug with how it handled a certain feature and was just brought up, needed to add about 10 lines of code to handle it; Then I found a bug within those 10 lines (after it was working).

 With that in mind, it's likely no program will be 'done', but if they do the job well enough then it's probably good enough. So to answer it, the answer is probably yes it applies to dmd.

On Tuesday, 22 January 2013 at 14:44:26 UTC, Era Scarecrow wrote:
> It's been quoted that for every 10 lines of code there's a bug. There are programs with tens of thousands of lines of code, so finding every bug is probably impossible for large programs (above 1000 lines).

I love how >1kloc is "large" :D

I'd say anything under 100kloc is a small program. 100kloc-1mloc medium, and >1mloc large.

Era Scarecrow:

> Are you going to check after every little + that you
> didn't have an overflow?

In debug mode that's the job of a modern well designed language, just like checking an index is inside the bounds of an array every time you perform an array access.

Bye,
bearophile

On Tuesday, 22 January 2013 at 14:59:48 UTC, Peter Alexander wrote:
> On Tuesday, 22 January 2013 at 14:44:26 UTC, Era Scarecrow wrote:
>> It's been quoted that for every 10 lines of code there's a bug. There are programs with tens of thousands of lines of code, so finding every bug is probably impossible for large programs (above 1000 lines).
>
> I love how >1kloc is "large" :D
>
> I'd say anything under 100kloc is a small program. 100kloc-1mloc medium, and >1mloc large.

It really depends if we are talking about java or not.

On Tuesday, 22 January 2013 at 14:59:48 UTC, Peter Alexander wrote:
> On Tuesday, 22 January 2013 at 14:44:26 UTC, Era Scarecrow wrote:
>
> I'd say anything under 100kloc is a small program. 100kloc-1mloc medium, and >1mloc large.

That means (at least) 100k bugs. Happy fixing!

On 2013-01-22, 15:59, Peter Alexander wrote:

> On Tuesday, 22 January 2013 at 14:44:26 UTC, Era Scarecrow wrote:
>> It's been quoted that for every 10 lines of code there's a bug. There are programs with tens of thousands of lines of code, so finding every bug is probably impossible for large programs (above 1000 lines).
>
> I love how >1kloc is "large" :D
>
> I'd say anything under 100kloc is a small program. 100kloc-1mloc medium, and >1mloc large.

It's context dependent, of course. Finding all the bugs in 1kloc is doable,
but lots of work. Finding all the bugs in 10kloc, conceivably doable, but
unlikely to be worth it. >= 100kloc? ouch.

-- 
Simen

On Tuesday, 22 January 2013 at 15:26:28 UTC, deadalnix wrote:
> On Tuesday, 22 January 2013 at 14:59:48 UTC, Peter Alexander wrote:
>> On Tuesday, 22 January 2013 at 14:44:26 UTC, Era Scarecrow wrote:
>>> It's been quoted that for every 10 lines of code there's a bug. There are programs with tens of thousands of lines of code, so finding every bug is probably impossible for large programs (above 1000 lines).
>>
>> I love how >1kloc is "large" :D
>>
>> I'd say anything under 100kloc is a small program. 100kloc-1mloc medium, and >1mloc large.
>
> It really depends if we are talking about java or not.

Not just Java. According to Wikipedia Debian 5 has over 300 million lines of code.

http://en.wikipedia.org/wiki/Source_lines_of_code

Last time I counted, Phobos has ~200kloc.

On Tuesday, 22 January 2013 at 15:11:41 UTC, bearophile wrote:
> Era Scarecrow:
>
>> Are you going to check after every little + that you didn't have an overflow?
>
> In debug mode that's the job of a modern well designed language, just like checking an index is inside the bounds of an array every time you perform an array access.

 Agreed. However D (compilers) doesn't have an option to check those, I think it was requested but walter said no (due to slower speed I think); Therefore if the compiler won't do it for you, you have to do it yourself. I really wouldn't want to have to use BigInt for everything that can't overflow and then check to make sure I can fit it in my smaller variables afterwards along with the extra move. I wouldn't want to use BigInts everywhere, and long's aren't needed everywhere either.

 Of course if an attribute was added that checked just those functions for important overflows then it could help, but in truth it kinda clutters the signatures with something that isn't an important attribute. Guess 'CheckedInt' could work in those cases, but that's more during runtime and release rather than debugging.

> Not just Java. According to Wikipedia Debian 5 has over 300 million lines of code.

It also consists of over 20000 packages. It is not one program.