On 4/14/2019 1:01 AM, Mike Franklin wrote:
> For those who don't know and want to help Walter out, the list is here:  https://forum.dlang.org/post/p6oibo$1lmi$1@digitalmars.com


And some examples of what I'm trying to accomplish:

https://github.com/dlang/dmd/pull/9510
https://github.com/dlang/dmd/pull/9527

Like:

    super(ident);
    this.loc = loc;

replaced with:

    super(loc, ident);

https://github.com/dlang/dmd/commit/033879a6b733aa121e354b4399ecdb7fa59cc923#diff-e9eb240d8785a5470c85ca78b4145383R125

This is more than just cosmetic. The first method cannot be used to build a const object, the second can.

Also, upending the code base with large changes and reorganizations is not likely to get incorporated, and be aware that people can and do disagree strongly about what constitutes improvement and what doesn't. When in doubt, do a small version and see how it goes.

On Sunday, 14 April 2019 at 08:21:38 UTC, Walter Bright wrote:
> Also, upending the code base with large changes and reorganizations is not likely to get incorporated, and be aware that people can and do disagree strongly about what constitutes improvement and what doesn't. When in doubt, do a small version and see how it goes.

The DMD codebase suffers from systemic misorganisation, both on the massive function level, and the complete lack of organisation of the files in the source directory. Small change are never going to fix those issues.

You are trying to find a local optimum, we need to find a more global one, and that involves doing things like https://github.com/dlang/dmd/pull/9511#discussion_r270614236

On 4/14/2019 1:33 AM, Nicholas Wilson wrote:
> The DMD codebase suffers from systemic misorganisation, both on the massive function level, and the complete lack of organisation of the files in the source directory.

We're not going to get anywhere litigating that here. Defer to DConf.

> Small change are never going to fix those issues.

There's an lot of low hanging fruit that needs doing. I know it's not as exciting or fulfilling as giant reshuffles, which is why I wind up doing it.

On Friday, 12 April 2019 at 07:35:05 UTC, Tofu Kaitlyn wrote:
> 
> I put on my resume that I like D and every interview I get asked about it, having to explain what D even is because they have never heard of it. I have never seen a job posting listing D.

We are still hiring programmers - including to write D - in London and HK (could do Singapore also).  We pay well and we have interesting people. I have said I will pause after ten more people, but it's likely to be more than that in the longer run.   Drop me a line if you like -  laeeth at kaleidic.io

The people that talk about what they are doing in public - it's a particular subset and that leads to a distorted perspective sometimes.

Have you noticed also that the largest commercial users of D don't spend much time in the forums?  My guess is it's not because they don't want to, but just because they don't have time.

On Sunday, 14 April 2019 at 05:35:41 UTC, silentwatcher wrote:
> On Sunday, 14 April 2019 at 04:48:00 UTC, Walter Bright wrote:
>
> i think there are some other things you don't understand yet.
> go back in this thread and read what people think about D and why they think it should be forked.
> you guys made lab experiment of it instead of finding out what the real world programming needs. why are people dissatisfied?
> stop finding all those mediocre things/solutions like help here or do that. i admire the gdc project but i would not use it.
> my experience is, that programmers (at work) look at D and are afraid of using it. to large, to many features that are nice but nobody needs, web like syntax, the GC and after reading in the forum, they are even more afraid to use an unstructured experiment.
> then there no tools, libraries etc., just visuald and that is the only reason why some try D for a short time.
> well now will tell us again - write the tools/libraries, but in a business you don't have the time to do that. all those things come with c++, c# or java. why should i invest time and money into D?
> no time to experiment.
> i like D, followed it for a long, long time, but it turned into a moloch. some of us still use D1 for little tasks. i hope somebody takes D1, strips the gc, adds templates, cleans up this mess and forgets about the rest of the bloat.

Maintenance constitutes the largest part of the total cost of ownership of code.  In other words when the code is 'finished' then you have made only a down-payment.

If you don't want to invest your own time into working with D, then I don't think you should.  I wouldn't dream of trying to change your mind.  But there's clearly some ambivalence there because why else would you be posting.

The most important aspects of D might be the values and good taste.  When I decided to learn D, there was nothing calculating about it - I just wanted to find a language I could stand to program in because otherwise I wouldn't be doing much programming as life is too short and it's not my only interest.  One thing led to another and working from my home office led to consulting and then being in charge of technology and part of research for a 150 odd person firm.  I don't know, and it's a longer story but probably that wouldn't have happened if I hadn't been drawn to D.

Turns out also that the values that characterise the language and the community are peculiarly suitable for the commercial context of what's still an early stage firm that has grown very quickly.

