On 2/27/2013 12:05 AM, pjmlp wrote:
> This is not true.
>
> Javadoc uses a plugin architecture known as doclet.

I didn't know about doclets. Thanks for the correction.

On Tuesday, 26 February 2013 at 23:37:57 UTC, Andrei Alexandrescu wrote:
<snip>
>
> Agreed, but it does happen often that a language feature is later superseded by a generalization thereof.
>
> Andrei

I agree that this does happen. The question is how the language evolve with that in mind. Do we choose to preserve *all* previous semantics? Do we have a proper deprecation process? etc, etc..
I think that unfortunately, the D design process is not adequate as of yet - there is no proper deprecation process which causes things like a "sudden death" for previously valid syntax (alias syntax) instead of gradually deprecate it with proper announcements *everywhere* (website, NG, ..) on the one hand and keeping redundant special cases in the language and refusing to change semantics (AAs) to allow for an easier path forward, on the other hand.

So I think we agree on the spirit of things but the problems I'm voicing are about the details or lack thereof. Where are the guidelines describing all these issues? How to address required semantic changes in the language? how to address syntax changes? how to remove previously failed features or no longer needed ones? What constitutes a feature that should be completely removed and what should only be put on permanent deprecation status? How all those things interact?
If we still (after a decade!) decide these based on c++ common wisdom only than I think something is really broken here. Previously valid D syntax is easily broken without much regard yet we are still stuck on the comma backwards compatibility to C. We ignore all other languages that programmers migrate from to D and ignore their common wisdom and experience. Isn't it time for D to become its own language instead of a leech on C++ idioms?

On Wednesday, 27 February 2013 at 00:01:31 UTC, Andrei Alexandrescu wrote:
>
> I understand how you see it, and honestly could see it from a mile. When a post (a) cherry-picks all negatives and (b) has a final tone that mentions no possible solution - it's a foregone conclusion that no amount of explaining, amending, arguing, etc. will improve the poster's outlook.
>
> I could say e.g. "Well I think things have changed, and look we've turned the bug trend curve (http://goo.gl/kf4ZC) which is unprecedented, fixed some incomplete features, break new records on bug fixes with each release, and have a big conference coming." - to which I have no doubt it's possible to concoct a negative answer.
>
> So I understand you have a negative outlook on D. That's entirely fine, as is mentioning it on the forum. The only thing I'd like you to understand and appreciate is that we who work on D are doing our best to find solutions to the various problems in front of us, and in quite a literal sense we don't know how to do any better. The constructive thing I'm getting out of this is that we could use some more radicalization - try things that push stronger against our comfort zone. I have a few in mind but it's too early to discuss them publicly.
>
>
> Andrei

Let me emphasize again, I did *not* intend to discuss the specific features, Walter brought that topic up. I intended to point out the lack of good general guidelines for the D design process. And i did actually mention one (partial) solution. I mean no disrespect to the hard work of the contributers and did not wish to discourage them, just to prevent wasted effort due to lack of proper guidelines.
The other criticism I have is exactly the last paragraph above. Rust is designed in the open and so I can read the weekly minutes and get the bigger picture of the design process, what are the different proposed alternatives, what are the considerations and trade-offs, etc. In D on the other hand, it's all closed. D claims that it is an open source project but all the major design decisions happen personally between you and Walter and this is worse than big company languages that at least publish some articles online.

On 2013-02-26 21:51, foobar wrote:

> Again, this is a completely superfluous feature. D already has
> annotations (took only several years to convince Walter to add them)
> which are more flexible and much better suited for this.
>
> @unittest // <- this is a unit-test function
> void mySuperDuperTestFunction(...);
>
> There is no benefit in having all those special case features in the
> language which have all sorts of integration issues yet deny the
> usefulness of a more general solution generally accepted in the
> programming world, successfully used in many languages and thus also
> familiar to programmers coming from those languages.

I like that I don't have to create a function for the tests. I can run arbitrary code in the unit test blocks. Otherwise I agree with you.

-- 
/Jacob Carlborg

On 2013-02-27 00:37, Andrei Alexandrescu wrote:

> Agreed, but it does happen often that a language feature is later
> superseded by a generalization thereof.

In this case it would be two features:

1. Allow to run arbitrary code at top level
2. Allow to pass a delegate to a function after the parameter list

void unittest (void delegate () dg)

unittest {
    assert(true);
}

Would be lowered to:

unittest({
    assert(true);
});

Then we also can easily support named unit tests:

void unittest (string name, void delegate () dg)

unittest("foo") {
    assert(true);
}

Would be lowered to:

