www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - 2015 H1 Vision

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Hello,


Walter and I have been mulling for a while on a vision for the first six 
months of 2015.

http://wiki.dlang.org/Vision/2015H1

This is stuff we consider important for D going forward and plan to work 
actively on. We encourage the D community to focus contributions along 
the same lines.

We intentionally kept the document short and high-level as opposed to 
discussing tactical details. Such discussions are encouraged in the 
appropriate forums.


Thanks,

Walter and Andrei
Jan 31 2015
next sibling parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 1/02/2015 2:17 p.m., Andrei Alexandrescu wrote:

 Hello,


 Walter and I have been mulling for a while on a vision for the first six
 months of 2015.

 http://wiki.dlang.org/Vision/2015H1

 This is stuff we consider important for D going forward and plan to work
 actively on. We encourage the D community to focus contributions along
 the same lines.

 We intentionally kept the document short and high-level as opposed to
 discussing tactical details. Such discussions are encouraged in the
 appropriate forums.


 Thanks,

 Walter and Andrei


I'm personally slightly concerned about libraries into phobos. Not so 
much libraries in general. But frameworks.
This is how we do x, kind.

Can we please keep opinionated "libraries" of how to do things away from 
phobos?
An ORM is a great example of this. But a client library to e.g. Mysql is 
fine.

Anyway enough about that, the plan is definitely looking good!
Jan 31 2015
prev sibling next sibling parent reply "data man" <datamanrb gmail.com> writes:
Vision/2015H1 wrote:

 We believe safety is an important aspect of language design, 
 and we plan to continue building on the  safe/ trusted/ system 
 troika.


I like the "troika" :-)
Jan 31 2015
parent "Tofu Ninja" <emmons0 purdue.edu> writes:
On Sunday, 1 February 2015 at 03:46:25 UTC, data man wrote:

 Vision/2015H1 wrote:

 We believe safety is an important aspect of language design, 
 and we plan to continue building on the  safe/ trusted/ system 
 troika.


 I like the "troika" :-)


I had to look up what it means :/
Jan 31 2015
prev sibling next sibling parent reply "Joakim" <dlang joakim.fea.st> writes:
On Sunday, 1 February 2015 at 01:17:41 UTC, Andrei Alexandrescu 
wrote:

 Hello,


 Walter and I have been mulling for a while on a vision for the 
 first six months of 2015.

 http://wiki.dlang.org/Vision/2015H1

 This is stuff we consider important for D going forward and 
 plan to work actively on. We encourage the D community to focus 
 contributions along the same lines.

 We intentionally kept the document short and high-level as 
 opposed to discussing tactical details. Such discussions are 
 encouraged in the appropriate forums.


Nice work, D needed some direction like this.  I thought one 
oversight was no mention of ddmd, which seems to have gone into 
limbo over the last year.  According to Daniel, it's pretty much 
done but is just waiting on Brad to add some support in the 
auto-tester, for 9 months now:

http://forum.dlang.org/post/m8bt6s$1s86$1 digitalmars.com

Moving the dmd frontend to D would help encourage contribution, 
one of the explicit goals in the vision statement, and would help 
keep the C++ support up to date, as the backends will stay C++.

I wish there had been some mention of mobile.  Recent news was 
that 1 billion Android smartphones were sold last year: that 
dwarfs the 316 million PCs sold, a number that keeps declining.  
That doesn't even include the two hundred million tablets sold 
last year.  Right now, there's two people working on Android 
support and one person on iOS support.

Even Android has moved to Ahead-Of-Time compilation with 
Lollipop.  Mobile is a giant opportunity for native languages, 
one D cannot afford to miss.
Jan 31 2015
next sibling parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Joakim"  wrote in message news:nphrawlkmiwksghfybxr forum.dlang.org...


 Nice work, D needed some direction like this.  I thought one oversight was 
 no mention of ddmd, which seems to have gone into limbo over the last 
 year.  According to Daniel, it's pretty much done but is just waiting on 
 Brad to add some support in the auto-tester, for 9 months now:


Brad has put the host compiler in place on windows now, so the only issue 
with that is the invalid config file sitting in the dmd dir, which will 
probably be fixed by updating the dmd install to master so I can use the new 
'-conf' switch.

There is also a crash related to D's va_copy not working, which I've nearly 
solved.
Jan 31 2015
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2015-02-01 08:12, Joakim wrote:


 I wish there had been some mention of mobile.  Recent news was that 1
 billion Android smartphones were sold last year: that dwarfs the 316
 million PCs sold, a number that keeps declining. That doesn't even
 include the two hundred million tablets sold last year.  Right now,
 there's two people working on Android support and one person on iOS
 support.


I agree.

-- 
/Jacob Carlborg
Feb 01 2015
prev sibling next sibling parent "John" <john.joyus gmail.com> writes:
On Sunday, 1 February 2015 at 01:17:41 UTC, Andrei Alexandrescu 
wrote:

 Hello,


 Walter and I have been mulling for a while on a vision for the 
 first six months of 2015.

 http://wiki.dlang.org/Vision/2015H1

 This is stuff we consider important for D going forward and 
 plan to work actively on. We encourage the D community to focus 
 contributions along the same lines.



