www.digitalmars.com         C & C++   DMDScript  

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

reply "bioinfornatics" <bioinfornatics fedoraproject.org> writes:
Dear,

My topic is a kick in the anthill. I hope this will help D to 
think on his problems.

D exist since 1999, if we look behind, what is done?
We have :
- a huge cemetery of D project
- no D killer application
- miss the goal what to do to improve D experience
- each new D release your application is broken and often with
some D compiler bugs
With around 15 years of works we are at same state as the
beginning.
What to do:
   - Stop to add new feature in D (new annotation or whatever is
not an urgent needs)
   - Get a compiler and a language stable
   - When this is done work on some free (libre) framework in some
specific fields
      * grid computing (sub-field: data-computing)
      * web-server
      * graphics computing (sub-field: gui )
And not more, not to disperse …


 From the beginning D had a bad start (1999-200X):
- dmd compiler was not totally open.
- we got a fight on standard library phobos - tango
With this language started to get a bad publicity
- d2 is come with a new syntax which kill lot of project: -> 
http://www.dsource.org/
survivor are: phobos: derelict, gtkd all others are dead

We get for years deprecated module: xml, json, mmfile

When we introduce a new feature we release it with a partial use:
-  safe often is not used as is not yet implemented into phobos
- range even the basic io as ByLine which implement range can't 
work with std.range.takeOne as is not an Input Range. While a 
basic function such as takeOne do not really need to use save 
method to work a forward range is enough.

So we adding feature and going forward without consolidate the 
previous works.
That is like you give to a children a gift, barely opened you 
give another gift.

Currently D project are:
- not open project to make money (no code shared)
- personal code ( which fit only one point of view )

Really I hope to see D3 with a clean model and a stable language. 
Do not release it as a toy like was done for D1 and D2.
Release D3 with much ah possible no compiler bug and a well 
implemented standard library. We have get enough experience to do 
it.


Why we do not create a useful D programming environment as is 
done is java, python, ruby.
Dec 18 2014
next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 19/12/2014 1:38 a.m., bioinfornatics wrote:

 Dear,

 My topic is a kick in the anthill. I hope this will help D to think on
 his problems.

 D exist since 1999, if we look behind, what is done?
 We have :
 - a huge cemetery of D project
 - no D killer application
 - miss the goal what to do to improve D experience
 - each new D release your application is broken and often with
 some D compiler bugs
 With around 15 years of works we are at same state as the
 beginning.
 What to do:
    - Stop to add new feature in D (new annotation or whatever is
 not an urgent needs)
    - Get a compiler and a language stable
    - When this is done work on some free (libre) framework in some
 specific fields
       * grid computing (sub-field: data-computing)
       * web-server
       * graphics computing (sub-field: gui )
 And not more, not to disperse …


  From the beginning D had a bad start (1999-200X):
 - dmd compiler was not totally open.
 - we got a fight on standard library phobos - tango
 With this language started to get a bad publicity
 - d2 is come with a new syntax which kill lot of project: ->
 http://www.dsource.org/
 survivor are: phobos: derelict, gtkd all others are dead

 We get for years deprecated module: xml, json, mmfile

 When we introduce a new feature we release it with a partial use:
 -  safe often is not used as is not yet implemented into phobos
 - range even the basic io as ByLine which implement range can't work
 with std.range.takeOne as is not an Input Range. While a basic function
 such as takeOne do not really need to use save method to work a forward
 range is enough.

 So we adding feature and going forward without consolidate the previous
 works.
 That is like you give to a children a gift, barely opened you give
 another gift.

 Currently D project are:
 - not open project to make money (no code shared)
 - personal code ( which fit only one point of view )

 Really I hope to see D3 with a clean model and a stable language. Do not
 release it as a toy like was done for D1 and D2.
 Release D3 with much ah possible no compiler bug and a well implemented
 standard library. We have get enough experience to do it.


 Why we do not create a useful D programming environment as is done is
 java, python, ruby.


I'm in agreement that we need to start freezing the language.
E.g. in the next 6 months we will get x done. And no new features other 
then those chosen will be added.

One thing I will say without going full raging, we as a community need 
to work together for scoping of reusable projects that we all can agree to.
By scoping down significantly we won't have massive big code bases that 
are both a library and framework for a number of uses all rolled into one.
We have dub, which has sub packages its not acceptable to not do this.

D as a language is easy to sell to an education institute as a first 
language. I've done it.
Now we really should focus on getting started and cook book related 
tutorials on the main site.
Ali's book is amazing, but we also need to get e.g. ApplyYourDLang or 
something along those lines properly going and having them both combined 
as part of the main site. Maybe even with a nice big flashy banner at 
the top of the page saying go there to get started.
Dec 18 2014
next sibling parent reply "bioinfornatics" <bioinfornatics fedoraproject.org> writes:
about Dub, I have another view.
This build system was created for end user to get a missing 
library when they want their killer application. As is done with 
PyPI or gem.
Dub to me is not a builder for developer and even less for an OS. 
dub install software in home user "a la" windows style. I prefer 
to use makefile at least with it I can to write a clean builder 
with respect of standard OS specification. For this I tool 
makefile template from makefileForD hosted on github.
But we have already give a lot of talk on this, so we could 
discuss on it into a separate thread.
Dec 18 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 18 December 2014 at 13:16:11 UTC, bioinfornatics 
wrote:

 about Dub, I have another view.
 This build system was created for end user to get a missing 
 library when they want their killer application. As is done 
 with PyPI or gem.


Build system is never for end users but always for developers. 
Dub is 100% superior to gems/pip because it decoupled application 
dependencies and development dependencies. End user gets 
applications built with dub and sees no traces of it, neither he 
needs to be aware of any of code.dlang.org packages - this is the 
huge benefit of compiled languages and specifically dub.

Contrary to that gem/pip force me to install loads of stuff that 
is not handled by system package manager and does not 
inter-operate with the rest of the OS. It sucks, though somewhat 
inevitable by design of interpreted languages.


 Dub to me is not a builder for developer and even less for an 
 OS. dub install software in home user "a la" windows style.


Bullshit. No, BULLSHIT.

Users should never see dub or even know of its existence. It is 
only for developers and packagers. Stop considering developers 
users and you will be good.
Dec 18 2014
parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 18 December 2014 at 14:52:27 UTC, Dicebot wrote:

 [...]


Stop reading my mind !
Dec 18 2014
prev sibling next sibling parent reply Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 18/12/14 14:07, Rikki Cattermole via Digitalmars-d wrote:

 I'm in agreement that we need to start freezing the language.
 E.g. in the next 6 months we will get x done. And no new features other then
 those chosen will be added.


IMHO, it's important to demarcate well what is considered "done", but also to 
enthusiastically embrace breaking changes that improve the performance and 
reliability of the language.

Well-defined and well-kept promises for what is stable, what is in development, 
and what is in the roadmap, matter more than just freezing things.  The fact 
that "problem X will never be fixed because of backwards compatibility" can be 
just as demotivating to uptake (if not more so) than "feature Y may change in 
the next release".
Dec 18 2014
parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 19/12/2014 10:22 a.m., Joseph Rushton Wakeling via Digitalmars-d wrote:

 On 18/12/14 14:07, Rikki Cattermole via Digitalmars-d wrote:

 I'm in agreement that we need to start freezing the language.
 E.g. in the next 6 months we will get x done. And no new features
 other then
 those chosen will be added.


 IMHO, it's important to demarcate well what is considered "done", but
 also to enthusiastically embrace breaking changes that improve the
 performance and reliability of the language.

 Well-defined and well-kept promises for what is stable, what is in
 development, and what is in the roadmap, matter more than just freezing
 things.  The fact that "problem X will never be fixed because of
 backwards compatibility" can be just as demotivating to uptake (if not
 more so) than "feature Y may change in the next release".


Basically you wrote exactly what I meant :)
Dec 18 2014
prev sibling parent reply "Vic" <vic apakau.com> writes:
<snip>> We have :

 - a huge cemetery of D project




+ 1

 What to do:
   - Stop to add new feature in D (new annotation or whatever is
 not an urgent needs)




+1000.

But this is not the culture of the creators. They think adding 
features is fun.

Vic
blog.apakau.com - company built on top of D in Silicon Valley

<snip>
Dec 18 2014
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 18 December 2014 at 21:39:49 UTC, Vic wrote:

 <snip>> We have :

 - a huge cemetery of D project




 + 1

 What to do:
  - Stop to add new feature in D (new annotation or whatever is
 not an urgent needs)




 +1000.

 But this is not the culture of the creators. They think adding 
 features is fun.

 Vic
 blog.apakau.com - company built on top of D in Silicon Valley

 <snip>


We need adding/chaging features because existing ones are not 
good enough for long term production usage. And yes, this is 
opinion from existing production user.
Dec 18 2014
parent "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
On Friday, 19 December 2014 at 07:39:25 UTC, Dicebot wrote:

 On Thursday, 18 December 2014 at 21:39:49 UTC, Vic wrote:

 <snip>> We have :

 - a huge cemetery of D project




 + 1

 What to do:
 - Stop to add new feature in D (new annotation or whatever is
 not an urgent needs)




 +1000.

 But this is not the culture of the creators. They think adding 
 features is fun.

 Vic
 blog.apakau.com - company built on top of D in Silicon Valley

 <snip>


 We need adding/chaging features because existing ones are not 
 good enough for long term production usage. And yes, this is 
 opinion from existing production user.


+1 from another production user.
Dec 19 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/18/2014 1:39 PM, Vic wrote:

 But this is not the culture of the creators. They think adding features is fun.


I spent most of my time saying "no" to new features and trying to find ways to 
support things without adding features.
Dec 19 2014
parent reply "Joakim" <dlang joakim.fea.st> writes:
On Friday, 19 December 2014 at 10:04:34 UTC, Walter Bright wrote:

 On 12/18/2014 1:39 PM, Vic wrote:

 But this is not the culture of the creators. They think adding 
 features is fun.


 I spent most of my time saying "no" to new features and trying 
 to find ways to support things without adding features.


I think his point is that you haven't said "no" enough. ;) A 
tough job, but then BDFL doesn't come without its pains.
Dec 19 2014
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On 12/19/2014 8:39 PM, Joakim wrote:

 I think his point is that you haven't said "no" enough. ;)


Which obviously comes from a lack of any historical reference. If Vic 
had been around this community longer than he actually has, he never 
would have made such a remark. Walter's nickname should be Dr. No.
Dec 19 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 19 December 2014 at 13:15:21 UTC, Mike Parker wrote:

 Which obviously comes from a lack of any historical reference. 
 If Vic had been around this community longer than he actually 
 has, he never would have made such a remark. Walter's nickname 
 should be Dr. No.


Well, the point is not that one should say "no", but assign 
priorities (and degree of certainty) to 
features/enhancements/fixes and attach them to milestones that 
gives a predictable path to a series of stable release.

So, "no" is not a good answer, but "not for release X, if this 
goes in it should be designed along with feature Y which is 
planned for release Z" is an answer that might encourage people 
to create a proof-of-concept-prototype without expecting it to go 
in right away.
Dec 19 2014
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Friday, 19 December 2014 at 11:39:08 UTC, Joakim wrote:

 On Friday, 19 December 2014 at 10:04:34 UTC, Walter Bright 
 wrote:

 On 12/18/2014 1:39 PM, Vic wrote:

 But this is not the culture of the creators. They think 
 adding features is fun.


 I spent most of my time saying "no" to new features and trying 
 to find ways to support things without adding features.


 I think his point is that you haven't said "no" enough. ;) A 
 tough job, but then BDFL doesn't come without its pains.


I don't think the problem is saying no here.

The problem is that many feature are incomplete or have holes or 
are not orthogonal to each others. Let me take 2 simple examples :
  - type qualifiers are transitive. Except for delegate's context.
  - There is no implicit sharing. Except via delegate (because of 
the above mentioned point), exceptions and promotion of pure 
function's result.

The problem with having these holes, is that you can't rely on 
anything. That makes it very hard to write reliable library, or 
to add new features as you get a myriad of special cases all over 
the place.

Sometime, fixing these holes require adding new feature, or 
extending a bit existing ones. That is fine as this new thing 
will allow for closure of what is already open. This is a 
beneficial addition and saying no would be a step back.

In other situations, adding new feature simply extends the 
language and create new specials cases. In which case, no or 
later is the appropriate answer at this point.
Dec 19 2014
parent reply "Joakim" <dlang joakim.fea.st> writes:
On Friday, 19 December 2014 at 14:03:06 UTC, deadalnix wrote:

 On Friday, 19 December 2014 at 11:39:08 UTC, Joakim wrote:

 On Friday, 19 December 2014 at 10:04:34 UTC, Walter Bright 
 wrote:

 On 12/18/2014 1:39 PM, Vic wrote:

 But this is not the culture of the creators. They think 
 adding features is fun.


 I spent most of my time saying "no" to new features and 
 trying to find ways to support things without adding features.


 I think his point is that you haven't said "no" enough. ;) A 
 tough job, but then BDFL doesn't come without its pains.


 I don't think the problem is saying no here.

 The problem is that many feature are incomplete or have holes 
 or are not orthogonal to each others. Let me take 2 simple 
 examples :
  - type qualifiers are transitive. Except for delegate's 
 context.
  - There is no implicit sharing. Except via delegate (because 
 of the above mentioned point), exceptions and promotion of pure 
 function's result.

 The problem with having these holes, is that you can't rely on 
 anything. That makes it very hard to write reliable library, or 
 to add new features as you get a myriad of special cases all 
 over the place.

 Sometime, fixing these holes require adding new feature, or 
 extending a bit existing ones. That is fine as this new thing 
 will allow for closure of what is already open. This is a 
 beneficial addition and saying no would be a step back.

 In other situations, adding new feature simply extends the 
 language and create new specials cases. In which case, no or 
 later is the appropriate answer at this point.


While implementation quality of all these features is no doubt a 
big part of the problem, my guess, based on Vic's previous post 
about stripping down the language to a stable core, is that he'd 
prefer if some subset of D's features were put off or ditched 
altogether.  Of course, that ties into the fact that the more 
features you have, the less time you have to polish them and make 
sure each feature interacts well with everything else, 
particularly given D's small core team.

As for Walter already saying "no" a lot, given how many features 
D has, obviously one can still wish he went from 99% "no" to 
99.5%. ;)  You don't need to be around the D community forever to 
feel that D still has too many features that made it in.
Dec 19 2014
parent reply "Tobias Pankrath" <tobias pankrath.net> writes:
 As for Walter already saying "no" a lot, given how many 
 features D has, obviously one can still wish he went from 99% 
 "no" to 99.5%. ;)  You don't need to be around the D community 
 forever to feel that D still has too many features that made it 
 in.


Care to name a few and justify why exactly those features should 
be gone?
Dec 19 2014
next sibling parent reply "Joakim" <dlang joakim.fea.st> writes:
On Friday, 19 December 2014 at 14:38:02 UTC, Tobias Pankrath 
wrote:

 As for Walter already saying "no" a lot, given how many 
 features D has, obviously one can still wish he went from 99% 
 "no" to 99.5%. ;)  You don't need to be around the D community 
 forever to feel that D still has too many features that made 
 it in.


 Care to name a few and justify why exactly those features 
 should be gone?


No, as that's not really my problem.  I was simply trying to 
clarify the argument others have made, that the language seems 
overstuffed and overwhelming, which I have experienced at times 
but I'm not personally complaining about.

To Walter, the language may feel like it consists of a small, 
well-chosen set of features, given the many others he's nixed 
over the years.  But to others coming to D from even smaller or 
less well-thought out languages, even that set may seem too big 
and overwhelming to navigate.  Certainly, they may feel that it 
would be better to focus on honing less features, rather than 
adding more half-baked but potentially good ones, however nice 
they'd be to have.
Dec 19 2014
parent reply "Tobias Pankrath" <tobias pankrath.net> writes:
On Friday, 19 December 2014 at 14:58:07 UTC, Joakim wrote:

 On Friday, 19 December 2014 at 14:38:02 UTC, Tobias Pankrath 
 wrote:

 As for Walter already saying "no" a lot, given how many 
 features D has, obviously one can still wish he went from 99% 
 "no" to 99.5%. ;)  You don't need to be around the D 
 community forever to feel that D still has too many features 
 that made it in.


 Care to name a few and justify why exactly those features 
 should be gone?


 No, as that's not really my problem.  I was simply trying to 
 clarify the argument others have made, that the language seems 
 overstuffed and overwhelming, which I have experienced at times 
 but I'm not personally complaining about.>


It is a worthless claim to make that there is too much of 
something, if you cannot come up with an concrete example. "I've 
got that gut feeling, that" is not even remotely an argument and 
just kills time of everyone in this discussion.

If we want to discuss the future of the language, it's totally 
pointless to do it in an abstract way. “We need to make the 
language more stable“ is not a goal or something, it is totally 
unclear what that actually means, why this is important in the 
first place, how we can say that we have accomplished it or what 
we need to do to realise that goal.
Dec 19 2014
next sibling parent reply "Joakim" <dlang joakim.airpost.net> writes:
On Friday, 19 December 2014 at 15:11:30 UTC, Tobias Pankrath 
wrote:

 On Friday, 19 December 2014 at 14:58:07 UTC, Joakim wrote:

 On Friday, 19 December 2014 at 14:38:02 UTC, Tobias Pankrath 
 wrote:

 As for Walter already saying "no" a lot, given how many 
 features D has, obviously one can still wish he went from 
 99% "no" to 99.5%. ;)  You don't need to be around the D 
 community forever to feel that D still has too many features 
 that made it in.


 Care to name a few and justify why exactly those features 
 should be gone?


 No, as that's not really my problem.  I was simply trying to 
 clarify the argument others have made, that the language seems 
 overstuffed and overwhelming, which I have experienced at 
 times but I'm not personally complaining about.>


 It is a worthless claim to make that there is too much of 
 something, if you cannot come up with an concrete example. 
 "I've got that gut feeling, that" is not even remotely an 
 argument and just kills time of everyone in this discussion.

 If we want to discuss the future of the language, it's totally 
 pointless to do it in an abstract way. “We need to make the 
 language more stable“ is not a goal or something, it is totally 
 unclear what that actually means, why this is important in the 
 first place, how we can say that we have accomplished it or 
 what we need to do to realise that goal.


I have no dog in this fight.  I was merely pointing out to Walter 
and Mike that it's possible to say "no" a lot and still have 
others wish you had said "no" even more. :) There's no particular 
feature that I wish wasn't there, though of course there are many 
features that many wish were implemented or worked together 
better, as deadalnix points out.

When Vic suggested a split into a stable core and an experimental 
layer, I suggested documenting the perceived stability of various 
features instead, so that users could have a guide for what 
features might be more problematic without having to do a 
deep-dive in bugzilla to figure it out for themselves.  I didn't 
back a split or have not suggested removing features.
Dec 19 2014
parent reply "Vic" <vic apakau.com> writes:
First, thank you all the committers for a 'gifted free' lang that 
we use to build a company, we could have used any lang, we chose 
D.

My point is on 'management' more than on 'software'. On 
management, *EVERY* project is resource constrained, so imo, D 
should figure out what resources it has at hand. Based on that 
prioritize what can be maintained and what can't be maintained 
and hence marked as deprecated (so those that do care for it can 
move it downstream). It's painful to kill many scared cows. I 
used example or CLR and JRE team size relative to their 'features 
surface area'.

