On 2015-05-08 00:28, Walter Bright wrote:

> D has some excellent tools that are generally nonstandard, klunky or
> nonexistent in other languages:
>
> 1. unit testing
> 2. documentation generation
> 3. coverage analysis
> 4. profiler
> 5. and as of last week, a memory usage profiler
>
> I know many feel that these features can be improved, sure. But the
> first three have knocked the ball out of the park, and number four is a
> solid hit. And frankly, if I had to choose between 1..5 and package
> manager, static analysis tool, linter, and formatter, I'd choose the
> former.

I guess we just have different preferences. I would only choose unit testing and documentation generation from your list, if I have to choose. Perhaps I would even choose package manager as the most important tool, because the other tools could be provided by packages in the package manager.

Regards to unit testing, if I compare that with Ruby, for example. Ruby doesn't have language support for unit tests but there are two major unit test libraries in use, one which is included in the standard library.

The built-in unit testing in D is so limiting that a third party framework is needed anyway, and here there's no obvious library to pick.

-- 
/Jacob Carlborg

On Thursday, 7 May 2015 at 22:27:57 UTC, Walter Bright wrote:
> On 5/7/2015 5:16 AM, d user wrote:
>> the truth is, one of the biggest things holding D back from mass adoption is the
>> complete lack of tooling compared to  basically every other mainstream language.
>
> D has some excellent tools that are generally nonstandard, klunky or nonexistent in other languages:
>
> 1. unit testing
> 2. documentation generation
> 3. coverage analysis
> 4. profiler
> 5. and as of last week, a memory usage profiler
>

some of these really are klunky though.
e.g, if D's built-in unit testing is so good, why are there eight packages for unit testing on dub?

On 5/7/2015 11:30 PM, Jacob Carlborg wrote:
> On 2015-05-08 00:28, Walter Bright wrote:
>
>> D has some excellent tools that are generally nonstandard, klunky or
>> nonexistent in other languages:
>>
>> 1. unit testing
>> 2. documentation generation
>> 3. coverage analysis
>> 4. profiler
>> 5. and as of last week, a memory usage profiler
>>
>> I know many feel that these features can be improved, sure. But the
>> first three have knocked the ball out of the park, and number four is a
>> solid hit. And frankly, if I had to choose between 1..5 and package
>> manager, static analysis tool, linter, and formatter, I'd choose the
>> former.
>
> I guess we just have different preferences. I would only choose unit testing and
> documentation generation from your list, if I have to choose. Perhaps I would
> even choose package manager as the most important tool, because the other tools
> could be provided by packages in the package manager.

The coverage analysis is necessary to make the unit testing effective. Otherwise, one is just shooting in the dark. My experience developing Warp was typical - I went back and forth between unit tests and coverage analysis from the ground up. The result was Warp was developed unusually quickly and had very, very few bugs show up after release.


You don't have to add another package, run other tools, etc., like in other languages. Just throw a switch. This convenience should not be underestimated.

One big reason I want dmd to be in D is to get the unit testing.


> Regards to unit testing, if I compare that with Ruby, for example. Ruby doesn't
> have language support for unit tests but there are two major unit test libraries
> in use, one which is included in the standard library.
>
> The built-in unit testing in D is so limiting that a third party framework is
> needed anyway, and here there's no obvious library to pick.

On the other hand, D's builtin unit testing is so effective it has been a game changer, in that it has successfully changed the culture of D programming.

On Thursday, 7 May 2015 at 22:27:57 UTC, Walter Bright wrote:
> But let's not forget the meat and potatoes on our plate while looking at our neighbor's salad dressing.

Yes, but I think people actually mean an IDE when they say that tooling is the main issue. Then again, many C/C++ people swear by emacs/gdb so tooling is not the primary issue!

And people don't pick a language because of a testing framework…

Language, compiler, runtime…

On 2015-05-08 09:55, Walter Bright wrote:

> On the other hand, D's builtin unit testing is so effective it has been
> a game changer, in that it has successfully changed the culture of D
> programming.

Perhaps compared to C++ or previous D code. But compared to Ruby it's certainly not a game changer and has a long way to go.

-- 
/Jacob Carlborg

On 5/8/2015 1:16 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> And people don't pick a language because of a testing framework…

Which is why I need to point out just how productivity boosting -unittest and -cov are.

On 5/8/2015 12:45 AM, weaselcat wrote:
> some of these really are klunky though.

Nobody's ever satisfied. Doesn't mean the tools aren't effective, and doesn't mean a "complete lack of tooling".

I find:

   dmd std/algorithm -main -unittest -cov

quite far removed from 'klunky'. How do you do it in [pick a language]?


> e.g, if D's built-in unit testing is so good, why are there eight packages for
> unit testing on dub?

