Windows experience is atrocious

[H. S. Teoh]

On Wed, Jul 26, 2023 at 04:27:24AM +0000, harakim via Digitalmars-d wrote:
> On Tuesday, 25 July 2023 at 16:51:04 UTC, H. S. Teoh wrote:
> > In compiler terms, this just means that the compiler has to (1)
> > understand that it's dealing with code meant for an older version of
> > the language, and (2) based on that knowledge adapt the way it
> > processes the code in a way that preserves its original meaning.
>
> That's an interesting comparison to older languages. I agree if you
> can do 1 and 2 then the problem wouldn't exist. I have doubts about
> whether people would do (1), although it could be done retroactively
> as needed, maybe even in an automated fashion. So that could work.

This one is easy: introduce a version declaration at the top of every
module, say a `version = "2.105.0";`, or something alongside the module
declaration, like `module my.module version("2.105.0");`.  All older
code that don't have this declaration will be assumed to be written for
some fixed baseline version, say the latest version before this scheme
is implemented in the compiler.  Then going forward, all unmarked code
will be pinned at that version, and to get newer features you'd
introduce the version declaration to your module, thereby ensuring that
it will be properly marked going forward.


> Then there is (2). Would there be 104 code paths (for ex, 1 for each
> version) in the compiler? That seems like it would be super
> complicated.

It's impractical to retroactively do this for previous releases. Just
set the current release (or whatever release this scheme will start in)
as the baseline, and have each new feature guarded by an appropriate
version condition, so that the old code path will continue to run if the
current module isn't versioned for a release that includes the new
feature.  We don't have to keep 104 copies of the compiler code around
for this, that'd be an unmaintainable mess.


> > Something along these lines has to be done, otherwise we're never
> > gonna move forward.  The ecosystem is just gonna stagnate because
> > the more the language advances, the more old code and old libraries
> > will stop compiling.
> 
> This is definitely true. I worked a job where we would sell a lot but
> our software was so bad, we would lose more customers than we gained.
> I hadn't really thought of it like that but I do feel like I find
> fewer tools and native libraries than I used to.
> 
> I think it would be reasonable for people to keep multiple compilers
> around.  Maybe someone could be expected to keep each LTS version
> around. I don't know how much that would solve though since there
> would still be all the incremental versions. I'm not convinced the
> version thing is practical yet, but it would solve the problem. Do you
> think it would be practical to have a single compiler managing 100s of
> versions of the language?

It will make the compiler more complex to maintain, certainly.  But
*something* has to be done... otherwise nothing is going to change and
the D ecosystem is going to remain small forever.


T

-- 
Once bitten, twice cry...