Hi guys,

I've been following the forums for a while. I'm interested in looking into D, but I understand that currently it changes often, and is not very reliable.
I've also read that there's a new release model planned, where a stable version of the language is released every year or two. Is that so? When would it take place?

What's holding you from releasing a version now and declaring it stable for e.g. a year?

On Sunday, 21 April 2013 at 19:58:14 UTC, Tourist wrote:
> Hi guys,
>
> I've been following the forums for a while. I'm interested in looking into D, but I understand that currently it changes often, and is not very reliable.
> I've also read that there's a new release model planned, where a stable version of the language is released every year or two. Is that so? When would it take place?
>
> What's holding you from releasing a version now and declaring it stable for e.g. a year?

The year long support is not going to be put in place at this time. Several took issue with that plan considering it to provide limited/no benefit.

The core dev team is currently getting use to using a staging branch to prepare a release.

Eventually we may see a release get patched up until the point of the next release, but this has not yet been adopted by the core team or those writing patches. Having a clear understanding of what goes where has been a big point of discussion which again no one could agree on the specifics.

On Sunday, 21 April 2013 at 19:58:14 UTC, Tourist wrote:
> What's holding you from releasing a version now and declaring it stable for e.g. a year?

What would be the benefit of just declaring one release stable?

This is not a trick question.

David

On Monday, 22 April 2013 at 14:25:21 UTC, David Nadlinger wrote:
> On Sunday, 21 April 2013 at 19:58:14 UTC, Tourist wrote:
>> What's holding you from releasing a version now and declaring it stable for e.g. a year?
>
> What would be the benefit of just declaring one release stable?
>
> This is not a trick question.

That would not be a benefit, maybe. But, however, an answer to the question: "will EVER D be finished?" would be more than wonderful.

Clean up the doubtful or wrong features and let it as it is. Further language improvements should be made after several years of use. Much like C++ is evolving with its standards, also C (C89, C99 etc.)

Seriously, now, D is in the making for a decade and more. And, until it gets stable and Walter STOPS working on D (language) and, instead, only works on the COMPILER, things are not done.

D starts looking like the D in _D_uke Nukem Forever (and forever it will take...).

I got old looking at D and hoping that it will ever get released.

Imagine that Bjarne Stroustrup would proceed today with changing C++ at the same pace as D is. C++ still evolves, albeit less fast than D, but also with much more scrutinity and, let's say, conservatorism. Which, after a while, it is good.

Will D remain the forever unborn child of the programming languages?

Born it. Let it become what is intended to be: a MATURE language. Yes, it might not grow perfect, but it will grow. It needs to get into childhood, enough with the (pro-)creation.

At my job I went back to C++. With a language contunously in the making, the tools will never mature enough, never will get Eclipse plugins as good as CDT, never etc.

I have that feeling (correct me if I am wrong) that C++ will catch up with D in several years. Look at C++11, it is a nice improvement. C++14 will be (hopefully) even better. And, then?...

Radons&Minayev made a good decision to quit D back then and never look behind. A toy it was, a toy remained.

I started a project a month ago, and for the moment my feeling is just: D can already be used as it. It's not "finished" but the state is stable enough I think.

The compiler is not perfect (not always really explicit messages, not able to compile for all architecture like ARM,...), but a lot of things can already be done.

I made few games on Nintendo DS console, with a pretty old gcc version on which it wasn't recommended to develop in C++ due to the lack of support of some core feature of language. Now I can just find D more advanced.

C++11 and C++14 aren't really interesting for me, just cause of lack of support of some compilers like Visual Studio, it really can be the hell to realize portable applications (iOS, Android, Windows, Mac OS X, gcc, clang, cl,...). Without talking of template meta programming that are pretty hard to compile on different compilers.
Because D is pretty well specified, you will never loose your time with compilers flags, missing features on a platform or macro issues before an include,...

I was surprise how it's easy to progress in D just because it's fast to build and test. There is also a lot of advanced features like __traits,... that are directly in the core of language/std lib.

Any IDE support D perfectly but Visual D and MonoD are just good enough for starting.

On Monday, 22 April 2013 at 23:35:56 UTC, Flamaros wrote:

The problem is not that D is usable or not as it is. The problem is that, until officially "handled to the user", it won't be taken too serious by the industry.

In other words, you won't find jobs as a D programmer.

C++ will improve more with the pending modules and other features that do not even have to wait 2014 for that (a TR will do the job). But the point here is not about C++.

The problem with D is that it's never finished. Everybody waits for the next version. Everytime I spoke to my boss about D, the answer was like: "hmmm... we'll discuss about it when it's ready".

