Why Phobos is cool

[Chris]

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.