October 08, 2014
On 10/8/2014 4:17 AM, Don wrote:
> As I said in my Dconf 2013 talk -- I advocate a focus on Return On Investment.
> I'd love to see us chasing the easy wins.

I love the easy wins, too. It'd be great if you'd start a thread about "Top 10 Easy Wins" from yours and Sociomantic's perspective.

Note that I've done some work on the deprecations you've mentioned before.

October 08, 2014
On 10/8/14, 4:17 AM, Don wrote:
> On Monday, 6 October 2014 at 19:07:40 UTC, Andrei Alexandrescu wrote:
>> More particulars would be definitely welcome. I should add that
>> Sociomantic has an interesting position: it's a 100% D shop so
>> interoperability is not a concern for them, and they did their own GC
>> so GC-related improvements are unlikely to make a large difference for
>> them. So "C++ and GC" is likely not to be high priority for them. --
>> Andrei
>
> Exactly. C++ support is of no interest at all, and GC is something we
> contribute to, rather than something we expect from the community.

That's awesome, thanks!

> Interestingly we don't even care much about libraries, we've done
> everything ourselves.
>
> So what do we care about? Mainly, we care about improving the core product.
>
> In general I think that in D we have always suffered from spreading
> ourselves too thin. We've always had a bunch of cool new features that
> don't actually work properly. Always, the focus shifts to something
> else, before the previous feature was finished.
>
> At Sociomantic, we've been successful in our industry using only the
> features of D1. We're restricted to using D's features from 2007!!
> Feature-wise, practically nothing from the last seven years has helped us!
>
> With something like C++ support, it's only going to win companies over
> when it is essentially complete. That means that working on it is a huge
> investment that doesn't start to pay for itself for a very long time. So
> although it's a great goal, with a huge potential payoff, I don't think
> that it should be consuming a whole lot of energy right now.
>
> And personally, I doubt that many companies would use D, even if with
> perfect C++ interop, if the toolchain stayed at the current level.

That speculation turns out to not be true for Facebook. My turn to speculate - many other companies have existing codebases in C++, so Sociomantic is "special".

> As I said in my Dconf 2013 talk -- I advocate a focus on Return On
> Investment.
> I'd love to see us chasing the easy wins.

That's of course good, but the reality is we're in a complicated trade-off space with "important", "urgent", "easy to do", "return on investment", "resource allocation" as axes. An example of the latter - ideally we'd put Walter on the more difficult tasks and others on the easy wins. Walter working on improving documentation might not be the best use of his time, although better documentation is an easy win.


Andrei

October 08, 2014
On 10/6/2014 11:13 AM, Dicebot wrote:
> Especially because
> you have stated that previous proposal (range-fication) which did fix the issue
> _for me_ is not on the table anymore.

I think it's more stalled because of the setExtension controversy.


> How about someone starts paying attention to what Don posts? That could be an
> incredible start.

I don't always agree with Don, but he's almost always right and his last post was almost entirely implemented.

October 08, 2014
On 09/10/2014 2:40 am, "Joakim via Digitalmars-d" < digitalmars-d@puremagic.com> wrote:
>
> On Wednesday, 8 October 2014 at 13:55:11 UTC, Manu via Digitalmars-d
wrote:
>>
>> On 08/10/2014 9:20 pm, "Don via Digitalmars-d"
>>>
>>> So what do we care about? Mainly, we care about improving the core
>>
>> product.
>>>
>>>
>>> In general I think that in D we have always suffered from spreading
>>
>> ourselves too thin. We've always had a bunch of cool new features that don't actually work properly. Always, the focus shifts to something else, before the previous feature was finished.
>>>
>>>
>>> And personally, I doubt that many companies would use D, even if with
>>
>> perfect C++ interop, if the toolchain stayed at the current level.
>>
>> As someone who previously represented a business interest, I couldn't
agree
>> more.
>> Aside from my random frustrated outbursts on a very small set of language
>> issues, the main thing I've been banging on from day 1 is the tooling.
Much
>> has improved, but it's still a long way from 'good'.
>>
>> Debugging, ldc (for windows), and editor integrations (auto complete,
>> navigation, refactoring tools) are my impersonal (and hopefully
>> non-controversial) short list. They trump everything else I've ever
>> complained about.
>> The debugging experience is the worst of any language I've used since the
>> 90's, and I would make that top priority.
>
>
> While it would be great if there were a company devoted to such D
tooling, it doesn't exist right now.  It is completely unrealistic to expect a D community of unpaid volunteers to work on these features for your paid projects.  If anybody in the community cared as much about these features as you, they'd have done it already.
>
> I suggest you two open bugzilla issues for all these specific bugs or
enhancements and put up bounties for their development.  If you're not willing to do that, expecting the community to do work for you for free is just whining that is easily ignored.