Also, I'm pleased that 'no' is said at times (but ... we are 
still adding things right, w/o saying: and if we add that, what 
are 2 features we can move downstream?'. Last I'm hearing is 
Andreii will gift C++ compatibility, etc into core. **: reason to 
split up forum into users and public comitters so people like me 
don't panic)
Cheers,
Vic
ps:
Second smaller thing I 'elude' to but don't verbalize in that 
argument is my personal preference for a smaller language. Less 
is better/faster. I proposed to move those deprecated  features 
'downstream', just like Linux Kernel and Linux GNU are separated 
(but can't exist w/o each other). To build an eco system.
(here is comments on C++ having more features, one of the reasons 
I like smaller
http://harmful.cat-v.org/software/c++/linus
I do see 'featuritis' http://bit.ly/1wzVPMR as a way to doom 
projects in a compound way )

As to Walter (yes I used Wacom c compiler) saying No, I think he 
is to nice and 99.5% is not good enough, I'd like him to be a mean
- http://www.brainyquote.com/quotes/quotes/l/linustorva141511.html
and start removing things. The list of candidates is long, GC has 
been brought up as something that can be moved downstream.
D could have reference counters in base classes, but end users 
could INJECT a 3rd party GC mechanism they like. It's same thing, 
but downstream. Also I showed example of Go exceptions being 
downstream.
I'm not saying these 2 (our of 100) are not nice features, I'm 
saying if 'we' were forced, they could be moved downstream. You 
can just open Andreii's D book table of contents and find over 
weight things - if you are motivated to do that.


On Friday, 19 December 2014 at 16:44:59 UTC, Joakim wrote:

 On Friday, 19 December 2014 at 15:11:30 UTC, Tobias Pankrath 
 wrote:

 On Friday, 19 December 2014 at 14:58:07 UTC, Joakim wrote:

 On Friday, 19 December 2014 at 14:38:02 UTC, Tobias Pankrath 
 wrote:

 As for Walter already saying "no" a lot, given how many 
 features D has, obviously one can still wish he went from 
 99% "no" to 99.5%. ;)  You don't need to be around the D 
 community forever to feel that D still has too many 
 features that made it in.


 Care to name a few and justify why exactly those features 
 should be gone?


 No, as that's not really my problem.  I was simply trying to 
 clarify the argument others have made, that the language 
 seems overstuffed and overwhelming, which I have experienced 
 at times but I'm not personally complaining about.>


 It is a worthless claim to make that there is too much of 
 something, if you cannot come up with an concrete example. 
 "I've got that gut feeling, that" is not even remotely an 
 argument and just kills time of everyone in this discussion.

 If we want to discuss the future of the language, it's totally 
 pointless to do it in an abstract way. “We need to make the 
 language more stable“ is not a goal or something, it is 
 totally unclear what that actually means, why this is 
 important in the first place, how we can say that we have 
 accomplished it or what we need to do to realise that goal.


 I have no dog in this fight.  I was merely pointing out to 
 Walter and Mike that it's possible to say "no" a lot and still 
 have others wish you had said "no" even more. :) There's no 
 particular feature that I wish wasn't there, though of course 
 there are many features that many wish were implemented or 
 worked together better, as deadalnix points out.

 When Vic suggested a split into a stable core and an 
 experimental layer, I suggested documenting the perceived 
 stability of various features instead, so that users could have 
 a guide for what features might be more problematic without 
 having to do a deep-dive in bugzilla to figure it out for 
 themselves.  I didn't back a split or have not suggested 
 removing features.
Dec 20 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Saturday, 20 December 2014 at 19:11:53 UTC, Vic wrote:

 Second smaller thing I 'elude' to but don't verbalize in that 
 argument is my personal preference for a smaller language. Less 
 is better/faster.


I think this is the main reason why we have different perspective 
on necessity of change. Smaller language simply means that you 
need to put more complexity into actual applications and while D 
looks all cool at the first glance trying to get deeper (== 
implement BIG projects) inevitably makes you encounter 
fundamental design quirks that affect maintenance costs. Deadlnix 
has provided pretty good list of suck problematic points.

While there is some value in splitting the spec into core 
language and extensions I don't believe it is wise for D to 
compete in simplicity domain.
Dec 21 2014
parent reply "Vic" <vic apakau.com> writes:
I think you nailed the argument.

On Sunday, 21 December 2014 at 09:36:00 UTC, Dicebot wrote:

 On Saturday, 20 December 2014 at 19:11:53 UTC, Vic wrote:

 Second smaller thing I 'elude' to but don't verbalize in that 
 argument is my personal preference for a smaller language. 
 Less is better/faster.


 I think this is the main reason why we have different 
 perspective on necessity of change. Smaller language simply 
 means that you need to put more complexity into actual 
 applications and while D looks all cool at the first glance 
 trying to get deeper (== implement BIG projects) inevitably 
 makes you encounter fundamental design quirks that affect 
 maintenance costs. Deadlnix has provided pretty good list of 
 suck problematic points.

 While there is some value in splitting the spec into core 
 language and extensions I don't believe it is wise for D to 
 compete in simplicity domain.


Core and extensions/ plugins is a way to manage complexity and 
resources. I cite some 'random dude' 
http://www.codingninja.co.uk/best-programmers-quotes :
"Controlling complexity is the essence of computer programming."

I am a user of D, and I need something stable to lean on - if I 
don't know the bug is what I wrote or what the compiler wrote, it 
gets harder.

Further D does not have choice but to be excellent (via 
simplicity) - there is not enough paid maintainers. (Struts what 
I worked w/ before was written in 48 hours and had several 
million 'users/developers' using it). So the pain of limited 
resources forces excellence.

D does not have a choice but to make GC a DI/IOC - it will happen 
as the only choice, popular or not. People can be upset about the 
sacred cow or be confident of the outcome. I am in the second 
case.
Alternative is death and I am optimist the committers will be 
forced to trim down.

Vic
Dec 21 2014
parent reply "ZombineDev" <valid_email he.re> writes:
NO. Just don't use features that you don't understand or like, but
don't punish happy D users by demanding a crippled D version.


On Sunday, 21 December 2014 at 22:21:21 UTC, Vic wrote:

 ...
Dec 21 2014
next sibling parent "Vic" <vic apakau.com> writes:
I assume in order for your company to be happy in using D, you'd 
want it work, right? That is all I'm saying as well, lots of git 
examples and commercial projects using D.
And I'm not saying to remove *any* features at all. I'm saying 
*MOVE* some features, tbd. For example Linux has Kernal and GNU, 
who cares where in git they sit, right? (but GNU needs a working 
Kernal).

The example I linked(do you have it?) is like a more 
modern/younger language GO has exceptions. Or w/ GC, DI/IOC a 
'generic' GC that makes you happy. But it does not make you sad 
to have an eco system, right?

Anyway, you have to hear maintainers start saying/doing things to 
make things more maintainable before you can worry, since I am 
not a committer my opinions ads up to 0 basically in open source 
world. (if I was, I'd fork it until 'CW' catches up and backports 
it).

Vic


On Monday, 22 December 2014 at 01:08:00 UTC, ZombineDev wrote:

 NO. Just don't use features that you don't understand or like, 
 but
 don't punish happy D users by demanding a crippled D version.


 On Sunday, 21 December 2014 at 22:21:21 UTC, Vic wrote:

 ...
Dec 21 2014
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 22 December 2014 at 01:08:00 UTC, ZombineDev wrote:

 NO. Just don't use features that you don't understand or like, 
 but
 don't punish happy D users by demanding a crippled D version.


 On Sunday, 21 December 2014 at 22:21:21 UTC, Vic wrote:

 ...




That is a valid argument if feature are orthogonal. When they 
aren't, it is just rhetorical bullshit.
Dec 22 2014
prev sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 19 December 2014 at 15:11:30 UTC, Tobias Pankrath 
wrote:

 If we want to discuss the future of the language, it's totally 
 pointless to do it in an abstract way. “We need to make the 
 language more stable“ is not a goal or something, it is totally 
 unclear what that actually means, why this is important in the 
 first place, how we can say that we have accomplished it or 
 what we need to do to realise that goal.


Yes, but it would be easy to define some focused goals for each 
release and refuse to touch stuff that belongs to a later 
release. E.g.

2.70-2.79:
- fix all problems related to private changes in libraries 
breaking application-code

2.80-2.89:
- focus on polishing support for applications that use GC and can 
take the collection hit

2.90-2.99:
- focus on polishing support for applications that are real time 
and don't use GC
- standard lib fully  nogc
- scope etc

3.0:
- breaking change: full clean up of syntax
- non-GC ownership model
- optional precise GC
- remove less important features: lazy, etc…

3.1:
- 3.0 update, supplements features in 3.0

3.2-3.3:
- faster compilation

3.4-3.5
- profiling guided optimization
- whole program optimization
Dec 19 2014
next sibling parent reply "Tobias Pankrath" <tobias pankrath.net> writes:
On Friday, 19 December 2014 at 16:45:40 UTC, Ola Fosheim Grøstad 
wrote:

 On Friday, 19 December 2014 at 15:11:30 UTC, Tobias Pankrath 
 wrote:

 If we want to discuss the future of the language, it's totally 
 pointless to do it in an abstract way. “We need to make the 
 language more stable“ is not a goal or something, it is 
 totally unclear what that actually means, why this is 
 important in the first place, how we can say that we have 
 accomplished it or what we need to do to realise that goal.


 Yes, but it would be easy to define some focused goals for each 
 release and refuse to touch stuff that belongs to a later 
 release. E.g.

 2.70-2.79:
 - fix all problems related to private changes in libraries 
 breaking application-code

 2.80-2.89:
 - focus on polishing support for applications that use GC and 
 can take the collection hit

 2.90-2.99:
 - focus on polishing support for applications that are real 
 time and don't use GC
 - standard lib fully  nogc
 - scope etc

 3.0:
 - breaking change: full clean up of syntax
 - non-GC ownership model
 - optional precise GC
 - remove less important features: lazy, etc…

 3.1:
 - 3.0 update, supplements features in 3.0

 3.2-3.3:
 - faster compilation

 3.4-3.5
 - profiling guided optimization
 - whole program optimization


How would that improve the development process? Which problems 
that we currently face does that solve and why? I'm not trying to 
troll here.
Dec 19 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 19 December 2014 at 16:59:54 UTC, Tobias Pankrath 
wrote:

 How would that improve the development process? Which problems 
 that we currently face does that solve and why? I'm not trying 
 to troll here.


1. You can hit a stable release for a particular application area 
one by one: batch programming, server programming, realtime 
programming. That could increase commercial uptake because you 
hit the first stable (supported) release earlier.

2. You can defer decisions so that they happen in the right 
order, and still let people work on a solution 3 releases ahead 
know when their work will be evaluated.

3. You can assign different people with different expertise to 
coordinate a specific development area (like GC improvments).

4. You can make sure that design-problems that are interlinked 
are treated at the same time so you don't have to go "oh no, that 
won't work, because we added Y in another release".

5. You can break down the problems into smaller problems and line 
up milestones and dependencies.

6. You can defer all discussions that are truly breaking to a 
working-group focusing on a breaking 3.0 release.

etc.
Dec 19 2014
parent reply "Joakim" <dlang joakim.airpost.net> writes:
On Friday, 19 December 2014 at 17:14:57 UTC, Ola Fosheim Grøstad 
wrote:

 On Friday, 19 December 2014 at 16:59:54 UTC, Tobias Pankrath 
 wrote:

 How would that improve the development process? Which problems 
 that we currently face does that solve and why? I'm not trying 
 to troll here.


 1. You can hit a stable release for a particular application 
 area one by one: batch programming, server programming, 
 realtime programming. That could increase commercial uptake 
 because you hit the first stable (supported) release earlier.

 2. You can defer decisions so that they happen in the right 
 order, and still let people work on a solution 3 releases ahead 
 know when their work will be evaluated.

 3. You can assign different people with different expertise to 
 coordinate a specific development area (like GC improvments).

 4. You can make sure that design-problems that are interlinked 
 are treated at the same time so you don't have to go "oh no, 
 that won't work, because we added Y in another release".

 5. You can break down the problems into smaller problems and 
 line up milestones and dependencies.

 6. You can defer all discussions that are truly breaking to a 
 working-group focusing on a breaking 3.0 release.


Some decent suggestions for a company that has a certain game 
plan, but mostly useless for an open source project where every 
contributor has their own priorities.  The core team can only 
work on what they think is important and evaluate whether they 
want others' features or the quality of their pulls, whenever 
those are provided.  Think bazaar, not cathedral.

Now, you're right that the core team can do a better job of 
laying out their current priorities and of having an actual 
roadmap of where they'd like the project to go, but they can't 
really do anything to enforce this herd of cats to listen to them.
Dec 19 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 19 December 2014 at 18:58:11 UTC, Joakim wrote:

 contributor has their own priorities.  The core team can only 
 work on what they think is important and evaluate whether they 
 want others' features or the quality of their pulls, whenever 
 those are provided.  Think bazaar, not cathedral.


Bazaar has never worked for design. Linux was not designed, the 
design was already done with Unix. But even in Linux experimental 
features are not added over night. They are added when they have 
been proven mature. Where would Linux be today if they did not 
focus on stability?


 Now, you're right that the core team can do a better job of 
 laying out their current priorities and of having an actual 
 roadmap of where they'd like the project to go, but they can't 
 really do anything to enforce this herd of cats to listen to 
 them.


The goal is not to control what people do, but to sort out the 
dependencies and coordinate so that people can focus on the area 
they are interested in with an idea of when extensions could be 
added and what the missing pieces are.

It makes no commercial sense to invest with no plan for the next 
two releases and no time estimates,. That means you get 
contributors that do what they do because it is a hobby, or 
because it is educational, because they hope to be hired by a 
company that uses D today, or because some commercial backer 
"believes" in the project (in the emotional sense).

A company like Intel invests in LLVM and many other open source 
projects that supports their products… They probably would not if 
they had no idea when or if those projects would reach a stable 
production ready release.
Dec 19 2014
prev sibling next sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Ola Fosheim Grøstad" " wrote in message 
news:fjmtziqyopoyrpesznoz forum.dlang.org...


 Yes, but it would be easy to define some focused goals for each release 
 and refuse to touch stuff that belongs to a later release. E.g.


It would be easy to define such a list, but it would be near-impossible to 
force contributors to follow it.  Refusing to accept contributions outside 
the goals would most likely result in less contributions, not more focused 
contributions.
Dec 20 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Saturday, 20 December 2014 at 12:13:42 UTC, Daniel Murphy 
wrote:

 It would be easy to define such a list, but it would be 
 near-impossible to force contributors to follow it.


Hardly, you have to be specific and make the number of issues 
covered in the next release small enough to create a feeling of 
being within reach in a short time span. People who don't care 
about fixing current issues should join a working group focusing 
on long term efforts (such as new features, syntax changes etc).


 Refusing to accept contributions outside the goals would most 
 likely result in less contributions, not more focused 
 contributions.


That's good, people should not expect experimental features or 
unpolished implementations to be added to the next release. What 
goes into the next release should be decided on before you start 
on it.
Dec 20 2014
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Ola Fosheim Grøstad" " wrote in message 
news:aimenbdjdflzgkkteruk forum.dlang.org...


 Hardly, you have to be specific and make the number of issues covered in 
 the next release small enough to create a feeling of being within reach in 
 a short time span. People who don't care about fixing current issues 
 should join a working group focusing on long term efforts (such as new 
 features, syntax changes etc).


Saying it will work doesn't make it so.


 That's good, people should not expect experimental features or unpolished 
 implementations to be added to the next release. What goes into the next 
 release should be decided on before you start on it.


That's nice an all, but if you can't get developers to work on the features 
you've decided on then all you end up doing is indefinitely postponing other 
contributions.

I do agree that work should be polished before it is merged, but good luck 
convincing Walter to stop merging work-in-progress features into master. 
I've been on both sides of that argument and neither way is without 
drawbacks, with the current contributor energy we have available.
Dec 22 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 22 December 2014 at 08:22:35 UTC, Daniel Murphy wrote:

 "Ola Fosheim Grøstad" " wrote in message 
 news:aimenbdjdflzgkkteruk forum.dlang.org...


 Hardly, you have to be specific and make the number of issues 
 covered in the next release small enough to create a feeling 
 of being within reach in a short time span. People who don't 
 care about fixing current issues should join a working group 
 focusing on long term efforts (such as new features, syntax 
 changes etc).


 Saying it will work doesn't make it so.


You need a core team, the core team needs to be able to cooperate 
on the most important features for the greater good. Then you 
have outside contributors with special interests, perhaps even 
educational (like a master student) that could make great long 
term contributions if you established work groups headed by 
people who knew the topic well.

More importantly: it makes no business sense to invest in an open 
source project that shows clear signs of being mismanaged. Create 
a spec that has business value, manage the project well and 
people with a commercial interest will invest. Why would I 
contribute to the compiler if I see no hope of it ever reaching a 
stable release that is better than the alternatives from a 
commercial perspective?
Dec 22 2014
parent "Joakim" <dlang joakim.fea.st> writes:
On Monday, 22 December 2014 at 10:30:47 UTC, Ola Fosheim Grøstad 
wrote:

 More importantly: it makes no business sense to invest in an 
 open source project that shows clear signs of being mismanaged. 
 Create a spec that has business value, manage the project well 
 and people with a commercial interest will invest. Why would I 
 contribute to the compiler if I see no hope of it ever reaching 
 a stable release that is better than the alternatives from a 
 commercial perspective?


It is not clear that the core team wants commercial investment, 
that's merely my guess of how D might become more polished and 
popular.  AFAICT, Andrei and Walter hope to get to a million 
users mostly through volunteers, which is a pipe dream if you ask 
me, though they don't appear to be against commercial 
involvement.  As you say, without presenting a more organized 
front, maybe such commercial investment is unlikely.
Dec 22 2014
prev sibling parent reply "Martin Nowak" <code dawg.eu> writes:
On Friday, 19 December 2014 at 16:45:40 UTC, Ola Fosheim Grøstad 
wrote:

 Yes, but it would be easy to define some focused goals for each 
 release and refuse to touch stuff that belongs to a later 
 release. E.g.


http://wiki.dlang.org/Agenda
Jan 13 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 13 January 2015 at 23:40:32 UTC, Martin Nowak wrote:

 On Friday, 19 December 2014 at 16:45:40 UTC, Ola Fosheim 
 Grøstad wrote:

 Yes, but it would be easy to define some focused goals for 
 each release and refuse to touch stuff that belongs to a later 
 release. E.g.


 http://wiki.dlang.org/Agenda


That's a good start, but it is too vague. You need to design 
ahead so that you don't start on the release without having 
measurable goals and milestones. "c++ and gc" is not measurable.

You need to map out future releases and dependencies between 
features.

Then you need to evaluate what went "wrong" in the last release, 
and what was added to the last release, but not in the plan and 
why. The "Agenda" is loosing its authority as a plan if it is not 
evaluated. Without evaluation you can basically ignore it?
Jan 14 2015
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Friday, 19 December 2014 at 14:38:02 UTC, Tobias Pankrath 
wrote:

 As for Walter already saying "no" a lot, given how many 
 features D has, obviously one can still wish he went from 99% 
 "no" to 99.5%. ;)  You don't need to be around the D community 
 forever to feel that D still has too many features that made 
 it in.


 Care to name a few and justify why exactly those features 
 should be gone?


  - lazy . It is completely unable to interact with all qualifier 
code that run should be able to have.
  - scope in its current state. Do not ensure anything.
  - in and out parameters.
  - optional parenthesis. They cause confusion and great language 
complication in their current form.
  - Non first class functions. Useless baggage from C and C++, 
which only benefit are to complicate the situation with optional 
() and cause a large part of the standard lib to go banana when 
passed a non first class function via alias parameter.
  - inout. Completely underpowered for its cost, ambiguous and can 
cause compiler crash in some ambiguous cases.
  - most of traits. They are completely inconsistent, for 
instance, some return aliases, some return strings and there is 
no way to really know.
  - __parameters. Yes, this is a keyword.

That is what you get you add half assed feature to solve an 
immediate problem, but don't look at the broader picture.
Dec 19 2014
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
19-Dec-2014 18:08, deadalnix пишет:

 On Friday, 19 December 2014 at 14:38:02 UTC, Tobias Pankrath wrote:

 As for Walter already saying "no" a lot, given how many features D
 has, obviously one can still wish he went from 99% "no" to 99.5%. ;)
 You don't need to be around the D community forever to feel that D
 still has too many features that made it in.


 Care to name a few and justify why exactly those features should be gone?


   - lazy . It is completely unable to interact with all qualifier code
 that run should be able to have.
   - scope in its current state. Do not ensure anything.
   - in and out parameters.


+1


   - optional parenthesis. They cause confusion and great language
 complication in their current form.


Unless there was a way for author to enforce one way of writing it. 
Which gets us to some useful  properties.


   - Non first class functions. Useless baggage from C and C++, which
 only benefit are to complicate the situation with optional () and cause
 a large part of the standard lib to go banana when passed a non first
 class function via alias parameter.



   - inout. Completely underpowered for its cost, ambiguous and can cause
 compiler crash in some ambiguous cases.


I too never understood the appeal of inout. Not only interfaces now 
allow template final functions but also the bolierplate is easily 
removed with (template) mixins.


   - most of traits. They are completely inconsistent, for instance, some
 return aliases, some return strings and there is no way to really know.
   - __parameters. Yes, this is a keyword.


