On Monday, 27 August 2018 at 19:51:52 UTC, 12345swordy wrote:
> On Monday, 27 August 2018 at 18:20:04 UTC, Chris wrote:
>> Then the D Foundation should work on it.
> Easier said then done. You can't go around demanding people to build factories without addressing the issues that comes with building factories, such as the big question of how is it going to be payed to be built.
>
> -Alex

No one is (and no one should be) demanding anything, hoping maybe..

Walter, wants to build D, and he is doing what he can to continue building it
Andrei and many others joined him

If we are sharing our opinion, its not coming from any sense of entitlement, we are sharing our opinion, because the builders, provided the platform for us to voice our opinion

And again, because I keep repeating this, if they want more donations, I think talking more about the future plans will help, D currently neither have a larger user base, or an ambitious future plan, it make sense that they are not getting a lot of donations, they are not really making it attractive to donate

I think that most current donors are probably incentivized by negative factors, or negatively motivated, they are probably afraid D's Development will stop or they feel guilty for using the language and not providing much back

I dont think many donors are doing so because they are excited about the future

Nothing seriously wrong about negative motivation, it works, but positive motivation is better

On Monday, 27 August 2018 at 18:20:04 UTC, Chris wrote:
> Then the D Foundation should work on it. Get companies on board etc. All I hear is "we don't have enough money, we depend on the good will of our community members..." Then leave it. There's no way D can compete with languages that are backed by companies and that have additional benefits like targeting Android, iOS and the Web, e.g. Kotlin.

My question becomes, how is it possible that D supposedly only has a income of 3.2K ( opencollective ).

hen i look at Crystal, they have 2.5k ( bountysource ) and another 2k from a single company. By that definition, Crystal what is at a 0.26 release, is out funding D by 50%...

Julia on the other hand raises $4.6 million in funding in 2017...

On Monday, 27 August 2018 at 21:34:53 UTC, RhyS wrote:
> My question becomes, how is it possible that D supposedly only has a income of 3.2K ( opencollective ).

Well, one could aquire grants from Mozila through MOSS or The Linux Foundation for development. One could market D as the very next javascript through LLVM and WebAssembly, for which its actually really really good. Or, one could go with a few benchmarks of productivity, code quality and operation cost to one of the big companies with a lot of custom software running on cloudservers. Being able to say that your solution can approach C/C++ speeds while having java like development speeds and in general a better maintainability than java is a huge plus for them. They might want to invest in D so that they might have a better tool in one or two years, plus dedication from the community.

Granted, its not as simple as that. Goals need to be set, and the roadmap must become clear. And Andrei and Walter need to say yes or no to a plan from which they won't know if it'll neccesarily work out. But for exactly this, a manager for D would be perfect. Because the power of D is that the language must become better, even if that results in postphoning desparately wanted features. (Preffarably not)

On Saturday, August 25, 2018 2:16:16 PM MDT Walter Bright via Digitalmars-d wrote:
> On 8/25/2018 7:37 AM, Jonathan M Davis wrote:
> > In general, any place where D was
> > designed around the idea that something would _always_ be there (e.g.
> > init values and default initialization) but we've then later added the
> > ability to get around it (e.g. void initialization or @disable) has
> > tended to not play well with everything else and has caused some fun
> > problems.
>
> It's why that stuff isn't allowed in @safe code, and hence one should realize one is taking responsibility from the compiler for ensuring the correctness. D expects someone writing @system code to have a much greater awareness of how the language and the machine works.
>
> If you remove the blade guards from the table saw, more things can be done with it, but you'll need to take much greater care using it.

Definitely, but some of the features don't play well together even with @system - e.g. if you have a struct with an invariant, you can't use void initialization, because the invariant will be checked when you assign the struct an actual value later. I was forced to remove the invariant that SysTime had years ago, because of issues related to that, and I've basically given up on using invariants in structs as a result. If I'm in full control of all of the code, it's not a problem, but as soon as I'm providing library code to someone eles, struct invariants become land mines.

And just in general, it becomes pretty problematic to try to skip or disable something that the lanugage was built around (e.g. default initialization) - though fortunately, it usually interacts better than invariants tend to do when you do something like void initialization.

