On 1/16/2012 12:00 AM, Gour wrote:
> Recently I was evaluating one CMS written in one popular Python
> framework and after reporting bug which makes it unusable for even
> simple page layout, hearing nothing from the developer and then seeing
> it's fixed after more than two months, it was not difficult to abandon
> idea to base our sites on such a product.


Your other ideas are well considered, but I have to take issue with this one.

I have submitted many, many bug reports over the decades to Major Software Vendors with well supported software products.

How many times have I gotten anything other than a robo-reply?

    zero

When my company has paid $ in the 5 figures for "premium" tech service, what is the response to bug reports?

    nothing

    -- or --

    that's not a bug

    -- or --

    you're a unique snowflake and nobody else has that problem
    so we won't fix it

How many times has a bug I reported ever been fixed, even waiting a year for the next update?

    zero

I take that back. One time I got so mad about this I contacted the CEO of the Major Software Vendor (I knew him personally) and he got out a crowbar, went to see the dev team, and (allegedly) thwacked a few of them. The bug still never got fixed, but I got an acknowledgment.

This has obviously never impeded anyone from using their software tools.

It's also why:

1. I never bother filing bug reports to Major Software Vendors anymore.

2. With Digital Mars products, anyone can file a bug report with Bugzilla without needing me to acknowledge or filter it.

3. Anyone can read and comment on those bug reports.

4. I think we've had great success using Github and allowing anyone to fork & fix & publish.

I know our response to bug reports is far from perfect, but at least we aren't hiding under a rock.

It's also true that if a company wanted to bet the farm on D, and were willing to put some money behind it, their concerns would get priority, as full time professional developers could get hired to do it.

On 2012-01-17 02:05, Walter Bright wrote:
> On 1/16/2012 3:26 PM, Kiith-Sa wrote:
>> I'm well aware of the fact - my work depends on SDL, OpenGL and FreeType
>> using the Derelict bindings (Those probably don't belong to Deimos as
>> they're
>> not absolutely thin bindings although they don't wrap the APIs in any
>> way)
>
> It would be nice to split the Derelict bindings in twain - a thin layer
> for Deimos, and then the more D-ish layer for Derelict on top of that.

It doesn't contain a D-ish layer. The only idea beside the bindings are to help loading the libraries at runtime platform independent.

-- 
/Jacob Carlborg

On 2012-01-16 22:02, Kiith-Sa wrote:
> A:
> 1 -
> I think we're getting close to that point. I do encounter compiler bugs
> from time to time, but the frequency is rapidly decreasing with the recent
> releases. We already have the "Easier to code" and "Decent performance"
> parts, but there's a lot of room to improve (standard build system, package
> manager, better Phobos, better GC or better noGC options).
>
> 2 -
> This is a problem and it probably will continue to be so for some time.
> Native D GUI framework of size of GTK/Qt is infeasible.
> AFAIK GtkD is usable now, but not sure how D-like its API is, probably
> not much?

DWT is a GUI library completely written in D:

http://www.dsource.org/projects/dwt

-- 
/Jacob Carlborg

On Mon, 16 Jan 2012 20:32:40 -0800
Walter Bright <newshound2@digitalmars.com> wrote:

> Your other ideas are well considered, but I have to take issue with this one.

OK.

> 4. I think we've had great success using Github and allowing anyone to fork & fix & publish.

I apologize for my (poor) attempt to illustrate Adrei's "Otherwise, we must show people that we are serious about finishing the core language implementation, that we make promises that we are able to keep, and that we make plans that we follow even in the broadest strokes." and my post was in no way trying to minimize community work when handling bug reports. At the end, I never submitted even the single bug report, so it wouldn't be fair to criticize it.

My example was just meant to show what might be the result when one feels that developers are not behind their product in a sense that one 'cannot count on the project' which was supposed to be continuation on my "we always get the feedback it's not safe investment of our time & energy and it would be better to use something else, either C(++), Java, Scala, Python etc."

So, I highly admire the work of all members within D community giving something valuable for free, but being interested in success of D, I wanted to share my experience I have when trying to advocate using of D for real (open-source) projects *today*.

I'll try to be more sensitive next time...


Sincerely,
Gour

-- 
What is night for all beings is the time of awakening for the self-controlled; and the time of awakening for all beings is night for the introspective sage.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

