On 2014-04-13 08:55:53 +0000, "Paolo Invernizzi" <paolo.invernizzi@no.address> said:

> I don't remember if this has been already posted here in the forum, but I think that this rant of Theo de Raadt about heartbleed is _very_ interesting.
> 
> http://article.gmane.org/gmane.os.openbsd.misc/211963
> 
> TBW, I agree with him: it's not a matter of scrutiny or a matter of being human, and the post clarify this very well.

Interesting. As far as I know, the D GC is also a wrapper around malloc, and it will not return memory using free when an object is deallocated. That rant could also apply to D.

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca

On Sunday, 13 April 2014 at 08:55:47 UTC, Paulo Pinto wrote:
> 20 years ago I would have answered both are bad and Object Pascal/Delphi is the way.
>
> Sadly Borland did lots of major screw ups and let the language momentum fade away.

Ironically, I have been using Pascal/Delphi at my first programming job. Switching later to C was a big relief - yes, it was less safe and sometimes awkward. But it did feel like a language designed by engineers, not academicians and that alone has boosted productivity a lot.

On Sun, Apr 13, 2014 at 12:38 AM, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:

> C++ is better in theory, but not all that much better than C in practice. The design flaws of the language often makes it worse than C in terms of maintainability. At my day job, we switched a major project from C++ back to C, because the C++ codebase was over-engineered and full of abstractions that nobody understood, patched over multiple times by people who were reassigned to take the place of the original people who left, who didn't understand the original design but had unreasonable deadlines to meet, so as a result they just added hacks and workarounds to get their job done before they got fired. By the time a few years had passed, *nobody* understood what the system even does, and every new code change was a "blindly copy-n-paste from other parts of the code and pray it won't break something else" deal. It was bloated, slow, and riddled with bugs nobody dared to fix, because nobody understood what it does. Certain features were dependent on dtor side-effects, and other such pathological things, and it was maintenance hell.
>

I don't understand what is the C++ fault when the management of the project
forces people to
write shit. The same situation would have happen with any language and a
full rewrite by a fixed team
would have been better whatever the new language.
I've heard the same story with Java, C# and Python in the last few years.
Always management fault.

I'm not sure I understand the arguments against C++ in your examples, in particular if you use D which have destructors and "magic" too.

On 4/13/2014 5:57 AM, Dicebot wrote:
> Ironically, I have been using Pascal/Delphi at my first programming job.
> Switching later to C was a big relief - yes, it was less safe and sometimes
> awkward. But it did feel like a language designed by engineers, not academicians
> and that alone has boosted productivity a lot.

I had the same feeling switching from Pascal to C. I was far more productive in C right off the bat. I never looked back, never wrote another line of Pascal.

On Sunday, 13 April 2014 at 15:17:30 UTC, Klaim - Joël Lamotte wrote:
> I don't understand what is the C++ fault when the management of the project
> forces people to
> write shit. The same situation would have happen with any language and a
> full rewrite by a fixed team
> would have been better whatever the new language.
> I've heard the same story with Java, C# and Python in the last few years.
> Always management fault.
>
> I'm not sure I understand the arguments against C++ in your examples, in
> particular if you use D which have destructors and "magic" too.

C++ fault is that it makes very easy even for experienced programmer to write faulty code and consequences of a mistake can be rather dire. C has similar issues but C is much smaller and simpler language which allows to keep all possible danger points in mind. I have yet to meet a single C++ programmer who can remember about all corner cases at the same time. I am not sure even Bjorne himself can.

D makes situation much better by refining base semantics to adhere "safe by default, fast when explicitly asked" principle (array bounds checks, default initialization of locals). It is still not 100% consistent but greatly reduces stress of the context comparing to C++.

I'd still prefer C++ over C for most projects but only if using very small well-defined  subset of C++ verified by static analysis tool continuously.

On 4/13/2014 4:04 AM, Michel Fortin wrote:
> Interesting. As far as I know, the D GC is also a wrapper around malloc, and it
> will not return memory using free when an object is deallocated. That rant could
> also apply to D.

You're right in that a malloc debugger would be ineffective when the D GC is used. But the D GC offers its own memory debugging features. They can be turned on with version identifiers in the GC source.

On 4/13/2014 9:26 AM, Dicebot wrote:
> C++ fault is that it makes very easy even for experienced programmer to write
> faulty code and consequences of a mistake can be rather dire. C has similar
> issues but C is much smaller and simpler language which allows to keep all
> possible danger points in mind. I have yet to meet a single C++ programmer who
> can remember about all corner cases at the same time. I am not sure even Bjorne
> himself can.
>
> D makes situation much better by refining base semantics to adhere "safe by
> default, fast when explicitly asked" principle (array bounds checks, default
> initialization of locals). It is still not 100% consistent but greatly reduces
> stress of the context comparing to C++.
>
> I'd still prefer C++ over C for most projects but only if using very small
> well-defined  subset of C++ verified by static analysis tool continuously.

Interestingly, I've been seeing that what makes D code much more robust is a consequence of 'unittest' coupled with -cov.

On Sunday, 13 April 2014 at 17:31:17 UTC, Walter Bright wrote:
> Interestingly, I've been seeing that what makes D code much more robust is a consequence of 'unittest' coupled with -cov.

Built-in unittests are the best thing since jet engines.

On Sunday, 13 April 2014 at 17:31:17 UTC, Walter Bright wrote:
> Interestingly, I've been seeing that what makes D code much more robust is a consequence of 'unittest' coupled with -cov.

It is big deal breaker for personal projects and open-source collaboration. For big private projects agreeing on single testing framework and adding one of coverage analyzers to the CI is not that much of a problem. Convenient, but not a deal breaker over C++.

But being less afraid to actually write code because of more powerful type system and safer defaults - this is huge.

I think most important thing about built-in unittests is how this feature encourages to add tests when contributing to projects that don't currently have any real coverage. It becomes so easy that there is not reason to not do it and this help open-source a lot.

Am 13.04.2014 14:57, schrieb Dicebot:
> On Sunday, 13 April 2014 at 08:55:47 UTC, Paulo Pinto wrote:
>> 20 years ago I would have answered both are bad and Object
>> Pascal/Delphi is the way.
>>
>> Sadly Borland did lots of major screw ups and let the language
>> momentum fade away.
>
> Ironically, I have been using Pascal/Delphi at my first programming job.
> Switching later to C was a big relief - yes, it was less safe and
> sometimes awkward. But it did feel like a language designed by
> engineers, not academicians and that alone has boosted productivity a lot.

Different experiences I guess. I never felt C made me productive in any way.