On Wednesday, 3 November 2021 at 23:08:54 UTC, arco wrote:

This is not true. Really persistent myth but easy to prove that it was GPL'd as early as 2002. gdc's predecessor was out by 2003, also GPL licensed.

On Wednesday, 3 November 2021 at 23:13:34 UTC, Adam Ruppe wrote:

But at what point did D become truly usable using open source compilers? GDC was only declared feature complete, supported and merged upstream in GCC 9.0, that is in 2019. Both Go and Rust came with open source, production quality, reference compilers since day 1. It really makes a difference.

Have you got some information about the early GPL'd compiler? My understanding is that DMD only became open source some time around 2014, was there another early project?

On Wednesday, 3 November 2021 at 14:39:19 UTC, zjh wrote:

After getting rid of GC. I Can heavily promote in the QQ group.

Rust is for large company.
D can aimed at Technology Entrepreneurship man.
D can aimed at small companys.
Many other relied on large company's language is Unreliable.
So,Work hard, man.
Unlike others, I think D has a good future.

On Tuesday, 2 November 2021 at 17:27:25 UTC, Dr Machine Code wrote:

I've been playing with D from time to time for, may be, 10 years and here are my observations.
Positive:

• Maintainers like contributions.
• My PRs were reviewed in a timely manner.
• Great thanks to Ali for his book - it helped me a lot.
  Negative:
• If I don't know how to fix a bug then it will likely be never fixed.
• Not enough tutorials how to do things.
• Lack of "best practices" documentation.
• Quite steep learning curve about how to contribute (things might have changed but I remember that compile DMD on Windows was not so simple).
• Unclear roadmap for D/DMD/Phobos.
• Unclear processes for extending standard library - there are bunch of packages that are marked as "candidate for inclusion into std lib" and some of them were not updated for 5+ years.

My personal verdict: I like D and I'll try to bring it into my company (if I won't leave it soon) but only to allow people to play with it.

What I'd like to see in the future:

• Fixing bugs in compiler should be the highest priority. So we can say that stable code is a priority.
• Clear roadmap of what to expect in D/DMD/Phobos in the future.
• Clear process of how new features in are delivered to public.
• Having "preview" mode of new features (e.g. dmd --preview=feature-foo).
• Clear process of how contributors can add new modules into Phobos. For example: someone nominates a library for inclusion, this application is reviewed by stakeholders and might be conditionally approved (they might reject); the condition is that library source code must meet "Phobos code quality" requirements (checks should be automatic) and as soon as this requirement is met, the library is added to std.
• Have a tool that upgrades the code so I don't need to do the same simple thing in thousand places (this is the case for long-living production code).
• Have better support in IDE - I prefer using IDEA, not VisualStudio.

The other thought that I hope might be useful:

There should be a list of "preferred" (not sure that this is the correct word) packages. It should be opt-in list that (a) provides a benefit for the package of being listed as preferred, (b) is a requirement for a package to be promoted into Phobos, (c) the package is tested with 5 (or other reasonable number) last versions of compilers and guaranteed to be working (being built). On the other side adding a package into that list requires some commitment from the author(s): if upcoming version of compiler breaks the build then the author is responsible to fix it, otherwise the package will be excluded. Having such a list will give the public the understanding of what is expected to work and what packages are maintained. In addition to that, DMD/Phobos maintainers can test the changes against the packages in the list to ensure that they are not breaking the most maintained packages.

On Thursday, 4 November 2021 at 02:40:54 UTC, Andrey Zherikov wrote:

Also I think all bugs should be in github, not bugzilla. There should be a requirement what they should have (like compiler version, minimal code that reproduces the bug). Having this, we can have a bot that reproduces the bug automatically (i.e. build provided example). This bot can even validate that the bug still persists with new compiler and automatically close the ones that are not reproduced anymore (for example the bug was fixed by other change).

On Wednesday, 3 November 2021 at 13:10:21 UTC, Ola Fosheim Grøstad wrote:

But how to evaluate the viewpoint with arguments, or the research, that's the problem. It is possible that I didn't pinpoint the problem with most forum theories about language popularity accurately, so I think I should present an example of what I do find convincing. It's not about language adoption, but nonetheless about a complex subject where you can't rebut bad arguments with simple self-made examples. If you can provide that level of argumentation for your favorite language adoption theory, then it's time to take it seriously IMO.

On Thursday, 4 November 2021 at 10:28:52 UTC, Dukc wrote:

And I find that conclusion to be highly suspicious. I can make an argument for why, but it is totally off topic. If you don't agree with an argument, put forth a counter argument/examples or just ignore it.

On Thursday, 4 November 2021 at 10:45:05 UTC, Ola Fosheim Grøstad wrote:

Read it all and consider it. Really do. I don't think you managed to give it serious consideration in 15 minutes. Not saying you should agree with it, but you're losing a lot if you don't consider its arguments.

But no need for the counter argument. First, as you said it would be off topic. Second, I don't want to reveal here what I precisely think of that article besides that it's arguments are generally convincing. Third, if that article does not convince you no way I'm going to.

Of course.

On Thursday, 4 November 2021 at 10:59:42 UTC, Dukc wrote:

I have not interest in the topic…

But please understand that in fields such as software process improvement, educational research and design, the most useful ideas are not backed by "hard data".

Most papers on education and design are anecdotal in nature, but that does not mean you should ignore them.

This is the nature of the setting as the context is not stable and the system dynamics are complex.