www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Why Phobos is cool

reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
Phobos sometimes gets a bad name around these parts, but actually it's
pretty cool (in spite of well-known warts).  One of the cool things
about it is the batteries-included philosophy that used to be its
guiding principle.  Over the course of my usage of D, the following have
stood out as being particularly convenient when I needed it:

1) std.bigint: one time, I was working on a quadratic irrational
arithmetic module, and pretty quickly discovered that numerical overflow
was a problem that cropped up pretty often.  Or rather, I was seeing
what I *thought* was caused by arithmetic overflow, and wanted to be
sure.  Solution?  Easy: templatize the coefficient type, import
std.bigint, and within several minutes, I have a working implementation
that can support arbitrarily large coefficients -- with which I not only
confirmed that the observed problems were caused by arithmetic overflow,
but also obtained a working solution simultaneously.  Win!

2) std.numeric.poly: another time, I had to work with evaluating a bunch
of polynomials, and specifically, with evaluating their roots quickly
and accurately.  I could roll my own, poorly, and get results that may
or may not be highly-skewed by accumulated errors... or I could use
std.numeric.poly to get a reliable evaluation of the polynomial, and,
better yet, use std.numeric.findRoot to compute roots with the
confidence that the value I get will have as small an error as is
possible within the constraints of built-in hardware floats. Plus, this
saved me tons of development and debugging time to roll my own solution.
Win!

3) Just today, I needed to implement a fast Fourier transform. Not
expecting this to be in Phobos, I was glancing over various algorithms
to decide which one suited my use case best and is easy enough to
implement quickly. And then I discovered std.numeric.Fft, already done
and nicely-packaged and ready to use.  Total win!!

Seriously, D + Phobos is cool beans.  Yes it's not perfect -- the
language has its fair share of dark corners, WATs, and Phobos has its
share of poorly-designed APIs and outdated modules.  But seriously, a
lot of what's currently there is pretty darned cool, and we shouldn't
let all the bad stuff cloud our appreciation of just how cool it already
is.


T

-- 
If the comments and the code disagree, it's likely that *both* are wrong. --
Christopher
Jun 24 2020
next sibling parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Wednesday, 24 June 2020 at 21:37:37 UTC, H. S. Teoh wrote:

 Phobos sometimes gets a bad name around these parts, but 
 actually it's pretty cool (in spite of well-known warts).  One 
 of the cool things about it is the batteries-included 
 philosophy that used to be its guiding principle.  Over the 
 course of my usage of D, the following have stood out as being 
 particularly convenient when I needed it:

 1) std.bigint: one time, I was working on a quadratic 
 irrational arithmetic module, and pretty quickly discovered 
 that numerical overflow was a problem that cropped up pretty 
 often.  Or rather, I was seeing what I *thought* was caused by 
 arithmetic overflow, and wanted to be sure.  Solution?  Easy: 
 templatize the coefficient type, import std.bigint, and within 
 several minutes, I have a working implementation that can 
 support arbitrarily large coefficients -- with which I not only 
 confirmed that the observed problems were caused by arithmetic 
 overflow, but also obtained a working solution simultaneously.  
 Win!

 2) std.numeric.poly: another time, I had to work with 
 evaluating a bunch of polynomials, and specifically, with 
 evaluating their roots quickly and accurately.  I could roll my 
 own, poorly, and get results that may or may not be 
 highly-skewed by accumulated errors... or I could use 
 std.numeric.poly to get a reliable evaluation of the 
 polynomial, and, better yet, use std.numeric.findRoot to 
 compute roots with the confidence that the value I get will 
 have as small an error as is possible within the constraints of 
 built-in hardware floats. Plus, this saved me tons of 
 development and debugging time to roll my own solution. Win!

 3) Just today, I needed to implement a fast Fourier transform. 
 Not expecting this to be in Phobos, I was glancing over various 
 algorithms to decide which one suited my use case best and is 
 easy enough to implement quickly. And then I discovered 
 std.numeric.Fft, already done and nicely-packaged and ready to 
 use.  Total win!!

 Seriously, D + Phobos is cool beans.  Yes it's not perfect -- 
 the language has its fair share of dark corners, WATs, and 
 Phobos has its share of poorly-designed APIs and outdated 
 modules.  But seriously, a lot of what's currently there is 
 pretty darned cool, and we shouldn't let all the bad stuff 
 cloud our appreciation of just how cool it already is.


 T


I suggest checking http://mir-algorithm.libmir.org/.
Ilya has been doing a truly amazing job at both developing, 
maintaining and optimizing this library.
Also he has put a hard focus on memory allocators,  nogc and 
betterC (for exposing libmir to C and C++ users and also for 
scripting languages like Python or Julia).
AFAIK his work has been sponsored by Symmetry, so I suppose 
libmir gets a lot of internal use there.

Meanwhile, if you look at std.numeric, for past several years, 
basically all contributions but a few have been just around basic 
stuff like code style, imports and fixing a few compile errors in 
generic code.

Phobos is dead. There haven't been any new modules since ~2016. 
Actually the last one (IIRC) was std.experimental.ndslice, which 
Ilya contributed and then removed (1-2 releases after) from 
Phobos to start libmir.