I haven't used them, and so have no opinion on them. I use the builtin capability every day I am working on D code, and find it easy and indispensable.

On Friday, 8 May 2015 at 08:51:24 UTC, Walter Bright wrote:
> On 5/8/2015 12:45 AM, weaselcat wrote:
>> some of these really are klunky though.
>
> Nobody's ever satisfied. Doesn't mean the tools aren't effective, and doesn't mean a "complete lack of tooling".
>
> I find:
>
>    dmd std/algorithm -main -unittest -cov
>
> quite far removed from 'klunky'. How do you do it in [pick a language]?
>
>
>> e.g, if D's built-in unit testing is so good, why are there eight packages for
>> unit testing on dub?
>
> I haven't used them, and so have no opinion on them. I use the builtin capability every day I am working on D code, and find it easy and indispensable.

Well, I have to say that I love what D has done with unit tests and code coverage. It's not perfect, but the fact that it's built-in makes it extremely easy to use and embarrassing if you don't. And on the whole, I really don't see the need for some of the kinds of features that others complain about D missing. That's not to say that there's not value in some of those features, but I think that the language itself has a very good foundation for unit testing with covers the 90% case, and if others want to create their own unit testing frameworks to handle more complex cases, they're certainly free to do so.

For larger projects, I'd probably want to be able to have names for the unittest blocks and have the be printed as the tests run, but that's easy enough to add (albeit possibly a bit tedious). So, I really haven't found D's built-in unit test framework to be particularly lacking, and based on discussions on it in the past, I think that it's quite clear that there would be a lot of disagreement on how it should be changed if we were looking to add to the language itself some of the features that those 3rd party unit test frameworks have.

Certainly, being able to just put unit tests in my modules rather than having to find and link against a 3rd party unit test framework is a definite improvement over other languages that I've used. And even if someone prefers one of the unit test frameworks on code.dlang.org, it's not like that's any worse than other languages where you _have_ to use a 3rd party unit test framework. So, while I can understand someone wanting the built-in unit test framework to do more and being frustrated with that is understandable, I think that a bit of perspective is in order. After all, what other language has unit tests built in at all?

- Jonathan M Davis

On 5/8/2015 1:33 AM, Jacob Carlborg wrote:
> On 2015-05-08 09:55, Walter Bright wrote:
>
>> On the other hand, D's builtin unit testing is so effective it has been
>> a game changer, in that it has successfully changed the culture of D
>> programming.
>
> Perhaps compared to C++ or previous D code. But compared to Ruby it's certainly
> not a game changer and has a long way to go.

I've never seen any as easy to use as D's, and that includes Ruby. Easy to use is what makes it a game changer, because people are much more likely to use it.

I know from long experience that when a test framework comes with a manual, people tend to not use it. It's just the way people are. If it's not builtin, people also tend not to use it.

I'm not claiming D has invented unit testing, nor that it is sophisticated. But it is trivial to use, and getting people to actually use it is what matters. It's like exercise - just getting out and doing something, anything, regularly is 90% of it.

It doesn't matter how sophisticated a testing and coverage tool is if people aren't using it as a matter of course. I've seen enough tool manuals sitting on programmers' shelves for years still in their shrink wrap.

For example, a well-known Ruby project, Rails. Picking a file pretty much at random:

https://github.com/rails/rails/blob/master/actionmailer/lib/action_mailer/base.rb

No unit tests in it. Poking around, I found this:

https://github.com/rails/rails/blob/master/actionmailer/test/base_test.rb

in another directory. I presume those are the tests for base.rb. Why can't the tests be in base.rb? I assume there is some 3rd file that connects the two. I really like having the unit tests adjacent to the function under test, for the same reason that the Ddoc is adjacent. It sounds trite, but having them all together and not in some other file hierarchy is a game changer. It certainly changed things in D (before Ddoc, Phobos documentation was an utter disaster).

DMD has a set of source files in one directory, and test files in another. There's no obvious correspondence between code and its corresponding test. We don't actually know how good the test coverage is. I'm very much looking forward to ddmd in order to address this. I expect this will result in a large increase in quality.

On 5/8/2015 2:52 AM, Jonathan M Davis wrote:
> the fact that it's built-in makes it extremely easy to use and embarrassing if you don't.

That's the game changing part, and what's missing from other languages.


> After all, what other language has unit tests built in at all?

Yup. I haven't done anything remotely resembling an exhaustive search, but Go and Ruby have testing as add-on packages. JUnit is an add-on the user must download and install. There's not a word in the C and C++ specs about unit testing. And so on.

Unit testing, coverage analysis, documentation generation, and profiling are very deliberately built in to the core compiler and language. They are always there, always available, and always the right version.

One can dismiss that as trivia, that any professional won't be stopped by having to find the right download, install, and integration procedure. But the reality is that having this all built-in has seismically changed how D code is written.