On Tuesday, 4 September 2018 at 13:34:03 UTC, TheSixMillionDollarMan wrote:
> I think D's 'core' problem, is that it's trying to compete with, what are now, widely used, powerful, and well supported languages, with sophisticate ecosystems in place already. C/C++/Java/C# .. just for beginners.

Yes, I believe there was an academic early on that allowed students to use D, but when C++17 (etc) came about he held the view that it would be better for D to align its semantics with C++. He was met with silence, except me, who supported that view. D is too much like C++ for a skilled modern C++ programmer to switch over, but D semantics are also too different to compile to C++ in a useful manner.

> Then it's also trying to compete with startup languages (Go, Rust ....) - and some of those languages have billion dollar organisations behind them, not to mention the talent levels of their *many* designers and contributors.

Ok, so my take on this is that Rust is in the same group as D right now,  and I consider it experimental as I am not convinced that it is sufficient for effective low level programming. Although Rust has more momentum, it depends too much on a single entity (with unclear profitability) despite being open sourced, just like D. Too much singular ownership. Go is also open source in theory, but if we put legalities aside then I think it is having the traits of a proprietary language. They are building up a solid runtime, and it has massive momentum within services, but the language itself is somewhat primitive and messy. Go could be a decent compilation target for a high level language.

That said , I think most languages don't compete directly with other languages, but compete within specific niches.

Rust: for writing services and command line programs where C++ would have been a natural candidate, but for people who want a higher level language or dislike C++.

Go: for writing web-services where Python, Java  and C# is expected to be too resource-intensive.

D: based on what seems to be recurring themes in the forums D seems to be  used by independent programmers (personal taste?) and programmers in finance that find interpreted languages too slow and aren't willing to adopt C++.

> C++ is much more than just a langauge. It's an established, international treaty on what the language must be.

Yes, it is an ISO-standard, and evolve using a global standardisation community as input. As such it evolves with the feedback from a wide range of user groups by the nature of the process.

> That is not a statement about the quality of D. It's a statement about the competitive nature of programming languages.

It kinda is both, but the issue is really what you aim to be supporting and what you do to move in that direction.

When there is no focus on any particular use case, just language features, then it becomes very difficult to move and difficult to engage people in a way that make them pull in the same direction.

> I wonder has already happened to D.

No, it mostly comes down to a lack of focus and a process to back it up. Also, memory management should be the first feature to nail down, should come before language semantics...

> I just do not see, how D can even defeat its' major competitors.

But are they really competitors? Is D predominantly used for writing web-services? What is D primarily used for? Fast scripting-style programming?

> Instead D could be a place where those competitors come to look for great ideas (which, as I understand it, does occur .. ranges for example).

No, there are thousands of such languages. Each university has a handful of languages that they create in order to back their comp.sci. research.

No need to focus on performance in that setting.

> You seem to be saying that, raising money so you can pay people, is enough.
>
> But I wonder about that.

There has to be a focus based on analysis of where you can be a lot better for a specific use scenario, define the core goals that will enable something valuable for that scenario, then cut back on secondary ambitions and set up a process to achieve those core goals (pertaining to a concrete usage scenario).

Being everything for everybody isn't really a strategy. Unless you are Amazon, and not even then.

Without defining a core usage scenario you cannot really evaluate the situation or the process that has to be set up to change the situation...

Well, I've said this stuff many times before.

On 29.08.2018 22:01, Walter Bright wrote:
> On 8/29/2018 10:50 AM, Timon Gehr wrote:
>> D const/immutable is stronger than immutability in Haskell (which is usually _lazy_).
> 
> I know Haskell is lazy, but don't see the connection with a weaker immutability guarantee.

In D, you can't have a lazy value within an immutable data structure (__mutable will fix this).

> In any case, isn't immutability a precept of FP?

Yes, but it's at a higher level of abstraction. The important property of a (lazy) functional programming language is that a language term can be deterministically assigned a value for each concrete instance of an environment in which it is well-typed (i.e., values for all free variables of the term). Furthermore, the language semantics can be given as a rewrite system such that each rewrite performed by the system preserves the semantics of the rewritten term. I.e., terms change, but their values are preserved (immutable). [1]