Since std.experimental.allocator was added to Phobos circa 2015, 
there hasn't been a single Phobos or Druntime module using it 
(ndslice and checkedint don't count). Many packages on 
code.dlang.org enthusiastically embraced 
std.experimental.allocator only to get burned a few dmd releases 
after as Phobos doesn't follow SemVer. The solution? Many of the 
most popular OSS D apps libraries (I can only comment on those) 
transitioned to using the Dub fork: 
https://github.com/dlang-community/stdx-allocator. How does it 
help? Well, OSS D libraries can't control the compiler that their 
users are using. For example, vibe.d tries to support the last 5 
major versions of dmd/ldc, and Dub the last 15+ major versions. 
This means they can't depend on std.experimental.* as there's no 
telling what kind changes can happen for such a large timespan. 
Instead they can stick a particular version of 
https://code.dlang.org/packages/stdx-allocator in their 
dub.{json,sdl} file and be sure that it won't suddenly break 
their code.

The sooner we realize this and start collectively working on 
improving Dub and code.dlang.org, the better. Yes, Dub is not a 
great build tool. And so what? Most great build tools were not so 
great in their infancy. I doubt Scons was much better in 1999. If 
people continue avoiding Dub for whatever reason it won't get 
better by itself.
There's no reason why Dub can't expose a lower-level DSL for 
precise target dependency graph building. It's just a matter of 
people making a sustained effort in contributing one.

The Rust community has realized that a slim standard library + a 
solid package manager is the way to go. Rust is also backed by 
Mozilla. And so what? I seriously doubt that more than 5-10% of 
all of the 42k packages on https://crates.io/ were created by 
Mozilla employees. Instead the core Rust team realized that they 
can't build everything by themselves, and focused on helping the 
community scale by putting a concentrated effort on Cargo (their 
version of Dub).
Jun 24 2020
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Thursday, 25 June 2020 at 06:52:05 UTC, Petar Kirov 
[ZombineDev] wrote:

 The sooner we realize this and start collectively working on 
 improving Dub and code.dlang.org, the better.


FYI for anyone interested, this has been a topic of discussion at 
the past two quarterly foundation meetings. We have outlined a 
path forward, but we just need to secure funding. We're currently 
awaiting news on that front. Whether the news is good or bad, 
I'll be able to announce the plans shortly after I hear it. If 
it's bad news, we'll likely have to seed the initiative with the 
HR fund and depend on the community to keep it going long-term 
until we get an alternative solution. I'm hopeful it won't come 
to that.
Jun 25 2020
parent Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Thursday, 25 June 2020 at 09:08:37 UTC, Mike Parker wrote:

 On Thursday, 25 June 2020 at 06:52:05 UTC, Petar Kirov 
 [ZombineDev] wrote:

 The sooner we realize this and start collectively working on 
 improving Dub and code.dlang.org, the better.


 FYI for anyone interested, this has been a topic of discussion 
 at the past two quarterly foundation meetings. We have outlined 
 a path forward, but we just need to secure funding. We're 
 currently awaiting news on that front. Whether the news is good 
 or bad, I'll be able to announce the plans shortly after I hear 
 it. If it's bad news, we'll likely have to seed the initiative 
 with the HR fund and depend on the community to keep it going 
 long-term until we get an alternative solution. I'm hopeful it 
 won't come to that.


Thank you for the update Mike, I appreciate it.

I think even the fact that this has been the topic of discussion 
for the those meetings is a good news in itself!

I haven't been able to contribute to D in the past 1-2 years as I 
would like to, but before that, at some point, I was in the top 3 
people in terms of number of pull request code reviews, so back 
then I had very good visibility of the how things were going.

I'm currently the CTO of a small startup, and needless to say, 
I'd very much like our team to use D for more things, but the 
biggest blockers for us is that the competition (Rust, Go, 
TypeScript) has much better developed ecosystem. Strangely for 
many, IDE support is not important for us. (And especially given 
D's metaprogramming capabilities, I haven't had high expectations 
anyway :D)
Most of the libraries that we need will never be part of Phobos. 
If the third-party library & package ecossytem doesn't catch up 
with Rust or Nim, using D is just not going to be practical for 
the core of our business.
Jun 25 2020
prev sibling next sibling parent reply Avrina <avrina12309412342 gmail.com> writes:
On Thursday, 25 June 2020 at 06:52:05 UTC, Petar Kirov 
[ZombineDev] wrote:

 Since std.experimental.allocator was added to Phobos circa 
 2015, there hasn't been a single Phobos or Druntime module 
 using it (ndslice and checkedint don't count). Many packages on 
 code.dlang.org enthusiastically embraced 
 std.experimental.allocator only to get burned a few dmd 
 releases after as Phobos doesn't follow SemVer. The solution? 
 Many of the most popular OSS D apps libraries (I can only 
 comment on those) transitioned to using the Dub fork: 
 https://github.com/dlang-community/stdx-allocator. How does it 
 help? Well, OSS D libraries can't control the compiler that 
 their users are using. For example, vibe.d tries to support the 
 last 5 major versions of dmd/ldc, and Dub the last 15+ major 
 versions. This means they can't depend on std.experimental.* as 
 there's no telling what kind changes can happen for such a 
 large timespan. Instead they can stick a particular version of 
 https://code.dlang.org/packages/stdx-allocator in their 
 dub.{json,sdl} file and be sure that it won't suddenly break 
 their code.


This gets brought up quite often. Breaking changes doesn't seem 
to be a concern. I'm not even talking about the DIP changes that 
are going to cause breaking changes. There's just compiler 
changes that break codes for almost every new release. There 
doesn't even need to be a big change, just slowing down the 
releases would help. So there's less versions you have to deal 
with to support a longer term of time.
Jun 25 2020
parent Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Thursday, 25 June 2020 at 11:09:04 UTC, Avrina wrote:

 This gets brought up quite often. Breaking changes doesn't seem 
 to be a concern. I'm not even talking about the DIP changes 
 that are going to cause breaking changes. There's just compiler 
 changes that break codes for almost every new release. There 
 doesn't even need to be a big change, just slowing down the 
 releases would help. So there's less versions you have to deal 
 with to support a longer term of time.


Breaking changes are not a problem. As someone who was very 
involved in pull request reviews in the past, I can definitely 
say that outside of std.experimental, for the past few years we 
have been relatively rigorous (compared to say 5 years ago), and 
almost every breaking change that we were aware has first gone 
through a deprecation process.

So breaking changes are not a problem by themselves. The problem 
is how they're delivered. The problem is that Phobos is 
distributed as part of each compiler release. You can't keep 
using an older version of Phobos if you need the new platform 
support of say LDC 1.22.0. And vice versa, if you need a new 
Phobos function, but there's a compiler bug preventing you from 
upgrading you're again stuck between a rock and a hard place.

And what frustrates me the most is that this is an already solved 
problem technically, it's just that the community doesn't want to 
reach consensus on using and investing in improving Dub. Today, 
in all of our projects at work, the version of TypeScript that we 
used is managed by SemVer. The version of all our dependencies is 
also managed by SemVer. If I want to use the latest language 
features of TypeScript, I'm not afraid to upgrade it, as each of 
my dependencies can use whatever TS version they want (again 
following SemVer), and so on.
Jun 25 2020
prev sibling next sibling parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Thursday, 25 June 2020 at 06:52:05 UTC, Petar Kirov 
[ZombineDev] wrote:

 On Wednesday, 24 June 2020 at 21:37:37 UTC, H. S. Teoh wrote:

 [...]


 I suggest checking http://mir-algorithm.libmir.org/.
 Ilya has been doing a truly amazing job at both developing, 
 maintaining and optimizing this library.
 Also he has put a hard focus on memory allocators,  nogc and 
 betterC (for exposing libmir to C and C++ users and also for 
 scripting languages like Python or Julia).
 AFAIK his work has been sponsored by Symmetry, so I suppose 
 libmir gets a lot of internal use there.

 [...]


I know that we are quite few on this side, but IMHO a well shaped 
standard library has advantages over a sparse ecosystem of 
independent library ...

Anyway, if we can, we try to stick with Phobos, as long as we 
don't have a particular problem to solve that needs an external 
library: recent example, Martin std.io or SumType instead of 
std.variant ...
Jun 25 2020
parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Thursday, 25 June 2020 at 12:13:21 UTC, Paolo Invernizzi wrote:

 I know that we are quite few on this side, but IMHO a well 
 shaped standard library has advantages over a sparse ecosystem 
 of independent library ...


Who says that this is a binary choice? And also, the way you 
fraise it it's obvious that say Flutter is better choice than 
React as everything is very tightly integrated and you could 
build your whole app without reaching for third-party code. Also, 
it's obvious that in terms of trust, it's better to rely on the 
diligence of the upsteam development team, than random strangers 
from the internet.

But what if 90% of the code my team needs has no place in Phobos? 
We already have to rely heavily on third-party packages. Yes 
there are a lot of risks and we try to be careful, but we have no 
other choice. We could spend years reiventing the wheel 
(high-quality code that already exists in other languages), or we 
could focus on delivering products to our users based on the 
already existing ecosystem in other languages. Well, a choice 
would exist if we had an unlimited budget, but given that we're 
not as lucky, we can only use other languages for our projects 
currently.

Technically, phobos is actually already on Dub 
(https://code.dlang.org/packages/phobos), so in the future 
nothing could prevent you to continue using it, but you would 
just get it from there and not from the compiler distribution 
archive. It's the same code, made by the same people, just with a 
different distribution model.

The way I see things is that we as a community need to focus on a 
vetted, well shaped collection of libraries.
We need to have process where third-party libraries are able to 
gain broader support and join dlang-community. Also we need 
dlang-community to have a healthy number of people who actually 
maintain the code.
We need the leadership to realize that investing just in dmd, 
druntime and phobos is necessary, but very insufficient.
W&A need to stop pretending that Dub doesn't exist. I feel that 
unless we embrace using code.dlang.org as method of distribution 
of everything that's currently part of the compiler archive, 
Dub's limitations will never be addressed and from that the 
broader community will suffer.


 Anyway, if we can, we try to stick with Phobos, as long as we 
 don't have a particular problem to solve that needs an external 
 library: recent example, Martin std.io or SumType instead of 
 std.variant ...


See, some of the problems in Phobos already have a good solution. 
The problem that we need to address is the trust.
The more high-quality and well-maintained libraries there are, 
the less cautious one would need to be before reaching to 
code.dlang.org.
Jun 25 2020
next sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Thursday, 25 June 2020 at 14:27:02 UTC, Petar Kirov 
[ZombineDev] wrote:

 Technically, phobos is actually already on Dub 
 (https://code.dlang.org/packages/phobos), so in the future 
 nothing could prevent you to continue using it, but you would 
 just get it from there and not from the compiler distribution 
 archive. It's the same code, made by the same people, just with 
 a different distribution model.


Aside: it seems like Dub is not properly picking up the tagged 
releases, and only has '~master' and '~stable' available. Fixing 
this would make using Phobos via dub a much more attractive 
proposition.
Jun 25 2020
parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Thursday, 25 June 2020 at 15:14:21 UTC, Paul Backus wrote:

 On Thursday, 25 June 2020 at 14:27:02 UTC, Petar Kirov 
 [ZombineDev] wrote:

 Technically, phobos is actually already on Dub 
 (https://code.dlang.org/packages/phobos), so in the future 
 nothing could prevent you to continue using it, but you would 
 just get it from there and not from the compiler distribution 
 archive. It's the same code, made by the same people, just 
 with a different distribution model.


 Aside: it seems like Dub is not properly picking up the tagged 
 releases, and only has '~master' and '~stable' available. 
 Fixing this would make using Phobos via dub a much more 
 attractive proposition.


I agree, this would at least allow people pick an exact version. 
(Of course, given that Phobos doesn't follow SemVer, every minor 
release (2.xx.0) could introduce a breaking change - a symbol 
being removed after the 2 year deprecation period.)

But still, the next major problem to solve is actually ensuring 
that each Phobos release works with several different compiler 
releases, which as far as I can see is not going to happen 
anytime soon.
Jun 25 2020
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 25 June 2020 at 16:23:11 UTC, Petar Kirov 
[ZombineDev] wrote:

 [snip]

 I agree, this would at least allow people pick an exact 
 version. (Of course, given that Phobos doesn't follow SemVer, 
 every minor release (2.xx.0) could introduce a breaking change 
 - a symbol being removed after the 2 year deprecation period.)

 But still, the next major problem to solve is actually ensuring 
 that each Phobos release works with several different compiler 
 releases, which as far as I can see is not going to happen 
 anytime soon.


File bugzilla issue?
Jun 25 2020
parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Thursday, 25 June 2020 at 17:11:58 UTC, jmh530 wrote:

 On Thursday, 25 June 2020 at 16:23:11 UTC, Petar Kirov 
 [ZombineDev] wrote:

 [snip]

 I agree, this would at least allow people pick an exact 
 version. (Of course, given that Phobos doesn't follow SemVer, 
 every minor release (2.xx.0) could introduce a breaking change 
 - a symbol being removed after the 2 year deprecation period.)

 But still, the next major problem to solve is actually 
 ensuring that each Phobos release works with several different 
 compiler releases, which as far as I can see is not going to 
 happen anytime soon.


 File bugzilla issue?


https://github.com/dlang/projects would be more appropriate, so 
if other people see value in this, I hope they will post there 
(I'm running out of time to continue this long topic atm).
Jun 25 2020
parent jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 25 June 2020 at 18:25:47 UTC, Petar Kirov 
[ZombineDev] wrote:

 On Thursday, 25 June 2020 at 17:11:58 UTC, jmh530 wrote:

 [snip]

 File bugzilla issue?


 https://github.com/dlang/projects would be more appropriate, so 
 if other people see value in this, I hope they will post there 
 (I'm running out of time to continue this long topic atm).


I filed one here
https://issues.dlang.org/show_bug.cgi?id=20977
anyone is free to improve it and add to projects.
Jun 25 2020
prev sibling next sibling parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Thursday, 25 June 2020 at 14:27:02 UTC, Petar Kirov 
[ZombineDev] wrote:

 On Thursday, 25 June 2020 at 12:13:21 UTC, Paolo Invernizzi 
 wrote:

 I know that we are quite few on this side, but IMHO a well 
 shaped standard library has advantages over a sparse ecosystem 
 of independent library ...


 Who says that this is a binary choice? And also, the way you 
 fraise it it's obvious that say Flutter is better choice than 
 React as everything is very tightly integrated and you could 
 build your whole app without reaching for third-party code. 
 Also, it's obvious that in terms of trust, it's better to rely 
 on the diligence of the upsteam development team, than random 
 strangers from the internet.

 But what if 90% of the code my team needs has no place in 
 Phobos? We already have to rely heavily on third-party 
 packages. Yes there are a lot of risks and we try to be 
 careful, but we have no other choice. We could spend years 
 reiventing the wheel (high-quality code that already exists in 
 other languages), or we could focus on delivering products to 
 our users based on the already existing ecosystem in other 
 languages. Well, a choice would exist if we had an unlimited 
 budget, but given that we're not as lucky, we can only use 
 other languages for our projects currently.

 Technically, phobos is actually already on Dub 
 (https://code.dlang.org/packages/phobos), so in the future 
 nothing could prevent you to continue using it, but you would 
 just get it from there and not from the compiler distribution 
 archive. It's the same code, made by the same people, just with 
 a different distribution model.

 The way I see things is that we as a community need to focus on 
 a vetted, well shaped collection of libraries.
 We need to have process where third-party libraries are able to 
 gain broader support and join dlang-community. Also we need 
 dlang-community to have a healthy number of people who actually 
 maintain the code.
 We need the leadership to realize that investing just in dmd, 
 druntime and phobos is necessary, but very insufficient.
 W&A need to stop pretending that Dub doesn't exist. I feel that 
 unless we embrace using code.dlang.org as method of 
 distribution of everything that's currently part of the 
 compiler archive, Dub's limitations will never be addressed and 
 from that the broader community will suffer.


I understand your point of view and what you are trying to say. 
In my opinion it's a chicken and egg problem, IMHO.

My question is: why 90% of the code you need is not in Phobos, 
and why is Phobos stagnating? In the just released beta of DMD, 
there are zero Phobos references in the changelog ...


 Anyway, if we can, we try to stick with Phobos, as long as we 
 don't have a particular problem to solve that needs an 
 external library: recent example, Martin std.io or SumType 
 instead of std.variant ...


 See, some of the problems in Phobos already have a good 
 solution. The problem that we need to address is the trust.
 The more high-quality and well-maintained libraries there are, 
 the less cautious one would need to be before reaching to 
 code.dlang.org.


It's not only a problem of trust, it's a problem of integration 
and maintenance also: for example, some days ago I tried to use 
Martin and Steven std.io with std.concurrency, and I faced a wall 
of problems related to non copiable struct, variants, reference 
counting implementation, and so on ...

I know that there're advantages in flexibility, but there are 
costs also, for example, not everyone scouting for DLang as a 
candidate for a task has your (great!) experience in managing all 
the sort of problems that arises when trying to combine different 
packages, or has the experience (or the time?) to choose the 
"golden" one.

Anyway, you are right, it's not a binary choice.

/P
Jun 25 2020
parent Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Thursday, 25 June 2020 at 15:33:18 UTC, Paolo Invernizzi wrote:

 [snip]

 I understand your point of view and what you are trying to say. 
 In my opinion it's a chicken and egg problem, IMHO.


Yes, that's a fair assessment.


 My question is: why 90% of the code you need is not in Phobos,


I can go in more detail later, but let's just say that Phobos is 
a generic library aiming to solve general use-cases of most/all 
language users. In many domains, such as mine that's less than 5% 
of what I need, the rest is really domain-specific. And obviously 
there are more domain-specific libraries in other more popular 
languages.
Also, Phobos is very poor in terms of general application-level 
programming. Unlike e.g. Node.js or Flutter, it's neither 
sufficient for frontend (web/mobile/desktop) nor backend 
programming.


 and why is Phobos stagnating?


Several related reasons from the top of my head:
1. People are simply not interested in contributing (anymore).
A few hypothetical examples (I/me == random contributor):
1.a. As an individual developer I write code for fun, so I don't 
find value in going through the difficult (as it should be) 
process of proposing my code for std and passing through code 
reviews.
1.b. As an organization, we like to contribute to the community, 
and publishing on GitHub/GitLab/etc. + code.dlang.org is mutually 
beneficial: Other community members or companies can find value 
in what we do and can reports bugs and contribute improvements. 
However, contributing to Phobos takes just too long and also 
limits the potential number of contributors. Also we don't 
control the code anymore. So in general it's hard to justify from 
a business point of view.
1.c. (I guess that would be a fair approximation of the ndslice 
case): I'm a highly motivated individual who wants to contribute 
a foundational piece to the standard library, the positive 
effects of which would permeate throughout the ecosystem. Few 
problems:
- I want to support older/newer GDC/LDC versions (a few years ago 
that wasn't at all possible for upstream phobos)
- It's a nice start, but actually the reason I made this 
contribution is so I can advance in my domain (e.g. scientific 
computing, fintech, whatever), so now I need to to write domain 
specific libraries. Well actually, to support those libraries I 
need to make changes to the API. Well I can't do that easily 
anymore as I don't own the code and breaking changes are not well 
supported in Phobos (no SemVer). I also want betterC support, so 
I need to vendor (fork and rewrite) parts of druntime. The 
changes are good enough for me, but they can't be accepted 
upstream. And so my library now has non-Phobos dependencies, and 
so obviously it can't be part of Phobos.
1.d. I work on a security-sensitive library (e.g. crypto). I need 
to follow a responsible security vulnerability disclosure policy. 
Also when I have fixed the issue, and the changes are audited, I 
need to push a new release ASAP. A new compiler release (even 
point/bugfix one) typically has a latency of at least 1 month. It 
can contain also other unrelated breaking changes.

2. Failure to cultivate and *****retain***** community talent. By 
community talent I mean contributors who are *not* paid. E.g. 
Dicebot, JinShil, berni, Kenji, Joakim, and so on. Yeah, each 
case has its specifics, but if people with contributions of their 
caliber were to leave my company, I would be seriously worried 
and losing sleep (and selling stonks :D)
For example, not until recently (let's say 2017/2018), if a 
newcomer were to look at this page: 
https://github.com/dlang/dmd/graphs/contributors they would 
conclude that dmd was Kenji and Walter's project (and not Walter 
+ contributors), as Kenji had substantially bigger number of 
commits than Walter at that point of time.



 In the just released beta of DMD, there are zero Phobos 
 references in the changelog ...


Well, this varies with each release, but outside of bug fixes, 
refactoring or otherwise improvements to existing code and 
addition of fundamental vocabulary types (e.g. SumType), what 
exactly do you expect to see? Can you list exactly what kinds of 
contributions would you expect to see from non-paid volunteers? 
And I don't mean to say "non-paid" in a bad way regarding DLF. I 
mean that people who work for free are usually even more 
self-motivated then paid contributors. Why would anyone want to 
put new modules in Phobos, where they can develop them much 
faster in the open?

Also, contributing to the compiler and runtime has a much higher 
value than Phobos, especially given how easy and beneficial in 
many cases it is to replace Phobos with a code.dlang.org package.

Additionally, most of the code in dmd/druntime is internal and 
it's much easier to change than Phobos, which for the most part 
is comprised of public functions. In the compiler and the runtime 
you can make huge changes without breaking backwards 
compatibility at all.


 Anyway, if we can, we try to stick with Phobos, as long as we 
 don't have a particular problem to solve that needs an 
 external library: recent example, Martin std.io or SumType 
 instead of std.variant ...


 See, some of the problems in Phobos already have a good 
 solution. The problem that we need to address is the trust.
 The more high-quality and well-maintained libraries there are, 
 the less cautious one would need to be before reaching to 
 code.dlang.org.


 It's not only a problem of trust, it's a problem of integration 
 and maintenance also: for example, some days ago I tried to use 
 Martin and Steven std.io with std.concurrency, and I faced a 
 wall of problems related to non copiable struct, variants, 
 reference counting implementation, and so on ...


By trust, I also meant compatibility and general dependability.
For example, in the frontend world, even though Redux and React 
are developed by different teams (there's overlap but still), I 
feel like an illuminati apocalypse would be a more likely event 
than Redux somehow breaking React.js compatibility or vice versa 
:D

In the case of Steven and Martin's libraries, they're both pretty 
cool guys, whom I've met and chatted with at DConf, so I trust 
them as people, but they're both pretty busy these days (just my 
casual observation from GitHub and the forums), so I can't 
"trust" these libraries for critical stuff, as they don't have a 
high enough number of contributors who could take the lead in 
case Martin or Steven are not there.

I really hope we can improve as a community in this regard.


 I know that there're advantages in flexibility, but there are 
 costs also, for example, not everyone scouting for DLang as a 
 candidate for a task has your (great!) experience in managing 
 all the sort of problems that arises when trying to combine 
 different packages, or has the experience (or the time?) to 
 choose the "golden" one.

 Anyway, you are right, it's not a binary choice.

 /P


Yeah, flexibility almost always brings complexity (e.g. generic 
code can be easy to write, but sometimes it can be complex to 
debug). Really, what I mean is that we need to create a carefully 
curated collection of packages that work together and are 
maintained by a good number of qualified people. That's kind of 
the idea of dlang-community, but with a single large project like 
DCD in it (and its dependencies), it kind of twists the balance 
of contributions towards DCD. There's also the vibe-d and libmir 
organizations. However, we lack a broader collaboration and 
cooperation between them.


 managing all the sort of problems that arises when trying to 
 combine different packages


P.S. That is actually full-time job in the npm world :D
But it actually makes a lot of sense from business point of view. 
Nowadays, no company, no matter how huge could build in-house all 
that already exists (and is of high-quality) in the open-source 
world. It's cheaper to spend one week choosing 1 library from 
100+ then spending a few months to create another one that solves 
the same problem. Especially if your in-house developers need to 
move on a different project and then no one could maintain your 
in-house creation.

----

These are all really difficult problems to solve, but solving 
them can potentially create the biggest value of the community. 
Just like the Nodejs codebase represents <<<< 0.01% of the code 
of the whole npmjs ecosystem, the D language spec, dmd, druntime, 
phobos and the tools are absolutely foundational and critical, 
but would still represent a small fraction of the total value 
that our community can create.
We now need to focus on scaling the bigger part of the pie.
Jun 25 2020
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/25/20 10:27 AM, Petar Kirov [ZombineDev] wrote:

 The way I see things is that we as a community need to focus on a 
 vetted, well shaped collection of libraries.
 We need to have process where third-party libraries are able to gain 
 broader support and join dlang-community. Also we need dlang-community 
 to have a healthy number of people who actually maintain the code.
 We need the leadership to realize that investing just in dmd, druntime 
 and phobos is necessary, but very insufficient.
 W&A need to stop pretending that Dub doesn't exist. I feel that unless 
 we embrace using code.dlang.org as method of distribution of everything 
 that's currently part of the compiler archive, Dub's limitations will 
 never be addressed and from that the broader community will suffer.


(By the way just to clarify "A" in "W&A" would stand for Atila. I'm 
commenting as just one in the community.)

I'm a bit confused by this argument. So there is the compiler and 
standard library, and then there's a community-supported library, which 
includes a copy of the standard library under an improved versioning 
schema. It's all legal and encouraged by the generous licensing of the 
compiler and standard library, both of which Walter and I fought hard in 
the past to obtain and maintain.

Dub is the perfect place where community leadership can set the tone and 
organized things as they need to without heavy-handed intervention from 
above. Several people have criticized "the leadership" for not doing 
things the way they wanted, so it seems perplexing that leadership 
intervention is now asked for. What's that nonsense with "pretending dub 
doesn't exist"? So now they need to take ownership of the 
community-driven dub as well? Isn't that a bit too much work for a 
handful of folks in the best of times?

Is money that's been asked for? We don't have enough to do competitive 
hiring.

I don't think Bjarne or Herb have ever been accused of not contributing 
to Boost (which they didn't), or asked to invest in it. Boost has been a 
community-led effort which has had a great influence on C++ development 
- with the participation of volunteers, not the formal standards committee.


 Anyway, if we can, we try to stick with Phobos, as long as we don't 
 have a particular problem to solve that needs an external library: 
 recent example, Martin std.io or SumType instead of std.variant ...


 
 See, some of the problems in Phobos already have a good solution. The 
 problem that we need to address is the trust.
 The more high-quality and well-maintained libraries there are, the less 
 cautious one would need to be before reaching to code.dlang.org.


This is and will always be the case, and it's normal. A standard library 
can't implement all special purpose libraries, or even a significant 
fraction. A community-led library is a great thing.
Jun 25 2020
next sibling parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Thursday, 25 June 2020 at 16:25:01 UTC, Andrei Alexandrescu 
wrote:

 On 6/25/20 10:27 AM, Petar Kirov [ZombineDev] wrote:

 The way I see things is that we as a community need to focus 
 on a vetted, well shaped collection of libraries.
 We need to have process where third-party libraries are able 
 to gain broader support and join dlang-community. Also we need 
 dlang-community to have a healthy number of people who 
 actually maintain the code.
 We need the leadership to realize that investing just in dmd, 
 druntime and phobos is necessary, but very insufficient.
 W&A need to stop pretending that Dub doesn't exist. I feel 
 that unless we embrace using code.dlang.org as method of 
 distribution of everything that's currently part of the 
 compiler archive, Dub's limitations will never be addressed 
 and from that the broader community will suffer.


 (By the way just to clarify "A" in "W&A" would stand for Atila. 
 I'm commenting as just one in the community.)


Hi Andrei, well, I meant Walter and you during 2015-2019, though 
just to be clear, I neither wish, nor it was my intension to turn 
this discussion into a personal attack. My goal is to stress how 
important it is to focus on helping the community grow and scale 
in a healthy way. Focusing just on the language spec and 
implementation is missing the bigger picture, IMO. But since you 
decided to address specifically this point, I'll try to elaborate 
more:

I don't recall you or Walter getting involved with the 
development of dub or the dub-registry in any significant manner. 
I remember that you criticized the addition of SDLang as an 
alternative to JSON package description format, but that's it.

I feel there is a very big disconnect between you and the 
community. One on hand, I think that Dub and code.dlang.org are 
one of the biggest assets of the community. On the other hand, it 
seems to me that you're not interested in Dub at all. It's just 
another community project that "they"'re free to do whatever they 
want it.
For example, my impression (though I'd be happy to be wrong), is 
that you have never actually tried using Dub for any project of 
significant size, or such depending on a significant proportion 
of code that you don't maintain. On the other side, take as an 
example any company that needs to bring a D web project quickly 
to market. The first thing they'll likely reach for is dub + 
vibe-d + mysql-native + some js frontend framework - basically 
100% third-party code for that team. Since (as far as I'm aware) 
you haven't invested much time in projects like this, I'd guess 
that it would be hard for you to fully appreciate the necessity, 
challenges, and benefits of using a package manager like Dub. 
Which is why, to me it seems that Dub is not very high on your 
radar of important things to improve for to D succeed.

Different people having different priorities is absolutely normal 
but on the other hand, if hypothetically most people using D type 
`dub` in their terminal say 99% of their time compared to 1% for 
`dmd`, perhaps it's not unreasonable for the community to expect 
the leadership to take a Dub's issues in a proportional manner. 
Or at least the community would find it strange that the keywords 
code.dlang.org or Dub were not mentioned even once in the vision 
documents, e.g. https://wiki.dlang.org/Vision/2018H1. Yeah, 
"tooling" is mentioned, but honestly, that too unspecific to be 
actionable. On a related topic, "mobile" and "wasm" also not 
mentioned, which areas where D in theory could do very well, and 
its direct competitors are rapidly gaining market share.


 I'm a bit confused by this argument. So there is the compiler 
 and standard library, and then there's a community-supported 
 library, which includes a copy of the standard library under an 
 improved versioning schema. It's all legal and encouraged by 
 the generous licensing of the compiler and standard library, 
 both of which Walter and I fought hard in the past to obtain 
 and maintain.


Okay... though I don't see why you need to point this out.
Yes, getting dmd fully Boost-licensed was a great achievement, 
and I and the rest of community are all grateful for that, though 
we're currently discussing about Phobos. I have never used a 
language which doesn't have an open-source and 
permissively-licensed standard-library.


 Dub is the perfect place where community leadership can set the 
 tone and organized things as they need to without heavy-handed 
 intervention from above. Several people have criticized "the 
 leadership" for not doing things the way they wanted, so it 
 seems perplexing that leadership intervention is now asked for. 
 What's that nonsense with "pretending dub doesn't exist"? So 
 now they need to take ownership of the community-driven dub as 
 well? Isn't that a bit too much work for a handful of folks in 
 the best of times?

 Is money that's been asked for? We don't have enough to do 
 competitive hiring.


No, money is not what's been asked for. For me, the most 
straightforward way to look at things is as if the DLF doesn't 
exist and there's no money on the table in the first place. (Also 
funding can only reward future contritions, so in a sense, it's 
not fair to past contributions.) So what's left (in this way of 
looking at things) is just individuals motivated for whatever 
non-financial reasons (at least not direct ones) who are working 
to improve D. It follows that motivated, talented people who 
effectively collaborate and cooperate are the primary asset of 
the community. The job of the "community leadership" would then 
be to attract, cultivate, and **retain** community talent and 
endorse collaboration. If funding is not an asset, then the only 
remaining leverage is good community management.


 I don't think Bjarne or Herb have ever been accused of not 
 contributing to Boost (which they didn't), or asked to invest 
 in it. Boost has been a community-led effort which has had a 
 great influence on C++ development - with the participation of 
 volunteers, not the formal standards committee.


We can only compare D to C++ on technical merits. The size of 
their community is just in a very different scale to ours. For 
example, I work in a startup where everyone needs to wear many 
hats and handle a very diverse set of responsibilities. We have 
more projects than people. Previously, I've worked at Fortune Top 
10 software company with 20k+ employees. Needless to say, the 
scale is very different.

Instead, we should compare D to language communities developed in 
the past 10-15 years. I suggest you look around and see how each 
one is doing and what were the different steps they took. I can 
assure you that probably all of their leaders at some points have 
been accused of not paying enough attention to this or that thing 
important to some part of the community. That's normal. Leading a 
small community or organization is very different than leading a 
big one.


 Anyway, if we can, we try to stick with Phobos, as long as we 
 don't have a particular problem to solve that needs an 
 external library: recent example, Martin std.io or SumType 
 instead of std.variant ...


 
 See, some of the problems in Phobos already have a good 
 solution. The problem that we need to address is the trust.
 The more high-quality and well-maintained libraries there are, 
 the less cautious one would need to be before reaching to 
 code.dlang.org.


 This is and will always be the case, and it's normal. A 
 standard library can't implement all special purpose libraries, 
 or even a significant fraction. A community-led library is a 
 great thing.


I agree completely. I was not trying to argue the other way 
around. I think Phobos needs to be slimmer (e.g. throw away curl, 
odbc and other nonsense).
For example, the only languages that have good built-in 
networking/HTTP libraries are the ones where this has been an 
explicit goal of the maintainers. Right now we don't have 
sufficient Phobos maintainers with the experience and interest in 
building a GUI framework, so nothing like this should even be 
attempted to be added to Phobos.

A library should only try to do what its maintainers are good at. 
In the case of Phobos that would be generic code like algorithms, 
ranges, allocators, containers, typecons, meta programming, 
process, path and file manipulation and basic IO. Everything else 
should be removed. I'm glad that https://dlang.org/phobos/std_xml 
is finally going away, as probably only Jonathan has real 
experience of building an XML library (hence dxml). Though that 
should have happened much sooner.
Jun 25 2020
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/25/20 5:51 PM, Petar Kirov [ZombineDev] wrote:

 I don't recall you or Walter getting involved with the development of 
 dub or the dub-registry in any significant manner. I remember that you 
 criticized the addition of SDLang as an alternative to JSON package 
 description format, but that's it.
 
 I feel there is a very big disconnect between you and the community. One 
 on hand, I think that Dub and code.dlang.org are one of the biggest 
 assets of the community. On the other hand, it seems to me that you're 
 not interested in Dub at all. It's just another community project that 
 "they"'re free to do whatever they want it.
 For example, my impression (though I'd be happy to be wrong), is that 
 you have never actually tried using Dub for any project of significant 
 size, or such depending on a significant proportion of code that you 
 don't maintain. On the other side, take as an example any company that 
 needs to bring a D web project quickly to market. The first thing 
 they'll likely reach for is dub + vibe-d + mysql-native + some js 
 frontend framework - basically 100% third-party code for that team. 
 Since (as far as I'm aware) you haven't invested much time in projects 
 like this, I'd guess that it would be hard for you to fully appreciate 
 the necessity, challenges, and benefits of using a package manager like 
 Dub. Which is why, to me it seems that Dub is not very high on your 
 radar of important things to improve for to D succeed.
 
 Different people having different priorities is absolutely normal but on 
 the other hand, if hypothetically most people using D type `dub` in 
 their terminal say 99% of their time compared to 1% for `dmd`, perhaps 
 it's not unreasonable for the community to expect the leadership to take 
 a Dub's issues in a proportional manner. Or at least the community would 
 find it strange that the keywords code.dlang.org or Dub were not 
 mentioned even once in the vision documents, e.g. 
 https://wiki.dlang.org/Vision/2018H1. Yeah, "tooling" is mentioned, but 
 honestly, that too unspecific to be actionable. On a related topic, 
 "mobile" and "wasm" also not mentioned, which areas where D in theory 
 could do very well, and its direct competitors are rapidly gaining 
 market share.


Cool cool cool. (Kind of funny you frame lack of involvement in dub as 
something to be ashamed of, like having cheated. I'll level with you: 
I'm just a casual dub user.) So as far as I understand the argument goes 
"Whatever you've worked on, that was missing the point because you 
should have worked on dub instead, which was way more important." From a 
very simple teleological viewpoint, you're entirely right: if D isn't 
mainstream, clearly there is something we didn't do right. As such, all 
paths not taken are very attractive. What if we put all that effort in 
dub? Or an IDE? Or a killer application written in D? No shortage of 
paths not taken. You seem to believe that dub is the most important, but 
over the years there have been many ideas from many people about what is 
the most important.

 From where you stand dub would be the thing to focus on, but for years 
Walter and I have been fighting huge quality problems that now seem to 
be forgotten. Those would preclude any application work. dmd was be 
unable to compile anything beyond the most trivial examples of its own 
flagship features - for years! And when it got it right, phobos got 
something wrong.

It does seem the presence of a package manager is a contributor to 
success. Some languages swear by it (Python/pip, Rust/cargo, 
Haskell/cabal). Yet some others are successful without an official one 
(Java, C, C++, PHP); and yet others aren't doing well in spite of having 
a good one (Perl/cpan). So it's not quite the foregone conclusion. Other 
people would say that an IDE is the thing, and I have been repeatedly 
asked to work on one. I'm sure those asking were as convinced about the 
importance of an IDE, as you are about the importance of dub.

The simple fact is I'm not an expert in package management or IDEs. I 
could probably learn how to do it, but it's unlikely he result would be 
anywhere close to world-class. In the meantime, I did think I could do a 
decent job at writing a standard library and helping with the language 
definition and there was an obvious necessity for those, too.

The main problem with the argument "why didn't you work more on X, when 
clearly X would have made the D language more successful than working on 
your core expertise Y" is... there's something wrong with it. Whatever 
the problem is, the solution can't be let's have fewer people do more 
work. It doesn't scale.


 Instead, we should compare D to language communities developed in the 
 past 10-15 years. I suggest you look around and see how each one is 
 doing and what were the different steps they took. I can assure you that 
 probably all of their leaders at some points have been accused of not 
 paying enough attention to this or that thing important to some part of 
 the community. That's normal. Leading a small community or organization 
 is very different than leading a big one.


Yes, that's a good point. It is self-evident to me that I have not been 
a good leader, which is part of why I bowed out.

All the paths not taken; surely one of them must have been better. I 
totally agree we didn't find the right sauce (how could I disagree? D 
doesn't have a million users). I think something endemic to our 
community is a certain thorniness, in most likelihood caused by its 
leadership (it always starts from the leadership) and slow mainstream 
adoption. Never in my life have I thrown so much work at such an 
unending pit of hostility. Years and years of my life, and some of my 
best work ever. Hundreds of thousands of lines written. Many more 
reviewed, to be fought tooth and nail by people whom I was just trying 
to help improve. The contrast is fascinating, because many companies are 
ready to pay handily for the very same thing, and the C++ community has 
always been happy with much less significant work. I was never able to 
explain this all to myself. But clearly there's something wrong about 
it. We seem to be dealing in some counterfeit expertise currency.

To this day, many moons after I stepped aside, there's no week going by 
without somebody in this forum putting the poop on something I've done, 
or teaching me how I should have done it.

We could use more kindness around here. Look at the title of this 
thread. "Why Phobos is cool." Someone found something he liked in 
Phobos. I knew as soon as I saw the title a poopfest was going to 
inevitably follow. Let the man have his day.
Jun 25 2020
next sibling parent aberba <karabutaworld gmail.com> writes:
On Friday, 26 June 2020 at 01:58:13 UTC, Andrei Alexandrescu 
wrote:

 On 6/25/20 5:51 PM, Petar Kirov [ZombineDev] wrote:

 I don't recall you or Walter getting involved with the 
 development of dub or the dub-registry in any significant 
 manner. I remember that you criticized the addition of SDLang 
 as an alternative to JSON package description format, but 
 that's it.
 
 I feel there is a very big disconnect between you and the 
 community. One on hand, I think that Dub and code.dlang.org 
 are one of the biggest assets of the community. On the other 
 hand, it seems to me that you're not interested in Dub at all. 
 It's just another community project that "they"'re free to do 
 whatever they want it.
 For example, my impression (though I'd be happy to be wrong), 
 is that you have never actually tried using Dub for any 
 project of significant size, or such depending on a 
 significant proportion of code that you don't maintain. On the 
 other side, take as an example any company that needs to bring 
 a D web project quickly to market. The first thing they'll 
 likely reach for is dub + vibe-d + mysql-native + some js 
 frontend framework - basically 100% third-party code for that 
 team. Since (as far as I'm aware) you haven't invested much 
 time in projects like this, I'd guess that it would be hard 
 for you to fully appreciate the necessity, challenges, and 
 benefits of using a package manager like Dub. Which is why, to 
 me it seems that Dub is not very high on your radar of 
 important things to improve for to D succeed.
 
 Different people having different priorities is absolutely 
 normal but on the other hand, if hypothetically most people 
 using D type `dub` in their terminal say 99% of their time 
 compared to 1% for `dmd`, perhaps it's not unreasonable for 
 the community to expect the leadership to take a Dub's issues 
 in a proportional manner. Or at least the community would find 
 it strange that the keywords code.dlang.org or Dub were not 
 mentioned even once in the vision documents, e.g. 
 https://wiki.dlang.org/Vision/2018H1. Yeah, "tooling" is 
 mentioned, but honestly, that too unspecific to be actionable. 
 On a related topic, "mobile" and "wasm" also not mentioned, 
 which areas where D in theory could do very well, and its 
 direct competitors are rapidly gaining market share.


 Cool cool cool. (Kind of funny you frame lack of involvement in 
 dub as something to be ashamed of, like having cheated. I'll 
 level with you: I'm just a casual dub user.) So as far as I 
 understand the argument goes "Whatever you've worked on, that 
 was missing the point because you should have worked on dub 
 instead, which was way more important."


I would say its not about the MOST, it doesn't always have to be 
the most but one could say without any direct mention of Dub or 
mobile, dub especially, it calls into question how that document 
is compiled. For example is there a community wide survey or 
anything to see which issues are most desired to be tackled. It 
doesn't have to be all but at least help get a couple these 
addressed. Especially dub.


From a very simple
 teleological viewpoint, you're entirely right: if D isn't 
 mainstream,


Right now its about getting D to improve for users. Not potential 
users per se. Phobos is great for what it doesn't but what it 
doesn't, dub needs to be a stronghold.


clearly there is something we didn't do right. As
 such, all paths not taken are very attractive. What if we put 
 all that effort in dub? Or an IDE? Or a killer application 
 written in D? No shortage of paths not taken. You seem to 
 believe that dub is the most important, but over the years 
 there have been many ideas from many people about what is the 
 most important.

 From where you stand dub would be the thing to focus on, but 
 for years Walter and I have been fighting huge quality problems 
 that now seem to be forgotten. Those would preclude any 
 application work. dmd was be unable to compile anything beyond 
 the most trivial examples of its own flagship features - for 
 years! And when it got it right, phobos got something wrong.

 It does seem the presence of a package manager is a contributor 
 to success. Some languages swear by it (Python/pip, Rust/cargo, 
 Haskell/cabal). Yet some others are successful without an 
 official one (Java, C, C++, PHP); and yet others aren't doing 
 well in spite of having a good one (Perl/cpan). So it's not 
 quite the foregone conclusion.


All those languages succeeded, because they found themselves in a 
advantageous point in time. So people could put up with it 
despite its shortfalls. This
could mean it was also immediately interesting to many people 
(contributors) and companies at that time.

Do you really think any new language now can succeed without a 
package repository?


 Other people would say that an IDE is the thing, and I have 
 been repeatedly asked to work on one. I'm sure those asking 
 were as convinced about the importance of an IDE, as you are 
 about the importance of dub.

 The simple fact is I'm not an expert in package management or 
 IDEs.


There's already efforts. It just need support. Again, not always 
financially.

  > I could probably learn how to do it, but it's unlikely he

 result would be anywhere close to world-class. In the meantime, 
 I did think I could do a decent job at writing a standard 
 library and helping with the language definition and there was 
 an obvious necessity for those, too.

 The main problem with the argument "why didn't you work more on 
 X, when clearly X would have made the D language more 
 successful than working on your core expertise Y" is... there's 
 something wrong with it. Whatever the problem is, the solution 
 can't be let's have fewer people do more work. It doesn't scale.


 Instead, we should compare D to language communities developed 
 in the past 10-15 years. I suggest you look around and see how 
 each one is doing and what were the different steps they took. 
 I can assure you that probably all of their leaders at some 
 points have been accused of not paying enough attention to 
 this or that thing important to some part of the community. 
 That's normal. Leading a small community or organization is 
 very different than leading a big one.


 Yes, that's a good point. It is self-evident to me that I have 
 not been a good leader, which is part of why I bowed out.

 All the paths not taken; surely one of them must have been 
 better. I totally agree we didn't find the right sauce (how 
 could I disagree? D doesn't have a million users). I think 
 something endemic to our community is a certain thorniness, in 
 most likelihood caused by its leadership (it always starts from 
 the leadership) and slow mainstream adoption. Never in my life 
 have I thrown so much work at such an unending pit of 
 hostility. Years and years of my life, and some of my best work 
 ever. Hundreds of thousands of lines written. Many more 
 reviewed, to be fought tooth and nail by people whom I was just 
 trying to help improve. The contrast is fascinating, because 
 many companies are ready to pay handily for the very same 
 thing, and the C++ community has always been happy with much 
 less significant work. I was never able to explain this all to 
 myself.


You've been a great inspiration. I would often skip other Dconf 
videos just to see what you'll present.


But clearly there's something wrong about it. We seem
 to be dealing in some counterfeit expertise currency.


Ok now I also feel bad myself. And I can speak for myself now.

I'm probably sure I'm biased and greedy, probably. For example if 
we had some of these issues solved, I'd probably be complaining 
about something else I need.


 To this day, many moons after I stepped aside, there's no week 
 going by without somebody in this forum putting the poop on 
 something I've done, or teaching me how I should have done it.


"There's languages people don't use and those others complain."

However agree we need to control how we air out our complaints so 
it doesn't become a personal attack.

And part of it is being a leader on a project is again more than 
compilers and technically hard core fixes. It also includes 
managing people and marshalling together talents and empowering 
efforts. We've also seen people give up DIPs completely because 
they hit this wall. Communication, communication, people 
management. We're humans first.

If you don't air out opinions on matters, the void will 
definitely be filled.

It's not always about Walter do it, or Andrei fo it, or Atila do 
it. It's about marshalling people together to take responsibility 
of other things you just can't do. Its existing efforts 
everywhere. Again how will you as a CEO promote products of your 
company you don't use yourself or haven't got a gist of.


 We could use more kindness around here. Look at the title of 
 this thread. "Why Phobos is cool." Someone found something he 
 liked in Phobos. I knew as soon as I saw the title a poopfest 
 was going to inevitably follow. Let the man have his day.


Ha ha.

Yeah you're right we've ruined the thread. Sorry.

Why Phobos is cool." it is. Phobos
Jun 26 2020
prev sibling next sibling parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Friday, 26 June 2020 at 01:58:13 UTC, Andrei Alexandrescu 
wrote:

 Never in my life have I thrown so much work at such an unending 
 pit of hostility. Years and years of my life, and some of my 
 best work ever. Hundreds of thousands of lines written. Many 
 more reviewed, to be fought tooth and nail by people whom I was 
 just trying to help improve. The contrast is fascinating, 
 because many companies are ready to pay handily for the very 
 same thing, and the C++ community has always been happy with 
 much less significant work. I was never able to explain this 
 all to myself. But clearly there's something wrong about it. We 
 seem to be dealing in some counterfeit expertise currency.

 To this day, many moons after I stepped aside, there's no week 
 going by without somebody in this forum putting the poop on 
 something I've done, or teaching me how I should have done it.


Let me try and compensate by saying Thank You, which I think has 
not been said enough. The day you announced that you quit your 
job at Facebook to work on D 100% was like Elon Musk announcing 
they would build a network of super chargers: it gave a huge 
confidence boost. Just WOW. So thank you, and I’m glad to see an 
increased involvement from you again recently.

— Bastiaan.
Jun 26 2020
next sibling parent mate <aiueo aiueo.aiueo> writes:
On Friday, 26 June 2020 at 09:23:46 UTC, Bastiaan Veelo wrote:

 On Friday, 26 June 2020 at 01:58:13 UTC, Andrei Alexandrescu 
 wrote:

 Never in my life have I thrown so much work at such an 
 unending pit of hostility. Years and years of my life, and 
 some of my best work ever. Hundreds of thousands of lines 
 written. Many more reviewed, to be fought tooth and nail by 
 people whom I was just trying to help improve. The contrast is 
 fascinating, because many companies are ready to pay handily 
 for the very same thing, and the C++ community has always been 
 happy with much less significant work. I was never able to 
 explain this all to myself. But clearly there's something 
 wrong about it. We seem to be dealing in some counterfeit 
 expertise currency.

 To this day, many moons after I stepped aside, there's no week 
 going by without somebody in this forum putting the poop on 
 something I've done, or teaching me how I should have done it.


 Let me try and compensate by saying Thank You, which I think 
 has not been said enough. The day you announced that you quit 
 your job at Facebook to work on D 100% was like Elon Musk 
 announcing they would build a network of super chargers: it 
 gave a huge confidence boost. Just WOW. So thank you, and I’m 
 glad to see an increased involvement from you again recently.

 — Bastiaan.


Same feelings here.

Thank you Andrei.
Jun 26 2020
prev sibling next sibling parent Arjan <arjan ask.me.to> writes:
On Friday, 26 June 2020 at 09:23:46 UTC, Bastiaan Veelo wrote:

 On Friday, 26 June 2020 at 01:58:13 UTC, Andrei Alexandrescu 
 wrote:

 [...]


 Let me try and compensate by saying Thank You, which I think 
 has not been said enough. The day you announced that you quit 
 your job at Facebook to work on D 100% was like Elon Musk 
 announcing they would build a network of super chargers: it 
 gave a huge confidence boost. Just WOW. So thank you, and I’m 
 glad to see an increased involvement from you again recently.

 — Bastiaan.


This! +1000
Thanks you very much!
Jun 26 2020
prev sibling parent reply Clarice <cl ar.ice> writes:
This is grossly off-topic.
Jun 26 2020
parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Saturday, 27 June 2020 at 01:08:22 UTC, Clarice wrote:

 This is grossly off-topic.


Andrei has been instrumental in the development of Phobos, and he 
deserves a lot of credit for why Phobos is cool (the title of 
this thread). Thanking him for that is not grossly off-topic, 
unlike this answer.

— Bastiaan.
Jun 27 2020
parent reply Jordan Wilson <wilsonjord gmail.com> writes:
On Saturday, 27 June 2020 at 22:32:04 UTC, Bastiaan Veelo wrote:

 On Saturday, 27 June 2020 at 01:08:22 UTC, Clarice wrote:

 This is grossly off-topic.


 Andrei has been instrumental in the development of Phobos, and 
 he deserves a lot of credit for why Phobos is cool (the title 
 of this thread). Thanking him for that is not grossly 
 off-topic, unlike this answer.

 — Bastiaan.


I think there is a bit of miscommunication here. I'm reasonably 
sure of my understanding, so I'll speak on Clarice's behalf: he 
was responding to a post by Seb that appears to have since been 
removed (most likely due to it's off-topicness).

Jordan
Jun 27 2020
parent Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Saturday, 27 June 2020 at 23:30:25 UTC, Jordan Wilson wrote:

 I think there is a bit of miscommunication here. I'm reasonably 
 sure of my understanding, so I'll speak on Clarice's behalf: he 
 was responding to a post by Seb that appears to have since been 
 removed (most likely due to it's off-topicness).

 Jordan


Ah, thanks for clearing that up. The tone as it appeared to me 
didn’t match Clarice’s earlier posts, so it really made me raise 
my eye brows. All good.

— Bastiaan.
Jun 28 2020
prev sibling next sibling parent Guillaume Piolat <first.name gmail.com> writes:
On Friday, 26 June 2020 at 01:58:13 UTC, Andrei Alexandrescu 
wrote:

 We could use more kindness around here. Look at the title of 
 this thread. "Why Phobos is cool." Someone found something he 
 liked in Phobos. I knew as soon as I saw the title a poopfest 
 was going to inevitably follow. Let the man have his day.


+1

Kindness is powerful.

I think we the community is prompt to point out the few mistakes 
while ignoring the stream of good decision the D leadership made 
along the years. One of those being a "big" Phobos that has lured 
many teams towards D. Considering the package explosion in "thin" 
stdlib languages, it was a clear win.
Jun 26 2020
prev sibling next sibling parent bachmeier <no spam.net> writes:
On Friday, 26 June 2020 at 01:58:13 UTC, Andrei Alexandrescu 
wrote:


 The simple fact is I'm not an expert in package management or 
 IDEs. I could probably learn how to do it, but it's unlikely he 
 result would be anywhere close to world-class. In the meantime, 
 I did think I could do a decent job at writing a standard 
 library and helping with the language definition and there was 
 an obvious necessity for those, too.


We all know the concept of comparative advantage. It definitely 
wouldn't make sense for you or Walter to work on a package 
manager or IDE. I concluded long ago that the lack of a 
productive community was holding D back from achieving what other 
languages have.


 Yes, that's a good point. It is self-evident to me that I have 
 not been a good leader


I don't agree on this point. Imperfect but ultimately we ended up 
with a really good language and implementation that works well 
for many of us. I am very thankful for all the effort you put 
into the language.
Jun 26 2020
prev sibling parent reply Chris <wendlec tcd.ie> writes:
On Friday, 26 June 2020 at 01:58:13 UTC, Andrei Alexandrescu 
wrote:

 Cool cool cool. (Kind of funny you frame lack of involvement in 
 dub as something to be ashamed of, like having cheated. I'll 
 level with you: I'm just a casual dub user.) So as far as I 
 understand the argument goes "Whatever you've worked on, that 
 was missing the point because you should have worked on dub 
 instead, which was way more important." From a very simple 
 teleological viewpoint, you're entirely right: if D isn't 
 mainstream, clearly there is something we didn't do right. As 
 such, all paths not taken are very attractive. What if we put 
 all that effort in dub? Or an IDE? Or a killer application 
 written in D? No shortage of paths not taken. You seem to 
 believe that dub is the most important, but over the years 
 there have been many ideas from many people about what is the 
 most important.

 From where you stand dub would be the thing to focus on, but 
 for years Walter and I have been fighting huge quality problems 
 that now seem to be forgotten. Those would preclude any 
 application work. dmd was be unable to compile anything beyond 
 the most trivial examples of its own flagship features - for 
 years! And when it got it right, phobos got something wrong.

 It does seem the presence of a package manager is a contributor 
 to success. Some languages swear by it (Python/pip, Rust/cargo, 
 Haskell/cabal). Yet some others are successful without an 
 official one (Java, C, C++, PHP); and yet others aren't doing 
 well in spite of having a good one (Perl/cpan). So it's not 
 quite the foregone conclusion. Other people would say that an 
 IDE is the thing, and I have been repeatedly asked to work on 
 one. I'm sure those asking were as convinced about the 
 importance of an IDE, as you are about the importance of dub.


But you do realize that Java does have package managers (even if 
there's no official one)? And IDEs are important. It'd be enough 
to have a plugin for IntelliJ or Eclipse.


 The simple fact is I'm not an expert in package management or 
 IDEs. I could probably learn how to do it, but it's unlikely he 
 result would be anywhere close to world-class. In the meantime, 
 I did think I could do a decent job at writing a standard 
 library and helping with the language definition and there was 
 an obvious necessity for those, too.


Nobody expects YOU to write a package manager, and you know that. 
You should keep on working on the library and stuff like that 
because you are very good at it, so you are. And here lies the 
problem, I think. You only see this particular aspect while your 
average John Doe needs a package manager. Think about the average 
development process. You write code in order to ship a product. 
You need 3rd party libraries. This should not be an issue or a 
hack. The average dev just wants to write good, stable code and 
ship the program, and do it fast if there are bug fixes.


 The main problem with the argument "why didn't you work more on 
 X, when clearly X would have made the D language more 
 successful than working on your core expertise Y" is... there's 
 something wrong with it. Whatever the problem is, the solution 
 can't be let's have fewer people do more work. It doesn't scale.


The job of the DLF would be to identify the priorities (as boring 
as they may seem) and coordinate how you go about it and hire, 
yes hire, programmers who work on one of the priorities.


 Instead, we should compare D to language communities developed 
 in the past 10-15 years. I suggest you look around and see how 
 each one is doing and what were the different steps they took. 
 I can assure you that probably all of their leaders at some 
 points have been accused of not paying enough attention to 
 this or that thing important to some part of the community. 
 That's normal. Leading a small community or organization is 
 very different than leading a big one.


 Yes, that's a good point. It is self-evident to me that I have 
 not been a good leader, which is part of why I bowed out.


Once you are a leader you have to stop developing and start 
coordinating things. If you try to do both you'll fail. I said 
this years ago. You love PLs and programming too much to be a 
leader, you want to write good code (so does Walter). You should 
never have become a leader in the first place. You'd need someone 
like Steve Jobs who has a vision and the energy to push his cause.


 All the paths not taken; surely one of them must have been 
 better. I totally agree we didn't find the right sauce (how 
 could I disagree? D doesn't have a million users). I think 
 something endemic to our community is a certain thorniness, in 
 most likelihood caused by its leadership (it always starts from 
 the leadership) and slow mainstream adoption. Never in my life 
 have I thrown so much work at such an unending pit of 
 hostility. Years and years of my life, and some of my best work 
 ever. Hundreds of thousands of lines written. Many more 
 reviewed, to be fought tooth and nail by people whom I was just 
 trying to help improve. The contrast is fascinating, because 
 many companies are ready to pay handily for the very same 
 thing, and the C++ community has always been happy with much 
 less significant work. I was never able to explain this all to 
 myself. But clearly there's something wrong about it. We seem 
 to be dealing in some counterfeit expertise currency.


There were clear suggestions nobody in the leadership picked up 
on. Simple things like stability, tooling. The leadership just 
bulldozers on even if people shout "Noooooo!". The problem of the 
D leadership is that they like programming and hacking too much 
and you're experimenting with code at the expense of your users. 
Do you know how it feels when you're code doesn't compile anymore 
from one version to the next and you have to spend hours to fix 
and test it while your users want this and that new feature?

A PL is more than just code and CS theory. It's a complicated, 
delicate social network, jobs and end users depend on it, it's 
embedded in a competitive fast moving economy. And you have 
neglected this aspect over the years. Instead you concentrated on 
code and CS theory. You were blind to socioeconomic aspects of D.

You are a very good engineer, top of the league. (I still 
sometimes think of your approach when I write code.) But you are 
not a leader. A man has to know his limitations.


 To this day, many moons after I stepped aside, there's no week 
 going by without somebody in this forum putting the poop on 
 something I've done, or teaching me how I should have done it.


Because D attracts the non-mainstream crowd that is more critical 
and demanding, and they feel they are closer to the leadership 
(familiarity), rightly or wrongly so. And if you stick your head 
out you have to live with fair and unfair criticism alike. You 
cannot say "Look at my allocators! Am I not a cool programmer!" 
and then ignore issues you consider "minor issues" (ARM, dub, 
autodecode) that are very important to the actual users. And then 
you break code for users because of some fancy CS thing you 
always wanted to implement. Of course people get angry sometimes.


 We could use more kindness around here. Look at the title of 
 this thread. "Why Phobos is cool." Someone found something he 
 liked in Phobos. I knew as soon as I saw the title a poopfest 
 was going to inevitably follow. Let the man have his day.


Well, the post was a bit, how should I say, well, FFT is in the 
standard lib, great.
Jun 26 2020
parent reply Paul Backus <snarwin gmail.com> writes:
On Friday, 26 June 2020 at 15:06:03 UTC, Chris wrote:

 Once you are a leader you have to stop developing and start 
 coordinating things. If you try to do both you'll fail. I said 
 this years ago. You love PLs and programming too much to be a 
 leader, you want to write good code (so does Walter). You 
 should never have become a leader in the first place. You'd 
 need someone like Steve Jobs who has a vision and the energy to 
 push his cause.


This raises the question: where can D community to find such a 
person?

There is an opportunity for someone with strong communication and 
organizational skills to do a great service for the D community 
by stepping up and filling this leadership vacuum. So far, no one 
has done so. Perhaps this is because we do not have a "Steve 
Jobs" in our midst--or perhaps we do, and they simply lack 
confidence that their contribution would be valued and rewarded.

It is worth thinking about what might be done to encourage such a 
person to volunteer, and what obstacles might currently be 
standing in their way.
Jun 26 2020
next sibling parent reply Chris <wendlec tcd.ie> writes:
On Friday, 26 June 2020 at 16:21:17 UTC, Paul Backus wrote:

 This raises the question: where can D community to find such a 
 person?

 There is an opportunity for someone with strong communication 
 and organizational skills to do a great service for the D 
 community by stepping up and filling this leadership vacuum. So 
 far, no one has done so. Perhaps this is because we do not have 
 a "Steve Jobs" in our midst--or perhaps we do, and they simply 
 lack confidence that their contribution would be valued and 
 rewarded.

 It is worth thinking about what might be done to encourage such 
 a person to volunteer, and what obstacles might currently be 
 standing in their way.


I don't know, but the D community consists mainly of programming 
enthusiasts. That's why they put up a lot if sub-optimal hack-y 
stuff. D needs some sort of Steve Jobs who says "I want it to be 
a great experience for users".
Jun 26 2020
parent Paul Backus <snarwin gmail.com> writes:
On Friday, 26 June 2020 at 16:27:52 UTC, Chris wrote:

 On Friday, 26 June 2020 at 16:21:17 UTC, Paul Backus wrote:

 This raises the question: where can D community to find such a 
 person?

 There is an opportunity for someone with strong communication 
 and organizational skills to do a great service for the D 
 community by stepping up and filling this leadership vacuum. 
 So far, no one has done so. Perhaps this is because we do not 
 have a "Steve Jobs" in our midst--or perhaps we do, and they 
 simply lack confidence that their contribution would be valued 
 and rewarded.

 It is worth thinking about what might be done to encourage 
 such a person to volunteer, and what obstacles might currently 
 be standing in their way.


 I don't know, but the D community consists mainly of 
 programming enthusiasts. That's why they put up a lot if 
 sub-optimal hack-y stuff. D needs some sort of Steve Jobs who 
 says "I want it to be a great experience for users".


I think there are plenty of people willing to contribute to 
improving D's UX, but without any kind of coordination or 
agreement on an overall plan, it is difficult for individuals to 
motivate themselves to take the first step.

This is why I stress "communication and organizational skills." 
IMHO both the desire and the capability are already there, but 
everyone is pointed in different directions.
Jun 26 2020
prev sibling next sibling parent reply bachmeier <no spam.net> writes:
On Friday, 26 June 2020 at 16:21:17 UTC, Paul Backus wrote:


 Perhaps this is because we do not have a "Steve Jobs" in our 
 midst--or perhaps we do, and they simply lack confidence that 
 their contribution would be valued and rewarded.


I'm not sure what it means to talk about a Steve Jobs in the 
context of an open source project. He hired many of the top 
people, paid very high salaries, and shouted at them until he had 
a product he wanted to use. It's easy to be a visionary leader if 
you have billions of dollars to implement your vision.
Jun 26 2020
parent reply Paul Backus <snarwin gmail.com> writes:
On Friday, 26 June 2020 at 16:41:36 UTC, bachmeier wrote:

 On Friday, 26 June 2020 at 16:21:17 UTC, Paul Backus wrote:


 Perhaps this is because we do not have a "Steve Jobs" in our 
 midst--or perhaps we do, and they simply lack confidence that 
 their contribution would be valued and rewarded.


 I'm not sure what it means to talk about a Steve Jobs in the 
 context of an open source project. He hired many of the top 
 people, paid very high salaries, and shouted at them until he 
 had a product he wanted to use. It's easy to be a visionary 
 leader if you have billions of dollars to implement your vision.


I was using "Steve Jobs" to mean the kind of person Chris 
referred to in this quote:


 You'd need someone like Steve Jobs who has a vision and the 
 energy to push his cause.


Feel free to mentally replace it with "a talented leader," if you 
find Steve Jobs himself objectionable.
Jun 26 2020
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jun 26, 2020 at 04:56:20PM +0000, Paul Backus via Digitalmars-d wrote:

 On Friday, 26 June 2020 at 16:41:36 UTC, bachmeier wrote:


[...]

 I'm not sure what it means to talk about a Steve Jobs in the context
 of an open source project. He hired many of the top people, paid
 very high salaries, and shouted at them until he had a product he
 wanted to use.  It's easy to be a visionary leader if you have
 billions of dollars to implement your vision.


 
 I was using "Steve Jobs" to mean the kind of person Chris referred to
 in this quote:
 

 You'd need someone like Steve Jobs who has a vision and the energy
 to push his cause.


 
 Feel free to mentally replace it with "a talented leader," if you find
 Steve Jobs himself objectionable.


You're missing the point, which is the Steve Jobs had billions of
dollars at his disposal and could (and undoubtedly did) use it to pay
people to implement his vision, whereas Walter does not have billions of
dollars at his disposal and cannot motivate volunteers to do what he
wants with money.

Had Steve Jobs *not* been in the position to hire people with billions
of dollars, perhaps a lot less might have come of his vision.


T

-- 
Heads I win, tails you lose.
Jun 26 2020
prev sibling parent reply bachmeier <no spam.net> writes:
On Friday, 26 June 2020 at 16:56:20 UTC, Paul Backus wrote:

 On Friday, 26 June 2020 at 16:41:36 UTC, bachmeier wrote:

 On Friday, 26 June 2020 at 16:21:17 UTC, Paul Backus wrote:


 Perhaps this is because we do not have a "Steve Jobs" in our 
 midst--or perhaps we do, and they simply lack confidence that 
 their contribution would be valued and rewarded.


 I'm not sure what it means to talk about a Steve Jobs in the 
 context of an open source project. He hired many of the top 
 people, paid very high salaries, and shouted at them until he 
 had a product he wanted to use. It's easy to be a visionary 
 leader if you have billions of dollars to implement your 
 vision.


 I was using "Steve Jobs" to mean the kind of person Chris 
 referred to in this quote:


 You'd need someone like Steve Jobs who has a vision and the 
 energy to push his cause.


 Feel free to mentally replace it with "a talented leader," if 
 you find Steve Jobs himself objectionable.


I don't find Steve Jobs objectionable, I just don't think there's 
anything to be gained from pretending there's an equivalent for 
an open source project. Maybe the closest would be Rich Hickey, 
and Clojure's not exactly setting the world on fire.

It doesn't seem all that difficult to figure out what D needs: 
IDE support, a good package manager, solid libraries, and good 
documentation all come to mind. We need volunteers willing to do 
hard work and/or funding to pay people to do the hard work.
Jun 26 2020
parent Yatheendra <indra yath.io> writes:
I am a long-time lurker still debating how to dip my toes in 
BetterC, but I have read these forums, watched DConf videos and 
perused library code.

Phobos is great because the parts I looked at are the first time 
I have grokked library code, it is so well-written. Part of it is 
down to the language offering "developability", the rest is down 
to good taste I guess :-) I could understand at a high-level 
whatever was going on, before ever writing a single line of D.

The complaints cropping up all the time make the forum so bloody 
unproductive (sorry for using strong words. is it just regular 
free-riding ingrates? or some other types? why this overdose just 
on D forums!). Anyway, let me pontificate too.

Leadership, past and present: please ignore all non-contributors' 
complaints, just expect them to write up a technical bug 
report/enhancement proposal (unless you enjoy riling them up). 
You have continued to make your bleeding edge ideas openly 
available, and don't really need to respond to second-guessing by 
non-language designers. I don't know any other project of this 
size with the founders remaining involved this deeply, you have a 
lot of stamina to be replying to less-knowledgeable strangers too.

Contributor-driven forum threads have been so much more 
substantive, but their open availability is what gives a newcomer 
pause. I think it is legitimate to do that in a less discoverable 
place than the forums. Because right now, between auto-decode 
default and the complaints of contributors about process as well 
as direction, I don't know how newcomers can shake the feeling 
that this is Walter's and Andrei's long-term lab!

Contributors: you must have left C++ too far behind, you wouldn't 
deign to suggest changes in that morass. Just because this is a 
more open place with a direct line to leadership, you seem to 
want equal footing for your approaches. I don't think it is too 
much to expect that you defer to Walter's choices because he does 
have a fuller view. Contributing to his considered vision can't 
be of no ongoing benefit.

Users: please try to derate your negativity by acknowledging the 
possibility that language and library design is hard, and other 
language communities likely have all of these debates but not 
overtly publicly. By all means, look for stability but do not 
look for perfection. D is likely better than most any 
natively-compiled language, it is just that you won't hear false 
assurances of no breakage across releases - it is software made 
by few minds, and there will be the odd regression.
Jun 26 2020
prev sibling parent reply aberba <karabutaworld gmail.com> writes:
On Friday, 26 June 2020 at 16:21:17 UTC, Paul Backus wrote:

 On Friday, 26 June 2020 at 15:06:03 UTC, Chris wrote:

 Once you are a leader you have to stop developing and start 
 coordinating things. If you try to do both you'll fail. I said 
 this years ago. You love PLs and programming too much to be a 
 leader, you want to write good code (so does Walter). You 
 should never have become a leader in the first place. You'd 
 need someone like Steve Jobs who has a vision and the energy 
 to push his cause.


 This raises the question: where can D community to find such a 
 person?

 There is an opportunity for someone with strong communication 
 and organizational skills to do a great service for the D 
 community by stepping up and filling this leadership vacuum. So 
 far, no one has done so. Perhaps this is because we do not have 
 a "Steve Jobs" in our midst--or perhaps we do, and they simply 
 lack confidence that their contribution would be valued and 
 rewarded.

 It is worth thinking about what might be done to encourage such 
 a person to volunteer, and what obstacles might currently be 
 standing in their way.



It can be done. The problem is the mindset that those things are 
not important or people complaining about such stuff are 
unproductive idiots who have nothing to do with their life but 
spend all day (...in their mind) spamming the D forum, so to 
speak.

We all get paid for writing code. But there's a tool maker and 
there's a tool user. A tool user can also be another person's 
tool user.

Again its the mindset, not everyone has that level of polish and 
UX mind/priority. Some have never written user facing code where 
it has to be done is such a way regular people (in D's case the 
tool user) can feel comfortable to pick up.

It all depends on the mindset, I don't believe it has to do with 
being a (hard core) programmer or anything like it. I've seen D 
tools well polished with good UX. Some value communication and 
organizational skills naturally. The basic elements you learn in 
some high schools or in entrepreneurship class needed to make 
ventures succeed and grow, in addition to other agents.

In D's case, its hard to tell. Some think money is the only way 
to attract talents and they'll only pick that from the Steve jobs 
analogy.

At the end of the day, its all about trying to make D better.
Jun 27 2020
parent Chris <wendlec tcd.ie> writes:
On Saturday, 27 June 2020 at 09:44:01 UTC, aberba wrote:

 On Friday, 26 June 2020 at 16:21:17 UTC, Paul Backus wrote:

 On Friday, 26 June 2020 at 15:06:03 UTC, Chris wrote:

 Once you are a leader you have to stop developing and start 
 coordinating things. If you try to do both you'll fail. I 
 said this years ago. You love PLs and programming too much to 
 be a leader, you want to write good code (so does Walter). 
 You should never have become a leader in the first place. 
 You'd need someone like Steve Jobs who has a vision and the 
 energy to push his cause.


 This raises the question: where can D community to find such a 
 person?

 There is an opportunity for someone with strong communication 
 and organizational skills to do a great service for the D 
 community by stepping up and filling this leadership vacuum. 
 So far, no one has done so. Perhaps this is because we do not 
 have a "Steve Jobs" in our midst--or perhaps we do, and they 
 simply lack confidence that their contribution would be valued 
 and rewarded.

 It is worth thinking about what might be done to encourage 
 such a person to volunteer, and what obstacles might currently 
 be standing in their way.



 It can be done. The problem is the mindset that those things 
 are not important or people complaining about such stuff are 
 unproductive idiots who have nothing to do with their life but 
 spend all day (...in their mind) spamming the D forum, so to 
 speak.

 We all get paid for writing code. But there's a tool maker and 
 there's a tool user. A tool user can also be another person's 
 tool user.

 Again its the mindset, not everyone has that level of polish 
 and UX mind/priority. Some have never written user facing code 
 where it has to be done is such a way regular people (in D's 
 case the tool user) can feel comfortable to pick up.

 It all depends on the mindset, I don't believe it has to do 
 with being a (hard core) programmer or anything like it. I've 
 seen D tools well polished with good UX. Some value 
 communication and organizational skills naturally. The basic 
 elements you learn in some high schools or in entrepreneurship 
 class needed to make ventures succeed and grow, in addition to 
 other agents.

 In D's case, its hard to tell. Some think money is the only way 
 to attract talents and they'll only pick that from the Steve 
 jobs analogy.

 At the end of the day, its all about trying to make D better.


Well put. I think what's missing is a general vision. There are 
too many "subthreads" going on. Everybody has their pet features 
or need just one specific thing out of D an that's that (I 
suppose some users / companies are happy with a subset of D and 
don't care about the rest that might be important to others). The 
problem is that the "leaders" should not actively develop as this 
narrows the field of vision, and if a company sponsors D but only 
focuses on the one aspect that is important to them, then it 
cannot really be a "general purpose" language.

What you basically need is someone like Steve Jobs 
(metaphorically speaking) who sees the bigger picture and says 
"cut that crap" when necessary.
Jun 27 2020
prev sibling parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On 25/06/2020 18:25, Andrei Alexandrescu via Digitalmars-d wrote:

 On 6/25/20 10:27 AM, Petar Kirov [ZombineDev] wrote:

 The way I see things is that we as a community need to focus on a vetted, well
shaped collection of libraries.
 We need to have process where third-party libraries are able to gain broader
support and join dlang-community. Also we need dlang-community to have a
healthy number of people who actually maintain the code.
 We need the leadership to realize that investing just in dmd, druntime and
phobos is necessary, but very insufficient.
 W&A need to stop pretending that Dub doesn't exist. I feel that unless we
embrace using code.dlang.org as method of distribution of everything that's
currently part of the compiler archive, Dub's limitations will never be
addressed and from that the broader community will suffer.


 
 (By the way just to clarify "A" in "W&A" would stand for Atila. I'm commenting
as just one in the community.)
 
 I'm a bit confused by this argument. So there is the compiler and standard
library, and then there's a community-supported library, which includes a copy
of the standard library under an improved versioning schema. It's all legal and
encouraged by the generous licensing of the compiler and standard library, both
of which Walter and I fought hard in the past to obtain and maintain.
 
 Dub is the perfect place where community leadership can set the tone and
organized things as they need to without heavy-handed intervention from above.
Several people have criticized "the leadership" for not doing things the way
they wanted, so it seems perplexing that leadership intervention is now asked
for. What's that nonsense with "pretending dub doesn't exist"? So now they need
to take ownership of the community-driven dub as well? Isn't that a bit too
much work for a handful of folks in the best of times?
 


If I was to take some of it at face value, I'd probably turn around and say:
you know what, I'm going to drop Phobos from GDC and tell people to get it from
Dub instead.

Apart from std.math, there are no differences between upstream and downstream
copies anyway (and I could always upstream version(GNU) asm implementations for
x86, RISC-V, ...).

It would certainly make my life easier, would speed up both time to build
compiler and run the testsuite, and no more worrying about getting the mathlib
working on PPC64, or PA-RISC, or M68K, or VAX.  That's now someone else's
problem, and I can think of better things I could be doing with my time anyway.

Would people be happy if I did this?  I doubt it.
Jul 17 2020
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 18/07/2020 2:14 AM, Iain Buclaw wrote:

 Apart from std.math, there are no differences between upstream and downstream
copies anyway (and I could always upstream version(GNU) asm implementations for
x86, RISC-V, ...).
 
 It would certainly make my life easier, would speed up both time to build
compiler and run the testsuite, and no more worrying about getting the mathlib
working on PPC64, or PA-RISC, or M68K, or VAX.  That's now someone else's
problem, and I can think of better things I could be doing with my time anyway.
 
 Would people be happy if I did this?  I doubt it.


How often does compiling Phobos as part of the testsuite catch bugs in gdc?

If the answer is never, then maybe some deferring could be possible.
Jul 17 2020
parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On 17/07/2020 16:28, rikki cattermole via Digitalmars-d wrote:

 On 18/07/2020 2:14 AM, Iain Buclaw wrote:

 Apart from std.math, there are no differences between upstream and downstream
copies anyway (and I could always upstream version(GNU) asm implementations for
x86, RISC-V, ...).

 It would certainly make my life easier, would speed up both time to build
compiler and run the testsuite, and no more worrying about getting the mathlib
working on PPC64, or PA-RISC, or M68K, or VAX.  That's now someone else's
problem, and I can think of better things I could be doing with my time anyway.

 Would people be happy if I did this?  I doubt it.


 
 How often does compiling Phobos as part of the testsuite catch bugs in gdc?
 
 If the answer is never, then maybe some deferring could be possible.


We're usually very good at finding bugs in Phobos, rather than the other way
round.

However, the combination of testsuite + druntime alone is not really
representative of catching all issues that could happen on changes made to the
code generator, and there have been a few fairly intrusive changes I've been
testing in the last weeks where Phobos has proved to be a good litmus test for
finding problems (especially in the changes being done to emission strategy - I
can no longer ignore it due to newly added GC tests in druntime that depend on
weak rather than vague linkage).

Though the same "representative" argument can be made of testsuite + druntime +
phobos as well, and it shouldn't be too difficult to add a test script that
obtains and builds a bunch of projects (similar to dmd buildkite) as a kind of
expensive testsuite run.
Jul 17 2020
prev sibling parent reply aberba <karabutaworld gmail.com> writes:
On Thursday, 25 June 2020 at 14:27:02 UTC, Petar Kirov 
[ZombineDev] wrote:

 On Thursday, 25 June 2020 at 12:13:21 UTC, Paolo Invernizzi 
 wrote:

 I know that we are quite few on this side, but IMHO a well 
 shaped standard library has advantages over a sparse ecosystem 
 of independent library ...


 Who says that this is a binary choice? And also, the way you 
 fraise it it's obvious that say Flutter is better choice than 
 React as everything is very tightly integrated and you could 
 build your whole app without reaching for third-party code. 
 Also, it's obvious that in terms of trust, it's better to rely 
 on the diligence of the upsteam development team, than random 
 strangers from the internet.

 But what if 90% of the code my team needs has no place in 
 Phobos? We already have to rely heavily on third-party 
 packages. Yes there are a lot of risks and we try to be 
 careful, but we have no other choice. We could spend years 
 reiventing the wheel (high-quality code that already exists in 
 other languages), or we could focus on delivering products to 
 our users based on the already existing ecosystem in other 
 languages. Well, a choice would exist if we had an unlimited 
 budget, but given that we're not as lucky, we can only use 
 other languages for our projects currently.

 Technically, phobos is actually already on Dub 
 (https://code.dlang.org/packages/phobos), so in the future 
 nothing could prevent you to continue using it, but you would 
 just get it from there and not from the compiler distribution 
 archive. It's the same code, made by the same people, just with 
 a different distribution model.

 The way I see things is that we as a community need to focus on 
 a vetted, well shaped collection of libraries.
 We need to have process where third-party libraries are able to 
 gain broader support and join dlang-community. Also we need 
 dlang-community to have a healthy number of people who actually 
 maintain the code.
 We need the leadership to realize that investing just in dmd, 
 druntime and phobos is necessary, but very insufficient.
 W&A need to stop pretending that Dub doesn't exist. I feel that 
 unless we embrace using code.dlang.org as method of 
 distribution of everything that's currently part of the 
 compiler archive, Dub's limitations will never be addressed and 
 from that the broader community will suffer.


 Anyway, if we can, we try to stick with Phobos, as long as we 
 don't have a particular problem to solve that needs an 
 external library: recent example, Martin std.io or SumType 
 instead of std.variant ...


 See, some of the problems in Phobos already have a good 
 solution. The problem that we need to address is the trust.
 The more high-quality and well-maintained libraries there are, 
 the less cautious one would need to be before reaching to 
 code.dlang.org.



Almost the exact reason why i use JavaScript (nodejs) for work 
and not D. It takes more than a nice language. When some here say 
they don't use Dub or they don't care about dub packages, I'm 
wondering what kind of software they are writing.

In my line if work, it's highly dependant of availability of 
packages to get the job done. Encryption, networking, data 
manipulation, database connectors, socket, rest, cloud services, 
etc. Its more like glueing services and APIs together.

Unless you're building compilers and softwares that don't connect 
to internet, then it makes sense to not be bothered by the lack 
of certain packages on dub.

This will only happen when the community collaborates, which will 
only happen when there's a visible leadership push/backing. I 
meant D conf online has taken forever to happen and I'm not sure 
if community building is a thing prioritized at all.


I've been policing and trying several packages on dub...some, 
talking to their maintainers. I want to make this happen. Its the 
only way.

I rarely use core nodejs packages. Its like npm has got 
everything. Its what dub needs. Already I'm happy with quite a 
few dub packages. And there's huge!! room for improvement if only 
there's a visible official push. Its not always about money.

I'm not sure why we don't even have regular online community 
meetups. Yeah, there's people who would rather code and feel more 
productive that way. That's also fine.

Except there's another side about community building. DConf is a 
Joy to watch. Just the community interaction alone and how ideas 
are shared. It could happen more often. More often online.
Jun 25 2020
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
On 6/25/20 12:42 PM, aberba wrote:

 This will only happen when the community collaborates, which will only 
 happen when there's a visible leadership push/backing.


This is speculation. What is it based on? Boost was started by Beman 
Dawes with no backing. I know next to nothing about npm, but a look at 
their website www.npmjs.com suggests it's a traditional for-profit 
company with no ties to ECMA or other JavaScript formal leadership bodies.

What concrete forms of said leadership push/backing do you envision?
Jun 25 2020
parent reply aberba <karabutaworld gmail.com> writes:
On Thursday, 25 June 2020 at 17:03:02 UTC, Andrei Alexandrescu 
wrote:

 On 6/25/20 12:42 PM, aberba wrote:

 This will only happen when the community collaborates, which 
 will only happen when there's a visible leadership 
 push/backing.


 This is speculation. What is it based on? Boost was started by 
 Beman Dawes with no backing. I know next to nothing about npm, 
 but a look at their website www.npmjs.com suggests it's a 
 traditional for-profit company with no ties to ECMA or other 
 JavaScript formal leadership bodies.


First, you're making the whole point of it about npm (JavaScript) 
specifically, there's also Cargo (rust).

JavaScript is now very big so there's multiple movements. But 
let's take nodejs, there's a foundation. I've watched several 
meetings by the core team and you can find them on YouTube. Its 
open and live for everyone to see.


 What concrete forms of said leadership push/backing do you 
 envision?


Again since I'm more into nodejs recently, I'll just show you 
their get involved page.

https://nodejs.org/en/get-involved/

I want to be fair because nodejs community has grown and there's 
many stakeholders now...but the initial work to attract interest 
has to be done first.

I don't have all the answers. I may not have articulated my 
opinions well...for sure. However the thing about community, I'm 
not the only person who has that view.
Jun 25 2020
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
On 6/25/20 3:38 PM, aberba wrote:

 On Thursday, 25 June 2020 at 17:03:02 UTC, Andrei Alexandrescu wrote:

 On 6/25/20 12:42 PM, aberba wrote:

 This will only happen when the community collaborates, which will 
 only happen when there's a visible leadership push/backing.


 This is speculation. What is it based on? Boost was started by Beman 
 Dawes with no backing. I know next to nothing about npm, but a look at 
 their website www.npmjs.com suggests it's a traditional for-profit 
 company with no ties to ECMA or other JavaScript formal leadership 
 bodies.


 
 First, you're making the whole point of it about npm (JavaScript) 
 specifically, there's also Cargo (rust).


Yah, rust is an even better example. They have talented people who are 
dedicated to everything related to the rust community, and doing so 
improves their own career and pays their bills. How would you walk and 
talk if your formal job, and that of a team around you, would be to 
serve, manage, and improve the D community? Completely different ballgame.

At least with the resources we can muster for the time being, this is a 
war of attrition we can't sustain. It's simple. Our flamewars are 
similar to the poor couple fighting and giving each other the example of 
the Joneses and how easy everything seems to be for them.
Jun 25 2020
parent reply Avrina <avrina12309412342 gmail.com> writes:
On Thursday, 25 June 2020 at 19:49:21 UTC, Andrei Alexandrescu 
wrote:

 Yah, rust is an even better example. They have talented people 
 who are dedicated to everything related to the rust community, 
 and doing so improves their own career and pays their bills. 
 How would you walk and talk if your formal job, and that of a 
 team around you, would be to serve, manage, and improve the D 
 community? Completely different ballgame.

 At least with the resources we can muster for the time being, 
 this is a war of attrition we can't sustain. It's simple. Our 
 flamewars are similar to the poor couple fighting and giving 
 each other the example of the Joneses and how easy everything 
 seems to be for them.


The only thing the community can do is voice their disdain with 
what they are unhappy with. The situation with DIP1028 is what it 
takes to change course of the SS Didanic. The whole community has 
to be riled up in protest for a change to actually happen. It's 
difficult to make even small changes for the better.
Jun 25 2020
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/25/2020 3:14 PM, Avrina wrote:

 The only thing the community can do is voice their disdain with what they are 
 unhappy with.


Anyone in the community can step up and appoint themself the leader of Dub. If 
they do a good job, the rest of the community will naturally follow.
Jun 25 2020
parent reply Avrina <avrina12309412342 gmail.com> writes:
On Friday, 26 June 2020 at 03:49:09 UTC, Walter Bright wrote:

 On 6/25/2020 3:14 PM, Avrina wrote:

 The only thing the community can do is voice their disdain 
 with what they are unhappy with.


 Anyone in the community can step up and appoint themself the 
 leader of Dub. If they do a good job, the rest of the community 
 will naturally follow.


I appoint myself leader of DMD. E-mail me and give me permissions 
to the DMD repository :).
Jun 26 2020
parent reply Paul Backus <snarwin gmail.com> writes:
On Friday, 26 June 2020 at 13:17:13 UTC, Avrina wrote:

 On Friday, 26 June 2020 at 03:49:09 UTC, Walter Bright wrote:

 On 6/25/2020 3:14 PM, Avrina wrote:

 The only thing the community can do is voice their disdain 
 with what they are unhappy with.


 Anyone in the community can step up and appoint themself the 
 leader of Dub. If they do a good job, the rest of the 
 community will naturally follow.


 I appoint myself leader of DMD. E-mail me and give me 
 permissions to the DMD repository :).


Genuine question: what did you hope to achieve by sending this 
reply? It is neither kind nor constructive, and I cannot imagine 
anything useful resulting from it.
Jun 26 2020
parent reply Avrina <avrina12309412342 gmail.com> writes:
On Friday, 26 June 2020 at 13:41:28 UTC, Paul Backus wrote:

 On Friday, 26 June 2020 at 13:17:13 UTC, Avrina wrote:

 On Friday, 26 June 2020 at 03:49:09 UTC, Walter Bright wrote:

 On 6/25/2020 3:14 PM, Avrina wrote:

 The only thing the community can do is voice their disdain 
 with what they are unhappy with.


 Anyone in the community can step up and appoint themself the 
 leader of Dub. If they do a good job, the rest of the 
 community will naturally follow.


 I appoint myself leader of DMD. E-mail me and give me 
 permissions to the DMD repository :).


 Genuine question: what did you hope to achieve by sending this 
 reply? It is neither kind nor constructive, and I cannot 
 imagine anything useful resulting from it.


I could ask the same thing of the post I replied to.
Jun 26 2020
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/26/2020 9:26 AM, Avrina wrote:

 I could ask the same thing of the post I replied to.


Many D community members have stepped up at their own initiative to become the 
leader of various parts.
Jun 26 2020
parent reply Avrina <avrina12309412342 gmail.com> writes:
On Friday, 26 June 2020 at 21:00:43 UTC, Walter Bright wrote:

 On 6/26/2020 9:26 AM, Avrina wrote:

 I could ask the same thing of the post I replied to.


 Many D community members have stepped up at their own 
 initiative to become the leader of various parts.


Go ahead and list some. I already have a feeling I know what the 
trend is going to be like.
Jun 27 2020
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/27/2020 5:07 AM, Avrina wrote:

 Many D community members have stepped up at their own initiative to become the 
 leader of various parts.


 Go ahead and list some. I already have a feeling I know what the trend is
going 
 to be like.


Rainer does the Win64 and VS support. Brad Roberts initiated, built, and ran
the 
test servers for many years. He did bugzilla too. Iain does GDC. The LDC team
is 
entirely self-selected. Jacob does the Objective-C support. Vladimir wrote the 
Dforum software (and many other indispensable tools). And on and on for nearly 
every part of the D system.

You want something to happen? Step up and make it happen.
Jun 27 2020
next sibling parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Saturday, 27 June 2020 at 20:29:22 UTC, Walter Bright wrote:

 On 6/27/2020 5:07 AM, Avrina wrote:

 Many D community members have stepped up at their own 
 initiative to become the leader of various parts.


 Go ahead and list some. I already have a feeling I know what 
 the trend is going to be like.





 Jacob does the Objective-C support.


He does also DWT.
Jun 28 2020
parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/28/2020 3:26 AM, Patrick Schluter wrote:

 On Saturday, 27 June 2020 at 20:29:22 UTC, Walter Bright wrote:

 Jacob does the Objective-C support.


 He does also DWT.


Yes. My list does not remotely cover everyone who has stepped up to take charge 
and make things happen.
Jun 28 2020
prev sibling next sibling parent aberba <karabutaworld gmail.com> writes:
On Saturday, 27 June 2020 at 20:29:22 UTC, Walter Bright wrote:

 On 6/27/2020 5:07 AM, Avrina wrote:

 Many D community members have stepped up at their own 
 initiative to become the leader of various parts.


 Go ahead and list some. I already have a feeling I know what 
 the trend is going to be like.


 Rainer does the Win64 and VS support. Brad Roberts initiated, 
 built, and ran the test servers for many years. He did bugzilla 
 too. Iain does GDC. The LDC team is entirely self-selected. 
 Jacob does the Objective-C support. Vladimir wrote the Dforum 
 software (and many other indispensable tools). And on and on 
 for nearly every part of the D system.

 You want something to happen? Step up and make it happen.


Yes, someone definitely has to be uncharged. That's always true.

But what's your (DLF) role in this? Does it fall outside the 
vision of the foundation to participate and keep the fire burning 
in whatever way it can? Is there no coordination to solidify and 
unify all those efforts to ensure continuity? What happens when 
those people leave. What's the foundation doing about this?
Jun 28 2020
prev sibling next sibling parent Chris <wendlec tcd.ie> writes:
On Saturday, 27 June 2020 at 20:29:22 UTC, Walter Bright wrote:

 On 6/27/2020 5:07 AM, Avrina wrote:

 Many D community members have stepped up at their own 
 initiative to become the leader of various parts.


 Go ahead and list some. I already have a feeling I know what 
 the trend is going to be like.


 Rainer does the Win64 and VS support. Brad Roberts initiated, 
 built, and ran the test servers for many years. He did bugzilla 
 too. Iain does GDC. The LDC team is entirely self-selected. 
 Jacob does the Objective-C support. Vladimir wrote the Dforum 
 software (and many other indispensable tools). And on and on 
 for nearly every part of the D system.

 You want something to happen? Step up and make it happen.


The point is actually that some aspects of D should be taken care 
of directly by the DLF to guarantee continuity and stability. 
What if a contributor leaves the project? What are you gonna do 
then? Volunteers can work on libraries or interfaces to other 
languages, but there are essential parts that should have 
guaranteed LTS from the DLF. I'd say that first class LDC 
integration along with cross platform support should be one of 
the top priorities. You cannot just sit and wait till somebody 
steps up or hope that nobody drops out. That's gambling.

Also, if you rely on volunteers to do important work, the DLF 
might revise its approach to communicating with them. A lot of 
people have left over the way they were being treated and 
projects have been discontinued, and yet the DLF seems to shrug 
it off every time this happens instead of doing some 
introspection. (As a side note: it is of course ironic when 
members of the DLF complain about lack of support and gratitude, 
when they have no qualms about stonewalling enthusiastic 
contributors. Quelle ironie!)

Anyway, chances are that ARM will decide the fate of D.
Jun 28 2020
prev sibling parent reply Avrina <avrina12309412342 gmail.com> writes:
On Saturday, 27 June 2020 at 20:29:22 UTC, Walter Bright wrote:

 On 6/27/2020 5:07 AM, Avrina wrote:

 Many D community members have stepped up at their own 
 initiative to become the leader of various parts.


 Go ahead and list some. I already have a feeling I know what 
 the trend is going to be like.


 Rainer does the Win64 and VS support. Brad Roberts initiated, 
 built, and ran the test servers for many years. He did bugzilla 
 too. Iain does GDC. The LDC team is entirely self-selected. 
 Jacob does the Objective-C support. Vladimir wrote the Dforum 
 software (and many other indispensable tools). And on and on 
 for nearly every part of the D system.

 You want something to happen? Step up and make it happen.


There's only so much "stepping up" to make something happen can 
do. The changes that I think need to happen won't actually be put 
into place, in part because a package manager that is disjoint 
from the rest of the development can only do so much. A forum, a 
server, more servers, a bug tracker, miscellaneous tools, and an 
IDE plugin can all operate disjointly without a significant 
impact (for most of the cases) on the quality of the project. 
Part of the root of the problem with Dub lies with DMD. So simply 
having control to make decisions that would potentially cause 
breaking changes only of Dub isn't enough.

I guess you are a bit spoiled when it comes to having projects 
like LDC where someone did step up and took it upon themselves to 
create something that DMD wasn't able to provide. Not sure how 
well it would go, if for example they decided a DIP (like 
DIP1028) shouldn't be implemented and they simply strip it from 
LDC and reject the DIP themselves. Realistically I doubt this 
will happen, and that's in part because they aren't actually 
fully in control.

You care so little about Dub that you'd let just anyone take up 
the reins and do whatever they want with it. Including running it 
into the ground. The thing about individual projects is that they 
don't need Dub. I use a 100 line python script that does 
everything I need, I'm not going to waste my time with Dub. Just 
as DMD doesn't use dub (except for the library version). It's 
simply easier to not use it. No body is going to invest in 
something they can do themselves for much less effort while still 
being able to work on their own projects instead of having to 
shelf them to work on a package manager.

I think ultimately having past successes with having "someone 
step up" and do the work for you and thinking the same thing 
applies to and will work for Dub, is ultimately hurting Dub in 
the long run.

Well I'm done talking about Dub, maybe I'll link this post in 
5-10 years and we'll see what's come of Dub and your wait and see 
approach to developing it.

#dub #fixdub #dub2028
Jun 28 2020
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/28/2020 9:13 AM, Avrina wrote:

 I guess you are a bit spoiled


Please post with professional demeanor.
Jun 28 2020
next sibling parent reply aeldemery <aeldemery.de gmail.com> writes:
On Monday, 29 June 2020 at 04:49:39 UTC, Walter Bright wrote:

 On 6/28/2020 9:13 AM, Avrina wrote:

 I guess you are a bit spoiled


 Please post with professional demeanor.


Hello all,

This is my first post ever although I've an eye on the forum 
since quite some time.
I wanted to say this kind of destructive conversations is hurting 
the reputation of the language, deepen the feeling that the 
language is unsuccessful and turning newcomers off. The people 
behind this wonderful project deserve some gratitude and 
recognition.
That doesn't deny the fact that it, like any human endeavor, is 
subjected to incongruity and discordance, nevertheless, I think 
there should be another respectful tone in the conversations.

Thanks and have a good day.
Jun 29 2020
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/29/2020 12:04 AM, aeldemery wrote:

 Hello all,
 
 This is my first post ever although I've an eye on the forum since quite some
time.
 I wanted to say this kind of destructive conversations is hurting the
reputation 
 of the language, deepen the feeling that the language is unsuccessful and 
 turning newcomers off. The people behind this wonderful project deserve some 
 gratitude and recognition.
 That doesn't deny the fact that it, like any human endeavor, is subjected to 
 incongruity and discordance, nevertheless, I think there should be another 
 respectful tone in the conversations.
 
 Thanks and have a good day.


We try pretty hard to use a light touch with the moderation, and only remove
the 
worst of them. It's a tough line to call balancing allowing people to speak 
their minds while not destroying the usefulness of the forums.
Jun 29 2020
prev sibling next sibling parent reply aberba <karabutaworld gmail.com> writes:
On Monday, 29 June 2020 at 07:04:30 UTC, aeldemery wrote:

 On Monday, 29 June 2020 at 04:49:39 UTC, Walter Bright wrote:

 On 6/28/2020 9:13 AM, Avrina wrote:

 I guess you are a bit spoiled


 Please post with professional demeanor.


 Hello all,

 I wanted to say this kind of destructive conversations is 
 hurting the reputation of the language, deepen the feeling that 
 the language is unsuccessful and turning newcomers off.


I personally avoid insults. And its quite unfortunate some people 
choose those kind of words.

In some cultures certain words might not sound that offensive 
though. But since we're dealing with an internal community and 
words don't reflect actual emotions, its best to be careful about 
choice of words.


The
 people behind this wonderful project deserve some gratitude and 
 recognition.


That MOST of us do. Not everyone it might seem air it out more 
though. But you know, its a common thing that people usually talk 
without being asked when they are rather troubled within 
something. Doesn't always work the same for when they're good. 
But that's not a good thing for a community.

Does the complaints make D unsuccessful? No. (Well it might sound 
unsuccessful to newcomers...but that's just so for every language 
people actually use, its why say Apple keep releasing new product 
updates).

The language itself is solid. I may be biased but better than any 
system programming language I've ever tried. An that's a 
problem...cus it doesn't deliver it quite complete... ecosystem 
wise (in my perspective).

And that's it, its normal to hear people air the views on those 
issues. And these views are diverse...tools, GC,  safe, Minimal 
runtime, generic, compiler, etc. Different pain points. Could be 
more considering majority (I guess) of D users rare write a 
single word here. I doesn't mean they're not bothered by certain 
things they'd like to be addressed.

You know, I'd rather think the DLF takes these views as community 
feedback.

Side note: code-d plugin for VS code is so good I wonder why its 
not been covered on say the D blog or website preferably.

And that's what I'm afraid will lead many people to feel D 
doesn't have a great code editor support (the maintainer is doing 
amazing job, you'd just have to try it yourself). Same as Visual 
Studio itself. But you don't hear about them, and that's a 
problem.

Of course some seasoned D devs already know this, but what about 
newcomers? Will this not drive them away? And that's just about 
VS code. There's many other efforts like it.


Who will do this? A community manager primarily of course. 
Initially its the LEADER/DLF. Community == contributors with 
diverse contributions.
Jun 29 2020
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/29/2020 4:32 AM, aberba wrote:

 Side note: code-d plugin for VS code is so good I wonder why its not been 
 covered on say the D blog or website preferably.


How about writing an article about it? The D Blog even pays a modest amount to 
authors who get their articles published there.
Jun 29 2020
parent reply aberba <karabutaworld gmail.com> writes:
On Monday, 29 June 2020 at 23:13:57 UTC, Walter Bright wrote:

 On 6/29/2020 4:32 AM, aberba wrote:

 Side note: code-d plugin for VS code is so good I wonder why 
 its not been covered on say the D blog or website preferably.


 How about writing an article about it? The D Blog even pays a 
 modest amount to authors who get their articles published there.


Sounds like you're giving me a good idea. I've added it to my 
to-do list.
Jun 30 2020
parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/30/2020 1:30 AM, aberba wrote:

 Sounds like you're giving me a good idea. I've added it to my to-do list.


Looking forward to it!
Jun 30 2020
prev sibling next sibling parent matheus <matheus gmail.com> writes:
On Monday, 29 June 2020 at 07:04:30 UTC, aeldemery wrote:

 Hello all,

 This is my first post ever although I've an eye on the forum 
 since quite some time.
 I wanted to say this kind of destructive conversations is 
 hurting the reputation of the language, deepen the feeling that 
 the language is unsuccessful and turning newcomers off. The 
 people behind this wonderful project deserve some gratitude and 
 recognition.
 ...


+1 and the strange thing is that "low" conversation was raised on 
a topic which the title is: "Why Phobos is cool".

So instead reading about "the cool things", the topic was 
derailed to "the awful things", and that's pity.

Unfortunately there is this dark mood on this forum lately.

Matheus.
Jun 29 2020
prev sibling parent matheus <matheus gmail.com> writes:
On Monday, 29 June 2020 at 07:04:30 UTC, aeldemery wrote:

 Hello all,

 This is my first post ever although I've an eye on the forum 
 since quite some time.
 I wanted to say this kind of destructive conversations is 
 hurting the reputation of the language, deepen the feeling that 
 the language is unsuccessful and turning newcomers off. The 
 people behind this wonderful project deserve some gratitude and 
 recognition.
 ...


+1 and the strange thing is that "low" conversation was raised on 
a topic which the title is: "Why Phobos is cool".

So instead reading about "the cool things", the topic was 
derailed to "the awful things", and that's pity.

Unfortunately there is this dark mood on this forum lately.

Matheus.
Jun 29 2020
prev sibling parent reply Chris <wendlec tcd.ie> writes:
On Monday, 29 June 2020 at 04:49:39 UTC, Walter Bright wrote:

 On 6/28/2020 9:13 AM, Avrina wrote:

 I guess you are a bit spoiled


 Please post with professional demeanor.


I think the actual point to take home was that you cannot expect 
people to step up forever and ever only because they have done so 
in the past. That's basically gambling. And I do hope you don't 
think that someone will eventually step up if his/her livelihood 
is at stake (ARM).

Please do not use the way something is phrased as an excuse to 
dismiss what is being said, unless it is an outright insult like 
for example a swear word. Experience tells me that when somebody 
is nitpicking about the way something is said and is taking 
offence at everything, it is usually a sign that s/he has no 
answer.
Jun 29 2020
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/29/2020 3:55 AM, Chris wrote:

 and is taking offence at everything,


That is a complete misunderstanding of what is going on here. The targets of 
rude behavior are not the problem, it is the rude behavior that's the problem.

It's about professional demeanor.

Unprofessional posts will be deleted.
Jun 29 2020
parent reply Chris <wendlec tcd.ie> writes:
On Monday, 29 June 2020 at 23:35:13 UTC, Walter Bright wrote:

 On 6/29/2020 3:55 AM, Chris wrote:

 and is taking offence at everything,


 That is a complete misunderstanding of what is going on here. 
 The targets of rude behavior are not the problem, it is the 
 rude behavior that's the problem.

 It's about professional demeanor.

 Unprofessional posts will be deleted.


Personally I think that the sentence was not really rude or 
insulting but maybe polemical, so within the range of a 
passionate and heated debate, I'd say, even in a professional 
environment.

IMO, it's neither fair nor good style to single out one sentence 
from a long post and dismiss the whole post because you consider 
the sentence to be rude or unprofessional. It may give people the 
impression that it's merely a strategy to avoid inconvenient 
questions / points. And since "professional demeanor" is a 
flexible term one can always change the criteria as one sees fit 
(another one is "unspecific" which has become a rather unspecific 
term too :).

In this case, you could have just said something like "That's not 
a nice way to put it, but I get your point [answer] ...May I ask 
you to be a bit more careful in your choice of words the next 
time. We're trying to keep things strictly professional here."

As for the point the poster made, there is no answer I guess, 
because relying on volunteers is a big gamble and only because 
people have stepped up in the past doesn't mean it's gonna be 
like that forever. Again, for the third time, you haven't 
addressed this point but instead talked about "professional 
demeanor".
Jun 30 2020
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/30/2020 1:33 AM, Chris wrote:

 Personally I think that the sentence was not really rude or insulting but
maybe 
 polemical, so within the range of a passionate and heated debate, I'd say,
even 
 in a professional environment.


Calling someone "spoiled" is rude and unprofessional. Period.



 IMO, it's neither fair nor good style to single out one sentence from a long 
 post and dismiss the whole post because you consider the sentence to be rude
or 
 unprofessional.


People who want their message heard need to post in a professional manner. I 
don't care about the opinions of rude people. I don't care to work with them, 
even if they are good. I am hardly alone in this - pretty much nobody in the 
professional world responds to rude messages.



 And since "professional demeanor" is a 
 flexible term one can always change the criteria as one sees fit (another one
is 
 "unspecific" which has become a rather unspecific term too :).


I recommend that anyone who has difficulties understanding what politeness is 
get a copy of Emily Post's book on business etiquette.


Ill-mannered people find themselves shut out of all kinds of opportunities, and 
they rarely figure out why.
Jun 30 2020
next sibling parent reply Arun Chandrasekaran <aruncxy gmail.com> writes:
On Tuesday, 30 June 2020 at 21:40:31 UTC, Walter Bright wrote:

 On 6/30/2020 1:33 AM, Chris wrote:

 Personally I think that the sentence was not really rude or 
 insulting but maybe polemical, so within the range of a 
 passionate and heated debate, I'd say, even in a professional 
 environment.


 Calling someone "spoiled" is rude and unprofessional. Period.



 IMO, it's neither fair nor good style to single out one 
 sentence from a long post and dismiss the whole post because 
 you consider the sentence to be rude or unprofessional.


 People who want their message heard need to post in a 
 professional manner. I don't care about the opinions of rude 
 people. I don't care to work with them, even if they are good. 
 I am hardly alone in this - pretty much nobody in the 
 professional world responds to rude messages.



 And since "professional demeanor" is a flexible term one can 
 always change the criteria as one sees fit (another one is 
 "unspecific" which has become a rather unspecific term too :).


 I recommend that anyone who has difficulties understanding what 
 politeness is get a copy of Emily Post's book on business 
 etiquette.


 Ill-mannered people find themselves shut out of all kinds of 
 opportunities, and they rarely figure out why.


Well said! This is especially applicable for healthy societies 
and communities.

Unrelated to this, but around a month ago I was discussing with a 
friend of mine who is a psychiatrist on how common narcissism has 
become these days and is being mistaken for boldness and how 
leadership roles are being taken by such people and how 
meritocratic communities tend to expell narcists and kakistocracy 
communities tend to favor them, especially if it involves money.

If we do not point out and stand up against their wrong doings, 
they would think they would think they are doing a favor. If we 
do, they won't realize their mistake but would assume personal 
grudge!
Jun 30 2020
parent reply Clarice <cl ar.ice> writes:
On Wednesday, 1 July 2020 at 03:25:45 UTC, Arun Chandrasekaran 
wrote:

 On Tuesday, 30 June 2020 at 21:40:31 UTC, Walter Bright wrote:

 On 6/30/2020 1:33 AM, Chris wrote:

 Personally I think that the sentence was not really rude or 
 insulting but maybe polemical, so within the range of a 
 passionate and heated debate, I'd say, even in a professional 
 environment.


 Calling someone "spoiled" is rude and unprofessional. Period.



 IMO, it's neither fair nor good style to single out one 
 sentence from a long post and dismiss the whole post because 
 you consider the sentence to be rude or unprofessional.


 People who want their message heard need to post in a 
 professional manner. I don't care about the opinions of rude 
 people. I don't care to work with them, even if they are good. 
 I am hardly alone in this - pretty much nobody in the 
 professional world responds to rude messages.



 And since "professional demeanor" is a flexible term one can 
 always change the criteria as one sees fit (another one is 
 "unspecific" which has become a rather unspecific term too :).


 I recommend that anyone who has difficulties understanding 
 what politeness is get a copy of Emily Post's book on business 
 etiquette.


 Ill-mannered people find themselves shut out of all kinds of 
 opportunities, and they rarely figure out why.


 Well said! This is especially applicable for healthy societies 
 and communities.

 Unrelated to this, but around a month ago I was discussing with 
 a friend of mine who is a psychiatrist on how common narcissism 
 has become these days and is being mistaken for boldness and 
 how leadership roles are being taken by such people and how 
 meritocratic communities tend to expell narcists and 
 kakistocracy communities tend to favor them, especially if it 
 involves money.

 If we do not point out and stand up against their wrong doings, 
 they would think they would think they are doing a favor. If we 
 do, they won't realize their mistake but would assume personal 
 grudge!


For what it's worth, while I often disagree with Chris' current 
phrasing and diction, he does have valid points, and I think he 
has good intentions too. (Frustration, like stress, may be a 
negative or a positive motivator!) It would probably benefit us 
all if leadership scheduled a video conference Q&A, or perhaps 
something more informal, e.g. an 'official' BeerConf, as textual 
discussions are more prone to faulty and uncharitable inferences.

And so that this post is somewhat on-topic, I also like a beefier 
stdlib. I don't need an HTTP server or graphics, but containers, 
generic algorithms, protocols, data formats, etc. are all very 
welcome; Phobos satisfies a good chunk of this list.
Jun 30 2020
next sibling parent aberba <karabutaworld gmail.com> writes:
On Wednesday, 1 July 2020 at 04:13:15 UTC, Clarice wrote:

 On Wednesday, 1 July 2020 at 03:25:45 UTC, Arun Chandrasekaran 
 wrote:



but
 containers, generic algorithms, ..., data formats,
 are all very welcome; Phobos satisfies a good chunk of this 
 list.


That's one thing I've always admired Java for. At least for 
containers.

  D has solid generic algorithms thanks to Andrei among others.

Containers and common data formats (json, XML, CSV,..) I'm not 
sure we're there yet.

However, there's solid implementations on dub (vibe.data.json, 
std_data_json, dxml,...) so I personally don't have trouble 
getting things done.

But those are core things that rarely change so fit into a 
standard library for easy get-go.
Jul 01 2020
prev sibling next sibling parent aberba <karabutaworld gmail.com> writes:
On Wednesday, 1 July 2020 at 04:13:15 UTC, Clarice wrote:

 On Wednesday, 1 July 2020 at 03:25:45 UTC, Arun Chandrasekaran 
 wrote:
 It would probably benefit us all if leadership scheduled a 
 video conference Q&A, or perhaps something more informal, e.g. 
 an 'official' BeerConf, as textual discussions are more prone 
 to faulty and uncharitable inferences.


Couldn't agree more. Hoping for it.

DLF: added to my to-do list, checked :)
Jul 01 2020
prev sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 1 July 2020 at 04:13:15 UTC, Clarice wrote:

 And so that this post is somewhat on-topic, I also like a 
 beefier stdlib.


I wish we had more interfaces and UDAs in there.

Today for day job work, I need to do a generic serialize function 
that can handle std.datetime. It would be very cool if it already 
worked, if there was a `void serialize(ISerializer)` already 
there, and/or a ` serializable` attribute.

The stdlib doesn't need to implement all the things, but having 
the interface means it would be easy to reuse all these things 
without writing as many special-purpose adapters.
Jul 01 2020
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 6/30/20 5:40 PM, Walter Bright wrote:

 On 6/30/2020 1:33 AM, Chris wrote:

 Personally I think that the sentence was not really rude or insulting 
 but maybe polemical, so within the range of a passionate and heated 
 debate, I'd say, even in a professional environment.


 
 Calling someone "spoiled" is rude and unprofessional. Period.


I disagree with this. "spoiled" is a term to mean "harmed in character 
by being treated too leniently or indulgently". In that sense, the OP's 
point (right or wrong) was that you may have an incorrect expectation 
that someone will volunteer to step up because you have known nothing 
but people volunteering to do projects without you having to prod people 
into it.

In that sense, this isn't a derogatory or rude term, but conveys 
accurately what the person is trying to say. I personally would not take 
offense at someone saying I'm spoiled by D because it has too many 
awesome features. I have a hard time dealing with other languages 
because D is too good. It *HAS* spoiled me.

Begin even more off-topic rant:

I just want to also say, we are somehow in a time where people take so 
much offense at everything that is said. Basically construing what is 
said in the worst possible light, and I feel like this doesn't help 
discussion at all. It derails the discussion and cancels sometimes valid 
opinions without addressing them. I prefer to think people are mostly 
just trying to convey a point, and if they do it in a rude way, it's 
either because I may have misunderstood them (or they aren't familiar 
with the alternate meaning of what they said), or because they let their 
emotions get the best of them (it happens to everyone). It can be just 
as effective to point out the offense, and remind people that we should 
avoid these kinds of tones, rather than refuse to discuss further (which 
often has the opposite effect -- escalating).

So many online services are starting to cave to the slightest of 
offenses, and I hope this forum doesn't start doing the same.

As a funny anecdote, I worked at a company which bought bagels for 
everyone every morning. When the delivery would come, the receptionist 
would email the building saying the bagels are here.

One morning she misspelled bagels as beagles and added some phrase like 
"come and get em while their hot" or something like that.

There were many obviously tongue-in-cheek or friendly ribbing responses. 
One person, however, responded with one word "Cannibal!" It was someone 
I worked with, so I asked him if he knew what cannibal meant. He said 
"of course, it means someone who eats cute animals." Needless to say as 
we were in a more sane time, he was not fired for such an offense, 
apologized, and we all had a good laugh about it (at his expense of 
course). Deescalation and humor I find are often a better response than 
shaming and begrudging.

-Steve
Jul 01 2020
next sibling parent matheus <matheus gmail.com> writes:
On Wednesday, 1 July 2020 at 13:40:30 UTC, Steven Schveighoffer 
wrote:

 On 6/30/20 5:40 PM, Walter Bright wrote:

 On 6/30/2020 1:33 AM, Chris wrote:

 Personally I think that the sentence was not really rude or 
 insulting but maybe polemical, so within the range of a 
 passionate and heated debate, I'd say, even in a professional 
 environment.


 
 Calling someone "spoiled" is rude and unprofessional. Period.


 I disagree with this. "spoiled" is a term to mean "harmed in 
 character by being treated too leniently or indulgently". In 
 that sense, the OP's point (right or wrong) was that you may 
 have an incorrect expectation that someone will volunteer to 
 step up because you have known nothing but people volunteering 
 to do projects without you having to prod people into it.

 In that sense, this isn't a derogatory or rude term, but 
 conveys accurately what the person is trying to say. I 
 personally would not take offense at someone saying I'm spoiled 
 by D because it has too many awesome features. I have a hard 
 time dealing with other languages because D is too good. It 
 *HAS* spoiled me.


One thing to take in count, is there are a lot a foreigners in 
this forum (Like myself), so one word which may sound "rude" for 
a native person, may be different for a non native.

I think people may forget that during a discussion and I wonder 
if a flag showing the nationality would be helpful in these 
situations.

Matheus.
Jul 01 2020
prev sibling next sibling parent Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Wednesday, 1 July 2020 at 13:40:30 UTC, Steven Schveighoffer 
wrote:
[...]

 -Steve


I am of the same sentiment. Thank you for wording this in a 
de-escalating way, and for raising the spirit on these forums!

— Bastiaan.
Jul 01 2020
prev sibling next sibling parent sebasg <h366l6wxik 326oo.anonbox.net> writes:
On Wednesday, 1 July 2020 at 13:40:30 UTC, Steven Schveighoffer 
wrote:

 [...]
 -Steve


I'm happy to read this from a long-time member of the D ng. To be
honest I got a (probably unwarranted) bad feeling yesterday when
I read WB message. But this is reconforting. Thanks.
Jul 02 2020
prev sibling parent Chris <wendlec tcd.ie> writes:
On Wednesday, 1 July 2020 at 13:40:30 UTC, Steven Schveighoffer 
wrote:

 Begin even more off-topic rant:


[...]


 It can be just as effective to point out the offense, and 
 remind people that we should avoid these kinds of tones, rather 
 than refuse to discuss further (which often has the opposite 
 effect -- escalating).


Yes. Exactly. Thank you.


 Deescalation and humor I find are often a better response than 
 shaming and begrudging.

 -Steve


Again, yes. Thanks.

The D forum used to be more tolerant and focus on the issues that 
were raised rather than on the way things were worded. Also, if 
you have to think carefully about every word in order to sound 
nice and proper and avoid offense at any cost (somebody is always 
offended), chances are that the real point of your message gets 
lost. This could be interpreted as a strategy to muffle dissent.
Jul 02 2020
prev sibling parent reply Chris <wendlec tcd.ie> writes:
On Tuesday, 30 June 2020 at 21:40:31 UTC, Walter Bright wrote:


 Calling someone "spoiled" is rude and unprofessional. Period.


I disagree, you know there is such a thing as context.


 People who want their message heard need to post in a 
 professional manner. I don't care about the opinions of rude 
 people. I don't care to work with them, even if they are good. 
 I am hardly alone in this - pretty much nobody in the 
 professional world responds to rude messages.


That's a bit worrying. So you are saying that you dismiss / don't 
care about somebody's opinion, because you don't like their 
style? This is what I would call unprofessional. You have to 
listen to everybody if they have valid points or good ideas. 
We're talking about technology, a product, not politics.

Note aside: I think the guys who invented / developed the mouse + 
UI at Xerox were a bunch of "non-conformists" and they were fired 
(I think). Steve Jobs took them on (or offered more money? 
Correct me if I'm wrong, I don't know the whole story.)


 I recommend that anyone who has difficulties understanding what 
 politeness is get a copy of Emily Post's book on business 
 etiquette.


"Honesty" can be used as an excuse to hurt somebody, and 
"politeness" can be used as an excuse to chicken out: "Oh, that 
was a rude question, I don't need to answer to that. (Emily Post 
wouldn't have answered to that either, I'm sure.)"

Now, here's something about Emily Post:

"Emily Post (c. October 27, 1872 – September 25, 1960) was an 
American author and socialite, famous for writing about 
etiquette. [...]

The New York Times' Dinitia Smith reports, in her review of Laura 
Claridge's 2008 biography of Post,[4]

    'Emily was tall, pretty and spoiled.'"


There it is again: "spoiled". :) I wonder is there a link between 
being spoiled and insisting on etiquette?

Anyway, business and technology should not be guided by rules 
laid down by a socialite (a spoiled one at that!). And thanks be 
to God, it hasn't, else we wouldn't have the technologies we 
have. You know, over-insistence on etiquette can also be a sign 
of stagnation (cf. what the USA achieved vs. Europe)

(https://en.wikipedia.org/wiki/Emily_Post)



 Ill-mannered people find themselves shut out of all kinds of 
 opportunities, and they rarely figure out why.


"Ill-mannered" as defined by Emily Post?
Jul 02 2020
parent aberba <karabutaworld gmail.com> writes:
On Thursday, 2 July 2020 at 09:29:26 UTC, Chris wrote:

 On Tuesday, 30 June 2020 at 21:40:31 UTC, Walter Bright wrote:


 not politics.


 Note aside: I think the guys who invented / developed the mouse 
 + UI at Xerox were a bunch of "non-conformists" and they were 
 fired (I think). Steve Jobs took them on (or offered more 
 money? Correct me if I'm wrong, I don't know the whole story.)


Interesting. That guy hunted for talents like crazy. I think they 
once used the "Think Different" pitch.

Sometimes it also depends on culture. Not sure though.


But here people "fight" and eat from the same bowl.

But since this in an international community, it's safer to avoid 
certain words in certain contexts.


Sometimes we're just tired and frustrated with this software 
thing. It's fast changing, we need to get things done and if 
sometimes is not working put how you think you want it, it can 
take a huge toll on your emotions.

I try (or at least I'm trying) to l assume people have good 
intent and be positive biased...in a world of increasing 
negativity biasness.
Jul 02 2020
prev sibling next sibling parent Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Thursday, 25 June 2020 at 16:42:36 UTC, aberba wrote:

 Almost the exact reason why i use JavaScript (nodejs) for work 
 and not D. It takes more than a nice language. When some here 
 say they don't use Dub or they don't care about dub packages, 
 I'm wondering what kind of software they are writing.

 In my line if work, it's highly dependant of availability of 
 packages to get the job done. Encryption, networking, data 
 manipulation, database connectors, socket, rest, cloud 
 services, etc. Its more like glueing services and APIs together.

 Unless you're building compilers and softwares that don't 
 connect to internet, then it makes sense to not be bothered by 
 the lack of certain packages on dub.

 This will only happen when the community collaborates, which 
 will only happen when there's a visible leadership 
 push/backing. I meant D conf online has taken forever to happen 
 and I'm not sure if community building is a thing prioritized 
 at all.


 I've been policing and trying several packages on dub...some, 
 talking to their maintainers. I want to make this happen. Its 
 the only way.

 I rarely use core nodejs packages. Its like npm has got 
 everything. Its what dub needs. Already I'm happy with quite a 
 few dub packages. And there's huge!! room for improvement if 
 only there's a visible official push. Its not always about 
 money.

 I'm not sure why we don't even have regular online community 
 meetups. Yeah, there's people who would rather code and feel 
 more productive that way. That's also fine.

 Except there's another side about community building. DConf is 
 a Joy to watch. Just the community interaction alone and how 
 ideas are shared. It could happen more often. More often online.


I agree with everything you said.

Currently, *each* member of my dev team lives in a different 
country and in a different time zone, so all my day is spent in 
online collaboration (chat, audio and video calls) so I also 
can't understand why there hasn't been a stronger push for this 
kind of communication in D. https://dlang.slack.com/ has been a 
great improvement in this regard from the past couple of years, 
but it is insufficient.
Jun 25 2020
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Jun 25, 2020 at 04:42:36PM +0000, aberba via Digitalmars-d wrote:
[...]

 Almost the exact reason why i use JavaScript (nodejs) for work and not
 D. It takes more than a nice language. When some here say they don't
 use Dub or they don't care about dub packages, I'm wondering what kind
 of software they are writing.


Don't get me wrong, I'm not downplaying dub packages.  But for my
projects, it's mainly local computation and data processing and
transformation.  One project *is* related to publishing on a website,
but it's almost entirely prerendered static pages, so virtually all of
the processing is done in batch-oriented mode beforehand.



 In my line if work, it's highly dependant of availability of packages
 to get the job done. Encryption, networking, data manipulation,
 database connectors, socket, rest, cloud services, etc. Its more like
 glueing services and APIs together.


Actually, even in this area D shines, because of the ease of wrapping
existing C/C++ libraries.  If there's a C API for some library that
provides the functionality you need, it's easy to interface with it.
I've interfaced with e.g. libfreetype, X11, sqlite3, and a bunch of
other libraries, and it's pretty convenient.  Of course, the best is if
there's an existing D binding, then it's just plug-in and go, but even
where there isn't an existing binding, it's still pretty easy to declare
the C prototypes on an as-needed basis (which is what I did with X11 --
translating the entire X11 headers is too much work, and most of the API
I don't even need anyway, so I just declare what I need and add more as
the need arises).



 Unless you're building compilers and softwares that don't connect to
 internet, then it makes sense to not be bothered by the lack of
 certain packages on dub.


It depends on what kind of software you're building, certainly.  If
you're writing code for today that will be obsolete in 2-5 years' time,
then having a dub dependency pull in 200 dependencies is not a problem,
because by the time it becomes a problem you'll already have moved on
anyway.

I write my code to last; so anything that increases the likelihood of
future breakage is a big disincentive for me.  I really do not wish to
be rewriting a module that was working perfectly fine before, but broke
because some obscure dependency or sub-dependency decided to change
things in a way that breaks the way my code uses it. I consider that
time-wasting churn.  That doesn't mean I expect code to be static -- but
any change has to make actual progress, as in fixing a bug or adding a
new feature, or improving the quality of the code, not just change for
change's sake because of external factors completely unrelated to what
I'm doing.



 This will only happen when the community collaborates, which will only
 happen when there's a visible leadership push/backing.


I'm not following this logic.  Why can't the community collaborate in
spite of perceived lack of visible leadership push/backing?  The two are
not mutually exclusive.  In fact, this being a volunteer-driven project,
even if the leadership *does* push for community collaboration, it
doesn't guarantee it will actually happen.  Volunteers do whatever they
want to do, not what they're told to do, after all.


[...]

 I'm not sure why we don't even have regular online community meetups.


Because so far, nobody has stepped up to take charge of it.  Since you
feel so strongly about this, why not be the one to take charge?  Set up
an online meeting, post an announcement here to recruit people, and get
the ball rolling.  Nobody's going to stop you, and in fact, judging by
what many people are saying, probably a lot of people will appreciate
the effort and support you.  If your effort turns out to be successful,
it could even convince the BFDL(s) to officially endorse it.



 Yeah, there's people who would rather code and feel more productive
 that way.  That's also fine.


[...]

Personally, I have very limited time as it is to work on my D projects,
so whatever little time I have, I'd really rather devote to making
progress with my code than to participate in yet another online
meeting/forum/what-not (which I already have more than enough of). But
that's just me, personally; I don't speak for anyone else here.  And I
also have no opposition to such a thing, should you decide to take it
up. I might even support you in the background.  And I'm sure a good
number of people here will support you too, based on what people have
been saying about this.

So how about it?  Since D is lacking in this area, here's your
opportunity to fill the gap.  Show us how to run the community better
than we have been.  We'll support you.  Show us how to make things take
off.


T

-- 
It's bad luck to be superstitious. -- YHL
Jun 25 2020
prev sibling next sibling parent reply Guillaume Piolat <first.name gmail.com> writes:
On Thursday, 25 June 2020 at 06:52:05 UTC, Petar Kirov 
[ZombineDev] wrote:

 The Rust community has realized that a slim standard library + 
 a solid package manager is the way to go.


The practice seems to indicate that the theory is false.

The very first Rust program I built with Rust was an _example_ 
program for the Amethyst game engine (granted, a big endeavour).

It downloaded _146_ packages and then proceeded to build them at 
a glacial pace. This was a really "npm" moment.

In D my _full_ products have 6 packages (24 when counting 
sub-packages).

It seems slim stdlib has enormous community implications and 
require inordinate amount of coordination and agreements ; it 
changes the whole culture.
Jun 25 2020
next sibling parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Thursday, 25 June 2020 at 12:28:27 UTC, Guillaume Piolat wrote:

 On Thursday, 25 June 2020 at 06:52:05 UTC, Petar Kirov 
 [ZombineDev] wrote:

 The Rust community has realized that a slim standard library + 
 a solid package manager is the way to go.


 The practice seems to indicate that the theory is false.

 The very first Rust program I built with Rust was an _example_ 
 program for the Amethyst game engine (granted, a big endeavour).

 It downloaded _146_ packages and then proceeded to build them 
 at a glacial pace. This was a really "npm" moment.

 In D my _full_ products have 6 packages (24 when counting 
 sub-packages).

 It seems slim stdlib has enormous community implications and 
 require inordinate amount of coordination and agreements ; it 
 changes the whole culture.


The only thing that I need to say is that our team uses npm 
(actually yarn) for our stack and we're doing very well :)

So 146 number is pretty laughable in comparison. Running `yarn 
list | wc -l` on a random project of our gives me 7368 :D

Whether this is a good thing is a different question altogether, 
but in practice, this is not an issue at all for us and for 
thousands of other JS/TS teams around the world. What I know is 
that npm and yarn handle this huge (in comparison) number very 
well, but I'm not so sure about Dub. For example, yarn.lock has 
the SHA-512 of each of my dependencies. dub.selections.json only 
includes the version numbers.
Jun 25 2020
parent reply Guillaume Piolat <first.name gmail.com> writes:
On Thursday, 25 June 2020 at 14:41:49 UTC, Petar Kirov 
[ZombineDev] wrote:

 So 146 number is pretty laughable in comparison. Running `yarn 
 list | wc -l` on a random project of our gives me 7368 :D


I'l assume your post isn't satire ^^

This doesn't rezally work for native since:
- there is the cost of compiling this ahead of time, which isn't 
negligible and with a cost structure unlike Javascript (in the 
best case, code has to be compiled in and then stripped by 
linker, very slow)
- native programs have many possibilities to go wrong (deadlocks, 
threading, memory allocations...) and that differs from project 
to project ; you cannot enforce any invariant with such a number 
of libraries. And it's a huge hurdle for "common off the shelf" 
libraries.
Jun 25 2020
parent Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Thursday, 25 June 2020 at 15:30:18 UTC, Guillaume Piolat wrote:

 On Thursday, 25 June 2020 at 14:41:49 UTC, Petar Kirov 
 [ZombineDev] wrote:

 So 146 number is pretty laughable in comparison. Running `yarn 
 list | wc -l` on a random project of our gives me 7368 :D


 I'l assume your post isn't satire ^^


Yes, it's just a real, random data point, which is pretty typical 
for many frontend projects nowadays :/


 This doesn't rezally work for native since:
 - there is the cost of compiling this ahead of time, which 
 isn't negligible and with a cost structure unlike Javascript 
 (in the best case, code has to be compiled in and then stripped 
 by linker, very slow)


I know, I know. We use TypeScript, so our code and many of our 
dependencies actually need to be compiled, before the program can 
be executed. For example, running a project after git clone takes 
between 1-10mins. (When it's more than 2-3 mins it's actually 
because of C/C++. Many nodejs packages are actually C/C++ code 
with JS bindings, which needs to be compiled on npm install, 
because in the npm world, typically they ship only source code 
and not binaries. And also because before Node didn't have a 
stable ABI, so if you wanted to support Node.js versions released 
in the past several years, you would have to ship 20 different 
binaries of the same library :D)
But that's just the first time, because TypeScript and React.js 
(through webpack) have incremental compilation, so each change 
takes less than several seconds (in many cases less than 1 sec). 
By change, I mean the time to typecheck and emit JS code. Of 
course I'm well aware that this is not a fair comparison to pure 
"native" languages.


 - native programs have many possibilities to go wrong 
 (deadlocks, threading, memory allocations...) and that differs 
 from project to project ; you cannot enforce any invariant with 
 such a number of libraries. And it's a huge hurdle for "common 
 off the shelf" libraries.


A fork bomb is possible with almost all languages in practice. 
Every npm package has the ability to run random js code on 
install, which runs with the privileges of the current user. "A 
security nightmare" - you say, but in practice it's not that bad, 
given they have invested much more than us in a process of 
managing security vulnerabilities: 
https://docs.npmjs.com/reporting-a-vulnerability-in-an-npm-package
https://www.npmjs.com/policies/security
Jun 25 2020
prev sibling parent Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Thursday, 25 June 2020 at 12:28:27 UTC, Guillaume Piolat wrote:

 It seems slim stdlib has enormous community implications and 
 require inordinate amount of coordination and agreements ; it 
 changes the whole culture.


I just want to add that this is a *very* important point. We 
definitely need more collaboration and coordination in our 
community. Some examples:
- dstep, dpp, Calypso
- install.sh, dvm, digger (much broader scope, but can also do 
what dvm does, AFAIR), setup-dlang (only usable for GitHub 
actions, but actually replicates the code of install.sh and dvm 
to some extent).
- various  nogc libraries (containers, threading, etc.)
- various networking libraries
- etc.

I guess, the most important thing that I see in other language 
communities that I miss in D is exactly the coordination and 
cooperation. Of course it's very far from perfect in all of them, 
but it still feels that D is falling behind.
And I think that this is not a money problem, but a community and 
leadership problem.
Jun 25 2020
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Jun 25, 2020 at 06:52:05AM +0000, Petar via Digitalmars-d wrote:
[...]

 I suggest checking http://mir-algorithm.libmir.org/.
 Ilya has been doing a truly amazing job at both developing,
 maintaining and optimizing this library.
 Also he has put a hard focus on memory allocators,  nogc and betterC
 (for exposing libmir to C and C++ users and also for scripting
 languages like Python or Julia).


I'm aware of Ilya's work, and have been meaning to look it up, but
haven't had the time. And also I'm working with different constraints: I
primarily work with batch-oriented computations, so  nogc is not really
on my radar (though I do try to minimize GC use for obvious reasons),
and betterC isn't really under consideration for what I need to do. So
these factors in Mir don't really stand out to me as much as they may to
others.


[...]

 Meanwhile, if you look at std.numeric, for past several years,
 basically all contributions but a few have been just around basic
 stuff like code style, imports and fixing a few compile errors in
 generic code.


I'm not sure what this has to do with anything. If an algorithm is
solidly implemented, why would there need to be a continuous stream of
changes?  And just because something is changing quickly, doesn't
necessarily equate to higher quality.



 Phobos is dead. There haven't been any new modules since ~2016.
 Actually the last one (IIRC) was std.experimental.ndslice, which Ilya
 contributed and then removed (1-2 releases after) from Phobos to start
 libmir.
 
 Since std.experimental.allocator was added to Phobos circa 2015, there
 hasn't been a single Phobos or Druntime module using it (ndslice and
 checkedint don't count). Many packages on code.dlang.org
 enthusiastically embraced std.experimental.allocator only to get
 burned a few dmd releases after as Phobos doesn't follow SemVer.


Um... it's std.*experimental* for a reason?  Why are people surprised
when it changes?

OTOH, though, you do have a valid point about the distribution model.
Phobos is locked to compiler releases, and while that does have its
advantages in some areas, it also comes with disadvantages.



 The solution? Many of the most popular OSS D apps libraries (I can
 only comment on those) transitioned to using the Dub fork:
 https://github.com/dlang-community/stdx-allocator. How does it help?
 Well, OSS D libraries can't control the compiler that their users are
 using. For example, vibe.d tries to support the last 5 major versions
 of dmd/ldc, and Dub the last 15+ major versions. This means they can't
 depend on std.experimental.* as there's no telling what kind changes
 can happen for such a large timespan. Instead they can stick a
 particular version of https://code.dlang.org/packages/stdx-allocator
 in their dub.{json,sdl} file and be sure that it won't suddenly break
 their code.


This is a good case to make for prospective new Phobos modules to start
out as Dub packages, gain some real-world usage and traction, then
promote to Phobos.  Introducing packages directly into Phobos (via
std.experimental or otherwise) has proven to be high-risk, and in some
cases disastrous.



 The sooner we realize this and start collectively working on improving
 Dub and code.dlang.org, the better. Yes, Dub is not a great build
 tool. And so what? Most great build tools were not so great in their
 infancy. I doubt Scons was much better in 1999. If people continue
 avoiding Dub for whatever reason it won't get better by itself.


In 1999, SCons was not yet; there was its predecessor Cons, which has a
hard-to-maintain Perl script.  But the basic concepts that make it
awesome were already there.  This is a key point: it started out on the
right principles, and even though the implementation left some things to
be desired, it had the right footing and therefore had the foundation to
move on to be even better.  Dub, IMO, started out with the wrong
principles, or should I say, different principles from what I expect a
build tool to have, and therefore unless it undergoes a fundamental,
breaking rewrite from ground up, I doubt it will ever reach my
expectations of a build tool.

There are many advantages to integrating a build tool with a package
manager, I suppose, but TBH the way Dub does it is rather disappointing.
IMO, a package manager ought to be distinct from a build tool, even if
they do build(!) off each other.  Dub is actually not bad as a package
manager, but as a build tool I simply cannot vouch for it.

If you were to ask me, the first step to improving Dub would be to
separate the package manager from the build tool. As in, completely
extricate one from another so that they are usable as independent
pieces. (Note: this does not mean the user-facing driver cannot depend
on both at the same time.)

The next step, IMO, would be to separate the package manager code from
its unfriendly user-interface and make it dub-as-a-library.  That would
be something I can work with.



 There's no reason why Dub can't expose a lower-level DSL for precise
 target dependency graph building. It's just a matter of people making
 a sustained effort in contributing one.


TBH, I would much rather have dub-as-a-library than to try to
monkey-patch yet another hack on top of a foundation not designed to
support this sort of usage.



 The Rust community has realized that a slim standard library + a solid
 package manager is the way to go.


[...]

TBH, lately I've become skeptical of this approach.

More than a few times, I have been bitten by (non-D) libraries I depend
on (in my non-D projects) that have either become too obsolete and
doesn't compile anymore, or the new version has breaking changes that
cannot be easily worked around, or the network resource serving that
library has mysteriously vanished into the ether, never to be found
again, and also by external tools whose interfaces have changed, or
worst of all, whose behaviour has subtly changed in fundamentally
incompatible ways that cannot be remedied.  Also lately, shared
libraries that broke ABI compatibility just because I upgraded an OS
package, causing half of my programs to instantly become unrunnable.

As a result, I've become highly skeptical about the whole code reuse
mantra.  Where's the actual code reuse when it entails installing 5
different versions of the same library just because different programs
(or worse, different components of the same program) depend on different
versions?  This is dependency hell reincarnated.  What's the use of
depending on external programs that vanish into the ether, or get
changed in incompatible ways so that the only recourse is to keep a copy
of the old code around forever? (Fortunately, I only use open source
tools for this purpose; at least I keep a copy of the code around as
long as it remains compilable; imagine the disaster if it was a
proprietary tool that's no longer maintained, vanished into the ether,
or plain just doesn't run anymore on the latest OS.)

That's why I generally avoid libraries that have deep dependencies --
imagine all of the above multiplied recursively per dependent package.
Truly it's dependency hell reincarnated.  Instead, I look for libraries
like Adam Ruppe's arsd library, where most of the code has minimal
dependencies and can be used by literally just copying the danged file
into your source tree, where it will always be available, and is
guaranteed to be exactly the same code you last left it as and won't
subtly change and break stuff because some 3rd party network resource
somewhere out there in the ether decided to change it.  And where
calling a single lousy function does not pull in 2,345 irrelevant
dependencies that slow your build time down to an unusable crawl.

(And TBH, any library that requires pulling in that many recursive
dependencies makes me skeptical as to the quality of its design. IMNSHO
a properly-designed library ought to be as orthogonal as possible to
anything else, and to focus solely on providing that special
functionality that is its raison d'etre, and nothing else. It isn't as
though this is C, where composability is limited and a lot of external
things have to be baked into the library API just for it to be generally
applicable; in D we have metaprogramming, delegates, and all of that
good stuff that can be employed to eliminate all unnecessary library
dependencies and provide a powerful composable API that's completely
orthogonal to whatever's outside of its purview.  If a library requires
234 dependencies in order to do its job, perhaps it should get a new
job! :-P)


T

-- 
Живёшь только однажды.
Jun 25 2020
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 25 June 2020 at 16:20:54 UTC, H. S. Teoh wrote:

 On Thu, Jun 25, 2020 at 06:52:05AM +0000, Petar via 
 Digitalmars-d wrote: [...]

 I suggest checking http://mir-algorithm.libmir.org/.
 Ilya has been doing a truly amazing job at both developing,
 maintaining and optimizing this library.
 Also he has put a hard focus on memory allocators,  nogc and 
 betterC
 (for exposing libmir to C and C++ users and also for scripting
 languages like Python or Julia).


 I'm aware of Ilya's work, and have been meaning to look it up, 
 but haven't had the time. And also I'm working with different 
 constraints: I primarily work with batch-oriented computations, 
 so  nogc is not really on my radar (though I do try to minimize 
 GC use for obvious reasons), and betterC isn't really under 
 consideration for what I need to do. So these factors in Mir 
 don't really stand out to me as much as they may to others.

 [snip]


BTW, `mir` is not always and everywhere  nogc. It can be mixed 
with GC code. For instance, the `sliced` function will use the GC 
to allocate a slice. However, it also has facilities for 
allocating malloc'ed and referenced-counted slices. However, one 
design goal is that it can also be used  nogc.
Jun 29 2020
parent Andy Balba <pwplus7 gmail.com> writes:
On Monday, 29 June 2020 at 19:37:37 UTC, jmh530 wrote:

 On Thursday, 25 June 2020 at 16:20:54 UTC, H. S. Teoh wrote:

 [...]


 BTW, `mir` is not always and everywhere  nogc. It can be mixed 
 with GC code. For instance, the `sliced` function will use the 
 GC to allocate a slice. However, it also has facilities for 
 allocating malloc'ed and referenced-counted slices. However, 
 one design goal is that it can also be used  nogc.


BTW IMNSHO TBH  nogc everything !
Aug 10 2020
prev sibling next sibling parent Chris <wendlec tcd.ie> writes:
On Wednesday, 24 June 2020 at 21:37:37 UTC, H. S. Teoh wrote:

 3) Just today, I needed to implement a fast Fourier transform. 
 Not expecting this to be in Phobos, I was glancing over various 
 algorithms to decide which one suited my use case best and is 
 easy enough to implement quickly. And then I discovered 
 std.numeric.Fft, already done and nicely-packaged and ready to 
 use.  Total win!!


What if the language you're using doesn't have FFT in its 
standard lib? Hm. Maybe this would be a good starting point:

http://rosettacode.org/wiki/Fast_Fourier_transform

Maybe in other languages there are third party libraries that 
handle things like FFT, well, so I have heard. Never mind.
Jun 25 2020
prev sibling next sibling parent reply Jordan Wilson <wilsonjord gmail.com> writes:
On Wednesday, 24 June 2020 at 21:37:37 UTC, H. S. Teoh wrote:

 Phobos sometimes gets a bad name around these parts, but 
 actually it's pretty cool (in spite of well-known warts).  One 
 of the cool things about it is the batteries-included 
 philosophy that used to be its guiding principle.  Over the 
 course of my usage of D, the following have stood out as being 
 particularly convenient when I needed it:

 [...]


I don't think I'm a good enough programmer to know that Phobos is 
bad.
import std.stdio;
import std.algorithm;
import std.range;
import std.conv : to;

and I'm a happy man!

Jordan
Jun 25 2020
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jun 26, 2020 at 03:02:20AM +0000, Jordan Wilson via Digitalmars-d wrote:
[...]

 I don't think I'm a good enough programmer to know that Phobos is bad.
 import std.stdio;
 import std.algorithm;
 import std.range;
 import std.conv : to;
 
 and I'm a happy man!


[...]

These days, if you use a recent compiler, it's even easier:

	import std;

And off you go. :-P

Only catch is, sometimes you might run into some unfortunate name
conflicts within Phobos (e.g., std.file.remove vs.
std.algorithm.remove).  But for the most part, it's very convenient for
one-off scripts.

Even better yet, I've recently acquired the taste for one-line D
programs using `dmd -i -run -`, and a lot of these take advantage of
`import std;` for its conciseness:



	echo 'import std;void main(){writeln("Hello world");}' | dmd -run -


	echo 'import std;pragma(msg, PI);' | dmd -o- -


	echo 'import std;void main(){writeln([1,2,3].canFind(1));}' | dmd -run -

And also, one-line tests of code in the current directory tree:



	echo 'import mymod;pragma(msg, typeof(mymod.someSymbol));' | dmd -i -o- -


	echo 'import mymod;pragma(msg, is(typeof(myFun(3.14f))));' | dmd -i -o- -


	echo 'import mymod;void main(){writeln(myFun(3.14f));}' | dmd -i -run -

Or generate complex output for other programs using the expressive power
of D code:


	echo 'import std;void main(){writeln(iota(0.0,
100.0).map!(x=>sin(x)).filter!(x=>x > 0.5));}' |  dmd -run - | sort


Maybe we should have a Most Useful One-Line D Program contest. :-P


T

-- 
People say I'm arrogant, and I'm proud of it.
Jun 25 2020
next sibling parent Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Friday, 26 June 2020 at 05:39:59 UTC, H. S. Teoh wrote:



 	echo 'import std;void main(){writeln("Hello world");}' | dmd 
 -run -


 	echo 'import std;pragma(msg, PI);' | dmd -o- -


 	echo 'import std;void main(){writeln([1,2,3].canFind(1));}' | 
 dmd -run -

 And also, one-line tests of code in the current directory tree:



 	echo 'import mymod;pragma(msg, typeof(mymod.someSymbol));' | 
 dmd -i -o- -


 	echo 'import mymod;pragma(msg, is(typeof(myFun(3.14f))));' | 
 dmd -i -o- -


 	echo 'import mymod;void main(){writeln(myFun(3.14f));}' | dmd 
 -i -run -

 Or generate complex output for other programs using the 
 expressive power of D code:


 	echo 'import std;void main(){writeln(iota(0.0, 
 100.0).map!(x=>sin(x)).filter!(x=>x > 0.5));}' |  dmd -run - | 
 sort


 Maybe we should have a Most Useful One-Line D Program contest. 
 :-P


 T


I’ll make a mental bookmark of this, thanks!

— Bastiaan.
Jun 26 2020
prev sibling next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Friday, 26 June 2020 at 05:39:59 UTC, H. S. Teoh wrote:


 Maybe we should have a Most Useful One-Line D Program contest. 
 :-P


Or a blog post showing off all of this and explaining the 
compiler flags :-)
Jun 26 2020
parent reply tastyminerals <tastyminerals gmail.com> writes:
On Friday, 26 June 2020 at 09:10:57 UTC, Mike Parker wrote:

 On Friday, 26 June 2020 at 05:39:59 UTC, H. S. Teoh wrote:


 Maybe we should have a Most Useful One-Line D Program contest. 
 :-P


 Or a blog post showing off all of this and explaining the 
 compiler flags :-)


That would be great if someone could do this! I would like to 
learn and show off the D one-liners in the company.
Jul 08 2020
parent reply aberba <karabutaworld gmail.com> writes:
On Wednesday, 8 July 2020 at 08:48:52 UTC, tastyminerals wrote:

 On Friday, 26 June 2020 at 09:10:57 UTC, Mike Parker wrote:

 On Friday, 26 June 2020 at 05:39:59 UTC, H. S. Teoh wrote:


 Maybe we should have a Most Useful One-Line D Program 
 contest. :-P


 Or a blog post showing off all of this and explaining the 
 compiler flags :-)


 That would be great if someone could do this! I would like to 
 learn and show off the D one-liners in the company.


How interested are you in making this D one-line showcasing thing 
happen? Been thinking, its something that needs to happen.
Jul 17 2020
parent reply aberba <karabutaworld gmail.com> writes:
On Friday, 17 July 2020 at 20:41:57 UTC, aberba wrote:

 On Wednesday, 8 July 2020 at 08:48:52 UTC, tastyminerals wrote:

 On Friday, 26 June 2020 at 09:10:57 UTC, Mike Parker wrote:

 On Friday, 26 June 2020 at 05:39:59 UTC, H. S. Teoh wrote:


 Maybe we should have a Most Useful One-Line D Program 
 contest. :-P


 Or a blog post showing off all of this and explaining the 
 compiler flags :-)


 That would be great if someone could do this! I would like to 
 learn and show off the D one-liners in the company.


 How interested are you in making this D one-line showcasing 
 thing happen? Been thinking, its something that needs to happen.


Especially now that there's some momentum in getting the D wiki 
up to speed.
Jul 17 2020
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jul 17, 2020 at 08:44:40PM +0000, aberba via Digitalmars-d wrote:

 On Friday, 17 July 2020 at 20:41:57 UTC, aberba wrote:

 On Wednesday, 8 July 2020 at 08:48:52 UTC, tastyminerals wrote:




[...]

 That would be great if someone could do this! I would like to
 learn and show off the D one-liners in the company.


 
 How interested are you in making this D one-line showcasing thing
 happen? Been thinking, its something that needs to happen.


 
 Especially now that there's some momentum in getting the D wiki up to
 speed.


Check out the scriptlike dub package.  It has a bunch of stuff that
makes scripting tasks easier (i.e., less verbose).  If you have
scriptlike installed, one-liners could potentially be even more compact.


T

-- 
Don't modify spaghetti code unless you can eat the consequences.
Jul 17 2020
parent aberba <karabutaworld gmail.com> writes:
On Friday, 17 July 2020 at 21:14:19 UTC, H. S. Teoh wrote:

 On Fri, Jul 17, 2020 at 08:44:40PM +0000, aberba via 
 Digitalmars-d wrote:

 On Friday, 17 July 2020 at 20:41:57 UTC, aberba wrote:

 On Wednesday, 8 July 2020 at 08:48:52 UTC, tastyminerals 
 wrote:




 [...]

 That would be great if someone could do this! I would like 
 to learn and show off the D one-liners in the company.


 
 How interested are you in making this D one-line showcasing 
 thing happen? Been thinking, its something that needs to 
 happen.


 
 Especially now that there's some momentum in getting the D 
 wiki up to speed.


 Check out the scriptlike dub package.  It has a bunch of stuff 
 that makes scripting tasks easier (i.e., less verbose).  If you 
 have scriptlike installed, one-liners could potentially be even 
 more compact.


 T


Interesting. It's very well documented too.
Jul 17 2020
prev sibling parent reply Jordan Wilson <wilsonjord gmail.com> writes:
On Friday, 26 June 2020 at 05:39:59 UTC, H. S. Teoh wrote:

 On Fri, Jun 26, 2020 at 03:02:20AM +0000, Jordan Wilson via 
 Digitalmars-d wrote: [...]

 [...]


 [...]

 These days, if you use a recent compiler, it's even easier:

 [...]


Just now I wanted to find the max value of a column in a text 
file, my thinking went "Excel? It'll take ages to load...I'll 
just google awk or something...hang on a minute, didn't I read 
somewhere about D oneliners?"

echo 'import std; void main() { 
File("emu.sift","r").byLine.map!(a => a.splitter(" 
").front.to!double).maxElement.writeln; }' | dmd -run -

Thanks!

Jordan
Jul 06 2020
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Jul 06, 2020 at 08:47:36PM +0000, Jordan Wilson via Digitalmars-d wrote:
[...]

 Just now I wanted to find the max value of a column in a text file, my
 thinking went "Excel? It'll take ages to load...I'll just google awk
 or something...hang on a minute, didn't I read somewhere about D
 oneliners?"
 
 echo 'import std; void main() { File("emu.sift","r").byLine.map!(a =>
 a.splitter(" ").front.to!double).maxElement.writeln; }' | dmd -run -


[...]

Awesome stuff!!  We should collect a library of these one-liners, maybe
on the wiki or something, that can serve as a useful reference.  It can
also be used to show off D's capabilities too.


T

-- 
"You are a very disagreeable person." "NO."
Jul 07 2020
parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Tuesday, 7 July 2020 at 22:29:36 UTC, H. S. Teoh wrote:

 [...]

 Awesome stuff!!  We should collect a library of these 
 one-liners, maybe on the wiki or something, that can serve as a 
 useful reference.  It can also be used to show off D's 
 capabilities too.


 T


dmd -run code.d | dmd -
Jul 09 2020
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 9 July 2020 at 15:31:32 UTC, Petar Kirov 
[ZombineDev] wrote:

 On Tuesday, 7 July 2020 at 22:29:36 UTC, H. S. Teoh wrote:

 [...]

 Awesome stuff!!  We should collect a library of these 
 one-liners, maybe on the wiki or something, that can serve as 
 a useful reference.  It can also be used to show off D's 
 capabilities too.


 T


 dmd -run code.d | dmd -


So that compiles and runs code.d and then passes the result to 
dmd to build?
Jul 09 2020
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Jul 09, 2020 at 03:58:19PM +0000, jmh530 via Digitalmars-d wrote:

 On Thursday, 9 July 2020 at 15:31:32 UTC, Petar Kirov [ZombineDev] wrote:

 On Tuesday, 7 July 2020 at 22:29:36 UTC, H. S. Teoh wrote:

 [...]
 
 Awesome stuff!!  We should collect a library of these one-liners,
 maybe on the wiki or something, that can serve as a useful
 reference.  It can also be used to show off D's capabilities too.
 
 
 T


 
 dmd -run code.d | dmd -


 
 So that compiles and runs code.d and then passes the result to dmd to build?


Meaning, code.d generates D code that is run on the spot.

Here's another one: the most powerful one-line D program that ever
existed and will ever exist. It can do literally anything you tell it
do, and best of all, it doesn't even take up that much space.  In fact,
it takes literally no disk space at all.  All you have to do is to run
the following one-liner, and type in what you want it to do as D code,
and it will do it!  How amazing is that???

	cat | dmd -run -

:-P


T

-- 
Give me some fresh salted fish, please.
Jul 09 2020
parent reply tastyminerals <tastyminerals gmail.com> writes:
On Thursday, 9 July 2020 at 16:26:09 UTC, H. S. Teoh wrote:

 On Thu, Jul 09, 2020 at 03:58:19PM +0000, jmh530 via 
 Digitalmars-d wrote:

 On Thursday, 9 July 2020 at 15:31:32 UTC, Petar Kirov 
 [ZombineDev] wrote:

 On Tuesday, 7 July 2020 at 22:29:36 UTC, H. S. Teoh wrote:

 [...]


 
 dmd -run code.d | dmd -


 
 So that compiles and runs code.d and then passes the result to 
 dmd to build?


 Meaning, code.d generates D code that is run on the spot.

 Here's another one: the most powerful one-line D program that 
 ever existed and will ever exist. It can do literally anything 
 you tell it do, and best of all, it doesn't even take up that 
 much space.  In fact, it takes literally no disk space at all.  
 All you have to do is to run the following one-liner, and type 
 in what you want it to do as D code, and it will do it!  How 
 amazing is that???

 	cat | dmd -run -

 :-P


 T


Without args cat reads from stdin and outputs to stdout which dmd 
-run - catches.
However, I typed writeln("hello D"); after the one-liner above, 
hit enter and nothing happened. Hit enter again, nothing.
Jul 16 2020
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Jul 16, 2020 at 06:41:42PM +0000, tastyminerals via Digitalmars-d wrote:

 On Thursday, 9 July 2020 at 16:26:09 UTC, H. S. Teoh wrote:


[...]

 Here's another one: the most powerful one-line D program that ever
 existed and will ever exist. It can do literally anything you tell
 it do, and best of all, it doesn't even take up that much space.  In
 fact, it takes literally no disk space at all.  All you have to do
 is to run the following one-liner, and type in what you want it to
 do as D code, and it will do it!  How amazing is that???
 
 	cat | dmd -run -
 
 :-P
 
 
 T


 
 Without args cat reads from stdin and outputs to stdout which dmd -run
 - catches.
 However, I typed writeln("hello D"); after the one-liner above, hit
 enter and nothing happened. Hit enter again, nothing.


You have to end your input with ctrl-D.  DMD is not a REPL so it's not
going to evaluate individual input lines immediately.

But anyway, this particular one is a joke that refers to one of the
winning entries of the IOCCC from 1988 (see the entry by spinellis),
consisting of the single line:

	#include "/dev/tty"

It probably no longer works on modern C compilers, but the intent ought
to be obvious. :-)


T

-- 
We are in class, we are supposed to be learning, we have a teacher... Is it too
much that I expect him to teach me??? -- RL
Jul 16 2020
prev sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Monday, 6 July 2020 at 20:47:36 UTC, Jordan Wilson wrote:

 Just now I wanted to find the max value of a column in a text 
 file, my thinking went "Excel? It'll take ages to load...I'll 
 just google awk or something...hang on a minute, didn't I read 
 somewhere about D oneliners?"

 echo 'import std; void main() { 
 File("emu.sift","r").byLine.map!(a => a.splitter(" 
 ").front.to!double).maxElement.writeln; }' | dmd -run -

 Thanks!

 Jordan


IMO this still doesn't hold a candle to the awk version:

     awk '{ if ($1 > max) max = $1 } END { print max }'

With better library functions, though, the D version could be 
much, much nicer. Something like:

     stdin.byRecord.map(r => r.fields[0]).maxElement
Jul 07 2020
next sibling parent reply Jordan Wilson <wilsonjord gmail.com> writes:
On Tuesday, 7 July 2020 at 23:38:26 UTC, Paul Backus wrote:

 On Monday, 6 July 2020 at 20:47:36 UTC, Jordan Wilson wrote:

 Just now I wanted to find the max value of a column in a text 
 file, my thinking went "Excel? It'll take ages to load...I'll 
 just google awk or something...hang on a minute, didn't I read 
 somewhere about D oneliners?"

 echo 'import std; void main() { 
 File("emu.sift","r").byLine.map!(a => a.splitter(" 
 ").front.to!double).maxElement.writeln; }' | dmd -run -

 Thanks!

 Jordan


 IMO this still doesn't hold a candle to the awk version:

     awk '{ if ($1 > max) max = $1 } END { print max }'

 With better library functions, though, the D version could be 
 much, much nicer. Something like:

     stdin.byRecord.map(r => r.fields[0]).maxElement


Oh I agree the awk version is nicer (as is your theoretical D 
version). But I couldn't write that off the top of my head, 
whereas the D version I could.

Here's something I just did now that might be more relevant:
echo 'import std; void main() { 
"bets.json".readText.parseJSON.toPrettyString.writeln; }' | dmd 
-run - | more

I did this without looking up anything. Whereas before this 
echo/import std; into dmd -run trick, I would have opened up vim, 
and hoped that my previous command to pretty print was still in 
the history! (using python if I remember correctly).

I *think* that writing a more slightly more verbose D one-liner 
without needing to reference anything might prove itself useful 
to me in the long run, but we shall see.

Jordan
Jul 07 2020
next sibling parent reply Panke <tobias pankrath.net> writes:
On Wednesday, 8 July 2020 at 03:53:55 UTC, Jordan Wilson wrote:

 Here's something I just did now that might be more relevant:
 echo 'import std; void main() { 
 "bets.json".readText.parseJSON.toPrettyString.writeln; }' | dmd 
 -run - | more

 I did this without looking up anything. Whereas before this 
 echo/import std; into dmd -run trick, I would have opened up 
 vim, and hoped that my previous command to pretty print was 
 still in the history! (using python if I remember correctly).



 Jordan


Have a look at jq [1] and jqed. What's up with the bets? Writing 
a betfair bot by any chance?

[1] https://stedolan.github.io/jq/
Jul 08 2020
parent Jordan Wilson <wilsonjord gmail.com> writes:
On Wednesday, 8 July 2020 at 07:39:03 UTC, Panke wrote:

 On Wednesday, 8 July 2020 at 03:53:55 UTC, Jordan Wilson wrote:

 Here's something I just did now that might be more relevant:
 echo 'import std; void main() { 
 "bets.json".readText.parseJSON.toPrettyString.writeln; }' | 
 dmd -run - | more

 I did this without looking up anything. Whereas before this 
 echo/import std; into dmd -run trick, I would have opened up 
 vim, and hoped that my previous command to pretty print was 
 still in the history! (using python if I remember correctly).



 Jordan


 Have a look at jq [1] and jqed.


After writing the post, I recalled that several months ago I 
actually did install jq for that very issue of just quickly 
inspecting a json file, but clearly forgot all about it. I 
suppose it illustrates my general point...a familiar sledgehammer 
might be more useful than an unfamiliar hammer.


 What's up with the bets?


Haha, not a bot, but rather data gathering of NBA odds (before 
everything was shut down).

Jordan
Jul 08 2020
prev sibling parent reply Ogi <ogion.art gmail.com> writes:
Maybe we should add an option to rdmd that compile and run a 
string, importing std automatically? Writing one-liners would be 
as easy as
rdmd -dscript 'writeln("hello, shell");'
Jul 08 2020
next sibling parent reply Dennis <dkorpel gmail.com> writes:
On Wednesday, 8 July 2020 at 10:15:17 UTC, Ogi wrote:

 Maybe we should add an option to rdmd that compile and run a 
 string, importing std automatically? Writing one-liners would 
 be as easy as
 rdmd -dscript 'writeln("hello, shell");'


rdmd --eval 'writeln("hello, shell");'

```
   --eval=code        evaluate code as in perl -e (multiple --eval 
allowed)
   --loop             assume "foreach (line; stdin.byLine()) { ... 
}" for eval
```
Jul 08 2020
parent Ogi <ogion.art gmail.com> writes:
On Wednesday, 8 July 2020 at 10:34:55 UTC, Dennis wrote:

 On Wednesday, 8 July 2020 at 10:15:17 UTC, Ogi wrote:

 Maybe we should add an option to rdmd that compile and run a 
 string, importing std automatically? Writing one-liners would 
 be as easy as
 rdmd -dscript 'writeln("hello, shell");'


 rdmd --eval 'writeln("hello, shell");'

 ```
   --eval=code        evaluate code as in perl -e (multiple 
 --eval allowed)
   --loop             assume "foreach (line; stdin.byLine()) { 
 ... }" for eval
 ```


Whoa! rdmd is cool, too.
Jul 08 2020
prev sibling parent MoonlightSentinel <moonlightsentinel disroot.org> writes:
On Wednesday, 8 July 2020 at 10:15:17 UTC, Ogi wrote:

 Maybe we should add an option to rdmd that compile and run a 
 string, importing std automatically? Writing one-liners would 
 be as easy as
 rdmd -dscript 'writeln("hello, shell");'


Try rdmd --eval='writeln("hello, shell");'
Jul 08 2020
prev sibling parent Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
On Tuesday, 7 July 2020 at 23:38:26 UTC, Paul Backus wrote:

 On Monday, 6 July 2020 at 20:47:36 UTC, Jordan Wilson wrote:

 echo 'import std; void main() { 
 File("emu.sift","r").byLine.map!(a => a.splitter(" 
 ").front.to!double).maxElement.writeln; }' | dmd -run -

 Thanks!

 Jordan


 IMO this still doesn't hold a candle to the awk version:

     awk '{ if ($1 > max) max = $1 } END { print max }'

 With better library functions, though, the D version could be 
 much, much nicer. Something like:

     stdin.byRecord.map(r => r.fields[0]).maxElement


Not in one liner form

readText("emu.sift").csvReader!(Tuple!(double))(' ').map!(x => 
x[0]).maxElement.writeln;

I wanted to us

https://dlang.org/phobos/std_range.html#transversal

But that didn't work for a few reasons. It would be nice because 
this example isn't good if trying to do something with say the 25 
element.
Jul 07 2020
prev sibling parent reply Robert Schadek <rschadek symmetryinvestments.com> writes:
On Friday, 26 June 2020 at 03:02:20 UTC, Jordan Wilson wrote:

 I don't think I'm a good enough programmer to know that Phobos 
 is bad.
 import std.stdio;
 import std.algorithm;
 import std.range;
 import std.conv : to;

 and I'm a happy man!

 Jordan


I'm a real noob as well. I'm so bad, I also import std.format.
Jun 29 2020
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Jun 29, 2020 at 12:20:23PM +0000, Robert Schadek via Digitalmars-d
wrote:

 On Friday, 26 June 2020 at 03:02:20 UTC, Jordan Wilson wrote:

 
 I don't think I'm a good enough programmer to know that Phobos is bad.
 import std.stdio;
 import std.algorithm;
 import std.range;
 import std.conv : to;
 
 and I'm a happy man!
 
 Jordan


 
 I'm a real noob as well. I'm so bad, I also import std.format.


LOL!  I *always* import std.format, it's so convenient, I can't live
without it!  In spite of its very well-known flaws.


T

-- 
It's bad luck to be superstitious. -- YHL
Jun 29 2020
prev sibling parent tastyminerals <tastyminerals gmail.com> writes:
On Wednesday, 24 June 2020 at 21:37:37 UTC, H. S. Teoh wrote:

 Phobos sometimes gets a bad name around these parts, but 
 actually it's pretty cool (in spite of well-known warts).  One 
 of the cool things about it is the batteries-included 
 philosophy that used to be its guiding principle.  Over the 
 course of my usage of D, the following have stood out as being 
 particularly convenient when I needed it:

 1) std.bigint: one time, I was working on a quadratic 
 irrational arithmetic module, and pretty quickly discovered 
 that numerical overflow was a problem that cropped up pretty 
 often.  Or rather, I was seeing what I *thought* was caused by 
 arithmetic overflow, and wanted to be sure.  Solution?  Easy: 
 templatize the coefficient type, import std.bigint, and within 
 several minutes, I have a working implementation that can 
 support arbitrarily large coefficients -- with which I not only 
 confirmed that the observed problems were caused by arithmetic 
 overflow, but also obtained a working solution simultaneously.  
 Win!

 2) std.numeric.poly: another time, I had to work with 
 evaluating a bunch of polynomials, and specifically, with 
 evaluating their roots quickly and accurately.  I could roll my 
 own, poorly, and get results that may or may not be 
 highly-skewed by accumulated errors... or I could use 
 std.numeric.poly to get a reliable evaluation of the 
 polynomial, and, better yet, use std.numeric.findRoot to 
 compute roots with the confidence that the value I get will 
 have as small an error as is possible within the constraints of 
 built-in hardware floats. Plus, this saved me tons of 
 development and debugging time to roll my own solution. Win!

 3) Just today, I needed to implement a fast Fourier transform. 
 Not expecting this to be in Phobos, I was glancing over various 
 algorithms to decide which one suited my use case best and is 
 easy enough to implement quickly. And then I discovered 
 std.numeric.Fft, already done and nicely-packaged and ready to 
 use.  Total win!!

 Seriously, D + Phobos is cool beans.  Yes it's not perfect -- 
 the language has its fair share of dark corners, WATs, and 
 Phobos has its share of poorly-designed APIs and outdated 
 modules.  But seriously, a lot of what's currently there is 
 pretty darned cool, and we shouldn't let all the bad stuff 
 cloud our appreciation of just how cool it already is.


 T


I was honestly surprised to read here that Phobos gets a bad 
name. But I am not a D expert to judge anyway.

For example, I simply can't stand Python stdlib docs and only go 
there when everything else fails.
They are really hard to read for me for some unknown reason 
(design, wording or both?) and I know that I am not alone in 
this. But Python can get away with it, right and why's that? :)
On the contrary Scala standard library is a great example of 
being well written and designed.

Personally, I was impressed by Phobos once I started going 
through the docs for the first time after reading Ali's 
"Programming in D" book. It is actually Phobos that made me 
believe that D has a solid and rich standard library. I was 
pleasantly surprised that description of many functions contained 
complexity information and pragmatically explained how things 
work.
For example, std.algorithm contains many cool things like 
"balancedParens" or "levenshteinDistance" (which even Python 
doesn't have and needs an external C++ lib to use). I like how 
each module is split into logical groups and how the function 
names are simply linguistically more precise. If there is no a 
function that you expect to have, you get a feeling that it is 
not there because it is probably a one liner in D or something 
that should be done with the available tools. I also like the 
general design and layout. It is all very readable. All that 
persuaded me to proceed with the language further. My only 
critique or rather a wish would be more code examples.
Of course, I can imagine things are not all pretty for people 
working with D for many years and it is absolutely fine. It 
should be like this because there will be no challenge and 
therefore progress. However, from beginners view Phobos is cool.
Jul 08 2020