named arguments, string interpolation, please stop. (page 4)

On Thursday, 11 January 2024 at 18:20:29 UTC, H. S. Teoh wrote: > It's always more exciting to work on new features, to invent the next thing that will revolutionize D. Improving the quality of existing features? Too boring, too tedious, and totally unrewarding. Guess what gets done, and what doesn't. > It looks like management need to start saying no. And do bad if some people quit. The alternative is the whole thing stagnate of sink.

On Thu, Jan 11, 2024 at 06:24:46PM +0000, deadalnix via Digitalmars-d wrote: > On Thursday, 11 January 2024 at 18:20:29 UTC, H. S. Teoh wrote: > > It's always more exciting to work on new features, to invent the next thing that will revolutionize D. Improving the quality of existing features? Too boring, too tedious, and totally unrewarding. Guess what gets done, and what doesn't. > > > > It looks like management need to start saying no. And do bad if some people quit. The alternative is the whole thing stagnate of sink. That's what the aforementioned company did, and they went under. The root of the problem lies in their policy of hiring only the best people, people who are not interested in doing the menial, but necessary work. T -- In order to understand recursion you must first understand recursion.

On 1/11/24 19:02, deadalnix wrote: > ... > There is a design mistake I see people making again and again, and it goes way beyond software: they design for what their current most satisfied users want. This is perhaps a mistake if your primary goal is to increase your user base, but on the other hand popularity is mostly a function of marketing and inertia, technical merit is of lesser importance. Keeping your current users happy is therefore also important. > But that's really dumb, these people are already happy with the product! I think it's a bit more complicated than that in the context of an open source project. Those people can afford to use a project whose potential has not been fully realized and they can actively participate in shaping the product, which is part of the value proposition. You are not going to be able to keep people engaged enough to fix long-standing tricky issues that do not impact them a lot if they cannot even make an impact on something they care about that would be simple to implement. > Anyone in this forum fall into that bucket, by the way. You got to observe how D is used int he wild by people not frequenting this space. Well, that is pretty hard to do. I don't know most of those people, so this is not something that is actionable to me. The subset that I do know prioritize similar things to be fixed or improved that I do. > What problem do they encounter? What frustrates them? What make the stop using it? These are the people you want to design for if you want to actually improve the product. In any case, I think everything on your list (and probably anything further that will come to mind) also improves the experience for existing users. They are just maybe not the blockers they had been in your experience for everyone and/or they are hard to fix due to technical debt.

On 1/11/2024 5:07 AM, deadalnix wrote: > These are just simple thing that I have on top of my mind, but there are a ton more. Thanks for taking the time to write this list. I would like to see all of your issues, though! Let's make a list and then have a bugzilla entry for each of them, so we can start picking them off. > such as @nogc, has been a productivity disaster I don't really understand this. Just don't use @nogc?

January 11, 2024

Re: named arguments, string interpolation, please stop.

Posted by Don Allen
in reply to deadalnix

Permalink

Don Allen

Posted in reply to deadalnix

Permalink

On Thursday, 11 January 2024 at 13:07:52 UTC, deadalnix wrote:

I have been in the D community for a very long time. I have seen D successfully deployed in companies, and the pain points associated with it. I have seen D fails to catch on in companies and why that is has well.

Let me tell you, none of this has anything to do with feature D has or does not have. At large, D has more features than most languages.

D chasing the next feature like a crack addict chase his next dose. With the same level of success.

The main problem people face with D in the real world are almost exclusively of the implementation kind. The list is endless (and yes, there are many bugs reports about these things). I recently made a post about how the OOP implementation is extremely sub-par vs what people in OOP languages would expect. no change of the language required to fix. See here: https://forum.dlang.org/post/hteuczyclxajakrisxjd@forum.dlang.org

But if you are not convinced, here are a few more example of thing being implemented wrong or existing feature not working right:

D runtime is unable to see thread started manually (for instance with pthread-create) leading to all kind of bizarre behavior.
Template symbols are generated as weak, which prevents inlining (!).
Pretty much no cross module inlining, making helper function absurdly costly.
scope(success) generates exception handling code.
D goes virtual by default for class methods, but LTO is unable to finalize (contrary to every other languages going virtual by default).
The GC implementation is nowhere close to where it needs to be.
in contracts are dynamically bound (and in the callee) instead of statically bounds and in the caller.

These are just simple thing that I have on top of my mind, but there are a ton more. I have seen some of the above cause projects to fail. None of them require any significant language change.