That's just baggage that's far less destructive.


 That is what you get you add half assed feature to solve an immediate
 problem, but don't look at the broader picture.




-- 
Dmitry Olshansky
Dec 23 2014
prev sibling next sibling parent reply "Joakim" <dlang joakim.fea.st> writes:
I don't think it's fair to lump D1 into the 15 years, since D2 
went in a different direction and broke compatibility.  In any 
case, ruby was around for a decade before it took off, and it 
didn't have to deal with a version break and all the stuff that 
went with it.

To answer your question, here's my guess as to the plan:

- Make D efficient, that already rules out competition from ruby, 
python, and all the interpreted languages.
- Add a bunch of features that are either C++ done better or 
pulled from the more dynamic languages but done at compile-time, 
ie CTFE and mixins.
- Hope commercial support comes along and cleans up a bunch of 
bugs and clashing features.

Commercial support might consist of companies contributing to the 
D core, a mob of users putting up bounties for bugs they want 
fixed or features they'd like, or a language vendor closing up 
parts of the D core and selling a paid version.

The hope is that some commercial entities like the first two 
aspects of D so much that they think it's worthwhile to invest in 
fixing and polishing it up.  Otherwise, D has no hope of becoming 
a "used" language.
Dec 18 2014
next sibling parent "Gary Willoughby" <dev nomad.so> writes:
On Thursday, 18 December 2014 at 17:13:08 UTC, Joakim wrote:

 - Hope commercial support comes along and cleans up a bunch of 
 bugs and clashing features.

 Commercial support might consist of companies contributing to 
 the D core, a mob of users putting up bounties for bugs they 
 want fixed or features they'd like, or a language vendor 
 closing up parts of the D core and selling a paid version.

 The hope is that some commercial entities like the first two 
 aspects of D so much that they think it's worthwhile to invest 
 in fixing and polishing it up.  Otherwise, D has no hope of 
 becoming a "used" language.


IMHO commercial support is now what D needs most badly.
Dec 18 2014
prev sibling parent reply "Laeeth Isharc" <laeeth laeeth.com> writes:
More complex creatures may take longer to mature than simpler 
ones.  At the age of five, an infant is a much less impressive 
creature than a dog of the same age.  (And one might sometimes 
feel the same way also when it reaches the age of 15 ;)  Social 
institutions have organic traits too, so the metaphor may have 
some application.

Sometimes in the growth of a business there are some limiting 
factors that simply need to be worked through, and there may be 
no viable short-cut.  It's easy to become frustrated if one makes 
comparisons, but it may be that the situations simply are not 
comparable because the problems faced are different.

The growth of a business also often depends on external factors. 
It just trundles along for years, and suddenly the stars align, 
and there is explosive growth.  People attribute overnight 
success to overnight causal factors, but that is rarely how it 
works beyond the most superficial level of understanding.  When 
the stars align, it isn't just one thing, but rather a whole 
bunch of often slow but powerful developments coming together.

I am a newcomer to D, and by far not an expert in computer 
science, processor and memory tends etc.  But perhaps it may be 
the case that changing cost conditions dramatically influence the 
kinds of tools that best suit the most pressing problems.  These 
problems too may be becoming more ambitious in terms of 
magnitude.  For a long time in the business world, processing 
power was essentially a free resource (and often RAM was too).  
Gamers had more powerful machines, even compared sometimes to 
those used in the financial sector.  But people do respond to 
relative prices, and when something is cheap they find ways to 
use lots of it although it does take some time.

Ie it was once perhaps true as a simple generalisation for quite 
some time that much activity was I/O bound, and so the speed of 
interpreted languages with a C back-end like Python simply didn't 
matter.  It may perhaps also be true that the world of the future 
will be quite different.

That is why I am interested in D - it seems to be the only viable 
option that seems likely to perform well whilst meeting a certain 
set of constraints that I believe will be important for me.  
Sometimes I get things wrong, but often I tend to identify 
changes in trends early enough, and it may be that others come to 
similar conclusions in time.

Its adoption at Facebook is intriguing.  The temptation is to 
dismiss it and suggest that they have a lot of resources for R&D, 
and a handsome salary for Dr Andreiscu is a rounding error 
compared to the productivity of a talented person, and if he 
wants to program in VBA then if it works, why fight him!  Also, 
to say that Facebook has some extraordinary challenges that are 
not representative of those faced by other business applications, 
and that are not ever representative to be so.

But I have a different perspective, and I think perhaps the kinds 
of challenges faced by Facebook may be more like the leading edge 
of what many more people may be facing in the years to come. 
William Gibson's "The future is here already, but not evenly 
distributed".

In any case, there is little point speculating about the future, 
and certainly none throwing up one's hands in woe at what seems 
to be slow adoption.  (If one compares oneself to the languages 
that have been most quickly adopted, one will always feel bad 
because that is the nature of comparison).

Strife is good, if one responds to it in a creative fashion.  One 
also should not be limited by what seem to be immediate 
constraints of lacking resources - budget, people etc.  First of 
all one comes up with a vision and plan to execute it, and 
somehow magically the path to get there emerges slowly out of the 
fog.  The amounts of money at stake to me really seem to be quite 
small in the bigger picture of things.  I cannot personally help 
today, but that may change in a few years, and I will if I can 
then.

I don't claim to have great technical expertise, but it does seem 
to me that - contrary to what might be inferred from the original 
post - D has made very substantial progress since it was 
launched.  The years have not been wasted, because it is a much 
better language that has kind of discovered further sources of 
beauty that were unexpected perhaps even by its creators.

I personally think the following would be very helpful

- better reference documentation.  I don't believe I lack the 
ability generally to figure things out, but the dlang.org library 
reference is far from being utterly clear if you don't start from 
a place of understanding the language and its concepts.  once you 
get the spirit of it, it all makes sense, but modern people don't 
tend to be distinguished by their grit and many will give up 
first.

- better worked examples.  python is outstanding for this.  you 
can figure out how to do anything by looking at someone else's 
example.  of course there isn't presently the support for this, 
and I recognize that one attracts a different kind of person when 
it becomes easy to learn a language.  but such is the price of 
maturity.

- agree about commercial support.  if you are using it at an 
enterprise level you want to know you can call someone and get it 
fixed because the price of not doing so may be incalculably high, 
and people don't necessarily trust themselves to be able to fix 
it.  entrepreneurs don't like uncertainty outside their home 
ground that they cannot pin down.

- some degree of strategic planning as regards use cases.  if 
someone owned the product they would be very interested and 
inquisitive about the nitty gritty details to see who is using it 
in different domains, why (and why don't people go for the 
competition), what the language does really well, and whether the 
problems perceived to be the biggest ones actually align with 
what end-users find important.

- also a degree of relating D's power to emerging trends in 
different sectors and some writing up of stories, case studies, 
interviews with end users.  this is a kind of community-building 
task and requires very different skills and emotional makeup to 
other aspects.  the obvious areas I might think about would be 
the financial sector (hedge funds, investment banks, financial 
exchanges, platforms etc), machine learning media analysis 
problems, economic analysis (much larger data sets than 
economists are used to, and the don't have the right tools for 
it), bioinformatics, processing logs for the internet of things, 
etc.

if you were running a business you would want there to be 
somebody you could call if you were a practitioner in 
bioinformatics and wanted to know the experience of people using 
D in that area.  I appreciate that's highly unrealistic for the 
time being, but it may be worth bearing in mind as something 
helpful for the distant future.

- finally, a bit better organisation.  Andrei spoke about needing 
more lieutenants.  Of course it's a no-brainer that he shouldn't 
be spending his time designing a conference web site.  But 
perhaps you could make it clearer by adding a section on the D 
wiki front page: "Interested in supporting D?  Here's how you can 
help".  It could then take you to a page that breaks down 
different areas to work on and tasks to be accomplished on each 
of them.  Then someone with time and inclination can see "oh - it 
would be great to have someone promote this event on Reddit".  
But as things stand, I imagine to a certain extent nobody knows 
what specifically they can do.

I am horribly disorganized, so I am not the right one here.


- and one could have a bit of patience and self-confidence.  
having high standards and wanting to achieve excellence does not 
mean one cannot recognize one cannot get there overnight and that 
it is more a matter of taking steps in the right direction, 
sustained over time.  I liked Andrei's attitude of brutal honesty 
in this respect.
Dec 18 2014
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Dec 18, 2014 at 08:12:07PM +0000, Laeeth Isharc via Digitalmars-d wrote:
[...]

 - better reference documentation.  I don't believe I lack the ability
 generally to figure things out, but the dlang.org library reference is
 far from being utterly clear if you don't start from a place of
 understanding the language and its concepts.  once you get the spirit
 of it, it all makes sense, but modern people don't tend to be
 distinguished by their grit and many will give up first.


Please file documentation enhancement bugs in bugzilla.  I do try to
work on improving documentation when I have the time, but if nobody
points out a possible improvement, I might never think of it (or it
might take a long time before I notice it, esp. if I rarely use that
module!). I'm sure others who browse bugzilla from time to time will
also appreciate having documentation bugs to work on -- since they're
generally the lowest-hanging fruit that even most newbies should be able
to contribute to.



 - better worked examples.  python is outstanding for this.  you can
 figure out how to do anything by looking at someone else's example.
 of course there isn't presently the support for this, and I recognize
 that one attracts a different kind of person when it becomes easy to
 learn a language.  but such is the price of maturity.


Please file doc enhancement requests for these too. :-) A lot of Phobos
documentation is unfortunately quite lacking in good examples. I've done
a few of them, but generally, having a bugzilla issue for it is much
better, because I may already know function X like the back of my hand
and so never notice that the examples aren't that good, whereas if a
newbie pointed out that the examples for X are unclear, then I'd know
there's an issue and look into how to explain X better.


[...]

 - finally, a bit better organisation.  Andrei spoke about needing more
 lieutenants.  Of course it's a no-brainer that he shouldn't be
 spending his time designing a conference web site.  But perhaps you
 could make it clearer by adding a section on the D wiki front page:
 "Interested in supporting D?  Here's how you can help".  It could then
 take you to a page that breaks down different areas to work on and
 tasks to be accomplished on each of them.  Then someone with time and
 inclination can see "oh - it would be great to have someone promote
 this event on Reddit".  But as things stand, I imagine to a certain
 extent nobody knows what specifically they can do.


[...]

There's some preliminary info at:

	http://wiki.dlang.org/Get_involved

But it would be greatly appreciated if you could help improve it by
adding more material. ;-)


T

-- 
"You are a very disagreeable person." "NO."
Dec 18 2014
next sibling parent reply "Kiith-Sa" <kiithsacmp gmail.com> writes:
On Friday, 19 December 2014 at 00:21:06 UTC, H. S. Teoh via 
Digitalmars-d wrote:

 On Thu, Dec 18, 2014 at 08:12:07PM +0000, Laeeth Isharc via 
 Digitalmars-d wrote:
 [...]

 - better reference documentation.  I don't believe I lack the 
 ability
 generally to figure things out, but the dlang.org library 
 reference is
 far from being utterly clear if you don't start from a place of
 understanding the language and its concepts.  once you get the 
 spirit
 of it, it all makes sense, but modern people don't tend to be
 distinguished by their grit and many will give up first.


 Please file documentation enhancement bugs in bugzilla.  I do 
 try to
 work on improving documentation when I have the time, but if 
 nobody
 points out a possible improvement, I might never think of it 
 (or it
 might take a long time before I notice it, esp. if I rarely use 
 that
 module!). I'm sure others who browse bugzilla from time to time 
 will
 also appreciate having documentation bugs to work on -- since 
 they're
 generally the lowest-hanging fruit that even most newbies 
 should be able
 to contribute to.



 - better worked examples.  python is outstanding for this.  
 you can
 figure out how to do anything by looking at someone else's 
 example.
 of course there isn't presently the support for this, and I 
 recognize
 that one attracts a different kind of person when it becomes 
 easy to
 learn a language.  but such is the price of maturity.


 Please file doc enhancement requests for these too. :-) A lot 
 of Phobos
 documentation is unfortunately quite lacking in good examples. 
 I've done
 a few of them, but generally, having a bugzilla issue for it is 
 much
 better, because I may already know function X like the back of 
 my hand
 and so never notice that the examples aren't that good, whereas 
 if a
 newbie pointed out that the examples for X are unclear, then 
 I'd know
 there's an issue and look into how to explain X better.


 [...]

 - finally, a bit better organisation.  Andrei spoke about 
 needing more
 lieutenants.  Of course it's a no-brainer that he shouldn't be
 spending his time designing a conference web site.  But 
 perhaps you
 could make it clearer by adding a section on the D wiki front 
 page:
 "Interested in supporting D?  Here's how you can help".  It 
 could then
 take you to a page that breaks down different areas to work on 
 and
 tasks to be accomplished on each of them.  Then someone with 
 time and
 inclination can see "oh - it would be great to have someone 
 promote
 this event on Reddit".  But as things stand, I imagine to a 
 certain
 extent nobody knows what specifically they can do.


 [...]

 There's some preliminary info at:

 	http://wiki.dlang.org/Get_involved

 But it would be greatly appreciated if you could help improve 
 it by
 adding more material. ;-)


 T


In case you'll have time/will to work on this in near future - 
resulted from previous "D docs suck" discussion (I'll probably do 
some of it eventually, but I'm unlikely to be free till summer):

https://issues.dlang.org/show_bug.cgi?id=13863
Dec 18 2014
parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Dec 19, 2014 at 01:11:02AM +0000, Kiith-Sa via Digitalmars-d wrote:
[...]

 In case you'll have time/will to work on this in near future -
 resulted from previous "D docs suck" discussion (I'll probably do some
 of it eventually, but I'm unlikely to be free till summer):
 
 https://issues.dlang.org/show_bug.cgi?id=13863


Oooh, that sounds like something I'm quite interested in, along the
lines of:

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

However, I won't be able to get to this for about a week or so (at
least). It's definitely something I'd want to see fixed, as it greatly
degrades the quality of Phobos documentation.


T

-- 
I am Ohm of Borg. Resistance is voltage over current.
Dec 18 2014
prev sibling parent reply "Laeeth Isharc" <laeethnospam spammenot_laeeth.com> writes:
On Friday, 19 December 2014 at 00:21:06 UTC, H. S. Teoh via 
Digitalmars-d wrote:

 On Thu, Dec 18, 2014 at 08:12:07PM +0000, Laeeth Isharc via 
 Digitalmars-d wrote:
 [...]

 - better reference documentation.  I don't believe I lack the 
 ability generally to figure things out, but the dlang.org 
 library reference is far from being utterly clear if you don't 
 start from a place of
 understanding the language and its concepts.  once you get the 
 spirit of it, it all makes sense, but modern people don't tend 
 to be
 distinguished by their grit and many will give up first.


 Please file documentation enhancement bugs in bugzilla.  I do 
 try to work on improving documentation when I have the time, 
 but if nobody points out a possible improvement, I might never 
 think of it (or it might take a long time before I notice it, 
 esp. if I rarely use that module!). I'm sure others who browse 
 bugzilla from time to time will also appreciate having 
 documentation bugs to work on -- since they're generally the 
 lowest-hanging fruit that even most newbies should be able to 
 contribute to.


I will register an account now, and try to make a start in the 
coming months.



 - better worked examples.  python is outstanding for this.  
 you can figure out how to do anything by looking at someone 
 else's example.
 of course there isn't presently the support for this, and I 
 recognize that one attracts a different kind of person when it 
 becomes easy to learn a language.  but such is the price of 
 maturity.


 Please file doc enhancement requests for these too. :-) A lot 
 of Phobos documentation is unfortunately quite lacking in good 
 examples. I've done a few of them, but generally, having a 
 bugzilla issue for it is much better, because I may already 
 know function X like the back of my hand and so never notice 
 that the examples aren't that good, whereas if a newbie pointed 
 out that the examples for X are unclear, then I'd know there's 
 an issue and look into how to explain X better.


Will start keeping track and try to write some points up when I 
have a few of them.  It's often just the absence of anything more 
than a few lines.  Now I have spent some time with D, it becomes 
easier - and one can just go read the source.  But some people 
will be put off by that.  There is a benefit from having a toll 
to enter too, but probably in the long run D's destiny cannot be 
to remain a tool solely for those with good taste, courage, and 
perseverance ;)

One should be patient with oneself about where one starts from, 
and it may well be that this is the least of anyone's concerns 
for the time being, but it might be something to work towards, 
step by step, over time.

Some simple examples for python:
http://python.readthedocs.org/en/latest/howto/urllib2.html
https://wiki.python.org/moin/HowTo/Sorting
[compare the above with the rather terse docs on std.algorithm, 
which are the only ones that come up that I can see when doing a 
search on dlang.org for sorting]

If D wants to be purely a systems language then people who can't 
figure it out for themselves should stick with something better 
suited to them - we all have limitations.  But I think what D 
intrinsically wants to be (just as an acorn wants to be an oak) 
is rather broader in scope, and if true that may  mean the 
ecosystem needs to grow in a different way to permit that.

