I'm also attempting to utilize D on a commercial basis in an attempt to gain productivity benefits over C++. I'm willing to put up with some bugs and a few breaking changes so long as I see D is improving for the better, and at a decent pace.

I think what this forum definitely could use is a place holder for commercial users. That way the D developers can see what is working well and what is not when the language is put to real use. Everyone will win from having that.

--rt

On 2012-11-28 02:40, deadalnix wrote:

> Don't you think that this whole situation is due to adding feature after
> feature in an unstabilized mess ?

It is, that's the major problem with D. Not the actual code breakage, rather how those are introduced.

-- 
/Jacob Carlborg

On 2012-11-28 01:56, deadalnix wrote:

> We have a project management issue here in the first place.

I completely agree.

-- 
/Jacob Carlborg

On 2012-11-28 02:30, Mike Parker wrote:

> I've no idea what sort of commercial interests are using D in
> production, but I'd still confidently make the bet that a few breaking
> changes now (for issues that people find frustrating) would do more good
> than harm in the long run. Especially if they are introduced gradually
> and with time to understand their ramifications.

There's been a few post in this thread mentioning they work on a commercial code base using D. They all came to the same conclusion that the code breaking is worth it if it fixes actual problems in the language.

-- 
/Jacob Carlborg

On 2012-11-27 22:23, Walter Bright wrote:

> I understand what you're saying, but the counterpoint is we lost half
> the D community when D2 broke D1 code. We still have at least one major
> D1 user that still finds it impractical to upgrade to D2.

That was more an issue of how the community and project were run (or rather not run). Not the actual code breakage.

> It is unbelievably frustrating for people to have their code break with
> each new release, have older projects all invalidated, with few willing
> to do the maintenance work to bring them back on line.

I think it's just as unbelievably frustrating to freeze a language at a given point without thinking of the implications. Or declaring that a language cannot receive any more breaking changes when it's far from done and many things aren't working properly.

I cannot believe how you could consider D stable when your adding new features directly to the master branch willy nilly. A book was released way, way too soon for a language far from ready.

This is mostly a problem about how the project is run and managed. No road map, a poor release process, committing new features directly to the master branch. Unstable features added, added even before they're can be considered finished. I mean, "const" was one of the first things added to D2, it still has problems and druntime/Phobos is still not const correct.

We have complained before, quite often Andrei agrees that several things need to be changed but it's not much that happens.

-- 
/Jacob Carlborg

On 2012-11-27 22:23, Walter Bright wrote:

> I understand what you're saying, but the counterpoint is we lost half
> the D community when D2 broke D1 code. We still have at least one major
> D1 user that still finds it impractical to upgrade to D2.
>
> It is unbelievably frustrating for people to have their code break with
> each new release, have older projects all invalidated, with few willing
> to do the maintenance work to bring them back on line.

In the keynote for the latest Ruby on Rails conference. The original creator of Ruby on Rails goes out and say: Yes, Rails 4 will break existing code. He also says that progress is good and one should keep a young mind.

I can assure you that Ruby on Rails has vastly more commercial developers than D has.

What I mean is that that process of improving the language most not stop and should always continue. It's just the process how that is made that makes the big difference.

-- 
/Jacob Carlborg

On 28 November 2012 03:30, Mike Parker <aldacron@gmail.com> wrote:

> On Tuesday, 27 November 2012 at 21:23:12 UTC, Walter Bright wrote:
>
>> On 11/28/2012 5:25 AM, Max Samukha wrote:
>>
>>> Please stop repeating that "will break lots of code" mantra. D user base is very small and it doesn't grow *because* issues like the one discussed do not get fixed. When they are fixed people may start using the language. And *then* you would have to worry about backward compatibility. Look at the recent Manu's complaints and see what people who would really use the language have wanted from it for years.
>>>
>>
>> I understand what you're saying, but the counterpoint is we lost half the D community when D2 broke D1 code. We still have at least one major D1 user that still finds it impractical to upgrade to D2.
>>
>
> That was more than a breaking change. That was a massive paradigm shift. All the drama going on back then was rooted more in philosophical differences and the Phobos/Tango divide, than changes to the language. What's being discussed here is breakage on a much smaller scale.
>
> I've always said that it's the little things in aggregate that make D such a wonderful language to work with. But the flipside of that is the little annoyances in aggregate can make it frustrating to work with. New users coming to a language often have little patience. IMO, their encountering these little annoyances before the good stuff takes hold is a far more pressing issue than a few minor breaking changes.
>

