On Thursday, 18 November 2021 at 09:38:09 UTC, FeepingCreature wrote:

Thanks for your detailed reply! It provides a useful counterpoint.

This is exactly what I mean by not wanting to learn workarounds. I find battling with 'suprising' behaviour and/or bugs in any development environment extremely frustrating these days. For developers coming fresh to D they have to manage to break through this pain barrier to get to the point of productivity. It's a personal thing of mine but I've just had enough of this particular fight. I just want it to work without needing to pull out what remains of my hair while I learn the foibles and failings of the tool. I suspect that the body of D developers at any one time falls into those who are fairly new and haven't yet faced many frustrations, and those who are now experts and instinctively avoid problem areas. I suspect there is a great deal of 'wastage' i.e. developers leaving, between those two levels. Just a suspicion.

Yes, it's likely a communications problem. I don't have the heart or time to come back and try again, so I have to infer the current status of D from the forums. The impression that I have gained, and I suspect the same for other observers, is the one I have recounted.

I don't know why I do it, but I read pretty much all the messages in General and have done for many years. This is the impression I have got.

On Thursday, 18 November 2021 at 11:05:12 UTC, Abdulhaq wrote:

Yeah that makes sense. I think this is more an issue with General than the language though; the debate tends to be centered on controversial new features because that's what attracts attention. I think that's part of why the DLF has dedicated feedback talks with industry users, because otherwise it's very easy for that signal to get lost in the noise.

On Thursday, 18 November 2021 at 10:11:46 UTC, Ola Fosheim Grøstad wrote:

I don't understand you, no-one will pick up D if they have no prior interest. I have a lot of interest in using D because of its expressivity, but won't use it in a commercial environment for the reasons given. It's nothing to do with lack of interest.

It's very illuminating that the two of us, both long term readers of the forums, have opposite opinions of what Walter thinks regarding the direction he is 'heading' to. It says to me that the direction has not been well communicated - which is perhaps one of my main points.

On Thursday, 18 November 2021 at 11:11:20 UTC, FeepingCreature wrote:

Well it's great that they are doing that, but ATM the number of corporates using D and attending DLF meetings is tiny compared to the number that could potentially use D but are holding back due to perceived problems.

Going back to my original question at the top of the thread, do you have an answer to my questions? Is the answer actually well known but it has slipped me by? I think you're saying it's already polished and done, and features tend to work well. So what about the perennial issues, memory management, DLL support, Android/iOS support? Shared? They keep coming up, do I have to spend a few months digging in to D again to see if my experience is now one of 'it just works' on Windows, Linux, Mac? Mobile?

On Thursday, 18 November 2021 at 11:13:05 UTC, Abdulhaq wrote:

No, I didn't mean you. Nothing wrong with commercial developers in small teams. But if Big Business start making D mandatory, then that would not necessarily mean improvements for the existing users.

Being nimble and passionate is an advantage D has over C++. I like that C++ is improving by adding stuff, but the overall cognitive burden is quite large even for highly skilled developers. Unfortunately the leaders of D view C++'s model as successful. Well, it isn't. C++ has had momentum since early 90s. That is the source for C++'s success. It does not confirm their development process!

D1 had one big advantage over C++: lower cognitive burden. I agree with you, D2 needs to be better at that. I think that is in effect what you feel uncertain about regarding bringing it into your workplace?

Or… there is no focus on concrete use cases, so there is no direction to communicate?

I also think you already know the answer to your own doubts. If we look at history, I'd say D2 is stable in 10 years if ever. Because big new features are added while the count of weird deficiencies isn't really changing. So that count will not reach zero…

Someone from the outside with a background in usability, software engineering and software process improvement probably has to enter the scene and break the patterns before you get the focus and clear direction communicated.

I think D could benefit immensely from some outside consulting… :-)

On Thursday, 18 November 2021 at 11:48:28 UTC, Ola Fosheim Grøstad wrote:

Yes, and yes.... but it's worth laying it out so that it is more visible.

On Thursday, 18 November 2021 at 11:32:15 UTC, Abdulhaq wrote:

I mean, I guess the answer for us is that we just don't need any of those.

I don't think D is ready to be used by everyone for every purpose. But I think it's ready to be used by some for some purposes, and has been for a long time. Even by many for many purposes. I think the set of "customers that D is ready for" is badly communicated at the moment, but it is definitely non-empty. (Evidence one.)

PS: I concur with the GC. I think this is one case where D majorly falls down, because it advertises as "you don't need to think about memory management" and if you take that seriously, you will get punished for it as you scale up input. You can't write D like Java, because D's GC is significantly less forgiving, but this is not communicated anywhere.

PPS: 'shared' is one of those features that we've just elected to not touch with a ten foot pole. It does nothing useful for us; I believe I've had rants on the topic. :) Luckily, it's easy to pretend it doesn't exist.

On Tuesday, 16 November 2021 at 08:55:27 UTC, Abdulhaq wrote:

(Assuming you talk about D2 new features compared to D1)

A problem is that D1 to D2 was a major change with several objectives.

The current approach that is to introduce changes, incrementally "DIP driven"-ly,
is more likely to result in finished features. To me, unfisnished D2 "new" features (e.g shared) are more a symptom of the poor managment and the poor methodology that drove D development 10 years ago.

On Thursday, 18 November 2021 at 12:45:16 UTC, user1234 wrote:

I don't think DIPs constitute a method. It also doesn't work all that great for other languages in my opinion. I think even Python is aggregating bloat and complexity now that Guido took the hand of the breaks. Bloat destroys good languages, over time.

You need some kind of structured loop(s), very sketchy:

1. gather information related to key use cases
2. analyse
3. rank and select key problem to be addressed
4. describe problem, ask for solution propositions (many)
5. analyse, evaluate, select
6. make experimental implementations
7. analyse, evaluate, go back to 3-6 if needed
8. make a release strategy (minor/major release)
9. implement, test
10. collect feedback from end users
11. analyse, evaluate, go back to 3-10 if needed
12. polish, deploy, go to 1

That is just for addressing pressing issues, and does not cover strategic planning or quality assurance.