On 2/9/2018 6:49 AM, Jonathan M Davis wrote:
> The amazing thing is when a programmer tries to argue that having unit tests
> makes your code worse - not that they take too long to write or that they
> don't want to bother with them or any that - that they somehow make the code
> worse.

It's not amazing at all :-)

The reasons people give to not try something new are hardly ever the actual reasons. People will make up on the spot reasons that they think you want to hear or that sound good. Their actual reasons they keep to themselves because they don't sound good.

If you talk with someone enough you'll eventually figure out their actual reasons.

On Friday, February 09, 2018 13:39:22 Walter Bright via Digitalmars-d wrote:
> On 2/9/2018 6:01 AM, Atila Neves wrote:
> > Unit tests are a great idea, right? Try convincing a group of 10 programmers who have never written one and don't know anyone else who has. I have; I failed.
> Unit tests are one of the great success stories of D. I believe it was a success because it was so simple to add unit tests to the code, and to run those tests.
>
> D's unit testing system didn't even need to be very good. It just had to be *easy*. And that changed everything.

Yeah. git did the same thing for me for source control. Before, I almost never did anything with source control with my personal projects, because it was too much of a pain to set up; you basically had to set up a server to talk to (even if it was on the same machine), whereas with git, it's just

git init .

and you have a repository. Now, all my source code goes in a git repo unless it's just a quick test that I'm going to throw away when I'm done. And the fact that places like github and bitbucket make it so easy to create repos online means that a lot of my stuff is online too, whereas if I had to use something like SVN, I'd probably have next to nothing in source control.

And the way that D handles unit tests has had the same effect. If I were doing all of my personal projects n C++, I don't know how many would be unit tested. Anything really serious would be, but the extra effort of setting something up to be able to have unit tests is enough that anything simple would probably never have any tests, because it would be too much effort for me to bother. Having unit tests built-in is definitely a game changer.

- Jonathan M Davis

On Fri, Feb 09, 2018 at 01:39:22PM -0800, Walter Bright via Digitalmars-d wrote:
> On 2/9/2018 6:01 AM, Atila Neves wrote:
> > Unit tests are a great idea, right? Try convincing a group of 10 programmers who have never written one and don't know anyone else who has. I have; I failed.
> 
> Unit tests are one of the great success stories of D. I believe it was a success because it was so simple to add unit tests to the code, and to run those tests.