This is great, thanks!
Btw, people usually search for Dlang roadmap. Please use the word 
"roadmap" somewhere to make it searchable. Also, a generic link 
would be nice, without that 2015H1 in the url.
Feb 01 2015
prev sibling next sibling parent reply "Dicebot" <public dicebot.lv> writes:
I'd really like "Emphasize vibe.d" to be replaced with "Emphasize 
dub". Get the latter and you get the former essentially for free 
(and it is WIP already).

Other than that - list makes perfect sense.
Feb 01 2015
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Sunday, 1 February 2015 at 10:20:47 UTC, Dicebot wrote:

 I'd really like "Emphasize vibe.d" to be replaced with 
 "Emphasize dub". Get the latter and you get the former 
 essentially for free (and it is WIP already).


I wish inclusions like this would go through a code review, the 
sort we put new Phobos modules through. I don't use Dub but in #d 
you can regularly hear complaints about it crashing or inversely, 
silently catching all exceptions in some places.

Of course, this is wishful thinking - we have no resources to 
spare for such reviews, no resources to follow up on such 
reviews, and no resources to come up with alternatives that would 
pass these hypothetical reviews.

Still, who is going to take care of all these issues?

https://github.com/D-Programming-Language/dub/issues
Feb 01 2015
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Vladimir Panteleev"  wrote in message 
news:viqwfixznbdbdwvhavuk forum.dlang.org...


 I don't use Dub


You really should!  I put it off for months and months but I'm quite happy 
with it now.
Feb 01 2015
next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Mon, 02 Feb 2015 16:24:00 +1100, Daniel Murphy wrote:


 "Vladimir Panteleev"  wrote in message
 news:viqwfixznbdbdwvhavuk forum.dlang.org...
=20

 I don't use Dub


=20
 You really should!  I put it off for months and months but I'm quite
 happy with it now.


dub is very limited tool. first: it can't do separate compilation. some=20
of my modules, for example, do alot of CTFE things (including parsing=20
disk files) and eating memory like crazy. there is simply no way to to=20
batch compiles for me. besides, batch compile means that if i'll change=20
one line in one module, dub will recompile them all, so i forced to group=20
modules to libraries by size, not by intent.

second: dub can't compile code in other languages. some of my projects=20
includes several C modules, for example, and my build tool has no=20
problems building that and automatically tracking dependencies.

