Re: A strategic vision for D

[John Gabriele via Digitalmars-d]

On Tuesday, 1 May 2018 at 17:20:54 UTC, Ali wrote:

On Tuesday, 1 May 2018 at 12:26:25 UTC, Joakim wrote:
I realize it's right before the conference, but I'd like to 
put out a request for Walter and Andrei to spend five minutes 
during your talks laying out some overarching strategy for how 
you see D evolving. It could be during the keynotes or leading 
off the Q panel, but I think it's worth laying a broad 
strategy out there.


For D's vision as set by D's core team
check https://wiki.dlang.org/Vision/2018H1


In particular, I'd like to hear how the core team weighs:

  * making useful breaking changes vs maintaining backcompat, and

  * adding more features vs more simplification of the language.

It is very clear, and feel free to read between the lines, on 
what might be the long term strategy


I think point 1 in the vision is very telling

1. Lock down the language definition


Sorry, I'm not understanding. To me that says the core team 
values multiple implementations that adhere to the same spec. 
Does it imply something else?

Re: Beta 2.079.0

[John Gabriele via Digitalmars-d-announce]

On Tuesday, 20 February 2018 at 20:08:55 UTC, jmh530 wrote:
On Tuesday, 20 February 2018 at 19:36:46 UTC, John Gabriele 
wrote:


In:

import myModule : foo, bar;

how do you know if bar is myModule.bar or if it's a separate 
module bar?


It probably could be described a little better in the change 
log. It uses examples, but doesn't really describe what the 
file structure is that work with those examples.


Perhaps this:

--- pkg.d
module pkg;

public import pkg.mod1;
public import pkg.mod2;

--- pkg.mod1.d
module pkg.mod1;

enum sym1;

--- pkg.mod2.d
module pkg.mod2;

enum sym2;

If this structure works for both of those examples, then
import pkg.mod1 : sym1, mod2 : sym2;
works because mod2 has a selective import and
import pkg.mod1 : sym1, sym2, pkg.mod2;
works because pkg.mod2 is fully qualified (it may be annoying 
to find sym2 if this works with the above structure).


Thanks. Is the point to be able to string a bunch of selective 
imports together, as in:


import pkg.mod1 : sym1, sym2, pkg.mod2 : sym1, sym2, pkg.mod3 
: sym1;


?

That's difficult to read; it's hard to see the difference between 
the commas that separate the symbols vs the commas that separate 
the modules+symbols groups.

Re: Beta 2.079.0

[John Gabriele via Digitalmars-d-announce]

On Tuesday, 20 February 2018 at 08:43:50 UTC, Martin Nowak wrote:

On Monday, 19 February 2018 at 15:58:57 UTC, Joakim wrote:
17. Allow multiple selective imports from different modules in 
a single import statement


I have a bad feeling that that one is going to be a source of 
a raft of bugs for years to come.


No need to use it if you don't like it. It's particularly 
useful for small examples, localized imports and hacking.
It's mainly a generalisation of the existing possibility to mix 
module imports and one selective import at the end.
If you prefer java-like 50 lines import manifests, then by all 
means keep using those.

How would that feature cause bugs though?


In:

import myModule : foo, bar;

how do you know if bar is myModule.bar or if it's a separate 
module bar?

Re: Dub, Cargo, Go, Gradle, Maven

[John Gabriele via Digitalmars-d]

