On 1/29/2016 12:26 AM, John Colvin wrote:
> It depends what you mean by templated. I believe the interoperability work is
> for the results of instantiated templates, not on the templates themselves.

That's right. D can link to instantiated templates, and will duplicate the layout. But D will not implement C++ semantics, such as how C++ does overload resolution on templates.

Guillaume Piolat
"- D is a large language, not sure how much relatively to Rust. I've heard Rust is complicated too."
and yet, it's easy to get started if you know C.  one can be quite quickly productive without having any experience of template metaprogramming, CTFE, and the like, and gradually absorb language features as you go.  Phobos is pretty readable, on the whole.  I agree with bearophile about GC making it easier in the beginning.

bearophile:
"I am sometimes able to write working D code almost as quickly as Python code"

Yes, indeed - that's my experience too.  I wonder what we could do to make this most of the time, if not almost always, and for less experienced programmers than you.  It wouldn't be surprising to find that the things that tend to get in the way fall in certain common categories.  Some people have applied machine learning to compilers to study this - that's probably beyond our resources for now, but the idea makes sense.  Adam's and others' work on error messages might be part of the answer.

Thank you for the colour on OcaML.  What could be done to improve Algebraic and pattern matching?  The talk at the London dmeetup was quite interesting, but I had the sense that was fairly experimental at this stage.

"There are several kinds of code that D allows you to write quite better than Rust (generic application code, script-like code, explorative scientific numerical code (like ndslice), medium-integrity code, metaprogramming, compile-time computations, template-level computations and specializations, higher order template magic, and so on. "

Should we make more of a feature of this in the intro page.  Tutorials per category showing the value?  And should the Rosetta stone examples (many of which you wrote, as I understand it) be more prominently featured?  Maybe even in the code samples on the front page too.

"In Ada you can be productive if you use it for the purposes it was invented for, but most times you don't write that kind of code."
Thank you - yes that's what I figured, and it probably isn't for me.  But I wanted to see if I was missing something.

" I like languages that avoid me most common bugs,"
I wonder what the most common bugs and traps are in D.  P0nce's D idioms allude to some of them, but that isn't the focus of what he writes.

"I think D should relax and keep improving its strengths (like C++ interoperability), fix some of its holes (safety, GC-less programming, fixing its contract-driven programming experience, etc), improve its medium-integrity coding, and keep going on as usual, slowly getting better. The Rust and D niches are sufficiently different, there's minimal overlapping in their purposes and niches."

Yes - I completely agree.  As Peter Thiel says, competition is for losers.  Much better to have a monopoly that you have earned (and have to keep earning).  I agree with Knuth that language reflects thought and people intrinsically think differently (this also being shaped by the domain) - he welcomed the prospect of an expansion in the number and kinds of language available.

It's funny how the most negative critics in this forum and who make diffuse statements about how D has lost the race often don't seem to contribute much code to making things better.  Contrast with Manu, for example, who whilst spirited is actually through actually using the language and reporting concrete difficulties is directly driving the completion of some features.

Walter - sorry about that.  I need to get someone to help on that front as I have so little time.  Should work now.


Laeeth

On Sunday, 31 January 2016 at 15:44:37 UTC, Laeeth Isharc wrote:
> Guillaume Piolat
> "- D is a large language, not sure how much relatively to Rust. I've heard Rust is complicated too."
> and yet, it's easy to get started if you know C.  one can be quite quickly productive without having any experience of template metaprogramming, CTFE, and the like, and gradually absorb language features as you go.  Phobos is pretty readable, on the whole.  I agree with bearophile about GC making it easier in the beginning.
>
> bearophile:
> "I am sometimes able to write working D code almost as quickly as Python code"
>
> Yes, indeed - that's my experience too.  I wonder what we could do to make this most of the time, if not almost always, and for less experienced programmers than you.  It wouldn't be surprising to find that the things that tend to get in the way fall in certain common categories.  Some people have applied machine learning to compilers to study this - that's probably beyond our resources for now, but the idea makes sense.  Adam's and others' work on error messages might be part of the answer.
>
> Thank you for the colour on OcaML.  What could be done to improve Algebraic and pattern matching?  The talk at the London dmeetup was quite interesting, but I had the sense that was fairly experimental at this stage.
>
> "There are several kinds of code that D allows you to write quite better than Rust (generic application code, script-like code, explorative scientific numerical code (like ndslice), medium-integrity code, metaprogramming, compile-time computations, template-level computations and specializations, higher order template magic, and so on. "
>
> Should we make more of a feature of this in the intro page.  Tutorials per category showing the value?  And should the Rosetta stone examples (many of which you wrote, as I understand it) be more prominently featured?  Maybe even in the code samples on the front page too.
>
> "In Ada you can be productive if you use it for the purposes it was invented for, but most times you don't write that kind of code."
> Thank you - yes that's what I figured, and it probably isn't for me.  But I wanted to see if I was missing something.
>
> " I like languages that avoid me most common bugs,"
> I wonder what the most common bugs and traps are in D.  P0nce's D idioms allude to some of them, but that isn't the focus of what he writes.
>
> "I think D should relax and keep improving its strengths (like C++ interoperability), fix some of its holes (safety, GC-less programming, fixing its contract-driven programming experience, etc), improve its medium-integrity coding, and keep going on as usual, slowly getting better. The Rust and D niches are sufficiently different, there's minimal overlapping in their purposes and niches."
>
> Yes - I completely agree.  As Peter Thiel says, competition is for losers.  Much better to have a monopoly that you have earned (and have to keep earning).  I agree with Knuth that language reflects thought and people intrinsically think differently (this also being shaped by the domain) - he welcomed the prospect of an expansion in the number and kinds of language available.
>
> It's funny how the most negative critics in this forum and who make diffuse statements about how D has lost the race often don't seem to contribute much code to making things better.  Contrast with Manu, for example, who whilst spirited is actually through actually using the language and reporting concrete difficulties is directly driving the completion of some features.
>
> Walter - sorry about that.  I need to get someone to help on that front as I have so little time.  Should work now.
>
>
> Laeeth

