H. S. Teoh wrote:

> On Wed, Jun 14, 2017 at 11:45:43PM +0300, ketmar via Digitalmars-d wrote:
>> Ola Fosheim Grøstad wrote:
>> 
>>> On Wednesday, 14 June 2017 at 12:22:36 UTC, Russel Winder wrote:
>>>> If a code is to be left untouched but the compiler not archived
>>>> then the code must be recompiled and amended as needed with each
>>>> new compiler that is accepted in the workflow.
>>> I don't disagree with the general sentiment than one have to evolve
>>> the codebase along with the tooling, but if C, C++, Python and
>>> JavaScript didn't provide backwards compatibility in their
>>> maintained "production lines"
>> at least C doesn't: almost all old-enough code is broken by various
>> "UB".
>
> The difference is that unlike D deprecations, the C code will still
> compile and appear to work (for the most part, anyway), thus giving
> people the illusion that their old code is still "OK".  When actually,
> the compiler may have done something unexpected with the UBs and thus
> inadvertently introduced security holes.
>
> Of course, none of this matters, since when was the last time bad C code
> has caused security problems? :-P

yeah. D should silently miscompile old code too: it seems that this is exactly what people want!

On Wednesday, 14 June 2017 at 12:22:36 UTC, Russel Winder wrote:
> On Wed, 2017-06-14 at 11:57 +0000, bachmeier via Digitalmars-d wrote:
>> 
> […]
>> I've been using D for four years. I can still compile code that compiled with DMD at that time, with only a few minor modifications. I expect to be able to do the same four years from now.
>
> I suggest this is the wrong view of backward compatibility.
>
> If you have a code that is never to change then you should archive the compiler that compiled it along with that code. To demand that D must never fail to compile ancient code is just wrong.
>
> If a code is to be left untouched but the compiler not archived then the code must be recompiled and amended as needed with each new compiler that is accepted in the workflow.

I'm not saying all old code should compile without changes, just that it should compile with only minor changes. I know that in some cases new releases of DMD have stopped compiling pieces of my code that shouldn't have compiled in the first place, and that's a good thing. On the other hand, dropping the GC would be a dramatic change that would require a complete rewrite. Libraries have to work with future versions of the compiler, especially if others are using them and can't make changes themselves.

On Wednesday, 14 June 2017 at 20:35:15 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 14 June 2017 at 12:22:36 UTC, Russel Winder wrote:
>> If a code is to be left untouched but the compiler not archived then the code must be recompiled and amended as needed with each new compiler that is accepted in the workflow.
>
> I don't disagree with the general sentiment than one have to evolve the codebase along with the tooling, but if C, C++, Python and JavaScript didn't provide backwards compatibility in their maintained "production lines" then I most likely wouldn't use them and switch to something more stable...
>
> So, I have no problem with Python going to Pyton3.x, as long as they update and maintain Python 2.7...

It's a bigger problem for D than for those languages. If you introduce too many changes, the tools stop working, and we don't have the manpower to fix them. The same goes for libraries. A language with a larger group of developers, like Python, can be less conservative about breaking changes and not have it disrupt the ecosystem.

On Wednesday, 14 June 2017 at 21:20:58 UTC, ketmar wrote:
> yeah. D should silently miscompile old code too: it seems that this is exactly what people want!

Please point out the people who advocate for D silently miscompiling old code... Because i have yet to see anybody in this topic advocate this.

There is a difference between changes that:

- Fix bugs
- Fix security issues

And changes like

- Rewritten Library functions where those function calls end up working differently
- Removal of the Garbage collector ( and introducing ownership / lifetime and other rules )
- Changes that make tools not work anymore
- ...

It is this second part people worry about. If i need to fix code issues 5 years from now because the compiler got smarter, so be it. This will happen anyway with each progressive  bugfix / recompile. But there is a difference if massive rewrites are done on the language or libraries for that benefit only a few specific people there own usage.