- Jonathan M Davis

On 8/27/2018 10:08 AM, H. S. Teoh wrote:
> Const in D makes sense as-is.  Though, granted, its infectiousness means
> its scope is actually very narrow, and as a result, we ironically can't
> use it in very many places, and so its touted benefits only rarely
> apply. :-(  Which also means that it's taking up a lot of language
> design real estate with not many benefits to show for it.

D const is of great utility if you're interested in functional programming. Using it has forced me to rethink how I separate tasks into functions, and the result is for the better.

I agree that D const has little utility if you try to program in C++ style.

On Tuesday, 28 August 2018 at 01:11:14 UTC, Walter Bright wrote:
> On 8/27/2018 10:08 AM, H. S. Teoh wrote:
>> Const in D makes sense as-is.  Though, granted, its infectiousness means
>> its scope is actually very narrow, and as a result, we ironically can't
>> use it in very many places, and so its touted benefits only rarely
>> apply. :-(  Which also means that it's taking up a lot of language
>> design real estate with not many benefits to show for it.
>
> D const is of great utility if you're interested in functional programming. Using it has forced me to rethink how I separate tasks into functions, and the result is for the better.
>
> I agree that D const has little utility if you try to program in C++ style.

It doesn't play well with templates or any of the like either, so even if you try to do template programming it is just better to not use it.

I'm curious as to what an example of this D const for functional programming would look like.

On 8/27/2018 2:14 AM, Chris wrote:
> On Sunday, 26 August 2018 at 22:44:05 UTC, Walter Bright wrote:
>> Because nobody thought about that issue before. A lot of things only become apparent in hindsight.
> QED. With this approach you do more harm than good. I have a bad feeling about the way things are going atm.

I can quote you a loooong list of problems that are obvious only in hindsight, by world leading development teams.

Start by watching the documentary series "Aviation Disasters", look at Challenger, Deepwater Horizon, Fukushima, Apollo 1, Apollo 13, the World Trade Centers, etc. Of course, there are a number of them in C, C++, Java, Javascript, basically every language I've worked with.

I'll guarantee every non-trivial project you've worked on has problems that are obvious only in hindsight, too. If you wait till it's perfect, you'll never ship, and yet it'll *still* have problems.

I'm not making excuses for mistakes - just don't have unworkable requirements.

The end of the day is, does D get the job done for you better than other languages? That's a decision only you can make.

On 8/26/2018 11:16 PM, Manu wrote:
>> The code looks the same, and in fact, is about 98% the same.
> This code appears to be a mechanical translation.

It's not. It's by hand. But I had a specific goal of minimizing the diffs, so that if the translation didn't work, it reduced the number of places to look for the mistake. And in fact, this has saved me a LOT of grief :-)


> That's not what
> happened in this case; he wrote his game in D from scratch.
> It was just that he arrived at mostly the same place. He was googling
> for styling and sample material, but I suspect the problem was a lack
> of topical material demonstrating how he might write his D code
> differently.

It takes time to learn how to write idiomatic D effectively. I'm still learning how to do it right, too.


> It's also the case that the significant difference between C++ and D
> (in my experience) mostly come down to: D has modules, tidier meta,
> UDA's, slices, and ranges/UFCS. In trade, D struggles with const, and
> ref is broken.
> If your code doesn't manifest some gravity towards one of those
> features, it will tend to be quite same-ey, and advantage may not be
> particularly apparent.

I suspect that is still a bit stuck on looking at individual instruments and not seeing the orchestra.

Let's take the much-maligned D const. It isn't C++ const (let's call that "head-const", because that's what it is). Head-const for a function parameter tells us very little about what may happen to it in the function. You can pass a head-const reference to a container, and have the function add/change/delete every element of that container, all without a peep from any C++ tool. Looking at the function signature, you've really got no clue whatsoever.

The reason people have trouble with transitive-const is that they are still programming in C++, where they *do* add/change/delete every member of the "const" container.

That includes me. I try to add transitive-const, and it won't compile, because I as well am used to replacing the engine and tail lights in my head-const car. In order to use transitive-const, it's forcing me to fundamentally re-think how I organize code into functions.

For example, dmd is full of functions that combine data-gathering with taking-action. I've been reorganizing to separate data-gathering and taking-action into separate functions. The former can be transitive-const, maybe even pure. And I like the results, the code becomes much easier to understand.

On Tuesday, 28 August 2018 at 07:53:34 UTC, Walter Bright wrote:
> Let's take the much-maligned D const. It isn't C++ const (let's call that "head-const", because that's what it is). Head-const for a function parameter tells us very little about what may happen to it in the function. You can pass a head-const reference to a container, and have the function add/change/delete every element of that container, all without a peep from any C++ tool. Looking at the function signature, you've really got no clue whatsoever.
>
> The reason people have trouble with transitive-const is that they are still programming in C++, where they *do* add/change/delete every member of the "const" container.
>
> That includes me. I try to add transitive-const, and it won't compile, because I as well am used to replacing the engine and tail lights in my head-const car. In order to use transitive-const, it's forcing me to fundamentally re-think how I organize code into functions.
>
> For example, dmd is full of functions that combine data-gathering with taking-action. I've been reorganizing to separate data-gathering and taking-action into separate functions. The former can be transitive-const, maybe even pure. And I like the results, the code becomes much easier to understand.

There are still valid use cases where const should be "broken". One of them is mutex (another one caching). I have very little experiance in multi-threaded programming, but what do you think about "mutable" members, despite the object is const?

On Tuesday, 28 August 2018 at 07:30:01 UTC, Walter Bright wrote:
> On 8/27/2018 2:14 AM, Chris wrote:

>> bad feeling about the way things are going atm.
>
> I can quote you a loooong list of problems that are obvious only in hindsight, by world leading development teams.
>
> Start by watching the documentary series "Aviation Disasters", look at Challenger, Deepwater Horizon, Fukushima, Apollo 1, Apollo 13, the World Trade Centers, etc. Of course, there are a number of them in C, C++, Java, Javascript, basically every language I've worked with.
>
> I'll guarantee every non-trivial project you've worked on has problems that are obvious only in hindsight, too. If you wait till it's perfect, you'll never ship, and yet it'll *still* have problems.
>
> I'm not making excuses for mistakes - just don't have unworkable requirements.

This is all good and well and I know that anyone who develops software shoots him/herself in the foot sooner or later. But this is not the same situation. If you have to ship something till date X, then you are under pressure and naturally make mistakes that are obvious only on hindsight. But D is not under pressure to  include new features so frequently. There's absolutely no reason to rush into something that eats up a lot of your time (better spent on more urgent problems) and by so doing produce possible breakages.

> The end of the day is, does D get the job done for you better than other languages? That's a decision only you can make.

It has done a better job until recently. The problem are not things like @safe, `const` and whatnot, the problem are very practical issues such as fear of breakage / time spent fixing things and running the code on ARM, integration into other technologies (webasm).

Since the D Foundation was founded I really thought that part of the effort would go into stabilizing the language and developing better tools for various aspects of programming (not just language features). Programming is so much more than just language features, and languages that offer the "so much more" part are usually the ones people adopt. But somehow D still seems to be in its hobby hacker days. Features are first and foremost, everything else comes second. But features get "ripped" by other programming languages and they can pick and choose, because they know what really worked in D, while D has to struggle with the things that didn't work or only half worked.

Laeeth was talking about being analytical about the whole thing. Why not find out what features are really being used? I.e. does the majority really need - for practical purposes - partially constructed objects?

When people choose a programming language, there are several boxes that have to be ticked, like for example:

- what's the future of language X? (guarantees, stability)
- how easy is it to get going (from "Hello world" to a complete tool chain)
- will it run on ARM?
- will it be a good choice for the Web (e.g. webasm)?
- how good is it at data processing / number grinding
- etc.

I think the D Foundation should focus on the more "trivial" things too. If a company is asked to develop a data grinding web application along with a smart phone app - will it choose D? If a company offers localization services and translations - will it choose D (autodecode)?

The D community / leadership is acting as if they had all the time in the world. But other languages are moving fast and they learn from D what _not_ to do.

Last but not least, if it's true that the D Foundation has raised only 3.2K, then there's something seriously wrong.