Guillaume Piolat:

>What could be done to improve Algebraic and pattern matching?<

The number of developers working on D compiler, D design and Phobos is limited, and D is a large language. So it's better to focus the developing work on fixing and finishing the unfinished parts of D, instead of adding new ways to do the same things.

And even if you want new D features, there are more important things to think about, like GC-less coding, C++ interoperability, async/await, and so on.


>I wonder what the most common bugs and traps are in D.<

You have to take care of the less common bugs too if you want a reliable language.

And currently it's dead-easy to write unsafe code even in @safe D functions:

int[] foo() pure @safe {
    int[2] a = [10, 20];
    auto b = a[];
    return b;
}
void main() {}

Now that Rust is showing some "intellectual" competition with C++, Stroustrup is even starting to think about adding some memory safety to C++ (but it's hard for this to become a complete memory safety for C++):
https://isocpp.org/blog/2015/09/bjarne-stroustrup-announces-cpp-core-guidelines

Regarding the code reliability, D is better than C++11, but it can be further improved, as Ada2012/SPARK show. On the other hand, a higher reliability has a cost, and sometimes you don't want to pay it. Every language has to find its balance between many different design goals and desires.

Bye,
bearophile

On Sunday, 31 January 2016 at 16:18:21 UTC, bearophile wrote:
> Regarding the code reliability, D is better than C++11

That's a bold claim. What do you mean by "code reliability"? You get as strong typing as you want with C++.

(And no, Laeeth, the fact that Manu has a nice boss that allows him to use an unfinished product in production is not a good reason for other people to do so. Try to be reasonable, just try...)

Thanks, bearophile.

On Sunday, 31 January 2016 at 16:30:47 UTC, Ola Fosheim Grøstad wrote:
> On Sunday, 31 January 2016 at 16:18:21 UTC, bearophile wrote:
>> Regarding the code reliability, D is better than C++11
>
> That's a bold claim. What do you mean by "code reliability"? You get as strong typing as you want with C++.
>
> (And no, Laeeth, the fact that Manu has a nice boss that allows him to use an unfinished product in production is not a good reason for other people to do so. Try to be reasonable, just try...)

He likely means that, in general, D code has fewer bugs than C++11 code. There are numerous reasons for this but I'll just give a few examples:

* Certain types of implicit casts are not allowed in D where the original value may be lost, e.g. int to short.
* Functions MUST return a value in D or at least throw an error.
* D has far less "undefined behavior" than C++.
* safe, pure, transitive const/immutable, thread-local by default, etc.

This and much more makes D far more "reliable" than C++.

On Sunday, 31 January 2016 at 18:32:12 UTC, Xinok wrote:
> He likely means that, in general, D code has fewer bugs than C++11 code.

Which is a questionable claim. If we are going to compare we have to compare performance vs proficiency vs risk of making mistake vs tooling vs X factors.

You certainly can write very high risk code in both C++ and D trying to get the highest possible performance.

> * Certain types of implicit casts are not allowed in D where the original value may be lost, e.g. int to short.

Except D has modular arithmetics for integers and a very heavy handed cast operator. In my own C++ code I use a cast function that asserts value ranges in debug builds. So no, I am not accepting this.

> * Functions MUST return a value in D or at least throw an error.

?

> * D has far less "undefined behavior" than C++.

And static analysis tooling that reports on some of it, but I have never actually experienced any problems related to "undefined behaviour" in my own code.

> * safe, pure, transitive const/immutable, thread-local by default, etc.

Thread local globals may or may not cause bugs. Depends on what you expect, but it is primarily a syntax issue.

Pure does not effect reliability.

Transitive const may offer some better reliability, except in the situations where you can't use it because you need head const. Which is what I usually need...

> This and much more makes D far more "reliable" than C++.

No, it does not make D anything in particular. It is just a claim.

Having a GC makes D more reliable, but we can make a similar list for D without GC vs C++, or C++ with a boehm collector and static analyzers vs D.

The problem is most C++ projects are not suitable for a GC. I only know of one FOSS project that use a GC with C++: Inkscape.

On Sun, 31 Jan 2016 15:44:37 +0000, Laeeth Isharc wrote:
> bearophile:
> "I am sometimes able to write working D code almost as quickly as Python
> code"
> 
> Yes, indeed - that's my experience too.  I wonder what we could do to make this most of the time, if not almost always, and for less experienced programmers than you.

Google's internal recommendations used to be: use Python when your project is going to stay small, use Java or C++ otherwise. Their recent recommendations are the same, but with the note that projects do not stay small.

I feel like D catches up in productivity (purely from a language and tools standpoint, not from a library standpoint) within the first hundred lines of code. The only things I use python for these days are its REPL (which is a pretty nice calculator) and pretty-printing JSON.

On Sunday, 31 January 2016 at 15:44:37 UTC, Laeeth Isharc wrote:
> Walter - sorry about that.  I need to get someone to help on that front as I have so little time.  Should work now.

Still happening, had three email replies returned this weekend.

On Sunday, 31 January 2016 at 16:18:21 UTC, bearophile wrote:
> And currently it's dead-easy to write unsafe code even in @safe D functions:
>
> int[] foo() pure @safe {
>     int[2] a = [10, 20];
>     auto b = a[];
>     return b;
> }
> void main() {}

Doesn't http://wiki.dlang.org/DIP25 fix this ?