unittest("foo", {
    assert(true);
});

I think it would be nice if D could get better at declarative programming.

-- 
/Jacob Carlborg

On 2013-02-26 21:24, H. S. Teoh wrote:

> But D's built-in unittests, for all their warts and shortcoming, have
> the benefit of being right there, ready to use, and guaranteed to be
> runnable by whoever is compiling the code (don't have to worry about
> people not having Expect/python/whatever installed, so contributors have
> no excuse to not run them, etc.).

I think that is one of the problems with unit tests in D. I don't know how to run them. It's just the -unittest flag, but that's not enough.

* How do I run all the unit test in all of my files? Some will have a shell script called "test.sh", some will call it "unittest.sh". How do I then run the test on Windows, I can run Bash scripts on Windows. Some will have a D file "test.d", what the h*ll should I do with that? Compile it? run it using RDMD?

* How do I run a single test?
* How do I run a subset of the tests?

The questions go on.

Using Ruby on Rails, the first thing I see when I clone a repository is either a "test" or a "spec" folder. These are run using "rake test" or "rake spec". All projects using these frameworks support running all test, a single test and a subset of test. And it's the same commands on for all projects on all platforms.

-- 
/Jacob Carlborg

On 2013-02-26 20:53, Walter Bright wrote:
> On 2/25/2013 11:56 PM, foobar wrote:
>> DDoc isn't part of the language but rather part of the compiler,
>> nevertheless it
>> has its downsides.  [...]
>> unittest is worse,

[SNIP]

I'm going to use the big "if".

If the D compiler was built properly as a library, preferably in D. We could build all these features as separate tools (Ddoc, unit test) with the help of the compiler. These tools would then be included in the D distribution. Actually, the unit test support doesn't need the compiler as a library.

The build in unit tests support doesn't give much. It's easily implemented as a library with a simple tool to drive it. Example:

void unitTest (void delegate () dg);

static this ()
{
    unitTest({
        assert(true);
    });
}

It's then easy to add support for named unit tests:

void unitTest (string name, void delegate () dg);

static this ()
{
    unitTest("foo", {
        assert(true);
    });
}

If we then add some syntax sugar and allow a delegate to be passed after the parameter list we could have this:

static this ()
{
    unitTest("foo") {
        assert(true);
    }
}

If we then could support having arbitrary code at top level we would have this:

unitTest("foo") {
    assert(true);
}

Which is basically the same syntax as we have now but it's implemented as a library function. It can easily be extended with other similar functions doing slightly different things.

-- 
/Jacob Carlborg

On 2013-02-27 00:44, Walter Bright wrote:

> 1. require the user to type the information in twice
> 2. add parsing and semantic analysis capability to the doc generator

3. Build the compiler as a library. Use the library when creating the separate ddoc tool.

Number 3 would be the correct approach.

-- 
/Jacob Carlborg

On 2/27/13 5:01 AM, foobar wrote:
> Let me emphasize again, I did *not* intend to discuss the specific
> features, Walter brought that topic up. I intended to point out the lack
> of good general guidelines for the D design process. And i did actually
> mention one (partial) solution. I mean no disrespect to the hard work of
> the contributers and did not wish to discourage them, just to prevent
> wasted effort due to lack of proper guidelines.

I agree we should have a more organized process.

> The other criticism I have is exactly the last paragraph above. Rust is
> designed in the open and so I can read the weekly minutes and get the
> bigger picture of the design process, what are the different proposed
> alternatives, what are the considerations and trade-offs, etc.
> In D on
> the other hand, it's all closed. D claims that it is an open source
> project but all the major design decisions happen personally between you
> and Walter and this is worse than big company languages that at least
> publish some articles online.

Four years ago I would've entirely agreed. But right now it's an odd comment to make seeing as we're discussing all major decisions in this group and we're switching full-bore to DIPs.


Andrei

On 2/27/13, Jacob Carlborg <doob@me.com> wrote:
> * How do I run a single test?
> * How do I run a subset of the tests?

If this is really an often-requested feature it could be implemented by default in Druntime. All you'd need is to parse command-line arguments before calling main(), document these switches, and implement this feature in the default unit tester that's found in core.runtime.runModuleUnitTests after the "if( Runtime.sm_moduleUnitTester is null )" check.

For example I use this:

https://github.com/AndrejMitrovic/dgen/blob/master/src/dgen/test.d

If I want to test specific modules I use:
rdmd --testModsRun=a.b.c --testModsRun=d.e.f main.d

And if I want to ignore running specific tests:
rdmd --testModsSkip=a.b.c main.d