2019 H1 Vision document?
Looks like 2018H2 vision hasn't been published, and it's a bit late for it. Are there any plans for 2019H1 document? I think it provides a good framework for discussions, gives something to get excited about. Right now it's hard to see what are the short and long term goals for the language and ecosystem, from the perspective of leadership.
Re: High-level vision for 2018 H2?
On 8/18/2018 8:55 AM, David Nadlinger wrote: On Saturday, 18 August 2018 at 07:50:04 UTC, Dukc wrote: What's HOPL? https://hopl4.sigplan.org, presumably. —David That's right.
Re: High-level vision for 2018 H2?
On Saturday, 18 August 2018 at 07:50:04 UTC, Dukc wrote: On Thursday, 16 August 2018 at 14:11:20 UTC, Andrei Alexandrescu wrote: we're working on a HOPL submission. What's HOPL? https://hopl4.sigplan.org, presumably. —David
Re: High-level vision for 2018 H2?
On Saturday, 18 August 2018 at 07:50:04 UTC, Dukc wrote: On Thursday, 16 August 2018 at 14:11:20 UTC, Andrei Alexandrescu wrote: we're working on a HOPL submission. What's HOPL? http://www.hopl.info/
Re: High-level vision for 2018 H2?
On Thursday, 16 August 2018 at 14:11:20 UTC, Andrei Alexandrescu wrote: we're working on a HOPL submission. What's HOPL?
Re: High-level vision for 2018 H2?
On 8/13/18 10:06 AM, walker wrote: I am curious about the plan of 2018/H2 version also, the H1 is very promising and may be hard to summarize its output. Thanks for the interest. We're behind this mainly because we're working on a HOPL submission. I'll try to delegate.
Re: High-level vision for 2018 H2?
On Monday, 13 August 2018 at 14:06:24 UTC, walker wrote: I am curious about the plan of 2018/H2 version also, the H1 is very promising and may be hard to summarize its output. --walker + 1 Decillion D needs more vision talk and elaboration Long term goals increase motivation around the project
Re: High-level vision for 2018 H2?
I am curious about the plan of 2018/H2 version also, the H1 is very promising and may be hard to summarize its output. --walker
Re: High-level vision for 2018 H2?
On Saturday, 28 July 2018 at 08:37:25 UTC, Peter Alexander wrote: The wiki still links to high-level vision for 2018 H1. We're now nearly one month into H2. Is a H2 document in progress? Bump
High-level vision for 2018 H2?
The wiki still links to high-level vision for 2018 H1. We're now nearly one month into H2. Is a H2 document in progress?
Re: A strategic vision for D
On Monday, 7 May 2018 at 15:52:38 UTC, David J Kordsmeier wrote: On Monday, 7 May 2018 at 10:27:32 UTC, Joakim wrote: [...] Great marketing beats great tech (sadly), but we are creatures subject to social influence and that which is shiny. Who actually runs marketing for Dlang? Is it the foundation, collective cooperation, or ? Does Dlang have what it needs to be successful in this category in terms of financial resources, expertise, and focus? As an aside, this was the original marketing for Node.js, in the years before it was acquired by Joyent: http://tinyclouds.org/ . In a single year, it caught fire (that is, it became wildly successful) because it had a strong BDFL (who was not a dictator, and who stepped down as soon as it made sense to do so, and he took on some messianic stature as a result), strong technical merits, a clear focused message of where it fit in the market, and it met a need. In fact, it met many more needs than intended, widely used in both cloud and embedded type applications. 8 years on from moving the project into the hands of a corporate sponsor, through much controversy over governance and some community strife, forks, etc., it's doing well in the hands of a foundation: https://foundation.nodejs.org/ . From a market focused perspective there is the technology itself in one bucket, and then there is the adoption by enterprise. Certain things have to happen for enterprise adoption to actually take place. If we follow the pattern of what happened for Go or Node.js, we can boil those down to execution of certain tangibles: - Project is well documented - Project is available under favorable OSS license (I won't get into what favorable means, but for corporations, they have their preferences) - Project has a good toolchain and tools support - Project has a good IDE integration - Project has good sample applications built, lots of good examples - Project has a strong and active community of developers with the appropriate mix of core contributors, external contributors, experts, casual users, and people evaluating possible use - Project has strong technical merits - Project has strong market differentiators (this may require real marketing to get this down on paper and promote this) - Project has commercial support available (training, bug fixing, development) - Project has an academic community (this often helps seed use in Universities), and students eventually grow up to work for enterprise corporations - Project has corporate sponsors (or foundation sponsors ... they are really representing corporations) - Project has a sustainable model (legal, financial) to maintain its community, engineering, and marketing. - Project has multiple big projects that rely upon it Grade Go, Rust, and Node.js on this list above. Where are they at on each item? Grade Dlang on this. We still have some work to do. What companies offer commercial support in D? Are there any Dlang focused agencies out there? How many projects are using Dlang commercially? Who are the corporate sponsors of Dlang? Again, I think much of this comes back to that marketing message. What is the unique selling proposition. Define that. Then conquer the world. Those are mostly things that have to be done collectively in a community project like this. Much has already been done: the front page of the website has a slogan, "Fast code, fast," and a list of companies using D. D is never going to have a completely structured process like a well-organized company, where it defines those objectives and then pays to get them done. As a community project, it's much more decentralized, which has its pros and cons, but more positives for me than being backed by a single company. However, what the community leaders can do is put out a strategic vision, for the community to gather around if they accept it. The vision document is a great example of this, where anyone can pick items off that list and go work on them. However, an overall strategy is broader than that, which someone could further by working on something _not on that list_, that they think up themselves.
Re: A strategic vision for D
On Monday, 7 May 2018 at 21:55:28 UTC, Dave Jones wrote I'm sure Walter and Andrei would love to have the newsgroup micromanaging their decision making process. i dont think anyone is trying to micromanage anyone i think D's strategic positioning, is a very interesting question and it is normal for some, especially for new comers or anyway who is not already very invested in D to be interested in an answer and in D's case i think it is hard to find a satisfying answer D have two leaders and you mention Andrei and Walter, and the way I see, I dont think they both fully agree on an answer for this question Going back to D's 2018 vision document and comparing whats in it to both Andrei and Walter comments and youtube videos I would argue Walter is all in on the -betterC feature (for now), while Andrei is more into improving D overall and doubling down on introspection Both are really good and unique features
Re: A strategic vision for D
On Wednesday, 2 May 2018 at 04:48:46 UTC, Joakim wrote: On Wednesday, 2 May 2018 at 03:44:37 UTC, Nick Sabalausky (Abscissa) wrote: On 05/01/2018 10:27 PM, Joakim wrote: Yes, but how is it decided what the "most important things" are? There is a strategy at work for any prioritization, even if it's implicit and never even articulated in their own minds. If unarticulated, you can gain a lot by spending time to articulate it, as you may find unwanted contradictions in the way you had been prioritizing. I'm sure Walter and Andrei would love to have the newsgroup micromanaging their decision making process.
Re: A strategic vision for D
On Monday, 7 May 2018 at 10:27:32 UTC, Joakim wrote: On Saturday, 5 May 2018 at 04:59:58 UTC, germandiago wrote: On Tuesday, 1 May 2018 at 12:26:25 UTC, Joakim wrote: [...] My 2 cents. I have been following D for a long time and started using it in a very small project. I am a very long term C++ user. [...] Interesting analysis. These are pretty much the points of technical and marketing emphasis today, so it appears the current message resonated with you. However, I was talking about more from the point of which markets D would target first, ie the types of end users who'd use D, whether game programmers or compiled GUI apps. So far D's gained some traction at startups that need performance. One issue with the current approach is that they seem to implicitly assume that D needs to match or surpass C and C++. Can't disagree with the betterC approach as that's really needed, but I'm not sure if D should want to be a better C++. Certainly app devs don't really care about @nogc and the current systems programming emphasis aimed at C++ devs like you. My point is that whatever that strategy is should be clearly articulated, or you may even undermine yourself by not thinking through carefully what your goals are. Great marketing beats great tech (sadly), but we are creatures subject to social influence and that which is shiny. Who actually runs marketing for Dlang? Is it the foundation, collective cooperation, or ? Does Dlang have what it needs to be successful in this category in terms of financial resources, expertise, and focus? As an aside, this was the original marketing for Node.js, in the years before it was acquired by Joyent: http://tinyclouds.org/ . In a single year, it caught fire (that is, it became wildly successful) because it had a strong BDFL (who was not a dictator, and who stepped down as soon as it made sense to do so, and he took on some messianic stature as a result), strong technical merits, a clear focused message of where it fit in the market, and it met a need. In fact, it met many more needs than intended, widely used in both cloud and embedded type applications. 8 years on from moving the project into the hands of a corporate sponsor, through much controversy over governance and some community strife, forks, etc., it's doing well in the hands of a foundation: https://foundation.nodejs.org/ . From a market focused perspective there is the technology itself in one bucket, and then there is the adoption by enterprise. Certain things have to happen for enterprise adoption to actually take place. If we follow the pattern of what happened for Go or Node.js, we can boil those down to execution of certain tangibles: - Project is well documented - Project is available under favorable OSS license (I won't get into what favorable means, but for corporations, they have their preferences) - Project has a good toolchain and tools support - Project has a good IDE integration - Project has good sample applications built, lots of good examples - Project has a strong and active community of developers with the appropriate mix of core contributors, external contributors, experts, casual users, and people evaluating possible use - Project has strong technical merits - Project has strong market differentiators (this may require real marketing to get this down on paper and promote this) - Project has commercial support available (training, bug fixing, development) - Project has an academic community (this often helps seed use in Universities), and students eventually grow up to work for enterprise corporations - Project has corporate sponsors (or foundation sponsors ... they are really representing corporations) - Project has a sustainable model (legal, financial) to maintain its community, engineering, and marketing. - Project has multiple big projects that rely upon it Grade Go, Rust, and Node.js on this list above. Where are they at on each item? Grade Dlang on this. We still have some work to do. What companies offer commercial support in D? Are there any Dlang focused agencies out there? How many projects are using Dlang commercially? Who are the corporate sponsors of Dlang? Again, I think much of this comes back to that marketing message. What is the unique selling proposition. Define that. Then conquer the world.
Re: A strategic vision for D
On Saturday, 5 May 2018 at 04:59:58 UTC, germandiago wrote: On Tuesday, 1 May 2018 at 12:26:25 UTC, Joakim wrote: [...] My 2 cents. I have been following D for a long time and started using it in a very small project. I am a very long term C++ user. [...] Interesting analysis. These are pretty much the points of technical and marketing emphasis today, so it appears the current message resonated with you. However, I was talking about more from the point of which markets D would target first, ie the types of end users who'd use D, whether game programmers or compiled GUI apps. So far D's gained some traction at startups that need performance. One issue with the current approach is that they seem to implicitly assume that D needs to match or surpass C and C++. Can't disagree with the betterC approach as that's really needed, but I'm not sure if D should want to be a better C++. Certainly app devs don't really care about @nogc and the current systems programming emphasis aimed at C++ devs like you. My point is that whatever that strategy is should be clearly articulated, or you may even undermine yourself by not thinking through carefully what your goals are.
Re: A strategic vision for D
On Tuesday, 1 May 2018 at 12:26:25 UTC, Joakim wrote: I realize it's right before the conference, but I'd like to put out a request for Walter and Andrei to spend five minutes during your talks laying out some overarching strategy for how you see D evolving. It could be during the keynotes or leading off the Q&A panel, but I think it's worth laying a broad strategy out there. Specifically, what uses do you see D being put to for the next five years and how do we make it better in those directions. For example, in what way you'd like to see D get better as a language for writing apps, or what particular niches you see D as a systems language doing well in first. For another example, here's what I'd say, ie my strategic vision: the pendulum is about to swing hard back towards the client, towards the billion and a half mobile devices sold each year, and D is ideally positioned with its native efficiency to do well there. However, since it's not the blessed language for any mobile platform, like Kotlin or Swift, it will take much work on libraries to pull that off. Some caveats: since D is not controlled by a company with W&A as co-CEOs, they cannot obviously order people to follow their vision. However, that should leave you free to really share your unexpurgated thoughts, after all, we're all free to ignore it. ;) Another is that perhaps D has chosen to evolve tactically as opposed to strategically, carefully picking off wins with a new feature or mode of programming but not following any grand strategy, similar to how Linus Torvalds claims he didn't have any grand vision for linux either. However, a strategic vision can inspire people to work towards that goal, if there is one to be shared. My 2 cents. I have been following D for a long time and started using it in a very small project. I am a very long term C++ user. Many people say that D does not offer anything over C++, improvements-wise. Or people tell you that there is Go and Rust. Because D does not have these fancy algebraic data types, or that borrow checker... no, no and NO. I think we do not need to enter that game. I have tried all 3. Here is my opinion. 1. Go --> excellent...!!! For what it does: namely, intensive communication client/server. It falls short of abstraction power in some areas, has no compile-time evaluation, no metaprogramming... though I must recognize it works pretty smooth for its simplicity. 2. Rust --> the borrow checker... excellent, in theory: in practice, as Andrei Alexandrescu once mentioned: you spend a lot of effort on something that in reality is not a problem most of the time. It is a problem, yes, but these problems can be avoided with much more lightweight solutions or simply, as D does, being able to avoid GC where it is needed. A much more practical solution. Rust has other things of value, such as Algebraic data types and Traits, but the borrow checker has a big impact for several reasons: it takes time to get used to, socially, people cannot use Rust from day one, so... you need added training for teams. But also remember... an "alien" type system makes it more difficult for integration with previous systems. How should be D advertised? Well, I think that Ali Çehreli did a good job explaining in one of his keynotes the conveniencies of D, but this will not make people migrate. Why I am myself starting to take a look into D? I am a person that if I publish a project as open source, I want people to be able to contribute. Coding is, above all, a social activity, so: - Come from Java, C#, want faster alternative? D will take little effort. - Come from C, abstractions are too low level? D will take the same effort as alternatives with native performance, but you can start coding today. - Come from C++ (like myself)? D is way cleaner and more convenient: modules, better metaprogramming, pervasive CTFE, *much better introspection* and also easy to learn. Those are all good reasons, but, for me, what sets D apart is its level of integration with C/C++. If I come for D in the first place is because I can reuse my old code. This is true for most businesses: they have older code to integrate. So my opinion is that D is a very pragmatic language that has this real, also management-perceivable advantages over all these nice algebraic data types integrated into the language and so on: - if I pick up D in a team, it is very likely that D will be easier to pick up because many, many people know C++/Java/C# or similar things. This is a very important social factor and usually not mentioned or underestimated. - if I have some C/C++ code to integrate, I can do it *way smoother* than with other languages to do it: please guys keep working on this. - if I want safety, there are mechanisms that take you 90% there. Why would you pick up an alien like Rust where you
Re: A strategic vision for D
On Tuesday, 1 May 2018 at 22:20:53 UTC, John Gabriele wrote: On Tuesday, 1 May 2018 at 17:20:54 UTC, Ali wrote: I think point 1 in the vision is very telling 1. Lock down the language definition Sorry, I'm not understanding. To me that says the core team values multiple implementations that adhere to the same spec. Does it imply something else? In many ways, I agree, with the other comments the current strategy seem to continue pushing D as a safer more predictable systems programming language Lock down the language definition, will help make D more predictable, and safer to use
Re: A strategic vision for D
On Wednesday, 2 May 2018 at 03:44:37 UTC, Nick Sabalausky (Abscissa) wrote: On 05/01/2018 10:27 PM, Joakim wrote: Those are specific technical priorities that hint at a strategy, as you say, but it is better to lay out that strategy itself. Not knocking that vision document, as I called for a concrete document like that for years, but a conference keynote is a good place to lay out a strategy too. I think the "overall strategy" is simply: "Identify the most important things for the core folk to work on, prioritize those things." Really don't think anything beyond that really matters or exists. We're not exactly pitching to VC's here. Yes, but how is it decided what the "most important things" are? There is a strategy at work for any prioritization, even if it's implicit and never even articulated in their own minds. If unarticulated, you can gain a lot by spending time to articulate it, as you may find unwanted contradictions in the way you had been prioritizing. As for pitching VCs, there's a reason they want to know that vision, to know if that's something worth investing in. Similarly, potential D users and the existing community want to know if there's a vision worth investing their time and money into. Since D is an open source project, they're always free to ignore the core team's vision and use D in their own way, ie meld their own vision as Linus talks about happened with linux over the years, but it helps to know what the core team's strategy is for many people.
Re: A strategic vision for D
On 05/01/2018 10:27 PM, Joakim wrote: Those are specific technical priorities that hint at a strategy, as you say, but it is better to lay out that strategy itself. Not knocking that vision document, as I called for a concrete document like that for years, but a conference keynote is a good place to lay out a strategy too. I think the "overall strategy" is simply: "Identify the most important things for the core folk to work on, prioritize those things." Really don't think anything beyond that really matters or exists. We're not exactly pitching to VC's here.
Re: A strategic vision for D
On Tuesday, 1 May 2018 at 17:20:54 UTC, Ali wrote: On Tuesday, 1 May 2018 at 12:26:25 UTC, Joakim wrote: I realize it's right before the conference, but I'd like to put out a request for Walter and Andrei to spend five minutes during your talks laying out some overarching strategy for how you see D evolving. It could be during the keynotes or leading off the Q&A panel, but I think it's worth laying a broad strategy out there. For D's vision as set by D's core team check https://wiki.dlang.org/Vision/2018H1 It is very clear, and feel free to read between the lines, on what might be the long term strategy I think point 1 in the vision is very telling 1. Lock down the language definition Those are specific technical priorities that hint at a strategy, as you say, but it is better to lay out that strategy itself. Not knocking that vision document, as I called for a concrete document like that for years, but a conference keynote is a good place to lay out a strategy too.
Re: A strategic vision for D
On Tuesday, 1 May 2018 at 22:20:53 UTC, John Gabriele wrote: On Tuesday, 1 May 2018 at 17:20:54 UTC, Ali wrote: It is very clear, and feel free to read between the lines, on what might be the long term strategy I think point 1 in the vision is very telling 1. Lock down the language definition Sorry, I'm not understanding. To me that says the core team values multiple implementations that adhere to the same spec. Does it imply something else? I think it means stop making changes to the language, and all further changes are limited to library-only. (Could be wrong. Hope I'm wrong. But that is the impression I've been getting that Andrei's been pushing for for quite awhile.)
Re: A strategic vision for D
On Tuesday, 1 May 2018 at 17:20:54 UTC, Ali wrote: On Tuesday, 1 May 2018 at 12:26:25 UTC, Joakim wrote: I realize it's right before the conference, but I'd like to put out a request for Walter and Andrei to spend five minutes during your talks laying out some overarching strategy for how you see D evolving. It could be during the keynotes or leading off the Q&A panel, but I think it's worth laying a broad strategy out there. For D's vision as set by D's core team check https://wiki.dlang.org/Vision/2018H1 In particular, I'd like to hear how the core team weighs: * making useful breaking changes vs maintaining backcompat, and * adding more features vs more simplification of the language. It is very clear, and feel free to read between the lines, on what might be the long term strategy I think point 1 in the vision is very telling 1. Lock down the language definition Sorry, I'm not understanding. To me that says the core team values multiple implementations that adhere to the same spec. Does it imply something else?
Re: A strategic vision for D
On Tuesday, 1 May 2018 at 12:26:25 UTC, Joakim wrote: I realize it's right before the conference, but I'd like to put out a request for Walter and Andrei to spend five minutes during your talks laying out some overarching strategy for how you see D evolving. It could be during the keynotes or leading off the Q&A panel, but I think it's worth laying a broad strategy out there. For D's vision as set by D's core team check https://wiki.dlang.org/Vision/2018H1 It is very clear, and feel free to read between the lines, on what might be the long term strategy I think point 1 in the vision is very telling 1. Lock down the language definition
Re: A strategic vision for D
On Tuesday, 1 May 2018 at 12:46:04 UTC, bachmeier wrote: On Tuesday, 1 May 2018 at 12:26:25 UTC, Joakim wrote: I realize it's right before the conference, but I'd like to put out a request for Walter and Andrei to spend five minutes during your talks laying out some overarching strategy for how you see D evolving. It could be during the keynotes or leading off the Q&A panel, but I think it's worth laying a broad strategy out there. My vision for D is that we'll get to a point where the community develops its own infrastructure to push D forward without the involvement of Andrei, Walter, or the D Foundation. Things like SciPy, RStudio, and the like. Not just a few side projects, but really large projects with many contributors. That's been going on for some time now, W&A and the foundation do a minority of the work, albeit very important. Mir is in the vein you seem to want and wasn't driven by them. I think Weka sponsors some work on ldc, at least for themselves. But I take your point that it'd be good to see more efforts like that. I had hoped the bounties would spur some pooling around particular issues like that, but it hasn't done that well.
Re: A strategic vision for D
On Tuesday, 1 May 2018 at 12:26:25 UTC, Joakim wrote: I realize it's right before the conference, but I'd like to put out a request for Walter and Andrei to spend five minutes during your talks laying out some overarching strategy for how you see D evolving. It could be during the keynotes or leading off the Q&A panel, but I think it's worth laying a broad strategy out there. My vision for D is that we'll get to a point where the community develops its own infrastructure to push D forward without the involvement of Andrei, Walter, or the D Foundation. Things like SciPy, RStudio, and the like. Not just a few side projects, but really large projects with many contributors.
A strategic vision for D
I realize it's right before the conference, but I'd like to put out a request for Walter and Andrei to spend five minutes during your talks laying out some overarching strategy for how you see D evolving. It could be during the keynotes or leading off the Q&A panel, but I think it's worth laying a broad strategy out there. Specifically, what uses do you see D being put to for the next five years and how do we make it better in those directions. For example, in what way you'd like to see D get better as a language for writing apps, or what particular niches you see D as a systems language doing well in first. For another example, here's what I'd say, ie my strategic vision: the pendulum is about to swing hard back towards the client, towards the billion and a half mobile devices sold each year, and D is ideally positioned with its native efficiency to do well there. However, since it's not the blessed language for any mobile platform, like Kotlin or Swift, it will take much work on libraries to pull that off. Some caveats: since D is not controlled by a company with W&A as co-CEOs, they cannot obviously order people to follow their vision. However, that should leave you free to really share your unexpurgated thoughts, after all, we're all free to ignore it. ;) Another is that perhaps D has chosen to evolve tactically as opposed to strategically, carefully picking off wins with a new feature or mode of programming but not following any grand strategy, similar to how Linus Torvalds claims he didn't have any grand vision for linux either. However, a strategic vision can inspire people to work towards that goal, if there is one to be shared.
Vision for 2018 H1?
Is it intended to be updated? No pressure, just making sure it's not forgotten...
Re: Vision for the D language - stabilizing complexity?
On 15.07.2016 22:29, Walter Bright wrote: On 7/15/2016 12:55 PM, Jack Stouffer wrote: On Friday, 15 July 2016 at 19:06:15 UTC, Walter Bright wrote: 4. making use of asserts to provide information to the optimizer Do dmd/ldc/gdc actually do this? dmd doesn't. I don't know about other compilers. The point is it's possible because C++ doesn't have asserts. C++ has an assert macro, defined to be the same as in C. The definition of assert in C is such that it is turned on/off with the NDEBUG macro, meaning that when it is off, the compiler CANNOT derive any semantic information from it, because it effectively vanishes from the code. In contrast, assert in D is a keyword and has a semantic production. Even if generating code for the assert is disabled with the -release switch, the semantics of it remain and are available to the optimizer. C++ didn't repeat that mistake with 'static_assert' (another feature copied from D), but static assert doesn't help the optimizer. Just to be explicit about this: What kind of "help" do you want to be provided to the optimizer? I.e., why didn't you say: "Failing assertions are undefined behavior with the -release switch."
Re: Vision for the D language - stabilizing complexity?
On Monday, 11 July 2016 at 18:57:51 UTC, deadalnix wrote: Alright, but keep in mind that is an example, not the actual problem I'm talking about. There are many reasonable way to make the example above safe: disallow dereferencing pointers from unknown source, do a bound check on .ptr, disallow .ptr altogether and much more. The root problem is that "@safe guarantee memory safety and if it doesn't it is a bug" provides no information as to what is the bug here and no actionable items as to how to fix it, or even as to what needs fixing. Saw it on reddit: how rust manages safety bugs: https://www.reddit.com/r/programming/comments/4vto4r/inside_the_fastest_font_renderer_in_the_world/d61ltp8
Re: Vision for the D language - stabilizing complexity?
On Thursday, 21 July 2016 at 16:39:18 UTC, Andrew Godfrey wrote: You seem to be assuming that everyone already agrees on which set of changes should be made to the language. (Otherwise, how could you expect anyone to "officially back" a side project?) But agreeing on which changes to make and, especially, which to NOT make, is the hard part. And it's why you'd need a lot of planning & discussion up front (if any of us non-founders wanted to participate). And many people don't understand this, which IMO is behind a lot of hard feelings in the forums. The basic idea would be not to radically change the language, but come down to a clean core and build the existing useful concepts on top of that core. A year ago or so it was claimed that the compiler core would would be refactored and before that it was asked in the forum if current users would prefer non-breaking changes or a clean up. My impression was that the majority was willing to take some breaking changes in order to get a more streamlined experience. Anyway, it is summertime, maybe we can discuss this later in the autumn ;-). (I don't have time to follow the forums.)
Re: Vision for the D language - stabilizing complexity?
On Thursday, 21 July 2016 at 09:35:55 UTC, Kagamin wrote: You can lower D to Assembler and analyze that. Assembler is simple, isn't it? You can, and that is what C++ is mostly limited to, but you then you most likely get false positives and cannot use the analysis as part of the type-system. If you are going to use e.g. pointer analysis as part of the type system, then it has to happen at a higher level.
Re: Vision for the D language - stabilizing complexity?
On 07/18/2016 03:37 PM, Walter Bright via Digitalmars-d wrote: On 7/18/2016 6:48 AM, Andrew Godfrey wrote: We risk scaring away potential community members, and alienating existing ones, by the way we say "no" to proposals for breaking changes. We could improve how we say "no", by having a place to point people to. Potential topics: Anything we do will risk scaring away people. The only answer is we have to do what is right. 3) Why we feel that breaking changes risk killing D outright. (I just don't see it. I wonder if we're confusing "dfixable" breaking changes, with other more disruptive kinds (such as Tango=>Phobos).) Because if you thoroughly break a person's code, you put them in a position of rewriting it, and they may not choose to rewrite it in D3. They may choose a more stable language. I have many older programs in different languages. It's nice if they recompile and work. It's not nice if I have to go figure out how they work again so I can get them to work again. For some changes there could be switches, rather like optimization level switches, or those managed by version. This would allow the compilation version to be set based on a compile time variable, I'm not totally sure whether this should be file level or, as with version, block level...or selectable. This would get to be a huge maintenance chore after awhile, but it would allow you a few years to deprecate code. The question is "How important would a change need to be to justify this kind of action?", and my guess is that it would need to be pretty important.
Re: Vision for the D language - stabilizing complexity?
On Thursday, 21 July 2016 at 16:21:17 UTC, Andrew Godfrey wrote: You can lower D to Assembler and analyze that. Assembler is simple, isn't it? Are you trolling? Lowering discards information. AFAIK, that's what static analysis is built for: to infer high-level properties of the code that are not expressed in it.
Re: Vision for the D language - stabilizing complexity?
On Thursday, 21 July 2016 at 08:40:03 UTC, Ola Fosheim Grøstad wrote: On Saturday, 16 July 2016 at 13:09:22 UTC, Andrew Godfrey wrote: ideas that would require a major version change. The thing about that is that it can't be done incrementally; it's the rare kind of thing that would need to be planned long in advance, and would have to amount to a huge improvement to justify even considering it. It does not need to be planned long in advance, it only requires official backing as a side project. They could freeze current D2 as a stable release and also work on a cleanup. Instead you get people working on their own forks (myself included), or spin-off languages that goes nowhere. Because you need momentum. As a result neither D or the spin-offs gain momentum. And there are several spin-offs (some dead). You seem to be assuming that everyone already agrees on which set of changes should be made to the language. (Otherwise, how could you expect anyone to "officially back" a side project?) But agreeing on which changes to make and, especially, which to NOT make, is the hard part. And it's why you'd need a lot of planning & discussion up front (if any of us non-founders wanted to participate). And many people don't understand this, which IMO is behind a lot of hard feelings in the forums.
Re: Vision for the D language - stabilizing complexity?
On Thursday, 21 July 2016 at 09:35:55 UTC, Kagamin wrote: On Saturday, 16 July 2016 at 06:36:33 UTC, Ola Fosheim Grøstad wrote: Not sure what you mean. 1. It is more time consuming to write an analysis engine that can cover convoluted machinery than simple machinery. 2. It it more difficult to extend complex machinery than simple machinery. 3. It is more work to figure out adequate simple machinery to describe complex machinery, than just keeping things simple from the start. Not very surprising that experienced language designers try to keep the core language as simple as possible? You can lower D to Assembler and analyze that. Assembler is simple, isn't it? Are you trolling? Lowering discards information.
Re: Vision for the D language - stabilizing complexity?
On Saturday, 16 July 2016 at 06:36:33 UTC, Ola Fosheim Grøstad wrote: Not sure what you mean. 1. It is more time consuming to write an analysis engine that can cover convoluted machinery than simple machinery. 2. It it more difficult to extend complex machinery than simple machinery. 3. It is more work to figure out adequate simple machinery to describe complex machinery, than just keeping things simple from the start. Not very surprising that experienced language designers try to keep the core language as simple as possible? You can lower D to Assembler and analyze that. Assembler is simple, isn't it?
Re: Vision for the D language - stabilizing complexity?
On Saturday, 16 July 2016 at 13:09:22 UTC, Andrew Godfrey wrote: ideas that would require a major version change. The thing about that is that it can't be done incrementally; it's the rare kind of thing that would need to be planned long in advance, and would have to amount to a huge improvement to justify even considering it. It does not need to be planned long in advance, it only requires official backing as a side project. They could freeze current D2 as a stable release and also work on a cleanup. Instead you get people working on their own forks (myself included), or spin-off languages that goes nowhere. Because you need momentum. As a result neither D or the spin-offs gain momentum. And there are several spin-offs (some dead). In the meantime low level languages like C++, Rust and semi-high level languages like Swift cuts into the D feature set from both sides. C++ is clogged up by backwards-compatibility issues, but they are also smoothing out the rough edges where D once had clear advantages. Especially in the areas of convenience. C++14/C++17 are not very exciting in terms of features, but the additions are removing what people now seem to call «friction». In order to stay competitive over time you need something significantly better, like stronger typing, which depends on static analysis, which requires a simple identifiable core (not a simple language, but a simple core language after you remove syntactic sugar). One possible valuable addition would have been restricted refinement types, another is solid pointer analysis (without false positives). Neither are incompatible with D as such, but you would probably need to attract compiler developers with a theoretical background to get it up in reasonable time. Without a clean core they will conclude that the it will be too much work and they will go to other big languages instead or work on other alternative languages that also go nowhere because they lack momentum...
Re: Vision for the D language - stabilizing complexity?
That's an interesting outcome that backward compatibility matters for hobby users more than for commercial users :)
Re: Vision for the D language - stabilizing complexity?
On Wednesday, 20 July 2016 at 20:12:14 UTC, Jack Stouffer wrote: On Tuesday, 19 July 2016 at 15:22:19 UTC, Andrew Godfrey wrote: [...] Something being dfix-able is not enough for the simple reason that legacy code in D is already becoming a thing, despite D2 only existing for nine years. A complaint has arisen many times in the forum and in DConfs that there are many packages on code.dlang.org or on Github that don't compile because the author stopped maintaining them. In many cases, these repo's have only been unmaintained for a year(!) or less, and they already don't compile. [...] Thanks for the explanation. If most changes aren't dfixable (or aren't believed to be), that explains why the discussions I've read don't mention the dfix approach.
Re: Vision for the D language - stabilizing complexity?
On Tuesday, 19 July 2016 at 15:22:19 UTC, Andrew Godfrey wrote: Just like earlier in this thread, where I mentined dfixable breaking changes and Walter implied that even though a would cause people to have to manually rewrite. Something being dfix-able is not enough for the simple reason that legacy code in D is already becoming a thing, despite D2 only existing for nine years. A complaint has arisen many times in the forum and in DConfs that there are many packages on code.dlang.org or on Github that don't compile because the author stopped maintaining them. In many cases, these repo's have only been unmaintained for a year(!) or less, and they already don't compile. There's no way for anyone other than the original author that can fix this; all we can do is add a warning on code.dlang.org. All the while it reduces the signal to noise ratio of good to bad D code online. Every breakage needs to take into account the baggage of visible old code. There's also the point that there are few changes which can be dfix-able (according to its author).
Re: Vision for the D language - stabilizing complexity?
On Tuesday, 19 July 2016 at 09:49:50 UTC, Chris wrote: On Monday, 18 July 2016 at 18:03:49 UTC, Mathias Lang wrote: 2016-07-18 15:48 GMT+02:00 Andrew Godfrey via Digitalmars-d < digitalmars-d@puremagic.com>: I've never seen a definitive "No" to breaking changes. We do breaking changes all the time. Did everyone already forget what the latest release (2.071.0) was about ? Revamping the import system, one of the core component of the language. But it took a lot of time, and experience, to do it. It did deprecate patterns people were using for a long time before (e.g. inheriting imports), but its a (almost) consistent and principled implementation. Although it can be a PITA, people accept breaking changes, if they really make sense. Way too often I see suggestions for a change with one (or more) of the following mistakes: - Want to bring a specific construct in the language rather than achieve a goal - Only consider the pros of such a proposal and completely skip any cons analysis - Focus on one single change without considering how it could affect the whole language That's also my impression. Given that D is open source I'm surprised that nobody has grabbed it and come up with a prototype of D3 or whatever. How else could you prove your case? After all the onus of proof is on the one who proposes a change. Don't just sit and wait until Walter says "Go ahead", knowing full well that the core devs are in no position to dedicate time to D3 at the moment - that's too easy and it gets us nowhere. But I've never seen someone willing to put the effort in a proposal to improve the language be turned away. In fact, our review process for language change was recently updated as well to make it more accessible and save everyone's time. If it's not a commitment for continuous improvement of the language, I don't know what it is. We all seem to be in agreement that people often make breaking-change proposals without considering the impact properly. I have seen this many times on the forums and not once (so far) has the reply been simply, "please go and read the section of our vision doc that talks about breaking changes". I'm suggesting that is what should happen. Instead, I have seen each time a disussion thread that explores only parts of the topic of breaking changes, and does so badly. Just like earlier in this thread, where I mentined dfixable breaking changes and Walter implied that even though a would cause people to have to manually rewrite. (This example is a specific bias I have noticed in other threads: arguing about a breaking change without evaluating whether it is dfixable).
Re: Vision for the D language - stabilizing complexity?
On Monday, 18 July 2016 at 18:03:49 UTC, Mathias Lang wrote: 2016-07-18 15:48 GMT+02:00 Andrew Godfrey via Digitalmars-d < digitalmars-d@puremagic.com>: I've never seen a definitive "No" to breaking changes. We do breaking changes all the time. Did everyone already forget what the latest release (2.071.0) was about ? Revamping the import system, one of the core component of the language. But it took a lot of time, and experience, to do it. It did deprecate patterns people were using for a long time before (e.g. inheriting imports), but its a (almost) consistent and principled implementation. Although it can be a PITA, people accept breaking changes, if they really make sense. Way too often I see suggestions for a change with one (or more) of the following mistakes: - Want to bring a specific construct in the language rather than achieve a goal - Only consider the pros of such a proposal and completely skip any cons analysis - Focus on one single change without considering how it could affect the whole language That's also my impression. Given that D is open source I'm surprised that nobody has grabbed it and come up with a prototype of D3 or whatever. How else could you prove your case? After all the onus of proof is on the one who proposes a change. Don't just sit and wait until Walter says "Go ahead", knowing full well that the core devs are in no position to dedicate time to D3 at the moment - that's too easy and it gets us nowhere. But I've never seen someone willing to put the effort in a proposal to improve the language be turned away. In fact, our review process for language change was recently updated as well to make it more accessible and save everyone's time. If it's not a commitment for continuous improvement of the language, I don't know what it is.
Re: Vision for the D language - stabilizing complexity?
On 7/18/2016 5:06 AM, Kagamin wrote: On Saturday, 16 July 2016 at 21:52:02 UTC, Walter Bright wrote: I've seen SAL before, but have not studied it. My impression is it is much more complex than necessary. For example, https://msdn.microsoft.com/en-us/library/hh916383.aspx describes annotations to memcpy(). I believe these are better handled by use of dynamic arrays and transitive const. I suppose in case of memcpy the compiler can catch (at the caller side) the case when the destination buffer has insufficient size, while D can catch it only at runtime. It's a contract expressed with a simple grammar. Determining array bounds is the halting problem in the general case, and SAL doesn't solve that.
Re: Vision for the D language - stabilizing complexity?
On 7/18/2016 9:08 AM, Andrew Godfrey wrote: On Thursday, 14 July 2016 at 20:01:54 UTC, Walter Bright wrote: On 7/14/2016 11:49 AM, Steven Schveighoffer wrote: In C++, the compiler has to reload x, because it may have changed. That's right. I learned that the hard way, when the original optimizer would assume that x hadn't changed. It broke a surprising amount of code. It also means that the utility of const in C++ is extremely limited. Walter, I hope you were just in a rush. Because I think you meant to say, "the utility of const in C++ for *optimizing code* is extremely limited". No. I meant const's utility to provide checkable, reliable information about code. I'm a big believer in encapsulation, and const is a major tool for that. But C++ const just isn't very helpful.
Re: Vision for the D language - stabilizing complexity?
On 7/18/2016 6:48 AM, Andrew Godfrey wrote: We risk scaring away potential community members, and alienating existing ones, by the way we say "no" to proposals for breaking changes. We could improve how we say "no", by having a place to point people to. Potential topics: Anything we do will risk scaring away people. The only answer is we have to do what is right. 3) Why we feel that breaking changes risk killing D outright. (I just don't see it. I wonder if we're confusing "dfixable" breaking changes, with other more disruptive kinds (such as Tango=>Phobos).) Because if you thoroughly break a person's code, you put them in a position of rewriting it, and they may not choose to rewrite it in D3. They may choose a more stable language. I have many older programs in different languages. It's nice if they recompile and work. It's not nice if I have to go figure out how they work again so I can get them to work again.
Re: Vision for the D language - stabilizing complexity?
2016-07-18 15:48 GMT+02:00 Andrew Godfrey via Digitalmars-d < digitalmars-d@puremagic.com>: > > We risk scaring away potential community members, and alienating existing > ones, by the way we say "no" to proposals for breaking changes. We could > improve how we say "no", by having a place to point people to. Potential > topics: > [...] > I've never seen a definitive "No" to breaking changes. We do breaking changes all the time. Did everyone already forget what the latest release (2.071.0) was about ? Revamping the import system, one of the core component of the language. But it took a lot of time, and experience, to do it. It did deprecate patterns people were using for a long time before (e.g. inheriting imports), but its a (almost) consistent and principled implementation. Way too often I see suggestions for a change with one (or more) of the following mistakes: - Want to bring a specific construct in the language rather than achieve a goal - Only consider the pros of such a proposal and completely skip any cons analysis - Focus on one single change without considering how it could affect the whole language But I've never seen someone willing to put the effort in a proposal to improve the language be turned away. In fact, our review process for language change was recently updated as well to make it more accessible and save everyone's time. If it's not a commitment for continuous improvement of the language, I don't know what it is.
Re: Vision for the D language - stabilizing complexity?
On Thursday, 14 July 2016 at 20:01:54 UTC, Walter Bright wrote: On 7/14/2016 11:49 AM, Steven Schveighoffer wrote: In C++, the compiler has to reload x, because it may have changed. That's right. I learned that the hard way, when the original optimizer would assume that x hadn't changed. It broke a surprising amount of code. It also means that the utility of const in C++ is extremely limited. Walter, I hope you were just in a rush. Because I think you meant to say, "the utility of const in C++ for *optimizing code* is extremely limited". If you really think that the optimizer is the primary audience for language features, then ... well that would surprise me given D's design, which generally seems quite mindful of "humans are the primary audience". Though at times I do feel people use "auto" when they should state the type they expect (because then the compiler could help detect changes which break intent, that might otherwise compile just fine).
Re: Vision for the D language - stabilizing complexity?
On Monday, 18 July 2016 at 13:48:16 UTC, Andrew Godfrey wrote: 1) As you say, a vision for D3. Maybe just a summary of the things that are now agreed upon, e.g. autodecoding (though even there, I think the details of where to move to, are still contentious. E.g. I personally dislike the convention of "char" meaning a 1-byte data type but I think some others like it). 2) The case against incremental breaking changes. (I see this argument somewhat, though it applies less to "dfixable" breaking changes). 3) Why we feel that breaking changes risk killing D outright. (I just don't see it. I wonder if we're confusing "dfixable" breaking changes, with other more disruptive kinds (such as Tango=>Phobos).) I wasn't around for the D1 to D2 change, but I was around for Python 2 to Python 3, which was inconvenient. My sense is that a lot of the things mentioned here are "woulda-coulda-shoulda", like having defaults be @safe instead of @system. Would have been nice to have from the beginning, but just seems way too disruptive to change it now. However, I don't have any particular issue with incremental breaking changes that are dfixable. But I think that saving them all up to do a huge D3 is potentially more disruptive than doing a small D3, completely dfixable, then a small D4, etc. Even a D3 that just changed autodecoding (which I don't think is dixable, but who knows) would be good as it would be just a small limited breaking change.
Re: Vision for the D language - stabilizing complexity?
On Monday, 18 July 2016 at 09:45:39 UTC, Chris wrote: On Sunday, 17 July 2016 at 02:17:52 UTC, Andrew Godfrey wrote: On Saturday, 16 July 2016 at 21:35:41 UTC, Walter Bright wrote: On 7/16/2016 6:09 AM, Andrew Godfrey wrote: Walter called Prolog "singularly useless". You have been referring to changes that would amount to a new major version of D as "a cleanup". From the forums, my sense is that there IS a groundswell of opinion, that D2 has some major mistakes in it that can't be rectified without doing a D3, and there's a strong reaction to that idea based on experience with D1 -> D2. Perhaps what is needed is a separate area for discussion about ideas that would require a major version change. The thing about that is that it can't be done incrementally; it's the rare kind of thing that would need to be planned long in advance, and would have to amount to a huge improvement to justify even considering it. I agree that D2 has made some fundamental mistakes. But it also got a great deal right. I haven't banned Ola from the forums, he has done nothing to deserve that. He's welcome to post here, and others are welcome to engage him. I'm more interested in engaging on "in how many years will the D leadership be interested in engaging on the topic of D3?" I feel this is a significant omission from the vision doc, and that omission inflames a lot of the recurring animosity I see on the forums. Even an answer of "never" would be a significant improvement over "we refuse to engage on that". And I doubt you're really thinking "never". I do think that ideas from academia will mostly cause a lot of unwanted noise in such a discussion - because academia, in my experience, is more focused on "software construction" than on "software evolution", and D takes an approach that is built on practical experience with evolution. But academia also has occasional nuggets of extreme value. The question is what is D3 supposed to be? I'm neither for nor against D3, it pops up every once in a while when people are not happy with a feature. My questions are: 1. Is there any clear vision of what D3 should look like? 2. What exactly will it fix? 3. Is there a prototype (in progress) to actually prove it will fix those things? 4. If there is (real) proof[1], would it justify a break with D2 and risk D's death? I think this topic is too serious to be just throwing in (partly academic) ideas that might or might not work in the real world. It's too serious to use D as a playground and later say "Ah well, it didn't work. [shrug]". D has left the playground and can no longer afford to just play around with ideas randomly. One has to be realistic. I'd also like to add that if we had a "clean and compact" D3, it would become more complex over time and people would want D4 to solve this, then D5 and so forth. I haven't seen any software yet that hasn't become more complex over time. Last but not least, it would help to make a list of the things D2 got right to put the whole D3 issue into proportion. [1] I.e. let's not refer to other languages in an eclectic manner. I'm asking for a proof that D works as D3 and is superior to D2. We risk scaring away potential community members, and alienating existing ones, by the way we say "no" to proposals for breaking changes. We could improve how we say "no", by having a place to point people to. Potential topics: 1) As you say, a vision for D3. Maybe just a summary of the things that are now agreed upon, e.g. autodecoding (though even there, I think the details of where to move to, are still contentious. E.g. I personally dislike the convention of "char" meaning a 1-byte data type but I think some others like it). 2) The case against incremental breaking changes. (I see this argument somewhat, though it applies less to "dfixable" breaking changes). 3) Why we feel that breaking changes risk killing D outright. (I just don't see it. I wonder if we're confusing "dfixable" breaking changes, with other more disruptive kinds (such as Tango=>Phobos).)
Re: Vision for the D language - stabilizing complexity?
On Sunday, 17 July 2016 at 02:59:42 UTC, Nobody wrote: Perl 6. Inequality operator :)
Re: Vision for the D language - stabilizing complexity?
On Saturday, 16 July 2016 at 21:52:02 UTC, Walter Bright wrote: I've seen SAL before, but have not studied it. My impression is it is much more complex than necessary. For example, https://msdn.microsoft.com/en-us/library/hh916383.aspx describes annotations to memcpy(). I believe these are better handled by use of dynamic arrays and transitive const. I suppose in case of memcpy the compiler can catch (at the caller side) the case when the destination buffer has insufficient size, while D can catch it only at runtime. It's a contract expressed with a simple grammar.
Re: Vision for the D language - stabilizing complexity?
On Monday, 18 July 2016 at 11:05:34 UTC, Bill Hicks wrote: On Sunday, 17 July 2016 at 05:50:31 UTC, H. S. Teoh wrote: On Sun, Jul 17, 2016 at 02:59:42AM +, Nobody via Digitalmars-d wrote: Perl 6. Are you serious? Perl is the *prime* example of "unprincipled and complex". Larry Wall himself said (in print, no less): English is useful because it is a mess. Since English is a mess, it maps well onto the problem space, which is also a mess, which we call reality. Similarly, Perl was designed to be a mess, though in the nicest of all possible ways. -- Larry Wall T 1. Perl 6 is not Perl. 2. Perl 6 is better designed language than D will ever be. 3. Perl 6 is complex, but not complicated. I think people sometimes confuse the two. 4. D is a failed language, regardless of how people choose to categorize its attributes. There are some interesting discussions about Perl 6[1][2]. They remind me of the discussions about D. Apart from some irrational points (the logo!), the fact that it took 15 years figures prominently - and people complain about its features that were so carefully designed. I don't know Perl 6 and cannot comment on the validity of that criticism. [1] http://blogs.perl.org/users/zoffix_znet/2016/01/why-in-the-world-would-anyone-use-perl-6.html [2] https://www.quora.com/Why-is-Perl-6-considered-to-be-a-disaster
Re: Vision for the D language - stabilizing complexity?
On Sunday, 17 July 2016 at 05:50:31 UTC, H. S. Teoh wrote: On Sun, Jul 17, 2016 at 02:59:42AM +, Nobody via Digitalmars-d wrote: Perl 6. Are you serious? Perl is the *prime* example of "unprincipled and complex". Larry Wall himself said (in print, no less): English is useful because it is a mess. Since English is a mess, it maps well onto the problem space, which is also a mess, which we call reality. Similarly, Perl was designed to be a mess, though in the nicest of all possible ways. -- Larry Wall T 1. Perl 6 is not Perl. 2. Perl 6 is better designed language than D will ever be. 3. Perl 6 is complex, but not complicated. I think people sometimes confuse the two. 4. D is a failed language, regardless of how people choose to categorize its attributes.
Re: Vision for the D language - stabilizing complexity?
On Sunday, 17 July 2016 at 02:17:52 UTC, Andrew Godfrey wrote: On Saturday, 16 July 2016 at 21:35:41 UTC, Walter Bright wrote: On 7/16/2016 6:09 AM, Andrew Godfrey wrote: Walter called Prolog "singularly useless". You have been referring to changes that would amount to a new major version of D as "a cleanup". From the forums, my sense is that there IS a groundswell of opinion, that D2 has some major mistakes in it that can't be rectified without doing a D3, and there's a strong reaction to that idea based on experience with D1 -> D2. Perhaps what is needed is a separate area for discussion about ideas that would require a major version change. The thing about that is that it can't be done incrementally; it's the rare kind of thing that would need to be planned long in advance, and would have to amount to a huge improvement to justify even considering it. I agree that D2 has made some fundamental mistakes. But it also got a great deal right. I haven't banned Ola from the forums, he has done nothing to deserve that. He's welcome to post here, and others are welcome to engage him. I'm more interested in engaging on "in how many years will the D leadership be interested in engaging on the topic of D3?" I feel this is a significant omission from the vision doc, and that omission inflames a lot of the recurring animosity I see on the forums. Even an answer of "never" would be a significant improvement over "we refuse to engage on that". And I doubt you're really thinking "never". I do think that ideas from academia will mostly cause a lot of unwanted noise in such a discussion - because academia, in my experience, is more focused on "software construction" than on "software evolution", and D takes an approach that is built on practical experience with evolution. But academia also has occasional nuggets of extreme value. The question is what is D3 supposed to be? I'm neither for nor against D3, it pops up every once in a while when people are not happy with a feature. My questions are: 1. Is there any clear vision of what D3 should look like? 2. What exactly will it fix? 3. Is there a prototype (in progress) to actually prove it will fix those things? 4. If there is (real) proof[1], would it justify a break with D2 and risk D's death? I think this topic is too serious to be just throwing in (partly academic) ideas that might or might not work in the real world. It's too serious to use D as a playground and later say "Ah well, it didn't work. [shrug]". D has left the playground and can no longer afford to just play around with ideas randomly. One has to be realistic. I'd also like to add that if we had a "clean and compact" D3, it would become more complex over time and people would want D4 to solve this, then D5 and so forth. I haven't seen any software yet that hasn't become more complex over time. Last but not least, it would help to make a list of the things D2 got right to put the whole D3 issue into proportion. [1] I.e. let's not refer to other languages in an eclectic manner. I'm asking for a proof that D works as D3 and is superior to D2.
Re: Vision for the D language - stabilizing complexity?
On Sunday, 17 July 2016 at 12:38:46 UTC, Andrei Alexandrescu wrote: On 7/15/16 10:43 AM, Andrew Godfrey wrote: On Friday, 15 July 2016 at 11:09:24 UTC, Patrick Schluter wrote: On Friday, 15 July 2016 at 10:25:16 UTC, Shachar Shemesh wrote: I think the one that hurts the most is fixing "C++ fault" #3. It means there are many scenarios in which I could put const in C++, and I simply can't in D, because something somewhere needs to be mutable. Then it is not const and marking it as const is a bug. D enforces to not write a bug, what's wrong with that? One example is if you make a class that has an internal cache of something. Updating or invalidating that cache has no logical effect on the externally-observable state of the class. So you should be able to modify the cache even on a 'const' object. This is not a bug and I've seen it have a huge effect on performance - probably a lot more than the const optimizations Walter is talking about here. I suggest you take a look at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2669.htm. It adds guarantees for STL containers that effectively prohibit them from using mutable. If they do use mutable, they are on their own in ensuring correctness. Also, although arguably all types should behave that way, there is no way to express something near "this user-defined type satisfies N2669" within the C++ type system. Also, N2669 encodes existing practice; the whole logical const and surreptitious caches inside apparently const objects is liable to bring more problems than it solves (see e.g. the std::string reference counting fiasco). -- Andrei It's certainly true that if I see "mutable" used in code, it catches my attention and engages my extreme skepticism. It is very hard to get right. Yet, in the handful of cases I've ever seen it used, the people who used it generally knew what they were doing and did get it right. And banning mutable in those situations would have caused a cascade of non-const reaching far up into the system, where it wasn't wanted and would remove important protections. I read N2669 and it doesn't "effectively prohibit" mutable as far as I can see. It does mean that to use any mutable state you'd need protection, such as locks, or lockfree trickery. Generally, I suspect that the only allowable externally-observable effect of using "mutable" is improved performance. But perhaps there is some other valid use that I just haven't encountered.
Re: Vision for the D language - stabilizing complexity?
On 2016-07-17 05:35, Andrew Godfrey wrote: No it's not the same - void initialization leaves the variable uninitialized. I'm saying, something that still initialized, but marks that initial value as not to be used. Anyway... given the existence of void initialization (which I'd forgotten about), what I suggested would be very confusing to add. I think annotating a variable with a UDA would be perfect for this. The static analyzer would recognize the UDA and do the proper analyzes. -- /Jacob Carlborg
Re: Vision for the D language - stabilizing complexity?
On 7/15/16 10:43 AM, Andrew Godfrey wrote: On Friday, 15 July 2016 at 11:09:24 UTC, Patrick Schluter wrote: On Friday, 15 July 2016 at 10:25:16 UTC, Shachar Shemesh wrote: I think the one that hurts the most is fixing "C++ fault" #3. It means there are many scenarios in which I could put const in C++, and I simply can't in D, because something somewhere needs to be mutable. Then it is not const and marking it as const is a bug. D enforces to not write a bug, what's wrong with that? One example is if you make a class that has an internal cache of something. Updating or invalidating that cache has no logical effect on the externally-observable state of the class. So you should be able to modify the cache even on a 'const' object. This is not a bug and I've seen it have a huge effect on performance - probably a lot more than the const optimizations Walter is talking about here. I suggest you take a look at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2669.htm. It adds guarantees for STL containers that effectively prohibit them from using mutable. If they do use mutable, they are on their own in ensuring correctness. Also, although arguably all types should behave that way, there is no way to express something near "this user-defined type satisfies N2669" within the C++ type system. Also, N2669 encodes existing practice; the whole logical const and surreptitious caches inside apparently const objects is liable to bring more problems than it solves (see e.g. the std::string reference counting fiasco). -- Andrei
Re: Vision for the D language - stabilizing complexity?
On Sun, Jul 17, 2016 at 02:59:42AM +, Nobody via Digitalmars-d wrote: > On Saturday, 9 July 2016 at 00:14:34 UTC, Walter Bright wrote: > > On 7/8/2016 2:58 PM, Ola Fosheim Grøstad wrote: > > > On Friday, 8 July 2016 at 21:24:04 UTC, Walter Bright wrote: > > > > On 7/7/2016 5:56 PM, deadalnix wrote: > > > > > While this very true, it is clear that most D's complexity > > > > > doesn't come from there. D's complexity come for the most part > > > > > from things being completely unprincipled and lack of vision. > > > > > > > > All useful computer languages are unprincipled and complex due > > > > to a number of factors: > > > > > > I think this is a very dangerous assumption. And also not true. > > > > Feel free to post a counterexample. All you need is one! > > > > Perl 6. Are you serious? Perl is the *prime* example of "unprincipled and complex". Larry Wall himself said (in print, no less): English is useful because it is a mess. Since English is a mess, it maps well onto the problem space, which is also a mess, which we call reality. Similarly, Perl was designed to be a mess, though in the nicest of all possible ways. -- Larry Wall T -- Being able to learn is a great learning; being able to unlearn is a greater learning.
Re: Vision for the D language - stabilizing complexity?
On Sunday, 17 July 2016 at 05:14:57 UTC, Walter Bright wrote: On 7/16/2016 7:17 PM, Andrew Godfrey wrote: I'm more interested in engaging on "in how many years will the D leadership be interested in engaging on the topic of D3?" I feel this is a significant omission from the vision doc, and that omission inflames a lot of the recurring animosity I see on the forums. Even an answer of "never" would be a significant improvement over "we refuse to engage on that". And I doubt you're really thinking "never". There are no plans for D3 at the moment. All plans for improvement are backwards compatible as much as possible. D had its wrenching change with D1->D2, and it nearly destroyed us. I think alienating the Tango crowd did way more in that reguard than any breaking change could.
Re: Vision for the D language - stabilizing complexity?
On 7/16/2016 7:17 PM, Andrew Godfrey wrote: I'm more interested in engaging on "in how many years will the D leadership be interested in engaging on the topic of D3?" I feel this is a significant omission from the vision doc, and that omission inflames a lot of the recurring animosity I see on the forums. Even an answer of "never" would be a significant improvement over "we refuse to engage on that". And I doubt you're really thinking "never". There are no plans for D3 at the moment. All plans for improvement are backwards compatible as much as possible. D had its wrenching change with D1->D2, and it nearly destroyed us. I do think that ideas from academia will mostly cause a lot of unwanted noise in such a discussion - because academia, in my experience, is more focused on "software construction" than on "software evolution", and D takes an approach that is built on practical experience with evolution. But academia also has occasional nuggets of extreme value. Academia certainly does have value for us. Andrei has a PhD in computer science, I have a BS in mechanical and aerospace engineering, and I believe the difference in our backgrounds makes for great complementary skills.
Re: Vision for the D language - stabilizing complexity?
On Sunday, 17 July 2016 at 02:07:19 UTC, pineapple wrote: On Sunday, 17 July 2016 at 02:03:52 UTC, Andrew Godfrey wrote: 2) I wonder if an "uninitialized" feature would be worthwhile. That is, a value you can initialize a variable to, equal to 'init', but that static analyzers know you don't mean to ever use. Don't we already have this in the form of int uninitialized_value = void; ? No it's not the same - void initialization leaves the variable uninitialized. I'm saying, something that still initialized, but marks that initial value as not to be used. Anyway... given the existence of void initialization (which I'd forgotten about), what I suggested would be very confusing to add.
Re: Vision for the D language - stabilizing complexity?
On Saturday, 9 July 2016 at 00:14:34 UTC, Walter Bright wrote: On 7/8/2016 2:58 PM, Ola Fosheim Grøstad wrote: On Friday, 8 July 2016 at 21:24:04 UTC, Walter Bright wrote: On 7/7/2016 5:56 PM, deadalnix wrote: While this very true, it is clear that most D's complexity doesn't come from there. D's complexity come for the most part from things being completely unprincipled and lack of vision. All useful computer languages are unprincipled and complex due to a number of factors: I think this is a very dangerous assumption. And also not true. Feel free to post a counterexample. All you need is one! Perl 6.
Re: Vision for the D language - stabilizing complexity?
On Saturday, 16 July 2016 at 21:35:41 UTC, Walter Bright wrote: On 7/16/2016 6:09 AM, Andrew Godfrey wrote: Walter called Prolog "singularly useless". You have been referring to changes that would amount to a new major version of D as "a cleanup". From the forums, my sense is that there IS a groundswell of opinion, that D2 has some major mistakes in it that can't be rectified without doing a D3, and there's a strong reaction to that idea based on experience with D1 -> D2. Perhaps what is needed is a separate area for discussion about ideas that would require a major version change. The thing about that is that it can't be done incrementally; it's the rare kind of thing that would need to be planned long in advance, and would have to amount to a huge improvement to justify even considering it. I agree that D2 has made some fundamental mistakes. But it also got a great deal right. I haven't banned Ola from the forums, he has done nothing to deserve that. He's welcome to post here, and others are welcome to engage him. I'm more interested in engaging on "in how many years will the D leadership be interested in engaging on the topic of D3?" I feel this is a significant omission from the vision doc, and that omission inflames a lot of the recurring animosity I see on the forums. Even an answer of "never" would be a significant improvement over "we refuse to engage on that". And I doubt you're really thinking "never". I do think that ideas from academia will mostly cause a lot of unwanted noise in such a discussion - because academia, in my experience, is more focused on "software construction" than on "software evolution", and D takes an approach that is built on practical experience with evolution. But academia also has occasional nuggets of extreme value.
Re: Vision for the D language - stabilizing complexity?
On 7/16/2016 7:03 PM, Andrew Godfrey wrote: I'm thinking: 1) Static analysis tools still have relevance even in D code. I agree, but their utility is greatly reduced, meaning the payback for the effort makes for a small benefit/cost ratio. 2) I wonder if an "uninitialized" feature would be worthwhile. That is, a value you can initialize a variable to, equal to 'init', but that static analyzers know you don't mean to ever use. There is the `= void;` initialization. A static analyzer could flag any attempts to use a void initialized variable/field that is live.
Re: Vision for the D language - stabilizing complexity?
On Sunday, 17 July 2016 at 02:03:52 UTC, Andrew Godfrey wrote: 2) I wonder if an "uninitialized" feature would be worthwhile. That is, a value you can initialize a variable to, equal to 'init', but that static analyzers know you don't mean to ever use. Don't we already have this in the form of int uninitialized_value = void; ?
Re: Vision for the D language - stabilizing complexity?
On Saturday, 16 July 2016 at 21:52:02 UTC, Walter Bright wrote: On 7/16/2016 5:32 AM, Andrew Godfrey wrote: [...] Thanks for taking the time to post about your experience with it. Comparing D with SAL is a worthwhile exercise. [...] I've seen SAL before, but have not studied it. My impression is it is much more complex than necessary. For example, https://msdn.microsoft.com/en-us/library/hh916383.aspx describes annotations to memcpy(). I believe these are better handled by use of dynamic arrays and transitive const. But there's no doubt that careful use of SAL will reduce bugs. [...] Uninitialized variables, along with their cousin adding a field to a struct and forgetting to initialize it in one of its constructors, have caused me endless problems and cost me untold hours. It was a major motivator to solve this problem in D, and I am pleased that my problems with it have been essentially eliminated. You write that SAL still leaves undetected cases of uninitialized variables. I think I'd rather live with the limitation you mentioned in the D way rather than risk uninitialized variables. Having a predictable wrong value in a variable is debuggable, having an unpredictable wrong value is often not debuggable, which is why they consume so much time. I'm not trying to argue against D's design here. I'm thinking: 1) Static analysis tools still have relevance even in D code. 2) I wonder if an "uninitialized" feature would be worthwhile. That is, a value you can initialize a variable to, equal to 'init', but that static analyzers know you don't mean to ever use.
Re: Vision for the D language - stabilizing complexity?
On 7/16/2016 5:32 AM, Andrew Godfrey wrote: On Saturday, 16 July 2016 at 06:40:31 UTC, Walter Bright wrote: But in C++, everything is @system. I'm not sure how people successfully create enormous programs with it. I work on Microsoft Word. I'm not sure how much I can share about internal verification tools, but I can say: We do have SAL annotation: https://msdn.microsoft.com/en-us/library/ms235402.aspx Thanks for taking the time to post about your experience with it. Comparing D with SAL is a worthwhile exercise. As solutions go, SAL is dissatisfyingly incomplete, and not an easy mini-language to learn (I still haven't managed it, I look up what I need on the occasions that I need it). But it does impress at times with what it can catch. It goes a bit beyond memory safety, too, so I would guess that there are bug patterns it can catch that D currently won't. I've seen SAL before, but have not studied it. My impression is it is much more complex than necessary. For example, https://msdn.microsoft.com/en-us/library/hh916383.aspx describes annotations to memcpy(). I believe these are better handled by use of dynamic arrays and transitive const. But there's no doubt that careful use of SAL will reduce bugs. One class of bug I find interesting here is uninitialized variables. I'm not sure if Visual Studio helps here (we have an internal tool, I know some 3rd party tools do this too). But it's interesting that these tools can (often, not always) spot code paths where a variable doesn't get initialized. D's approach to this helps strongly to avoid using uninitialized memory, but in so doing, it discards the information these tools are using to spot such bugs. (So, the kind of bug D lets slip through here would tend to be one where variable foo's value is foo.init but it should have been initialized to some other value). Uninitialized variables, along with their cousin adding a field to a struct and forgetting to initialize it in one of its constructors, have caused me endless problems and cost me untold hours. It was a major motivator to solve this problem in D, and I am pleased that my problems with it have been essentially eliminated. You write that SAL still leaves undetected cases of uninitialized variables. I think I'd rather live with the limitation you mentioned in the D way rather than risk uninitialized variables. Having a predictable wrong value in a variable is debuggable, having an unpredictable wrong value is often not debuggable, which is why they consume so much time.
Re: Vision for the D language - stabilizing complexity?
On 7/16/2016 6:09 AM, Andrew Godfrey wrote: Walter called Prolog "singularly useless". You have been referring to changes that would amount to a new major version of D as "a cleanup". From the forums, my sense is that there IS a groundswell of opinion, that D2 has some major mistakes in it that can't be rectified without doing a D3, and there's a strong reaction to that idea based on experience with D1 -> D2. Perhaps what is needed is a separate area for discussion about ideas that would require a major version change. The thing about that is that it can't be done incrementally; it's the rare kind of thing that would need to be planned long in advance, and would have to amount to a huge improvement to justify even considering it. I agree that D2 has made some fundamental mistakes. But it also got a great deal right. I haven't banned Ola from the forums, he has done nothing to deserve that. He's welcome to post here, and others are welcome to engage him.
Re: Vision for the D language - stabilizing complexity?
On Saturday, 16 July 2016 at 07:14:03 UTC, Ola Fosheim Grøstad wrote: On Thursday, 14 July 2016 at 23:38:17 UTC, Walter Bright wrote: On 7/14/2016 6:26 AM, Chris wrote: Now, now. Where's your sense of humor? The thing is, he's just here to troll us. His posts all follow the same pattern of relentlessly finding nothing good whatsoever in D, and we're all idiots. Whoah, that's sensitive. Never called anyone an idiot, but D zealots seem to have a very low threshold for calling everyone else with a little bit of experience idiots if they see room for change in the language. The excesses of broken argumentation in this newsgroup is keeping change from coming to the language. It is apparent by now that you and Andrei quite often produce smog screens to cover your trails of broken argument chains, which only serve to defend status quo and not really lead to the language to a competitive position. And no, you are not right just because you declare it, and no if you loose an argument it is not because someone changed the topic. The sad part about D is that it could've become a major player, but is very unlikely to become one without outside help and less hostile attitude towards rather basic CS. But outside help is not really wanted. Because apparently D can become a major player by 2020 without a cleanup according to you and Andrei. It is highly unlikely for D to become a major player without language cleanup and opening more up to outside input. I didn't see anyone call you an idiot either. You and Walter have both gone too far, probably because you're annoyed at each other's words and attitude: Walter called Prolog "singularly useless". You have been referring to changes that would amount to a new major version of D as "a cleanup". From the forums, my sense is that there IS a groundswell of opinion, that D2 has some major mistakes in it that can't be rectified without doing a D3, and there's a strong reaction to that idea based on experience with D1 -> D2. Perhaps what is needed is a separate area for discussion about ideas that would require a major version change. The thing about that is that it can't be done incrementally; it's the rare kind of thing that would need to be planned long in advance, and would have to amount to a huge improvement to justify even considering it.
Re: Vision for the D language - stabilizing complexity?
On Saturday, 16 July 2016 at 06:40:31 UTC, Walter Bright wrote: But in C++, everything is @system. I'm not sure how people successfully create enormous programs with it. I work on Microsoft Word. I'm not sure how much I can share about internal verification tools, but I can say: We do have SAL annotation: https://msdn.microsoft.com/en-us/library/ms235402.aspx As solutions go, SAL is dissatisfyingly incomplete, and not an easy mini-language to learn (I still haven't managed it, I look up what I need on the occasions that I need it). But it does impress at times with what it can catch. It goes a bit beyond memory safety, too, so I would guess that there are bug patterns it can catch that D currently won't. One class of bug I find interesting here is uninitialized variables. I'm not sure if Visual Studio helps here (we have an internal tool, I know some 3rd party tools do this too). But it's interesting that these tools can (often, not always) spot code paths where a variable doesn't get initialized. D's approach to this helps strongly to avoid using uninitialized memory, but in so doing, it discards the information these tools are using to spot such bugs. (So, the kind of bug D lets slip through here would tend to be one where variable foo's value is foo.init but it should have been initialized to some other value).
Re: Vision for the D language - stabilizing complexity?
On Thursday, 14 July 2016 at 23:38:17 UTC, Walter Bright wrote: On 7/14/2016 6:26 AM, Chris wrote: Now, now. Where's your sense of humor? The thing is, he's just here to troll us. His posts all follow the same pattern of relentlessly finding nothing good whatsoever in D, and we're all idiots. Whoah, that's sensitive. Never called anyone an idiot, but D zealots seem to have a very low threshold for calling everyone else with a little bit of experience idiots if they see room for change in the language. The excesses of broken argumentation in this newsgroup is keeping change from coming to the language. It is apparent by now that you and Andrei quite often produce smog screens to cover your trails of broken argument chains, which only serve to defend status quo and not really lead to the language to a competitive position. And no, you are not right just because you declare it, and no if you loose an argument it is not because someone changed the topic. The sad part about D is that it could've become a major player, but is very unlikely to become one without outside help and less hostile attitude towards rather basic CS. But outside help is not really wanted. Because apparently D can become a major player by 2020 without a cleanup according to you and Andrei. It is highly unlikely for D to become a major player without language cleanup and opening more up to outside input.
Re: Vision for the D language - stabilizing complexity?
On 7/15/2016 11:28 PM, Shachar Shemesh wrote: First of all, it sounds like you envision that everyone will solely be using the D supplied allocators, and no one will be writing their own. There won't be anything stopping anyone from writing their own allocators, just like there's nothing stopping one from writing their own sine and cosine functions. I'm well aware that systems programmers like to write their own allocators. But even if this turns out to be an adequate replacement for all the cases in which I'd want to use intrusive reference counting in C++ (unlikely), that only works for my first example, not my second one. You mean move semantics? You can't move anything if there are existing pointers to it that can't be changed automatically.
Re: Vision for the D language - stabilizing complexity?
On 7/15/2016 11:12 PM, Shachar Shemesh wrote: So, would you say you shouldn't use D unless all of your code is @safe? Most? Some? None? The idea is to minimize the use of @system. If you've got a large team and large codebase, the use of @system should merit special attention in code reviews, and should be in the purview of the more experienced programmers. There's way too much @system in Phobos, and I expect most of it can be scrubbed out.
Re: Vision for the D language - stabilizing complexity?
On 7/15/2016 11:04 PM, Andrew Godfrey wrote: Ok. Well, when you and Shachar were arguing, it still doesn't seem like Shachar was talking about @safe code specifically. I can't wrap my mind around wanting a "logical const" feature usable in @safe context; you could already use @system for those cases. @system provides a way around the type system, and offers fewer guarantees, sort of "use at your own risk". But use of @system is checkable, and when used properly only a small percentage of the code should be in @system functions. But in C++, everything is @system. I'm not sure how people successfully create enormous programs with it. I do know that the makers of add-on checkers like Coverty make bank. I once told a Coverity salesman that the purpose of D was to put Coverity (and its competitors) out of business :-) I saw him again a couple years later and he remembered me and that line!
Re: Vision for the D language - stabilizing complexity?
On Friday, 15 July 2016 at 09:29:27 UTC, Kagamin wrote: On Thursday, 14 July 2016 at 20:12:13 UTC, Ola Fosheim Grøstad wrote: And please note that this horrible excuse is propagate in the C++ community too. Time and time again people claim that C++ is complex, but it has to be like that in order to provide the features it provides. Not true for C++. Not true for D. Your suggestion for static analysis goes the same way: static analysis is way more complex than D currently is, but you suggest it must be this complex? Not sure what you mean. 1. It is more time consuming to write an analysis engine that can cover convoluted machinery than simple machinery. 2. It it more difficult to extend complex machinery than simple machinery. 3. It is more work to figure out adequate simple machinery to describe complex machinery, than just keeping things simple from the start. Not very surprising that experienced language designers try to keep the core language as simple as possible?
Re: Vision for the D language - stabilizing complexity?
On 16/07/16 02:04, Walter Bright wrote: On 7/15/2016 1:58 PM, Shachar Shemesh wrote: Do enlighten me how to use intrusive reference counting in D. I am quite interested in the answer. Andrei and I are working on it. As he's expressed elsewhere, the idea is to maintain the reference count in memory that is outside the type system. It's meant to work hand-in-glove with the storage allocator. First of all, it sounds like you envision that everyone will solely be using the D supplied allocators, and no one will be writing their own. That's not my vision of how a system programming language is used. In fact, I have seen very few large scale projects where a custom allocator was not used. Either way, prefixing data to a structure is not what "intrusive" means. But even if this turns out to be an adequate replacement for all the cases in which I'd want to use intrusive reference counting in C++ (unlikely), that only works for my first example, not my second one. Shachar
Re: Vision for the D language - stabilizing complexity?
On 16/07/16 07:24, Walter Bright wrote: Since casting away immutable/const is allowed in @system code, yes, I am referring to @safe code here. That is something without which none of your arguments made sense to me. Thank you for your clarification. So, would you say you shouldn't use D unless all of your code is @safe? Most? Some? None? Shachar
Re: Vision for the D language - stabilizing complexity?
On Saturday, 16 July 2016 at 04:24:39 UTC, Walter Bright wrote: On 7/15/2016 8:25 PM, Andrew Godfrey wrote: I agree and I like mechanically checkable things. But I also like compiler features that mix mechanical checking with the ability to attest to something that can't be mechanically checked. Like the @system attribute. So this line of reasoning feels incomplete to me. Are we talking here about immutable/const only within the context of @safe code? If so, then I missed that but I get it. Since casting away immutable/const is allowed in @system code, yes, I am referring to @safe code here. Ok. Well, when you and Shachar were arguing, it still doesn't seem like Shachar was talking about @safe code specifically. I can't wrap my mind around wanting a "logical const" feature usable in @safe context; you could already use @system for those cases.
Re: Vision for the D language - stabilizing complexity?
On 7/15/2016 8:25 PM, Andrew Godfrey wrote: I agree and I like mechanically checkable things. But I also like compiler features that mix mechanical checking with the ability to attest to something that can't be mechanically checked. Like the @system attribute. So this line of reasoning feels incomplete to me. Are we talking here about immutable/const only within the context of @safe code? If so, then I missed that but I get it. Since casting away immutable/const is allowed in @system code, yes, I am referring to @safe code here.
Re: Vision for the D language - stabilizing complexity?
On Friday, 15 July 2016 at 23:00:45 UTC, Walter Bright wrote: On 7/15/2016 1:48 PM, Shachar Shemesh wrote: On 15/07/16 22:50, Walter Bright wrote: You can do logical const in D just like in C++, and get those performance gains. You just can't call it "const". But you can call it /*logical_const*/ and get the same result. No, you can't. The fact that the compiler enforces the no const to mutable transition (unless you use a cast) The compiler does next to nothing - the maintainer can stick in 'mutable' members, and there's no reliable way to detect that. The maintainer can stick in const removing casts, and there's no reliable way to detect that, either. If it's not mechanically checkable, it is not reliable, and is what I call "faith-based programming." is one of the main appeals of using const in any language. If you call something "logical const", but the compiler does not help you to catch bugs, then I don't see the point. I agree, and the C++ compiler is unable to verify "logical const". It's entirely based on faith. In effect, if logical const is what you want, C++ gives you a tool while D leaves you to your own devices. As a result, a lot of places you'd define as const in C++ are defined mutable in D, losing language expressiveness. You and I certainly have polar opposite opinions on that. C++ does not have a notion of "logical const" (it is not in the C++ Standard). It's an uncheckable convention, might as well just use /*logical const*/. D, on the other hand, has verifiable const and verifiable purity. D's const/immutable feature is powerful and I love it. I would not trade it for C++'s version of const. It also seems fair to say that const as C++ implements it, would not be worth adding to D even if having two very similar features wasn't confusing. After all, every feature starts with a negative score. This subthread took it too far, that's the only reason I waded in. C++'s const feature is not entirely useless. Similarly: If it's not mechanically checkable, it is not reliable, I agree and I like mechanically checkable things. But I also like compiler features that mix mechanical checking with the ability to attest to something that can't be mechanically checked. Like the @system attribute. So this line of reasoning feels incomplete to me. Are we talking here about immutable/const only within the context of @safe code? If so, then I missed that but I get it. Otherwise, I don't get it.
Re: Vision for the D language - stabilizing complexity?
On 7/15/2016 1:58 PM, Shachar Shemesh wrote: Do enlighten me how to use intrusive reference counting in D. I am quite interested in the answer. Andrei and I are working on it. As he's expressed elsewhere, the idea is to maintain the reference count in memory that is outside the type system. It's meant to work hand-in-glove with the storage allocator.
Re: Vision for the D language - stabilizing complexity?
On 7/15/2016 1:58 PM, Shachar Shemesh wrote: I think your argument there is completely destroyed :-) I do not understand the joy both you and Andrei express when you think you have "won" an "argument". This gives me the feeling that I'm not part of a process designed to make the language better, but rather part of an argument meant to prove to me that the language is fine the way it is. Not a great feeling, and not something that fosters confidence in the language's future direction. It's just a gentle ribbing, as evidenced by the :-) Please don't read more into it than that, as none is intended.
Re: Vision for the D language - stabilizing complexity?
On 7/15/2016 1:48 PM, Shachar Shemesh wrote: On 15/07/16 22:50, Walter Bright wrote: You can do logical const in D just like in C++, and get those performance gains. You just can't call it "const". But you can call it /*logical_const*/ and get the same result. No, you can't. The fact that the compiler enforces the no const to mutable transition (unless you use a cast) The compiler does next to nothing - the maintainer can stick in 'mutable' members, and there's no reliable way to detect that. The maintainer can stick in const removing casts, and there's no reliable way to detect that, either. If it's not mechanically checkable, it is not reliable, and is what I call "faith-based programming." is one of the main appeals of using const in any language. If you call something "logical const", but the compiler does not help you to catch bugs, then I don't see the point. I agree, and the C++ compiler is unable to verify "logical const". It's entirely based on faith. In effect, if logical const is what you want, C++ gives you a tool while D leaves you to your own devices. As a result, a lot of places you'd define as const in C++ are defined mutable in D, losing language expressiveness. You and I certainly have polar opposite opinions on that. C++ does not have a notion of "logical const" (it is not in the C++ Standard). It's an uncheckable convention, might as well just use /*logical const*/. D, on the other hand, has verifiable const and verifiable purity.
Re: Vision for the D language - stabilizing complexity?
On Friday, 15 July 2016 at 21:24:12 UTC, Andrei Alexandrescu wrote: On 07/15/2016 04:58 PM, Shachar Shemesh wrote: I do not understand the joy both you and Andrei express when you think you have "won" an "argument". This gives me the feeling that I'm not part of a process designed to make the language better, but rather part of an argument meant to prove to me that the language is fine the way it is. Not a great feeling, and not something that fosters confidence in the language's future direction. We should indeed improve that. Thanks! -- Andrei Humbug, destroying someone's argument is one of the best things ever. Source: high school debater.
Re: Vision for the D language - stabilizing complexity?
On 07/15/2016 04:58 PM, Shachar Shemesh wrote: I do not understand the joy both you and Andrei express when you think you have "won" an "argument". This gives me the feeling that I'm not part of a process designed to make the language better, but rather part of an argument meant to prove to me that the language is fine the way it is. Not a great feeling, and not something that fosters confidence in the language's future direction. We should indeed improve that. Thanks! -- Andrei
Re: Vision for the D language - stabilizing complexity?
On 15/07/16 22:06, Walter Bright wrote: 2. memory allocation - D programmers can use any of C++'s allocation methods Do enlighten me how to use intrusive reference counting in D. I am quite interested in the answer. Or, for that matter, tracking lifetime through an external linked list with an intrusive node structure. The first is impossible due to const casting rules, and the second adds the additional problem of being completely thwarted by D's move semantics. This is before mentioning how, unlike in D, alternate allocators are a fundamental part of C++'s standard library, or how it is not possible to throw exceptions without using the GC. I think your argument there is completely destroyed :-) I do not understand the joy both you and Andrei express when you think you have "won" an "argument". This gives me the feeling that I'm not part of a process designed to make the language better, but rather part of an argument meant to prove to me that the language is fine the way it is. Not a great feeling, and not something that fosters confidence in the language's future direction. Shachar
Re: Vision for the D language - stabilizing complexity?
On 15/07/16 22:50, Walter Bright wrote: You can do logical const in D just like in C++, and get those performance gains. You just can't call it "const". But you can call it /*logical_const*/ and get the same result. No, you can't. The fact that the compiler enforces the no const to mutable transition (unless you use a cast) is one of the main appeals of using const in any language. If you call something "logical const", but the compiler does not help you to catch bugs, then I don't see the point. In effect, if logical const is what you want, C++ gives you a tool while D leaves you to your own devices. As a result, a lot of places you'd define as const in C++ are defined mutable in D, losing language expressiveness. Shachar
Re: Vision for the D language - stabilizing complexity?
On 7/15/2016 12:55 PM, Jack Stouffer wrote: On Friday, 15 July 2016 at 19:06:15 UTC, Walter Bright wrote: 4. making use of asserts to provide information to the optimizer Do dmd/ldc/gdc actually do this? dmd doesn't. I don't know about other compilers. The point is it's possible because C++ doesn't have asserts. C++ has an assert macro, defined to be the same as in C. The definition of assert in C is such that it is turned on/off with the NDEBUG macro, meaning that when it is off, the compiler CANNOT derive any semantic information from it, because it effectively vanishes from the code. In contrast, assert in D is a keyword and has a semantic production. Even if generating code for the assert is disabled with the -release switch, the semantics of it remain and are available to the optimizer. C++ didn't repeat that mistake with 'static_assert' (another feature copied from D), but static assert doesn't help the optimizer.
Re: Vision for the D language - stabilizing complexity?
On Friday, 15 July 2016 at 18:01:43 UTC, Andrei Alexandrescu wrote: Read or write. For const(T) , same thing, but limited to write. Thanks. Reworked: "During and after mutating a memory location typed as (unqualified) type T, no thread in the program (including the current thread) is allowed to (a) effect a read of the same location typed as const(T) or immutable(T), or (b) effect a read or write of the same location typed as shared(T)." Andrei I think the idea is there, but there is still a problem : "During and after" do not have any meaning without ordering constraint/memory barrier.
Re: Vision for the D language - stabilizing complexity?
On Friday, 15 July 2016 at 19:06:15 UTC, Walter Bright wrote: 4. making use of asserts to provide information to the optimizer Do dmd/ldc/gdc actually do this?
Re: Vision for the D language - stabilizing complexity?
On 7/15/2016 7:43 AM, Andrew Godfrey wrote: One example is if you make a class that has an internal cache of something. Updating or invalidating that cache has no logical effect on the externally-observable state of the class. So you should be able to modify the cache even on a 'const' object. Yes, that's the "logical const" argument. The trouble with it is there's no way for the compiler to detect that's what you're doing, nor can it do any checks on it. In effect, C++ const becomes little more than a documentation suggestion. > This is not a bug and I've seen it have a huge > effect on performance - probably a lot more than the const optimizations Walter > is talking about here. You can do logical const in D just like in C++, and get those performance gains. You just can't call it "const". But you can call it /*logical_const*/ and get the same result.
Re: Vision for the D language - stabilizing complexity?
On 7/15/2016 3:25 AM, Shachar Shemesh wrote: On 15/07/16 13:13, Walter Bright wrote: 1. no protection against casting away const and changing it anyway 2. no protection against adding 'mutable' members and changing it anyway 3. only good for one level, no way to specify a data structure of generic type T as const (and, sadly, not something D does very well) Explain. D fixes C++ faults 1..3. Yes, it does. And the result is that const is well defined, safe, and completely impractical to turn on. There are many many places I'd have the compiler enforce const correctness in C++, where in D I just gave up. In one of those places we even went as far as to add run time checks that no one inadvertently changed a buffer. When we first introduced const to D, this was a common complaint. People were accustomed to the weaknesses of C++ const and misinterpreted it as a strength :-) But over time, D const won most over as being a better way, because it offered guarantees that C++ const simply does not. For one, it enables function purity. I think the one that hurts the most is fixing "C++ fault" #3. It means there are many scenarios in which I could put const in C++, and I simply can't in D, because something somewhere needs to be mutable. That's the same argument that appeared when we introduced transitive const. But it means you can't do FP in C++. It means const doesn't work with generic types and generic algorithms. It means that const in a function signature tells you little to nothing unless it is applied to basic types. Check this thread out to see that we actually do need something like #1 in D (though, at least if my suggestion is accepted, without throwing away the optimizations it allows). Casting away const is only allowed in @system code. I agree that we need an improved definition of what happens when const is cast away in @system code, but in no case does it make things worse than in C++. In terms of optimizations, there are, indeed, cases where, had const not been removable, things could be optimized more. I don't think D has a right to complain about C++ in that regard, however. Of course D does. I had to disable const optimizations in my C++ compiler, which is one of the motivations for the way const works in D. For const, yes. In almost every other aspect of the language, however, D favors safety over performance. > Just look at range checks, memory allocation, default > values, and those are just the examples off the top of my head. 1. range checks - can be disabled by a compiler switch 2. memory allocation - D programmers can use any of C++'s allocation methods 3. default values - are removed by standard dead assignment optimizations, or can be disabled by initializing with '= void;' There is one opportunity for C++ that D eschews: taking advantage of undefined behavior on signed integer overflow to improve loops: http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html Practically speaking, optimizers are heavily built for and tuned for C++ semantics. Opportunities that arise due to the semantics of D are not exploited, but this isn't the fault of the core language and does not make C++ better. Opportunities for D that are not available in C++: 1. making use of const 2. making use of immutable 3. making use of function purity 4. making use of asserts to provide information to the optimizer I'm not saying that as a bad thing about D. It is a perfectly valid and reasonable trade off to make. I'm just saying D has no right to criticize C++ for missed optimizations. People who live in glass houses should not throw stones. I think your argument there is completely destroyed :-)
Re: Vision for the D language - stabilizing complexity?
On 07/15/2016 01:27 PM, deadalnix wrote: On Friday, 15 July 2016 at 14:45:41 UTC, Andrei Alexandrescu wrote: On 07/14/2016 12:17 PM, Jesse Phillips wrote: On Tuesday, 12 July 2016 at 05:15:09 UTC, Shachar Shemesh wrote: C++ fully defines when it is okay to cast away constness, gives you aids so that you know that that's what you are doing, and nothing else, and gives you a method by which you can do it without a cast if the circumstances support it. D says any such cast is UB. Shachar Yeah C++ defines how you can modify const data after saying you can never modify data from a const qualified access path. §7.1.6.1/3[1] I still haven't found someone who can explain how C++ can define the behavior of modifying a variable after casting away const. Sure it says that if the original object was mutable (not stored in ROM) than you can modify it, but that is true of D as well, but the language doesn't know the object is not stored in ROM so it can't tell you what it will do when you try to modify it, only you can. 1. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf Getting back to D, a more appropriate definition that gives us enough flexibility to implement allocators etc. has to take time into account. Something like the following: "During and after mutating a memory location typed as (unqualified) type T, no thread in the program (including the current thread) is allowed to effect a read of the same location typed as shared(T) or immutable(T)." This allows us to implement portably allocators that mutate formerly immutable data during deallocation. Andrei Read or write. For const(T) , same thing, but limited to write. Thanks. Reworked: "During and after mutating a memory location typed as (unqualified) type T, no thread in the program (including the current thread) is allowed to (a) effect a read of the same location typed as const(T) or immutable(T), or (b) effect a read or write of the same location typed as shared(T)." Andrei
Re: Vision for the D language - stabilizing complexity?
On Friday, 15 July 2016 at 14:43:35 UTC, Andrew Godfrey wrote: On Friday, 15 July 2016 at 11:09:24 UTC, Patrick Schluter wrote: On Friday, 15 July 2016 at 10:25:16 UTC, Shachar Shemesh wrote: I think the one that hurts the most is fixing "C++ fault" #3. It means there are many scenarios in which I could put const in C++, and I simply can't in D, because something somewhere needs to be mutable. Then it is not const and marking it as const is a bug. D enforces to not write a bug, what's wrong with that? One example is if you make a class that has an internal cache of something. Updating or invalidating that cache has no logical effect on the externally-observable state of the class. So you should be able to modify the cache even on a 'const' object. This is not a bug and I've seen it have a huge effect on performance - probably a lot more than the const optimizations Walter is talking about here. That's actually not true. Memory barrier needs to be emitted, and considered in the caller code.
Re: Vision for the D language - stabilizing complexity?
On Friday, 15 July 2016 at 14:45:41 UTC, Andrei Alexandrescu wrote: On 07/14/2016 12:17 PM, Jesse Phillips wrote: On Tuesday, 12 July 2016 at 05:15:09 UTC, Shachar Shemesh wrote: C++ fully defines when it is okay to cast away constness, gives you aids so that you know that that's what you are doing, and nothing else, and gives you a method by which you can do it without a cast if the circumstances support it. D says any such cast is UB. Shachar Yeah C++ defines how you can modify const data after saying you can never modify data from a const qualified access path. §7.1.6.1/3[1] I still haven't found someone who can explain how C++ can define the behavior of modifying a variable after casting away const. Sure it says that if the original object was mutable (not stored in ROM) than you can modify it, but that is true of D as well, but the language doesn't know the object is not stored in ROM so it can't tell you what it will do when you try to modify it, only you can. 1. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf Getting back to D, a more appropriate definition that gives us enough flexibility to implement allocators etc. has to take time into account. Something like the following: "During and after mutating a memory location typed as (unqualified) type T, no thread in the program (including the current thread) is allowed to effect a read of the same location typed as shared(T) or immutable(T)." This allows us to implement portably allocators that mutate formerly immutable data during deallocation. Andrei Read or write. For const(T) , same thing, but limited to write. Everything else is UB, as it is already UB at the hardware level.
Re: Vision for the D language - stabilizing complexity?
On Friday, 15 July 2016 at 15:35:37 UTC, Dicebot wrote: One example is if you make a class that has an internal cache of something. Updating or invalidating that cache has no logical effect on the externally-observable state of the class. So you should be able to modify the cache even on a 'const' object. This is not a bug and I've seen it have a huge effect on performance - probably a lot more than the const optimizations Walter is talking about here. Yes and the fact that D prohibits this incredibly common C++ design anti-pattern makes me very grateful about such choice. Logical const is terrible - either don't mark such objects as const or make cache separate. +1 Use an interface that prevents external modifications, e.g. getters, but no setters.
Re: Vision for the D language - stabilizing complexity?
On 07/15/2016 05:43 PM, Andrew Godfrey wrote: > On Friday, 15 July 2016 at 11:09:24 UTC, Patrick Schluter wrote: >> On Friday, 15 July 2016 at 10:25:16 UTC, Shachar Shemesh wrote: >>> >>> I think the one that hurts the most is fixing "C++ fault" #3. It >>> means there are many scenarios in which I could put const in C++, and >>> I simply can't in D, because something somewhere needs to be mutable. >> >> Then it is not const and marking it as const is a bug. D enforces to >> not write a bug, what's wrong with that? > > One example is if you make a class that has an internal cache of > something. Updating or invalidating that cache has no logical effect on > the externally-observable state of the class. So you should be able to > modify the cache even on a 'const' object. This is not a bug and I've > seen it have a huge effect on performance - probably a lot more than the > const optimizations Walter is talking about here. Yes and the fact that D prohibits this incredibly common C++ design anti-pattern makes me very grateful about such choice. Logical const is terrible - either don't mark such objects as const or make cache separate.
Re: Vision for the D language - stabilizing complexity?
On 07/14/2016 12:17 PM, Jesse Phillips wrote: On Tuesday, 12 July 2016 at 05:15:09 UTC, Shachar Shemesh wrote: C++ fully defines when it is okay to cast away constness, gives you aids so that you know that that's what you are doing, and nothing else, and gives you a method by which you can do it without a cast if the circumstances support it. D says any such cast is UB. Shachar Yeah C++ defines how you can modify const data after saying you can never modify data from a const qualified access path. §7.1.6.1/3[1] I still haven't found someone who can explain how C++ can define the behavior of modifying a variable after casting away const. Sure it says that if the original object was mutable (not stored in ROM) than you can modify it, but that is true of D as well, but the language doesn't know the object is not stored in ROM so it can't tell you what it will do when you try to modify it, only you can. 1. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf Getting back to D, a more appropriate definition that gives us enough flexibility to implement allocators etc. has to take time into account. Something like the following: "During and after mutating a memory location typed as (unqualified) type T, no thread in the program (including the current thread) is allowed to effect a read of the same location typed as shared(T) or immutable(T)." This allows us to implement portably allocators that mutate formerly immutable data during deallocation. Andrei
Re: Vision for the D language - stabilizing complexity?
On Friday, 15 July 2016 at 11:09:24 UTC, Patrick Schluter wrote: On Friday, 15 July 2016 at 10:25:16 UTC, Shachar Shemesh wrote: I think the one that hurts the most is fixing "C++ fault" #3. It means there are many scenarios in which I could put const in C++, and I simply can't in D, because something somewhere needs to be mutable. Then it is not const and marking it as const is a bug. D enforces to not write a bug, what's wrong with that? One example is if you make a class that has an internal cache of something. Updating or invalidating that cache has no logical effect on the externally-observable state of the class. So you should be able to modify the cache even on a 'const' object. This is not a bug and I've seen it have a huge effect on performance - probably a lot more than the const optimizations Walter is talking about here.
Re: Vision for the D language - stabilizing complexity?
On Friday, 15 July 2016 at 10:25:16 UTC, Shachar Shemesh wrote: I think the one that hurts the most is fixing "C++ fault" #3. It means there are many scenarios in which I could put const in C++, and I simply can't in D, because something somewhere needs to be mutable. Then it is not const and marking it as const is a bug. D enforces to not write a bug, what's wrong with that?