I met the global head of derivatives research for a big 
investment bank in London for a coffee the other day.  He knew of 
D and a bit about it.  Right now they use mostly python.  He is 
interested, but he has a lot on his plate and not enough people.  
Beyond wanting more along the lines of the links above, it would 
be nice to be able to point him to a few tutorials that show here 
is how you use D to do certain basic business processes.  Like 
grabbing data from Fed web site, parsing, storing in HDF5 etc.  
And in other fields it must be similar.  You want to be able to 
tell your guy - here kid, you're a smart kid and our processes 
are too slow - go and take a look at this D thing and see if we 
can do something with it.  That's easier with more fleshed out 
use cases (Adam's stuff comes to mind).

I am musing aloud more than suggesting anything specific.  I will 
try to start contributing a bit, although limited by time and 
frankly experience of D.


Laeeth
Dec 19 2014
parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 20/12/2014 10:34 a.m., Laeeth Isharc wrote:

 On Friday, 19 December 2014 at 00:21:06 UTC, H. S. Teoh via
 Digitalmars-d wrote:

 On Thu, Dec 18, 2014 at 08:12:07PM +0000, Laeeth Isharc via
 Digitalmars-d wrote:
 [...]

 - better reference documentation.  I don't believe I lack the ability
 generally to figure things out, but the dlang.org library reference
 is far from being utterly clear if you don't start from a place of
 understanding the language and its concepts.  once you get the spirit
 of it, it all makes sense, but modern people don't tend to be
 distinguished by their grit and many will give up first.


 Please file documentation enhancement bugs in bugzilla.  I do try to
 work on improving documentation when I have the time, but if nobody
 points out a possible improvement, I might never think of it (or it
 might take a long time before I notice it, esp. if I rarely use that
 module!). I'm sure others who browse bugzilla from time to time will
 also appreciate having documentation bugs to work on -- since they're
 generally the lowest-hanging fruit that even most newbies should be
 able to contribute to.


 I will register an account now, and try to make a start in the coming
 months.



 - better worked examples.  python is outstanding for this. you can
 figure out how to do anything by looking at someone else's example.
 of course there isn't presently the support for this, and I recognize
 that one attracts a different kind of person when it becomes easy to
 learn a language.  but such is the price of maturity.


 Please file doc enhancement requests for these too. :-) A lot of
 Phobos documentation is unfortunately quite lacking in good examples.
 I've done a few of them, but generally, having a bugzilla issue for it
 is much better, because I may already know function X like the back of
 my hand and so never notice that the examples aren't that good,
 whereas if a newbie pointed out that the examples for X are unclear,
 then I'd know there's an issue and look into how to explain X better.


 Will start keeping track and try to write some points up when I have a
 few of them.  It's often just the absence of anything more than a few
 lines.  Now I have spent some time with D, it becomes easier - and one
 can just go read the source.  But some people will be put off by that.
 There is a benefit from having a toll to enter too, but probably in the
 long run D's destiny cannot be to remain a tool solely for those with
 good taste, courage, and perseverance ;)

 One should be patient with oneself about where one starts from, and it
 may well be that this is the least of anyone's concerns for the time
 being, but it might be something to work towards, step by step, over time.

 Some simple examples for python:
 http://python.readthedocs.org/en/latest/howto/urllib2.html
 https://wiki.python.org/moin/HowTo/Sorting
 [compare the above with the rather terse docs on std.algorithm, which
 are the only ones that come up that I can see when doing a search on
 dlang.org for sorting]

 If D wants to be purely a systems language then people who can't figure
 it out for themselves should stick with something better suited to them
 - we all have limitations.  But I think what D intrinsically wants to be
 (just as an acorn wants to be an oak) is rather broader in scope, and if
 true that may  mean the ecosystem needs to grow in a different way to
 permit that.

 I met the global head of derivatives research for a big investment bank
 in London for a coffee the other day.  He knew of D and a bit about it.
 Right now they use mostly python.  He is interested, but he has a lot on
 his plate and not enough people. Beyond wanting more along the lines of
 the links above, it would be nice to be able to point him to a few
 tutorials that show here is how you use D to do certain basic business
 processes.  Like grabbing data from Fed web site, parsing, storing in
 HDF5 etc. And in other fields it must be similar.  You want to be able
 to tell your guy - here kid, you're a smart kid and our processes are
 too slow - go and take a look at this D thing and see if we can do
 something with it.  That's easier with more fleshed out use cases
 (Adam's stuff comes to mind).

 I am musing aloud more than suggesting anything specific.  I will try to
 start contributing a bit, although limited by time and frankly
 experience of D.


 Laeeth


Aka we need use cases and tutorials on the main site. Already been 
suggested. Really we need to get our act together and make it happen.
Dec 19 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On actual plan of D development - I believe that if situation 
stays the same existing companies and core contributors will need 
to step up and take over management of the language at some 
point, based on some well-defined decision making protocol. Right 
language leadership is the bottleneck - and hardly backed by any 
implementation power.

This is purely my personal opinion (not Sociomantic) and I don't 
want really to put much into it until we are fully in D2 world 
but my opinion of established system is very pessimistic.

It is also sad that Andrei didn't manage to convince Facebook 
leadership to invest seriously into language development. It 
could have been very cost-efficient long term investment and game 
changer.
Dec 18 2014
prev sibling next sibling parent reply "Bienlein" <jeti789 web.de> writes:
I would say that D needs a usecase that puts it aside from other 
languages. For Java this was the Internet. For Go it was 
channel-based concurrency in conjunction with some style of green 
threads (aka CSP). It is now the time of server side concurrent 
programming. I would suggest to jump onto this wagon and add 
channels and green threads to D. When people successfully develop 
many server side systems this way as with Go the news will spread 
by itself. No killer app for D needed. Also Go does not have one.

-- Bienlein
Dec 20 2014
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Saturday, 20 December 2014 at 12:19:34 UTC, Bienlein wrote:

 I would say that D needs a usecase that puts it aside from 
 other languages. For Java this was the Internet. For Go it was 
 channel-based concurrency in conjunction with some style of 
 green threads (aka CSP). It is now the time of server side 
 concurrent programming. I would suggest to jump onto this wagon 
 and add channels and green threads to D. When people 
 successfully develop many server side systems this way as with 
 Go the news will spread by itself. No killer app for D needed. 
 Also Go does not have one.


CSP is not superior to message passing for concurrent server 
programming and D already beats Go in this domain, it is purely 
marketing crap. Stop repeating same statement over and over again 
with no technical data to back it up. Or just go and implement 
CSP if you want it so much - I doubt anyone would object merging 
it if it is already implemented.
Dec 20 2014
parent "Bienlein" <jeti789 web.de> writes:
On Saturday, 20 December 2014 at 12:21:49 UTC, Dicebot wrote:


 CSP is not superior to message passing for concurrent server 
 programming and D already beats Go in this domain, it is purely 
 marketing crap. Stop repeating same statement over and over 
 again with no technical data to back it up. Or just go and 
 implement CSP if you want it so much - I doubt anyone would 
 object merging it if it is already implemented.


A different approach would be to use D's existing multi-threading 
model and develop a first class actor system for it like Akka for 
Scala/Java. But that would be a big effort and competing with 
Akka would be difficult anyway. So, again, an idea to think of 
might be to add CSP to D.
Dec 20 2014
prev sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Saturday, 20 December 2014 at 12:19:34 UTC, Bienlein wrote:

 I would say that D needs a usecase that puts it aside from 
 other languages. For Java this was the Internet. For Go it was 
 channel-based concurrency in conjunction with some style of 
 green threads (aka CSP). It is now the time of server side 
 concurrent programming. I would suggest to jump onto this wagon 
 and add channels and green threads to D. When people 
 successfully develop many server side systems this way as with 
 Go the news will spread by itself. No killer app for D needed. 
 Also Go does not have one.

 -- Bienlein


Go has Google's sponsorship, Docker and CoreOS.
Dec 20 2014
parent reply "Bienlein" <jeti789 web.de> writes:
On Saturday, 20 December 2014 at 12:24:29 UTC, Paulo Pinto wrote:

 On Saturday, 20 December 2014 at 12:19:34 UTC, Bienlein wrote:

 I would say that D needs a usecase that puts it aside from 
 other languages. For Java this was the Internet. For Go it was 
 channel-based concurrency in conjunction with some style of 
 green threads (aka CSP). It is now the time of server side 
 concurrent programming. I would suggest to jump onto this 
 wagon and add channels and green threads to D. When people 
 successfully develop many server side systems this way as with 
 Go the news will spread by itself. No killer app for D needed. 
 Also Go does not have one.

 -- Bienlein


 Go has Google's sponsorship, Docker and CoreOS.


Message passing for concurrent server programming means 
asynchronous programming. Asynchronous programming is inherently 
difficult and error prone. I have done it for years and everyone 
else who has can confirm this.

The big thing with CSP-style channels is that while things are 
going on concurrently the code can be read like synchronous code. 
This way a lot of people out there have built server side systems 
with Go in record time. All the startups using Go are proof for 
this.

There is really a lot of "technical data" and scientic papers 
about this. The success of Go tells its own story. Also Rust will 
have a module for CSP-style concurrent programming. That comes 
for a reason.

This is the original paper titled "Communicating Sequential 
Processes" by C. A. R. Hoare: 
http://www.usingcsp.com/cspbook.pdf. CSP is not missing 
"technical data". It has a solid basis and Go shows that it works 
well. It has drawbacks like lack of pre-emptiveness, but things 
like the C10K problem solved out of the box is more important to 
many server side systems to be built.

Apparently, for D some commercial big spender has never popped 
up. Killer apps to be developed need some good piece of fortune 
to turn out successfull. But adding a more adequate 
multi-threading/concurrency model to D and make it a success. And 
that takes little resources compared to other alternatives to 
make D more widely used.

Docker is not developed by Google. It is made by a company of its 
own who was looking for a language suitable for server-side 
concurrent programming. It could have been D if D better support 
for this.
Dec 20 2014
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
People have already suggested you to actually try vibe.d at least 
once before repeating "CSP is necessary for easy async" mantra. 
How about actually doing so? vibe.d + std.concurrency gives you 
pretty much standard actor model - it lacks more complicated 
schedulers and network message passing but fundamentals are all 
there.
Dec 20 2014
parent "Bienlein" <jeti789 web.de> writes:
On Saturday, 20 December 2014 at 12:50:02 UTC, Dicebot wrote:

 People have already suggested you to actually try vibe.d at 
 least once before repeating "CSP is necessary for easy async" 
 mantra. How about actually doing so? vibe.d + std.concurrency 
 gives you pretty much standard actor model - it lacks more 
 complicated schedulers and network message passing but 
 fundamentals are all there.


CSP-style programming in D needs to be drop-dead simple as in Go 
to take off. You need to know about channels and the go command 
to spawn a thread and that's it. That's why Go was that 
successful. Vibe.d might be a well written system, but nobody 
will learn D and thereafter vibe.d. It is either laughable simple 
as in Go or it will not be noticed. The simplicity of channels 
and goroutines as in Go created the excitement. The same 
simplöicity is needed for any other language. The whole thing can 
be implemented with vibe.d, but at the surface there must only by 
goroutines and channels and nothing more.
Dec 20 2014
prev sibling parent reply "ponce" <contact gam3sfrommars.fr> writes:
On Saturday, 20 December 2014 at 12:39:01 UTC, Bienlein wrote:

 This way a lot of people out there have built server side 
 systems with Go in record time. All the startups using Go are 
 proof for this.


I would be wary of extrapolating best practices from what 
startups do.
Startups succeed when they bet on the right market or propose 
something new and needed. I suspect technological choices play 
little part here, and that's why most companies using Go are 
startups: they could use almost anything and have the same 
outcome.

Successful rewrites from hyped language X to hyped language Y as 
pictured in blogs can also be misleading: almost all rewrites are 
rewrites of problematic systems in the first place, hence 
successful especially rewrites of young programs.
Dec 20 2014
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Saturday, 20 December 2014 at 13:56:01 UTC, ponce wrote:

 On Saturday, 20 December 2014 at 12:39:01 UTC, Bienlein wrote:

 This way a lot of people out there have built server side 
 systems with Go in record time. All the startups using Go are 
 proof for this.


 I would be wary of extrapolating best practices from what 
 startups do.
 Startups succeed when they bet on the right market or propose 
 something new and needed. I suspect technological choices play 
 little part here, and that's why most companies using Go are 
 startups: they could use almost anything and have the same 
 outcome.

 Successful rewrites from hyped language X to hyped language Y 
 as pictured in blogs can also be misleading: almost all 
 rewrites are rewrites of problematic systems in the first 
 place, hence successful especially rewrites of young programs.



That is why I seldom buy into hype driven development.

Usually on our teams if a specific technology wasn't explicitly 
requested by the customer, whoever is bringing it in has to 
answer what is the business value to the customer.
Dec 20 2014
next sibling parent "ponce" <contact gam3sfrommars.fr> writes:
On Saturday, 20 December 2014 at 14:06:51 UTC, Paulo Pinto wrote:

 That is why I seldom buy into hype driven development.

 Usually on our teams if a specific technology wasn't explicitly 
 requested by the customer, whoever is bringing it in has to 
 answer what is the business value to the customer.


I think D clearly has some value for the business:
- highly expressive/productive,
- developer morale, "feel-smart" effect for better or worse
- high reuse
- lower bug counts when compared to C++

But much like there is hidden costs, those aspects can go 
unnoticed as "hidden cost savings".
Dec 20 2014
prev sibling parent reply "Bienlein" <jeti789 web.de> writes:
On Saturday, 20 December 2014 at 14:06:51 UTC, Paulo Pinto wrote:


That is why I seldom buy into hype driven development.


Okay, so Docker is hype? Have you seen the impact of it? Every 
Java magazine has articles about Docker. And that is not because 
Java people had an interest in it, because it is written in Go. 
It is because of its business value.

Have a look at all the job offers for Go developers here: 
http://www.golangprojects.com. All those jobs are the result of 
some hype.
Dec 20 2014
next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Saturday, 20 December 2014 at 15:14:28 UTC, Bienlein wrote:

 On Saturday, 20 December 2014 at 14:06:51 UTC, Paulo Pinto 
 wrote:


That is why I seldom buy into hype driven development.


 Okay, so Docker is hype? Have you seen the impact of it? Every 
 Java magazine has articles about Docker. And that is not 
 because Java people had an interest in it, because it is 
 written in Go. It is because of its business value.

 Have a look at all the job offers for Go developers here: 
 http://www.golangprojects.com. All those jobs are the result of 
 some hype.


I wasn't talking about Go specifically, rather the adoption of 
technologies in the going up slope of the hype curve in the IT 
fashion world.
Dec 20 2014
parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sat, 2014-12-20 at 22:09 +0000, Paulo Pinto via Digitalmars-d wrote:

 On Saturday, 20 December 2014 at 15:14:28 UTC, Bienlein wrote:

 




[…]

 Have a look at all the job offers for Go developers here: 
 http://www.golangprojects.com. All those jobs are the result of 
 some hype.


 
 I wasn't talking about Go specifically, rather the adoption of 
 technologies in the going up slope of the hype curve in the IT 
 fashion world.


I have ignored this thread for a while now as I had assumed most of it 
was angst. But I feel I have a few points to make prompted by this 
comment.

D was started as a better C++. Technically that may be true, but it 
has failed to gain traction in the market.  Most C++ people will move 
to C++14 rather than D. Most C people will move to Go rather than C++ 
or D.

Go was started as a better C with added concurrency. Go is not only 
superior to C for creating systems applications, it has gained huge 
traction. C's role is now well defined as being portable assembler for 
case when only that will do. Like COBOL though there will be a lot of C
about for a long time.

And note that Go has a very good garbage collector. Also worthy of 
note is that gc produces slow executing code very quickly where gccgo 
produces very fast executing code very slowly. Echoes of dmd vs. ldc 
and gdc :-)

It doesn't matter that Go may have arrived on a wave of hype, the 
language appealed to some high profile people who did things with it 
and showed how much better it was than the alternatives. For these 
people the alternatives were C and C++. D and Rust are just not in the 
game, though Rust when it gets to 1.0 will have an opportunity.  Go 
now has street cred. The biggest angst is now about whether Google 
will pull their funding of the core team.

Perhaps like Haskell, D is doomed to be a language used by few, but 
having enormous influence on other languages that are used by many.

Rust has Cargo, just like D has Dub! Go has a complete idiomatic 
subframework based on "go get" and DVCSs such as Git, Mercurial and 
Bazaar. (Though the last of these is now sadly a dead project since 
Canonical removed its funding.) 

Rust may not have got to 1.0 yet, but they have a superb framework for 
allowing people to upgrade to the latest nightly each morning 
(assuming you are happy downloading 160MB). This means people us it 
even though the language has regular breaking changes.

So D is battling against C++14, Go and Rust for market share, and to 
be honest is failing. This is partly because D is an old language that 
never caught on, but also because it has a lack of "new" marketing and 
a path to traction. Interminable discussion in these mailing lists 
achieves nothing. Trying to tell C and C++ folk they should change to D
achieves nothing. Having a reputation for internal angst and a bad 
garbage collector achieves huge negative waves. A language 11 years 
old and still in the same "breaking change" situation as Rust, yet 
claiming to be production ready isn't helping. Conversely Dub helps 
the D cause, code.dlang.org helps the D cause.

What D needs though is some high profile people doing high profile 
projects to create a sense of newness. This is the lesson D needs to 
take from Go and Rust. Make use of hype rather than just complaining 
about it. Set situations up that can be hyped. Hype is after all just 
over-enthusiastic marketing.

So what is the D USP on which hype can be hung?

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Dec 21 2014
next sibling parent reply "Joakim" <dlang joakim.fea.st> writes:
On Sunday, 21 December 2014 at 10:26:45 UTC, Russel Winder via 
Digitalmars-d wrote:

 D was started as a better C++. Technically that may be true, 
 but it
 has failed to gain traction in the market.  Most C++ people 
 will move
 to C++14 rather than D. Most C people will move to Go rather 
 than C++
 or D.


These two developments don't necessarily mean much for D.  C/C++ 
devs are not going to give up their big investments in their 
existing source and knowledge unless D presents some big wins, 
real world success like Sociomantic.  Until then, it's more 
likely that D's traction will come from the new and disaffected.  
If they succeed, C/C++ devs will copy them and switch over, or 
their bosses will make them. ;)


 It doesn't matter that Go may have arrived on a wave of hype, 
 the
 language appealed to some high profile people who did things 
 with it
 and showed how much better it was than the alternatives. For 
 these
 people the alternatives were C and C++. D and Rust are just not 
 in the
 game, though Rust when it gets to 1.0 will have an opportunity.
  Go
 now has street cred. The biggest angst is now about whether 
 Google
 will pull their funding of the core team.


---snip---

 So D is battling against C++14, Go and Rust for market share, 
 and to
 be honest is failing. This is partly because D is an old 
 language that
 never caught on, but also because it has a lack of "new" 
 marketing and
 a path to traction. Interminable discussion in these mailing 
 lists
 achieves nothing. Trying to tell C and C++ folk they should 
 change to D
 achieves nothing. Having a reputation for internal angst and a 
 bad
 garbage collector achieves huge negative waves. A language 11 
 years
 old and still in the same "breaking change" situation as Rust, 
 yet
 claiming to be production ready isn't helping. Conversely Dub 
 helps
 the D cause, code.dlang.org helps the D cause.

 What D needs though is some high profile people doing high 
 profile
 projects to create a sense of newness. This is the lesson D 
 needs to
 take from Go and Rust. Make use of hype rather than just 
 complaining
 about it. Set situations up that can be hyped. Hype is after 
 all just
 over-enthusiastic marketing.


I don't think "high profile people" matter, but yes, D will only 
succeed if it can generate some successful killer apps, ie what 
you call "high profile projects," though I'd add the qualifier of 
actually making money not just getting big investment.

But in the meantime, what you label "interminable discussion" is 
often people trying to figure out how to make D better in the 
interim.  Anytime you're working with other people, you need to 
talk to them first before you go do stuff.  Perhaps many here 
talk too much and don't contribute much code, granted, but a lot 
of it is enthusiasts putting forth their ideas and opinions for 
everyone else to chew on, which can have real value.  Nothing 
wrong with "internal angst," as quality only comes from such 
criticism and reflection, though like anything else, it can be 
overdone.

Sure, actual software like dub often helps more, but that often 
starts with a discussion.


 So what is the D USP on which hype can be hung?


Native efficiency combined with expressiveness and ease of use, 
as the front page says.  That's too general-purpose to just go 
build some specialized app like docker, but in the long run may 
lead to much bigger wins.
Dec 21 2014
parent reply "matovitch" <camille.brugel laposte.net> writes:
On Sunday, 21 December 2014 at 11:18:43 UTC, Joakim wrote:

 Native efficiency combined with expressiveness and ease of use, 
 as the front page says.  That's too general-purpose to just go 
 build some specialized app like docker, but in the long run may 
 lead to much bigger wins.


I think so too, D aims at a broader goal than most of the new 
languages out there.
I find the people in here quite grumpy these days. D is already a 
great usable and enjoyable language. I agree that some features 
should be removed and other extended for closure. But it's 
nothing that can't be achived in a few years.
Dec 21 2014
parent "Laeeth Isharc" <Laeeth.nospam nospam-laeeth.com> writes:
On Sunday, 21 December 2014 at 11:33:05 UTC, matovitch wrote:

 On Sunday, 21 December 2014 at 11:18:43 UTC, Joakim wrote:

 Native efficiency combined with expressiveness and ease of 
 use, as the front page says.  That's too general-purpose to 
 just go build some specialized app like docker, but in the 
 long run may lead to much bigger wins.


 I think so too, D aims at a broader goal than most of the new 
 languages out there.
 I find the people in here quite grumpy these days. D is already 
 a great usable and enjoyable language. I agree that some 
 features should be removed and other extended for closure. But 
 it's nothing that can't be achived in a few years.


Funnily enough, I had the same thoughts about grumpiness.  And it 
is not just the D forum, but this moment more generally, at least 
in the English-speaking world.  One of the ways I want to start 
using D is to do work on text analysis in order to better 
understand the influence of _affect_ on perception, economic 
fundamentals and market pricing.  I have not been able to find a 
better tool than D for this (only a bit more work to port the 
libraries).  Others are looking at this, but I think they start 
from a mechanistic idea that does not truly describe or lead to 
insights about mass human emotional dynamics.

For a concrete example of what I mean, it is in my view no 
coincidence that 2008 saw strife in the world of D (and, I 
gather, an explosion of bug reports) at the same time as 
gathering turmoil in financial markets.  The unfolding of a 
negative wave in affect, and its influence via the neuroeconomics 
phenomenon of misattribution of mood played a key part.

Back to D itself: comparing oneself with others may be 
destructive when the situation of others is different because one 
may learn a lesson that simply doesn't apply, even if at a 
pre-conscious level.  Andrei made this point some time ago.  And 
it is good that people argue if that means they have high 
standards and care about meeting them (see a recent book - 
something like the upside of your dark side), provided we use 
this energy to make things better, which, to this newcomer to D 
is what seems to be happening.

Social institutions ebb and flow.  And a language is a social 
institution.  The argument that because X has not gone anywhere 
means in the future it will not go anywhere is mistaken (whether 
or not the conclusion holds depends on other factors).  The right 
complemtentary factors as well as the right external conditions 
need to be in place before something reaches a point where it 
takes off publicly.  I don't think these conditions and factors 
were there before for D, and I wouldn't have bothered mentioning 
to people in finance.  But that is different now...