third (it's an extension of second, actually): track arbitrary=20
dependencies and exec arbitrary tools to generate some files based on=20
that dependencies.

dub is good, but only in limited use cases. so it's almost no sense in=20
using dub if some use cases are not suitable for it: it's way better to=20
adapt build tool that one already using (or write his own) instead of use=20
TWO build tools for different projects.=
Feb 01 2015
next sibling parent "Mathias LANG" <geod24 gmail.com> writes:
On Monday, 2 February 2015 at 05:57:27 UTC, ketmar wrote:

 On Mon, 02 Feb 2015 16:24:00 +1100, Daniel Murphy wrote:


 "Vladimir Panteleev"  wrote in message
 news:viqwfixznbdbdwvhavuk forum.dlang.org...
 

 I don't use Dub


 
 You really should!  I put it off for months and months but I'm 
 quite
 happy with it now.


 dub is very limited tool. first: it can't do separate 
 compilation. some
 of my modules, for example, do alot of CTFE things (including 
 parsing
 disk files) and eating memory like crazy. there is simply no 
 way to to
 batch compiles for me. besides, batch compile means that if 
 i'll change
 one line in one module, dub will recompile them all, so i 
 forced to group
 modules to libraries by size, not by intent.

 second: dub can't compile code in other languages. some of my 
 projects
 includes several C modules, for example, and my build tool has 
 no
 problems building that and automatically tracking dependencies.

 third (it's an extension of second, actually): track arbitrary
 dependencies and exec arbitrary tools to generate some files 
 based on
 that dependencies.

 dub is good, but only in limited use cases. so it's almost no 
 sense in
 using dub if some use cases are not suitable for it: it's way 
 better to
 adapt build tool that one already using (or write his own) 
 instead of use
 TWO build tools for different projects.


You can do separate compilation (--build-mode=singleFile).
It was implemented, quick and dirty (my bad), for one purpose: 
compile Vibe.d on a very limited machine (512 Mbs of RAM).
It has, however, no tracking of module dependency ATM, so it'll 
recompile everything, everytime. This is a known issue which, 
either no one is interested in, or no one has the time to. I also 
remember facing DMD bugs when I gave it a shot, but they may be 
fixed by now (one of them is for sure), so maybe this feature 
needs a second chance.

I will not disagree on the other points (support for other 
languages is what I'm missing most ATM).

If you wish to contribute patches, contact me, and I'll be the 
strawman (geod24/gmail).
Feb 01 2015
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-02-02 06:57, ketmar wrote:


 dub is good, but only in limited use cases. so it's almost no sense in
 using dub if some use cases are not suitable for it: it's way better to
 adapt build tool that one already using (or write his own) instead of use
 TWO build tools for different projects.


Dub should have been two tools, one for package management and one for 
building.

-- 
/Jacob Carlborg
Feb 01 2015
next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Mon, 02 Feb 2015 08:35:07 +0100, Jacob Carlborg wrote:


 On 2015-02-02 06:57, ketmar wrote:
=20

 dub is good, but only in limited use cases. so it's almost no sense in
 using dub if some use cases are not suitable for it: it's way better to
 adapt build tool that one already using (or write his own) instead of
 use TWO build tools for different projects.


=20
 Dub should have been two tools, one for package management and one for
 building.


i agree with you. the best thing of dub -- package management and=20
dependency management -- should be easily accessible. something like "pkg-
config", but with ability to download/install/uninstall/upgrade packages.=20
i.e. pkg manager like "apt" ;-), plus "pkg-config" functionality to allow=20
using in various build tools.

but i think that it's too late now to separate this dub parts. :-(=
Feb 01 2015
parent Russel Winder via Digitalmars-d-announce writes:
On Mon, 2015-02-02 at 07:59 +0000, ketmar via Digitalmars-d-announce wrote:

 […]
 
 but i think that it's too late now to separate this dub parts. :-(


Far from it. Now is the time to do it. There has been enough use of it 
that there is genuine practical experience of the workflows and the 
ups and downs. Now is the time to harness that experience and create 
the right system. Assuming it cannot change now would be a disservice.

All the new languages are doing package management effectively the 
same way, D, Rust, Ceylon. The Python egg → wheel shows it is possible 
to change.

-- 
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
Feb 02 2015
prev sibling parent reply "Atila Neves" <atila.neves gmail.com> writes:
On Monday, 2 February 2015 at 07:35:07 UTC, Jacob Carlborg wrote:

 On 2015-02-02 06:57, ketmar wrote:


 dub is good, but only in limited use cases. so it's almost no 
 sense in
 using dub if some use cases are not suitable for it: it's way 
 better to
 adapt build tool that one already using (or write his own) 
 instead of use
 TWO build tools for different projects.


 Dub should have been two tools, one for package management and 
 one for building.


Indeed. Most of the issues I hear about stem from it trying to do 
both at the same time. It's a good package manager but 
unfortunately a not so good build system. This makes me think, 
once more, of writing a D build system that uses dub only for 
package dependencies.

Atila
Feb 02 2015
next sibling parent Russel Winder via Digitalmars-d-announce writes:
On Mon, 2015-02-02 at 12:36 +0000, Atila Neves via Digitalmars-d-announce wrote:

 


[…]

 Indeed. Most of the issues I hear about stem from it trying to do 
 both at the same time. It's a good package manager but
 unfortunately a not so good build system. This makes me think, once 
 more, of writing a D build system that uses dub only for package 
 dependencies.
 


Given Gradle is both a dependency and build manager, and is the 
standard platform for Android builds, and has C++ as well as JVM 
languages support, I would suggest it would be a great base.
-- 
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
Feb 02 2015
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Monday, 2 February 2015 at 12:36:14 UTC, Atila Neves wrote:

 On Monday, 2 February 2015 at 07:35:07 UTC, Jacob Carlborg 
 wrote:

 On 2015-02-02 06:57, ketmar wrote:


 dub is good, but only in limited use cases. so it's almost no 
 sense in
 using dub if some use cases are not suitable for it: it's way 
 better to
 adapt build tool that one already using (or write his own) 
 instead of use
 TWO build tools for different projects.


 Dub should have been two tools, one for package management and 
 one for building.


 Indeed. Most of the issues I hear about stem from it trying to 
 do both at the same time. It's a good package manager but 
 unfortunately a not so good build system. This makes me think, 
 once more, of writing a D build system that uses dub only for 
 package dependencies.

 Atila


I agree that this is desired course of actions (I actually 
sometimes use it this way, wrapping dub into makefiles :P) but 
that can be a bit tricky when you think about different package 
types - binaries, source libraries, shared libraries. The fact 
that dub does both fetching and building ensures that all 
dependencies are compiled in uniform compatible matter - any 
decoupling proposal would need to ensure this stays.
Feb 02 2015
prev sibling parent Ben Boeckel via Digitalmars-d-announce writes:
On Mon, Feb 02, 2015 at 12:50:54 +0000, Russel Winder via
Digitalmars-d-announce wrote:

 Given Gradle is both a dependency and build manager, and is the 
 standard platform for Android builds, and has C++ as well as JVM 
 languages support, I would suggest it would be a great base.


I've been using CMake (with patches[1]) just fine[2].

--Ben

[1]https://github.com/trentforkert/cmake
[2]https://github.com/mathstuf/abagames-gunroar
Feb 02 2015
prev sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Monday, 2 February 2015 at 05:23:52 UTC, Daniel Murphy wrote:

 "Vladimir Panteleev"  wrote in message 
 news:viqwfixznbdbdwvhavuk forum.dlang.org...


 I don't use Dub


 You really should!  I put it off for months and months but I'm 
 quite happy with it now.


Replied in a new thread here:

http://forum.dlang.org/post/ysnfzpvrcvmjdekulfnq forum.dlang.org
Feb 02 2015
prev sibling next sibling parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
I think I can mostly agree with the plan, but:


 Improve language stability
 Define appropriately fuzzily-defined areas of the language 
 (e.g. shared semantics,  property).


This is either a contradiction in itself, or "stability" actually 
means "change".


 Foster library additions over language changes, and raise the 
 bar on language changes.


This needs to be handled on a case-by-case basis. The bare fact 
that something can be implemented in Phobos or user code doesn't 
mean it's a good idea. Both user experience and 
correctness/safety need to play a higher role in the decision 
than whether it requires language changes.

In particular, the stability argument must not be used as an 
excuse to keep bad design decisions around for the indefinite 
future.
Feb 01 2015
parent "Zach the Mystic" <reachzach gggmail.com> writes:
On Sunday, 1 February 2015 at 14:00:37 UTC, Marc Schütz wrote:

 I think I can mostly agree with the plan, but:


 Improve language stability
 Define appropriately fuzzily-defined areas of the language 
 (e.g. shared semantics,  property).


 This is either a contradiction in itself, or "stability" 
 actually means "change".


I agree. If you substitute "feature completion" for "stability" 
the vision statement makes more sense.
Feb 01 2015
prev sibling next sibling parent "Zach the Mystic" <reachzach gggmail.com> writes:
On Sunday, 1 February 2015 at 01:17:41 UTC, Andrei Alexandrescu 
wrote:

 Hello,


 Walter and I have been mulling for a while on a vision for the 
 first six months of 2015.

 http://wiki.dlang.org/Vision/2015H1

 This is stuff we consider important for D going forward and 
 plan to work actively on. We encourage the D community to focus 
 contributions along the same lines.

 We intentionally kept the document short and high-level as 
 opposed to discussing tactical details. Such discussions are 
 encouraged in the appropriate forums.


 Thanks,

 Walter and Andrei


Some of these vision statements are easier said than done. I'm 
reminded of the Serenity Prayer:

http://en.wikipedia.org/wiki/Serenity_Prayer

Question: When you say, "a focus on quality", what is that 
contrasted with? In the general sense, it's redundant to desire 
quality.
Feb 01 2015
prev sibling next sibling parent reply "Mathias LANG" <geod24 gmail.com> writes:
On Sunday, 1 February 2015 at 01:17:41 UTC, Andrei Alexandrescu 
wrote:

 Hello,


 Walter and I have been mulling for a while on a vision for the 
 first six months of 2015.

 http://wiki.dlang.org/Vision/2015H1

 This is stuff we consider important for D going forward and 
 plan to work actively on. We encourage the D community to focus 
 contributions along the same lines.

 We intentionally kept the document short and high-level as 
 opposed to discussing tactical details. Such discussions are 
 encouraged in the appropriate forums.


 Thanks,

 Walter and Andrei


I'm surprised by one of the goals:

 Our aim is to top 2000 pull requests by June 30, 2015.


This is arguably the most well-defined goal here, but at the same 
time, it sounds strange to judge the contributions by the numbers 
of pull request. We could top that number -and I'm afraid we'll 
be tempted to do so- by submitting a streamline of pull requests 
fixing trivial doc problems / mispelling (I'm not saying docs 
P.R. are worthless), or implementing trivial functions.

I'd rather see a list of (high-level) wanted features here, 
either in Phobos (better file abstraction, better release 
process...) than "Receive & accept 2000 P.R in 6 months".

Regarding Vibe.d:
I partly agree with Dicebot that we should focus on dub first.
However, I like the idea that not-breaking-Vibe.d should be 
required for a release (2.067 being a perfect example of a major 
breaking change for Vibe.d).

In fact, something that I wanted to do for a long time is to have 
"badges" on code.dlang.org, which indicates which library builds 
with which compiler. This is important for the overall quality of 
the language, as, once it's in place, dub will be able to refuse 
fetching a library that's not building with 2.0XX, providing a 
much nicer experience to user. We'll also be able to see how much 
code a release / nightly (which is also something we lack) will 
break code, and how much code in code.dlang.org works with which 
version.
Feb 01 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/1/15 7:48 AM, Mathias LANG wrote:

 This is arguably the most well-defined goal here, but at the same time,
 it sounds strange to judge the contributions by the numbers of pull
 request. We could top that number -and I'm afraid we'll be tempted to do
 so- by submitting a streamline of pull requests fixing trivial doc
 problems / mispelling (I'm not saying docs P.R. are worthless), or
 implementing trivial functions.


Yah, Walter is also unconvinced of such metrics. There's anecdotal 
evidence the use of simple metrics could go either way, the risk for 
abuse being obvious.

However lack of measurable metrics on account of them being open to 
abuse may lead to lack of progress. I've had excellent experience with 
good use of metrics and proxies, and I trust our community there's 
little motivation to look good by playing the numbers.


Andrei
Feb 01 2015
next sibling parent reply "Phil" <phil.j.ellison gmail.com> writes:
I think if a concrete number inspires people to commit loads of 
small fixes to docs, unittests, etc., then this is a good thing. 
It's not like anyone is going to give up on committing when the 
target's reached.
Feb 01 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/1/15 11:02 AM, Phil wrote:

 I think if a concrete number inspires people to commit loads of small
 fixes to docs, unittests, etc., then this is a good thing. It's not like
 anyone is going to give up on committing when the target's reached.


Nicely we already have 484 created in January: 
https://github.com/pulls?q=is%3Apr+user%3AD-Programming-Language+created%3A2015-01-01..2015-01-31

Andrei
Feb 01 2015
prev sibling parent Jonathan M Davis via Digitalmars-d-announce writes:
On Sunday, February 01, 2015 08:41:54 Andrei Alexandrescu via
Digitalmars-d-announce wrote:

 On 2/1/15 7:48 AM, Mathias LANG wrote:

 This is arguably the most well-defined goal here, but at the same time,
 it sounds strange to judge the contributions by the numbers of pull
 request. We could top that number -and I'm afraid we'll be tempted to do
 so- by submitting a streamline of pull requests fixing trivial doc
 problems / mispelling (I'm not saying docs P.R. are worthless), or
 implementing trivial functions.


 Yah, Walter is also unconvinced of such metrics. There's anecdotal
 evidence the use of simple metrics could go either way, the risk for
 abuse being obvious.

 However lack of measurable metrics on account of them being open to
 abuse may lead to lack of progress. I've had excellent experience with
 good use of metrics and proxies, and I trust our community there's
 little motivation to look good by playing the numbers.


I would think that an open source community of volunteers would stand a
better chance of avoiding some of the negatives of tracking various metrics,
because the monetary compensation, promotion opportunities, etc. that such
things can affect in a full-time job are not normally present in an open
source project. There are likely other ways that they could lead to bad
behavior that would affect us, but in general, I think that the odds that
tracking metrics and pushing for their improvement will cause problems are
fairly low. Now, they may not help particularly either, but I see no harm in
trying. We can always stop if we find that it's causing problems.

- Jonathan M Davis
Feb 01 2015
prev sibling next sibling parent reply Andrej Mitrovic via Digitalmars-d-announce writes:
On 2/1/15, Andrei Alexandrescu via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> wrote:

 http://wiki.dlang.org/Vision/2015H1


- Create the D Language Foundation

What exactly is this idea about, can you elaborate a bit?
Feb 01 2015
next sibling parent reply "bachmeier" <no spam.net> writes:
On Sunday, 1 February 2015 at 22:12:41 UTC, Andrej Mitrovic wrote:

 On 2/1/15, Andrei Alexandrescu via Digitalmars-d-announce
 <digitalmars-d-announce puremagic.com> wrote:

 http://wiki.dlang.org/Vision/2015H1


 - Create the D Language Foundation

 What exactly is this idea about, can you elaborate a bit?


I think it's a reference to this thread:

http://forum.dlang.org/thread/m0q2hk$jj4$1 digitalmars.com
Feb 01 2015
parent reply "Dicebot" <public dicebot.lv> writes:
On Sunday, 1 February 2015 at 22:31:47 UTC, bachmeier wrote:

 On Sunday, 1 February 2015 at 22:12:41 UTC, Andrej Mitrovic 
 wrote:

 On 2/1/15, Andrei Alexandrescu via Digitalmars-d-announce
 <digitalmars-d-announce puremagic.com> wrote:

 http://wiki.dlang.org/Vision/2015H1


 - Create the D Language Foundation

 What exactly is this idea about, can you elaborate a bit?


 I think it's a reference to this thread:

 http://forum.dlang.org/thread/m0q2hk$jj4$1 digitalmars.com


Well the question is more like "what exactly are you going to do 
about it from all ideas mentioned?" :)

btw I personally think this is single most important point in the 
list that is necessary to actually moved forward with others in 
focused manner. But it really depends on how it is defined.
Feb 01 2015
next sibling parent reply "Jerry Morrison" <jhm456 gmail.com> writes:
On Sunday, 1 February 2015 at 22:40:49 UTC, Dicebot wrote:

 - Create the D Language Foundation




 btw I personally think this is single most important point in 
 the list that is necessary to actually moved forward with 
 others in focused manner. But it really depends on how it is 
 defined.


Yes, a production language requires staffing the grunt work like 
release planning & management, soundness analysis, usability, 
documentation, bug fixing, testing, support, library development, 
tool development, and administration. (This must be a common 
issue for volunteer open-source projects.)

But first, people need to get on the same page about whether D is 
going to “cross the chasm” [1] to a production language with many 
more users than developers or remain what looks like a base for 
language experiments and hobby projects. I think a lot of 
grumpiness in the forums stems from this communication gap.


The other big thing missing from the Vision doc is picking a 
niche, *for example* a compelling destination for programmers & 
projects currently stuck in C++.
   * can call a wide range of C++ code [practical transition]
   * real-time, can run w/o GC pauses [projects that are OK with 
GC already moved off of C++]
   * familiar, multi-paradigm, fast builds, meta-programming, 
concurrency that doesn't kill you
   * simpler, predictable, few pitfalls, few special cases, few 
design quirks, orthogonal features
   * memory-safe, overflow-safe, reliable, secure, low maintenance 
costs

If you're up for that, it may require an incompatible transition 
(D3?) e.g. to make const non-transitive for C++ compatibility, to 
rethink memory management, and to change or remove incomplete 
features.

BTW a compiled language shines for fast startup (desktop apps) 
and predictable performance (real-time s/w). In contrast, JIT 
compilers and garbage collectors will continue improving program 
throughput (servers).

[1] 
http://smile.amazon.com/Crossing-Chasm-3rd-Geoffrey-Moore-ebook/dp/B00DB3D81G/ref=sr_1_1?s=books&ie=UTF8&qid=1422832418&sr=1-1&keywords=crossing+the+chasm
Feb 01 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/1/15 3:52 PM, Jerry Morrison wrote:

 On Sunday, 1 February 2015 at 22:40:49 UTC, Dicebot wrote:

 - Create the D Language Foundation




 btw I personally think this is single most important point in the list
 that is necessary to actually moved forward with others in focused
 manner. But it really depends on how it is defined.


 Yes, a production language requires staffing the grunt work like release
 planning & management, soundness analysis, usability, documentation, bug
 fixing, testing, support, library development, tool development, and
 administration. (This must be a common issue for volunteer open-source
 projects.)

 But first, people need to get on the same page about whether D is going
 to “cross the chasm” [1] to a production language with many more users
 than developers or remain what looks like a base for language
 experiments and hobby projects. I think a lot of grumpiness in the
 forums stems from this communication gap.


Well put.


 The other big thing missing from the Vision doc is picking a niche,


That may as well come later - or not at all. We don't think it is now 
time to commit to a particular niche.


 *for
 example* a compelling destination for programmers & projects currently
 stuck in C++.
    * can call a wide range of C++ code [practical transition]
    * real-time, can run w/o GC pauses [projects that are OK with GC
 already moved off of C++]
    * familiar, multi-paradigm, fast builds, meta-programming,
 concurrency that doesn't kill you
    * simpler, predictable, few pitfalls, few special cases, few design
 quirks, orthogonal features
    * memory-safe, overflow-safe, reliable, secure, low maintenance costs

 If you're up for that, it may require an incompatible transition (D3?)
 e.g. to make const non-transitive for C++ compatibility, to rethink
 memory management, and to change or remove incomplete features.


We're not planning for an incompatible revision. I see const 
transitivity a small problem; good style C++ code enforces transitive 
const semantics, and guarantees of STL containers have improved in that 
direction in C++11 (STL containers don't need write locks for const 
methods).


Andrei
Feb 01 2015
parent reply "Jerry Morrison" <jhm456 gmail.com> writes:
On Monday, 2 February 2015 at 00:58:53 UTC, Andrei Alexandrescu 
wrote:

 On 2/1/15 3:52 PM, Jerry Morrison wrote:

 The other big thing missing from the Vision doc is picking a 
 niche,


 That may as well come later - or not at all. We don't think it 
 is now time to commit to a particular niche.


OK. Just keep in mind that if you want to “cross the chasm” from 
visionaries to pragmatics, it requires meeting 100% of the needs 
of at least one niche (whether that's real-time, bare-metal, 
desktop apps, web servers, data analysis, mobile apps, or 
whatever).

It does no good to meet 90% of the needs of many niches.

https://blogs.saphana.com/2013/02/04/the-end-of-the-beginning-sap-hana-has-crossed-the-chasm/
Feb 01 2015
next sibling parent "Jerry Morrison" <jhm456 gmail.com> writes:
s/pragmatics/pragmatists/
Feb 01 2015
prev sibling parent reply "Joakim" <dlang joakim.fea.st> writes:
On Monday, 2 February 2015 at 01:43:02 UTC, Jerry Morrison wrote:

 On Monday, 2 February 2015 at 00:58:53 UTC, Andrei Alexandrescu 
 wrote:

 On 2/1/15 3:52 PM, Jerry Morrison wrote:

 The other big thing missing from the Vision doc is picking a 
 niche,


 That may as well come later - or not at all. We don't think it 
 is now time to commit to a particular niche.


 OK. Just keep in mind that if you want to “cross the chasm” 
 from visionaries to pragmatics, it requires meeting 100% of the 
 needs of at least one niche (whether that's real-time, 
 bare-metal, desktop apps, web servers, data analysis, mobile 
 apps, or whatever).

 It does no good to meet 90% of the needs of many niches.

 https://blogs.saphana.com/2013/02/04/the-end-of-the-beginning-sap-hana-has-crossed-the-chasm/


What was the niche C++ aimed for a couple decades back, C with 
objects?  D is aiming for the same "niche" as C and C++, a 
general-purpose, native-compiled language that allows you to 
extract almost-maximal performance while still being relatively 
easy to use, at least compared to the alternatives.

Perhaps focusing on a smaller niche first would allow D to gain a 
larger following quicker, but that might box it in from becoming 
more general-purpose later, as early decisions optimize for that 
niche and might be tough to undo.  Go certainly seems stuck in a 
niche now, though I'm not sure how much of that is because they 
just don't want to add more general-purpose features like 
generics, ie they're happy in their niche.

C and C++ are very general-purpose, but they can still be 
considered as a "niche" of performance languages.  What's wrong 
with D aiming for that "niche?"
Feb 01 2015
next sibling parent reply "Jerry Morrison" <jhm456 gmail.com> writes:
On Monday, 2 February 2015 at 03:50:10 UTC, Joakim wrote:

 C and C++ are very general-purpose, but they can still be 
 considered as a "niche" of performance languages.  What's wrong 
 with D aiming for that "niche?"


Most uses of C & C++ that haven't migrated to well-supported 
garbage-collected languages by now are those that cannot work 
with a garbage collector and/or are heavily tied to an existing 
C++ code base. Offering something much better for that 
niche/domain would be a great opportunity, and not a small niche.

The point is to focus efforts for one release on fully addressing 
what that domain requires. The next release can focus on another 
domain. And so on.
Feb 01 2015
parent reply "Joakim" <dlang joakim.fea.st> writes:
On Monday, 2 February 2015 at 05:17:40 UTC, Jerry Morrison wrote:

 On Monday, 2 February 2015 at 03:50:10 UTC, Joakim wrote:

 C and C++ are very general-purpose, but they can still be 
 considered as a "niche" of performance languages.  What's 
 wrong with D aiming for that "niche?"


 Most uses of C & C++ that haven't migrated to well-supported 
 garbage-collected languages by now are those that cannot work 
 with a garbage collector and/or are heavily tied to an existing 
 C++ code base. Offering something much better for that 
 niche/domain would be a great opportunity, and not a small 
 niche.

 The point is to focus efforts for one release on fully 
 addressing what that domain requires. The next release can 
 focus on another domain. And so on.


Well, given the current focus on  nogc and C++ integration, it 
appears that niche has been chosen, and you and Ola get your wish.
Feb 02 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 2 February 2015 at 18:20:18 UTC, Joakim wrote:

 Well, given the current focus on  nogc and C++ integration, it 
 appears that niche has been chosen, and you and Ola get your 
 wish.


Uhm... I don't think D-side STL and C++ exceptions is a good 
idea. I don't think tying the runtime to C++/C runtime is a good 
idea.

Most "indispensable" C/C++ libraries can be wrapped in a light 
weight fashion (but generating C++ code from D to instantiate 
templates utilizing "clang as a library" seems useful...).
Feb 02 2015
prev sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 2 February 2015 at 03:50:10 UTC, Joakim wrote:

 C and C++ are very general-purpose, but they can still be 
 considered as a "niche" of performance languages.  What's wrong 
 with D aiming for that "niche?"


That would be great, but the language designers are not aiming 
for it. The ideal in that niche is to use the hardware/OS 
features directly, including the threading model. Phobos + GC is 
way too invasive and presumptuous.

But C/C++/LLVM is already suffering from being based on scalars. 
Will it be able to keep up when vector based IRs mature? Will 
languages not built around SIMD and cache locality survive? Hard 
to say...
Feb 02 2015
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/1/15 2:40 PM, Dicebot wrote:

 On Sunday, 1 February 2015 at 22:31:47 UTC, bachmeier wrote:

 On Sunday, 1 February 2015 at 22:12:41 UTC, Andrej Mitrovic wrote:

 On 2/1/15, Andrei Alexandrescu via Digitalmars-d-announce
 <digitalmars-d-announce puremagic.com> wrote:

 http://wiki.dlang.org/Vision/2015H1


 - Create the D Language Foundation

 What exactly is this idea about, can you elaborate a bit?


 I think it's a reference to this thread:

 http://forum.dlang.org/thread/m0q2hk$jj4$1 digitalmars.com


 Well the question is more like "what exactly are you going to do about
 it from all ideas mentioned?" :)


I don't understand this question. -- Andrei
Feb 01 2015
parent reply "Dicebot" <public dicebot.lv> writes:
On Monday, 2 February 2015 at 00:23:22 UTC, Andrei Alexandrescu 
wrote:

 On 2/1/15 2:40 PM, Dicebot wrote:

 On Sunday, 1 February 2015 at 22:31:47 UTC, bachmeier wrote:

 On Sunday, 1 February 2015 at 22:12:41 UTC, Andrej Mitrovic 
 wrote:

 On 2/1/15, Andrei Alexandrescu via Digitalmars-d-announce
 <digitalmars-d-announce puremagic.com> wrote:

 http://wiki.dlang.org/Vision/2015H1


 - Create the D Language Foundation

 What exactly is this idea about, can you elaborate a bit?


 I think it's a reference to this thread:

 http://forum.dlang.org/thread/m0q2hk$jj4$1 digitalmars.com


 Well the question is more like "what exactly are you going to 
 do about
 it from all ideas mentioned?" :)


 I don't understand this question. -- Andrei


You have already partially asked here 
http://forum.dlang.org/post/mamfhp$1den$1 digitalmars.com
Feb 01 2015
parent "Dicebot" <public dicebot.lv> writes:
*answered
Feb 01 2015
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/1/15 1:46 PM, Andrej Mitrovic via Digitalmars-d-announce wrote:

 On 2/1/15, Andrei Alexandrescu via Digitalmars-d-announce
 <digitalmars-d-announce puremagic.com> wrote:

 http://wiki.dlang.org/Vision/2015H1


 - Create the D Language Foundation

 What exactly is this idea about, can you elaborate a bit?


Glad you asked. We currently have a few expenses associated with D 
operation. Walter and I prefer to be discreet about such, but some of 
them are fairly obvious and non-negligible - such as DConf.

Such expenses have been covered by the kickstarter campaign (for DConf 
2013) and now are going out of Walter's and my pocket. We've increased 
expenditures lately, to good effect, and would like to continue to do so 
but of course without becoming homeless in the process :o). It's become 
clear to us that the best way to scale things up is a formal framework, 
and a foundation is a commonly-used mechanism for such.

A foundation would provide a fair and transparent way for us to accept 
contributions, small and large, from interested parties, and apply them 
to further understanding and adoption of D.


Andrei
Feb 01 2015
parent "Dicebot" <public dicebot.lv> writes:
On Monday, 2 February 2015 at 00:14:51 UTC, Andrei Alexandrescu 
wrote:

 On 2/1/15 1:46 PM, Andrej Mitrovic via Digitalmars-d-announce 
 wrote:

 On 2/1/15, Andrei Alexandrescu via Digitalmars-d-announce
 <digitalmars-d-announce puremagic.com> wrote:

 http://wiki.dlang.org/Vision/2015H1


 - Create the D Language Foundation

 What exactly is this idea about, can you elaborate a bit?


 Glad you asked. We currently have a few expenses associated 
 with D operation. Walter and I prefer to be discreet about 
 such, but some of them are fairly obvious and non-negligible - 
 such as DConf.

 Such expenses have been covered by the kickstarter campaign 
 (for DConf 2013) and now are going out of Walter's and my 
 pocket. We've increased expenditures lately, to good effect, 
 and would like to continue to do so but of course without 
 becoming homeless in the process :o). It's become clear to us 
 that the best way to scale things up is a formal framework, and 
 a foundation is a commonly-used mechanism for such.

 A foundation would provide a fair and transparent way for us to 
 accept contributions, small and large, from interested parties, 
 and apply them to further understanding and adoption of D.


By the way I have forwarded the information that something is 
brewing to Sociomantic leadership - will report if they would 
want to participate in it one way or another :)
Feb 02 2015
prev sibling next sibling parent reply Russel Winder via Digitalmars-d-announce writes:
On Sun, 2015-02-01 at 22:46 +0100, Andrej Mitrovic via Digitalmars-d-announce
wrote:

 On 2/1/15, Andrei Alexandrescu via Digitalmars-d-announce <
 digitalmars-d-announce puremagic.com> wrote:

 http://wiki.dlang.org/Vision/2015H1


 
 - Create the D Language Foundation
 
 What exactly is this idea about, can you elaborate a bit?


Given involvement with SCons (which used to have a foundation, but it 
seems to have lapsed, but we need it), and Groovy (never had one but 
almost certainly needs one now), I see three main issues:

— A centralized organization supporting the distributed FOSS project, 
giving other organizations a generalized single point of contact. Also 
having an organization, not just a collection of individuals, given 
other organizations confidence in support, continuity and development.

— A legally established foundation can be the holder of IP. It makes 
any debates about licencing, etc. easier if there is a single entity 
to deal with. Really though this is more to keep other organizations 
happy and confident.

— A foundation can be a funds collection and redistribution entity. 
Again stuff can happen without a central "not for profit" 
organization, but it generates confidence in other organizations if 
there is one. Strong rather than small intermittent funded activity is 
more likely with a foundation than without.
  
Then you get the questions of where (in which jurisdiction), and who 
are the "directors" and how do they get changed.

There are many "off-the-shelf" organizational structures so it is 
"pick one". The problem of jurisdiction is more difficult these days. 
The usual knee-jerk reaction is "create a 'not for profit' in the 
USA". (Actually for D, like SCons, this is probably the most sensible 
start point; for Groovy it is far more difficult and less the right 
choice.) Unofficial legal opinion is that the USA government is 
currently very anti any new software language foundations. If true, 
that makes the Python Software Foundation model not viable. This would 
leave joining Eclipse or Apache (not really viable for D or SCons I 
suspect), or the Software Conservancy. A number of projects have gone 
this route, SCons is considering it since re-establishing a fully 
independent SCons Foundation is seeming an up-hill struggle.

I am not a lawyer.
-- 
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
Feb 02 2015
parent "Tobias Pankrath" <tobias pankrath.net> writes:
KDE is a german e.V. (eingetragener Verein, registered 
association [1] ). Maybe that's an option for D, too.


[1] http://en.wikipedia.org/wiki/Eingetragener_Verein
Feb 02 2015
prev sibling parent "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Sunday, 1 February 2015 at 01:17:41 UTC, Andrei Alexandrescu 
wrote:

 Hello,


 Walter and I have been mulling for a while on a vision for the 
 first six months of 2015.

 http://wiki.dlang.org/Vision/2015H1

 This is stuff we consider important for D going forward and 
 plan to work actively on. We encourage the D community to focus 
 contributions along the same lines.


While a don't see the content as disagreeable, I do find it to be 
a lot to focus on for the next 6 months.

* Improve language stability
* Memory Management
* Safety
* C++ integration

These all seem like that could deserve their own 6 months of 
focus. These should all get work, but it just seems that if 
you're going to take priority on something it shouldn't be spread 
across so many large tasks. Or maybe there just needs to be a 
list of things not taking priority.
Feb 02 2015