user narratives and communicating the benefit of D to the enterprise

I collected together a few of these here:
http://wiki.dlang.org/User_narratives_on_switching_to_D

Forgive my non-existent markup skills, and the text itself could 
do with some polishing.

Please do feel free to refine and extend these.

However I truly think that these can be very powerful in getting 
across the reasons why should someone should consider D.

We do a great job with sourcing, preparing, and cooking the 
steak.  Selling the sizzle is a work-in-progress, but if you 
think that D can benefit from broader corporate adoption, it's 
one area where a little effort can go a long way.  That doesn't 
mean telling a story that isn't true, but if someone is to 
appreciate why use D, then communicating the emotional sense of 
what is it like to switch must be a key part.

There were lots of helpful 'suggestions' on the reddit thread, 
and whilst you should listen to free advice (good criticism is 
hard to come by), it's often worth about what you pay for it 
because the people giving it, although perhaps well-intentioned, 
aren't familiar with your particular circumstances, and it's 
often these that matter.

As a newcomer to the forum and community, I am astonished by what 
people here have accomplished with very little funding.  
Obviously one talented programmer is better than a great deal of 
funding, but it seems like D might be at the point where a little 
(Continue reading)

Re: Dazz new description for D

On 08/31/2015 01:09 AM, Russel Winder via Digitalmars-d wrote:

 > Seems like the sound byte has become the "we can't read that sentence,
 > it is too long, and contains insufficient mispelt words". One does
 > wonder at the attention span of the post-texting generation, seems
 > like about 3ms. The human race is doomed.

That paragraph sounded interesting at first but tl;dr. :p

Ali

Re: Phobos' std.conv.text functions

On 08/31/2015 07:45 PM, H. S. Teoh via Digitalmars-d wrote:
> On Mon, Aug 31, 2015 at 07:40:24PM +0200, Timon Gehr via Digitalmars-d wrote:
>> On 08/31/2015 05:35 PM, H. S. Teoh via Digitalmars-d wrote:
> [...]
>> Also, the proposed rewrite does not fix the problem. (I haven't tested
>> it, but AFAIU, the following code is neither rejected by the pull, nor
>> does it print "123".)
>>
>> import std.stdio;
>>
>> void main(){
>>      string text="123";
>>      void foo(){
>>          import std.conv;
>>          writeln(text());
>>      }
>>      foo();
>> }
>>
>> (Also, essentially the same logic occurs in three distinct places in
>> the new code.)
>
> This code should *not* print "123", because text() is explicitly a
> function call, but the local variable 'text' is not a function.
>...

It's a typo, presumably caused by implicit good intentions. :o)
What I meant to write was this:

import std.stdio;
(Continue reading)

Re: Phobos' std.conv.text functions

On 08/31/2015 05:35 PM, H. S. Teoh via Digitalmars-d wrote:
> On Mon, Aug 31, 2015 at 03:15:07PM +0000, via Digitalmars-d wrote:
>> I have been bitten by the std.conv.text family of functions twice now
>> and while it's not a major issue, I think it still an issue that is
>> worth fixing and perhaps prevent similar issues in the future.
>>
>> First time I got bitten was because of local imports shadowing local
>> symbols without error or at least a warning.
>>
>> auto stuff(string text) {
>>    import std.conv;
>>
>>    foreach(ch; text.byDchar) {
>>    }
>> }
>
> https://issues.dlang.org/show_bug.cgi?id=10378
>
> Kenji has a pull for this, let's hope it goes through.
>
>
> T
>

Of course it is better than the status quo, but if it does, the bug 
report should stay open, and/or a few new ones should be filed. The pull 
ignores the discussion about what would be a good design and implements 
the rather awkward semantics that are quickest to hack into the compiler 
instead.

(Continue reading)

Meta via Digitalmars-d | 31 Aug 19:19 2015

Has anyone every successfully built a cross-compiler for the Nintendo DS?

I seem to remember that at one point somebody was working on 
compiling D to run on the Nintendo DS, but I can't find mention 
anywhere of it now. Did someone actually manage to get this 
working or am I just imagining things?

via Digitalmars-d | 31 Aug 19:03 2015

Re: Phobos' std.conv.text functions

On Monday, 31 August 2015 at 15:39:10 UTC, H. S. Teoh wrote:
> On Mon, Aug 31, 2015 at 03:15:07PM +0000, via Digitalmars-d 
> wrote:
>> I have been bitten by the std.conv.text family of functions 
>> twice now and while it's not a major issue, I think it still 
>> an issue that is worth fixing and perhaps prevent similar 
>> issues in the future.
>> 
>> First time I got bitten was because of local imports shadowing 
>> local symbols without error or at least a warning.
>> 
>> auto stuff(string text) {
>>   import std.conv;
>> 
>>   foreach(ch; text.byDchar) {
>>   }
>> }
>
> https://issues.dlang.org/show_bug.cgi?id=10378
>
> Kenji has a pull for this, let's hope it goes through.
>
>
> T

