D future ...

Chris Wright via Digitalmars-d digitalmars-d at puremagic.com
Wed Dec 21 20:47:06 PST 2016


> Library Standardization:
> ------------------------
> 
> Some of the proposals sounds very correct. The library needs to be
> split. Every module needs its own GIT. People need to be able to add
> standard modules ( after approval ).

I can't agree with you there. There are a lot of dependencies between 
modules.

> No offense but where is the standard database library for D? There is
> none. That is just a load of bull. Anybody who wants to program in any
> language expect the language to have a standard database library! Not
> that you need to search the packages for a standard library. I have seen
> one man projects that have more standard library support then D.

Go, Java, and C# each have database _interfaces_ in their standard 
libraries. Most other languages don't.

These interfaces don't let you connect to any database. You still need a 
library to connect to a specific database.

With the rise of document databases and alternate query systems, it's 
harder to define a generic database library. It's still possible to write 
one for SQL databases.

> I do not use 3th party packages

The standard library needs a rigorous approval process. That takes time 
and human attention for the review and to address concerns identified 
during review.

D is marginal, and that means we simply don't have the time to get these 
things done.

> Documentation:
> --------------
> 
> I do not use it. Its such a mess to read with long paragraphs

Long paragraphs describing the details of what a thing does is generally 
a good thing. MSDN's documentation is like that.

The "mess" part is when we have five hundred identifiers documented in 
one web page. dpldocs.info is much better about this.

> and a LOT of stuff not even documented.

There's no excuse for that.

> This automated documentation generation is the same **** i see in other
> "new" languages.

The documentation is hand-written. We don't have a tool capable of 
annotating, say, std.string.detab with "Replace each tab character in s 
with the number of spaces necessary to align the following character at 
the next tab stop." without human intervention. That would be impressive, 
though.

The HTML is generated by a tool.

> Editor support:
> ---------------
> 
> What a struggle. Visual Studio C is probably the editor with the best
> 3th party support.

VS Code isn't terrible. It's got the disadvantage that it tries to 
autocomplete every possible thing -- so you get __monitor and __vptr 
first, and the other options include things you can't access.

> Too many need 3th party to do something that D needs to support from
> itself:
> 
> dcd - Used for auto completion
> dfmt - Used for code formatting
> dscanner - Used for static code linting ...
> 
> This needs to be in the default installation of dmd! It makes no sense
> that these are not included.

>From a usability standpoint, I agree.

>From a political standpoint, it's unsurprising that they're not included.

> Future:
> --------
> 
> You want D to have traction.

That's *a* goal, but it's not the goal that's closest to most of our 
hearts, I think. Popularity doesn't exactly bring enjoyment -- it can 
remove some annoyances, but it's easier to work around those annoyances. 
It isn't fulfilling. And it doesn't pay the bills.

> Marketing, more library support, less focus
> on adding even more advanced features, fixing issues (
> like better GC ),

There are huge barriers to bringing D's GC to the state of the art. Some 
improvements could be made, though. For instance, the GC currently scans 
heap objects scattered about the whole heap. Using separate virtual 
address ranges for objects with pointers and objects without might 
improve efficiency somewhat.

> CTFE ( Stefan is dealing with that ), Documentation,
> better Editor support...

I think code-d could potentially be extended to install its dependencies, 
which would improve the situation there.

> Walter / Andrei:
> ----------------
> 
> No offense guys, just something that i see in a lot of posts. The
> hinting at people to add more to the standard libraries. That little
> push. But frankly, its annoying when nothing gets done.
> 
> People complain about x feature. You tell people to add to the standard
> library or bring the project in. But anybody who has ever read this
> forum sees how adding things to the language is LONG process and a lot
> of times idea's get shot down very fast.

The language is *very* conservative. The standard library is merely 
cautious. But since there's no cost to adding a package to dub, that 
doesn't prevent code from being written and reused. Except by those who 
refuse to go outside the standard library, and for those people, I would 
recommend Java or C#.

> For the standard library there is no process as far as i can tell.
> Experimental at best, where code seems to have a nice long death.

It could be much better documented.

The process for small changes:

* Make the change.
* Make a pull request.

The process for large changes:

* Propose it here, with your initial design. Get feedback.
* Implement it as a dub package.
* Ask for a formal review here.
* Address feedback.
* Make a pull request.

> Give people the ability to add more to std.experimental. Give it its own
> forum part.

Nothing stops you from adding dub packages using the namespace 
std.experimental. The tradition previously has been to use stdx for 
modules that are intended for the standard library.

An incubator organization might be appropriate as an intermediate between 
standard library and individuals' dub packages -- easier entry than the 
standard library, but multiple people are on hand to handle bugs.


More information about the Digitalmars-d mailing list