On Friday, 8 May 2015 at 10:56:22 UTC, Walter Bright wrote:
> 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.

True. If it ain't easy to use, nobody will use it.

First I was a bit sceptical about the unittests, cos you have tests for the finished product anyway ... But unittests are

a) a documentation of the code and
b) simple and easy to use in D
c) make you think about your code more carefully.

c) is very important. Designing a unittest often makes me realize that there are shortcomings in my code, or make me think of further possibilities. Having coverage, unittests and performance tests built in makes you think more about your code in general. Take a program that starts out as a command line tool like "open file, parse, analyze". You start with something that just "works", you need it fast, you need it now. But it doesn't harm you to add a unittest (the same stuff you would more or less test for anyway with `writeln(output)`. Your little tool becomes more reliable and well-documented, and can later grow into something bigger. I know, you should treat a simple command line tool as something that might possibly grow anyway, but D makes it so much easier. And let's be honest, we're all human, we're all lazy. If we weren't lazy, we wouldn't bother with programming - after all what else is programming than having a machine do something for you.

On Friday, 8 May 2015 at 08:45:07 UTC, Walter Bright wrote:
> 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.

D unittests can be neat for simpler libraries, but they also make code harder to browse. Phobos source code clearly suffers from it.

So I'd rather have them separate and have testing-support built into the IDE instead. I find that cleaner as unit-tests are actually not part of the semantical language, just part of the D syntax...

You are probably right that people use them more when they are "shipped with the product", though. Whether you ship the compiler or a bundle (IDE).

On Friday, 8 May 2015 at 13:31:38 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 8 May 2015 at 08:45:07 UTC, Walter Bright wrote:
>> 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.
>
> D unittests can be neat for simpler libraries, but they also make code harder to browse. Phobos source code clearly suffers from it.
>
> So I'd rather have them separate and have testing-support built into the IDE instead. I find that cleaner as unit-tests are actually not part of the semantical language, just part of the D syntax...
>
> You are probably right that people use them more when they are "shipped with the product", though. Whether you ship the compiler or a bundle (IDE).

I like unittests in phobos and other libraries, because they immediately show me how to use the code, and I like how simple it is:

dub --build=unittest

or

dmd myfile.d -unittest

Be honest, have you written unittests for each your Python scripts, for each of your command line tools? D makes it easy for you.

The only drawback is that sometimes the logic of a program does not allow to test every little bit, especially when handling files is concerned. But overall D in general makes me more "code aware" in many respects, be it performance, code hygiene or re-usability. And it helps that the compiler ships with a lot of flags that help me to analyze my code.

On Friday, 8 May 2015 at 14:00:01 UTC, Chris wrote:
> On Friday, 8 May 2015 at 13:31:38 UTC, Ola Fosheim Grøstad wrote:
>> On Friday, 8 May 2015 at 08:45:07 UTC, Walter Bright wrote:
>>> 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.
>>
>> D unittests can be neat for simpler libraries, but they also make code harder to browse. Phobos source code clearly suffers from it.
>>
>> So I'd rather have them separate and have testing-support built into the IDE instead. I find that cleaner as unit-tests are actually not part of the semantical language, just part of the D syntax...
>>
>> You are probably right that people use them more when they are "shipped with the product", though. Whether you ship the compiler or a bundle (IDE).
>
> I like unittests in phobos and other libraries, because they immediately show me how to use the code, and I like how simple it is:
>
> dub --build=unittest
>
> or
>
> dmd myfile.d -unittest
>
> Be honest, have you written unittests for each your Python scripts, for each of your command line tools? D makes it easy for you.
>
> The only drawback is that sometimes the logic of a program does not allow to test every little bit, especially when handling files is concerned. But overall D in general makes me more "code aware" in many respects, be it performance, code hygiene or re-usability. And it helps that the compiler ships with a lot of flags that help me to analyze my code.

The funny thing is that people keep complaining about the lack of tools for D, and when a tool is built into the language they say "That tool shouldn't be part of the language". Yet, if it were omitted, people would say "Why doesn't D have this tool built in?". Human nature, I guess.

On Friday, 8 May 2015 at 09:52:06 UTC, Jonathan M Davis wrote:
> 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.

My estimation is 20% - they apply to simplistic self-contained libraries like phobos and warp. My impression is not much code falls in this category. Even dmd doesn't, and it's already rather simplistic.

> 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.

Inability to use 3rd party libraries is a packaging (tooling) issue, though.

On 05/07/2015 08:16 AM, d user wrote:
>
> Go comes with a package manager,

Dub is slated to become packaged with DMD.

> a linter,

-wi

> a static analysis tool,

Normal D language semantics ;)

> a formatter.

Granted, not built-in, but a pretty minor thing IMO.

On 5/8/15 7:03 AM, Chris wrote:
> The funny thing is that people keep complaining about the lack of tools
> for D, and when a tool is built into the language they say "That tool
> shouldn't be part of the language". Yet, if it were omitted, people
> would say "Why doesn't D have this tool built in?". Human nature, I guess.

Nicely put :o). I think the right conclusion to this discussion is to fall in neither "D has no tooling", nor "D's tooling is great" extreme. As it often happens, there's no shortage of ideas on things we could work on, more so than folks ready to work on them. So... have at it! -- Andrei

On Friday, 8 May 2015 at 14:04:00 UTC, Chris wrote:
> The funny thing is that people keep complaining about the lack of tools for D, and when a tool is built into the language they say "That tool shouldn't be part of the language". Yet, if it were omitted, people would say "Why doesn't D have this tool built in?". Human nature, I guess.

Well, I am not saying "why doesn't D have any tools built in?" or even "why doesn't D have a great IDE?". I'm saying that tools are not as critical, they only affect a specific demographic, but not the bottom line.

There is a large potential demographic base that are quite content with barebones tooling (emacs/unix), so if you by improving the language/runtime can appeal more of those developers you also have a baseline for extending into other demographics. Extending into the "spoiled kids" demographic will lead  exactly to what you'd expect… more work, more demands.

"Tooling" and "testing" are very opinionated, fashionable and situated topics. Much more so than language semantics.

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.

I decided to line up our potatoes on a nice new wiki page:

http://wiki.dlang.org/Development_tools

On Friday, 8 May 2015 at 15:47:11 UTC, Vladimir Panteleev wrote:
> 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.
>
> I decided to line up our potatoes on a nice new wiki page:
>
> http://wiki.dlang.org/Development_tools

Good man yourself!