On Fri, Dec 23, 2022 at 08:46:09PM +0000, Hipreme via Digitalmars-d wrote: [...]
> Just check how much time D lost while trying to get into Android (which is unfortunately broken again).

What broke in Android?  My Android project still compiles (though I haven't worked on it for a while now -- busy with other things).


> Now we're living the Web era without real D support in WASM. D with the ability to be used as an alternative to Javascript/Typescript programmers would be specially useful as it is not a hard language to work with.

Call me a skeptic, but the last time I checked, which was earlier this year, I found WASM still very much in its infancy, it's still early adopter tech with lots of rough edges and uncertainties.  Expecting polished support at this point is IMO a bit unrealistic.  As I pointed out in another post, a lot of Javascript glue and boilerplate is still required to make things work.  A while back I posted my vision of what D support might look like: a preprocessing tool for extracting D function signatures, type declarations, target APIs (WebGPU, DOM, etc), etc., and generating the necessary JS boilerplate to make it work.  And some way to make the GC work without causing too many problems (which involves working with threads, which involves yet more JS boilerplate, which involves potentially nasty performance bottlenecks lurking behind the convenient abstractions).  The days of being able to just cross-compile a full-fledged D application, bells & whistles and GC and everything, into WASM with just a flick of a switch, are still far ahead in the future.  Be glad that LDC *can* compile a pretty big subset of D code into WASM already.  The key ingredients are already there, now we just need to build the plumbing.

But given the infancy of WASM, I'm really not sure if I want to be pouring a ton of time and effort into this yet.  I mean, c'mon, they haven't even finalized how you're going to interact with the host APIs yet, key things like GPU access, I/O, etc. -- these are pretty fundamental things without which you just ain't gonna have end-to-end WASM support, no matter how much you wish for it.  Even something as fundamental as passing string data across the JS/WASM boundary involves a huge amount of glue code and boilerplate; this isn't an off-the-shelf product that you can just take home and plug into your standardized WASM interface socket (it doesn't exist yet) and expect things will Just Work(tm).  This is a raw microchip that, despite whatever tremendous potential it may have, you still have solder to the motherboard yourself with your own soldering iron -- and the motherboard isn't provided, you have to build your own.

If somebody wants to build that standard WASM motherboard for interfacing with D, I'd fully applaud it.  But for the time being, I'm not expecting to be able to "just use D" on WASM just yet.


> The runtime problem must be solved somehow for we can stop dividing D and betterC libraries. A lot of projects were duplicated after betterC announcement.
[...]

What runtime problem?  Not being facetious here, just wasn't clear from your post which issue(s) specifically you're referring to.


T

-- 
Study gravitation, it's a field with a lot of potential.

On 24/12/2022 11:45 AM, H. S. Teoh wrote:
> On Fri, Dec 23, 2022 at 08:46:09PM +0000, Hipreme via Digitalmars-d wrote:
> [...]
>> Just check how much time D lost while trying to get into Android
>> (which is unfortunately broken again).
> What broke in Android?  My Android project still compiles (though I
> haven't worked on it for a while now -- busy with other things).

TLS in newer NDK's due to different linker.

On 12/23/2022 2:37 PM, rikki cattermole wrote:
> P1: separate out known state modules (ideally good) vs unknown state.

Please be more specific.


> To turn a module into known state you must severely document it, including TODO's.

One of my most common review comments are: "Please add ddoc comments to added functions." A common thing I do when working on a section of code is add ddoc comments to the functions.


> For good state: do the TODO's.

Grepping for TODOs in the source code doesn't yield much.


> Sound familiar? Its packagerization of leaf modules.

We've already discussed that one to death.


> Oh and on another note: WTF why do we have two ASTs? That's a massive technical debt to keep paying in maintenance (which we don't do).

That was a refactoring added by people other than me. I agree with you on that one. Finding the right refactoring is not easy.

On Sat, Dec 24, 2022 at 11:48:11AM +1300, rikki cattermole via Digitalmars-d wrote:
> On 24/12/2022 11:45 AM, H. S. Teoh wrote:
> > On Fri, Dec 23, 2022 at 08:46:09PM +0000, Hipreme via Digitalmars-d wrote: [...]
> > > Just check how much time D lost while trying to get into Android (which is unfortunately broken again).
> > What broke in Android?  My Android project still compiles (though I haven't worked on it for a while now -- busy with other things).
> 
> TLS in newer NDK's due to different linker.

Ahh I see.  I haven't updated my NDK in a while, that's probably why I didn't notice. :-/


T

-- 
When solving a problem, take care that you do not become part of the problem.

On 24/12/2022 11:57 AM, Walter Bright wrote:
> On 12/23/2022 2:37 PM, rikki cattermole wrote:
>> P1: separate out known state modules (ideally good) vs unknown state.
> 
> Please be more specific.

The root of the problem is we have an old code base which for all intents and purposes is in an unknown state.
We do not understand it in its entirety. There are duplicate behaviors, a lot of it is undocumented.

We cannot deal with it as a whole, but we can start with leafs, things that minimally depend on others.

As long as we keep known state vs unknown state in the same directory structure, we will never be motivated to deal with it.

>> To turn a module into known state you must severely document it, including TODO's.
> 
> One of my most common review comments are: "Please add ddoc comments to added functions." A common thing I do when working on a section of code is add ddoc comments to the functions.

Yeah that is a great long term strategy which I have been pleased to see happening, but the goal here is to do entire modules at a time.

>> For good state: do the TODO's.
> 
> Grepping for TODOs in the source code doesn't yield much.

Yeah, it takes concentrated efforts to add them first.

>> Sound familiar? Its packagerization of leaf modules.
> 
> We've already discussed that one to death.

Unfortunately. I (and a few others) just don't see any other way to pay off such significant debt. What we are doing now is just tinkering around the edges of the problem and isn't taking a sledge hammer to it which is what actually is needed.

>> Oh and on another note: WTF why do we have two ASTs? That's a massive technical debt to keep paying in maintenance (which we don't do).
> 
> That was a refactoring added by people other than me. I agree with you on that one. Finding the right refactoring is not easy.

Sounds like some refactoring to do ;)

Get the sledge hammer!

I've had some time to think about some more technical debt that could be paid off relatively easily.

In my last attempt at fixing ModuleInfo exportation, Iain complained about dmd's glue code state infecting the AST.

I.e. https://github.com/dlang/dmd/blob/5dfc20e016850820036a81a3c40b01bf08b8c244/compiler/src/dmd/dsymbol.h#L177

Which could be extracted out into its own struct which could be turned opaque or even used by ldc/gdc. The main issue is dub, which I think might be solvable by having a gluedefinitions subPackage in turn versions on if you have dmd-be.

On Friday, 23 December 2022 at 20:34:10 UTC, Walter Bright wrote:
> On 12/23/2022 6:24 AM, GrimMaple wrote:
>> What is your goal even, do you care about D at all? I'm going to great lengths to write software that's pure D, and when the creator of D gives up and starts "fixing" other languages, that's a huge off point to many.
>
> Expecting people with large C code bases to translate their C code to D is never, ever going to work. With ImportC, their C code bases can become "user friendly" with D code, making using D viable with a considerably larger user base.
>
> After all, look at the success of C++ with its integration with C.

This just further cements my point of you caring more about C programmers than about existing D programmers. You know, this is very difficult to deal with. Especially with your attitude of "I'm going to add half working stuff and if you're not satisfied with it just fix it yourself". You really shouldn't expect the community to run behind you and undo the damage that your toying around with the compiler does. There isn't any problem with manpower in the community at all. It's the fact that you keep introducing half-baked solutions so nobody understands what the heck to focus on, and what to fix. As a result, D promises a lot of potentially great features, that only really work on paper.

I've went through an effort and checked your github page. I didn't see you write or create anything beisdes the D compiler. Have you ever stepped down from your compiler work and tried to actually write anything in D? I'm not talking about basing your D code on top of existing C code, I'm talking about quality software written 100% in D. Because it feels like you're completely missing the point because you don't deal with the sufferings of D on a daily basis. I and a lot of the community are facing those problems, which is why a lot of people here told you to stop fixing C.

Now, about the C++ success part. I don't know how in the world you determined that C++ is a success, considering how every other C++ programmer (I've been a professional C++ programmer for about 10 years now) is loathing the language and desperatly wants to move out of it, but is held back by the legacy and the third party. C++ is so successful that Google had to make Carbon to fix it. For God's sake, wasn't the sole purpose of creating D to fix C++ in the first place? Aren't you just going against everything that D is?