D1 was killed by a under-developed phobos and by the the conflict tango-phobos, at least in part. What really killed D1 was the announcement of D2. And I have the feeling that after D2 is rolled out, people will start working on D3.

That's the wrong approach. If it is usable as it is, then shift the main effort on tools for it and on promoting it. Then, let it in the market, get feedback from compiler implementors and commercial users and formalize that as a proposal for the next D standard. Then, after public scrutinize the proposed changes for 6 months or 1 tear, implement them.

Only recently the focus was placed on implementing those shared libraries. Really, who'd have been expected to use D in commercial, large applications, without that support? Why did people wait for so long?

Keep running circles around Optlink and other specific tools just for the sake of them? I agree they *were* valuable, but they *were*. Focus on the ldc or gcc/gdc implementation, for example. Use that as the official compiler. Do not split effort. There are a lot of standard tools that will facilitate adoption, yet the effort is misplaced.

Put the current language version on the market, along with a document summarizing proposals for the future standard and get feedback from users that will start using it for real applications, on large scale.

No need, for now, to make Phobos the best of the best. The curse of Tango vanished. Ship it as it is, incomplete but cleaned, then some libraries will be written and they will find almost naturally place in the standard library, just as the C++ standard integrates parts from Boost, integrated STL etc.

Pursuing perfection will miss the good.

On Tuesday, 23 April 2013 at 01:06:49 UTC, eles wrote:
> On Monday, 22 April 2013 at 23:35:56 UTC, Flamaros wrote:
>
> The problem is not that D is usable or not as it is. The problem is that, until officially "handled to the user", it won't be taken too serious by the industry.
>
> In other words, you won't find jobs as a D programmer.
>
> C++ will improve more with the pending modules and other features that do not even have to wait 2014 for that (a TR will do the job). But the point here is not about C++.
>
> The problem with D is that it's never finished. Everybody waits for the next version. Everytime I spoke to my boss about D, the answer was like: "hmmm... we'll discuss about it when it's ready".
>
> D1 was killed by a under-developed phobos and by the the conflict tango-phobos, at least in part. What really killed D1 was the announcement of D2. And I have the feeling that after D2 is rolled out, people will start working on D3.
>
> That's the wrong approach. If it is usable as it is, then shift the main effort on tools for it and on promoting it. Then, let it in the market, get feedback from compiler implementors and commercial users and formalize that as a proposal for the next D standard. Then, after public scrutinize the proposed changes for 6 months or 1 tear, implement them.
>
> Only recently the focus was placed on implementing those shared libraries. Really, who'd have been expected to use D in commercial, large applications, without that support? Why did people wait for so long?
>
> Keep running circles around Optlink and other specific tools just for the sake of them? I agree they *were* valuable, but they *were*. Focus on the ldc or gcc/gdc implementation, for example. Use that as the official compiler. Do not split effort. There are a lot of standard tools that will facilitate adoption, yet the effort is misplaced.
>
> Put the current language version on the market, along with a document summarizing proposals for the future standard and get feedback from users that will start using it for real applications, on large scale.
>
> No need, for now, to make Phobos the best of the best. The curse of Tango vanished. Ship it as it is, incomplete but cleaned, then some libraries will be written and they will find almost naturally place in the standard library, just as the C++ standard integrates parts from Boost, integrated STL etc.
>
> Pursuing perfection will miss the good.

I couldn't have said it better!

On Monday, 22 April 2013 at 23:35:56 UTC, Flamaros wrote:
> I started a project a month ago, and for the moment my feeling is just:
> D can already be used as it.

Input:
	import std.stdio;
	struct S { string a; }
	pragma(msg,           S("x") == S("x".idup));
	void main() { writeln(S("x") == S("x".idup)); }


Output:
	true
	false

...


Nope, still broken.

On Tuesday, 23 April 2013 at 03:46:30 UTC, Mehrdad wrote:
> ...
>
>
> Nope, still broken.

The behavior isn't too surprising to me. Your code is buggy. Defining opEquals gets you the behavior you might want:

import std.stdio, std.algorithm;
struct S {
    string a;
    bool opEquals(S rhs) { return a.equal(rhs.a); }
}
pragma(msg,  S("x") == S("x".idup));
void main() {
    writeln(S("x") == S("x".idup));
}

outputs:
true
true

On Tuesday, 23 April 2013 at 04:26:59 UTC, Chris Cain wrote:
> On Tuesday, 23 April 2013 at 03:46:30 UTC, Mehrdad wrote:
>> ...
>>
>>
>> Nope, still broken.
>
> The behavior isn't too surprising to me. Your code is buggy.


?!??!