To get this property, it is crucially important the functional programming system does not leak reference identities of the underlying value representations. This is sometimes called referential transparency. Immutability is a means to this end. (If references allow mutation, you can detect reference equality by modifying the underlying object through one reference and observing that the data accessed through some other reference changes accordingly.)

Under the hood, functional programming systems simulate term rewriting in some way, ultimately using mutable data structures. Similarly, in D, the garbage collector is allowed to change data that has been previously typed as immutable, and it can type-cast data that has been previously typed as mutable to immutable. However, it is impossible to write a GC or Haskell-like programs in D with pure functions operating on immutable data, because of constraints the language puts on user code that druntime is not subject to.

Therefore, D immutable/pure are both too strong and too weak: they prevent @system code from implementing value representations that internally use mutation (therefore D cannot implement its own runtime system, or alternatives to it), and it does not prevent pure @safe code from leaking reference identities of immutable value representations:

pure @safe naughty(immutable(int[]) xs){
    return cast(long)xs.ptr;
}

(In fact, it is equally bad that @safe weakly pure code can depend on the address of mutable data.)



[1] E.g.:

(λa b. a + b) 2 3

and

10 `div` 2

are two terms whose semantics are given as the mathematical value 5.

During evaluation, terms change:

(λa b. a + b) 2 3 ⇝ 2 + 3 ⇝ 5
10 `div` 2 ⇝ 5

However, each intermediate term still represents the same value.

On Tuesday, September 4, 2018 5:56:54 AM MDT ShadoLight via Digitalmars-d wrote:
> We work full-time for employers which, in my case, employs thousands of engineers - and as a result engineering principles are applied to everything - including tools. So all SW dev teams here use standardized tooling/processes/coding standards/etc. - you simply do not have a choice to use your own editor of choice.

[snip]

> I really miss the appreciation of this fact in these incessant 'use Vim/Emacs' answers to people's queries on IDE support is the forum. This is not the reality for many people at work - this article [1] describes the reason why businesses prefer IDE's quite nicely.
>
> Most of my colleagues are not interested in hobby coding at home - they consider their family life separate to their professional lives - and that is perfectly OK. It is their choice. But it makes it impossible for people like me to even try to push their managers to "try D" if it does not fit into the workflow/processes that are already followed. For me (like for Manu [2]) this absolutely necessitates that it supports Visual Studio integration _out_of_the_box_!
>
> When I read answers like yours and Jonathan's it always makes me wonder: does D want to cater for the kind of businesses I describe as well? If not, ok - that is a perfectly valid answer and D can, as a consequence remain the slightly obscure language it has been up to now - used by enthusiasts that are willing to go the extra mile to get stuff done, and can hack around any limitation. That is perfectly fine.

[snip]

> I know the "we use Vim/Emacs, why don't you pitch in and help on VisualD if you want to use it" view is valid opinion, but it will not bring the masses since it will never happen - the critical mass is composed of devs that want to _use_ VS/eclipse/etc - not _develop_ to enable them. Besides, they are not coding at home, and there is very little incentive for said enterprises to assist with this - they see it simply as a cost if D does not offer sufficient benefit over C#/java/etc. So this is not going to happen except as an effort inside the D community itself.

Honestly, I don't understand why it would make any sense to require that all of the programmers use a particular code editor. Standardizing the build tools makes perfect sense (in fact, it would be crazy not to), and I've certainly worked at places that have required that a specific tool like visual studio or eclipse be used, because it's used for building, but they've never then disallowed using a tool like vim or emacs for code editing. And if an employer did, I'd almost certainly be looking for a new job (though finding a job that sucks less than your current one is frequently far from easy).