The large portion of C++ is just legacy that has to be supported despite the suffering. For me, D is slowly turning to the same thing. The sunk cost fallacy.

> Anyone is welcome to fork D.

Are you really that arrogant? I hope you don't mean it, because when people do end up forking D, what would you do? I've been told about the D vs Tango split in the past. It doesn't seem to have taught you anything though.

At this point, I don't think any convincing you is going to work. You're just gonna do it because you can do it. And if anyone disagrees, they, by your words, can just fork the compiler. That line can be read as "You can screw off" by someone who has put any effort in improving the D ecosystem.

That being said, consider another D contributor lost.
I might fork D later, but I don't think I could be bothered. I'm not a compiler developer, and there doesn't seem to be enough peope interested in D as a stable language. So instead I will just go back to C++ or C#.

On Friday, 23 December 2022 at 21:32:28 UTC, Walter Bright wrote:

> Anyone is welcome to fork D. It's designed and licensed to permit this. But unless it comes with a plan for paid staff, it's hard to see how it would be different.

AFter all, maybe, it is YOU who should fork the compiler and toy with it in your fork. Just leave the current compiler for the desperate community to fix

On Saturday, 24 December 2022 at 08:57:45 UTC, GrimMaple wrote:
> It's the fact that you keep introducing half-baked solutions so nobody understands what the heck to focus on, and what to fix.

Sometimes it works. SIMD features were added that way, and it brought D into Remedy’s games.

To the topic.
ImportC is good thing. There are lots and lots of libraries written in C.
Extending C syntax is definitely not, it’s a time wasted. No one can beat Herb Sutter (CPPfront).

All D needs is:
1. Roadmap
2. Stick to it

If D2 cannot be fixed because of codebase (= cashflow from professional users) - it’s okay, we all need to eat.

It just means D3. Python did it, why D can’t?