On 12/21/22 7:46 PM, Walter Bright wrote:
> On 12/21/2022 11:35 AM, Steven Schveighoffer wrote:
>> Stop trying to fix C. Fix D instead.
> 
> [..] is edging ahead in the twitter poll!
> 

It's the bots! Don't listen to them!

-Steve

On Wednesday, 21 December 2022 at 19:18:19 UTC, Walter Bright wrote:
> On 12/21/2022 11:09 AM, Walter Bright wrote:
>> https://news.ycombinator.com/edit?id=34084894
>> 
>> I'm wondering. Should I just go ahead and implement [..] in #ImportC?
>
> Vote here:
>
> https://twitter.com/WalterBright/status/1605642794965483521

I don’t use twitter, so count this as a vote for yes. The C committee doesn’t like adding features out of whole cloth like the C++ committee does, so having a C compiler with this extension is one step towards standardization.

On 12/21/2022 1:44 PM, Paul Backus wrote:
> Number of positive Hacker News comments, perhaps? :)

It has indeed generated a lot of positive interest in D.

Thanks for the references.

As you mentioned, they are a poor substitute. The proof of that is I simply never run across C code that uses them.

On 12/21/2022 3:13 PM, monkyyy wrote:
> If you are finding d too unwieldy to add features to, maybe its time to start planning d3 and how you going to clean up the technical debt

Every time I try to clean up technical debt, a cadre arises objecting that it breaks existing code.

On Thursday, 22 December 2022 at 00:46:03 UTC, Walter Bright wrote:
> On 12/21/2022 11:35 AM, Steven Schveighoffer wrote:
>> Stop trying to fix C. Fix D instead.
>
> [..] is edging ahead in the twitter poll!

We don't need faster horses.

To quote Coluche, "Just because they are many to be wrong doesn't mean they are right."

On Wed, Dec 21, 2022 at 07:23:47PM -0800, Walter Bright via Digitalmars-d wrote:
> On 12/21/2022 3:13 PM, monkyyy wrote:
> > If you are finding d too unwieldy to add features to, maybe its time to start planning d3 and how you going to clean up the technical debt
> 
> Every time I try to clean up technical debt, a cadre arises objecting that it breaks existing code.

That's what versioning is supposed to solve. Freeze the current language as version 2, put it on long-term maintenance, and start a new branch as a new version with breaking changes that fix technical debts.

The current language has plenty of rough spots that shouldn't be set in stone forever; there is still room for D to develop into the future. Don't lock yourself into the current suboptimal state; acknowledge it as the best effort so far, and give yourself a new opportunity to do better.


T

-- 
Nearly all men can stand adversity, but if you want to test a man's character, give him power. -- Abraham Lincoln

On Thursday, 22 December 2022 at 03:23:47 UTC, Walter Bright wrote:
> On 12/21/2022 3:13 PM, monkyyy wrote:
>> If you are finding d too unwieldy to add features to, maybe its time to start planning d3 and how you going to clean up the technical debt
>
> Every time I try to clean up technical debt, a cadre arises objecting that it breaks existing code.

You can't break D2 by working on D3. Also it would be perfect if D3 could implement ImportD2 and take advantage of the existing D2 modules. But I guess, ImportD2 is much more difficult than ImportC and won't be even considered.

On 12/21/2022 9:02 PM, H. S. Teoh wrote:
> That's what versioning is supposed to solve.

I know about versioning. But our -preview and -revert switches are better, as they allow the user to selectively decide which obsolete features they need. The request is always "I want X bug fixed, I want to keep the old Y feature, I want the new Z feature."

But the people objecting to breaking code also object to using a -revert switch.

Versioning comes with other problems. The most significant is we lack sufficient staff to maintain multiple versions.


> Freeze the current
> language as version 2, put it on long-term maintenance, and start a new
> branch as a new version with breaking changes that fix technical debts.

The trouble there is that fixing bugs *also* comes with breaking existing code. There is no clean separation between the two.