On Thursday, 18 February 2016 at 11:12:57 UTC, Jonathan M Davis wrote:
> And actually, he'd risk legal problems if he did, because he doesn't want anyone to be able to accuse him of taking code from gcc or llvm.

That's a silly strawman, and you should know better than putting that forward as an argument by now.

Walter is of course free to do whatever he pleases, and I would totally understand if his reason was just that it's hard to give something up you've worked on for a long time.

But please don't make up argument trying to rationalize whatever personal decision somebody else made. You could literally copy LLVM source code into your application and sell it as a closed-source product without risking any copyright problems (if you comply with the very modest attribution clause of the license).

> If anything, the problem is probably that the gdc and ldc folks could use more help, but dmd and Phobos suffer from that problem on some level as well, albeit probably not as acutely.

The problem that many of us are seeing is that D development is unnecessarily defocussed by spreading out the effort between three different compilers. Of course, ideally we would have infinite manpower. A "special-case" compiler that boasts lower compile times for x86 development would definitely be nice to have then. But our resources aren't limitless, and as such the question whether we can afford to maintain such a "nice to have"-compiler is very relevant.

Don't get me wrong, I understand that there is an argument to be made for the current situation. And, by the way, let me make very clear that even if I argue that sticking to DMD is a strategic mistake, this is not about personal things. I highly respect Walter as a compiler developer and like him as a person. But perpetuating ill-informed arguments really doesn't do this debate any good.

 — David

On Thursday, 18 February 2016 at 17:56:32 UTC, Jonathan M Davis wrote:
> […] if you want to be writing scripts in D (which is really useful), you need rdmd, which means using dmd

You can use rdmd with ldmd2 just as well (and presumably gdmd too).

> New users are frequently impressed by how fast dmd compiles code, and it's a big selling point for us. It's only later that benchmarking comes into play, and if want to do that, then use gdc or ldc. The download page already says to use gdc or ldc if you want better optimization.

I'd claim that an equal number of people is put off by the sometimes abysmal performance of optimized DMD output in their initial tests and first toy projects.

> dmd is a clear winner as far as development goes.

Clear only to somebody with x86-centric vision. I'm not claiming that the somewhat lower compile times aren't good for productivity. But being able to easily tap into the rich LLVM ecosystem or even just targeting the most widely used CPU architecture (in terms of units) is also something not to be forgotten when considering the development process.

 — David

On 18.02.2016 21:24, David Nadlinger wrote:
> But please don't make up argument trying to rationalize whatever
> personal decision somebody else made. You could literally copy LLVM
> source code into your application and sell it as a closed-source product
> without risking any copyright problems (if you comply with the very
> modest attribution clause of the license).

LLVM's license isn't the supposed problem. DMD's license is. You cannot copy DMD backend code to LLVM. By not contributing to other compilers, Walter stays in the clear in that regard. At least, that's how I understand the argument.

On Thursday, 18 February 2016 at 10:42:33 UTC, Márcio Martins wrote:
> On Thursday, 18 February 2016 at 10:16:40 UTC, Radu wrote:
>> [...]
>
> Walter doesn't have to give up working on DMD, right? Everyone could continue working on DMD, perhaps a few people could help on all three, I don't know... It's important if more people work on DMD and focus on polishing the frontend and language features, being the reference compiler, and used by all three compilers as well. What could potentially be important would be to backport key fixes/features from current frontend to LDC/GDC as well.

As history tells, everything has to do with him moving D to more open waters.

DMD is just a piece of that history and an excuse to keep working in a confort zone. It adds nothing strategically and it's just the last vestige of the old D world.

On Thursday, 18 February 2016 at 20:28:41 UTC, David Nadlinger wrote:
> On Thursday, 18 February 2016 at 17:56:32 UTC, Jonathan M Davis wrote:
>> […] if you want to be writing scripts in D (which is really useful), you need rdmd, which means using dmd
>
> You can use rdmd with ldmd2 just as well (and presumably gdmd too).

Good to know.

> Clear only to somebody with x86-centric vision. I'm not claiming that the somewhat lower compile times aren't good for productivity. But being able to easily tap into the rich LLVM ecosystem or even just targeting the most widely used CPU architecture (in terms of units) is also something not to be forgotten when considering the development process.

Having ldc is huge, but as long as you're targeting x86(_64) as one of your platforms, developing with dmd is going to be faster thanks to the fast compilation times. And if we can get dmd and ldc to be fully compatible like they should be, then as long as your code is cross-platform, it should be possible to develop it with dmd and then target whatever you want with ldc - though obviously some stuff will have to be done with ldc when it's something that dmd can't do (like a version block targeting ARM), and anything that's going to ultimately be released using ldc should be tested on it. But that fast compilation time is so tremendous in the edit-test-edit cycle, that I just can't see using ldc as the main compiler for development unless what you're doing isn't targeting x86(_64) at all, or ldc isn't compatible enough with dmd to do most of the development with dmd.

But assuming that dmd and gdc/ldc are compatible, I would definitely argue that the best way to do D development is to do most of the development with dmd and then switch to gdc or ldc for production. That way, you get the fast compilation times when you need it, and your final binary is better optimized.

- Jonathan M Davis