We're just talking about what we think would best drive adoption. Businesses aren't likely to adopt a language with the understanding that they need to write it's tooling. Debugging, code competition and refactoring are all expert tasks that probably require compiler involvement.

I know it's easy to say that businesses with budget should contribute more. But it's a tough proposition. Businesses will look to change language if it saves them time and money. If it's going to cost them money, and the state of tooling is likely to cost them time, then it's not a strong proposition. It's a chicken and egg problem. I'm sure business will be happy to contribute financially when it's a risk free investment; ie, when it's demonstrated that that stuff works for them.


October 09, 2014
On 9/25/2014 4:08 AM, Don wrote:
> I'd also like to see us getting rid of those warts like assert(float.nan) being
> true.

https://issues.dlang.org/show_bug.cgi?id=13489

It has some serious issues with it - I suspect it'll cause uglier problems than it fixes.


> And adding a @ in front of pure, nothrow.

https://issues.dlang.org/show_bug.cgi?id=13388

It has generated considerable discussion.
October 09, 2014
On Thursday, 9 October 2014 at 00:30:53 UTC, Walter Bright wrote:
> On 9/25/2014 4:08 AM, Don wrote:
>
>> And adding a @ in front of pure, nothrow.
>
> https://issues.dlang.org/show_bug.cgi?id=13388
>
> It has generated considerable discussion.

Please break the language, now.

---
/Paolo



October 09, 2014
On Wednesday, 8 October 2014 at 20:35:05 UTC, Andrei Alexandrescu wrote:
> On 10/8/14, 4:17 AM, Don wrote:
>> On Monday, 6 October 2014 at 19:07:40 UTC, Andrei Alexandrescu wrote:
>>
>> And personally, I doubt that many companies would use D, even if with
>> perfect C++ interop, if the toolchain stayed at the current level.
>
> That speculation turns out to not be true for Facebook. My turn to speculate - many other companies have existing codebases in C++, so Sociomantic is "special".

Well, when IMHO, when discussing 'strategies', pretty everything it's a speculation...
C++ interlope can also be attrattive when you need to start a new project, a you need C++ libs.

But, the point it's that, again, IMHO, you tend to conflate Facebook need with D need (I know I'll receive pain back for this ;-).

Sociomantic is not so special at all, about not having a previous C++ codebase: I personally know plenty of cases like that.

But if D don't stop thinking about "new feature" and never terminate the previous plans, well, my speculations is that I donno about future adopters, but for sure it's scouring actual adopters; and the for sure it's based on what we feel here in SR Labs company.

> That's of course good, but the reality is we're in a complicated trade-off space with "important", "urgent", "easy to do", "return on investment", "resource allocation" as axes. An example of the latter - ideally we'd put Walter on the more difficult tasks and others on the easy wins. Walter working on improving documentation might not be the best use of his time, although better documentation is an easy win.

Well, I've read your and Walter comment on the multiple alias this PR, so good: but the point that it was the community that pushed both of you on that track, it's systematic about an attitude.

And now, shields up, Ms Sulu!
--
/Paolo
October 09, 2014
On Wednesday, 8 October 2014 at 21:07:24 UTC, Walter Bright wrote:
> On 10/6/2014 11:13 AM, Dicebot wrote:
>> Especially because
>> you have stated that previous proposal (range-fication) which did fix the issue
>> _for me_ is not on the table anymore.
>
> I think it's more stalled because of the setExtension controversy.
>
>
>> How about someone starts paying attention to what Don posts? That could be an
>> incredible start.
>
> I don't always agree with Don, but he's almost always right and his last post was almost entirely implemented.

Wow, thanks, Walter! I'm wrong pretty regularly, though. A reasonable rule of thumb is to ask Daniel Murphy, aka yebblies. If he disagrees with me, and I can't change his mind within 30 minutes, you can be certain that I'm wrong. <g>
October 09, 2014
> While it would be great if there were a company devoted to such D tooling, it doesn't exist right now.  It is completely unrealistic to expect a D community of unpaid volunteers to work on these features for your paid projects.  If anybody in the community cared as much about these features as you, they'd have done it already.

It might be unfair but it is still a massive problem. The tooling compared to what I have with say C++ and Qt is not a fun experience. The language is nicer but the difference in tooling is making the difference seem a lot smaller than it should be.
October 09, 2014
> Debugging, ldc (for windows), and editor integrations (auto complete,
> navigation, refactoring tools) are my impersonal (and hopefully
> non-controversial) short list. They trump everything else I've

I don't know how well DCD works with other editors, but in Emacs at least (when DCD doesn't throw an exception, I need to chase those down), autocomplete and code navigation just work. _Including_ dub dependencies.

> The debugging experience is the worst of any language I've used since the
> 90's, and I would make that top priority.

Debugging can definitely be improved on. Even with Iain's fork of gdb I end up using writeln instead because it's frequently easier.

Atila