On 1/17/2012 2:07 AM, Gour wrote:
> My example was just meant to show what might be the result when one
> feels that developers are not behind their product in a sense that one
> 'cannot count on the project' which was supposed to be continuation on
> my "we always get the feedback it's not safe investment of our time&
> energy and it would be better to use something else, either C(++), Java,
> Scala, Python etc."
>
> So, I highly admire the work of all members within D community giving
> something valuable for free, but being interested in success of D, I
> wanted to share my experience I have when trying to advocate using of D
> for real (open-source) projects *today*.
>
> I'll try to be more sensitive next time...

I'm not taking issue with sensitivity, just that one is *less* likely to get responsive bug fixes from Major Software Vendor, and so dismissing D for that reason is invalid.

I've seen people say "D doesn't have feature X, so I'm going to use language B." But B doesn't have feature X, either. Again, the reason given is invalid.

The real issue is something they're not telling you. The trick is finding out the real issue, which can take some insight. Otherwise, you'll waste a lot of effort chasing rainbows.

Sometimes, the real issue is "nobody ever got fired for buying IBM." You could fix every issue on their list, and you still won't close the deal, because you are not IBM. You cannot please everyone, it's better to recognize who you *can* close the deal with (there's always someone who is not impressed by IBM), and work on their issues rather than the rainbows and smokescreens.

That means focus on what we are good at.

Hmm my experiences are similar for 90% of companies, though I have seen some exceptions (Perforce is receptive of feedback and bugs, Certain divisions of Microsoft are communicative, but not MSConnect).   The common denominator for communication looks pretty simple to me:

If there is anyone between you and the developer on the other end, it is doomed to be a black hole.   MSConnect is a form-letter 'your bug is a duplicate, we can't reproduce it, and please test it in our new version for us so we can fail to fix it even though we know about it', but working directly with divisions in Microsoft is much possible (i.e. console support for programmers working on XBOX is stellar for instance, completely the opposite experience of reporting bugs to MSConnect).


On 1/16/2012 10:32 PM, Walter Bright wrote:
> On 1/16/2012 12:00 AM, Gour wrote:
>> Recently I was evaluating one CMS written in one popular Python
>> framework and after reporting bug which makes it unusable for even
>> simple page layout, hearing nothing from the developer and then seeing
>> it's fixed after more than two months, it was not difficult to abandon
>> idea to base our sites on such a product.
>
>
> Your other ideas are well considered, but I have to take issue with this
> one.
>
> I have submitted many, many bug reports over the decades to Major
> Software Vendors with well supported software products.
>
> How many times have I gotten anything other than a robo-reply?
>
> zero
>
> When my company has paid $ in the 5 figures for "premium" tech service,
> what is the response to bug reports?
>
> nothing
>
> -- or --
>
> that's not a bug
>
> -- or --
>
> you're a unique snowflake and nobody else has that problem
> so we won't fix it
>
> How many times has a bug I reported ever been fixed, even waiting a year
> for the next update?
>
> zero
>
> I take that back. One time I got so mad about this I contacted the CEO
> of the Major Software Vendor (I knew him personally) and he got out a
> crowbar, went to see the dev team, and (allegedly) thwacked a few of
> them. The bug still never got fixed, but I got an acknowledgment.
>
> This has obviously never impeded anyone from using their software tools.
>
> It's also why:
>
> 1. I never bother filing bug reports to Major Software Vendors anymore.
>
> 2. With Digital Mars products, anyone can file a bug report with
> Bugzilla without needing me to acknowledge or filter it.
>
> 3. Anyone can read and comment on those bug reports.
>
> 4. I think we've had great success using Github and allowing anyone to
> fork & fix & publish.
>
> I know our response to bug reports is far from perfect, but at least we
> aren't hiding under a rock.
>
> It's also true that if a company wanted to bet the farm on D, and were
> willing to put some money behind it, their concerns would get priority,
> as full time professional developers could get hired to do it.

Jacob Carlborg wrote:

> On 2012-01-16 22:02, Kiith-Sa wrote:
>> A:
>> 1 -
>> I think we're getting close to that point. I do encounter compiler bugs
>> from time to time, but the frequency is rapidly decreasing with the recent
>> releases. We already have the "Easier to code" and "Decent performance"
>> parts, but there's a lot of room to improve (standard build system, package
>> manager, better Phobos, better GC or better noGC options).
>>
>> 2 -
>> This is a problem and it probably will continue to be so for some time.
>> Native D GUI framework of size of GTK/Qt is infeasible.
>> AFAIK GtkD is usable now, but not sure how D-like its API is, probably
>> not much?
> 
> DWT is a GUI library completely written in D:
> 
> http://www.dsource.org/projects/dwt
> 