On Thursday, 18 February 2016 at 20:24:31 UTC, David Nadlinger wrote:
> On Thursday, 18 February 2016 at 11:12:57 UTC, Jonathan M Davis wrote:
>> And actually, he'd risk legal problems if he did, because he doesn't want anyone to be able to accuse him of taking code from gcc or llvm.
>
> That's a silly strawman, and you should know better than putting that forward as an argument by now.
>
> Walter is of course free to do whatever he pleases, and I would totally understand if his reason was just that it's hard to give something up you've worked on for a long time.
>
> But please don't make up argument trying to rationalize whatever personal decision somebody else made. You could literally copy LLVM source code into your application and sell it as a closed-source product without risking any copyright problems (if you comply with the very modest attribution clause of the license).

It's not a strawman. Walter has state previously that he's explicitly avoided looking at the source code for other compilers like gcc, because he doesn't want anyone to be able to accuse him of stealing code, copyright infringement, etc. Now, that's obviously much more of a risk with gcc than llvm given their respective licenses, but it is a position that Walter has taken when the issue has come up, and it's not something that I'm making up.

Now, if Walter were willing to give up on the dmd backend entirely, then presumably, that wouldn't be a problem anymore regardless of license issues, but he still has dmc, which uses the same backend, so I very much doubt that that's going to happen.

- Jonathan M Davis

On Thursday, 18 February 2016 at 21:30:29 UTC, Jonathan M Davis wrote:
> It's not a strawman. Walter has state previously that he's explicitly avoided looking at the source code for other compilers like gcc, because he doesn't want anyone to be able to accuse him of stealing code, copyright infringement, etc.

Isn't this much more likely to happen if you don't look at the codebase for other compilers? How do you know if someone submitting code isn't just translating from GCC if you haven't looked at GCC?  If you have looked at GCC, then you can just choose a different implementation. :-)

Anyway, the clean-virgin thing in programming is related to reverse engineering very small codebases where the implementation most likely is going to be very similar (like BIOS). So you have one team writing the spec and another team implementing the spec (with no communication between them).

On Thu, 18 Feb 2016 21:39:45 +0000, Ola Fosheim Grøstad wrote:

> On Thursday, 18 February 2016 at 21:30:29 UTC, Jonathan M Davis wrote:
>> It's not a strawman. Walter has state previously that he's explicitly avoided looking at the source code for other compilers like gcc, because he doesn't want anyone to be able to accuse him of stealing code, copyright infringement, etc.
> 
> Isn't this much more likely to happen if you don't look at the codebase for other compilers? How do you know if someone submitting code isn't just translating from GCC if you haven't looked at GCC?

That's the exact opposite of true.

With copyright, the fact that you created yours on your own is sufficient defense, assuming the courts agree. If by sheer coincidence you come up with code identical to what's in GCC, but you can show that you didn't take the code from GCC, you're in the clear.

Patents, well, you're infringing even if you didn't refer to any other source. But if you did look at another source, especially if you looked in the patent database, you open yourself up to increased damages.

On 18 February 2016 at 22:23, Jonathan M Davis via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Thursday, 18 February 2016 at 20:28:41 UTC, David Nadlinger wrote:
>
>> On Thursday, 18 February 2016 at 17:56:32 UTC, Jonathan M Davis wrote:
>>
>>> […] if you want to be writing scripts in D (which is really useful), you need rdmd, which means using dmd
>>>
>>
>> You can use rdmd with ldmd2 just as well (and presumably gdmd too).
>>
>
> Good to know.
>
> Clear only to somebody with x86-centric vision. I'm not claiming that the
>> somewhat lower compile times aren't good for productivity. But being able to easily tap into the rich LLVM ecosystem or even just targeting the most widely used CPU architecture (in terms of units) is also something not to be forgotten when considering the development process.
>>
>
> Having ldc is huge, but as long as you're targeting x86(_64) as one of your platforms, developing with dmd is going to be faster thanks to the fast compilation times. And if we can get dmd and ldc to be fully compatible like they should be, then as long as your code is cross-platform, it should be possible to develop it with dmd and then target whatever you want with ldc - though obviously some stuff will have to be done with ldc when it's something that dmd can't do (like a version block targeting ARM), and anything that's going to ultimately be released using ldc should be tested on it. But that fast compilation time is so tremendous in the edit-test-edit cycle, that I just can't see using ldc as the main compiler for development unless what you're doing isn't targeting x86(_64) at all, or ldc isn't compatible enough with dmd to do most of the development with dmd.
>
> But assuming that dmd and gdc/ldc are compatible, I would definitely argue that the best way to do D development is to do most of the development with dmd and then switch to gdc or ldc for production. That way, you get the fast compilation times when you need it, and your final binary is better optimized.
>
> - Jonathan M Davis
>

Actually, I'm sure this is a great way to let bugs in.  There's no saying what could happen if you switch compiler and turn the optimisations throttle to full.  In 99% of cases, one would hope all is good.  But the bigger the codebase you're dealing with, the more you should really use both side by side when testing to ensure that no heisenbugs creep in.

On Thursday, 18 February 2016 at 22:22:57 UTC, Chris Wright wrote:
> With copyright, the fact that you created yours on your own is sufficient defense, assuming the courts agree. If by sheer coincidence you come up with code identical to what's in GCC, but you can show that you didn't take the code from GCC, you're in the clear.

And how are you going to show that? You can't, because it is widespread.

> Patents, well, you're infringing even if you didn't refer to any other source. But if you did look at another source, especially if you looked in the patent database, you open yourself up to increased damages.

There are no damages for GCC.