There is nothing features like string interpolations or named argument can bring to the table that could pay for the implementations problem of existing feature. The cost benefit analysis is just a big L for D: the fail to address the main pain points, while causing massive breakage in the tooling ecosystem (syntax highlighting support in 3rd party IDE, code formatter, etc...), and it cost real time and resource to upgrade these, or come at the cost of other quality of life stuff nullifying their benefit (for instance, the quality of syntax highlighting for D has degraded significantly in vim and sublime text over the past few years).

In addition, some recent D features, such as @nogc, has been a productivity disaster int he wild. While the impact might not be felt on smaller codebases, the infectious nature of the feature makes large codebase significantly harder the refactor than they used to be.

Each time we take steps in that direction, D becomes a harder sell.

While I don't have a long history with D or deep knowledge of the implementation details, the thrust of this message sounds right to me.

The calls I've seen recently for more language features strike me as misguided. As the above says, D is already a big language, lotsa features. It's also well-documented, compared with what I've seen with comparable languages, even Rust, whose "affectionately named" (seriously?) Book is simply awful, in my opinion.

I think Walter and Co. need to create a plan to address D's real weaknesses, e.g., tooling, issues with Phobos, and problems with the implementations of existing features. Lack of features is not among them, in my opinion.

This should be discussed with this community and we should, in turn, avoid the temptation to derail the Big Picture discussion by descending into talk of technical details prematurely. Make your best plan first. Then you can talk about how to implement it. This may cause an iteration back to the plan, adjusting with what you learned by considering implementation problems.

I'm, in effect, supporting Walter's preference for specifications, but at an even higher level than a particular DIP. I also generally support Walter's tendency to say "no" (perhaps improving communication of his reasoning), because it's consistent with what I'm advocating here. Make sure what you have is at a high professional level before moving on to the next great thing.

I don't think D's future lies in trying to be more dazzling than the competition. I think being better engineered (Walter's strength) and better crafted are the dimensions that suit this project. Think about products like Toyotas or Seiko watches. While both companies have produced some highly innovative products, we mostly know and admire them because their main-stream stuff Just Works. I think of D in that category. I believe that if the project focuses on this and people start to discover that in addition to writing programs in D being a huge improvement over wrestling with C or C++, all the tooling is there and of good quality (I'm really looking forward to the new dfmt), so that the D software-development experience, end-to-end, is as problem-free as possible. People don't want to fight with their tools; they want to use them to accomplish their goal. Serve that and you've got a winner.

On 1/11/2024 6:47 AM, zjh wrote: > On Thursday, 11 January 2024 at 14:34:57 UTC, jmh530 wrote: > Its a >> tricky organizational problem. It's hard to have high quality/standards with a lot of contributors. > > This is an organizational issue, how to arrange `manpower, time, and tasks`? It's a repeating occurrence that people often ask me what they can work on. I provide a list of A,B,C,D that would be of great benefit. They do Q, because Q interests them more. In order to assign tasks, one needs to actually employ people, as I cannot assign anything to volunteers. (Some of our volunteers do do things that aren't much fun, but need to be worked on. Those are our most valued contributors.)

On 1/11/2024 9:52 AM, deadalnix wrote: > I could have added 10x more by spending a little more time. For instance, demangling support for various debuggers would be tremendously valuable. I would appreciate you spending the time on that list. Eliminating all those little rocks in one's shoe is very worth while. I can't do anything about them if I don't know what they are. There is probably some low hanging fruit that we can easily take care of. We just have to know what they are!

On 1/11/2024 9:56 AM, deadalnix wrote: > But that doesn't work. If a GC cycle kicks in in between the thread starting and you having the chance to attach it, you may end up collecting live objects. This is what killed the project, BTW. > > Having thread that are not managed by the GC is a fine thing to want, but you got to do it the other way around by detaching the thread from the GC. If you could pseudocode a solution, we can add it to the bugzilla issue. Threading issues are not something I have much expertise in.

On 1/11/2024 9:45 AM, max haughton wrote: > Most of the issues with tooling in this sense when things change is purely just brought about because things are too separated. Along those lines I am planning to try to merge in all the tools as they use the dmd frontend more and more. The current layout of dfmt et al, and the compiler/s themselves is fundamentally biased towards making this kind of change difficult, fix that and there would be a lot less to complain about. On my end, I have fixed the lexer/parser so they are independent of the rest of the compiler. This is targeted towards enabling other tools to deal with D code.

Forums