D isn't competing head on with any major language in its dominant 
use case, because that never favours the little guy.  Where any 
newcomer gets traction is at the fringes - see the Innovators 
Dilemma by Christensen.  It builds strength quietly in areas 
neglected by the dominant player, and uses the table scraps to 
create something of intrinsically great future power later in its 
development.  I am no expert, but I am a thoughtful user, and I 
think for example one sees a little complacency in the neglect by 
senior people in Python of the need for raw power given its all 
I/O or done by the C library back end.  Many projects like cython 
and pypy, but from what I have been able to see for my uses they 
are inferior to doing it all in D.

One should look at the notable relative success stories too - do 
more of what is working than necessarily be all things to all 
men.  Sociomantic, adroll, Facebook?  Seems like if D has an edge 
in these areas, its not a domain that is going to be shrinking in 
the next few years...
Dec 21 2014
prev sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Sunday, 21 December 2014 at 10:26:45 UTC, Russel Winder via 
Digitalmars-d wrote:

 to C++14 rather than D. Most C people will move to Go rather 
 than C++ or D.


I would not use Go for anything I would consider C for atm, but I 
will move some stuff from Python to Go when it is supported on 
GAE…

D could find it's own niche in a competing cloud solution, like 
Amazon WS, if it was deliberately targeted and thus the most 
convenient language on the platform.

Being the most convinient language for a platform is the killer 
app par excellence, but you need to be stable, production ready 
and focused to do it, which requires planning!


 Perhaps like Haskell, D is doomed to be a language used by few, 
 but
 having enormous influence on other languages that are used by 
 many.


What language-features are unique to D?


 achieves nothing. Having a reputation for internal angst and a 
 bad
 garbage collector achieves huge negative waves. A language 11 
 years
 old and still in the same "breaking change" situation as Rust, 
 yet
 claiming to be production ready isn't helping.


I think you overestimate how well known D is among the average 
programmer. If being old is the problem, then all you need to do 
is clean up the syntax and call it D++. However, being old is not 
the real issue.


 projects to create a sense of newness. This is the lesson D 
 needs to
 take from Go and Rust. Make use of hype rather than just 
 complaining about it.


Go has had stable supported releases for many years and supports 
doing stuff that other languages either make hard or slow. So Go 
is acceptable for commercial uptake even though there are quite a 
lot of annoying deliberate minimalistic design flaws that would 
otherwise turn me off: like being forced to use capitalized 
symbol names, not being able to convert bools into ints, not 
having assert, etc. Go is not a great language, but the 
developers are doing the right things: Go is stable, supported, 
focus and the direction of Go is clearly communicated ahead of 
time.
Dec 21 2014
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Saturday, 20 December 2014 at 15:14:28 UTC, Bienlein wrote:

 On Saturday, 20 December 2014 at 14:06:51 UTC, Paulo Pinto 
 wrote:


That is why I seldom buy into hype driven development.


 Okay, so Docker is hype? Have you seen the impact of it? Every 
 Java magazine has articles about Docker. And that is not 
 because Java people had an interest in it, because it is 
 written in Go. It is because of its business value.

 Have a look at all the job offers for Go developers here: 
 http://www.golangprojects.com. All those jobs are the result of 
 some hype.


This is very definition of hype. Yes, Go is hugely overblown and 
it has nothing to do with any of its technical features. Only 
business value Go truly has is simplicity and even that doesn't 
matter in practice.

Please stop pretending technical features have any major impact 
on popularity.
Dec 21 2014
parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sun, 2014-12-21 at 09:30 +0000, Dicebot via Digitalmars-d wrote:

 […]
 
 This is very definition of hype. Yes, Go is hugely overblown and it 
 has nothing to do with any of its technical features. Only business 
 value Go truly has is simplicity and even that doesn't matter in 
 practice.


Sorry, but wrong and wrong. Go has a model of concurrency and 
parallelism that works very well and no other language has, so Go has 
technical merit. Go's simplicity is a huge selling point. C 
programmers failed to move to C++ exactly because C was simple and C++ 
wasn't. Go provides these followers of simplicity enough new stuff to 
move from the over-simple C. So basically Go has achieved what D has 
not.


 Please stop pretending technical features have any major impact on 
 popularity.


Not entirely correct but it is certainly the case that a language 
pushed by a major player will win over an unmarketed one even if 
technical arguments might imply the opposite.

This is not just technical vs. marketing (aka hype), reality is a mix 
of both. No programming language gets traction purely on technical 
merit, but bad languages do not gain traction based purely on 
marketing.

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Dec 21 2014
parent "Dicebot" <public dicebot.lv> writes:
On Sunday, 21 December 2014 at 10:33:09 UTC, Russel Winder via 
Digitalmars-d wrote:

 On Sun, 2014-12-21 at 09:30 +0000, Dicebot via Digitalmars-d 
 wrote:

 […]
 
 This is very definition of hype. Yes, Go is hugely overblown 
 and it has nothing to do with any of its technical features. 
 Only business value Go truly has is simplicity and even that 
 doesn't matter in practice.


 Sorry, but wrong and wrong. Go has a model of concurrency and
 parallelism that works very well and no other language has, so 
 Go has
 technical merit. Go's simplicity is a huge selling point. C
 programmers failed to move to C++ exactly because C was simple 
 and C++
 wasn't. Go provides these followers of simplicity enough new 
 stuff to
 move from the over-simple C. So basically Go has achieved what 
 D has
 not.


I was referring to "doesn't matter in practice for gaining 
popularity" not "doesn't matter in practice for development".


 No programming language gets traction purely on technical
 merit, but bad languages do not gain traction based purely on
 marketing.


This does not match my perspective at all. I see absolutely zero 
correlation between technical quality of programming languages 
and their resulting market success - it was always about good 
marketing, viral effect, catching the niche and so on.

Which is not surprising because most developers out there lack 
competence to effectively reason why advantages and disadvantages 
of given language for their projects and thus following the hype 
becomes only safe strategy.
Dec 21 2014
prev sibling next sibling parent reply "Bienlein" <jeti789 web.de> writes:
People have already suggested you to actually try vibe.d at 
least once before repeating "CSP is necessary for easy async" 
mantra.


I was trying to point out in some previous thread that the value 
of CSP is that concurrent things from the code looks like 

sync<< calls (not async, but sync). The statement above again 




says async and not sync (in "CSP is necessary for easy async 
mantra."). So, I'm not sure the point was understood.

Asynchronous programming is very difficult to get right and also 
inherently difficult. Programming with channels where things look 
like >>synchronous calls<< make concurrent programming immensely 
easier than with asynchronous programming. If you have done 
asynchronous programming for some years and then only spend 1/2 h 
looking at concurrency in Go you will grasp immediately that this 
is a lot lot simpler. All cores are being made used of very 
evenly out of the box and are constantly under high load. You 
have to work very hard for long time to achieve the same in 

conventional. With CSP-style concurrency in Go it is a lot easier 
to write concurrent server side applications and whatever you do 
can hold 40'000 network connections out of the box. Yes, you can 
do that with vibe.d as well. But for Go you only need to learn a 
drop simple language and you can start writing your server 
application, because all you need for concurrency is in the 
language.

One idea would be to add a drop dead simple abstraction layer for 
vibe.d to provide the same and sell D as a language for server 
side development like Go. There is a need for a unique selling 
point. Let's say the guys at Docker had chosen D, because it had 
that already. Then they would realize that they also can use D 
for general purpose programming and be happy. But first there has 
to be a unique selling point. The selling point of a better C++ 
has not worked out. You have to accept that and move on. Not 
accepting that time moves on is not an option.


Sorry, but wrong and wrong. Go has a model of concurrency and 
parallelism that works very well and no other language has, so 
Go has technical merit.


The technical merit is in the concurrency model as already said 
in the statement above. And currently is the time of server side 
software development. When C++ was started it was time for some 
better C. That time is over. Things change constantly and there 
is nothing you can do about that. You can accept that things have 
moved on and make use of the new chance of server side 
programming as a new selling point or continue living in the 
past. Go might be simplistic. So add CSP-style channels to D and 
you can overtake Go in all respects very easily. Besides, Haskell 
also has channel-based inter-process communication. If that is 
not academical/scientiic backing then I don't know.
Dec 22 2014
next sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 22 Dec 2014 08:51:15 +0000
Bienlein via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 But for Go you only need to learn a=20
 drop simple language and you can start writing your server=20
 application, because all you need for concurrency is in the=20
 language.


i can assure you that "concurency in the language" is not the only
thing one needs to know before "start writing a server". you keep
telling that everything else in Go is so cheap to learn, so only CSP
matters. oh, really? Go can magically do all header parsing, database
management and other things for me? or we talking about "echo" servers?

Go is just hyped, that's all. there is NOTHING hard in creating simple
HTTP(S) server with templated pages, forms and data processing with
vibe.d. hey, it even has a sample of such server out of the box! it's
dead easy. and vibe.d can utilize threads to use all CPU cores (you
will lost some handyness here, but hey: don't use global variables! ;-).

even adding the whole Go to D will not make D overtake Go. Go is hyped.
D is not. that's all.
Dec 22 2014
parent reply "Bienlein" <jeti789 web.de> writes:
On Monday, 22 December 2014 at 21:46:48 UTC, ketmar via 
Digitalmars-d wrote:


i can assure you that "concurency in the language" is not the 
only
thing one needs to know before "start writing a server". you keep
telling that everything else in Go is so cheap to learn, so only 
CSP
matters. oh, really? Go can magically do all header parsing, 
database
management and other things for me? or we talking about "echo" 
servers?


Go does have good libraries for networking and support for REST, 
WS, messaging systems, bindings to other messaging systems, and 
all that stuff. I remember that even Walter or Andrei 
acknowledged that themselves somewhere in a post in this forum. 
To me Go is too simplistic. Everytime I try to like it I can't 
resist to say "No, I can't continue with this. It's just too 
minimalistic.". But they have a true selling point which is 
developing server side software and they have the batteries 
included for that.

What I'm saying is that being good at everything is good, but 
only a true selling point would receive people's attention. 
That's the way it is. Making D fit for server side development is 
a suggestion of mine. It seems to me something that has traction 
and will continue to have so unless the Internet dies a sudden 
death. There might be other even better ideas what could be 
selling points, but continuing with being good at everything and 
hoping that one day a big spender will come along might in the 
end not work out and result in a great loss of time. I don't want 
to appear harsh. It only seems to me that I wasn't able to bring 
my point across.

Cheers, Bienlein
Dec 22 2014
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 23 December 2014 at 07:57:22 UTC, Bienlein wrote:

 What I'm saying is that being good at everything is good, but 
 only a true selling point would receive people's attention. 
 That's the way it is. Making D fit for server side development 
 is a suggestion of mine.


Yes, responsive servers such as game servers would be a nice 
niche, but good auto-vectorization support is needed to perform 
well even there.

Interactive applications and game clients need a lot more support 
both in terms of platforms/frameworks, portability and tooling.
Dec 23 2014
prev sibling parent "Joakim" <dlang joakim.fea.st> writes:
On Tuesday, 23 December 2014 at 07:57:22 UTC, Bienlein wrote:

 What I'm saying is that being good at everything is good, but 
 only a true selling point would receive people's attention. 
 That's the way it is. Making D fit for server side development 
 is a suggestion of mine. It seems to me something that has 
 traction and will continue to have so unless the Internet dies 
 a sudden death. There might be other even better ideas what 
 could be selling points, but continuing with being good at 
 everything and hoping that one day a big spender will come 
 along might in the end not work out and result in a great loss 
 of time. I don't want to appear harsh. It only seems to me that 
 I wasn't able to bring my point across.


You have a point that from a marketing/deployment perspective it 
is better to focus on one niche and do well there, then expand 
outwards, a point Ola has made before.  It is tougher to get 
potential users to focus on quality across the board, rather than 
one unique selling point, as you say.

But D has a much more ambitious goal, to be a better 
general-purpose programming language.  That has already been 
focused on the server to some extent, with vibe.d and the success 
of Sociomantic's real-time ad platform.  The problem with 
starting in a niche is that you can get too optimized for that 
niche and have trouble undoing those decisions later to become 
more general-purpose.  Is there any realistic chance that Go ever 
takes on a more general-purpose language like C++?  Probably not.

Walter and Andrei know what they're doing, but they need help 
building that vision, especially given the quality of 
implementation issues everyone is pointing out.  Hopefully enough 
people agree with that vision that they pitch in to help build 
it.  Success at building a general-purpose language will not come 
right away, but if and when it comes, it's much bigger and 
longer-lasting. :)
Dec 23 2014
prev sibling next sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 2014-12-22 at 23:46 +0200, ketmar via Digitalmars-d wrote:

 […]
 matters. oh, really? Go can magically do all header parsing, 
 database management and other things for me? or we talking about 
 "echo" servers?


What happened was that a lot of people interested in all this HTTP 
bullshit, SQL dross, UI using Qt, and Go, and wrote a lot of libraries 
that everyone can use. So yes Go can do all that magic stuff – not 
just echo servers.


 Go is just hyped, that's all. there is NOTHING hard in creating 
 simple HTTP(S) server with templated pages, forms and data 
 processing with vibe.d. hey, it even has a sample of such server out 
 of the box! it's dead easy. and vibe.d can utilize threads to use 
 all CPU cores (you will lost some handyness here, but hey: don't use 
 global variables! ;-).


I have no doubt that Vibe.d can do this. If there was a way of mocking 
(so that you can run integration tests without the actual network) 
with Vibe.d I would be having a play with it, but there isn't, so I am 
not.


 even adding the whole Go to D will not make D overtake Go. Go is 
 hyped. D is not. that's all.


At this stage hype or not is a complete irrelevance, the point is that 
Go has a lot of people writing a lot of software for wide availability 
and use. D…is probably a far better language, but…

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Dec 23 2014
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tuesday, 23 December 2014 at 17:01:13 UTC, Russel Winder via 
Digitalmars-d wrote:

 If there was a way of mocking
 (so that you can run integration tests without the actual 
 network)


With my cgi.d, I made a command line interface that triggers the 
library the same as a network does. This works even if you 
compile it with the embedded http server:

$ ./hellocgi  GET / foo=bar
Cache-Control: private, no-cache="set-cookie"
Expires: 0
Pragma: no-cache
Content-Type: text/html; charset=utf-8

hello


It was really easy for me to implement and it gives easy access 
to any function for testing and debugging. It also lets me use 
the shell as a kind of web console too.

This is something that often amazes me that everyone doesn't do.
Dec 23 2014
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 12/23/14, 2:08 PM, Adam D. Ruppe wrote:

 On Tuesday, 23 December 2014 at 17:01:13 UTC, Russel Winder via
 Digitalmars-d wrote:

 If there was a way of mocking
 (so that you can run integration tests without the actual network)


 With my cgi.d, I made a command line interface that triggers the library
 the same as a network does. This works even if you compile it with the
 embedded http server:

 $ ./hellocgi  GET / foo=bar
 Cache-Control: private, no-cache="set-cookie"
 Expires: 0
 Pragma: no-cache
 Content-Type: text/html; charset=utf-8

 hello


 It was really easy for me to implement and it gives easy access to any
 function for testing and debugging. It also lets me use the shell as a
 kind of web console too.

 This is something that often amazes me that everyone doesn't do.


This looks interesting.

How do you specify what the mock should respond?
Dec 23 2014
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tuesday, 23 December 2014 at 17:37:57 UTC, Ary Borenszweig 
wrote:

 How do you specify what the mock should respond?


I'd just grep it or something like that. The main thing with this 
bit though is just not needing additional network programs to get 
a response - I typically use this functionality to load up the 
program in a debugger easily.
Dec 23 2014
prev sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 23 Dec 2014 17:01:02 +0000
Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 On Mon, 2014-12-22 at 23:46 +0200, ketmar via Digitalmars-d wrote:

 [=E2=80=A6]
 matters. oh, really? Go can magically do all header parsing,=20
 database management and other things for me? or we talking about=20
 "echo" servers?


=20
 What happened was that a lot of people interested in all this HTTP=20
 bullshit, SQL dross, UI using Qt, and Go, and wrote a lot of libraries=20
 that everyone can use. So yes Go can do all that magic stuff =E2=80=93 no=


t=20

 just echo servers.


and so D. and i still has to learn libraries for all that. yet people
talking Go being magic bullet: just use concurency and that's all!

nope. that's not all. that's not even the biggest part.


 I have no doubt that Vibe.d can do this. If there was a way of mocking=20
 (so that you can run integration tests without the actual network)=20
 with Vibe.d I would be having a play with it, but there isn't, so I am=20
 not.


isn't localhost enough? sure, you can test all the logic without
network at all, and then use some of the available packages to test web
part.


 even adding the whole Go to D will not make D overtake Go. Go is=20
 hyped. D is not. that's all.


=20
 At this stage hype or not is a complete irrelevance, the point is that=20
 Go has a lot of people writing a lot of software for wide availability=20
 and use. D=E2=80=A6is probably a far better language, but=E2=80=A6


but it has no Google behind. the recipe is simple and easy:
1. take gw-basic.
2. take Google.
3. let Google to throw money into gw-basic hype.
4. people start writing alot of software in gw-basic.

there is no direct corellation between "being good in technical sense"
and "being successfull". but there is such corellation between
"advertising by Big Player" and "being successfull".

most people are morons. i'm not talking about Go uses here, not at all,
i'm talking about the attitude like "everybody talking about X! Big
Player supporting X! X is great!" here X can be anything.
Dec 23 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 23 December 2014 at 19:14:02 UTC, ketmar via 
Digitalmars-d wrote:

 and so D. and i still has to learn libraries for all that. yet 
 people
 talking Go being magic bullet: just use concurency and that's 
 all!

 nope. that's not all. that's not even the biggest part.


Library support is really important when doing web servers and 
integration with existing systems and workflows. This is not an 
area where D will be able to compete anytime soon, it is a 
crowded space: Java, Python, Ruby, Php, node.js and eventually 
Go. I have to connect to Google infrastructure, to legacy 
databases like Pervasive, parse Excel files, add encryption cross 
platform etc... Every other project might need a new library if 
you are to integrate with existing solutions, so there is really 
no end to what you need to support...


Reality check on stuff that could be relevant for a server:

https://github.com/trending?l=go&since=monthly

4943 stars for Go
2947 stars for Rocket
1029 stars for Docker
747 stars for  ssh-chat
622 stars for Kubernetes
672 stars for Jason
672 stars for aws-go
594 stars for bone
405 stars for influxdb
364 stars for etcd
356 stars for surgemq
246 stars for kite

https://github.com/trending?l=d&since=monthly

28 stars for vibe.d
10 stars for phobos
6 stars for druntime
6 stars for libasync
5 stars for arsd

That's a wipe out...


 1. take gw-basic.
 2. take Google.
 3. let Google to throw money into gw-basic hype.
 4. people start writing alot of software in gw-basic.

 there is no direct corellation between "being good in technical 
 sense"
 and "being successfull". but there is such corellation between
 "advertising by Big Player" and "being successfull".


There is a strong correlation between not having a stable release 
and getting less attention from people who write libraries and 
frameworks for commercial use.

Besides, Basic got traction at a time where people charged for 
good languages, it was available for free and was not too 
demanding on resources so it was built into the ROM on basically 
all home computers in the 80s. That's how Basic got big.
Dec 23 2014
next sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 23 Dec 2014 19:54:19 +0000
via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 On Tuesday, 23 December 2014 at 19:14:02 UTC, ketmar via=20
 Digitalmars-d wrote:

 and so D. and i still has to learn libraries for all that. yet=20
 people
 talking Go being magic bullet: just use concurency and that's=20
 all!

 nope. that's not all. that's not even the biggest part.


=20
 Library support is really important when doing web servers and=20
 integration with existing systems and workflows.


and learning libraries is not free (if such libraies exists in the
first place). yet people talking about Go tend to ignore this fact.


 This is not an area where D will be able to compete anytime soon


with all the C support libraries available D is not in a bad position.


 I have to connect to Google infrastructure


no wonder google support this with one of their pet language. ;-)


 to legacy databases like Pervasive


does it have C interface library?


 parse Excel files


good god!


 add encryption cross platform


in a web-server? O_O


 Every other project might need a new library if=20
 you are to integrate with existing solutions, so there is really=20
 no end to what you need to support...


that's where C libraries comes to rescue.


 Reality check on stuff that could be relevant for a server:
 https://github.com/trending?l=3Dgo&since=3Dmonthly