So please keep this topic on track and not pull any straw man argumentation's. Its the internet and i know that some people like to win arguments with any means necessary but keep facts alive thank you very much.

I see nothing new being added to this topic anymore beyond more and more ridiculous claims.

On Wed, 2017-06-14 at 21:55 +0000, bachmeier via Digitalmars-d wrote:
> […]
> 
> I'm not saying all old code should compile without changes, just that it should compile with only minor changes. I know that in some cases new releases of DMD have stopped compiling pieces of my code that shouldn't have compiled in the first place, and that's a good thing. On the other hand, dropping the GC would be a dramatic change that would require a complete rewrite. Libraries have to work with future versions of the compiler, especially if others are using them and can't make changes themselves.

If D dropped the GC, then there wouldn't be a problem because there wouldn't be any users. The GC is the single major factor for D in a world of C++17, Rust, and Go: without the GC there is little point in using D since C++, Rust, and Go have much more resources for development of tools as much as of the language – cf. CLion, Gogland, IntelliJ IDEA/Rust plugin to name just the JetBrains IDEs.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Wulfklaue wrote:

> On Wednesday, 14 June 2017 at 21:20:58 UTC, ketmar wrote:
>> yeah. D should silently miscompile old code too: it seems that this is exactly what people want!
>
> Please point out the people who advocate for D silently miscompiling old code... Because i have yet to see anybody in this topic advocate this.

we were talking about broken C code. that was a joke about what C commitee did with it's "UB" defintion, and allowing compilers to act as if code never ever can have "UB" in it.

On Thursday, 15 June 2017 at 07:32:42 UTC, Russel Winder wrote:
> The GC is the single major factor for D in a world of C++17, Rust, and Go:

An opinion. Mine is this: The two major factors for D are (and have been for as long as I've been using it):
1. Productivity (i.e. focusing on writing actual problem solving code, not on dealing with language deficiencies)
2. Maintainability (i.e. still have that productive code look reasonable easy to understand a year from now without having to look up language deficiencies to understand why something *has* to look exactly the way it does, or introduce bugs)
The GC is nice in that it contributes to both of these points (and I have no desire to see it removed), but even without it there is no other native language (that I've tried as of yet) that comes even remotely close.

> without the GC there is little point in using D since C++, Rust, and Go have much more resources for development of tools as much as of the language – cf. CLion, Gogland, IntelliJ IDEA/Rust plugin to name just the JetBrains IDEs.

Still an opinion, so here is mine again (based merely on personal experience):
Despite all those resources, someone having invested about the same amount of time in mastering C++(17), Rust, Go, and D will still end up being more productive in D, simply because, out of all of these languages, you have to fight D to do what you want the least.
Is D perfect? No, not by any stretch of the definition, but it is still (by far) the least worst choice out there, no matter how good the tooling for other languages is or becomes.

Moritz Maxeiner wrote:

> Is D perfect? No, not by any stretch of the definition, but it is still (by far) the least worst choice out there, no matter how good the tooling for other languages is or becomes.

exactly my feelings! ;-)

On Wednesday, 14 June 2017 at 12:08:16 UTC, Mike wrote:
>
> * immutable by default
>

I have to admit I always get confused why people get so invested in this. It seems like you would have to completely redesign everything related to std.range/std.algorithm.

On Wednesday, 14 June 2017 at 22:01:38 UTC, bachmeier wrote:
> It's a bigger problem for D than for those languages. If you introduce too many changes, the tools stop working, and we don't have the manpower to fix them. The same goes for libraries. A language with a larger group of developers, like Python, can be less conservative about breaking changes and not have it disrupt the ecosystem.

Yes, on the other hand, if you reach a stable version and stop adding features then you can focus on and reach maturity... Then leave the new features to the unstable version.

If you keep adding features to a stable branch then maturity is perpetually out of reach. I think Go gained a lot of ground from focusing on maturity over features.