DWT is a plain rewrite of SWT.
When writing D, I want to write D, not Java. I'd even prefer a C toolkit with
a D-style wrapper to that. I do think that D is an awesome language to
build a GUI toolkit from ground up - it's just unlikely to happen soon because
of the effort involved.

On 1/17/12 4:52 AM, Walter Bright wrote:
> On 1/17/2012 2:07 AM, Gour wrote:
>> My example was just meant to show what might be the result when one
>> feels that developers are not behind their product in a sense that one
>> 'cannot count on the project' which was supposed to be continuation on
>> my "we always get the feedback it's not safe investment of our time&
>> energy and it would be better to use something else, either C(++), Java,
>> Scala, Python etc."
>>
>> So, I highly admire the work of all members within D community giving
>> something valuable for free, but being interested in success of D, I
>> wanted to share my experience I have when trying to advocate using of D
>> for real (open-source) projects *today*.
>>
>> I'll try to be more sensitive next time...
>
> I'm not taking issue with sensitivity, just that one is *less* likely to
> get responsive bug fixes from Major Software Vendor, and so dismissing D
> for that reason is invalid.
>
> I've seen people say "D doesn't have feature X, so I'm going to use
> language B." But B doesn't have feature X, either. Again, the reason
> given is invalid.

This is often mentioned, so I, too, thought about it a fair amount. I think it would be hasty to simplify that judgment.

I think the reasoning goes like this:

1. D lacks feature X that is often needed during the use of language B, which lacks it too.

2. The person reasons they'll see advantage in switching to a language if it did have X.

3. D doesn't, so the proposition of making the effort to switch from B is less appealing.

Similar lines of thinking may go about features that B has and D doesn't, or about features that both B and D have but D implements them poorly, or about promising differentiating features that D has that don't work reliably.


Andrei

Andrei Alexandrescu Wrote:

> On 1/17/12 4:52 AM, Walter Bright wrote:
> > On 1/17/2012 2:07 AM, Gour wrote:
> >> My example was just meant to show what might be the result when one feels that developers are not behind their product in a sense that one 'cannot count on the project' which was supposed to be continuation on my "we always get the feedback it's not safe investment of our time& energy and it would be better to use something else, either C(++), Java, Scala, Python etc."
> >>
> >> So, I highly admire the work of all members within D community giving something valuable for free, but being interested in success of D, I wanted to share my experience I have when trying to advocate using of D for real (open-source) projects *today*.
> >>
> >> I'll try to be more sensitive next time...
> >
> > I'm not taking issue with sensitivity, just that one is *less* likely to get responsive bug fixes from Major Software Vendor, and so dismissing D for that reason is invalid.
> >
> > I've seen people say "D doesn't have feature X, so I'm going to use language B." But B doesn't have feature X, either. Again, the reason given is invalid.
> 
> This is often mentioned, so I, too, thought about it a fair amount. I think it would be hasty to simplify that judgment.
> 
> I think the reasoning goes like this:
> 
> 1. D lacks feature X that is often needed during the use of language B, which lacks it too.
> 
> 2. The person reasons they'll see advantage in switching to a language if it did have X.
> 
> 3. D doesn't, so the proposition of making the effort to switch from B is less appealing.
> 
> Similar lines of thinking may go about features that B has and D doesn't, or about features that both B and D have but D implements them poorly, or about promising differentiating features that D has that don't work reliably.
> 
> 
> Andrei

Solve d1, d2 to compatibility issues , Let d1 be popular , it¡®s are the current balanced each side the best way to , can be quiet and wait for the maturity of d2 .

thank's all

dolive

Le 11/01/2012 21:34, Walter Bright a écrit :
> On 1/11/2012 12:29 PM, Zachary Lund wrote:
>> D1 or D2 both don't have a very accurate definition. C and C++ has
>> several
>> hundred pages of specifications and while I'm hopefully not expecting
>> that, I do
>> want some certainty on what is *supposed* to happen.
>>
>> There is also no versioning. D2 is definitely different from D1 in the
>> case that
>> it's not backwards compatible, but version for the actual example
>> implementation
>> isn't enough, especially when that implementation doesn't always do
>> what it's
>> supposed to do.
>
> Please file bug reports for any errors/omissions in the specification on
> bugzilla.

Sorry to disapoint, but I don't think a newcomer can reasonably fill this type of bugs.

Usually, a newcomer isn't even sure if the bug comes from his/her code or from the compiler. How can you expect them to fill a bug about the spec ???