Re: 2015 H1 Vision
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.
Re: 2015 H1 Vision
On Mon, 2015-02-02 at 12:36 +, 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.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: 2015 H1 Vision
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.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: 2015 H1 Vision
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
Re: 2015 H1 Vision
On Mon, 2015-02-02 at 07:59 +, 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.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: 2015 H1 Vision
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
Re: 2015 H1 Vision
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...
Re: 2015 H1 Vision
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.
Re: 2015 H1 Vision
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 :)
Re: 2015 H1 Vision
On Mon, Feb 02, 2015 at 12:50:54 +, 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
Re: 2015 H1 Vision
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.
Re: 2015 H1 Vision
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...).
Re: 2015 H1 Vision
On Mon, 02 Feb 2015 08:35:07 +0100, 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. i agree with you. the best thing of dub -- package management and dependency management -- should be easily accessible. something like pkg- config, but with ability to download/install/uninstall/upgrade packages. i.e. pkg manager like apt ;-), plus pkg-config functionality to allow using in various build tools. but i think that it's too late now to separate this dub parts. :-( signature.asc Description: PGP signature
Re: 2015 H1 Vision
On Monday, 2 February 2015 at 05:23:52 UTC, Daniel Murphy wrote: Vladimir Panteleev wrote in message news:viqwfixznbdbdwvha...@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/ysnfzpvrcvmjdekul...@forum.dlang.org
Re: 2015 H1 Vision
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.
Re: 2015 H1 Vision
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.
Re: 2015 H1 Vision
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.
Re: 2015 H1 Vision
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
Re: 2015 H1 Vision
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
Re: 2015 H1 Vision
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.
Re: 2015 H1 Vision
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.
Re: 2015 H1 Vision
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
Re: 2015 H1 Vision
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.
Re: 2015 H1 Vision
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.
Re: 2015 H1 Vision
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?
Re: 2015 H1 Vision
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
Re: 2015 H1 Vision
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
Re: 2015 H1 Vision
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.
Re: 2015 H1 Vision
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
Re: 2015 H1 Vision
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=booksie=UTF8qid=1422832418sr=1-1keywords=crossing+the+chasm
Re: 2015 H1 Vision
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
Re: 2015 H1 Vision
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
Re: 2015 H1 Vision
*answered
Re: 2015 H1 Vision
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
Re: 2015 H1 Vision
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
Re: 2015 H1 Vision
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?
Re: 2015 H1 Vision
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/
Re: 2015 H1 Vision
s/pragmatics/pragmatists/
Re: 2015 H1 Vision
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
Re: 2015 H1 Vision
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:viqwfixznbdbdwvha...@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).
Re: 2015 H1 Vision
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.
Re: 2015 H1 Vision
Vladimir Panteleev wrote in message news:viqwfixznbdbdwvha...@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.
Re: 2015 H1 Vision
On Mon, 02 Feb 2015 16:24:00 +1100, Daniel Murphy wrote: Vladimir Panteleev wrote in message news:viqwfixznbdbdwvha...@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. signature.asc Description: PGP signature
2015 H1 Vision
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
Re: 2015 H1 Vision
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 :/
Re: 2015 H1 Vision
Joakim wrote in message news:nphrawlkmiwksghfy...@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.
Re: 2015 H1 Vision
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 :-)
Re: 2015 H1 Vision
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.
Re: 2015 H1 Vision
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!
