Stable D version?

[Paulo Pinto]

On Tuesday, 23 April 2013 at 07:43:21 UTC, Flamaros wrote:
> On Monday, 22 April 2013 at 22:17:33 UTC, eles wrote:
>> 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 don't think my boss I have to know if D is finished to let us
> adopt it for future products, he only want to know we'll able to
> create our next product with D with the same requirement and if
> the delay will be the same or better.
>
> For the moment due to our target platform the response is no. 
> But
> if we target only Desktops the answer seems to be really close 
> to
> a yes. Some libraries are missing, but there is nothing we 
> aren't
> capable to write. The major issue for a boss is to accept to 
> move
> "old" c++ code to trash, that was his investment, actually
> because there is no D developers on job market, D code isn't
> valuable for him.
>
> To break the vicious circle some companies have to take the risk
> to migrate to D and let the world know it.
>
> The easier way for a language to be inserted in companies is
> certainly as scripting language, just like python. Because
> companies doesn't consider script as really pieces of software
> and let developers send it to trash. It's a mistake to not
> considering scripts as valuable just because they are not sell.

The hardest selling point for systems programming languages is to 
get them adopted by an OS vendor, until then they are just 
another tool for business applications, a field already too 
crowded nowadays.

Look at C++, only in the last decade did OS vendors start coding 
operating systems in C++, instead of plain C, to the point that C 
is now considered legacy at Microsoft.

Who knows how long it will take for another vendor to pick up D 
for such use cases, even if it was 100% stable today?

These things take a long time, even programmer generations.

--
Paulo