On 24/03/2016 20:15, Walter Bright wrote:
>
>
>> But most shortcomings of NNTP are innate and cannot be addressed, not
>> in a
>> proper way.
>
> The only shortcoming of NNTP that is not innate are editing/deleting
> posts, and:
>

No, another shortcoming of NNTP that is innate is that it doesn't require an account / authentication : anyone can post without registering, emails accounts can be spoofed, etc.

You might argue that this is not a shortcoming, and ok, it's your opinion. But it is another aspect of NNTP that is *innate and can't be fixed*.

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

On 24/03/2016 20:15, Walter Bright wrote:
>
>> But most shortcomings of NNTP are innate and cannot be addressed, not
>> in a
>> proper way.
>
> The only shortcoming of NNTP that is not innate are editing/deleting
> posts, and:
>

No, there is another shortcoming of NNTP that is innate: it doesn't require an account / authentication, anyone can post without registering, emails accounts can be spoofed, etc.

You might argue that this is not a shortcoming, and ok, that's subjective. It is a shortcoming for me. But regardless, it is at the very another *aspect* of NNTP that is *innate and can't be fixed*.

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

On Friday, 25 March 2016 at 17:03:22 UTC, Bruno Medeiros wrote:
> But it is another aspect of NNTP that is *innate and can't be fixed*.

It'd be pretty easy to add digital signatures (some users already do it) and check them if you were really concerned about it. And that'd be more secure than the typical password system.

On 24/03/2016 17:50, Andrei Alexandrescu wrote:
> On 03/24/2016 12:50 PM, Bruno Medeiros wrote:
>> And this is one of the reasons why I've essentially moved from D to
>> Rust.
>
> It would be interesting to share a few thoughts about your experience
> with Rust if you have the time. Thanks! -- Andrei
>
>

If you're looking for an experience of someone who moved to writing a significant code base in Rust, that's not me. The most Rust code I've written so far is just this https://github.com/RustDT/Rainicorn - about 1-2 man-weeks of effort. and I don't even consider myself proficient in Rust yet. (it's damn complicated to master!)

What I meant with my comment above is that I've moved my *time and effort investment* from D to Rust, but that doesn't mean the investment was writing D or Rust code directly. Rather it has more to do with projects like DDT (https://github.com/DDT-IDE/DDT), a project I've worked on and off since 2008, but fairly intensively in the last 4-5 few years. The DDT IDE has its own D parser and semantic engine (for code completion, find definition, etc.), that I built from scratch, and have been improving throughout these years. About a year ago or so, I was on the verge of massive improvements in this engine.

On one hand it would begin to support template instantiation (not perfectly, but enough to support code completion well enough in the majority of cases). Most of the groundwork necessary to have this analysis work in a lazy and incremental way - such that it would perform well under the interactive nature of an editor - was done already.

Another thing nearly completed was refactoring the engine out of Eclipse itself, so that it could be run externally, as a daemon process. In a way quite similar to DCD, Go oracle, RLS, etc. The groundwork for all this was done (also implementing caching, etc.). I think this would have been quite interesting because with the template improvements above, the DDT engine would have been fairly more advanced than DCD currently, and be available to other D IDEs/editors (especially since Eclipse is not that popular nowadays, and I'm the first admit, fairly so - Eclipse sucks in certain regards)

I was already a bit worried 2-3 years ago when Go came into the scene. It would definitely take a bit of mind-share out of D, but like you said, Go is not really a competitor to D, so it wasn't that significant...

But then queue Rust coming in to the scene, and essentially I rapidly lost my motivation to work in D-specific tools once I looked more into Rust.

DDT will still be maintained, but only because I've refactored the IDE-generic code into a language-agnostic framework, and built https://github.com/RustDT/RustDT and https://github.com/GoClipse/goclipse with it. But I won't be working on the DDT semantic engine anymore, as far as things stand.

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

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

On 25.03.2016 15:56, Nick Sabalausky wrote:
> On 03/17/2016 01:02 PM, ag0aep6g wrote:
[...]
> "Woman" excludes non-adults. Non-adult, like I was when I started with
> code.

Being most inclusive is clearly not the goal here. Otherwise Karabuta wouldn't have specified the sex. Did he choose "a female" to include children when talking about "someone soft and mortal who actually understand how to communicate and build a community"? I doubt it.

> That's the problem with PC nitpicking, it never ends.

I agree that picking on every word someone says isn't good. And it's worse when bad intent is assumed behind every little odd choice of words. I don't mean to do that.

Maybe this use of "female" is benign, but it rubs me wrong way. I don't think I've been too hard on Karabuta by telling him that.

>> "A female" sounds like you're
>> talking about an animal.
>
> Not to a native english speaker.

I call bullshit on that. I don't have any strong evidence, and I'm not even a native English speaker myself, but I simply don't buy it.

Here's the first Google hit I got for "animal documentary male female":

https://youtu.be/kY7SlH3rzhQ?t=430

Didn't take long to find a spot where they talk about "the males" and "the females", because they always do in animal documentaries.

Note how the speaker switches from "male"/"female" for kangaroos to "man"/"woman" for humans. That's what I'm talking about.

On 3/25/2016 10:05 AM, Bruno Medeiros wrote:
> No, there is another shortcoming of NNTP that is innate: it doesn't require an
> account / authentication, anyone can post without registering, emails accounts
> can be spoofed, etc.

It's actually pretty easy to add a field with a crypto hash in it, and have the NNTP server reject postings without the hash, and then supply the hash only with validated account creation.

There's a scheme out there that does something like this for PGP key signing.


> You might argue that this is not a shortcoming, and ok, that's subjective. It is
> a shortcoming for me.

I agree that it is subjective. As far as the D forums go, I think it's a feature that people can post without setting up an account. In today's panopticon, it's nice to have a few islands here and there where people can express an honest opinion without being tracked, cataloged, data-mined, etc.

Sure, we get a few drive-by rogue and spam postings, but it's small enough to be manageable.

(I have HUNDREDS of accounts here and there. It's just tiresome to set up a new one every time I visit a new site.)

On Friday, 25 March 2016 at 19:40:08 UTC, Bruno Medeiros wrote:
>
> whilst being able to ignore/unwatch individual topics.

Yes, like this thread...

On 03/24/2016 04:52 PM, deadalnix wrote:
> On Thursday, 24 March 2016 at 23:04:42 UTC, QAston wrote:
>> If only one could somehow engineer societies (males? - that seems to
>> be the problem) meeting your standards.
>
> Replace male by jew in your sentence and ask yourself how it sounds.
>

We're getting there: :)

  https://en.wikipedia.org/wiki/Godwin%27s_law

Ali

On 03/25/2016 04:31 AM, QAston wrote:

> Well I can agree that Trump is like Hitler (and nazis, and fascists, and
> eugenics, and communists, and jews)

We've made it! :)

  https://en.wikipedia.org/wiki/Godwin%27s_law

Ali