On Thursday, 15 February 2018 at 16:47:35 UTC, Pjotr Prins wrote:
On Thursday, 15 February 2018 at 15:52:41 UTC, John Gabriele 
wrote:
It's a bit confusing since the first thing [the Guix 
webpage](https://www.gnu.org/software/guix/) talks about 
"GuixSD", rather than the Guix tool in its own right.


Yes. We discussed that at the hackathon before FOSDEM. It is 
rather difficult to position a project that has so many use 
cases...


Wow, I didn't realize how established Guix is. It's [packages 
page](https://www.gnu.org/software/guix/packages/) boasts 6868 
available packages!


~2000 added in the last year. I am updating the ldc package to 
1.7.0 this week.


Are any other languages using Guix for their 3rd-party online 
package repo? If not, why?


GNU Guile ;).


That's excellent. I remember years ago it looked like there was 
action in getting a Guile package repo going but it never panned 
out. Glad they found (and settled on) something! (Though 
 doesn't say 
anything about Guix, and I don't see anything about Guix in the 
[Guile 
manual](https://www.gnu.org/software/guile/docs/master/guile.html/)).


The current state is that everyone is rolling out some type of 
language support. The good news is that Guix allows for 
abstracting existing build systems. If you look at a typical 
python package you can see it leans on pip:


  
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/python.scm#n1004


The package is written in Guile scheme, but you can see it does 
not take a genius
to package something. In fact Guix can generate the actual 
package definition automatically.


We have not written something similar for dub. But I can do 
that if there is interest.


I'd love to see an overview article explaining how the pieces 
would fit together. Would Guix work with Dub? If so, what 
specifically (on GNU/Linux) would be required to make that 
happen, and what would using such a solution look like in 
practice?



Not at all. Seems like an amazing tool!


Agree. Give it a shot.


I don't yet know enough about D and Dub to even know what giving 
Guix a shot would mean :). I'm on Debian and so use apt for 
installing software. I'll have to spend some time with the Guix 
(and Dub) docs.


It does not hurt your system because the installer only uses 
/gnu (for the software) and /var/guix (for the database). To 
uninstall simply remove those dirs.

Guix never overwrites system directories.


Nice. Easy removal is most appreciated.

Re: Dub, Cargo, Go, Gradle, Maven

[John Gabriele via Digitalmars-d]

On Thursday, 15 February 2018 at 07:21:24 UTC, Pjotr Prins wrote:
On Thursday, 15 February 2018 at 04:11:51 UTC, Graham St Jack 
wrote:
Maybe a compromise position would be for a package management 
system to define an interface through which it can do things 
like:


* Discover what the external dependencies are,

* Provide those external dependencies, and

* Invoke a full build.

Then, any number of build systems (and deployment systems?) 
could be adapted to work with the package management system.


That is exactly what GNU Guix offers. With support for isolated 
builds, continuous integration testing, and containers thrown 
in, if you want that. People misunderstand Guix somewhat 
because it presents itself as a 'package manager' and even 
distribution in its own right. But actually it is a dependency 
manager that can run on top of any system.


It's a bit confusing since the first thing [the Guix 
webpage](https://www.gnu.org/software/guix/) talks about 
"GuixSD", rather than the Guix tool in its own right.


Wow, I didn't realize how established Guix is. It's [packages 
page](https://www.gnu.org/software/guix/packages/) boasts 6868 
available packages!


The [Guix manual](https://www.gnu.org/software/guix/manual/) 
appears to be comprehensive.


Are any other languages using Guix for their 3rd-party online 
package repo? If not, why?


I am writing a BLOG on how to use Guix for Python development 
using its package managers and even dependency injection (say a 
choice of BLAS libraries or LLVM in the case of D). When that 
is done I could do a D writeup if there is enough interest.


I am sure some people roll their eyes when I mention GNU Guix.


Not at all. Seems like an amazing tool!

Re: How to represent multiple files in a forum post?

[John Gabriele via Digitalmars-d]

On Wednesday, 14 February 2018 at 18:33:23 UTC, Jonathan Marler 
wrote:

@timotheecour and I came up with a solution to a common problem:

How to represent multiple files in a forum post?

So we decided to take a stab at creating a standard! (queue 
links to https://xkcd.com/927)


We're calling it "har" (inspired by the name tar).


Clever name. Har D har har {ducks!} :)

Here's the REPO: https://github.com/marler8997/har and here's 
what it looks like:


--- file1.d
module file1;

--- file2.d
module file2;

// some cool stuff

--- main.d
import file1, file2;
void main() { }

--- Makefile
main: main.d file1.d file2.d
dmd main.d file1.d file2.d


This looks handy.

Yes, it's easy enough in markdown docs to just put code block 
markers around them (such as ``` or ~~~).


Can the har file delimiter be more than three characters?

What do you think of allowing trailing dashes (or whatever the 
delim chars are) after the file/dir name? It would make it easier 
to see the delimiters for larger har'd files.


--- file1.d ---
module file1;

--- file2.d ---
module file2;

(Note that markdown allows extra trailing characters with its 
ATX-style headers, and Pandoc does likewise with ATX headers as 
well as its div syntax (delimited by at least three colons), for 
that very reason --- to make it easier to spot them.)

Re: The Expressive C++17 Coding Challenge in D

[John Gabriele via Digitalmars-d-announce]

On Tuesday, 13 February 2018 at 23:35:36 UTC, Seb wrote:
Someone revived the Expressive C++17 Coding Challenge thread 
today and I thought this is an excellent opportunity to revive 
my blog and finally write an article showing why I like D so 
much:


https://seb.wilzba.ch/b/2018/02/the-expressive-c17-coding-challenge-in-d

It's mostly targeted at beginners as I explain many basic D 
features, but maybe it's helpful for beginners looking into D.


Great article! Thank you!

Typo: "and finally format bundles" --> "and finally std.format 
bundles".


Another typo: "In the latter article I will also present a 
solution which only uses 12 lines, but it uses the built-in 
std.csv module and I think D doesn’t even need to cheat." should 
probably instead start "Later in this article I'll also 
present..." or "Further down I'll also present".


But even then, I don't think you should discount or put off using 
std.csv as "cheating". I'm guessing std.csv handles things like 
quoted elements containing commas. I realize that maybe you're 
being pedagogic and wanting to show off D's File byLine and 
splitter, but I think the first thing a reader will think when 
they see you rolling your own csv reader by hand is that 
something must be wrong with D or it's ecosystem if you're 
resorting to this, and they'll run for the hills (especially in 
an intro article, *and* one in which you point out that the goal 
is *expressive* code).


In fact, I'd go so far as to say that, when searching online for 
how to read in a csv file for a given language (see many examples 
at ), if the 
example involves splitting on commas, I immediately assume it's 
either old/incorrect, the language is very low-level only, or 
else maybe the language's std lib must be impoverished.

Re: Being Positive

[John Gabriele via Digitalmars-d]

On Tuesday, 13 February 2018 at 03:40:52 UTC, Jonathan M Davis 
wrote:
{snip} I suspect that part of it is that a lot of folks seem to 
come to D looking for the perfect language after having be 
frustrated by another language like C++, and while D is a lot 
closer to that for many folks than other languages are, it 
still has plenty of flaws, and we want those flaws fixed so 
that it can become the perfect language. Obviously, that's not 
going to happen. No language is perfect, but the vocal portion 
of the D community does have a tendency to want to push for 
everything that's arguably wrong with D to be fixed, and that 
can result in a lot of negativity, but it can also result in 
things getting fixed (though that requires actually doing 
something about it rather than just complaining).


I think what would help here is a D wiki page (maybe 
 could be expanded) that 
lists perceived flaws in the language, together with an 
explanation whether or not it's really considered a flaw, and if 
it is, why it's not being fixed. Those not-being-fixed reasons 
are the real crux of the issue, I think:


  * If the reason is lack of manpower or expertise in the area, 
then complaints about the flaw can be responded with, "see [that 
wiki page], can you pitch in?".


  * If the reason is that by fixing the issue it would cause 
problems {x}, {y}, and {z}, then the person raising the complaint 
learns something about language design.


  * If the reason is the language design team's personal 
preference on the matter, and the tradeoffs are listed, then 
users learn what the tradeoffs are and have to live with it.


  * If the reason for not fixing the issue is hesitation to break 
backward compatibility, then this may be an issue that D 
leadership wants to hear feedback on.


But I think pointing people to that wiki page and laying it out 
like that may diffuse a lot of arguments.

Re: Dub, Cargo, Go, Gradle, Maven

[John Gabriele via Digitalmars-d]

On Monday, 12 February 2018 at 10:35:06 UTC, Russel Winder wrote:
In all the discussion of Dub to date, it hasn't been pointed 
out that JVM building merged dependency management and build a 
long time ago. Historically:


  Make → Ant → Maven → Gradle

and Gradle can handle C++ as well as JVM language builds.

So the integration of package management and build as seen in 
Go, Cargo, and Dub is not a group of outliers. Could it be then 
that it is the right thing to do. {snip}


As an additional data point, the main project management tool for 
Clojure is [Leiningen](https://leiningen.org/). I don't 
understand the details under the hood, but it makes use of Maven 
infrastructure and can install packages from the Clojure online 
package repo, as well as from [Maven 
Central](http://search.maven.org/) (the online repo of JVM jars).


Lein installs packages into the same place maven does, into a 
"local repo" in an ~/.m2/repository directory. This makes it very 
easy to `rm -fr` it to start afresh if needed. Lein keeps 
multiple versions of packages when your various projects use 
different versions of the same library.


The lein project config file is itself written in Clojure. See a 
[sample lein config 
file](https://github.com/technomancy/leiningen/blob/master/sample.project.clj) if interested.


When I first encountered lein I was confused. Was it for project 
creation, dependency management, building and running your app, 
or running tests? Turns out it does all of those, and also 
supports plug-ins to allow it to do all kinds of other 
project-related tasks that aren't built-into the tool (for 
example, generating docs --- see the [full list of lein 
plug-ins](https://github.com/technomancy/leiningen/wiki/Plugins)).

Re: Which language futures make D overcompicated?

[John Gabriele via Digitalmars-d]

On Saturday, 10 February 2018 at 20:55:00 UTC, John Gabriele 
wrote:


{snip} It's not niche at all, it just doesn't have hoards of 
users. D is well-positioned to be hugely popular, but I think 
to succeed its leadership needs to be willing to fix things 
they want to fix and not worry about breaking backcompat.


Augh! "hordes", not "hoards".

Re: Which language futures make D overcompicated?

[John Gabriele via Digitalmars-d]

On Saturday, 10 February 2018 at 12:44:14 UTC, rjframe wrote:

On Fri, 09 Feb 2018 22:36:19 +, Ralph Doncaster wrote:

Frankly, I think it is doomed to be a niche-use language.  
While many more things were done right compared to C++, too 
many things were done wrong and there doesn't seem to be 
interest in breaking backward compatibility to excise them 
from D.


Yes.

If the current "let's get C++ programmers to like us" stuff 
continues, some of these problems will have to be fixed. I'm 
expecting C++20 to be a nice language for new projects, where 
you can ignore a lot of the blech (though not quite enough of 
it), and moving to C++20 will be easier than moving to D. The 
ROI just won't be there for most people (for many, it doesn't 
seem to be there today...).


I also agree. One of the prime benefits of a language with a 
smaller community is that you can make it _better_ *faster*, 
breaking backcompat more easily and more often, and getting a 
better language in the process. After all, if its users wanted 
something slow to evolve, they'd be using one of the 
industry-accepted behemoths.


I'm not sure that being a niche language is a bad thing; if we 
just say, "this is D; if you like it come and use it, come help 
make it better, but if it doesn't help you -- that's OK. There 
are other languages too" -- we may have more freedom to explore 
what D can do best. I've done compile- time stuff in D I would 
never have even considered attempting with C++ - and I haven't 
done nearly as much as others here. I don't think we've really 
explored the fullness of the language yet, and I wonder if 
that's only going to be possible if we quit comparing ourselves 
so much to C++.


I don't think D is designed to be a niche language. It's a 
general purpose language, open source with multiple 
implementations, solid engineering, and even has good-looking 
syntax. It's not niche at all, it just doesn't have hoards of 
users. D is well-positioned to be hugely popular, but I think to 
succeed its leadership needs to be willing to fix things they 
want to fix and not worry about breaking backcompat.

Re: Which language futures make D overcompicated?

[John Gabriele via Digitalmars-d]

On Friday, 9 February 2018 at 19:08:36 UTC, John Gabriele wrote:


Would it make sense to split out dub's build functionality from 
its package management? Separate sharp tools for separate jobs.


I've only heard of Atila's reggae today. Is reggae commonly 
used among D users? Are there any show stoppers to using it in 
place of dub for building dub-managed projects?


Ah. I see that I should probably first look into Meson and SCons 
as well as Reggae.

Re: Which language futures make D overcompicated?

[John Gabriele via Digitalmars-d]

On Friday, 9 February 2018 at 18:40:25 UTC, Seb wrote:

On Friday, 9 February 2018 at 18:13:08 UTC, Russel Winder wrote:

On Fri, 2018-02-09 at 16:10 +, Seb via Digitalmars-d wrote:



[…]

Dub is not dead, it just has limited resources.


So , if the D community want Dub to work as a build system as 
well as a package manager, extend the resources by corralling 
the grumblers and support them into fixing code and creating 
pull requests.



I already but my limited resources into real and _merged_ pull 
requests for actual bugs at dlang/dub
Please if you have ideas to motivate the grumblers to do so as 
well, act!


Would it make sense to split out dub's build functionality from 
its package management? Separate sharp tools for separate jobs.


I've only heard of Atila's reggae today. Is reggae commonly used 
among D users? Are there any show stoppers to using it in place 
of dub for building dub-managed projects?

Re: A betterC base

[John Gabriele via Digitalmars-d]

On Thursday, 8 February 2018 at 15:51:38 UTC, Adam D. Ruppe wrote:

On Thursday, 8 February 2018 at 15:43:01 UTC, ixid wrote:
That's been said over and over and the message has not gotten 
through.


It is almost never said! We always play by their terms and 
implicitly concede by saying "but we can avoid it" or "look 
-betterC".


Reddit invades our space, and we fall back. Rust assimilates 
entire worlds, and we fall back. Not again! The line must be 
drawn here! This far, no further!


Woot! Love it. :) Will save that quote you provided to use 
elsewhere. Thanks.


Regarding what you said about the implementation of the GC 
following in the footsteps of industry giants, what specifically 
about D's GC impl is patterned after other industry giant's GC's?

Re: Quora: Why hasn't D started to replace C++?

[John Gabriele via Digitalmars-d]

On Wednesday, 7 February 2018 at 21:02:11 UTC, data pulverizer 
wrote:
On Tuesday, 30 January 2018 at 20:45:44 UTC, Andrei 
Alexandrescu wrote:

https://www.quora.com/Why-hasnt-D-started-to-replace-C++

Andrei


The Betamax Problem


I don't think the analogy holds. With VHS and betamax, you just 
put in the tape and watch your movie. Most people didn't care 
very much what the name on the machine said --- both types of 
machines had the same buttons.


In contrast to that, programmers are very particular about the 
languages they use (which includes tooling, community, module 
repos, available books).


An important question is what problem set does D solve? It's 
very hard to sell a language to industry without convincingly 
answering that question. If you are selling them a 'better' 
language - that's a tougher sell. If you are selling a solution 
to a particular problem set - you stand better a chance.


My impression is that the object is not necessarily to sell D to 
industry, but rather to sell it to developers. Developers choose 
what they want to learn and use at home and in side projects. 
Then at work some tools here and there get written in it. Then 
some customer-facing projects. Before you know it, it's been 
"sold to industry".


I think, as of last year, D has upped its sales (to developers) 
game:


  * fully open-sourced dmd

  * GDC slated for inclusion into GCC

  * there's been talk of adding some markdown features to ddoc. 
Cosmetic, yes; sells D well to developers, emphatically yes.


I'm not sure how long dub has been around, but having an easy to 
use CPAN-alike (online module repo) is HUGE. Dub is great for 
sales. The better dub and the repo gets, the more attractive D 
gets.

Re: Quora: Why hasn't D started to replace C++?

[John Gabriele via Digitalmars-d]

On Friday, 2 February 2018 at 14:30:25 UTC, Russel Winder wrote:
On Thu, 2018-02-01 at 19:28 +, John Gabriele via 
Digitalmars-d wrote:
On Thursday, 1 February 2018 at 03:00:07 UTC, Walter Bright 
wrote:

> On 1/31/2018 5:58 PM, H. S. Teoh wrote:
> > cosmetic features.
> 
> I tough lesson I've learned is that cosmetics matter, a lot. 
> Sometimes much more than substance. There's no getting away 
> from it.


I agree but only if s/Markdown/AsciiDoctor/g

This is one reason I recommend markdown for docs. Cosmetics is 
what markdown does best. People *like* looking at it and 
editing it. It's like typing an email or a forum comment.


Other reasons I recommend it are:

   * everyone already knows it (it's at github, stackoverflow, 
and

reddit),

   * it's fairly easy to write (as easy as possible while still
looking good),

   * there's an open spec (CommonMark), and

   * writing new language-specific markup formats appears to be
something that's not done anymore. There's javadoc, texinfo,
doxygen, docbook, groff --- all very ... *mature* technologies.
In modern projects: Rust uses markdown, Python uses reST, Git
uses asciidoc --- all general-purpose non- language-specific
lightweight markup formats.

The only reason I can think of for *not* using markdown for 
project docs is if your project is another competing 
lightweight markup format.


Markdown was created to write a few HTML pages. AsciiDoc (and 
thus AsciiDoctor) was invented to be a front end to the 
DocBook/XML toolchain.


Thus Markdown is for a few small very simple webpages, 
AsciiDoctor is for creating any form of document from a page to 
a book. They are similar where Markdown has functionality, but 
AsciiDoctor has so much more, and most people end up finding 
they want all the extras. XeLaTeX and Sphinx/ReStructuredText 
are the competition for AsciiDoctor. Markdown is lacking in 
functionality people will find they need to use.


Note that markdown is a small sharp tool in your toolbox: for 
writing easily readable (in plain text) docs, easily converted to 
html. For more than that, tools like [Pandoc](http://pandoc.org):


  * convert markdown to html but also to a bunch of other formats 
as well, and


  * support extra markdown functionality like tables, definition 
lists, footnotes, and citations. Don't know how if handles making 
an index.


Also, note that it's not uncommon to write a short script that 
stitches together a handful of markdown docs into a website or 
other larger composite doc. I even wrote one myself: 
<http://www.unexpected-vortices.com/sw/rippledoc/index.html>. 
There may be others listed at 
<https://github.com/jgm/pandoc/wiki/Pandoc-Extras>.

Re: Quora: Why hasn't D started to replace C++?

[John Gabriele via Digitalmars-d]

On Friday, 2 February 2018 at 14:25:53 UTC, Russel Winder wrote:
On Thu, 2018-02-01 at 19:41 +, John Gabriele via 
Digitalmars-d wrote:



[…]
It's trivial to put multiple markdown files together into a 
large doc, if that's desired. Just put a bunch of .md files 
together into the same directory and run your markdown 
processor on them. They can link to each other in the [normal 
way](./other-file.html#normal-way).


Auto generation of contents pages, and indexes? Tables? Nested 
lists? The CommonMark crib sheet says nothing. AsciiDoctor has 
all of them, though I prefer XeLaTeX.


CommonMark is the less featureful common denominator markdown. 
For myself, to get TOC's and tables I use 
[Pandoc](http://pandoc.org/).


But I see your point. For larger complete documents like books, 
you want tools that can handle all the things that books require.


But, afaik, we're talking about 2 specific needs here:

 1. documenting code in a way that gets extracted and rendered 
into html

 2. dlang.org doc webpages

with a secret 3rd need: you want contributors to be willing to 
write and update these.


Markdown provides a simple, practical, modern, and 
commonly-known way to get docs written fast and by anyone who 
wants to pop in and improve them. There's no easier way to 
write plain text docs that look as good.


AsciiDoctor.


Everyone already knows and uses Markdown. It's so common that it 
gets used in plain text forums like this one, sometimes without 
folks even knowing they're using it. For short plain text docs 
that may be converted to html, markdown has won and is the 
easiest on-ramp for some writer who has a few minutes and is 
willing to write some doc-comments for a function (or a confusing 
passage in the docs) that they just stumbled over.


Sorry, can't recall if I already mentioned this, but D suffers 
from a perception that it's "old", or "the language that tried 
and failed to replace C++". Something simple like markdown for 
its docs sends a clear message that D is modern and knows when 
to pivot to new and better ways after the old ways are not 
serving it anymore.


Markdown is so last decade. Ditto AsciiDoctor. XeLateX so last 
millenium. The question is choosing the right tool for the job, 
not pandering to hipster fashionistas. Clearly one reviews new 
ways and moves to them if that provides a better way forward, 
but the goal is more important that the technology.


I wouldn't say markdown is last decade (not sure if you're 
joking). More like it's simply become part of the background at 
this point since it's so commonly used.


But I agree about not pandering to fashion. The goal is to make 
it as easy as possible to document your code and have tools 
render it as html for users to make use of, as well as making it 
easy as possible for potential contributors to jump in and make 
edits/improvements. I think markdown is the best way to acheive 
that goal.


There are the autogenerated reference pages. JavaDoc, Doxygen, 
all have their upside and downside. D has DDOC, is it fit for 
purpose? Should it be replaced (by Doxygen) or evolved? Maybe 
Markdown fits here, but without table support you end up 
hacking stuff. cf. vast tracts of early JavaDoc stuff.


Pandoc extends CommonMark and has tables, definiton lists, and a 
couple of other things worth imitating. Regarding tables, it 
supports three styles (again, the default easy-on-the-eyes style, 
plus a couple others --- see their docs). See 
<http://pandoc.org/MANUAL.html#tables>.





Incidentally, choosing an established standard like markdown 
is a good way to short-circuit bikeshedding about "it what 
ways should ddoc be updated to include some markdown 
features?". Just pick standard CommonMark markdown and you're 
done.


s/Markdown/AsciiDoctor/g


AsciiDoctor appears to be tuned for writing long docs like books. 
Markdown beats it on looks, convenience, and popularity --- 
exactly the things you want to attract folks to writing more 
comment docs and web pages.


One last note and I'll (try to!) stop: it's difficult enough 
to get good writers to help with docs. Much more so when 
they've got to first learn your own language-specific markup 
(which is only useful with your project).


This is a good and strong point, that has been raised in many 
other places I frequent. One group changed from their custom 
DocBook/XML to Sphinx because someone did stuff rather than 
talking about it. AsciiDoctor would clearly have been a better 
solution, evolution using the DocBook toolchain, but they went 
for the revolution because people put effort into it to make 
the decision happen.


The core point is how are you going to get pull requests from 
people to update and evolve the documentation. An esoteric, 
indeed unique, markup language is clearly the wrong choice.


I don't understand your comment there. I group DDoc, Docbook XML, 
DDoc, Texinfo, groff, etc. all in the same esoteric unique

Re: My choice to pick Go over D ( and Rust ), mostly non-technical

[John Gabriele via Digitalmars-d]

On Monday, 5 February 2018 at 22:56:47 UTC, Jonathan M Davis 
wrote:
On Monday, February 05, 2018 18:54:32 John Gabriele via 
Digitalmars-d wrote:
What is the specific purpose of -betterC? I see from 
<https://dlang.org/spec/betterc.html> that it's (A) useful 
when targeting constrained environments, and (B) for easier 
embedding of D libraries into larger projects. But I think 
I've read elsewhere in this forum that it was specifically 
useful for the DMD implementation itself.


Is betterC intended to be used for standalone "D -betterC" 
programs where C might've otherwise been used? My impression 
of D so far is that it can indeed already be used as a better 
C by avoiding the GC yourself, or invoking it yourself when 
appropriate.


It may be useful if that betterc.html page gave a rationale 
for it; to avoid any confusion on what its intended purpose is.


Based on Walter's comments, I get the impression that he thinks 
that the primary benefit of -betterC is to make it easier to 
port a C program to D, because then you can port it piece by 
piece rather than having to do it all at once. After that, it's 
D, and you can ditch -betterC and start taking advantage of the 
full feature set of D. Certainly, that's all that I would ever 
consider using -betterC for. I have zero interest in giving up 
on the features that require druntime. If I were going to 
consider that, I'd just ditch D for C++. At least then, I'd get 
a fully featured language even if it isn't as nice as D.


Thanks, Jonathan! Sounds like a great tool to have available to 
assist migrating to D.


However, there are some folks who like the idea of using 
-betterC as their primary or only way to use D, because they 
don't want the runtime for whatever reason. Some of that comes 
from the fact that it's easier to link against a D library from 
a C/C++ program when the D library doesn't require the runtime, 
but I don't think that that's the only reason.


Ah, I see. Around this notion then is where I'm seeing some folks 
here concerned about D "choosing a direction". If your impression 
(your first paragraph) is correct, then D has actually not 
changed direction (wrt betterC) in the first place.


Incidentally, this is one of those situations that reminds me how 
important names are, for example:


  * "D" = "the new and improved next incarnation of C/C++"
  * "-betterC" = "use this as a better (and in place of) C"

Naming is hard!

Re: My choice to pick Go over D ( and Rust ), mostly non-technical

[John Gabriele via Digitalmars-d]

On Sunday, 4 February 2018 at 11:14:43 UTC, JN wrote:

On Friday, 2 February 2018 at 15:06:35 UTC, Benny wrote:
You want to produce PDFs? fpdf 2015-Apr-06, a very limited PDF 
generation tool last updated 3 years go.




While not as trivial as just using a dub package, D easy 
interop with C means you can use C libraries for PDF like 
libharu or w/e.



* Are you targeting C developers?

Sure BetterC is a way towards that but again, what do you 
offer more then Rust? I see C developers more going for Rust 
then D on this point. Or hell even Zig or Jai or whatever 3 
letter flavor of the month language.




The problem with flavor of the month languages is that people 
switch to them, play with them for a bit and abandon them. To 
quote Bjarne Stroustrup: "There are only two kinds of 
languages: the ones people complain about and the ones nobody 
uses". Languages like D or Java fall into the "get stuff done" 
category. They don't try to reinvent programming, they don't 
use the latest abstract higher order category theory union type 
lambdas, so they are considered boring by the language-hoppers. 
That's not a flaw of the language.


Personally I agree that BetterC isn't a good alternative for C 
programmers. Sure, you get some benefits of D, but you will 
lose many benefits of C and you'll have to constantly fight 
"wait, can I use this in BetterC or not" kind of thing.


What is the specific purpose of -betterC? I see from 
 that it's (A) useful when 
targeting constrained environments, and (B) for easier embedding 
of D libraries into larger projects. But I think I've read 
elsewhere in this forum that it was specifically useful for the 
DMD implementation itself.


Is betterC intended to be used for standalone "D -betterC" 
programs where C might've otherwise been used? My impression of D 
so far is that it can indeed already be used as a better C by 
avoiding the GC yourself, or invoking it yourself when 
appropriate.


It may be useful if that betterc.html page gave a rationale for 
it; to avoid any confusion on what its intended purpose is.

Re: Quora: Why hasn't D started to replace C++?

[John Gabriele via Digitalmars-d]

On Thursday, 1 February 2018 at 11:06:09 UTC, Russel Winder wrote:
On Wed, 2018-01-31 at 16:13 +, John Gabriele via 
Digitalmars-d wrote:

[…]
this older language from times past, before C++11, and using 
ddoc
for docs instead of markdown contributes to this perception. 
Let
me know if you'd like help in translating D website and doc 
pages

from ddoc to markdown.


I am sure Markdown is find for single page HTML pages, but for 
bigger documents that need to render to HTML or PDF (or other 
e-publishing formats) surely AsciiDoctor and XeLaTeX are the 
only choices.


It's trivial to put multiple markdown files together into a large 
doc, if that's desired. Just put a bunch of .md files together 
into the same directory and run your markdown processor on them. 
They can link to each other in the [normal 
way](./other-file.html#normal-way).


Markdown provides a simple, practical, modern, and commonly-known 
way to get docs written fast and by anyone who wants to pop in 
and improve them. There's no easier way to write plain text docs 
that look as good.


Sorry, can't recall if I already mentioned this, but D suffers 
from a perception that it's "old", or "the language that tried 
and failed to replace C++". Something simple like markdown for 
its docs sends a clear message that D is modern and knows when to 
pivot to new and better ways after the old ways are not serving 
it anymore.


Incidentally, choosing an established standard like markdown is a 
good way to short-circuit bikeshedding about "it what ways should 
ddoc be updated to include some markdown features?". Just pick 
standard CommonMark markdown and you're done.


One last note and I'll (try to!) stop: it's difficult enough to 
get good writers to help with docs. Much more so when they've got 
to first learn your own language-specific markup (which is only 
useful with your project).

Re: Quora: Why hasn't D started to replace C++?

[John Gabriele via Digitalmars-d]

On Thursday, 1 February 2018 at 03:00:07 UTC, Walter Bright wrote:

On 1/31/2018 5:58 PM, H. S. Teoh wrote:

cosmetic features.


I tough lesson I've learned is that cosmetics matter, a lot. 
Sometimes much more than substance. There's no getting away 
from it.


This is one reason I recommend markdown for docs. Cosmetics is 
what markdown does best. People *like* looking at it and editing 
it. It's like typing an email or a forum comment.


Other reasons I recommend it are:

  * everyone already knows it (it's at github, stackoverflow, and 
reddit),


  * it's fairly easy to write (as easy as possible while still 
looking good),


  * there's an open spec (CommonMark), and

  * writing new language-specific markup formats appears to be 
something that's not done anymore. There's javadoc, texinfo, 
doxygen, docbook, groff --- all very ... *mature* technologies. 
In modern projects: Rust uses markdown, Python uses reST, Git 
uses asciidoc --- all general-purpose non- language-specific 
lightweight markup formats.


The only reason I can think of for *not* using markdown for 
project docs is if your project is another competing lightweight 
markup format.

Re: Quora: Why hasn't D started to replace C++?

[John Gabriele via Digitalmars-d]

On Wednesday, 31 January 2018 at 20:03:11 UTC, Adam D. Ruppe 
wrote:


{snip} (well, I tried to get it upstream but I think upstream 
is a brick wall and not worth trying anymore)


That is very concerning to hear.

Re: Quora: Why hasn't D started to replace C++?

[John Gabriele via Digitalmars-d]

On Wednesday, 31 January 2018 at 17:30:54 UTC, H. S. Teoh wrote:

On Wed, Jan 31, 2018 at 05:20:59PM +, Seb via Digitalmars-d


Please let us know what would help you to find this page 
quicker.


Wow.  I set out *deliberately* looking for that link, and 
couldn't find it until I looked at your screenshot. I 
definitely wouldn't have found it if I didn't even know it was 
there.


I just discovered that the individual os-specific dmd downloads 
*also* have links associated with them.


Seb, I've added a comment to your PR 2154. Thanks.

Re: Quora: Why hasn't D started to replace C++?

[John Gabriele via Digitalmars-d]

On Wednesday, 31 January 2018 at 11:42:14 UTC, Seb wrote:

On Wednesday, 31 January 2018 at 10:35:06 UTC, Benny wrote:

And 3 different installation method's depending on the 
platform.


Windows: DMD installer, LDC manually extract zip and setup 
path, GDC ...


That's only an issue on Windows.
For Posix there's the official install.sh script [1].

[1] https://dlang.org/install.html


I've never seen that page. Would've helped me to see it earlier. 
The D download page should include a blurb with a link to that 
install page.


I tried going to github.com/dlang/dlang.org, finding the download 
page, and adding a blurb+link to install.html above those `curl 
... install.sh` commands, but that download.dd page is written in 
a format I'm not familiar with. It's difficult to read, and 
appears quite clumsy to write as well.


It surprises me that D docs are written in that ddoc macro format 
--- especially for standalone docs like the download page. I 
think people unfamiliar with D have a perception of D as being 
this older language from times past, before C++11, and using ddoc 
for docs instead of markdown contributes to this perception. Let 
me know if you'd like help in translating D website and doc pages 
from ddoc to markdown.

Re: How programmers transition between languages

[John Gabriele via Digitalmars-d]

On Tuesday, 30 January 2018 at 09:20:37 UTC, aberba wrote:

On Sunday, 28 January 2018 at 18:54:34 UTC, Laeeth Isharc wrote:

On Sunday, 28 January 2018 at 13:50:03 UTC, Michael wrote:


Enterprises care about making money with whatever will help 
them do that (impress investors). Its developers who care about 
languages that help them write code that suites their 
requirements. The focus should be on developers not companies. 
People using D cannot be represented by Microsoft,
 Sociomantic,  Weka,  etc. employees. Its of no use chasing 
after companies... make it useful and everyone else will come.


If you want to draw people to the language (and, honestly, I 
wonder why it matters so much to many here


Its a simple math well understood since long ago.  The larger 
the army/workforce the better. Things get done. Walter always 
say here "Its left with someone to do the work". There other 
stuff he doesn't address including those outside language 
internals.



- it's clearly
taking hold, has momentum and will continue to grow for 
decades; an acorn will become an oak tree, and fretting about 
how much it's grown in the past year might be missing the 
point, so long as it's healthy enough), why not just focus on 
both improving the language itself (pull requests, 
documentation)


Someone needs to do that and we're short of people willing,  
have the time and able to do that.


Either someone is paid to care enough to do that (Like Google 
do with Go, Oracle with Java,  Jetbrains with Kotlin,  etc.) OR 
grow a community/workforce to collectively make that happen.



and on accomplishing something useful and worth doing with it?


There's also a possibility the acorn will loose interest and 
momentum and... die. Your opinion on what is worth doing is 
based on your domain or interest.


I get the impression that a wave is coming (or is already here) 
where people more and more are looking for modern 
natively-compiled statically-typed languages --- leaving 
Python/Perl/Ruby/PHP/JS --- not only for performance, but for 
easier development for larger projects.


The languages I see benefiting primarily from this wave are D, 
Rust, Go, and Kotlin/Native.


Of those, my impression is that Rust and Kotlin are perceived as 
the most modern. Go and Rust have some hype, but Go's hype seems 
to have already peaked. D appears well-positioned (good 
community, high-level with GC, has dub and , docs 
and books are available).


If there are areas of D that need to be modernized, streamlined, 
or simplified, but which will break backcompat, now may be a 
excellent time to consider beginning those changes/deprecations.

Re: How programmers transition between languages

[John Gabriele via Digitalmars-d]

On Friday, 26 January 2018 at 20:08:15 UTC, Paulo Pinto wrote:

On Friday, 26 January 2018 at 18:46:12 UTC, John Gabriele wrote:


One niche I could see D establishing some popularity is in 
GNU/Linux GTK desktop apps. Especially now that GDC will be 
part of GCC.


With GNOME in the process of adopting Rust, I don't have big 
hopes for it.


https://wiki.gnome.org/Hackfests/Rust2017

https://wiki.gnome.org/Hackfests/Rust2017-2


With Rust's extra complexity (over D) of ownership/borrowing, 
lifetimes, and no GC, although we may currently see a push for 
more Rust in Gnome for system-level code, I think D may beat it 
for writing *applications*.


I'm planning on learning more D, then trying out GtkD to see how 
it compares with Python + PyGObject for some little apps.

Re: How programmers transition between languages

[John Gabriele via Digitalmars-d]

On Friday, 26 January 2018 at 17:24:54 UTC, Benny wrote:


What i found interesting is the comparison between the "newer" 
languages and D ( see the reddit thread ).


 9  Go  4.1022
15  Kotlin  1.2798
18  Rust0.7317
35  Julia   0.0900
46  Vala0.0665
50  Crystal 0.0498
53  D   0.047%

While i can understand Rust ( Mozilla ), Kotlin ( Jetbrain ), 
Go ( Google ).

Even Vala and Crystal are ranked higher then D.


One niche I could see D establishing some popularity is in 
GNU/Linux GTK desktop apps. Especially now that GDC will be part 
of GCC.

Re: [dlang library documentation] Why there are dlang.org/library and dlang.org/phobos?

[John Gabriele via Digitalmars-d-learn]

On Tuesday, 23 January 2018 at 19:05:21 UTC, Seb wrote:

On Monday, 22 January 2018 at 19:38:45 UTC, John Gabriele wrote:
On Monday, 22 January 2018 at 15:32:29 UTC, Adam D. Ruppe 
wrote:

On Monday, 22 January 2018 at 15:18:38 UTC, Johann wrote:

Maybe it's due to historical reasons.


It's actually "future" reasons... the /phobos is the original 
one, and /library was supposed to replace it, but now many 
years later, /library is still kinda neglected and they both 
just exist.


What's needed to remove the "/phobos" one? Is it a decision 
from on-high, or is there a lot of editing of hardcoded links 
required?


This discussion and the referenced news group thread should 
give insights:


https://github.com/dlang/dlang.org/pull/1526



Thank you!

Re: [dlang library documentation] Why there are dlang.org/library and dlang.org/phobos?

[John Gabriele via Digitalmars-d-learn]

On Monday, 22 January 2018 at 15:32:29 UTC, Adam D. Ruppe wrote:

On Monday, 22 January 2018 at 15:18:38 UTC, Johann wrote:

Maybe it's due to historical reasons.


It's actually "future" reasons... the /phobos is the original 
one, and /library was supposed to replace it, but now many 
years later, /library is still kinda neglected and they both 
just exist.


What's needed to remove the "/phobos" one? Is it a decision from 
on-high, or is there a lot of editing of hardcoded links required?


This is a reason why I forked the d docs to my site 
dpldocs.info. Check out its search:


http://dpldocs.info/writef

But yeah, the link in the original source is hardcoded for the 
/phobos path... but is also a relative link. So when generated 
on /library, it is just a 404. On my fork, I just fixed it, but 
/library tries to build from the master branch so they can't 
really just fix things without making sure it still works in 
both generators. what a mess.


I'm not sure I understand. What would it take to make the 
"/library" pages good enough that you wouldn't need 
?

Re: The name "Phobos" in user-facing docs

[John Gabriele via Digitalmars-d]

On Friday, 12 January 2018 at 22:24:16 UTC, Dukc wrote:

On Friday, 12 January 2018 at 21:24:40 UTC, John Gabriele wrote:
 1. It has its own name. Phobos. This is unusual. I don't know 
of any other language who's std lib has any name other than 
"the {lang} standard library". Why does it have its own 
distinct name, and why do I (as a user) need to know it?


Because Walter Bright's company is named Digital Mars, D was 
initially named "Mars programming language". I am fairly 
certain that's the original reason for the name of the library. 
After all, why change it now when it's in common use? Where I 
live we have a saying: "A dear child has many names".


I don't think it should be changed, just removed from a few 
user-facing spots to increase clarity and remove any doubt about 
what's the D standard library.


Links and titles should just say "D Standard Library" or "Library 
Reference", and not mention "Phobos". It's a distraction to new 
users or possibly-returning-users who were around during the 
D1->D2 std lib transition.


On , it appears to me that 
it shouldn't say "phobos" anywhere (it's only in the top 
paragraphs as it is). Though maybe Walter or others like Phobos 
mentioned there for nostalgic reasons.


Anyhow, my comments aren't intended as complaints, but rather 
what I see as low-hanging easy marketing improvements for D.

The name "Phobos" in user-facing docs

[John Gabriele via Digitalmars-d]

After having started learning some D lately, two things about the 
standard library have struck me:


 1. It has its own name. Phobos. This is unusual. I don't know of 
any other language who's std lib has any name other than "the 
{lang} standard library". Why does it have its own distinct name, 
and why do I (as a user) need to know it?


 2. There is evidently *still* some lingering FUD out there about 
some long-since-settled dual-standard-library issue. I haven't 
been around here long enough, but I still see references to Tango 
here and there.


I think it would help D's image to simply remove the name 
"phobos" from any user-facing docs. That is, change "phobos" to 
"the standard library" everywhere users would be looking. (Of 
course, *internally* the name "phobos" may still be useful for 
repo names, mailing list names, and what have you.)


Just the fact that the std lib *has* it's own user-facing name 
suggests that there may be more than one standard library (or 
else, why would it need its own special name to begin with?). It 
may also imply that the door is open for some other young upstart 
library to swoop in usurp the title of official standard library. 
The standard library having its own distinct user-facing name 
appears to sow confusion.


Maybe, historically, it was useful to have distinct names for 
competing potential D standard libraries, in order to distinguish 
them. Is that still the case?

Re: Maybe D is right about GC after all !

[John Gabriele via Digitalmars-d]

On Thursday, 28 December 2017 at 15:57:18 UTC, Paulo Pinto wrote:
On Thursday, 28 December 2017 at 11:27:29 UTC, Russel Winder 
wrote:
On Wed, 2017-12-27 at 18:41 +, Laeeth Isharc via 
Digitalmars-d wrote:



[…]
However the GStreamer folk are backing Rust (for memory safety 
issues noted earlier) so even though D has a GStreamer binding 
(thanks to Mike and GtkD) I more or less have to use Rust 
because it is the official binding. Comparing and contrasting 
D and Rust is interesting for me. Both have many pluses and 
many minuses. However, in the end, the GStreamer core people 
know C, C++ a bit, D not at all. I suspect even if the choice 
had been Rust or D, Rust would have been chosen because it has 
no GC and D is a GC language.


Not only GStreamer, Rust is on its way to become an offical 
GNOME language, and who knows, eventually take over Vala's role.


I haven't followed Gnome+Rust news. What suggests Rust may be on 
its way to become an official Gnome language?


I'd think that people looking to write apps for Gnome would be 
more inclined to use a *higher*-level language, like D (see GtkD) 
or Python (see PyGObject) rather than a lower-level one like Rust 
where there's a need to deal with borrowing and lifetimes.


Another possible contender I'd forgotten about: 
[Kotlin/Native](https://github.com/JetBrains/kotlin-native). I 
see they have some sample code for using GTK: 
.

Re: D as a betterC a game changer ?

[John Gabriele via Digitalmars-d]

On Wednesday, 27 December 2017 at 20:53:46 UTC, Dan Partelly 
wrote:
On Wednesday, 27 December 2017 at 19:13:15 UTC, John Gabriele 
wrote:


Although I don't know D very well yet, it sounds like Russel 
hits the nail precisely on the head here. FWICT, folks have 
lately used scripting languages (ex. Python, Perl, Ruby) for 
larger and larger programs (and even JS+Node for local apps),


Resulting in terrible software. Take text editors written in 
JS+Electron. Slow bloated crap. {snip}


Maybe I wasn't being very clear there. Also, my unedited comment 
on that was:


Although I don't know D very well yet, it sounds like Russel 
hits the nail precisely on the head here. FWICT, folks have 
lately used scripting languages (ex. Python, Perl, Ruby) for 
larger and larger programs (and even JS+Node for local apps), 
but it seems to me like the pendulum is swinging back the other 
way as everyone wants optional types and also JIT 
implementations like [PyPy](http://pypy.org/).


with my point being that I think we're seeing many scripting 
language users now wanting the features that D already has 
(types, type inference, high performance and less resource usage 
(natively compiled)). I think it's a good time for D to attract 
those users.

Re: D as a betterC a game changer ?

[John Gabriele via Digitalmars-d]

On Wednesday, 27 December 2017 at 16:46:18 UTC, Russel Winder 
wrote:
On Wed, 2017-12-27 at 08:59 +, Dan Partelly via 
Digitalmars-d wrote:



[…]
I could not agree more with this. It is unfortunate D has 
dependencies on a garbage collector in language proper and in 
std.


Given the current situation, D's best route to traction is to 
embrace GC and ignore all complaints other than "give us a 
better GC". (*)


It is all about differentiation. Forget competing against C, 
C++, and

Rust. D is the   C++ inspired language with GC that isn't Go.


[…]


(*) "Better C" is a specialist use case for Walter and the D 
backend.


Although I don't know D very well yet, it sounds like Russel hits 
the nail precisely on the head here. FWICT, folks have lately 
used scripting languages (ex. Python, Perl, Ruby) for larger and 
larger programs (and even JS+Node for local apps), but it seems 
to me like the pendulum is swinging back the other way as 
everyone wants optional types and also JIT implementations like 
[PyPy](http://pypy.org/).


I think the D wiki would benefit from an article on how D 
competes-with/differs-from Go.


Also, as a related aside, another language that D competes with 
is Vala. Now that D is part of GCC, I wonder if D could replace 
Vala.

Re: Maybe D is right about GC after all !

[John Gabriele via Digitalmars-d]

On Friday, 22 December 2017 at 16:17:33 UTC, Dan Partelly wrote:
On Friday, 22 December 2017 at 15:23:51 UTC, Russel Winder 
wrote:
I think we are now in a world where Rust is the zero cost 
abstraction language to replace C and C++, except for those 
who are determined to stay with C++ and evolve it.


Why should we settle for this ? D code (efortless) is easier to 
read then Rust. I assume this to be true for a lot of 
programmers who know C/C++. It also introperates very well with 
C, which is great boon, since at low level we live on the 
shoulder of a titan written in C.  It has tremnedous features, 
and ironically the best of them could have been designed to not 
relay on GC. As most , if not all, of the features offered by 
its library could have been done with no GC.




D, like Go, should glory in having a GC and just go with it.

Of course this does not mean the GC as is is good enough. Go 
is on its

third I believe, and Java on it's fifth.


A good implementation at library level of GC would mean that I 
can use one single language
in all areas of system programming. Or at least, a 
implementation where std:: and core features of language should 
not relay on GC. This, IMO is an advantage not to be neglected. 
A better C mode with a very powerfull high level standard 
library (like std:: ), exceptions, RAII, classes (yes, why not 
) typeid would be a very big step ahead. All those could be 
done without having to worry about existence of GC. C++ has all 
those.


IMO the key here is the standard libray of the language. 
Nothing in it should relay  on the existence of GC. Why, why, 
does it have to depend on GC and hence automatically disqualify 
itself from a better C world ? The C runtime ezposed by core is 
powerfull, but imagine having std:: power in better C as well. 
I really lament this.


You could have the best of the two worlds.


Regarding GC being built into the core language, from [the D 
faq](https://dlang.org/faq.html):


"**Can't garbage collection be done in C++ with an add-on 
library?**


Yes, I use one myself. It isn't part of the language, though, and 
requires some subverting of the language to make it work. Using 
gc with C++ isn't for the standard or casual C++ programmer. 
Building it into the language, like in D, makes it practical for 
everyday programming chores."


I'm new to D. Coming primarily from Python these days, I'm 
looking at D not as a better C++ (haven't used that in many 
years), but as a better Python.

What is this "dd" doc format?

[John Gabriele via Digitalmars-d]

I just went looking for the source for the dlang.org overview 
page, and found 
[this](https://github.com/dlang/dlang.org/blob/master/overview.dd).


I've seen and used a lot of markup formats, but have never run 
across this. What format is it? Also curious: for what reasons 
was it chosen over a more customary markup?


Thanks.

Re: Wiki down?

[John Gabriele via Digitalmars-d]

On Friday, 15 December 2017 at 21:25:52 UTC, H. S. Teoh wrote:
On Fri, Dec 15, 2017 at 08:40:17PM +, John Gabriele via 
Digitalmars-d wrote:
Not sure where to mention this, but it appears that the wiki's 
down (for me at least). I can ping it, but it won't come up in 
my browser.


Down for me too. It comes up with a message saying they're 
experiencing technical difficulties. :-(



T


Thanks. I see it's up again now.

Wiki down?

[John Gabriele via Digitalmars-d]

Not sure where to mention this, but it appears that the wiki's 
down (for me at least). I can ping it, but it won't come up in my 
browser.

Re: Adding Markdown to Ddoc

[John Gabriele via Digitalmars-d]

On Tuesday, 12 December 2017 at 15:59:42 UTC, John Gabriele wrote:
On Monday, 11 December 2017 at 00:54:00 UTC, Walter Bright 
wrote:


I have a more pragmatic definition of a standard:

1. Products that implement it say they adhere to it and defer 
to it as the authority on correct behavior.


2. There's more than one such product.

3. There's more products adhering to that standard than some 
other competing standard.


So far as I know, commonmarkdown satisfies zero of those.


Looks like Stack Exchange is working on standardizing on 
CommonMark:




Rust is as well: .

Re: Adding Markdown to Ddoc

[John Gabriele via Digitalmars-d]

On Monday, 11 December 2017 at 00:54:00 UTC, Walter Bright wrote:


I have a more pragmatic definition of a standard:

1. Products that implement it say they adhere to it and defer 
to it as the authority on correct behavior.


2. There's more than one such product.

3. There's more products adhering to that standard than some 
other competing standard.


So far as I know, commonmarkdown satisfies zero of those.


Looks like Stack Exchange is working on standardizing on 
CommonMark:

Re: Adding Markdown to Ddoc

[John Gabriele via Digitalmars-d]

On Monday, 11 December 2017 at 00:54:00 UTC, Walter Bright wrote:

Don't get me wrong, I think commonmarkdown is a worthy effort, 
and is definitely in the running to be a standard. Certainly a 
lot more effort seems to have been put into it vs other 
markdowns.


Note that CommonMark isn't simply a markdown implementation. It's 
a:


  * spec
  * test suite
  * two reference implementations
  * collection of community implementations

and also includes an active community forum.

The people involved are dedicated. The spec is conservative, 
uncontroversial, and detailed.


But implementing commonmarkdown in Ddoc is not what we're going 
to do, at least for the near term.


Right. That said, if you want to add a handful of markdown-ish 
features, I think it would be most useful to draw your very 
limited markdown subset from the CommonMark markdown spec. The 
other option takes you down the road of unintentionally creating 
yet another variant for users to contend with.

Re: Adding Markdown to Ddoc

[John Gabriele via Digitalmars-d]

On Monday, 11 December 2017 at 15:45:07 UTC, Guillaume Piolat 
wrote:


The CommonMark approach is to just take the union of all 
possible features and call it a day.
Standards without opinions don't deserve to be implemented by 
anyone.


I disagree. If anything, it's more of a subset of features common 
to the most widely-used markdown implementations, with corner 
cases ironed out (see lots of discussion on the [CommonMark 
forum](https://talk.commonmark.org/), and also comparisons of 
output from different implementations at 
[Babelmark2](http://johnmacfarlane.net/babelmark2/) (linked to 
from commonmark.org)).

Re: Adding Markdown to Ddoc

[John Gabriele via Digitalmars-d]

On Friday, 8 December 2017 at 16:43:56 UTC, John Gabriele wrote:


If going forward with a rolling your own limited markdown 
version, go with a subset of CommonMark.


Sorry, typo, that should be, "consider going with".

Re: Adding Markdown to Ddoc

[John Gabriele via Digitalmars-d]

On Friday, 8 December 2017 at 10:13:28 UTC, Walter Bright wrote:

On 12/8/2017 1:48 AM, Jacob Carlborg wrote:


> I think we should try to support standard markdown [2]

Unfortunately, there's really no such thing.


Well, the main standardization effort is 
[CommonMark](http://commonmark.org/). They have a spec, test 
suite, and reference implementations in C and in JS. There's also 
a list of other implementations:


 (though D isn't there yet), as well as a community forum.

Here's [their 10-minute Markdown 
tutorial](http://commonmark.org/help/).


If going forward with a rolling your own limited markdown 
version, go with a subset of CommonMark. That subset could always 
grow into a full implementation of CommonMark if that's desired 
later on.

Re: Adding Markdown to Ddoc

[John Gabriele via Digitalmars-d]

On Wednesday, 6 December 2017 at 04:11:33 UTC, Walter Bright 
wrote:

https://help.github.com/articles/basic-writing-and-formatting-syntax/

Anyone interested in picking up the flag?

(I know this has come up before, and I've been opposed to it, 
but I've changed my mind.)


Great to hear this! :)

[Pandoc](http://pandoc.org/) is an excellent widely-used markdown 
implementation to emulate (or use directly); they support 
thoughtful additional syntax for definition lists, tables, 
mathematics, and a few other niceties (including syntax 
highlighting for D code blocks).

Re: git workflow for D

[John Gabriele via Digitalmars-d-learn]

On Sunday, 3 December 2017 at 20:05:47 UTC, bitwise wrote:
{snip} If anyone can offer any kind of advice, or an article 
that explains these things concisely and effectively, that 
would be helpful.


I found some git-specific info in this wiki page:

Re: Andrei's "The D Programming Language" book. Up to date?

[John Gabriele via Digitalmars-d-learn]

On Wednesday, 29 November 2017 at 17:26:11 UTC, Nick Treleaven 
wrote:
On Wednesday, 4 October 2017 at 20:49:26 UTC, John Gabriele 
wrote:
What's changed in the language, library, and community since 
then that I should be aware of if following along with and 
learning from that book?


Here's a list of significant things - maybe incomplete:
https://wiki.dlang.org/Differences_With_TDPL


Nice! Thanks, Nick!

Re: Thoughts about D

[John Gabriele via Digitalmars-d]

On Tuesday, 28 November 2017 at 08:58:46 UTC, Joakim wrote:


Since Mike started the official D blog last summer, downloads 
of the reference compiler are up 90%:


http://erdani.com/d/downloads.daily.png

I don't think that's a coincidence and attribute a significant 
chunk of that to his efforts and those who wrote posts, which 
is why I suggested starting an official blog years ago.


The big recent spike appears to coincide with DMD being 
re-licensed as fully open source, as well as the GDC inclusion 
into GCC.


Years ago I was interested in D but considered the licensing to 
be a show-stopper. I've recently come back to learn it proper and 
try it for some small projects precisely because of the licensing 
change.

Re: Advertise D's great compatibilty with JavaScript

[John Gabriele via Digitalmars-d]

On Monday, 19 June 2017 at 02:02:05 UTC, rikki cattermole wrote:

On 19/06/2017 2:57 AM, Laeeth Isharc wrote:
On Sunday, 18 June 2017 at 23:11:25 UTC, rikki cattermole 
wrote:

On 18/06/2017 5:29 PM, Meta wrote:
We should be careful not to make *too* close a comparison. 
While Javascript is a necessary evil for web applications 
and some people do like it, I get the feeling that it's 
becoming less and less liked. It's not quite a fractal of 
bad design like PHP, but it has more than a few drastic 
shortcomings and design flaws.


The moment webasm becomes a realistic target, I will do 
EVERYTHING in my power to get Lua in the browser (yes there 
already is solutions).


Stuff Javascript, kill it, replace it with something actually 
properly designed!


Why not D? And why wait till it's a realistic target? Wasm is 
clearly going to be the answer and it's an answer to a problem 
that exists, so what does one gain by waiting?


(1) eval
(2) time+not all API's required are available just yet.


Why do you choose Lua? Whatever replaces Javascript (and compiles 
to wasm) will be used for large apps, like how Javascript is 
currently used. My understanding is that Lua is not particularly 
well suited for building large apps.

Re: Emacs d-mode indentation, 2 spaces to 4?

[John Gabriele via Digitalmars-d-learn]

On Thursday, 5 October 2017 at 05:22:16 UTC, Ali Çehreli wrote:

On 10/04/2017 09:57 PM, John Gabriele wrote:
I'm using Emacs 25.2.2 with d-mode-20161022.717 on Debian 
Testing, and by default this mode indents by 2 spaces. Is 
there an easy way to configure it to use 4 spaces instead?




I can't imagine it has its own tab width. d-mode is based on 
cc-mode. Setting the tab width in that mode or in general 
should work for d-mode as well.


Just research tab width for Emacs. If nothing else works and 
you're happy with a global tab-width of 4, add this to your 
.emacs file:


(setq-default tab-width 4)

Ali


Thank you, but tried this and it didn't work. Aravinda's solution 
worked though.

Re: Emacs d-mode indentation, 2 spaces to 4?

[John Gabriele via Digitalmars-d-learn]

On Thursday, 5 October 2017 at 08:49:30 UTC, Aravinda VK wrote:
On Thursday, 5 October 2017 at 04:57:09 UTC, John Gabriele 
wrote:
I'm using Emacs 25.2.2 with d-mode-20161022.717 on Debian 
Testing, and by default this mode indents by 2 spaces. Is 
there an easy way to configure it to use 4 spaces instead?


Add below snippet to your .emacs file

(add-hook 'd-mode-hook
  (lambda ()
(setq c-basic-offset 4)
(setq tab-width 4)))



That did it! Thanks, Aravinda!

Emacs d-mode indentation, 2 spaces to 4?

[John Gabriele via Digitalmars-d-learn]

I'm using Emacs 25.2.2 with d-mode-20161022.717 on Debian 
Testing, and by default this mode indents by 2 spaces. Is there 
an easy way to configure it to use 4 spaces instead?

Andrei's "The D Programming Language" book. Up to date?

[John Gabriele via Digitalmars-d-learn]

Hi all,

This is my first message to this forum. And what a pleasure it is 
to be here. :)


I was just looking around at what D books are available. I see 
that Andrei's "The D Programming Language" was published in 2010. 
What's changed in the language, library, and community since then 
that I should be aware of if following along with and learning 
from that book?


Incidentally, is a new edition is on its way any time soon?

Thanks!