It's true that there's a high barrier to entry in the beginning with D - much better now, but if you are put off by discomfort and needing to figure things out for yourself then it's going to be quite a tough experience.  D doesn't place a high value on being accessible and if that's what is important then maybe somewhere else would be a better fit.  On the other hand it's also a moat that constitutes a filter - as it happens commercially people who are okay with being uncomfortable, with having to figure stuff out, are quite a good fit for our business, especially at the stage we are at.

It's a really very big world, not like it was when I started to learn to program in 1983.  Most software is developed by private organisations that don't talk much about what they are doing.

I never thought that D would be considered a  substitute for Ada and Pascal but that's been the case in one quite interesting commercial application for ship design.  Similarly for us D - and a little functional domain specific language written in D - has been a replacement for Excel spreadsheets and SQL reports.

Brutal upfront sometimes, but the upfront emotional experience is the least important part of the cost of developing and maintaining software.

The productivity experience has a different profile too - you spend time at different points on different things, but looking at our own experience from a commercially perspective I really don't think it would have been possible to be as productive taking a different route.

There are quite a lot of libraries now - 1500 last I checked on code.dlang.org

Calling python libraries is easy and calling C libraries using DPP is also easy.  DPP keeps improving and in time it will handle much more of C++ headers.

Yes - the tolerance for experimentation is an important question.  In firms where there isn't much of a tolerance for experimenting and for some of those experiments to fail then it's probably not the right environment to use D.  But I think the more interesting places to work are quite different.

On Sunday, 14 April 2019 at 09:42:01 UTC, Laeeth Isharc wrote:
> Brutal upfront sometimes, but the upfront emotional experience is the least important part of the cost of developing and maintaining software.

100% agree.

That's exactly my experience, the upfront payment of creating D software was sometimes brutal the first year - even for a seasoned D programmer - and afterwards it yielded dividends in lower Cost Of Ownership quite evidently.

And a lot of it is thanks to DUB/SemVer I must say, without it I wouldn't even dare maintaining that much projects else, and another big part is thanks to the community that comes with a particular culture. It really changes your perspective over time.

It's very important to keep the complexity down (not only code) in an organization and D is an integral part of this **because it scales from disposable code to production code**.

My _solo_ organization has 62 projects in 4 years, all in D (dub.json):
- 2 are open-source to eventually keep costs down, if other companies have similar views eventually,
- about 20 of which have to be maintained privately with  (Cost of Ownership),
- 27 are only maintained lazily when needed, they are absolutely needed for experimentation
- about 15 were thrown away and won't ever have to be maintained

If the rate of maintained-LOC _production_ was higher than that(it's hard not to produce code), it would lead to a worse outcome in the exponential curve of software size.

The future of D is perhaps more shared costs between D users, hiring reputed library designers, with a shared understanding that value must flow back to the D Foundation.

Only this can solve software size.

On Friday, 12 April 2019 at 07:35:05 UTC, Tofu Kaitlyn wrote:
> Sorry for that title, but this is something I have been thinking about for a while...
>
> I honestly feel like D is a failure. I kinda just wanted to vent about it and see what other people think.
>
> I have been using D since around 2012 or 2013, instantly fell in love, use to post on the forms a lot under the name Tofu Ninja. I was convinced D was the future but since then I have become disheartened. The biggest thing that makes me feel like this is that in the 7 years I have been using D I literally have never met another programmer IRL who has even heard of it. I put on my resume that I like D and every interview I get asked about it, having to explain what D even is because they have never heard of it. I have never seen a job posting listing D. Never see any projects pop up on /r/programming using D. It feels like to the rest of the programming universe, D doesn't even exist. Sometimes I see threads on reddit like "what's your favorite programming language" and I always look for D but never find it.
>
> And honestly I don't think that is going to change. I feel like D has failed.
>
> I duno... what do yall think? Is D going to somehow explode in popularity in 5-10 years? Am I missing some part of the picture? Or am I right and if so what can be done about it?

That lack of popularity, combined with the lack of corporate backing, may precisely be what allowed D to exist at all, as it is. I personally enjoy D both for paid work and for private projects.

Maybe there is a psychological explanation for the debate here - please bear with me - just speculating:

 * once the D beginner passed a few obstacles (how do I get a decent stack trace?)...

 * ...and enjoyed the full power of D's core features for a few years (runtime performance and stability, combined with high expressiveness, especially sprinkled with a limited amount of CTFE code, here and there)... pure bliss, probably where I am at...

 * ...things are going so smooth that tolerance to frustration steadily lowers, without one noticing it...

 * ...then the D user hits the "things-that-break-all-the-time", mostly more advanced features, and suffers, especially because of the blissful experience enjoyed so far, so that he takes the time and energy to complain here - actually a positive sign - instead of silently leaving the D community.

On the other side, Walter & Andrei point the lack of manpower, one cannot just complain and expect something to change. But since this type of debate pops up every now and then on the forum, there may well be some part of truth in it.

I warn against forking D - the already limited manpower would fragment, and most likely the result would be something like the LISP family of language, great fundamental expressive power, but many groups of people reimplementing everything from scratch, each group using its own variant.

My two cents of what could be possible on the short term, with limited amount of work:

(1)

Keep complaining! I mean it. But then please take the time to split into precise complaints, e.g. for each precise topic, write a text precisely describing the complaint on GitHub or similar, at best with a few suggestions for remedies, then point at it here, and see how many stars it gets.

This requires zero work from D's main contributors, only from the complainers, and does not clutter D's issue tracker, and could help to see how popular each specific complaint is.

(2)

On the other side it could be worth considering marking *language* features as experimental - or if it is already done, making it more obvious. When I look in Google for "dlang experimental features", I get mostly library stuff, not language features:
https://www.google.com/search?hl=en&q=dlang%20experimental%20features

This would help a lot in the context of long-term paid work, to decide whether to use a particular language feature of D, or not.


On the longer term, I see two things that would really help:

 * compilation that takes more advantage of having multiple cores,

 * more recurring sponsoring for the D fondation, without strings attached.

I hope this helps,
Guillaume

On Sunday, 14 April 2019 at 08:47:18 UTC, Walter Bright wrote:
> On 4/14/2019 1:33 AM, Nicholas Wilson wrote:
>> The DMD codebase suffers from systemic misorganisation, both on the massive function level, and the complete lack of organisation of the files in the source directory.
>
> We're not going to get anywhere litigating that here. Defer to DConf.

I plan to ;)

