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
