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 Java/C/C++/C#/whatever, because the threading model is 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