Yeah, it is so simple you feel ashamed for not writing them.  Which in turn generates a positive feedback loop where your unittests uncovers bugs early (rather than 2 months later when your customer's box blows up), so you feel motivated to write more tests, and your code quality continues improving.


> D's unit testing system didn't even need to be very good. It just had to be *easy*. And that changed everything.

Speaking of unittests... currently we have a problem:

	import std.regex;
	void main() {}

Compiling with -unittest:

	real	0m1.137s
	user	0m0.994s
	sys	0m0.141s

Compiling without -unittest:

	real	0m0.528s
	user	0m0.458s
	sys	0m0.069s

The problem: compiling with -unittest causes Phobos unittests to be instantiated, even if the user isn't compiling Phobos directly.

Proposal: unittests should only be compiled if the module it's found in is being compiled (i.e., among the modules listed on the command-line), even with -unittest.

This won't break anything, because as long as user projects compile all of their modules explicitly, -unittest will still work as before. I'd guess practically all user projects will do this. (There may be a few exceptions, e.g., if a module contains only templates, but IIRC even then you still have to list the module on the command-line, otherwise some templates won't instantiate correctly.)

It will improve compilation times and reduce executable bloat -- unittests from external libraries that are only linked, not compiled, won't be included.  It also makes more sense -- if I'm using a 3rd party library, why should I care to run *their* unittests?  I'm only interested in testing my own code.

What do you think?


T

-- 
People demand freedom of speech to make up for the freedom of thought which they avoid. -- Soren Aabye Kierkegaard (1813-1855)

On Friday, 9 February 2018 at 22:38:23 UTC, H. S. Teoh wrote:
>
> Proposal: unittests should only be compiled if the module it's found in is being compiled (i.e., among the modules listed on the command-line), even with -unittest.
>
> if I'm using a 3rd party library, why should I care to run *their* unittests?  I'm only interested in testing my own code.
>
> What do you think?
>

Currently being discussed in another thread, but that's an emphatic "YES, definitely". I proposed that awhile back and there was a bunch of hemming and hawing and ultimately nothing, but I really hope something will come of it this time.

On 2/9/2018 1:48 PM, Jonathan M Davis wrote:
> If I were
> doing all of my personal projects n C++, I don't know how many would be unit
> tested.

I know how many. Zero.

On Friday, February 09, 2018 19:50:48 Walter Bright via Digitalmars-d wrote:
> On 2/9/2018 1:48 PM, Jonathan M Davis wrote:
> > If I were
> > doing all of my personal projects n C++, I don't know how many would be
> > unit tested.
>
> I know how many. Zero.

If I were writing something like std.datetime in C++, I'd go to the trouble of writing unit tests, and I've written unit testing frameworks for C++ before for work. So, I don't think that it would necessarily be zero, but it's certainly true that I'd be a lot less willing to go to the effort, and I almost certainly wouldn't bother for smaller projects.

- Jonathan M Davis

On Tuesday, 30 January 2018 at 20:45:44 UTC, Andrei Alexandrescu wrote:
> https://www.quora.com/Why-hasnt-D-started-to-replace-C++
>
> Andrei

Why indeed!

Feature D C C++ C# Java (and this was bacvk in
=====================================
Garbage Collection Yes No No Yes Yes

Functions
=========
Function delegates		Yes No No Yes No
Function overloading		Yes No Yes Yes Yes
Out function parameters		Yes Yes Yes Yes No
Nested functions		Yes No No No No
Function literals		Yes No No No No
Dynamic closures		Yes No No No No
Covariant return types		Yes No Yes No No

Arrays
======
Lightweight arrays		Yes Yes Yes No No
Resizeable arrays		Yes No No No No
Arrays of bits		Yes No No No No
Built-in strings		Yes No No Yes Yes
Array slicing		Yes No No No No
Array bounds checking		Yes No No Yes Yes
Associative arrays		Yes No No No No
Strong typedefs		Yes No No No No
Aliases		Yes Yes Yes No No

OOP
===
Object Oriented		Yes No Yes Yes Yes
Multiple Inheritance		No No Yes No No
Interfaces		Yes No Yes Yes Yes
Operator overloading		Yes No Yes Yes No
Modules		Yes No Yes Yes Yes
Dynamic class loading		No No No No Yes
Inner classes		No No No No Yes
Covariant return types		Yes No Yes No No

Performance
===========
Inline assembler		Yes Yes Yes No No
Direct access to hardware		Yes Yes Yes No No
Lightweight objects		Yes Yes Yes Yes No
Explicit memory allocation control		Yes Yes Yes No No
Independent of VM		Yes Yes Yes No No
Direct native code gen		Yes Yes Yes No No
Templates		Yes No Yes No No

Reliability
===========
Design by Contract		Yes No No No No
Unit testing		Yes No No No No
Static construction order		Yes No No Yes Yes
Guaranteed initialization		Yes No No Yes Yes
RAII		Yes No Yes Yes No
Exception handling		Yes No Yes Yes Yes
try-catch-finally blocks		Yes No No Yes Yes
Thread synchronization primitives	Yes No No Yes Yes

Compatibility
=============
Algol-style syntax		Yes Yes Yes Yes Yes
Enumerated types		Yes Yes Yes Yes No
Support all C types		Yes Yes No No No
Long double floating point	Yes Yes Yes No No
Complex and Imaginary		Yes Yes No No No
Direct access to C		Yes Yes Yes No No
Use existing debuggers		Yes Yes Yes No No
Struct member alignment control	Yes Yes Yes No No
Generates standard object files	Yes Yes Yes No No
Macro preprocessor		No Yes Yes No No

Other
=====
Conditional compilation		Yes Yes Yes Yes No

On Sunday, 11 February 2018 at 00:03:16 UTC, psychoticRabbit wrote:
> On Tuesday, 30 January 2018 at 20:45:44 UTC, Andrei Alexandrescu wrote:
>> https://www.quora.com/Why-hasnt-D-started-to-replace-C++
>>
>> Andrei
>
> Why indeed!
>
> Feature D C C++ C# Java (and this was bacvk in
> =====================================

(correction to above line)
Feature D C C++ C# Java (and this was back in 2003)

..2003 ..gee.. that was what..15 years ago.

On Sunday, 11 February 2018 at 00:06:07 UTC, psychoticRabbit wrote:
> On Sunday, 11 February 2018 at 00:03:16 UTC, psychoticRabbit wrote:
>> On Tuesday, 30 January 2018 at 20:45:44 UTC, Andrei Alexandrescu wrote:
>>> https://www.quora.com/Why-hasnt-D-started-to-replace-C++
>>>
>>> Andrei
>>
>> Why indeed!
>>
>> Feature D C C++ C# Java (and this was bacvk in
>> =====================================
>
> (correction to above line)
> Feature D C C++ C# Java (and this was back in 2003)
>
> ..2003 ..gee.. that was what..15 years ago.

Well, it isn't correct in 2018...

On Sunday, 11 February 2018 at 00:15:32 UTC, Ola Fosheim Grostad wrote:
> On Sunday, 11 February 2018 at 00:06:07 UTC, psychoticRabbit wrote:
>> On Sunday, 11 February 2018 at 00:03:16 UTC, psychoticRabbit wrote:
>>> On Tuesday, 30 January 2018 at 20:45:44 UTC, Andrei Alexandrescu wrote:
>>>> https://www.quora.com/Why-hasnt-D-started-to-replace-C++
>>>>
>>>> Andrei
>>>
>>> Why indeed!
>>>
>>> Feature D C C++ C# Java (and this was bacvk in
>>> =====================================
>>
>> (correction to above line)
>> Feature D C C++ C# Java (and this was back in 2003)
>>
>> ..2003 ..gee.. that was what..15 years ago.
>
> Well, it isn't correct in 2018...

Hence the reason why D hasn't started to replace C++.

i.e C++ continues to evolve..

(except that D got many things right, in the first instance - and so D can focus on more important matters ;-)