What is the D plan's to become a used language?

Joakim via Digitalmars-d digitalmars-d at puremagic.com
Wed Jan 14 22:37:49 PST 2015


On Thursday, 15 January 2015 at 03:19:10 UTC, brian wrote:
> On Wednesday, 14 January 2015 at 05:10:05 UTC, Joakim wrote:
>> I don't think it's that unusual for a native compiled 
>> language: can you find C++ snippets to write tweets?  I doubt 
>> it.  A compiled languages is just not the tool people usually 
>> grab to write such things.
>
> Pardon my naivity, but I don't know why I *wouldn't* want to do 
> this in D? I want something to pull tweets, analyse them 
> quickly and produce results. And then I graph it in something 
> else. Isn't this what this language would be *really* good at, 
> as it provides efficiency with minimal coding?

You originally talked about _writing_ tweets by using a D tool, 
not pulling and analyzing them as you do now, which is usually 
what people use a native language for.  For writing tweets, 
tossing off something in a scripting language is usually much 
quicker and easier, as you see with all the perl/python/php/ruby 
libraries listed in the official Twitter libraries link Ola 
provided above.

However, D could be used for both writing and analyzing, and if 
you look on dub, you'll see two libraries that advertise twitter 
support:

http://code.dlang.org/packages/twitter4d
http://code.dlang.org/packages/graphite

>> D would like to be good at all these things, and some of them 
>> are enabled on dub.  But as a newer language with a smaller 
>> community than Java, obviously the amount of APIs covered is 
>> going to be less right now.
>
> I'd love to help it on this journey, with my limited knowledge. 
> Where can I start?

Simple, write the kinds of libraries or API wrappers you'd like 
to use.

>> This is the normal chicken-or-egg problem with a new language 
>> like D, ie people want libraries or API wrappers to get their 
>> job done easier but if they don't spend time writing them, 
>> they never get done.
>
> Agreed. But if I'm looking to use an API library and their 
> isn't one there, writing a new library entirely isn't exactly a 
> trivial task.

It doesn't have to be a new library.  It could just be a D 
wrapper for an existing C library, because D provides for 
wrapping C easily.  I ran the automated C->D header translation 
tool dstep and modified the output a little to provide a D 
wrapper for the native Android C APIs:

https://github.com/jacob-carlborg/dstep
https://github.com/joakim-noah/android

>> Also, maybe the D community doesn't put their code up for 
>> public consumption as much as some other language communities.
>
> This is my belief and main point.

Tough to say.

>> I don't doubt that these issues exist, I just consider them 
>> normal for a newer language.
>>
>> As for recommending D, I think it depends on the type of user.
>>  If they care at all about efficiency, I don't know that I'd 
>> recommend a language other than D.  If they don't really care 
>> how fast their code runs and prefer to stay at a higher 
>> scripting level, then the advantages of D fade compared to 
>> other languages.
>
> Yes the language is efficient but what's the point in having 
> efficient code if I don't know how to get it to do what I want?

Generally, the kind of people who write efficient code don't mind 
writing and figuring out such stuff themselves, without relying 
on existing code examples.

> While I'm not sure if you agree or disagree with me, I think 
> you also clarify what I was trying to say.
>
> My point wasn't that there aren't ways to do things in D.
> My point was that there are fewer examples of *how* to do 
> things in D.
> This will discourage the new user, which will prevent it 
> becoming a more popular language.
> So if I'm looking for a new language to use, I'd probably stick 
> to the ones that have more examples.

I agree that most users learn from examples, so to the extent D 
is missing those, it will not get as many users.  But any new 
language without corporate support has this problem, as language 
users generally don't bother taking the time to slap all their 
support code and examples online.

dub has been an effort to remedy that, and taking your twitter 
example, appears to have worked, based on the two links I found.  
Obviously, D still has a ways to go to reach ruby or Java levels 
of example/library availability.


More information about the Digitalmars-d mailing list