On Thursday, 28 December 2017 at 02:21:09 UTC, Dan Partelly wrote:
> On Thursday, 28 December 2017 at 01:09:34 UTC, codephantom wrote:
>>
>> But honestly, the best way to learn about a programming language, is to start using it.
>
> Sure ,  **if** you decide it worth to be learned. And honestly, almost everybody knows that to get better at a task you must perform the task itself.
>
>>
>> So I ask you...what have you written in D lately?
>
> 
> My problem currently is that I have no freaking idea what niche D serves, since as I said I perceive multiple personalities in it. I like a lot in the language, but I do not like that I perceive it as a indecisive language.
>
> This is one of the reasons I asked Walter in this thread what is the future of the language ?
> Where does it to go ? No clear answer yet.

It's a practical language for getting stuff done in a way thats plastic, efficient, powerful.

So I think the ecological niche is restricted mostly by capabilities of the people using it (it wasn't designed as golang was as a restricted and simple language for people who have limited experience, though I personally found it easy enough to learn), by the tolerance people have for discomfort upfront, by the ability to pay upfront costs in wrapping any necessary libraries, by the ability to pick your own tools rather than needing to persuade others first.  It's not as polished as more mature languages. It has fewer targets, so for example it doesn't yet have a production ready ARM 64 or web assembly target, and if you run it on Alpine Linux, FreeBSD or SmartOS it will probably work but you might have some work to do yourself. Embedded targets will need you to do work. If it's super important not to use the GC probably you will have some work to do.  If you work with younger people who expect Python style docs and an abundance of Stack Overflow answers you may have some work to do there.

Beyond that, it's pretty good for many things,from scripting to applications to numerical code, to systems programming.  That's really the point.

It's also especially good as glue because of ctfe and compile time reflection.  Pegged and other parser generators mean that it's a pretty nice language for writing DSLs in.

On Wednesday, 27 December 2017 at 10:08:37 UTC, Walter Bright wrote:
> On 12/27/2017 12:59 AM, Dan Partelly wrote:
>> All could have been prevented by going the C++ route of 0 cost abstraction,
> C++ is not 0 cost abstraction, despite the marketing. It's why C++ compilers have switches to disable things like EH and RTTI.

Hi Walter, Can you take a look at this betterC bug:  https://issues.dlang.org/show_bug.cgi?id=18099

==========
        struct D()
        {
                struct V {
                        ~this() {
                        }
                }
                auto get() {
                        V v ;
                        return v ;
                }
        }
        alias T = D!();
============
Error: Cannot use throw statements with -betterC
a.d(12): Error: template instance a.D!() error instantiating


It is a block for implement auto RefCount in betterC.  Since there is no GC,  auto RefCount is the way to make D work far more useable then pure C, and it relay on this bug to be fixed.

On Thursday, 28 December 2017 at 03:31:19 UTC, ChangLong wrote:
> On Wednesday, 27 December 2017 at 10:08:37 UTC, Walter Bright wrote:
>> On 12/27/2017 12:59 AM, Dan Partelly wrote:
>>> All could have been prevented by going the C++ route of 0 cost abstraction,
>> C++ is not 0 cost abstraction, despite the marketing. It's why C++ compilers have switches to disable things like EH and RTTI.
>
> Hi Walter, Can you take a look at this betterC bug:  https://issues.dlang.org/show_bug.cgi?id=18099
>
> ==========
>         struct D()
>         {
>                 struct V {
>                         ~this() {
>                         }
>                 }
>                 auto get() {
>                         V v ;
>                         return v ;
>                 }
>         }
>         alias T = D!();
> ============
> Error: Cannot use throw statements with -betterC
> a.d(12): Error: template instance a.D!() error instantiating
>
>
> It is a block for implement auto RefCount in betterC.  Since there is no GC,  auto RefCount is the way to make D work far more useable then pure C, and it relay on this bug to be fixed.

With BetterC and Auto RefCount,  Simple template can simulation Rust Box, Arc behavior.

I has try made a BetterC lib to work with libuv,  Fiber(implement by struct),  Thread local storage(use libuv api with Thread in struct).     There is noGc and Boxed data auto release by auto RefCount.


BetterC made D generate extreme fast and small binary execute code.  And the powerful template can easy simulation Rust Box and Go Channel.

If I add a D version to made the code at single thread mode,  the speed is even more fast since the Channel lock and Tls is removed without change code.

With D version Box template,  Boxed struct resource are allocate in a pool, and auto release into pool after the refCount to zero.  It make the code look like normal D Code without betterC,  and get the noGC benefit.

The defect is I can not use Class and Exception, It has be done with a custom  object.d.

On Wednesday, 27 December 2017 at 13:37:17 UTC, Adam D. Ruppe wrote:
> On Wednesday, 27 December 2017 at 10:10:03 UTC, Pawn wrote:
>> It's been expressed that there are now too many codebases such that introducing "breaking changes" would upset many people and companies. D is a mature language, not a young one.
>
> Just make it opt in at the module level and have the opposite attributes added. I suggest:
>
> @strict module foo;
>
>
> And that little @strict (or whatever name) thing indicates you want newer stuff for the entire module.
>
> No breakage, no community split, very little hassle. Javascript has had a fair amount of success with opt in stuff like this.

Well, to advance the language, I think we need to start breaking some egss, but, we also need a magic wand.

Scott Meyers makes the case well, for C++.

http://scottmeyers.blogspot.com.au/2015/11/breaking-all-eggs-in-c.html

Someone needs to make the case for D too.

On Thu, 2017-12-28 at 01:09 +0000, codephantom via Digitalmars-d wrote:
> 
[…]
> Well, you're doing what most people do, when they hear about a new programming language - i.e. start comparing it to others.... there is a psychological basis for that phenomena - it's human.
[…]

And is the way every programmer learns their non-first language. All newly learned programming languages are merged into a person's "head language" which is based on their first language but then evolves as new languages, especially of new computational mode, are learned.

See Marian Petre and others work over the last 30 years for scientific evidence of this.

-- 
Russel.
==========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Thursday, 28 December 2017 at 11:56:24 UTC, Russel Winder wrote:
> And is the way every programmer learns their non-first language. All newly learned programming languages are merged into a person's "head language" which is based on their first language but then evolves as new languages, especially of new computational mode, are learned.

One of the reasons I asked Walter to provide an insight into what he wants D to become, why betterC, GC or lack-thereof dilemma , and future evolution is to minimize a bit the biases I have.

What I learned the most in the last days is what other people than the creator of D think of D (valuable too), and that is hard to get a straight answer from the people developing D language on my predicament with seeing it with multiple personalities.

Also, no matter hope great D is, I practically live in a D-less void. No one cares about it around me and no one I know cares to learn it. This is another social aspect. As I learn it
and learn how the creator sees the language I could try to change this in my immediate surrounding if it worth. It would be up to me once I am convinced to seduce people I work with to consider it and learning it.

On Thursday, 28 December 2017 at 11:56:24 UTC, Russel Winder wrote:
> And is the way every programmer learns their non-first language. All newly learned programming languages are merged into a person's "head language" which is based on their first language but then evolves as new languages, especially of new computational mode, are learned.
>
> See Marian Petre and others work over the last 30 years for scientific evidence of this.

Hm…  I have some problem with this.  I can see how it would apply to Algol-like languages, but for I don't see how it fits on very different concepts like SQL/datalog/prolog, scheme, machine language, OO etc…

There might be some empirical issues here as _most_ programmers would move to something similar, but statistical significance doesn't imply causality…

On 12/27/17 00:10, Pawn wrote:
> On Wednesday, 27 December 2017 at 09:39:22 UTC, codephantom wrote:
>> IMHO..What will help the cause, in terms of keeping D as a 'modern'
>> programming language, is the willingness of its designers and its
>> community to make and embrace 'breaking changes' ... for example,
>> making @safe the default, instead of @system.
> It's been expressed that there are now too many codebases such that
> introducing "breaking changes" would upset many people and companies. D
> is a mature language, not a young one.
>

This is not true. I was at DConf one year (can't remember which) and I watched the representative of one of D's larger corporate users do everything but actually get on his knees and beg Walter to make a breaking change. IIRC they demonstrated their work around for the missing change a couple of DConf's later.

The reason that D isn't making breaking changes is that the language has enough broken stuff as it is. It does not make much sense to fork a code-base with significant known issues, break more things without fixing the existing things, and then release as a new version. It would create even more bugs and perpetuate the 'D is broken' meme. Once D2 has been thoroughly vetted and is free of known-bugs (sometimes called Zero Bug Bounce, there may be unknown bugs that are discovered, but all known bugs are fixed). Additionally, consider that if we have a stable base in D2 it will be much easier to merge bug-fixes into D3 while D3 is being worked on.

Let's fix the crap we have now. It'll take a while, it's not sexy, and it certainly won't make headlines on HN or Reddit. But it will have the effect of combating the biggest negative that D has to adoption. The perception of instability.

-- 
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;

On Thursday, 28 December 2017 at 03:31:19 UTC, ChangLong wrote:
> Hi Walter, Can you take a look at this betterC bug:  https://issues.dlang.org/show_bug.cgi?id=18099
>
> ==========
>         struct D()
>         {
>                 struct V {
>                         ~this() {
>                         }
>                 }
>                 auto get() {
>                         V v ;
>                         return v ;
>                 }
>         }
>         alias T = D!();
> ============
> Error: Cannot use throw statements with -betterC
> a.d(12): Error: template instance a.D!() error instantiating
>
>
> It is a block for implement auto RefCount in betterC.  Since there is no GC,  auto RefCount is the way to make D work far more useable then pure C, and it relay on this bug to be fixed.

I can hear him already, "Post it on buzzkill or it won't get fixed!"

On Saturday, 30 December 2017 at 23:04:21 UTC, Nicholas Wilson wrote:
> I can hear him already, "Post it on buzzkill or it won't get fixed!"

Stupid autocorrect. Bugzilla.