Great! This PR seems to only fix the local import shadowing bug, 
though.

via Digitalmars-d | 31 Aug 17:15 2015

Phobos' std.conv.text functions

I have been bitten by the std.conv.text family of functions twice 
now and while it's not a major issue, I think it still an issue 
that is worth fixing and perhaps prevent similar issues in the 
future.

First time I got bitten was because of local imports shadowing 
local symbols without error or at least a warning.

auto stuff(string text) {
   import std.conv;

   foreach(ch; text.byDchar) {
   }
}

Nowadays I always do selective imports, but sometimes for longer 
functions, this is sort of impractical. I think it's very 
error-prone for imports to override local symbols, but that's 
another issue.

Second time was similar but related to code morphing. I was 
developing some code that had a local variable called dtext. I 
later removed that symbol, but because there is a dtext function, 
it basically compiled fine. The problem took longer to find 
because I didn't know such family of functions even existed, so I 
was scratching my head lice for a while...

auto stuff(string x) {
   //auto dtext = x.toUTF32; // this got removed

(Continue reading)

Joakim via Digitalmars-d | 31 Aug 10:31 2015

Vision

I just stumbled across this recent Rust blog post where they laid 
out their vision for the rest of the year, thought it was very 
well done, strategic and specific:

http://blog.rust-lang.org/2015/08/14/Next-year.html

D really needs something like that: I'm hoping the next vision 
statement will at least move in that direction, ie more concrete. 
  I've been asking for a list of priorities from the core team, 
say a list of bugzilla issues that they think are important, but 
at least higher-level specifics like that would be useful.  It 
might help to reach out to more of the core team to write the 
next one, as Walter and Andrei may not be keeping track of all 
the initiatives that are underway.  I realize D development is 
likely more unplanned, but no reason we can't collect some common 
medium-term goals in one place.

The recent use of trello for short-term planning appears to have 
been a great move:

https://trello.com/b/XoFjxiqG/active

Thanks to Martin and others who spearheaded that effort.

Enamex via Digitalmars-d | 31 Aug 09:38 2015

Dazz new description for D

Some posters on reddit remarked that D's sales pitch on the 
website is unnecessarily long and unindicative.

I'm only making a suggestion; suggest others or comment on this 
one:

D is a multiparadigm systems programming language with excellent 
static introspection that lets you choose exactly what to pay 
for. <optional>D is a joy to write and easy to maintain: it's 
systems scripting with native performance.</optional>

Turned out too long :/

Daniel N via Digitalmars-d | 30 Aug 18:31 2015

declarations as template parameters

Frequently when trying to implement missing language-features in 
the library, it grinds to a halt because it's not possible to 
send declarations as template parameters.

i.e. ex!(int i);

Phobos solved this in a for me very undesirable way, ex:
   mixin(bitfields!(uint, "x", 1));
It no longer looks like a D-style declaration.

The obvious alternative is using strings and while I personally 
actually prefer that to the multiple parameters approach, I know 
a number of people who are vocally opposed to forcing library 
end-users to deal with string-based api:s and they do have a 
point, if only there was a better alternative?

ex!(int, "i"); // oh ze horror!
ex!q{int i};   // at least it now looks like a declaration again.

In before someone says: "Bikeshedding!"

Yes, it's just a few chars, but there's also a bigger difference, 
type-safety, good error messages and you don't really want to 
start parsing 'D' for something this trivial, every-time there is 
a new feature you have to update your little parser, etc. Well, I 
guess you could mixin the string as a declaration and then 
reflect over it... maybe it's the best way, didn't try that 
approach yet.

I did come up with a new(?) way though... as all the other 
(Continue reading)

Dicebot via Digitalmars-d | 30 Aug 16:08 2015

Possible solution for export : `unittest export`?

Follow-up to old 
http://forum.dlang.org/thread/m9lhc3$1r1v$1 <at> digitalmars.com 
thread by Benjamin

Short reminder of the issue:

Currently unsolved issue with finishing `export` implementation 
is lack of convenient semantics for its interaction with 
templates. If template function is marked as `export`, its 
non-template dependencies (called functions) will also need to be 
marked as effectively export (even if private) to be put in 
object file and avoid linker errors.

Which is impossible to do automatically because dependencies 
can't be figured out without instantiaton. And to do it manually 
you'd need to mark all dependencies with `export` too which is 
impossible without making them also public because currently 
`export` is defined as protection attribute. One of Benjamin 
proposals was to split it as a separate attribute kind but doing 
all manual annotation would still be hardly convenient / 
maintainable.

Proposal essentials:

Define `unittest export { /* tests here */ }` which will verify 
that all directly used symbols from same module/package are 
marked as export and automatically mark dependencies for 
placement into object files while doing semantic phase for tested 
instances.

(Continue reading)


Gmane