I completely disagree that IDEs are a better tool (at least as long as you're willing to put in the time to actually learn a tool like vim or emacs), but I'm not against someone using an IDE if they want to. And even if I think that it's stupid for a company to say that you must use editor X or IDE Y (regardless of what that program may be), I do think that folks should choose whatever code editor / IDE works best for them. If a whole bunch of folks want to use VisualD, then great, more power to them. I certainly don't agree with their choice, but they're the ones writing their code, not me. I'm not looking to force vim or emacs on anyone any more than I want to be forced to write code in Visual Studio. And much as I think that IDEs are generally inferior, given how many folks insist on using them, I do think that it's good for D to have good IDE support, even if I don't want to ever use it.

That being said, I'm not about to spend my time working on IDE support. While I want D to succeed, I don't spend my time on D doing things geared towards getting more people to use D. I spend my time on things that make D better as a language or which improve its libraries. That should then make it more desirable for folks to use D, and in some cases, it does get rid of obstacles that prevent folks from using D. So, I expect that that will help increase D's user base, but my entire focus is on making D better, not on trying to pave the way for others to use it - especially if it's an issue like you describe where an employer is really picky about the tools that programmers use simply to edit code. I honestly wouldn't expect a company like that to be interested in D anyway. So, I'm definitely not going to spend my free time on things aimed at making them happy, much as I sympathize with your situation. Personally, I'm only able to work in D now, because I work as a contractor. It was a lost cause to get D into any of my previous work places. They just weren't the kind of places where that was going to fly, regardless of the current state of D. Most companies and most programmers are not looking for a better programming language to use, and the reasons that they pick a particular language often has little to do with how good a language is.

But ultimately, regardless of the reasons why someone might want to use an IDE, if the current state of IDEs for D is not where it needs to be for them to use D with an IDE, and the amount of effort currently being put into improving IDEs for D is not going to get those IDEs to that point soon, then someone who actually cares about the issue is going to need to either pitch in or donate so that someone else can be paid to work on it; otherwise IDE support isn't going to improve enough. Regardless of the perceived value in IDE support, there are just too many other things that need doing for most of us to want to put our free time into working on an issue that isn't going to benefit us.

And while a number of us do do at least some work on D-related stuff that we don't care about aside from wanting to improve the D ecosystem for others, when the vast majority of the time being put in is on a volunteer basis, the reality of the matter is that most of the effort is going to go towards things that those contributing care about and not what the community at large might care about or what folks who may join the community might care about. That's just how it goes with open source and is part of why it can be critical for individuals or companies to donate money towards improving aspects of a project that no one wants to work on. And that's part of why it can be a big deal for there to be a big company backing a project. While it can be frustrating for someone to be told that they need to either pitch in or donate to get something that they want done, if it's something that isn't a priority for those who are spending their free time to do the work, it's often the cold the reality that that thing isn't going to get done any time soon.

- Jonathan M Davis

On Tue, Sep 04, 2018 at 02:00:37PM -0600, Jonathan M Davis via Digitalmars-d wrote: [...]
> And while a number of us do do at least some work on D-related stuff that we don't care about aside from wanting to improve the D ecosystem for others, when the vast majority of the time being put in is on a volunteer basis, the reality of the matter is that most of the effort is going to go towards things that those contributing care about and not what the community at large might care about or what folks who may join the community might care about.
[...]
> While it can be frustrating for someone to be told that they need to either pitch in or donate to get something that they want done, if it's something that isn't a priority for those who are spending their free time to do the work, it's often the cold the reality that that thing isn't going to get done any time soon.
[...]

Yes, that's just the cold hard reality.  Demanding for something in the forums rarely has the desired effect of making that thing happen.  In fact, it may have the opposite effect of turning off would-be volunteers because they get tired of hearing said demands and decide to just ignore it. Similarly, getting mad at the current state of things, while it may be a good way to vent one's frustrations, rarely results in any actual change in the status quo.

Realistically speaking, there are really only two ways to make a change happen:

(1) Do it yourself, then (optionally) contribute the code to the
community so that everyone else can reap the benefits; or

(2) Convince someone to do it for you -- which usually means pay them to do the work, which can be hiring someone yourself to do it, or donating to the D Foundation so that they can pay someone to do it.  Demanding volunteers to do something they aren't really interested in rarely has the desired effect.

One could argue that this state of things sucks, and I might even agree. But that still won't change anything.  Like it or not, nothing is going to happen until either (1) or (2) happens.  Things aren't going to materialize out of thin air just because people demand for it loudly enough, even if we'd like for that to happen.  *Somebody* has to do the work. That's just how the universe works.


T

-- 
Those who've learned LaTeX swear by it. Those who are learning LaTeX swear at it. -- Pete Bleackley

On Tuesday, September 4, 2018 2:45:53 PM MDT H. S. Teoh via Digitalmars-d wrote:
> Those who've learned LaTeX swear by it. Those who are learning LaTeX swear at it. -- Pete Bleackley

Well, that's a weirdly appropriate quote. The primary reason that I've done as much with latex as I have is so that I can use vim to write documents instead of having to use a word processor.

- Jonathan M Davis

On Tuesday, 4 September 2018 at 20:45:53 UTC, H. S. Teoh wrote:
> happens.  Things aren't going to materialize out of thin air just because people demand for it loudly enough, even if we'd like for that to happen.  *Somebody* has to do the work. That's just how the universe works.

Human beings are social in nature and follow a group-mentality, so when there are people willing to follow and you have a persuasive leader willing to lead and outline a bright and vivid future, then things can "materialize" out of thin air.

But it is not going to happen without focused leadership and the right timing.

There certainly have been people in the forums over the years looking for things to do.  So I really don't believe the whole "nothing will happen because nothing happens by itself" mantra.

What is almost always the case is that if you base an open source sub-project on only 1-2 people then that work is mostly wasted, as they most likely will leave it unmaintained. So leadership is critical, even when things do "materialize" out of thin air.

On 9/1/2018 4:12 AM, Chris wrote:
> Hope is usually the last thing to die. But one has to be wise enough to see that sometimes there is nothing one can do. As things are now, for me personally D is no longer an option, because of simple basic things, like autodecode, a flaw that will be there forever, poor support for industry technologies (Android, iOS) and the constant "threat" of code breakage. The D language developers don't seem to understand the importance of these trivial matters. I'm not just opinionating, by now I have no other _choice_ but to look for alternatives - and I do feel a little bit sad.

Autodecode - I've suffered under that, too. The solution was fairly simple. Append .byCodeUnit to strings that would otherwise autodecode. Annoying, but hardly a showstopper.

Android, iOS - Contribute to help make it better.

Breakage - I've dealt with this, too. The language changes have been usually just some minor edits. The more serious problems were the removal of some Phobos packages. I dealt with this by creating the undeaD library:

https://github.com/dlang/undeaD

On 9/4/2018 12:59 PM, Timon Gehr wrote:
>  [...]

Thanks for the great explanation! Not sure I thoroughly understand it, though.

> Therefore, D immutable/pure are both too strong and too weak: they prevent @system code from implementing value representations that internally use mutation (therefore D cannot implement its own runtime system, or alternatives to it), and it does not prevent pure @safe code from leaking reference identities of immutable value representations:
> 
> pure @safe naughty(immutable(int[]) xs){
>      return cast(long)xs.ptr;
> }
> 
> (In fact, it is equally bad that @safe weakly pure code can depend on the address of mutable data.)

Would it make sense to disallow such casts in pure code?

What other adjustments would you suggest?

https://issues.dlang.org/show_bug.cgi?id=19221

On Tuesday, 4 September 2018 at 21:36:16 UTC, Walter Bright wrote:
> On 9/1/2018 4:12 AM, Chris wrote:
>> Hope is usually the last thing to die. But one has to be wise enough to see that sometimes there is nothing one can do. As things are now, for me personally D is no longer an option, because of simple basic things, like autodecode, a flaw that will be there forever, poor support for industry technologies (Android, iOS) and the constant "threat" of code breakage. The D language developers don't seem to understand the importance of these trivial matters. I'm not just opinionating, by now I have no other _choice_ but to look for alternatives - and I do feel a little bit sad.
>
> Android, iOS - Contribute to help make it better.

It would help if the main official compiler supported those operating systems. That would mean adding ARM support to DMD. Or a much simpler solution, use an existing backend that has ARM support built in to it and is maintained by a much larger established group of individuals. Say like how some languages, like Rust, do.