Very important point! I'm far more patient and persistent than others in my company...

I've no idea what sort of commercial interests are using D in production,
> but I'd still confidently make the bet that a few breaking changes now (for issues that people find frustrating) would do more good than harm in the long run. Especially if they are introduced gradually and with time to understand their ramifications.

On 28 November 2012 03:40, deadalnix <deadalnix@gmail.com> wrote:

> On Wednesday, 28 November 2012 at 00:07:42 UTC, bearophile wrote:
>
>> Walter Bright:
>>
>>  It is unbelievably frustrating for people to have their code break with
>>> each new release, have older projects all invalidated, with few willing to do the maintenance work to bring them back on line.
>>>
>>
>> I am still converting some of my D1 code to D2, plus I have lot of D2 code. Since many months I have stopped downloading official dmd releases because the amount of breakages in my D2 code between a version and the successive one was too much large. DMD 2.061 has so many changes and improvements that it will require several changes in everyone D2 code.
>>
>> To avoid performing such large amount of changes I now compile dmd every two or three days, and I have scripts that compile all my D2 programs and report the breakages. This way I fix a small amount of breakages at a time in my D2 code, this is simpler.
>>
>> Most of those breakages are caused by bug fixings that reveal bugs in my D2 code (example: since recently throwing constructors accepted a nothrow tag, and I have many more examples). But I am willing to perform this maintenance work because they improve my future D2 programming and code.
>>
>> If we add to those bug-fixing-changes some breakage caused by design changes, this is not going to make my live significantly worse, it's just one more breakage among several others.
>>
>>
> Don't you think that this whole situation is due to adding feature after feature in an unstabilized mess ?
>

Not really. I haven't seen any problems in any new stuff since I've been around.

Almost all the issues I encounter stem from the type system (like the
alias/builtin type thing discussed), tuples (value/expression/type tuples?
what is the syntax to identify these? what are they exactly?),
is()/__traits not identifying things cleanly (strange workarounds to
identify seemingly trivial details)... and ref.

Every one of these things was in the language before I started using it, so at least to me, they feel like old features that have just always been there...


I mean, how the fact that a nothrow constructor can throw can be explained
> in another way (to use your example) ? A feature in that state should have reached any release, ever !
>

On Wednesday, 28 November 2012 at 09:26:55 UTC, Jacob Carlborg wrote:
> On 2012-11-27 22:23, Walter Bright wrote:
>
>> I understand what you're saying, but the counterpoint is we lost half
>> the D community when D2 broke D1 code. We still have at least one major
>> D1 user that still finds it impractical to upgrade to D2.
>>
>> It is unbelievably frustrating for people to have their code break with
>> each new release, have older projects all invalidated, with few willing
>> to do the maintenance work to bring them back on line.
>
> In the keynote for the latest Ruby on Rails conference. The original creator of Ruby on Rails goes out and say: Yes, Rails 4 will break existing code. He also says that progress is good and one should keep a young mind.
>...

Lets see if the Ruby community will take it better than the Python one has.

--
Paulo

On 2012-11-28 10:53, Paulo Pinto wrote:

> Lets see if the Ruby community will take it better than the Python one has.

Ruby on Rails still updates older version. Rails 3.2.8 is the current stable release. But since the first release of Rails 3 the Rails 2.3 branch has received new updates and releases. Ruby on Rails, actually most of the Ruby projects, use a sane versioning scheme that makes it easier to handle code breakage.

-- 
/Jacob Carlborg