yes, this is good indicator of "hypeness". that's all.


 1. take gw-basic.
 2. take Google.
 3. let Google to throw money into gw-basic hype.
 4. people start writing alot of software in gw-basic.

 there is no direct corellation between "being good in technical=20
 sense"
 and "being successfull". but there is such corellation between
 "advertising by Big Player" and "being successfull".


 There is a strong correlation between not having a stable release=20
 and getting less attention from people who write libraries and=20
 frameworks for commercial use.


i personally don't give a shit about that. i already expressed my
attitude to "commercial use", even though i'm an employer myself.


 Besides, Basic got traction at a time where people charged for=20
 good languages, it was available for free and was not too=20
 demanding on resources so it was built into the ROM on basically=20
 all home computers in the 80s. That's how Basic got big.


i took gw-basic as a widely-known sample of bad language. you can
replace it with your language of choice if you want, it doesn't matter.
Dec 23 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 23 December 2014 at 20:12:20 UTC, ketmar via 
Digitalmars-d wrote:

 and learning libraries is not free (if such libraies exists in 
 the
 first place). yet people talking about Go tend to ignore this 
 fact.


Yes, that is true. I tend to avoid frameworks and look for 
focused libraries. Go eco system is in the early stage, but there 
are several light weight frameworks that looks quite promising.


 with all the C support libraries available D is not in a bad 
 position.


That's great in theory, but basic C-libraries are not as cheap to 
get working as an existing binding with a convenient abstraction 
on top if you start counting hours.


 I have to connect to Google infrastructure


 no wonder google support this with one of their pet language. 
 ;-)


Indeed, and you can probably expect the same from Azure, so that 
leaves D with AWS as the only big option. Yet, there is no solid 
AWS support in sight...


 add encryption cross platform


 in a web-server? O_O


Easy integration across unsecured networks.


 Every other project might need a new library if you are to 
 integrate with existing solutions, so there is really no end 
 to what you need to support...


 that's where C libraries comes to rescue.


Actually no. Some stuff actually requires a mix of languages and 
a platform that supports the mix makes it a lot easier (cheaper).


 Reality check on stuff that could be relevant for a server:
 https://github.com/trending?l=go&since=monthly


 yes, this is good indicator of "hypeness". that's all.


It is a good indicator of activity and direction.
Dec 23 2014
parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 23 Dec 2014 20:23:07 +0000
via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 with all the C support libraries available D is not in a bad=20
 position.


 That's great in theory, but basic C-libraries are not as cheap to=20
 get working as an existing binding with a convenient abstraction=20
 on top if you start counting hours.


with good overall design plugging in a library is a matter of days.
sure, if you choose to not abstract your needs and go with some
library's API directly, this will be a PITA.


 Indeed, and you can probably expect the same from Azure, so that=20
 leaves D with AWS as the only big option. Yet, there is no solid=20
 AWS support in sight...


all that cloudy thing is another hype. ;-)


 add encryption cross platform


 in a web-server? O_O


 Easy integration across unsecured networks.


ahem... encryption algorithms are platform-independent. and your server
is running on known platform. am i missing something here?


 Every other project might need a new library if you are to=20
 integrate with existing solutions, so there is really no end=20
 to what you need to support...


 that's where C libraries comes to rescue.


 Actually no. Some stuff actually requires a mix of languages and=20
 a platform that supports the mix makes it a lot easier (cheaper).


the solution is easy: don't use things that have no C libraries. C is
"linuga franca" in this case.


 Reality check on stuff that could be relevant for a server:
 https://github.com/trending?l=3Dgo&since=3Dmonthly


 yes, this is good indicator of "hypeness". that's all.


 It is a good indicator of activity and direction.


let me quote myself: "most people are morons." ;-)
Dec 23 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 23 December 2014 at 20:36:35 UTC, ketmar via 
Digitalmars-d wrote:

 all that cloudy thing is another hype. ;-)


It is hyped, but it is going to grow since businesses can save 
money on it. HP's The Machine also appears to be cloud centric. 
It is pretty much well established across the board as the future 
of computing.


 ahem... encryption algorithms are platform-independent. and 
 your server
 is running on known platform. am i missing something here?


Not a big deal, but I'd rather have the same symmetric encryption 
code on all platforms and be sure that the implementation is 100% 
compatible with no corner cases.

This goes for all libraries:

I'd rather go for libraries+bindings that are tested by 1000s of 
projects, not 50 or 100.

I'd rather use a language where there are multiple competing 
libraries covering the same functionality so that I have another 
place to go if one library turns out to be buggy.

If D is spread thin all over the place, then you simply will not 
get the kind of attractive eco system that Go is building.

Having only one option is good enough for a hobby project. Having 
only one option when you have signed a contract is a liability.


 the solution is easy: don't use things that have no C 
 libraries. C is "linuga franca" in this case.


If the customer wants a full featured web-forum for support 
integrated into his marketing web site... what options do you 
actually have? One really sucky language... Not Go. Not Java. Not 
Ruby. Not Python. Not D...


 Reality check on stuff that could be relevant for a server:
 https://github.com/trending?l=go&since=monthly


 yes, this is good indicator of "hypeness". that's all.


 It is a good indicator of activity and direction.


 let me quote myself: "most people are morons." ;-)


We are all morons by thinking that morons cannot create great 
things...
Dec 23 2014
parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 23 Dec 2014 21:05:04 +0000
via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 On Tuesday, 23 December 2014 at 20:36:35 UTC, ketmar via=20
 Digitalmars-d wrote:

 all that cloudy thing is another hype. ;-)


 It is hyped, but it is going to grow since businesses can save=20
 money on it. HP's The Machine also appears to be cloud centric.=20
 It is pretty much well established across the board as the future=20
 of computing.


i've heard this before. you know, "mainframes will die, personal
computers is the future of computing". and now i see "the revenge of
mainframes". i bet we'll see another wave of this, this time with
"decentralized networks" (nope, "clouds" are not about that).


 ahem... encryption algorithms are platform-independent. and=20
 your server
 is running on known platform. am i missing something here?


 Not a big deal, but I'd rather have the same symmetric encryption=20
 code on all platforms and be sure that the implementation is 100%=20
 compatible with no corner cases.


NaCl/libsodium is your friend! ;-)


 Having only one option is good enough for a hobby project. Having=20
 only one option when you have signed a contract is a liability.


seeing the kind of people using Go and other overhyped things... i'd
better go with one C library than with 100 Go libraries. ;-)


 the solution is easy: don't use things that have no C=20
 libraries. C is "linuga franca" in this case.


 If the customer wants a full featured web-forum for support=20
 integrated into his marketing web site... what options do you=20
 actually have?


don't work with that customer. that is exactly what we doing: either we
do things our way or simply don't take the work.


 We are all morons by thinking that morons cannot create great=20
 things...


morons can create great things. the trouble is that morons don't know
how to use the things they created. ;-)
Dec 23 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 23 December 2014 at 21:48:32 UTC, ketmar via 
Digitalmars-d wrote:

 computers is the future of computing". and now i see "the 
 revenge of
 mainframes". i bet we'll see another wave of this, this time 
 with
 "decentralized networks" (nope, "clouds" are not about that).


With new tech changes will come for sure, like break throughs in 
AI, real time raytracing hardware or memristors with integrated 
logic... We'll see (or our kids will).


 morons can create great things. the trouble is that morons 
 don't know how to use the things they created. ;-)


They do, but I get a headache when looking at the source code... 
(e.g. wordpress...)
Dec 23 2014
parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 23 Dec 2014 22:16:32 +0000
via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 On Tuesday, 23 December 2014 at 21:48:32 UTC, ketmar via=20
 Digitalmars-d wrote:

 computers is the future of computing". and now i see "the=20
 revenge of
 mainframes". i bet we'll see another wave of this, this time=20
 with
 "decentralized networks" (nope, "clouds" are not about that).


=20
 With new tech changes will come for sure, like break throughs in=20
 AI, real time raytracing hardware or memristors with integrated=20
 logic... We'll see (or our kids will).


all the tech for decentralized mesh networks is already here. and people
starting to understand that centralized networks/servers sux.

i see that decentralized services are slowly rising: tox, bitmessage,
diaspora... you got the idea. the snow avalanche is already started.

it worth noting that each "privacy information leaking" adds to it.
Dec 23 2014
parent reply "Joakim" <dlang joakim.fea.st> writes:
On Tuesday, 23 December 2014 at 23:32:59 UTC, ketmar via 
Digitalmars-d wrote:

 On Tue, 23 Dec 2014 22:16:32 +0000
 via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 On Tuesday, 23 December 2014 at 21:48:32 UTC, ketmar via 
 Digitalmars-d wrote:

 computers is the future of computing". and now i see "the 
 revenge of
 mainframes". i bet we'll see another wave of this, this time 
 with
 "decentralized networks" (nope, "clouds" are not about that).


 
 With new tech changes will come for sure, like break throughs 
 in AI, real time raytracing hardware or memristors with 
 integrated logic... We'll see (or our kids will).


 all the tech for decentralized mesh networks is already here. 
 and people
 starting to understand that centralized networks/servers sux.

 i see that decentralized services are slowly rising: tox, 
 bitmessage,
 diaspora... you got the idea. the snow avalanche is already 
 started.

 it worth noting that each "privacy information leaking" adds to 
 it.


Good point, I too think this is going to be big soon, though the 
point of the spear for me is bitcoin and all its copycats.  
Torrents did it first but haven't really taken the next step.  
The cloud will wane as a result, as you say, while still having a 
role to play.
Dec 24 2014
parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 24 Dec 2014 16:53:16 +0000
Joakim via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 Good point, I too think this is going to be big soon, though the=20
 point of the spear for me is bitcoin and all its copycats. =20
 Torrents did it first but haven't really taken the next step. =20
 The cloud will wane as a result, as you say, while still having a=20
 role to play.


i completely agree with you, that is exactly what i mean. i just forgot
about cryptocurrencies as they are almost the "normal everyday thing"
already. ;-) see, banks and governments already trying to "regulate"
bitcoin instead of ignoring it as a silly geek toy.
Dec 24 2014
prev sibling next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tuesday, 23 December 2014 at 19:54:20 UTC, Ola Fosheim Grøstad 
wrote:

 5 stars for arsd


I'm almost famous!

I actually seriously wonder how many users my random stuff has. 
Maybe I should set up an email list - when I make a breaking 
change, I often wonder how many people I'm inconveniencing... (I 
don't often make breaking changes, but I sometimes do.)
Dec 23 2014
next sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 23 Dec 2014 23:12:45 +0000
"Adam D. Ruppe via Digitalmars-d" <digitalmars-d puremagic.com> wrote:


 On Tuesday, 23 December 2014 at 19:54:20 UTC, Ola Fosheim Gr=C3=B8stad=20
 wrote:

 5 stars for arsd


=20
 I'm almost famous!
=20
 I actually seriously wonder how many users my random stuff has.=20
 Maybe I should set up an email list - when I make a breaking=20
 change, I often wonder how many people I'm inconveniencing... (I=20
 don't often make breaking changes, but I sometimes do.)


i'm using it from time to time. mostly html parser, but i'm watching
for your scripting language changes too.

as for now it's ok for me to take a look at 'git diff' if something
breaks. don't bother yourself with support list until there will be
alot of personal emails asking something again and again (or just
cursing for breaking the old code ;-).

your stuff is relatively easy to use and it's always fun to read your
source code. ;-)
Dec 23 2014
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tuesday, 23 December 2014 at 23:39:31 UTC, ketmar via 
Digitalmars-d wrote:

 i'm using it from time to time. mostly html parser, but i'm 
 watching for your scripting language changes too.


I love dom.d. IMO it is better at doing what javascript's job in 
the browser is supposed to be than Javascript itself with the 
dynamic properties and all that.

The script thing just recently got property support so I can use 
it with a native class for my little json web api inspector 
thingy. That will enable automatic wrapping of arbitrary D 
objects when I get back to it, perhaps even whole modules, so 
exposing D code to the script will become even easier!

BTW, A couple weeks ago, I reopened my old twitter account and I 
post a little D code update there too if you're interested:

https://twitter.com/adamdruppe

Other recent modules added are some audio and joystick support. 
(I'm gearing up to write another game in D, but this time, I'm 
not even going to use SDL!)


 alot of personal emails asking something again and again


I like those because they tell me what trouble people are having..
Dec 23 2014
parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 24 Dec 2014 04:55:09 +0000
"Adam D. Ruppe via Digitalmars-d" <digitalmars-d puremagic.com> wrote:


 I love dom.d. IMO it is better at doing what javascript's job in=20
 the browser is supposed to be than Javascript itself with the=20
 dynamic properties and all that.


the same for me. i'm not doing heavy dom jobs though.


 The script thing just recently got property support so I can use=20
 it with a native class for my little json web api inspector=20
 thingy. That will enable automatic wrapping of arbitrary D=20
 objects when I get back to it, perhaps even whole modules, so=20
 exposing D code to the script will become even easier!


yep, i've seen that in recent commits. inability to easily wrap native
structs/objects was one of the major drawbacks for me. i was thinking
about doing something with it myself, but... you know, lazyness and
such. ;-)


 Other recent modules added are some audio and joystick support.=20
 (I'm gearing up to write another game in D, but this time, I'm=20
 not even going to use SDL!)


i've seen that too, and was curious to see what's coming next. ;-)


 alot of personal emails asking something again and again


 I like those because they tell me what trouble people are having..


i meant that it may become boring to answer the same things again and
again.

for me the biggest trouble is that your things looks handy and
unencumbered, and it's hard to resist the temptation to write my own
versions. you know, "it looks so easy that i MUST write my own
variant". can you please make your interfaces convoluted and
heavy-weight? ;-)
Dec 23 2014
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 24 December 2014 at 05:26:21 UTC, ketmar via 
Digitalmars-d wrote:

 for me the biggest trouble is that your things looks handy and
 unencumbered, and it's hard to resist the temptation to write 
 my own versions.


That's part of why I do it the way I do: you are hopefully able 
to customize the code just using mine as a starting point for 
your own hack jobs. I kinda assume everyone who wants to use them 
takes a look through the source - that's why I leave comments! 
(and my lack of traditional documentation means eyeballing the 
source (or asking me) is really the only way to find the hidden 
features anyway)


 you know, "it looks so easy that i MUST write
 my own variant". can you please make your interfaces convoluted
 and heavy-weight? ;-)


But then even I would get annoyed with them and just write a 
simpler version anyway!

This is how I pick libraries:

try
      solveMyProblem(close_to_exactly);
catch(Exception e)
      writeln("this library sucks");
finally {
      do it myself with exactly what i need and little more
}


Yes, DIY is finally :P Unless the lib actually happens to solve 
what I want exactly and has no other hassle... which basically 
never happens... I end up doing it myself whether it sucks or is 
actually OK.

y'all should do it too, it is informative!
Dec 24 2014
next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 24 Dec 2014 20:50:17 +0000
"Adam D. Ruppe via Digitalmars-d" <digitalmars-d puremagic.com> wrote:


 Yes, DIY is finally :P Unless the lib actually happens to solve=20
 what I want exactly and has no other hassle... which basically=20
 never happens... I end up doing it myself whether it sucks or is=20
 actually OK.
=20
 y'all should do it too, it is informative!


same for me. most of my libraries (both published and private) was born
out of frustration. first i have to solve some task, then i found that
existing libraries sux, then i wrote a solution, and then i see that i
can turn this solution into a library. now the problem is solved
and i have a new library, tested with the actual data and solves
exactly what i need to solve, not "everything someone may want to
solve". win-win. ;-)
Dec 24 2014
prev sibling parent reply "brian" <brian infinityplusb.com> writes:
I know this thread is a little old now, and I'm not the most 
experienced programmer by a long shot, but I'll post my 2 cents 
from the n00b persepctive.

A question first: ... what do people actually have working in D?
I find very few "working examples" of things I want to do. Or 
things in general. That I can read and say "oooh that's close to 
what I want, I can tweak it a little here and there".

Eg.
I want a program to write tweets.
I can't just google "twitter example d" and find a nice starter 
program to connect a write a tweet.
Do the same with "twitter example java" and you'll probably have 
your problem solved within half an hour.
So in half an hour I have a java program, and not a d one. I'll 
probably make changes to my java one and grow that, rather than 
trying to rewrite it in D because I don't even know it will work.

The same can be said when I try to do other things too:
Like parse a webpage.
Or connect to APIs.
(maybe I'm constantly looking for things that other's don't do, 
but that's unlikely)

So for me, it's getting easier to solve my simple programming 
problems in other languages because I can find examples that a) 
others have posted and b) others have the same issues I face.
I can't find those things in D nearly as easily (is this a limit 
of searching the term "D" or dlang?)


 try
      solveMyProblem(close_to_exactly);
 catch(Exception e)
      writeln("this library sucks");
 finally {
      do it myself with exactly what i need and little more
 }


I'd *love* to be able to do this, but if libraries don't work, 
personally, I don't know where to start most of the time. What if 
there isn't a library at all? html headers, oauth, blah blah. I 
may as well build a rocket. I have plenty of projects where I hit 
a wall (which I don't think is necessarily a language thing, but 
trying to use D to get to something else/do something).

So in summary, from my perspective I find it difficult to solve 
the programming challenges I face, using D. Maybe that's a skill 
thing.
Lack of working examples makes taking that first leap daunting.
Lack of connectivity (to the things I want to connect to) is 
frustrating. Through googling, I'll be able to get something 
running quicker in another language than continue trying to get D 
to work.
If I find these issues, and I'm moderately intelligent, I'm sure 
others have the same issues.
I love the language, but if someone wanted a language to learn, I 
don't think I would recommend D. :(
Jan 13 2015
next sibling parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 14/01/2015 12:34 p.m., brian wrote:

 I know this thread is a little old now, and I'm not the most experienced
 programmer by a long shot, but I'll post my 2 cents from the n00b
 persepctive.

 A question first: ... what do people actually have working in D?
 I find very few "working examples" of things I want to do. Or things in
 general. That I can read and say "oooh that's close to what I want, I
 can tweak it a little here and there".

 Eg.
 I want a program to write tweets.
 I can't just google "twitter example d" and find a nice starter program
 to connect a write a tweet.
 Do the same with "twitter example java" and you'll probably have your
 problem solved within half an hour.
 So in half an hour I have a java program, and not a d one. I'll probably
 make changes to my java one and grow that, rather than trying to rewrite
 it in D because I don't even know it will work.

 The same can be said when I try to do other things too:
 Like parse a webpage.
 Or connect to APIs.
 (maybe I'm constantly looking for things that other's don't do, but
 that's unlikely)

 So for me, it's getting easier to solve my simple programming problems
 in other languages because I can find examples that a) others have
 posted and b) others have the same issues I face.
 I can't find those things in D nearly as easily (is this a limit of
 searching the term "D" or dlang?)


 try
      solveMyProblem(close_to_exactly);
 catch(Exception e)
      writeln("this library sucks");
 finally {
      do it myself with exactly what i need and little more
 }


 I'd *love* to be able to do this, but if libraries don't work,
 personally, I don't know where to start most of the time. What if there
 isn't a library at all? html headers, oauth, blah blah. I may as well
 build a rocket. I have plenty of projects where I hit a wall (which I
 don't think is necessarily a language thing, but trying to use D to get
 to something else/do something).

 So in summary, from my perspective I find it difficult to solve the
 programming challenges I face, using D. Maybe that's a skill thing.
 Lack of working examples makes taking that first leap daunting.
 Lack of connectivity (to the things I want to connect to) is
 frustrating. Through googling, I'll be able to get something running
 quicker in another language than continue trying to get D to work.
 If I find these issues, and I'm moderately intelligent, I'm sure others
 have the same issues.
 I love the language, but if someone wanted a language to learn, I don't
 think I would recommend D. :(


For my next book I was thinking about taking it from the point of view 
of cook book. I want to do X, how do I do it?
Which is exactly what you are wanting.
Point being not language orientated. More feature orientated.
Jan 13 2015
prev sibling next sibling parent reply "Joakim" <dlang joakim.fea.st> writes:
On Tuesday, 13 January 2015 at 23:34:40 UTC, brian wrote:

 I know this thread is a little old now, and I'm not the most 
 experienced programmer by a long shot, but I'll post my 2 cents 
 from the n00b persepctive.

 A question first: ... what do people actually have working in D?
 I find very few "working examples" of things I want to do. Or 
 things in general. That I can read and say "oooh that's close 
 to what I want, I can tweak it a little here and there".


Take a look at the official package registry, called dub:

http://code.dlang.org/


 Eg.
 I want a program to write tweets.
 I can't just google "twitter example d" and find a nice starter 
 program to connect a write a tweet.
 Do the same with "twitter example java" and you'll probably 
 have your problem solved within half an hour.
 So in half an hour I have a java program, and not a d one. I'll 
 probably make changes to my java one and grow that, rather than 
 trying to rewrite it in D because I don't even know it will 
 work.


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.  D would like to break out of that box and be 
such a language, but it's probably not going to have a bunch of 
code written for small jobs like that yet.


 The same can be said when I try to do other things too:
 Like parse a webpage.
 Or connect to APIs.
 (maybe I'm constantly looking for things that other's don't do, 
 but that's unlikely)


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.


 So for me, it's getting easier to solve my simple programming 
 problems in other languages because I can find examples that a) 
 others have posted and b) others have the same issues I face.
 I can't find those things in D nearly as easily (is this a 
 limit of searching the term "D" or dlang?)


 try
     solveMyProblem(close_to_exactly);
 catch(Exception e)
     writeln("this library sucks");
 finally {
     do it myself with exactly what i need and little more
 }


 I'd *love* to be able to do this, but if libraries don't work, 
 personally, I don't know where to start most of the time. What 
 if there isn't a library at all? html headers, oauth, blah 
 blah. I may as well build a rocket. I have plenty of projects 
 where I hit a wall (which I don't think is necessarily a 
 language thing, but trying to use D to get to something else/do 
 something).


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.