> > Small change are never going to fix those issues.
>
> There's an lot of low hanging fruit that needs doing.

Be that as it may, I'm interested in bang for buck comprehensibility and navigability improvements. The low hanging stuff you're doing, while nice, is rather lower down my, and I'm sure many others, list of perceived bang for buck improvements.

On Sunday, 14 April 2019 at 04:48:00 UTC, Walter Bright wrote:
> On 4/13/2019 2:35 PM, Mike Franklin wrote:
>> Lately, I find the things that Walter is doing in DMD to be a very low priority compared to all of the bugs in bugzilla for which only he is qualified to fix.  I wish he'd stop refactoring code and start fixing bugs, but, maybe his refactorings of late are laying some groundwork for more important stuff.
>
> I gave a list a couple times on technical debt in DMD, and nobody picked up the flag. So I've been doing it.
>
> If this is let go for too long, the code becomes unmaintainable.

Everyone is busy doing Good Work so the only who can do Great Work must do Right Work.

On Sunday, 14 April 2019 at 09:42:01 UTC, Laeeth Isharc wrote:
[...]

> Yes - the tolerance for experimentation is an important question.
>  In firms where there isn't much of a tolerance for experimenting and for some of those experiments to fail then it's probably not the right environment to use D.  But I think the more interesting places to work are quite different.

That's all good and well and I sincerely congratulate you on your success. But what I see is the following divide: those who say that D works for their business usually use it for very specific purposes with a custom made ecosystem they've built up over the years (as I did too) maybe bound to a particular version of dmd or D1, and it's often for in-house purposes, e.g. analyzing the stock market or optimizing internet ads or machine learning. D is of course a good tool for that kinda stuff (as is Lisp or Scala). But once you have to step out of your biotope things get hairy. Once customers depend on your software directly (as in: installing it directly on a machine, interfacing with it via plug ins or accessing an API on your web server), you're out in the wild with D as far as tooling and stability (breaking changes) are concerned. In other words, D is good for fenced off software that is built for very specific purposes. When it comes to "general purpose", however, it's a different story all together. This is what I'm trying to convey.

D was a personal success for you, good, but I'm sure in a few years people will tell similar stories about Crystal, Nim and whatnot. When you started using D it had the edge over other languages in some respects, but other languages have caught up and offer ease of use on top of that. This is what doesn't register with the D community. Some users live happily in their respective self-made D biotopes, while others want more, a broader focus (and they mean well as they want D to be suceessful in the world not just in niches). These are the two factions, and it's the biotope faction that dominates the Foundation and the forum, indeed the "biotopeism" in the community is so far advanced that people have stared to fork D, the ultimate stage of "Ok, I'll do my own thing.", which is of course only a logical consequence of the insular mentality that permeates D culture. You encourage people to do it themselves, they will finally fork.

As there is no way the two factions can communicate with each other, there is only one logical consequence. The faction with the broader focus (like myself) wanders off and what remains are the die hard users who are happy in their biotope, so D will remain a niche language and, of course, there's the danger that some people will break off, fork D and add to the general chaos (and you may read questions like this on Stackoverflow: "Which D should I use? There are N implementations. Dragon, Volt, BetterD, CleanD, SaneD...").