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.

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.

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.

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

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.

"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. 

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

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.

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.

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.