Also, maybe the D community doesn't put their code up for public 
consumption as much as some other language communities.  Could be 
another reason for the disparity, but just a stab in the dark: I 
have no idea if it's true.


 So in summary, from my perspective I find it difficult to solve 
 the programming challenges I face, using D. Maybe that's a 
 skill thing.
 Lack of working examples makes taking that first leap daunting.
 Lack of connectivity (to the things I want to connect to) is 
 frustrating. Through googling, I'll be able to get something 
 running quicker in another language than continue trying to get 
 D to work.
 If I find these issues, and I'm moderately intelligent, I'm 
 sure others have the same issues.
 I love the language, but if someone wanted a language to learn, 
 I don't think I would recommend D. :(


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.
Jan 13 2015
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.  D would like to break out of that box and 
 be such a language, but it's probably not going to have a bunch 
 of code written for small jobs like that yet.


I kinda agree, except:

«twitcurl is a pure C++ library for twitter APIs. twitcurl uses 
cURL for handling HTTP requests and responses.»

https://code.google.com/p/twitcurl/
https://dev.twitter.com/overview/api/twitter-libraries

And Go has two twitter libraries...

There were a lot more people doing cute stuff like that for D1, I 
think. It will probably come when D2 is more stable.
Jan 14 2015
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 14 January 2015 at 10:45:17 UTC, Ola Fosheim 
Grøstad wrote:

 «twitcurl is a pure C++ library for twitter APIs. twitcurl uses 
 cURL for handling HTTP requests and responses.»



I feel like I say this all the time.... but there's a twitter bit 
hidden in my misc. D modules, in oauth.d

https://github.com/adamdruppe/arsd/blob/master/oauth.d#L320

Call it:

tweet(twitter(apiKey, apiSecret), userToken, userSecret, "tweet 
message");

You can get the four tokens on dev.twitter.com, create an app 
then create your own access token. Plug them in and call the 
function:

https://twitter.com/adamdruppe/status/555738599069868033

It depends on curl.d, sha.d, and cgi.d from my repo.


You can also use oauth.d to retrieve tweets - use the tokens it 
provides for a call to curlOauth to the api function, then parse 
it with something like dom.d or jsvar.d (I think it gives XML but 
they might have changed that in the last year since I used it) 
and authorize users. Authorization is a bit tricky:

https://github.com/adamdruppe/arsd/blob/master/oauth.d#L343

and I don't have an example written up for them (I do, but it is 
in my closed source work projects so I'd have to clean it up 
before posting in public, I can do it later if you're 
interested), but you have to call step one, then step two when 
you get the answer to that. It will return the tokens. It assumes 
you're a web app using my cgi.d.
Jan 15 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 15 January 2015 at 14:53:23 UTC, Adam D. Ruppe wrote:

 On Wednesday, 14 January 2015 at 10:45:17 UTC, Ola Fosheim 
 Grøstad wrote:

 «twitcurl is a pure C++ library for twitter APIs. twitcurl 
 uses cURL for handling HTTP requests and responses.»



 I feel like I say this all the time.... but there's a twitter 
 bit hidden in my misc. D modules, in oauth.d

 https://github.com/adamdruppe/arsd/blob/master/oauth.d#L320


Sounds like perfect topic for your newsletter? :)
Jan 15 2015
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 15 January 2015 at 14:57:48 UTC, Ola Fosheim Grøstad 
wrote:

 Sounds like perfect topic for your newsletter? :)


