On 23 April 2013 09:56, eles <eles@eles.com> wrote:

> On Tuesday, 23 April 2013 at 08:40:16 UTC, Dicebot wrote:
>
>>
>> D has reference compiler and thus you technically suggest to stop releasing any compiler version for 1-2 years. Ugh.
>>
>
> No. Stop adding things.
>
> Besides that, what's the alternative?
>

Adding things isn't a problem and does not affect already existing code. Perhaps you meant changing behaviours and removing things?

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Tuesday, 23 April 2013 at 09:23:50 UTC, Iain Buclaw wrote:
> On 23 April 2013 09:56, eles <eles@eles.com> wrote:
>
>> On Tuesday, 23 April 2013 at 08:40:16 UTC, Dicebot wrote:
>>
>>>
>>> D has reference compiler and thus you technically suggest to stop
>>> releasing any compiler version for 1-2 years. Ugh.
>>>
>>
>> No. Stop adding things.
>>
>> Besides that, what's the alternative?
>>
>
> Adding things isn't a problem and does not affect already existing code.
> Perhaps you meant changing behaviours and removing things?

Any addition in D can be breaking wconsidering feature like is(typeof(blah))

On Tuesday, 23 April 2013 at 08:56:37 UTC, eles wrote:
> On Tuesday, 23 April 2013 at 08:40:16 UTC, Dicebot wrote:
>>
>> D has reference compiler and thus you technically suggest to stop releasing any compiler version for 1-2 years. Ugh.
>
> No. Stop adding things.
>
> Besides that, what's the alternative?

We don't have formal spec. Bug-fixing changes can't be differentiated from "new" changes.  My ancient proposal is still in the newsgroup : http://forum.dlang.org/post/nchvayzsbrzevvucmmmi@forum.dlang.org

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

On 4/23/13 4:33 AM, eles wrote:
> On Tuesday, 23 April 2013 at 07:52:20 UTC, Mehrdad wrote:
>> On Tuesday, 23 April 2013 at 07:50:44 UTC, Dicebot wrote:
>>> I have raised this topic several times already. Stable version that
>>> is guaranteed to never break user code
>>
>>
>> So what happens when a flaw in the language is fixed?
>>
>> Do you fix it and break code, or do you leave it broken?
>
> I am more for following the C/C++ solution: periodical revise the
> language, but not every two months. Several years and once that the
> compiler infrastructure is already in place and tested, publish
> (officially) the new version.
>
> During the meantime, users could live with workarounds and "forbidden to
> do that!". Look at C and MISRA-C.
>
> It won't help to declare a stable version of D, while keep adding new
> things. What would really help is to stop adding new things, remove
> those that we are in doubt if they are good or no (properties?) or, at
> least, leave them as they are, then move towards improving the tools.
>
> A cleaner language with better tools will allow D to take off, while
> still leaving room for possible improvements in future revisions.
>
> C++ did not start as a perfect language, nor it has become, still there
> are tools for it, people are using it, companies are hiring C++ developers.
>
> Being predictable does matter sometimes. Tools matter too.

I think we shouldn't follow the C++ model. Whatever made C++ successful is not what'll make D successful. The context and expectations are very different now.

Andrei

On Tuesday, 23 April 2013 at 14:26:33 UTC, Andrei Alexandrescu wrote:
> I think we shouldn't follow the C++ model. Whatever made C++ successful is not what'll make D successful. The context and expectations are very different now.
>
> Andrei

That's a pretty vague assertion. Please define the model that you have in mind for D.

OK. Don't follow the C++ model. But, then, what is the model that D follows? Is there any such model?

On 4/23/13 2:42 PM, eles wrote:
> On Tuesday, 23 April 2013 at 14:26:33 UTC, Andrei Alexandrescu wrote:
>> I think we shouldn't follow the C++ model. Whatever made C++
>> successful is not what'll make D successful. The context and
>> expectations are very different now.
>>
>> Andrei
>
> That's a pretty vague assertion. Please define the model that you have
> in mind for D.
>
> OK. Don't follow the C++ model. But, then, what is the model that D
> follows? Is there any such model?

I was mainly referring to the fact that C++ succeeded in spite of having initially an incomplete specification. Nowadays the expectations are much higher.

Andrei

On Tuesday, 23 April 2013 at 18:57:46 UTC, Andrei Alexandrescu wrote:
> On 4/23/13 2:42 PM, eles wrote:
>> On Tuesday, 23 April 2013 at 14:26:33 UTC, Andrei Alexandrescu
> I was mainly referring to the fact that C++ succeeded in spite of having initially an incomplete specification. Nowadays the expectations are much higher.
>
> Andrei

As long as you keep changing the language, no specification will ever be complete.

C++ will long advance. D must be out and living before C++14. Then, it will be too late. My view.

On 04/23/2013 10:21 PM, eles wrote:
> On Tuesday, 23 April 2013 at 18:57:46 UTC, Andrei Alexandrescu wrote:
>> On 4/23/13 2:42 PM, eles wrote:
>>> On Tuesday, 23 April 2013 at 14:26:33 UTC, Andrei Alexandrescu
>> I was mainly referring to the fact that C++ succeeded in spite of
>> having initially an incomplete specification. Nowadays the
>> expectations are much higher.
>>
>> Andrei
>
> As long as you keep changing the language, no specification will ever be
> complete.
>

It is the other way round. As long as there is no specification, there are no language changes, as everything can be cast as a bug fix towards implementing some imaginary specification that is different for each dev.

> C++ will long advance. D must be out and living before C++14. Then, it
> will be too late.

I think there is no reason to assume that C++ can be fixed.

> My view.

Obviously.

Am 23.04.2013 22:21, schrieb eles:
> On Tuesday, 23 April 2013 at 18:57:46 UTC, Andrei Alexandrescu wrote:
>> On 4/23/13 2:42 PM, eles wrote:
>>> On Tuesday, 23 April 2013 at 14:26:33 UTC, Andrei Alexandrescu
>> I was mainly referring to the fact that C++ succeeded in spite of
>> having initially an incomplete specification. Nowadays the
>> expectations are much higher.
>>
>> Andrei
>
> As long as you keep changing the language, no specification will ever be
> complete.
>
> C++ will long advance. D must be out and living before C++14. Then, it
> will be too late. My view.

C++ was created around 1985, that is 28 years as of today.

I remember going through the ARM (Annotated Reference Manual) around
1995 and not finding a C++ compiler that was able to compile all examples.

Following "The C Users Journal", shortly thereafter renamed "The C/C++ Users Journal" and "C++ Report" and seeing the language change each month, with each C++ compiler offering a different view what the language meant.

C++ will be with us for many years to come, but you should not forget that it has a few years in the industry already, and as I mentioned in a separate post, systems programming languages require support from OS vendors.

As a supporter for stronger typed languages I look forward not only D, but Rust and Go as well, even with its issues, to gain wider support, but it takes time.

--
Paulo