Windows experience is atrocious

harakim harakim at gmail.com
Tue Jul 25 07:28:46 UTC 2023


On Monday, 24 July 2023 at 07:22:57 UTC, Paolo Invernizzi wrote:
> On Sunday, 23 July 2023 at 17:14:39 UTC, Walter Bright wrote:
>> On 7/23/2023 2:12 AM, Paolo Invernizzi wrote:
>>> On Saturday, 22 July 2023 at 01:23:54 UTC, Walter Bright 
>>> wrote:
>>>> Going to revisit this:
>>>>
>>>> https://github.com/dlang/dmd/pull/15443
>>> 
>>> *sigh*
>>
>> ??
>
> You know, I'm in the "deprecate and clean-up the language" camp 
> since forever ...

I am glad there is a deprecate and clean-up the language camp and 
it's gotten D to where it is today. I like to have improvements 
like that, but for about 7 years I have been in the stabilize the 
language camp and I'd like to explain why.

I have java code from 2006 that still compiles today. I have tens 
of thousands of lines of c/assembly from 1998 that compiles today 
with two errors and I would bet there's a flag to make it work if 
I didn't want to change it. In college (about 15 years ago) I 
helped someone with some code for their PHD dissertation. It was 
Fortran 57 code copied out of a textbook and it also compiled 
without issue. IMO, this is the norm for a project.

In contrast, I don't know that I have ever come back to an old D 
project and had it compile. Just the other day, I went to compile 
some code I wrote with dmd 2.100 with a 2.104 compiler and it 
would not compile. Sure, it's an easy fix, but that's not always 
the case and I am tired of tools that nickel-and-dime me. That is 
the whole point of picking a toolset, which includes the 
programming language: to have something that doesn't nickel and 
dime me - something that is fun and productive. When I'm in the 
flow, I can write code as fast as I can type forum posts. I can 
do that in C# for most things (and I just got a job in C# to 
boot). However, D is pretty much as good as C# for most things, 
but really shines in some other cases. It's 90% of the way to a 
solid choice for just about anything.

It is very demotivating to spend 100 hours on a project and then 
have to put it away, then come back in 2 years and have 
innumerable compilation errors or have all your libraries become 
unusable. It is very hard to want to commit to that kind of 
language where the first step of picking up an old project is 
replacing libraries - if there are even replacements - and fixing 
compilation errors and THEN trying to remember what you were 
doing and where you were at and only then can you actually make 
progress. This isn't necessarily a dealbreaker for people who 
work on it full time and keep their code up to date nor for 
single people who have lots of free time anyway, but it's a 
dealbreaker for many who are investigating the language or even 
for a part-time hobbyist.

So that is why I am a proponent of stabilizing the language. So I 
can work on solving my problem of interest and not working on 
rewriting libraries or compilation errors. So I can spend the 
time to get really good and write my own tools so it's even more 
out of the way of solving my problem.

Obviously, I would prefer the team to keep cleaning up the 
language, given it doesn't break all my existing code. Someone 
mentioned that gcc autocorrects code. That would facilitate clean 
up. Having a tool that would go through and make the minor 
automatic changes to upgrade to the latest standard would be a 
solution, if that is practical. Having a simple and unambiguous 
guide to changes you need to make between language versions could 
work if people knew to look for it and could find it easily. I 
also think distributing libraries as binaries could solve most of 
the big issues, tbh, although that idea doesn't seem to get a lot 
of mileage for reasons I can't understand.

I believe there is a plan that can work for everyone. I'm not an 
expert on compilers or build chains and I'm not super clear on 
where the language is going, so I'm not a great person to explain 
what that plan is. I am very happy to see that stability is being 
addressed, and I also understand I may not reflect the target 
audience of the language. I'm trying to find a way to get into 
the compiler to get some experience in my free time, but mostly 
I'm hoping to understand the different perspectives of people on 
this issue so I can draft a meaningful problem statement. I would 
like to be in a position to provide some good advice or even come 
up with a great idea to solve the stability issues without 
sacrificing moving the language forward. If you are open to it, I 
would appreciate hearing more about your perspective on this via 
a phone call or chat. If you're interested you can hit me up here 
or at my gmail address that is the same as my username.


More information about the Digitalmars-d mailing list