I could totally fill in the "project spotlight" with stuff from 
that repo for at least a year, not even kidding. But I don't want 
it to be all about me! (and oauth.d isn't new, i wrote that like 
three years ago... it had to be updated a while ago because 
twitter deprecated v1 of their api, but other than that, it 
hasn't changed much)

Over the years though, I've written a lot of D programs and do my 
own libs as required. I've done 2d games, working on a 3d game 
now, web applications with social media interop for authorization 
and posting, email marketing, email parsing, I've written a 
terminal emulator, taskbar, the list goes on and on.

And only about 1/3 of the D code I've written is even on Github! 
(Of course, about half of my D code is totally uninteresting, 
closed source business logic stuff, though it would make nice 
examples to how to use the libraries for real world tasks...)



Let me give an outline of the misc modules to give you an idea of 
how varied this is:

audio.d, screen.d, engine.d - my old game stuff, wrapping SDL, 
works in D1 and D2 (or at least did last time I tried it about a 
year ago). Soon to be replaced by the dependency-free 
simpledisplay.d, simpleaudio.d, joystick.d combo.

bmp.d, png.d - read/write for bmp and image files.
jpg.d - partial read support for jpeg headers (just to get the 
size of the image).

cgi.d - basic module for making web apps. Includes cgi, fastcgi, 
scgi, and an embedded http server. Reads url encoded data, MIME 
data (for file uploads on the web), and has full URL parsing, 
among other things.

characterencodings.d - stuff for converting other strings to 
UTF-8. Supports about twenty other encodings based on webpage and 
email mining I've done in the past. Also has a lossy conversion 
as a catchall.

color.d - a color struct for RGBA, also does CSS color string 
read/writing, HSL <-> RGB, some color manipulation, alpha 
blending, and image base classes including palette to true color 
and true color to palette (quantization).

csv.d - simple csv reader, predates std.csv (and is a bit simpler)

curl.d - wrapper for libcurl (predates std.net.curl)

database.d - base class for RDBMS access. Also includes basic ORM 
and query builder in the form of DataObject and SelectBuilder. It 
is a simple, low-level wrapper of sql so you can manipulate it 
semantically more easily but you still need to understand sql to 
use it. (It also doesn't limit your options!)

mysql.d, postgres.d, mssql.d, sqlite.d - drivers for database.d 
(wrapping C libraries)

dom.d - XML and HTML parsing and manipulation, including CSS 
selectors and other tools that can help for implementing a 
browser. API inspired by modern Javascript DOM, capable of 
scraping tag soup web pages.

email.d - functions for reading and writing emails with MIME 
attachments, html and text versions, character sets. Can scrape 
mbox format, I used it to automatically monitor and reply to some 
email addresses sitting on the smtp server.

english.d - printing numbers in English

eventloop.d - an epoll based event loop for responding to and 
sending events. My other modules can optionally tie into it, so 
you can have one event loop driving files, networks, terminals, X 
windows, and more.

html.d - stuff for html and CSS manipulation. Includes the Css 
Macro Expander, which is similar to functionality offered by SASS 
(also available as a stand alone dub package on code.dlang.org 
btw), and a Javascript macro expander which you can use to add 
stuff like foreach to that language. Also has HTML sanitization 
based on a full parser and whitelist.

htmltotext.d - converts html to plain text so you can display it 
in a terminal or an email, etc.

http.d - my old standalone http client. Does NOT depend on curl. 
I'm in the process of replacing it with http2.d, which has a more 
flexible, asynchronous api (still dependency free, though I have 
to add OpenSSL and SChannel support for SSL soon). http2 provides 
an object that kinda works like a browser -it can understand 
relative links, maintain cookies, etc.

joystick.d - code for accessing XBox 360 controllers (and similar 
ones, like the PS1 controller via usb) on Windows and Linux.

jsvar.d - a var type similar to Javascript, usable in D. Can be 
used to read and write JSON with a natural syntax and other 
dynamic type tasks.

mangle.d - mangles a D name

minigui.d - small, dependency-free (except for simpledisplay.d 
and color.d but doesn't even need Phobos) widget set, using Win32 
native widgets where possible, custom Xlib based ones otherwise. 
Still work in progress but already works for some basic forms.

oauth.d - OAuth library for client and server. I've used it with 
Twitter, Linked In, AWeber, Facebook, and more. Has specific 
functions for the Facebook Graph API, tweeting, serving oauth 1.0 
requests, and doing the OAuth authorization flow. Depends on the 
mhash C library.

querygenerator.d - a user-contributed module for sql query 
generation

rpc.d - a remote procedure call library for D, making interfaces 
available across the network. You might prefer the apache thrift 
bindings or something, this is a custom job that I haven't 
seriously used.

script.d - a script interpeter based on jsvar.d. The script 
language is like a cross of D and Javascript. Made for API 
convenience - very very easy to embed in an application.

sha.d - implementation of SHA1 and SHA2 in pure D (well and some 
inline asm).

simpleaudio.d - access to WinMM on Windows and ALSA on Linux for 
waveform sound I/O and MIDI I/O.

simpledisplay.d - dependency-free base windowing library. Allows 
drawing, input, and other basic functionality. Also allows OpenGL 
access.

sslsocket.d - Uses OpenSSL to inherit from std.socket.Socket and 
give client SSL support.

stb_truetype.d - port of C library for writing ttf fonts to 
images. Has some convenience functions (but they aren't great, 
works, but not great)

terminal.d - I/O support for the text console. Does real time 
input, cellular output, getting lines with user editing, 
coloring, mouse input, and more.

xwindows.d - functions for working with X, beyond what 
simpledisplay.d offers. Stuff like interacting with the window 
manager, getting window icons, etc. I wrote it to support my D 
xlib taskbar.

web.d - wraps a D class in an HTTP api, with automatic url 
routing, view generation, argument conversion, and much more. 
Also includes a HTML templating system among other stuff that 
brings a lot of these modules together.



There's a few other hidden gems in the files themselves, and so 
much more on my pipeline. Among the ones you might see added in 
the next month:

game.d - helper functions for writing games (bringing together 
the display, audio, and joystick stuff). I have OpenGL texture 
stuff written now, almost done with the high level input api, and 
some math stuff that will probably be in there.

model.d - loading and displaying a 3d model format with open gl.

midi.d, wav.d - loading, saving, and working with midi and wav 
files


(Yes, I'm writing a pair of D games again, finally! First time in 
a long time, but it is moving along well... and I don't need SDL 
this time!)
Jan 15 2015
next sibling parent "FrankLike" <1150015857 qq.com> writes:
On Thursday, 15 January 2015 at 15:38:05 UTC, Adam D. Ruppe wrote:


  mssql.d  - drivers for database.d (wrapping C libraries)



 minigui.d - small, dependency-free (except for simpledisplay.d 
 and color.d but doesn't even need Phobos) widget set, using 
 Win32 native widgets where possible, custom Xlib based ones 
 otherwise. Still work in progress but already works for some 
 basic forms.


Can you let the mssql.d work ok on your minigui.d with ANSI 
(wstring)?
Insert wstring? Get the SqlException?

Thank you.
Jan 15 2015
prev sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 15 January 2015 at 15:38:05 UTC, Adam D. Ruppe wrote:

 I could totally fill in the "project spotlight" with stuff from 
 that repo for at least a year, not even kidding. But I don't 
 want it to be all about me!


Right, and it is more fun if you get response on reddit etc, so 
something short and useful that the reader can expand for her/his 
own cute little gadget is probably a good choice?

I've noticed that some blogs have links back to reddit with the 
link "discuss this article on reddit" at the bottom.


 (and oauth.d isn't new, i wrote that like three years ago... it 
 had to be updated a while ago because twitter deprecated v1 of 
 their api, but other than that, it hasn't changed much)


Oauth2.0 is not so complicated, but it is annoying to wade 
through all the irrelvant stuff on the web... So I'd say that 
would be a nice topic. A cut'n'paste solution of how to connect 
to "famous" services.


 a year ago). Soon to be replaced by the dependency-free 
 simpledisplay.d, simpleaudio.d, joystick.d combo.


Sounds fun! Could break it up into 6 parts over 6 weeks:
- how to load images
- draw stuff on the screen
- control stuff on the screen
- simple physics simulation
- add sounds to collision events
- play lunar lander (or some other simple game)


 color.d - a color struct for RGBA, also does CSS color string 
 read/writing, HSL <-> RGB, some color manipulation, alpha 
 blending, and image base classes including palette to true 
 color and true color to palette (quantization).


The CSS stuff might be a useful startingpoint for Manu's 
std.colour library?


 csv.d - simple csv reader, predates std.csv (and is a bit 
 simpler)


All common data format conversions would be useful to have in 
cookbook format on the web. This is something I typically google 
for because I it is more like a "bump in the road" than a domain 
specific thing.


 database.d - base class for RDBMS access. Also includes basic 
 ORM and query builder in the form of DataObject and 
 SelectBuilder


Also a nice topic. Especially if you cover the configuration 
gotchas for common databases that is incredibly boring to get 
stuck on. A "problem solver" article, perhaps?


 dom.d - XML and HTML parsing and manipulation, including CSS 
 selectors and other tools that can help for implementing a 
 browser. API inspired by modern Javascript DOM, capable of 
 scraping tag soup web pages.


Spiders are a fun topic too. Like "how to extract links from 
reddit" or some simple NLP heuristics that looks for keywords 
"hot topics this week".


 joystick.d - code for accessing XBox 360 controllers (and 
 similar ones, like the PS1 controller via usb) on Windows and 
 Linux.


Stuff like this sounds like a hit. Fun to read about even if you 
don't need it. I think geeks like to learn about what is under 
the hood of things they use.


 jsvar.d - a var type similar to Javascript, usable in D. Can be 
 used to read and write JSON with a natural syntax and other 
 dynamic type tasks.


Nice topic. "How to create your own dynamic type in D."


 script.d - a script interpeter based on jsvar.d. The script 
 language is like a cross of D and Javascript. Made for API 
 convenience - very very easy to embed in an application.


I think these "continued next week" hooks where you get something 
complete to play with in each issue are nice.


 simpleaudio.d - access to WinMM on Windows and ALSA on Linux 
 for waveform sound I/O and MIDI I/O.


Yup, "under the hood" topic. I like to read those even if I don't 
need them.


 game.d - helper functions for writing games (bringing together 
 the display, audio, and joystick stuff). I have OpenGL texture 
 stuff written now, almost done with the high level input api, 
 and some math stuff that will probably be in there.

 model.d - loading and displaying a 3d model format with open gl.

 midi.d, wav.d - loading, saving, and working with midi and wav 
 files


Yep, all good stuff!

Nice concept you have going here.
Jan 15 2015
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
We're kinda going off topic here, but..

(BTW, I just hit escape AGAIN after typing that. my vim habits 
are going overgrown!)

On Thursday, 15 January 2015 at 16:31:56 UTC, Ola Fosheim Grøstad 
wrote:

 Right, and it is more fun if you get response on reddit etc, so 
 something short and useful that the reader can expand for 
 her/his own cute little gadget is probably a good choice?


yeah. I actually did the stack thing in the last issue because 
someone asked about it on reddit so I figured it is a kinda 
hotish topic.


 Oauth2.0 is not so complicated, but it is annoying to wade 
 through all the irrelvant stuff on the web...


My thing is mostly doing the 1.0 version, and the complication 
wasn't even so much the thing itself, but the varying 
interpretations of the "standard" that were around a few years 
ago. Like Twitter was case insensitive and LinkedIn wasn't and 
they expected different names and just silly little things like 
that. And, of course, when it fails, it just says "bad 
signature", you don't know why...

I think it is all working well now though, I've used that oauth.d 
with a bunch of services, at least last year, I didn't do so much 
D web stuff in 2014.


 Sounds fun! Could break it up into 6 parts over 6 weeks:


hmm, I could play with that. (also snipping a lot of other good 
ideas throughout btw)


 The CSS stuff might be a useful startingpoint for Manu's 
 std.colour library?


Maybe, though I just kinda hacked it together without knowing a 
great deal about the underlying theory, so Manu would probably do 
a better job than I did anyway.


 Stuff like this sounds like a hit. Fun to read about even if 
 you don't need it. I think geeks like to learn about what is 
 under the hood of things they use.


Ah, but it is easy! On Windows especially, they offer a new 
XInput dll that is made specifically for the xbox 360 controller 
and has super easy access to all its features. The hardest thing 
for me has been reconciling it with my old PS1 controller which I 
prefer the shape of...

I suppose I could talk about it anyway though, there's a few nice 
bits of implementation we could go over.


 Nice topic. "How to create your own dynamic type in D."


I'm thinking about doing this at dconf this year!
Jan 15 2015
next sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Jan 15, 2015 at 06:00:36PM +0000, Adam D. Ruppe via Digitalmars-d wrote:

 We're kinda going off topic here, but..
 
 (BTW, I just hit escape AGAIN after typing that. my vim habits are
 going overgrown!)


[...]

Only just??! For years now I've had this uncontrollable twitch in my
left hand, that every so often reaches in the direction of the ESC key
without my awareness. It's a sign of a true hardcore vi(m) user. :-P


T

-- 
Spaghetti code may be tangly, but lasagna code is just cheesy.
Jan 15 2015
prev sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 15 January 2015 at 18:00:38 UTC, Adam D. Ruppe wrote:

 We're kinda going off topic here, but..


Getting dependency free cook-book stuff on the web, that you just 
cut'n'paste into your editor could have a huge influence on D 
becoming more used.  Encouraging people to write small utilities 
that run faster than scripting languages allow with the same 
amount of typing.

There's something to the phrase: «Show, don't tell!»



 (BTW, I just hit escape AGAIN after typing that. my vim habits 
 are going overgrown!)


I get the same feeling when going from Emacs to Windows... Ctrl-X 
Ctrl-S. Very annoying to first delete a lot of stuff and then 
saving it... :-/



 I think it is all working well now though, I've used that 
 oauth.d with a bunch of services, at least last year, I didn't 
 do so much D web stuff in 2014.


All the google stuff is Oauth2, I think. But without a «show, 
don't tell» cut'n'paste solution I'm more like "sounds 
complicated and tedious, it can wait...".



 Ah, but it is easy! On Windows especially, they offer a new 
 XInput dll that is made specifically for the xbox 360 
 controller and has super easy access to all its features. The 
 hardest thing for me has been reconciling it with my old PS1 
 controller which I prefer the shape of...

 I suppose I could talk about it anyway though, there's a few 
 nice bits of implementation we could go over.


I think many have a 1-minute attention span when surfing the web, 
so I would worry more about not making it short enough than too 
short. You could probably structure such articles so that the fun 
part is on the top of the page and the "how to do it" on the 
lower part.

Besides it makes for a good reddit/hacker news title, so people 
might just comment on it to talk about their own stuff. Which is 
good. It still gets D exposure.



 Nice topic. "How to create your own dynamic type in D."


 I'm thinking about doing this at dconf this year!


Neat, Iooking forward to the slides!
Jan 15 2015
prev sibling parent reply "brian" <brian infinityplusb.com> writes:
On Wednesday, 14 January 2015 at 05:10:05 UTC, Joakim wrote:


 Take a look at the official package registry, called dub:


I love dub, who doesn't. It is evidence of a very active and 
large community.


 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?


 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?


 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.


 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.


 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?

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.
Jan 14 2015
next sibling parent "Joakim" <dlang joakim.fea.st> writes:
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.
Jan 14 2015
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/14/15 7:19 PM, brian wrote:

 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.


Yes, it would be great if we could crowdsource a cornucopia of "how to" 
topics in D. -- Andrei
Jan 14 2015
next sibling parent reply "Szymon Gatner" <noemail gmail.com> writes:
On Thursday, 15 January 2015 at 07:58:47 UTC, Andrei Alexandrescu 
wrote:

 On 1/14/15 7:19 PM, brian wrote:

 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.


 Yes, it would be great if we could crowdsource a cornucopia of 
 "how to" topics in D. -- Andrei



Adam's D Cookbook kindof does that
Jan 15 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/15/15 12:49 AM, Szymon Gatner wrote:

 On Thursday, 15 January 2015 at 07:58:47 UTC, Andrei Alexandrescu wrote:

 On 1/14/15 7:19 PM, brian wrote:

 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.


 Yes, it would be great if we could crowdsource a cornucopia of "how
 to" topics in D. -- Andrei



 Adam's D Cookbook kindof does that


Yah, we need stuff online and nice and with that upbeat ukulele music. 
-- Andrei
Jan 15 2015
prev sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
On Thursday, 15 January 2015 at 07:58:47 UTC, Andrei Alexandrescu 
wrote:

 On 1/14/15 7:19 PM, brian wrote:

 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.


 Yes, it would be great if we could crowdsource a cornucopia of 
 "how to" topics in D. -- Andrei


D is the 8th most popular language on Rosetta Code(I think most 
of the entries are from a single person - Bearophile), it's 
within ~25 entries of C, Ruby, etc.

There's also the cookbook on the wiki that's unfinished.
http://wiki.dlang.org/Cookbook
and the tutorial page
http://wiki.dlang.org/Tutorials
Jan 15 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/15/15 1:42 AM, weaselcat wrote:

 On Thursday, 15 January 2015 at 07:58:47 UTC, Andrei Alexandrescu wrote:

 On 1/14/15 7:19 PM, brian wrote:

 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.


 Yes, it would be great if we could crowdsource a cornucopia of "how
 to" topics in D. -- Andrei


 D is the 8th most popular language on Rosetta Code(I think most of the
 entries are from a single person - Bearophile), it's within ~25 entries
 of C, Ruby, etc.


Way to go bearophile! Could somebody please insert a reference to 
Rosetta Code on dlang.org?


 There's also the cookbook on the wiki that's unfinished.
 http://wiki.dlang.org/Cookbook
 and the tutorial page
 http://wiki.dlang.org/Tutorials


Well those need to be finished before we advertise them.


Andrei
Jan 15 2015
next sibling parent reply "CraigDillabaugh" <craig.dillabaugh gmail.com> writes:
On Thursday, 15 January 2015 at 16:53:14 UTC, Andrei Alexandrescu 
wrote:

 On 1/15/15 1:42 AM, weaselcat wrote:

 On Thursday, 15 January 2015 at 07:58:47 UTC, Andrei 
 Alexandrescu wrote:

 On 1/14/15 7:19 PM, brian wrote:

 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.


 Yes, it would be great if we could crowdsource a cornucopia 
 of "how
 to" topics in D. -- Andrei


 D is the 8th most popular language on Rosetta Code(I think 
 most of the
 entries are from a single person - Bearophile), it's within 
 ~25 entries
 of C, Ruby, etc.


 Way to go bearophile! Could somebody please insert a reference 
 to Rosetta Code on dlang.org?


 There's also the cookbook on the wiki that's unfinished.
 http://wiki.dlang.org/Cookbook
 and the tutorial page
 http://wiki.dlang.org/Tutorials


 Well those need to be finished before we advertise them.


 Andrei


I suppose such things will never be really 'finished', but indeed 
they are of uneven quality, and sort of scattered.  Seems like a 
rather random collection of stuff, which is a testament to the 
project's open source nature.

Finally, one issue with using a Wiki in general is that it would 
be nice if any code snippets in D howto's, FAQs, tutorials, etc 
could be run through the latest DMD release so that it doesn't 
get 'out of step' with the current language. I suppose if most of 
the Howto's/Tutorials were written in DDOC the Howto/Tutorials 
could be run through the auto-tester ... but I am not sure 
exactly how this would be done/how difficult it would be.
Jan 15 2015
parent "CraigDillabaugh" <craig.dillabaugh gmail.com> writes:
On Thursday, 15 January 2015 at 17:32:11 UTC, CraigDillabaugh 
wrote:

 On Thursday, 15 January 2015 at 16:53:14 UTC, Andrei 
 Alexandrescu wrote:

 On 1/15/15 1:42 AM, weaselcat wrote:

 On Thursday, 15 January 2015 at 07:58:47 UTC, Andrei 
 Alexandrescu wrote:

 On 1/14/15 7:19 PM, brian wrote:

 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.


 Yes, it would be great if we could crowdsource a cornucopia 
 of "how
 to" topics in D. -- Andrei


 D is the 8th most popular language on Rosetta Code(I think 
 most of the
 entries are from a single person - Bearophile), it's within 
 ~25 entries
 of C, Ruby, etc.


 Way to go bearophile! Could somebody please insert a reference 
 to Rosetta Code on dlang.org?


 There's also the cookbook on the wiki that's unfinished.
 http://wiki.dlang.org/Cookbook
 and the tutorial page
 http://wiki.dlang.org/Tutorials


 Well those need to be finished before we advertise them.


 Andrei


 I suppose such things will never be really 'finished', but 
 indeed they are of uneven quality, and sort of scattered.  
 Seems like a rather random collection of stuff, which is a 
 testament to the project's open source nature.

 Finally, one issue with using a Wiki in general is that it 
 would be nice if any code snippets in D howto's, FAQs, 
 tutorials, etc could be run through the latest DMD release so 
 that it doesn't get 'out of step' with the current language. I 
 suppose if most of the Howto's/Tutorials were written in DDOC 
 the Howto/Tutorials could be run through the auto-tester ... 
 but I am not sure exactly how this would be done/how difficult 
 it would be.


I think I should clarify my last point a bit.  What I had in 
mind, it that for tutorials/faqs/howtos, etc. It would be nice if 
each tutorial/howto were coded as a single D file, with the 
actual content in DDOC format, and any D code as compilable code 
within the file.  Then at each new release the tutorials could be 
compiled to make sure they stay in sync.

When I said I was unsure how difficult this would be I meant that 
this may present challenges for tutorial writers.  Also, in this 
case you would want your code (or a subset thereof) to show up in 
the output. Not sure if DDOC could handle that.
Jan 15 2015
prev sibling parent reply "Mengu" <mengukagan gmail.com> writes:
On Thursday, 15 January 2015 at 16:53:14 UTC, Andrei Alexandrescu 
wrote:

 On 1/15/15 1:42 AM, weaselcat wrote:

 On Thursday, 15 January 2015 at 07:58:47 UTC, Andrei 
 Alexandrescu wrote:

 On 1/14/15 7:19 PM, brian wrote:

 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.


 Yes, it would be great if we could crowdsource a cornucopia 
 of "how
 to" topics in D. -- Andrei


 D is the 8th most popular language on Rosetta Code(I think 
 most of the
 entries are from a single person - Bearophile), it's within 
 ~25 entries
 of C, Ruby, etc.


 Way to go bearophile! Could somebody please insert a reference 
 to Rosetta Code on dlang.org?


 There's also the cookbook on the wiki that's unfinished.
 http://wiki.dlang.org/Cookbook
 and the tutorial page
 http://wiki.dlang.org/Tutorials


 Well those need to be finished before we advertise them.


 Andrei


bearophile did an awesome job. hats off.

i've noticed there are some code that are not working such as the 
anonymous recursion example. [0] the first example there doesn't 
work but the second one works with DMD64 D Compiler v2.066.

let's get together and find out which examples are working well 
and which are not.

[0] http://rosettacode.org/wiki/Anonymous_recursion#D
Jan 15 2015
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Mengu:


 i've noticed there are some code that are not working such as 
 the anonymous recursion example. [0] the first example there 
 doesn't work but the second one works with DMD64 D Compiler 
 v2.066.


The code used to work... I fix all the time the code that used to 
work...



 let's get together and find out which examples are working well 
 and which are not.


Better to introduce a bit of coordination first! Perhaps in the 
D.learn newsgroup...

Bye,
bearophile
Jan 15 2015
parent reply "weaselcat" <weaselcat gmail.com> writes:
On Thursday, 15 January 2015 at 20:54:05 UTC, bearophile wrote:

 Mengu:


 i've noticed there are some code that are not working such as 
 the anonymous recursion example. [0] the first example there 
 doesn't work but the second one works with DMD64 D Compiler 
 v2.066.


 The code used to work... I fix all the time the code that used 
 to work...



 let's get together and find out which examples are working 
 well and which are not.


 Better to introduce a bit of coordination first! Perhaps in the 
 D.learn newsgroup...

 Bye,
 bearophile


Seems like it would be easier to keep the code in a git repo and
run regression tests on it.
Jan 15 2015
parent "Vlad Levenfeld" <vlevenfeld gmail.com> writes:
On Friday, 16 January 2015 at 01:16:26 UTC, weaselcat wrote:

 On Thursday, 15 January 2015 at 20:54:05 UTC, bearophile wrote:

 Mengu:


 i've noticed there are some code that are not working such as 
 the anonymous recursion example. [0] the first example there 
 doesn't work but the second one works with DMD64 D Compiler 
 v2.066.


 The code used to work... I fix all the time the code that used 
 to work...



 let's get together and find out which examples are working 
 well and which are not.


 Better to introduce a bit of coordination first! Perhaps in 
 the D.learn newsgroup...

 Bye,
 bearophile


 Seems like it would be easier to keep the code in a git repo and
 run regression tests on it.


Pull the D samples down with curl and run them periodically?
Jan 15 2015
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/15/15 12:41 PM, Mengu wrote:


 bearophile did an awesome job. hats off.


Yes, fantastic.


 i've noticed there are some code that are not working such as the
 anonymous recursion example. [0] the first example there doesn't work
 but the second one works with DMD64 D Compiler v2.066.

 let's get together and find out which examples are working well and
 which are not.

 [0] http://rosettacode.org/wiki/Anonymous_recursion#D


I wonder how to feature Rosetta Code more prominently on dlang.org.


Andrei



 Jan 15 2015



  parent reply "bearophile" <bearophileHUGS lycos.com>  writes:


Andrei Alexandrescu:


 I wonder how to feature Rosetta Code more prominently on 
 dlang.org.


I don't know. One option is to create a kind of "FAQ" page in the 
D wiki, that associates problems and questions with links to 
specific entries in the Rosettacode site.

Bye,
bearophile



 Jan 15 2015



  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 1/15/15 4:26 PM, bearophile wrote:

 Andrei Alexandrescu:


 I wonder how to feature Rosetta Code more prominently on dlang.org.


 I don't know. One option is to create a kind of "FAQ" page in the D
 wiki, that associates problems and questions with links to specific
 entries in the Rosettacode site.


We need to provide a clear path for people that starts at dlang.org and 
goes to rosetta. -- Andrei



 Jan 15 2015



prev sibling  parent  "bearophile" <bearophileHUGS lycos.com>  writes:


Mengu:


 i've noticed there are some code that are not working such as 
 the anonymous recursion example. [0] the first example there 
 doesn't work


I have fixed the bug. If you find other problems please list them 
in a single thread in D.learn (but keep in mind that Rosettacode 
D code is meant to be compiled with the latest unreleased 
compiler, usually dmd unless differently specified).

Bye,
bearophile



 Jan 15 2015



prev sibling  parent reply "ponce" <contact gam3sfrommars.fr>  writes:


On Thursday, 15 January 2015 at 03:19:10 UTC, brian wrote:

 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.


Does this help? http://p0nce.github.io/d-idioms/

In my eyes, it is a responsibility of the twitter library to 
provide an example.

The best we have for busy programmers is Adam Ruppe's book.



 Jan 15 2015



  parent reply "Joakim" <dlang joakim.fea.st>  writes:


On Thursday, 15 January 2015 at 08:54:34 UTC, ponce wrote:

 On Thursday, 15 January 2015 at 03:19:10 UTC, brian wrote:

 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.


 Does this help? http://p0nce.github.io/d-idioms/


Just went through your list of idioms, noticed one mistake, 
anonymous _nested_ structs/unions are in D:

"anonymous structs/unions are allowed as members of other 
structs/unions"
http://dlang.org/struct.html



 Jan 15 2015



 next sibling parent  "ponce" <contact gam3sfrommars.fr>  writes:


On Thursday, 15 January 2015 at 10:19:36 UTC, Joakim wrote:

 On Thursday, 15 January 2015 at 08:54:34 UTC, ponce wrote:

 On Thursday, 15 January 2015 at 03:19:10 UTC, brian wrote:

 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.


 Does this help? http://p0nce.github.io/d-idioms/


 Just went through your list of idioms, noticed one mistake, 
 anonymous _nested_ structs/unions are in D:

 "anonymous structs/unions are allowed as members of other 
 structs/unions"
 http://dlang.org/struct.html



Thanks! We were 2 to have missed that.



 Jan 15 2015



prev sibling  parent  "ponce" <contact gam3sfrommars.fr>  writes:


On Thursday, 15 January 2015 at 10:19:36 UTC, Joakim wrote:

 On Thursday, 15 January 2015 at 08:54:34 UTC, ponce wrote:

 On Thursday, 15 January 2015 at 03:19:10 UTC, brian wrote:

 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.


 Does this help? http://p0nce.github.io/d-idioms/


 Just went through your list of idioms, noticed one mistake, 
 anonymous _nested_ structs/unions are in D:

 "anonymous structs/unions are allowed as members of other 
 structs/unions"
 http://dlang.org/struct.html


Actually it's more complicated than that, _some_ anonymous nested 
struct are in D, but not the ones you need to translate C.
https://github.com/p0nce/d-idioms/issues/10#issuecomment-70154005



 Jan 15 2015



prev sibling  parent  "weaselcat" <weaselcat gmail.com>  writes:


On Tuesday, 13 January 2015 at 23:34:40 UTC, brian wrote:

 A question first: ... what do people actually have working in D?
 I find very few "working examples" of things I want to do. Or 
 things in general. That I can read and say "oooh that's close 
 to what I want, I can tweak it a little here and there".

 Eg.
 I want a program to write tweets.
 I can't just google "twitter example d" and find a nice starter 
 program to connect a write a tweet.


if you google "dlang" "twitter api"
http://code.dlang.org/packages/twitter4d is the second result.



 Jan 15 2015



prev sibling  parent  "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


On Tuesday, 23 December 2014 at 23:12:46 UTC, Adam D. Ruppe wrote:

 On Tuesday, 23 December 2014 at 19:54:20 UTC, Ola Fosheim 
 Grøstad wrote:

 5 stars for arsd


 I'm almost famous!

 I actually seriously wonder how many users my random stuff has. 
 Maybe I should set up an email list - when I make a breaking 
 change, I often wonder how many people I'm inconveniencing... 
 (I don't often make breaking changes, but I sometimes do.)


I think people often look for narrow solutions to the concrete 
problems they have. Big frameworks tend to generate more buzz and 
get more visible in search engines and the like, but narrow 
solutions might be just as attractive if not more. The problem is 
finding them...



 Dec 23 2014



prev sibling  parent reply Rikki Cattermole <alphaglosined gmail.com>  writes:


On 24/12/2014 8:54 a.m., "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 On Tuesday, 23 December 2014 at 19:14:02 UTC, ketmar via Digitalmars-d
 wrote:

 and so D. and i still has to learn libraries for all that. yet people
 talking Go being magic bullet: just use concurency and that's all!

 nope. that's not all. that's not even the biggest part.


 Library support is really important when doing web servers and
 integration with existing systems and workflows. This is not an area
 where D will be able to compete anytime soon, it is a crowded space:
 Java, Python, Ruby, Php, node.js and eventually Go. I have to connect to
 Google infrastructure, to legacy databases like Pervasive, parse Excel
 files, add encryption cross platform etc... Every other project might
 need a new library if you are to integrate with existing solutions, so
 there is really no end to what you need to support...


 Reality check on stuff that could be relevant for a server:

 https://github.com/trending?l=go&since=monthly

 4943 stars for Go
 2947 stars for Rocket
 1029 stars for Docker
 747 stars for  ssh-chat
 622 stars for Kubernetes
 672 stars for Jason
 672 stars for aws-go
 594 stars for bone
 405 stars for influxdb
 364 stars for etcd
 356 stars for surgemq
 246 stars for kite

 https://github.com/trending?l=d&since=monthly

 28 stars for vibe.d
 10 stars for phobos
 6 stars for druntime
 6 stars for libasync
 5 stars for arsd

 That's a wipe out...


 1. take gw-basic.
 2. take Google.
 3. let Google to throw money into gw-basic hype.
 4. people start writing alot of software in gw-basic.

 there is no direct corellation between "being good in technical sense"
 and "being successfull". but there is such corellation between
 "advertising by Big Player" and "being successfull".


 There is a strong correlation between not having a stable release and
 getting less attention from people who write libraries and frameworks
 for commercial use.

 Besides, Basic got traction at a time where people charged for good
 languages, it was available for free and was not too demanding on
 resources so it was built into the ROM on basically all home computers
 in the 80s. That's how Basic got big.


Lets not forget things like barcode generators, qrcode and pdf editor.
People have a tendency to like having those things for web services...
Unfortunately they have a tendency to have a requirement to have things 
such as a image library already. Which we also have a bad tendency to 
not standardized in one library.



 Dec 23 2014



 next sibling parent  "Adam D. Ruppe" <destructionator gmail.com>  writes:


On Wednesday, 24 December 2014 at 01:20:13 UTC, Rikki Cattermole 
wrote:

 Lets not forget things like barcode generators, qrcode and pdf 
 editor.


One of my larger D web projects included QR code generation - it 
was a printable coupon site.

I did it by just calling system("qrencode")... or whatever the 
program was called, instead of bothering with a library, then did 
the rest with plain image management (which I do have in D).

I'm sure I could have called a C lib or something too, but the 
command line interface was easy and quick to slap together.

It was easy and worked pretty well. Over years of using D in 
production for a few different startups, I never hit a problem I 
couldn't quickly solve.



 Dec 23 2014



prev sibling  parent  "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


On Wednesday, 24 December 2014 at 01:20:13 UTC, Rikki Cattermole 
wrote:

 Lets not forget things like barcode generators, qrcode and pdf 
 editor.


On-the-fly PDF generation is very useful for creating product 
sheets or printable versions of articles etc. There are few good 
solutions for that.



 Dec 23 2014



prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 12/18/14 4:38 AM, bioinfornatics wrote:

 - range even the basic io as ByLine which implement range can't work
 with std.range.takeOne as is not an Input Range. While a basic function
 such as takeOne do not really need to use save method to work a forward
 range is enough.


Could you please give an example of this? Thanks. -- Andrei



 Dec 23 2014



  parent  "Vladimir Panteleev" <vladimir thecybershadow.net>  writes:


On Tuesday, 23 December 2014 at 17:00:55 UTC, Andrei Alexandrescu 
wrote:

 On 12/18/14 4:38 AM, bioinfornatics wrote:

 - range even the basic io as ByLine which implement range 
 can't work
 with std.range.takeOne as is not an Input Range. While a basic 
 function
 such as takeOne do not really need to use save method to work 
 a forward
 range is enough.


 Could you please give an example of this? Thanks. -- Andrei


Unless I'm misunderstanding, it's really as simple as:

auto s = stdin.byLine.takeOne;

C:\...\std\range\package.d(1939): Error: template 
std.range.primitives.save cannot deduce function from argument 
types !()(ByLine!(char, char)), candidates are:
C:\...\std\range\primitives.d(1944):        
std.range.primitives.save(T)(T[] a)
test.d(5): Error: template instance 
std.range.takeOne!(ByLine!(char, char)) error instantiating



 Dec 23 2014



prev sibling  parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


Look at the curves for referring domains:

https://ahrefs.com/site-explorer/overview/subdomains/?target=www.dlang.org

https://ahrefs.com/site-explorer/overview/subdomains/?target=www.golang.org

https://ahrefs.com/site-explorer/overview/subdomains/?target=www.rust-lang.org

Rust has an impressive marketing trajectory there. But D is 
growing too.

(The backlinks graphs are misleading due to documentation pages 
etc.)



 Jan 15 2015



  parent  "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


On Thursday, 15 January 2015 at 10:05:23 UTC, Ola Fosheim Grøstad 
wrote:

 Look at the curves for referring domains:

 https://ahrefs.com/site-explorer/overview/subdomains/?target=www.dlang.org


Actually, that was wrong since dlang does not use the "www" 
standard, that is much better:

https://ahrefs.com/site-explorer/overview/exact/?target=dlang.org



 Jan 15 2015