At the moment it goes straight go code.dlang.org, which may be a bit overwhelming if you have just arrived at dlang.org and want to see what it can do.

Is it worth changing to the library wiki write up page on libraries?  And making sure link to code.dlang.org is prominent, saying "code.dlang.org is a registry of D libraries hosted on github.  There are currently XYZ libraries, of which ABC are under active development".

At the moment, the list of libraries on the wiki is fairly complete, but not oriented towards answering the question of how do I do stuff.  It would be nice to have a set of pages on this that mines the gold from the forums and makes it easy to find.  Eg "how do I navigate html or xml?".  Use dom.d or ae, and here are some simple programs.

Compare python community doc situation to ours.  (We are leaner, but that doesn't mean we can't do a better job),

Also say that if you cannot find the library you need, you should know that it is easy to interface to all C libraries (click for details), and that it is possible and fairly easy to interface to many C++ libraries (click here).

p0nce and others are doing great work on D idioms, but what is missing is pointers to examples of larger programs.  I know it is common sense if you are experienced to read the source of other projects to learn, but is it worth making this easy by having in the section on learning D some pointers to some model D code bases.

The FUD crowd on slashdot always brings up the Tango / Phobos split, but this is not prominently addressed on the web site.  Should this not be answered in the main FAQ?

The compilation speed of dmd (and somewhat ldc) is a major advantage.  It is stunning in outright terms, and almost inconceivable if you come from the world of c++.  It really matters because it allows you to shift styles to iterative development.  So it should be featured on the front page, and there should be quantitative benchmarks (because that's what modern people like) comparing dmd to other language compilers as well as pointing out how quickly phobos compiles. A YouTube video may make it more concrete.  And there should be quotes from authoritative users of D talking about how useful they find quick compilation and iterative development.

People are lazy.  Or more charitably, not wealthy in terms of attention and time in the modern world.  The documentation is often written from the point of view of the compiler and library writer, and this is not the point of view of the user, who wants to know what he can do, and how he can do it.

In the "interfacing to C tutorial", how about starting off by getting to the point.  Have the following section at the beginning, and maybe even make it crisper by saying that D can utilise all existing C libraries, and all that needs to be done is to translate the header  files to D.

Using Existing C Libraries
Since D can call C code directly, it can also call any C library functions, giving D access to the smorgasbord of existing C libraries. To do so, however, one needs to write a D interface (.di) file, which is a translation of the C .h header file for the C library into D.

For popular C libraries, the first place to look for the corresponding D interface file is the Deimos Project. If it isn't there already, and you write one, please contribute it to the Deimos Project.

---

In the spirit of accommodating peoples' attention poverty, why not say at the top that there are translation tools for objective C and C.  Click here to download dstep binaries (linux / win etc), and here to go to the github dstep site.  I confess that I struggled for ages unsuccessfully to compile dstep on my platform without realising that the binaries were available for download.

Similarly for C++, the web site starts off completely on the wrong note." While D is fully capable of interfacing to C, its ability to interface to C++ is much more limited. There are three ways to do it:"

I hear "much more limited", and think I am not going to bother with this (if I have not yet committed to the language).  Whereas in actual fact, as Walter pointed out in his talk, nobody else can interface with C++ and it is a marvel to be able to do so at all, let alone in a way that is much more complete than the docs suggest.  And it sounds like this phrasing is in any case outdated.

Change to something like: "Interfacing to C++ is a challenging endeavour for any language, but it is a challenge that must be met in order to take advantage of the large set of existing libraries and code bases in C++.  It is therefore a priority for 2015 to implement an ability to link to a set of C++ that will be complete for most use cases.  Walter Bright spoke recently at Microsoft on this topic, and the reader may find the following forum threads of interest.

As things stand, the following features are complete:..., whilst there are limitations with respect to: exceptions, multiple inheritance, ...

The aim is to finish C++ interfacing in the reference compiler DMD, and it is likely that this support will be extended to the other D language compilers: GDC, and LDC.

Parallel to this effort, there is an alpha project called Calypso that takes advantage of the clang API to integrate almost complete C++ support within the D compiler LDC and takes away the need to generate separate headers.  Link here to download binaries (they are not yet available, but we should offer standard builds even though it is alpha because of the strategic importance of the project, and because clang/llvm is not trivial to build - I needed to edit my usr/include headers to hack up size_align_t just to get it to compiled) and here for github.




Laeeth

On 27/01/2015 8:29 a.m., Laeeth Isharc wrote:
> At the moment it goes straight go code.dlang.org, which may be a bit
> overwhelming if you have just arrived at dlang.org and want to see what
> it can do.
>
> Is it worth changing to the library wiki write up page on libraries?
> And making sure link to code.dlang.org is prominent, saying
> "code.dlang.org is a registry of D libraries hosted on github.  There
> are currently XYZ libraries, of which ABC are under active development".
>
> At the moment, the list of libraries on the wiki is fairly complete, but
> not oriented towards answering the question of how do I do stuff.  It
> would be nice to have a set of pages on this that mines the gold from
> the forums and makes it easy to find. Eg "how do I navigate html or
> xml?".  Use dom.d or ae, and here are some simple programs.
>
> Compare python community doc situation to ours.  (We are leaner, but
> that doesn't mean we can't do a better job),
>
> Also say that if you cannot find the library you need, you should know
> that it is easy to interface to all C libraries (click for details), and
> that it is possible and fairly easy to interface to many C++ libraries
> (click here).
>
> p0nce and others are doing great work on D idioms, but what is missing
> is pointers to examples of larger programs.  I know it is common sense
> if you are experienced to read the source of other projects to learn,
> but is it worth making this easy by having in the section on learning D
> some pointers to some model D code bases.
>
> The FUD crowd on slashdot always brings up the Tango / Phobos split, but
> this is not prominently addressed on the web site. Should this not be
> answered in the main FAQ?
>
> The compilation speed of dmd (and somewhat ldc) is a major advantage.
> It is stunning in outright terms, and almost inconceivable if you come
> from the world of c++.  It really matters because it allows you to shift
> styles to iterative development.  So it should be featured on the front
> page, and there should be quantitative benchmarks (because that's what
> modern people like) comparing dmd to other language compilers as well as
> pointing out how quickly phobos compiles. A YouTube video may make it
> more concrete.  And there should be quotes from authoritative users of D
> talking about how useful they find quick compilation and iterative
> development.
>
> People are lazy.  Or more charitably, not wealthy in terms of attention
> and time in the modern world.  The documentation is often written from
> the point of view of the compiler and library writer, and this is not
> the point of view of the user, who wants to know what he can do, and how
> he can do it.
>
> In the "interfacing to C tutorial", how about starting off by getting to
> the point.  Have the following section at the beginning, and maybe even
> make it crisper by saying that D can utilise all existing C libraries,
> and all that needs to be done is to translate the header  files to D.
>
> Using Existing C Libraries
> Since D can call C code directly, it can also call any C library
> functions, giving D access to the smorgasbord of existing C libraries.
> To do so, however, one needs to write a D interface (.di) file, which is
> a translation of the C .h header file for the C library into D.
>
> For popular C libraries, the first place to look for the corresponding D
> interface file is the Deimos Project. If it isn't there already, and you
> write one, please contribute it to the Deimos Project.
>
> ---
>
> In the spirit of accommodating peoples' attention poverty, why not say
> at the top that there are translation tools for objective C and C.
> Click here to download dstep binaries (linux / win etc), and here to go
> to the github dstep site.  I confess that I struggled for ages
> unsuccessfully to compile dstep on my platform without realising that
> the binaries were available for download.
>
> Similarly for C++, the web site starts off completely on the wrong
> note." While D is fully capable of interfacing to C, its ability to
> interface to C++ is much more limited. There are three ways to do it:"
>
> I hear "much more limited", and think I am not going to bother with this
> (if I have not yet committed to the language).  Whereas in actual fact,
> as Walter pointed out in his talk, nobody else can interface with C++
> and it is a marvel to be able to do so at all, let alone in a way that
> is much more complete than the docs suggest.  And it sounds like this
> phrasing is in any case outdated.
>
> Change to something like: "Interfacing to C++ is a challenging endeavour
> for any language, but it is a challenge that must be met in order to
> take advantage of the large set of existing libraries and code bases in
> C++.  It is therefore a priority for 2015 to implement an ability to
> link to a set of C++ that will be complete for most use cases.  Walter
> Bright spoke recently at Microsoft on this topic, and the reader may
> find the following forum threads of interest.
>
> As things stand, the following features are complete:..., whilst there
> are limitations with respect to: exceptions, multiple inheritance, ...
>
> The aim is to finish C++ interfacing in the reference compiler DMD, and
> it is likely that this support will be extended to the other D language
> compilers: GDC, and LDC.
>
> Parallel to this effort, there is an alpha project called Calypso that
> takes advantage of the clang API to integrate almost complete C++
> support within the D compiler LDC and takes away the need to generate
> separate headers.  Link here to download binaries (they are not yet
> available, but we should offer standard builds even though it is alpha
> because of the strategic importance of the project, and because
> clang/llvm is not trivial to build - I needed to edit my usr/include
> headers to hack up size_align_t just to get it to compiled) and here for
> github.
>
>
>
>
> Laeeth
Maybe post this on D NG?

Forgive if I'm suggesting something which was already discussed and dismissed, but I too would love a way to leverage C++ stuff into D. Can't we go to C++? Meaning there's a C++ compiler coming from the same hands as D. Couldn't we try to get the C++ compiler to compile in such a manner that D can easily pick up the result?

I will only use libraries where I have the source code, so from my point of view, I don't need binary compatibility. I also don't need D to pollute itself with the past. But if the Digital Mars C++ compiler could help and assist with creating libs/dlls etc that are properly set up for D and possibly produce the import for D, then it would solve a lot of things. For instance, if a project is in C++, you will need to be able to track revisions to that project, meaning the D conversion should be reasonably painless. Take something like WxWidgets for instance, the D port is stale, but WxWidgets is compatible with Digital Mars. If any project doesn't support Digital Mars C++, then it would be a C++ to C++ port, which is always going to be easier and less volatile than a C++ to D port.

Just wondering....