Females in the community.

[Bruno Medeiros via Digitalmars-d]

On 24/03/2016 17:07, Vladimir Panteleev wrote:
> On Thursday, 24 March 2016 at 16:46:53 UTC, Bruno Medeiros wrote:
>> It is, *however*, illustrative of a larger issue I have with the
>> mindset and attitude of the core D team: that there are several
>> aspects there that I consider antiquated, or narrow-minded. Please
>> don't take this as a personal offense Walter, it's not meant as such.
>> But:
>
> Sorry, but this is complete FUD.
>
>> Not understanding the importance of package managers is another (DUB
>> still not part of official distro?) Compare with Rust's Cargo.
>
> Dub is not part of the distro because the Dub maintainers don't consider
> it ready. Everyone wants it packaged. We are waiting for it to
> stabilize. If you want to help, start with
> https://github.com/D-Programming-Language/dub/issues.
>

What does it meant for DUB to be "ready"? Does it need to be a "1.0" 
release? To have API, command line, and file formats all stabilized?

I'm not sure that's necessary. As long as DUB is popular and usable (and 
it is already), it could already do well to be included in the distro. 
Being "official" doesn't have to mean ready and finished!

Cargo is still version 0.7, despite Rust itself being 1.6 currently. So 
it's still "beta", but that didn't preclude it from being included.


Mind one important thing though, what I'm looking for is not just merely 
DUB being included in the official D distribution. Having one less 
package to download is not what's important here. What's significant is 
DUB becoming "official", that is, the core D team should be familiar 
with it, use it when appropriate, and, if something were to happen to 
Sonke (even simply him not wanting to work on DUB anymore), there should 
be a commitment from the core D team to work on DUB themselves on such 
scenario. This is what I mean when I talks about understanding the 
importance of package managers.


>> Not understanding the importance of IDE tooling is another. Compare
>> with Rust planned support for IDE tooling from the Mozilla team
>> itself. (https://github.com/rust-lang/rfcs/blob/master/text/1317-ide.md)
>
> No, this is completely understood. We simply do not have the resources
> for that. I think we've done everything reasonable to promote Visual D,
> for example - it's linked from the website, it's in the GitHub
> organization, it's in the installer, what more do you want? Unlike
> Mozilla, we can't hire people to work on things full-time.
>

First, I don't think promoting a single IDE is not a good idea. But hey, 
I'm the main developer of DDT, so maybe I'm biased!... ;)

More importantly, this has nothing to do with promoting any set of IDEs. 
The D users are smart enough, they can find the list of IDEs that are 
available for their tastes.

What I'm talking about is making IDE's *better*. I'm talking about doing 
work in tools like DCD ( https://github.com/Hackerpilot/DCD ) - which 
are IDE/editor agnostic anyway. Or even working in DMD or DUB 
functionality that is mainly of use to IDEs/editors.

Now, I can't blame Walter and Andrei for not having the same resources 
as Mozilla, but that's not what I did. What I was saying is that the 
relative importance that Walter and Andrei give to IDE tools is not on 
the same level as what the core Rust team gives. And that I can blame on 
them.

Let's look at an interesting example: the Nim language. It's a fairly 
small community, perhaps comparable to D, and also not backed by any 
large corporation, or any large team. It's just one or two main 
developers. Yet they  found time to support IDE tooling in the core 
toolchain: http://nim-lang.org/docs/idetools.html
No corporate support, AFAIK.


Even better, let me offer a thought experiment here. Imagine that Walter 
were offered a developer for free, to work for 1 year on any D related 
work that Walter chooses (and the developer would work competently on 
whichever assignment he was placed). Would Walter assign that developer 
to be working in IDE tools? Hell no. He'd be working on Phobos, or some 
GC issues, or maybe fixing DMD bugs, etc. Now what about 2 developers? 
And 3 and so ? How many would there need to be until a developer would 
be assigned to work on DCD or a similar tool? More than the size of the 
Rust team for sure.

TL;DR:
Here's the bottomline:
Does Walter even use any IDE tooling? Does he, for example, use DCD when 
developing in D? Does he use any IDE or IDE tooling when working with 
C/C++ ? If he doesn't use them, how would he ever rate this aspect 
*truly* important (not just important because other people like it)...


>> Even the fact that we are using custom web forum software (Vladimir's
>> forum) draws a strong parallel with the DigitalMars vs. LLVM backend
>> story.
>
> No.
>

Perhaps you're right... the gap between the size of the DM backend team 
and the LLVM backend team is much, much more massive.

>> I mean, Vladimir's forum is an impressive piece of work, and it's a
>> really good demo of D's capabilities. That said, it's the work of 1-2
>> people, it cannot stand against the capabilities and polish of
>> something like Discourse which is developed by a much bigger team, and
>> used by many different organizations.
>
> I take offense to that.
>
> In the same way that forum.dlang.org can never have some of Discourse's
> features by its nature, Discourse can never have some of forum.dlang.org
> features. The Discourse's team's priorities are different (for example,
> they put much less emphasis on responsiveness, resource usage,
> interoperability, or multiple forms of presentation).
>

With regards to interoperability, the design goals of forum.dlang.org 
and Discourse are quite different, so they can't really be compared. I 
can agree with that. But in any case I was more focusing in polish and 
functionality in the area of user interface, since that is more amenable 
to being compared. And it's the most important aspect of the software.

You say forum.dlang.org is focused on multiple forms of presentation, 
but I'd rather have one that works really well, than multiple ones that 
aren't that great. (see further ahead for the list of missing features).

As for responsiveness, Discourse works pretty responsively to me. Same 
with resource usage. Unless you meant resource usage in the server. I'm 
afraid I'm at a disadvantage here, I'm not familiar with backend 
details, so I can't really comment on those.


> Perhaps you could list some particular features you're missing.
>

LOL... I can give plenty:


* password / username recovery functionality.
* Being able to register with some pre-existing account (like Github), 
so it's one less login to remember.
* Profile functionality, so that people can put an blog/twitter/github 
URL in profile. (better than using signatures)

* Viewing topics that have new content, whilst being able to 
ignore/unwatch individual topics.

* Ability to spawn a new topic from an existing one. This is not 
something that is supported currently. Merely renaming the title doesn't 
do this - the sub-topic still remains part of the parent thread/topic. 
So there is noise around, you can't simply follow the sub-topic, whilst 
ignoring the rest of the thread, because they are not separate.

* The ability to flag posts for moderation.

* Editing posts, with the ability to view edit history.

* Auto-Scroll or some way to view an entire topic without having to 
click on "next page".
  * Alternatively, at least be able to set the number of posts per page 
to a large number, say 100.

* Having a link count for the links that people post. It's interesting.

* A nicer visual representation and interface for quoted text.

* Some basic markup support, like markdown.
* And with that, a markup editor.

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros