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 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?
Re: Vision for the D language - stabilizing complexity?
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. 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. 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). 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. 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. Shachar
Re: Vision for the D language - stabilizing complexity?
On 7/15/2016 2:34 AM, Shachar Shemesh wrote: Const is very far from meaningless in C++. It is an extremely valuable tool in turning bugs into compile time errors. That is not something to think lightly of Unfortunately, C++ const is little more than advisory: 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. 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.
Re: Vision for the D language - stabilizing complexity?
On Thursday, 14 July 2016 at 13:24:51 UTC, Ola Fosheim Grøstad wrote: You mean your process describes building prototypes only? Yes? You cannot easily iterate over the design of the core language without creating a mess. You can iterate the design of libraries and to some extent syntactical sugar. You create something when you ship a product. If you build only prototypes, you don't achieve the goal, you described a process of not creating anything, expectedly it bore no fruit.
Re: Vision for the D language - stabilizing complexity?
On 15/07/16 02:06, Jesse Phillips wrote: On Thursday, 14 July 2016 at 18:49:36 UTC, Steven Schveighoffer wrote: If what you wrote is UB (as it is in D), then the compiler can go ahead and assign 5 to y. In C++, the compiler has to reload x, because it may have changed. Someone explained this to me recently on the NG. -Steve Thanks, so when people say "C++ defines the behavior of modifying const" what they really mean is "C++ defines const as meaningless." Const is very far from meaningless in C++. It is an extremely valuable tool in turning bugs into compile time errors. That is not something to think lightly of (and, sadly, not something D does very well) 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. Also, see http://stackoverflow.com/questions/25029516/c-reliance-on-argument-to-const-reference-not-changing Shachar
Re: Vision for the D language - stabilizing complexity?
On Thursday, 14 July 2016 at 14:46:50 UTC, Ola Fosheim Grøstad wrote: The JVM is also a decent example of a core language that is fairly stable. It as based on the StrongTalk VM. AFAIK JVM has a design bug: can't reliably differentiate between methods to invoke the right one.
Re: Vision for the D language - stabilizing complexity?
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?
Re: Vision for the D language - stabilizing complexity?
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. There's no evidence he's ever written a line of D, his examples are pulled out of context from other posts. I don't believe he's ever read the D spec. Whenever he loses a point, he reframes and tries to change the context. He's never contributed a single line of code, nor submitted a single bug report, nor any proposals. His criticisms are always non-specific and completely unactionable. Trying to engage him in a productive discussion inevitably turns into an endless, fruitless, utterly meaningless thread, likely because he doesn't actually know anything about D beyond bits and pieces gleaned from other ng postings. It's sad, considering that he's obviously knowledgeable about the academic end of CS and could be a valuable contributor. But he chooses this instead. As for me, I've decided to put him in my killfile. He's the only one in 15 years to earn that honor.
Re: Vision for the D language - stabilizing complexity?
On Thursday, 14 July 2016 at 18:49:36 UTC, Steven Schveighoffer wrote: If what you wrote is UB (as it is in D), then the compiler can go ahead and assign 5 to y. In C++, the compiler has to reload x, because it may have changed. Someone explained this to me recently on the NG. -Steve Thanks, so when people say "C++ defines the behavior of modifying const" what they really mean is "C++ defines const as meaningless."
Re: Vision for the D language - stabilizing complexity?
On Thursday, 14 July 2016 at 20:09:26 UTC, Ola Fosheim Grøstad wrote: Excuses such as «system programming is complex therefore D must be this complex» is not a position that should be accepted. 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.
Re: Vision for the D language - stabilizing complexity?
On Thursday, 14 July 2016 at 19:17:06 UTC, Chris wrote: I certainly don't impose my view on others. The only reason I was going ad hominem was to get you on board in a more substantial manner than engaging in random discussions on the forum. That won't change anything. It's not a man-hour problem. D is open source. Would it be possible to provide a stripped down version that satisfies you as a proof of concept? I have no idea. I'm only familiar with the C++ code of DMD, and it was somewhat convoluted. When DMD transitioned to D it was stated that the codebase would be refactored heavily. It would make no sense to do anything until those who are intimate with the codebase are done with refactoring. Yet, it probably would not change anything, would it? Why would anyone start on something like that without official backing? That's good to hear. Maybe you should go ahead anyway and see if and how it could be integrated. Maybe it won't add another layer of complexity. It would, you would most likely need to add sub-typing constraints. You mean you won't give up until everybody has the same opinion as you That's not what I meant, and not what I said. I am looking for arguments, not opinions. If you have a good argument, good, then I learn something. If not, maybe you learn something, if you are willing. That simple. Maybe a more diplomatic approach would be better. That's just words, I'm sorry, but when a position is taken that is not sustainable then it doesn't really improve anything to say «oh, you are a little bit right, except maybe not». The point is, if people are reasonably intelligent, they do pick up the argument even if they don't admit to it in the heat of the moment. So it is better to try to present a clean position. Muddying the water pretending that people are having a reasonable position doesn't really move anything, it just confirms the position they are holding. The point is not to win, or to be right, but to bring proper arguments forth, only when people do so will there be some hope of gaining insights. Excuses such as «system programming is complex therefore D must be this complex» is not a position that should be accepted. You have to get rid of this position if you want to get anywhere. Create facts. Provide a stripped down version of D and show that it's better. Completely unreasonable position. That would be more work than writing my own compiler since I don't have an intimate understanding of the current DMD codebase. If I had time to implement my own D compiler then I would just design my own language too... What you are expecting is out of proportions. There is also no point in turning a sketch into a DIP that I know will be shot down because it will require sub-typing. With the current situation it would be quite reasonable to shoot it down for adding complexity. And I am also not willing to propose something that won't give the language a competitive edge... because that won't be a real improvement to status quo. There are basically two options: 1. The people who said they were welcoming breaking changes need to push for a semantic cleanup of the core language so that D can continue to evolve. 2. Someone like Timon who appears to be trying to create a more formal model for D (if I haven't got it completely wrong) will have to find a clean core language underneath the current semantics that can express the current semantics (or most of it) and also be extended in desirable directions. The only thing I can do is support (1).
Re: Vision for the D language - stabilizing complexity?
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.
Re: Vision for the D language - stabilizing complexity?
On 7/13/2016 4:48 AM, John Colvin wrote: Pointer arithmetic in objects is really quite dangerous w.r.t. immutability/const. Right, and one reason why pointer arithmetic isn't allowed in @safe code.
Re: Vision for the D language - stabilizing complexity?
On Thursday, 14 July 2016 at 18:36:26 UTC, Ola Fosheim Grøstad wrote: On Thursday, 14 July 2016 at 18:23:54 UTC, Chris wrote: On Thursday, 14 July 2016 at 18:00:36 UTC, Ola Fosheim Grøstad wrote: You were going ad hominem for no good reason. Here is a pretty good rule: if you don't think you will get something out of an discussion, don't engage in it. I personally find that I learn a lot from discussions on language design, even when other people are completely wrong. You have your own view of what is needed, I have a completely different view. You cannot impose your view of what is need on me, it won't work without a good argument to back it up. I certainly don't impose my view on others. The only reason I was going ad hominem was to get you on board in a more substantial manner than engaging in random discussions on the forum. My view is that the position that some are arguing holds: the core language has to be stripped down of special casing in order to make major progress. Aka: one step back, two steps forwards. D is open source. Would it be possible to provide a stripped down version that satisfies you as a proof of concept? The problem is that abstract reasoning doesn't convince in IT. If you provide something concrete people can work with, then they might pick up on it. If it makes you happy: I am from time to time looking at various ways to modify floating point behaviour, but it won't really matter until complexity is cut back. Because it could easily become another complexity layer on top of what is already there. The best way to improve on D is not to add more complexity, but to cut back to a cleaner core language. That's good to hear. Maybe you should go ahead anyway and see if and how it could be integrated. Maybe it won't add another layer of complexity. Unless you share it, nobody can chip in their 2 cents which might lead to a good solution. I think you are taking a way too convenient position, somehow pretending that there are no major hurdles to overcome in terms of mindshare. My view is that mindshare is the most dominating problem, e.g. changing viewpoints through arguments is really the only option at the moment. You mean you won't give up until everybody has the same opinion as you :) Well, that's not how things work. Maybe a more diplomatic approach would be better. What other options are there? Create facts. Provide a stripped down version of D and show that it's better. You don't need to do it all by yourself. Ask like minded people to help you. I'd be interested in the result. You've praised stripped down D so much that I'm curious. I'm not ideological about things.
Re: Vision for the D language - stabilizing complexity?
On 7/14/16 1:46 PM, Jesse Phillips wrote:
On Thursday, 14 July 2016 at 16:47:20 UTC, Ola Fosheim Grøstad wrote:
On Thursday, 14 July 2016 at 16:17:19 UTC, Jesse Phillips wrote:
I still haven't found someone who can explain how C++ can define the
behavior of modifying a variable after casting away const.
C++ is locked down in a mine-field of backward compatibility issues
and a need to interface with C verbatim (directly including C header
files where const parameters might lack the const modifier).
D does not work with C header files and can redefine the interfaces to
fit D semantics in C bindings...
That doesn't explain how you can define the behavior:
void foo(int const* p) {
*(const_cast(p)) = 3;
}
Does 'p' get modified or is the program going to crash or something
else? Please define it for me. C++ says: You can't modify the location
pointed to by 'p' from 'p', using const_cast on 'p' you'll either get
undefined behavior or it will modify the location 'p' points to. So it
is defined to either be undefined or modify the location 'p' refers to.
The language isn't able to tell you what will happen so how can it
define the behavior?
That section means the compiler will stop you from doing it unless you
cast it away :)
That is:
*p = 3;
is a compiler error. That's all the note is saying.
What defining the behavior means is that the compiler has to take into
account that a variable can change even though all available accesses to
it are const.
For example:
int x = 5;
foo();
int y = x;
If what you wrote is UB (as it is in D), then the compiler can go ahead
and assign 5 to y.
In C++, the compiler has to reload x, because it may have changed.
Someone explained this to me recently on the NG.
-Steve
Re: Vision for the D language - stabilizing complexity?
On Thursday, 14 July 2016 at 18:23:54 UTC, Chris wrote: On Thursday, 14 July 2016 at 18:00:36 UTC, Ola Fosheim Grøstad wrote: Please don't try to make yourself look like a martyr. Huh? Where is that coming from all of a sudden? Sorry, I don't see the point of this comment. You were going ad hominem for no good reason. Here is a pretty good rule: if you don't think you will get something out of an discussion, don't engage in it. I personally find that I learn a lot from discussions on language design, even when other people are completely wrong. You have your own view of what is needed, I have a completely different view. You cannot impose your view of what is need on me, it won't work without a good argument to back it up. My view is that the position that some are arguing holds: the core language has to be stripped down of special casing in order to make major progress. Aka: one step back, two steps forwards. If it makes you happy: I am from time to time looking at various ways to modify floating point behaviour, but it won't really matter until complexity is cut back. Because it could easily become another complexity layer on top of what is already there. The best way to improve on D is not to add more complexity, but to cut back to a cleaner core language. I think you are taking a way too convenient position, somehow pretending that there are no major hurdles to overcome in terms of mindshare. My view is that mindshare is the most dominating problem, e.g. changing viewpoints through arguments is really the only option at the moment. What other options are there?
Re: Vision for the D language - stabilizing complexity?
On Thursday, 14 July 2016 at 18:00:36 UTC, Ola Fosheim Grøstad wrote: Please don't try to make yourself look like a martyr. Huh? Where is that coming from all of a sudden? Sorry, I don't see the point of this comment. A martyr for what? Martyrs are stupid people, they should have stayed at home enjoying a nice fresh beer instead of trying to change the course or the world single-handedly. Maybe you should have one too, a beer that is, and think about becoming a contributor to D.
Re: Vision for the D language - stabilizing complexity?
On Thursday, 14 July 2016 at 17:36:59 UTC, Chris wrote: On Thursday, 14 July 2016 at 15:59:30 UTC, Ola Fosheim Grøstad wrote: Not sure what you mean by calling D multi-paradigm. As opposed to Java that is 100% OOP (well 99%). Which programming model is it that D supports that Java doesn't? Functional? Logic? ...? Ok, this is called a metaphor, a figure of speech. Poor metaphor. :) But, uh, you do get it, don't you? That's right, I don't get it, and it isn't true. Walter's vision obviously changed with D2, it was a shift in the core original vision which focused on creating a significantly simpler language than C++. That's perfectly ok, a change in personal interests towards a more ambitious vision is perfectly ok. But it has an impact on the outcome, obviously. And why is that so? Is it because of inherent difficulties to marry low-level functionality with high-level concepts? No, it's because language designers are stopid [<= irony] Poor irony too... It is so because: 1. system level programming language design has very little academic value 2. it is very difficult to unseat C/C++ which is doing a fair job of it 3. because portability is very very important and difficult 4. because high level languages often try to provide solutions to specific areas contributions to the core language. How could anyone keep track of not to mention act on criticism that is scattered out all over threads. Oh, you don't have to. I am backing those that are arguing for reasonable positions and will do so for as long as I think that will move the project to a more interesting position. Please don't try to make yourself look like a martyr. Or is it an intricate problem that's not trivial to solve? I very seldom run into memory related issues unless I do pointer arithmetic, which @safe does not help with. If it is hard to solve, the solution is easy: postpone it until you have something on paper that can work...
Re: Vision for the D language - stabilizing complexity?
On Thursday, 14 July 2016 at 16:47:20 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 14 July 2016 at 16:17:19 UTC, Jesse Phillips wrote:
I still haven't found someone who can explain how C++ can
define the behavior of modifying a variable after casting away
const.
C++ is locked down in a mine-field of backward compatibility
issues and a need to interface with C verbatim (directly
including C header files where const parameters might lack the
const modifier).
D does not work with C header files and can redefine the
interfaces to fit D semantics in C bindings...
That doesn't explain how you can define the behavior:
void foo(int const* p) {
*(const_cast(p)) = 3;
}
Does 'p' get modified or is the program going to crash or
something else? Please define it for me. C++ says: You can't
modify the location pointed to by 'p' from 'p', using const_cast
on 'p' you'll either get undefined behavior or it will modify the
location 'p' points to. So it is defined to either be undefined
or modify the location 'p' refers to. The language isn't able to
tell you what will happen so how can it define the behavior?
Re: Vision for the D language - stabilizing complexity?
On Thursday, 14 July 2016 at 15:59:30 UTC, Ola Fosheim Grøstad wrote: It wasn't pure OOP, not sure what you mean by that either. Not sure what you mean by calling D multi-paradigm. As opposed to Java that is 100% OOP (well 99%). I still don't get the comparison. I don't buy a new computer until I am running out of RAM. Speed is no longer a big issue for me, not even with C++ compilation speed. Ok, this is called a metaphor, a figure of speech. I'll translate it for you: To wait until a language is perfect, before you deploy it is like constantly waiting for the next generation of computers to come out, before you buy one. I.e. it will never happen, because there will always a next generation that is even better. But, uh, you do get it, don't you? So they don't exist, because the perfect language is also a system level language. Who has been talking about perfect? Geez, system programming languages are lightyears away from perfect. And they are way way behind high level ones. And why is that so? Is it because of inherent difficulties to marry low-level functionality with high-level concepts? No, it's because language designers are stopid [<= irony] It's tiresome and doesn't get us anywhere. Then don't argue the point without having a real argument against it. If your motivation is entirely defensive then you don't really achieve anything. If your motivation is informational, then it can achieve something. E.g. you could enlighten me. I don't agree with you that knowledge doesn't get people anywhere. I think it does, it just takes a lot of time, depending on where they come from. I don't know much about Andrei, but Walter does move over time. Except your knowledge is not focused and thus doesn't help anyone, random rants on whatever topic comes up instead of a focused plan of action with proofs of concept and possibly contributions to the core language. How could anyone keep track of not to mention act on criticism that is scattered out all over threads. E.g. low-level control vs. safety (cf. the discussion about casting away immutable) I don't think that is a very good argument. All it tells me is that D's approach to safety isn't working and that you need to do this by static analysis over a much simpler core language. Or is it an intricate problem that's not trivial to solve? But this is going nowhere ...
Re: Vision for the D language - stabilizing complexity?
On Thursday, 14 July 2016 at 16:17:19 UTC, Jesse Phillips wrote: I still haven't found someone who can explain how C++ can define the behavior of modifying a variable after casting away const. C++ is locked down in a mine-field of backward compatibility issues and a need to interface with C verbatim (directly including C header files where const parameters might lack the const modifier). D does not work with C header files and can redefine the interfaces to fit D semantics in C bindings...
Re: Vision for the D language - stabilizing complexity?
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
Re: Vision for the D language - stabilizing complexity?
On Thursday, 14 July 2016 at 15:28:45 UTC, Chris wrote: I don't know much about Simula (your patriotic choice :), but it's pure OOP and as such cannot be compared to D either (which is multi-paradigm). It wasn't pure OOP, not sure what you mean by that either. Not sure what you mean by calling D multi-paradigm. I.e you have to deploy it at some point, it will never be perfect before you deploy it - just as you have to buy a computer at some point. If you keep waiting for the next generation, you'll never buy a computer (has happened!). I still don't get the comparison. I don't buy a new computer until I am running out of RAM. Speed is no longer a big issue for me, not even with C++ compilation speed. So they don't exist, because the perfect language is also a system level language. Who has been talking about perfect? Geez, system programming languages are lightyears away from perfect. And they are way way behind high level ones. It's tiresome and doesn't get us anywhere. Then don't argue the point without having a real argument against it. If your motivation is entirely defensive then you don't really achieve anything. If your motivation is informational, then it can achieve something. E.g. you could enlighten me. I don't agree with you that knowledge doesn't get people anywhere. I think it does, it just takes a lot of time, depending on where they come from. I don't know much about Andrei, but Walter does move over time. E.g. low-level control vs. safety (cf. the discussion about casting away immutable) I don't think that is a very good argument. All it tells me is that D's approach to safety isn't working and that you need to do this by static analysis over a much simpler core language.
Re: Vision for the D language - stabilizing complexity?
On Thursday, 14 July 2016 at 14:46:50 UTC, Ola Fosheim Grøstad wrote: On Thursday, 14 July 2016 at 14:11:25 UTC, Chris wrote: On Thursday, 14 July 2016 at 13:39:48 UTC, Ola Fosheim Grøstad wrote: On Thursday, 14 July 2016 at 13:26:06 UTC, Chris wrote: Such a language will never see the light of day. Many such languages exist. Didn't I say that I don't have time for a long rant? :-) Simula is a pretty good example. In it's first incarnation it was a simulation language, then it was reformulated as a general purpose language. Dart is a pretty good example. The extensions have been primarily syntactical AFAIK. TypeScript is a pretty good example of a language that is both stable and wildly expansive, as the core language is JavaScript and TypeScript is a layer above the core language. It is getting pretty good actually. Go is a reasonable example (despite the error handling blunder). It has not changed much in terms of the core language and IIRC it is based on earlier languages by the same authors. The JVM is also a decent example of a core language that is fairly stable. It as based on the StrongTalk VM. I could go on for a while. I'm not convinced. Dart & TypeScript are scripting languages for the Internet and cannot be compared to D and C++. Go is an Internet/server language, very bare bones and designed for Google's code mines. All three languages above where designed by big companies with certain commercial goals in mind. I don't know much about Simula (your patriotic choice :), but it's pure OOP and as such cannot be compared to D either (which is multi-paradigm). ... and they're all usable as in I can write software with them right now. Plenty of languages are usable, both Pony and Pure are usable, but they are not widely used. So it currently does not make much sense for me to use them as they most likely would cause more trouble than they would save me. But you don't use them for a reason. Examples? Slices etc. Yes, exactly, they were never meant to be big languages, just scripting tools. Same happened to Python in a way. It should never have left the lab and infected millions of people. Python was informed by an educational language, but was designed to appeal to professionals, so I don't think it applies to Python as much. But only in a "lab environment". There's never _the_ perfect time to deploy a language, just like there's never _the_ perfect time to buy a computer, the moment you leave the shop it's out of date. Huh, I don't understand the comparison? I.e you have to deploy it at some point, it will never be perfect before you deploy it - just as you have to buy a computer at some point. If you keep waiting for the next generation, you'll never buy a computer (has happened!). Anyhow, I don't upgrade until I hit some unacceptable performance issues. I have a 4 year old computer and have no performance issues with it yet. :-P There is very little advantage for me to have a faster computer than where the software is deployed. You're dreaming of a language that only exists in cloud cuckoo land and it will get you nowhere. Nope. Such languages exits, but they are not _system level_ programming languages. So they don't exist, because the perfect language is also a system level language. But of course, it's much easier to criticize the players on the pitch from your comfy armchair than to actually go onto the pitch and play yourself. What makes you think that I am not playing? What you actually are saying is that one should not make judgments about programming languages or try to influence their direction. I don't know whether I should be sad or angry to see someone with your knowledge and experience wasting his time endlessly ranting about D (while praising every other language under the sun). You could make valuable hands-on contributions to D, but choose to be the Statler & Waldorf of the community - only without the fun factor. It's tiresome and doesn't get us anywhere. No language ever gets it 100% right, because there are conflicting demands, and it's trivial to point out flaws that are bound to arise out of conflicting demands. What conflicting demands do you suggest applies to D? I don't see them, so I hope you can inform me. E.g. low-level control vs. safety (cf. the discussion about casting away immutable)
Re: Vision for the D language - stabilizing complexity?
On Thursday, 14 July 2016 at 14:11:25 UTC, Chris wrote: On Thursday, 14 July 2016 at 13:39:48 UTC, Ola Fosheim Grøstad wrote: On Thursday, 14 July 2016 at 13:26:06 UTC, Chris wrote: Such a language will never see the light of day. Many such languages exist. Didn't I say that I don't have time for a long rant? :-) Simula is a pretty good example. In it's first incarnation it was a simulation language, then it was reformulated as a general purpose language. Dart is a pretty good example. The extensions have been primarily syntactical AFAIK. TypeScript is a pretty good example of a language that is both stable and wildly expansive, as the core language is JavaScript and TypeScript is a layer above the core language. It is getting pretty good actually. Go is a reasonable example (despite the error handling blunder). It has not changed much in terms of the core language and IIRC it is based on earlier languages by the same authors. The JVM is also a decent example of a core language that is fairly stable. It as based on the StrongTalk VM. I could go on for a while. ... and they're all usable as in I can write software with them right now. Plenty of languages are usable, both Pony and Pure are usable, but they are not widely used. So it currently does not make much sense for me to use them as they most likely would cause more trouble than they would save me. Examples? Slices etc. Yes, exactly, they were never meant to be big languages, just scripting tools. Same happened to Python in a way. It should never have left the lab and infected millions of people. Python was informed by an educational language, but was designed to appeal to professionals, so I don't think it applies to Python as much. There's never _the_ perfect time to deploy a language, just like there's never _the_ perfect time to buy a computer, the moment you leave the shop it's out of date. Huh, I don't understand the comparison? Anyhow, I don't upgrade until I hit some unacceptable performance issues. I have a 4 year old computer and have no performance issues with it yet. :-P There is very little advantage for me to have a faster computer than where the software is deployed. You're dreaming of a language that only exists in cloud cuckoo land and it will get you nowhere. Nope. Such languages exits, but they are not _system level_ programming languages. But of course, it's much easier to criticize the players on the pitch from your comfy armchair than to actually go onto the pitch and play yourself. What makes you think that I am not playing? What you actually are saying is that one should not make judgments about programming languages or try to influence their direction. No language ever gets it 100% right, because there are conflicting demands, and it's trivial to point out flaws that are bound to arise out of conflicting demands. What conflicting demands do you suggest applies to D? I don't see them, so I hope you can inform me.
Re: Vision for the D language - stabilizing complexity?
On Thursday, 14 July 2016 at 13:39:48 UTC, Ola Fosheim Grøstad wrote: On Thursday, 14 July 2016 at 13:26:06 UTC, Chris wrote: Such a language will never see the light of day. Many such languages exist. Like? I mean languages that can be used in the real world. Certainly not Nim. It's not usable yet, it may change drastically any time. What makes a language attractive is that you can actually use it - here and now. What makes a language attractive is that it has system support and provides solutions that save time. That's what languages like TypeScript, Python, C#, Java, Swift and Go attractive. ... and they're all usable as in I can write software with them right now. I follow several languages that are very attractive, but that I cannot use because they don't have system support. I am also using languages that are less attractive than the alternatives for the same reasons. Of course, the first thing you ought to do is to look at existing knowhow related to language design. Which is what D did. No, it did not build on existing knowhow in language design theory, it was a fair reinterpretation of the C++ programming model with a tiny bit of Pythonesque extensions. Examples? ... which, in fairness, where never meant to be carefully designed languages. Just convenient hacks for everyday tasks. Perl and Php started as small and convenient scripting languages, but they were predominantly evolved in an iterative fashion for decades after that, and aggregated a lot of issues related to exactly iterative evolution. Yes, exactly, they were never meant to be big languages, just scripting tools. Same happened to Python in a way. It should never have left the lab and infected millions of people. Both C++ and D shows clear signs of their abstraction mechanisms not fitting well with the core language. Too many mechanisms, not generic enough. And that happened because significant changes came late in the process, after deployment. You can say the same thing about Go and error-handling, it sticks out like a sore thumb. There's never _the_ perfect time to deploy a language, just like there's never _the_ perfect time to buy a computer, the moment you leave the shop it's out of date. You're dreaming of a language that only exists in cloud cuckoo land and it will get you nowhere. But of course, it's much easier to criticize the players on the pitch from your comfy armchair than to actually go onto the pitch and play yourself. No language ever gets it 100% right, because there are conflicting demands, and it's trivial to point out flaws that are bound to arise out of conflicting demands.
Re: Vision for the D language - stabilizing complexity?
On Thursday, 14 July 2016 at 13:26:06 UTC, Chris wrote: Such a language will never see the light of day. Many such languages exist. What makes a language attractive is that you can actually use it - here and now. What makes a language attractive is that it has system support and provides solutions that save time. That's what languages like TypeScript, Python, C#, Java, Swift and Go attractive. I follow several languages that are very attractive, but that I cannot use because they don't have system support. I am also using languages that are less attractive than the alternatives for the same reasons. Of course, the first thing you ought to do is to look at existing knowhow related to language design. Which is what D did. No, it did not build on existing knowhow in language design theory, it was a fair reinterpretation of the C++ programming model with a tiny bit of Pythonesque extensions. ... which, in fairness, where never meant to be carefully designed languages. Just convenient hacks for everyday tasks. Perl and Php started as small and convenient scripting languages, but they were predominantly evolved in an iterative fashion for decades after that, and aggregated a lot of issues related to exactly iterative evolution. Both C++ and D shows clear signs of their abstraction mechanisms not fitting well with the core language. Too many mechanisms, not generic enough. And that happened because significant changes came late in the process, after deployment. You can say the same thing about Go and error-handling, it sticks out like a sore thumb.
Re: Vision for the D language - stabilizing complexity?
On Thursday, 14 July 2016 at 12:12:34 UTC, Ola Fosheim Grøstad wrote: On Thursday, 14 July 2016 at 11:38:59 UTC, Chris wrote: On Wednesday, 13 July 2016 at 17:30:53 UTC, Kagamin wrote: Software design is an iterative process because one can't sort everything at once. Not true. Ola can. :) (I just couldn't resist ...) I don't have time for a long rant on this... Now, now. Where's your sense of humor? But if you are designing a truly new langauge (and D isn't), then you create prototypes, then you build a framework that is suitable for evolutionary design, then you spec it, then you try to prove it sound, then you implement it then you trash it, and redesign it and write a new spec. Once you have a foundation where most things can be expressed in libraries you have a good base for iterating and handing it to the world. Such a language will never see the light of day. Never. And given the constant changes in the IT business, you'll have to constantly trash and re-implement things. Nobody will be able to use the language in the real world, and it's using a language in the real world that shows you where a language's strengths and weaknesses are. I fear that some of the younger languages are taking that path. They will be ready for use by the time we'll have quark based processors or switched to telepathy altogether :-) What makes a language attractive is that you can actually use it - here and now. Of course, the first thing you ought to do is to look at existing knowhow related to language design. Which is what D did. That's a no-brainer. The alternative, to just iterate, is what gives you languages like Perl and Php. ... which, in fairness, where never meant to be carefully designed languages. Just convenient hacks for everyday tasks.
Re: Vision for the D language - stabilizing complexity?
On Thursday, 14 July 2016 at 13:11:36 UTC, Kagamin wrote: On Thursday, 14 July 2016 at 12:57:06 UTC, Ola Fosheim Grøstad wrote: Huh? I need to explain the purpose of building prototypes? You mean your process describes building prototypes only? Yes? You cannot easily iterate over the design of the core language without creating a mess. You can iterate the design of libraries and to some extent syntactical sugar.
