On 11/30/2014 12:54 PM, bearophile wrote:
> Walter Bright:
>
>> I decided to try and update DMDScript from D1 to D2. Thousands and thousands
>> of error messages :-(
>
> It's not just the errors, it's also the new features and opportunities offered
> by the newer D/Phobos that you weren't using in the old code... Just removing
> the errors is usually not enough to produce modern and very good D2 code.

I'm aware that D2 offers many opportunities to improve the code :-)

After all, DMDScript is a very early D project.

On 11/30/2014 12:28 PM, Dmitry Olshansky wrote:
> 30-Nov-2014 23:22, Walter Bright пишет:
>> On 11/30/2014 7:36 AM, H. S. Teoh via Digitalmars-d wrote:
>>> Good idea! We should archive docs from older versions of Phobos and make
>>> them accessible on dlang.org. I'm working on revamping some parts of the
>>> Phobos docs build; once that's in, it might not be too hard to make it
>>> also generate docs for older releases.
>>
>> I decided to try and update DMDScript from D1 to D2. Thousands and
>> thousands of error messages :-(
>>
>
> Even back in 2010 it took about 10 evenings to get it to "runnable" state. Then
> another ~20 evenings to fix most of bugs, including semantic errors and GC
> collecting live objects.
>
> You may want to check my fork that used to compile with dmd 2.058 or smth
> (whatever was actual in 2012). Might help to assess the amount of work...
> https://github.com/DmitryOlshansky/DMDScript
>
> It at least passed about 90% (most fails in library tests) of 2012 Google's
> Spuntik JavaScript test.
>

Wow, I didn't know you'd done this. I'll check it out.

I know that the D1 version did pass Sun's Javascript test suite which was vintage 2000 or so.

My intent after updating DMDScript is to put it on dub.

On Sun, Nov 30, 2014 at 12:22:54PM -0800, Walter Bright via Digitalmars-d wrote:
> On 11/30/2014 7:36 AM, H. S. Teoh via Digitalmars-d wrote:
> >Good idea! We should archive docs from older versions of Phobos and make them accessible on dlang.org. I'm working on revamping some parts of the Phobos docs build; once that's in, it might not be too hard to make it also generate docs for older releases.
> 
> I decided to try and update DMDScript from D1 to D2. Thousands and thousands of error messages :-(

Well... upgrading from C to C++ involves... close to zero error messages. But that's not necessarily a good thing, as I'm sure you'll agree! I think in many ways, D2 is a far different language than D1, and it'd be unrealistic to expect D1 code to compile with D2 without a fair amount of changes.


T

-- 
"I suspect the best way to deal with procrastination is to put off the procrastination itself until later. I've been meaning to try this, but haven't gotten around to it yet. " -- swr

On 11/30/2014 12:28 PM, Dmitry Olshansky wrote:
> 30-Nov-2014 23:22, Walter Bright пишет:
>> On 11/30/2014 7:36 AM, H. S. Teoh via Digitalmars-d wrote:
>>> Good idea! We should archive docs from older versions of Phobos and make
>>> them accessible on dlang.org. I'm working on revamping some parts of the
>>> Phobos docs build; once that's in, it might not be too hard to make it
>>> also generate docs for older releases.
>>
>> I decided to try and update DMDScript from D1 to D2. Thousands and
>> thousands of error messages :-(
>>
>
> Even back in 2010 it took about 10 evenings to get it to "runnable" state. Then
> another ~20 evenings to fix most of bugs, including semantic errors and GC
> collecting live objects.
>
> You may want to check my fork that used to compile with dmd 2.058 or smth
> (whatever was actual in 2012). Might help to assess the amount of work...
> https://github.com/DmitryOlshansky/DMDScript
>
> It at least passed about 90% (most fails in library tests) of 2012 Google's
> Spuntik JavaScript test.
>

Do you mind if I simply merge your fork into https://github.com/DigitalMars/DMDScript ?

On 29/11/14 16:56, Andrej Mitrovic via Digitalmars-d wrote:
> The fact that you think you're going to get symbol suggestions for 2
> year old code just shows how out of touch you are with the development
> process. We have a deprecation stage, and a removal stage. There's no
> way you're going to get suggestions for missing symbols for code that
> references those symbols which existed 2 years ago.

It's fair to say that 2 years is a long time in recent Phobos development.

However, I don't think Walter's point is about it biting him personally.  The question is, what happens if somebody tries to use or resurrect an old D project -- how much trouble are they going to have trying to bring it back to life, and where they need to update code, how helpful are the tools?  It doesn't reflect well on the language or its community if older D code is as unusable as Walter describes, and it's particularly problematic where it relates to Phobos, because here we have much more scope to deprecate things without ever actually removing them.

That said, I don't think this is an argument for freezing things.  I think it's an argument for being very clear about what parts of the Phobos API are stable, and allowing for the (clearly documented) possibility of change where that may be desirable.

On 11/30/2014 7:28 AM, H. S. Teoh via Digitalmars-d wrote:
> I think the complaint was not so much the fact that the code broke, but
> the fact that it broke *without any clue as to how to fix it*.

Yup. Consider the fnmatch => globMatch change. Just edit the name, right? Easy-peesy, right? But:

1. the guy given the job of updating the software is not the guy who wrote it - he doesn't know what the code is intending to do

2. He gets "fnmatch is undefined"

3. there's no documentation for fnmatch anymore. He has no idea what fnmatch is supposed to do. Now he's got to embark on some sort of forensic search through old versions of the compiler, and not having much clue which ones to look at

4. he figures out what it does, then starts poking through the Phobos documentation looking for something that might work

5. he finds globMatch, it looks like it'll work

6. hopefully he's got a good test suite to verify that it is actually the correct replacement

A simple name change has turned into a fair amount of work.


> Now, if we had something like @disable with an optional message, we could do
> something like:
>
> 	@disabled("Please use globMatch instead") auto fnmatch(...);
>
> At least in theory, this would fix the problem. Of course, in practice,
> things rarely work out so nicely except in retrospect. :-P

Keeping around a deprecated alias translating the old symbol to the new one is a good approach. For a more detailed message, instead of the @disabled enhancement, a simpler way is:

  void fnmatch()(...) {
    static assert(0, "use globMatch instead of fnmatch");
  }

Walter Bright:

> I'm aware that D2 offers many opportunities to improve the code :-)

One problem I am seeing is that there is a large distance from the bare-bones code D2 requires you to write, and the code that I now regard as good D2 code. And the D2 compiler doesn't require or pushes you much toward the better code.

You can see that even for in the smallest things, like:

foreach (i; 0 .. 10) {
    writeln(i);
    i++;
    writeln(i);
}

I suggested to make that variable i an immutable by default. Currently it's a mutable and nearly no one bothers to write the correct and safer code:

foreach (immutable i; 0 .. 10) {
    writeln(i);
    writeln(i + 1);
}


The moral of this story is that a language needs to be designed to have by default the best&safe idioms (but avoiding excessive amounts of typing as Ada). This is a hard balance to find.

Here you can see two examples of code that show the difference from the C-style code that compiles with D2, and the code you can write in D2 only if you push yourself a lot to express more invariants and more precise typing:

http://rosettacode.org/wiki/Hidato#D

(The two programs are similar but they don't do exactly the same things. The second program is longer also because it does a little more).
Most of the D code you see in the wild is the C-like code of the first kind.

This problem is present even in Ada code or F# code, but in F# the "basic" style of coding is rather safer than D written in the bare bones C-style, and it's rather crisp.

Bye,
bearophile

On Sunday, 30 November 2014 at 23:16:14 UTC, bearophile wrote:
> ...
> I suggested to make that variable i an immutable by default.

I suggest everything be made immutable by default ;)

weaselcat:

> On Sunday, 30 November 2014 at 23:16:14 UTC, bearophile wrote:
>> ...
>> I suggested to make that variable i an immutable by default.
>
> I suggest everything be made immutable by default ;)

Currently D doesn't have a keyword as "mut" or "mutable" so if you make the foreach variable immutable by default, you have some troubles when (rarely) you want a mutable foreach index (you need an auxiliary variable, and you have to type it manually, because if you use "auto" you get another immutable again).

But for the general case of all the variables, this breaks all the D2 code, so you can't do that (but I don't know why this change wasn't done in the D1->D2 transition), and I think Walter doesn't like things like pragma(strict) to be put beside the module name to denote modules where variables are const/immutable by default. So I didn't even discuss this impossible option.

Bye,
bearophile

On Sun, Nov 30, 2014 at 03:03:37PM -0800, Walter Bright via Digitalmars-d wrote: [...]
> Keeping around a deprecated alias translating the old symbol to the new one is a good approach. For a more detailed message, instead of the @disabled enhancement, a simpler way is:
> 
>   void fnmatch()(...) {
>     static assert(0, "use globMatch instead of fnmatch");
>   }
[...]

That's a good idea.

Keep in mind, though, that in this particular case, std.path was essentially replaced wholesale, so does that mean that every time we replaced a module, we have to keep the entire old set of symbols around basically forever?


T

-- 
It said to install Windows 2000 or better, so I installed Linux instead.