Re: DIP 1028--Make @safe the Default--Formal Assessment
On 28/05/2020 12:33 AM, aberba wrote: On Thursday, 21 May 2020 at 18:36:51 UTC, H. S. Teoh wrote: On Thu, May 21, 2020 at 05:49:27PM +, Paul Backus via Digitalmars-d-announce wrote: [...] Even if we suppose for the sake of argument that the decision is sound on a technical level, this is poor leadership, and bodes ill for the future of the D language and its community. D excels at the technical aspects, but time and time again has shown that it lacks proper management / leadership. Contrary to my own inclinations I'm compelled to suggest hiring a *non-technical* person to take up the management/leadership roles (emphatically non-technical, because let's face it, we techies just don't have the people skillz it takes to do this properly), because the current situation clearly isn't working, and is quite detrimental to D and its future. T Ha ha. I tried suggesting something like this some yrs ago as I saw it happen and deadalnix bashed me like crazy. Didn't articulate it as well as you just did though. This needs to happen. I've been saying since 2012 that we need a project manager to help with communication. Mike has taken on parts of this role and has done quite a good job of it.
Re: DIP 1028--Make @safe the Default--Formal Assessment
On Thursday, 21 May 2020 at 18:36:51 UTC, H. S. Teoh wrote: On Thu, May 21, 2020 at 05:49:27PM +, Paul Backus via Digitalmars-d-announce wrote: [...] Even if we suppose for the sake of argument that the decision is sound on a technical level, this is poor leadership, and bodes ill for the future of the D language and its community. D excels at the technical aspects, but time and time again has shown that it lacks proper management / leadership. Contrary to my own inclinations I'm compelled to suggest hiring a *non-technical* person to take up the management/leadership roles (emphatically non-technical, because let's face it, we techies just don't have the people skillz it takes to do this properly), because the current situation clearly isn't working, and is quite detrimental to D and its future. T Ha ha. I tried suggesting something like this some yrs ago as I saw it happen and deadalnix bashed me like crazy. Didn't articulate it as well as you just did though. This needs to happen.
Re: DIP 1028--Make @safe the Default--Formal Assessment
On 2020-05-24 00:15, Walter Bright wrote: On 5/23/2020 4:26 AM, Faux Amis wrote: Just a suggestion, but sometimes matters are best discussed over audio/video. Would having a public teams/zoom/.. meeting be helpful? I would definitely listen/watch; even if I were muted and could only chat maybe. You're right, and that is the whole purpose behind DConf. It's amazing how our differences melt away when discussing with a beer in hand :-) I meant it could be something being done more often, Dconf is (normally) only once a year. Maybe discussions like these need to be discussed more frequently.. quarterly, or even a quick official Dtalk every month :)
Re: DIP 1028--Make @safe the Default--Formal Assessment
On Saturday, 23 May 2020 at 15:07:16 UTC, Andrei Alexandrescu wrote: On 5/21/20 7:49 PM, Bruce Carneal wrote: On Thursday, 21 May 2020 at 16:32:32 UTC, Adam D. Ruppe wrote: On Thursday, 21 May 2020 at 16:14:02 UTC, Seb wrote: Why we can't we have a technical board where the community can vote in experts and potentially companies could even buy a seat for $$$ which would mean a lot more for them than the current very vague sponsorship options. ditto, I think we should have like a seven person elected DIP committee who pass/fail things by majority vote. It is obvious to me that the current process is totally useless. As noted earlier, I'm with Steve, Seb, Adam, and "everyone but Walter" as far as I can see. If this stands we'll have gone from @safe meaning "the compiler is responsible" to "the compiler can't guarantee anything unless you're pure D all the way down". Atila, what's your take on all this? Is it fork time? A fork does exist. As expected it went nowhere. https://bitbucket.org/larsivi/amber/wiki/Home. There is a paradox about forking the language - anyone good enough to lead a successful fork would also be wise enough to work on the D language instead. Arguably they would then be wise enough to stay away from D (and have). His strength comes with equally unique ability to explain and debate, which makes many of the discussions in forums very frustrating. It is unique that's for sure. That's a good way to put it without being rude.
Re: DIP 1028--Make @safe the Default--Formal Assessment
On 5/23/20 6:49 PM, ag0aep6g wrote: On 23.05.20 17:07, Andrei Alexandrescu wrote: A fork does exist. As expected it went nowhere. https://bitbucket.org/larsivi/amber/wiki/Home. There is a paradox about forking the language - anyone good enough to lead a successful fork would also be wise enough to work on the D language instead. I can only read that as you calling larsivi not "good enough to lead a successful fork" and not "wise enough to work on the D language instead". Walter says: "Belittling [others] [...] is unprofessional behavior." He was refering to other people on the forum, of course. But I would expand that to authors of other projects as well, particularly ones that are (even) smaller than D. Punching down is not cool. The point is on the other side - the barrier is very high. Carrying a programming language design and implementation is an extremely difficult task.
Re: DIP 1028--Make @safe the Default--Formal Assessment
On 23.05.20 17:07, Andrei Alexandrescu wrote: A fork does exist. As expected it went nowhere. https://bitbucket.org/larsivi/amber/wiki/Home. There is a paradox about forking the language - anyone good enough to lead a successful fork would also be wise enough to work on the D language instead. I can only read that as you calling larsivi not "good enough to lead a successful fork" and not "wise enough to work on the D language instead". Walter says: "Belittling [others] [...] is unprofessional behavior." He was refering to other people on the forum, of course. But I would expand that to authors of other projects as well, particularly ones that are (even) smaller than D. Punching down is not cool.
Re: DIP 1028--Make @safe the Default--Formal Assessment
On 5/23/2020 4:26 AM, Faux Amis wrote: Just a suggestion, but sometimes matters are best discussed over audio/video. Would having a public teams/zoom/.. meeting be helpful? I would definitely listen/watch; even if I were muted and could only chat maybe. You're right, and that is the whole purpose behind DConf. It's amazing how our differences melt away when discussing with a beer in hand :-)
Re: DIP 1028--Make @safe the Default--Formal Assessment
On 5/21/20 7:49 PM, Bruce Carneal wrote: On Thursday, 21 May 2020 at 16:32:32 UTC, Adam D. Ruppe wrote: On Thursday, 21 May 2020 at 16:14:02 UTC, Seb wrote: Why we can't we have a technical board where the community can vote in experts and potentially companies could even buy a seat for $$$ which would mean a lot more for them than the current very vague sponsorship options. ditto, I think we should have like a seven person elected DIP committee who pass/fail things by majority vote. It is obvious to me that the current process is totally useless. As noted earlier, I'm with Steve, Seb, Adam, and "everyone but Walter" as far as I can see. If this stands we'll have gone from @safe meaning "the compiler is responsible" to "the compiler can't guarantee anything unless you're pure D all the way down". Atila, what's your take on all this? Is it fork time? A fork does exist. As expected it went nowhere. https://bitbucket.org/larsivi/amber/wiki/Home. There is a paradox about forking the language - anyone good enough to lead a successful fork would also be wise enough to work on the D language instead. A committee would work if the community were at least one order of magnitude larger. It's just big numbers. Walter is world-class, another way of saying there's only a few of comparable strength in the world. A larger community would mean a larger likelihood of there being other people of comparable strength in it. Those could form a committee. As things are, Walter is so much stronger than every one of us, the relationship is highly asymmetric. His strength comes with equally unique ability to explain and debate, which makes many of the discussions in forums very frustrating.
Re: DIP 1028--Make @safe the Default--Formal Assessment
On 2020-05-22 03:16, Walter Bright wrote: The level of negativity in that thread was what caused me to stop responding, though I continued reading. Every reply I made produced 10 responses, an exponential explosion, and yet I was just repeating myself. Two sides to every story. FWIW, I am going to try again with another post here, for those who want a convenient summary of the rationale. Just a suggestion, but sometimes matters are best discussed over audio/video. Would having a public teams/zoom/.. meeting be helpful? I would definitely listen/watch; even if I were muted and could only chat maybe.
Re: DIP 1028--Make @safe the Default--Formal Assessment
Perhaps not the ideal solution, but would a compiler flag, e.g. --strict-safe, that ensures the compiler errors on un-@trusted non-D function prototypes be appropriate? This way, those who do work on mission-critical stuff can feel a tad better.
Re: DIP 1028--Make @safe the Default--Formal Assessment
On Thursday, 21 May 2020 at 23:49:22 UTC, Bruce Carneal wrote: On Thursday, 21 May 2020 at 16:32:32 UTC, Adam D. Ruppe wrote: On Thursday, 21 May 2020 at 16:14:02 UTC, Seb wrote: [...] ditto, I think we should have like a seven person elected DIP committee who pass/fail things by majority vote. It is obvious to me that the current process is totally useless. As noted earlier, I'm with Steve, Seb, Adam, and "everyone but Walter" as far as I can see. If this stands we'll have gone from @safe meaning "the compiler is responsible" to "the compiler can't guarantee anything unless you're pure D all the way down". Atila, what's your take on all this? Is it fork time? No.
Re: DIP 1028--Make @safe the Default--Formal Assessment
On Thursday, 21 May 2020 at 13:51:34 UTC, Mike Parker wrote: DIP 1028, "Make @safe the Default", has been accepted without comment. https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1028.md I've made a draft PR to try and address the potential safety issue discussed in this thread. Any and all constructive feedback is greatly appreciated, so feel free to comment: https://github.com/dlang/dmd/pull/11176
Re: DIP 1028--Make @safe the Default--Formal Assessment
On 5/21/2020 4:45 PM, H. S. Teoh wrote: This makes it sound like you think that those who disagree with you disagree with @safe by default. That is not the case. I'm sure you all know what I'm talking about.
Re: DIP 1028--Make @safe the Default--Formal Assessment
On 5/21/2020 2:41 PM, Steven Schveighoffer wrote: I even put forth a completely ignored compromise solution that would have solved the problem and allowed extern(C) functions to be considered @safe by default: https://digitalmars.com/d/archives/digitalmars/D/Discussion_Thread_DIP_1028--Make_safe_the_Default--Final_Review_336354.html#N336968 I did see it. I can't even get across the notion of what "undefined symbol " messages from the linker mean to a lot of programmers. I'll never get this one across. The linking process is already as complex as I dare. BTW, two symbols resolving to the same address can be a bit awkward in some object formats and isn't really supported, like with COMDATs. In my experience, unless C or C++ compilers generate certain constructs, linkers (and debuggers) don't work for those constructs, whether they are documented to or not. This is why I consider the process a waste of time, and why I'm done participating. The level of negativity in that thread was what caused me to stop responding, though I continued reading. Every reply I made produced 10 responses, an exponential explosion, and yet I was just repeating myself. Two sides to every story. FWIW, I am going to try again with another post here, for those who want a convenient summary of the rationale.
Re: DIP 1028--Make @safe the Default--Formal Assessment
On Friday, 22 May 2020 at 00:50:00 UTC, Walter Bright wrote: On 5/21/2020 2:44 PM, Joseph Rushton Wakeling wrote: One concern here is that these responses are scattered across different parts of a long discussion thread. So it probably would be a good idea for the acceptance to be accompanied by an explanation of what the major objections were to the DIP, and why they were discounted. It's not so different from the way that, at the end of a talk or presentation, it's a good idea to recap the key points that have already been covered. Fair enough. I'll do so. Stay tuned. Thank you. Having an explanation on why the DIP is accepted despite being highly controversial would be sufficient. -Alex
Re: DIP 1028--Make @safe the Default--Formal Assessment
On 5/21/2020 2:45 PM, bachmeier wrote: On Thursday, 21 May 2020 at 20:48:18 UTC, Walter Bright wrote: On 5/21/2020 10:03 AM, bachmeier wrote: Walter makes decisions based on his mood on a particular day That's uncalled for. Regional variation in English? Translation: You make your decisions based on how you feel about the situation at a point in time. "Mood" is used because there's some subjectivity and "gut feel" involved in the decision. It's not intended to be negative, it's simply a description of how any human makes any decision. That's why I said the same about how a committee would make decisions. As a native English speaker, telling someone they are making decisions based on moods is telling them they are making irrational decisions. I accept that you did not intend it in this manner, but you should be aware that many people would be offended by it.
Re: DIP 1028--Make @safe the Default--Formal Assessment
On 5/21/2020 2:44 PM, Joseph Rushton Wakeling wrote: One concern here is that these responses are scattered across different parts of a long discussion thread. So it probably would be a good idea for the acceptance to be accompanied by an explanation of what the major objections were to the DIP, and why they were discounted. It's not so different from the way that, at the end of a talk or presentation, it's a good idea to recap the key points that have already been covered. Fair enough. I'll do so. Stay tuned.
Re: DIP 1028--Make @safe the Default--Formal Assessment
On Thursday, 21 May 2020 at 16:32:32 UTC, Adam D. Ruppe wrote: On Thursday, 21 May 2020 at 16:14:02 UTC, Seb wrote: Why we can't we have a technical board where the community can vote in experts and potentially companies could even buy a seat for $$$ which would mean a lot more for them than the current very vague sponsorship options. ditto, I think we should have like a seven person elected DIP committee who pass/fail things by majority vote. It is obvious to me that the current process is totally useless. As noted earlier, I'm with Steve, Seb, Adam, and "everyone but Walter" as far as I can see. If this stands we'll have gone from @safe meaning "the compiler is responsible" to "the compiler can't guarantee anything unless you're pure D all the way down". Atila, what's your take on all this? Is it fork time?
Re: DIP 1028--Make @safe the Default--Formal Assessment
On Thu, May 21, 2020 at 01:46:09PM -0700, Walter Bright via
Digitalmars-d-announce wrote:
[...]
> I expected flak from this decision. I'm prepared to take the flak
> because this is the right decision. I did not make it lightly.
This makes it sound like you think that those who disagree with you
disagree with @safe by default. That is not the case. I think in
general, (almost?) everyone here agrees that safety by default is the
way to go. We all agree that @safe by default ought to be in the
language, in one form or another. That's not the dispute here.
The dispute concerns the specific implementation of @safe by default as
set out in this DIP. Specifically, the weakening of the promise of @safe
by implicitly trusting extern(C) declarations to be @safe, which is
equivalent to programming by convention ("trust the programmer to
remember to write @system on extern(C) prototypes"). Which, ironically,
undermines the whole purpose of this DIP. (That is, unless I
misunderstood, and the whole purpose of this DIP is to undermine @safety
and thereby make it even more of a joke than it currently is right now.)
> Please keep in mind that I've made other unpopular decisions that have
> proven their worth over time. I hope you'll reserve judgement until we
> all see how this change plays out.
[...]
Oh I'm waiting to see this one plays out, you bet! What will come of
trusting the programmer to do the right thing when it comes to
annotating extern(C) prototypes with @system? Well, I'm sure it will
all work out well in the end, since, after all, it isn't as if we didn't
have ~50 years or so of experience with programming by convention,
y'know, esp. in C code (that we should implicitly trust when calling
from D, btw), which has led to beautiful security holes and exploits
caused by memory corruption and other such wonderful things.
Or, since you like airplane analogies, there's absolutely nothing wrong
with designing your cockpit controls such that the default behaviour,
when the pilot does not indicate otherwise, is to nose-dive into the
ground. After all, if he didn't mean to do that, he should've
remembered to override the default behaviour explicitly, right? That's
what he was trained to do, anyway. And besides, it's easier to
implement the controls this way, since doing otherwise would add
excessive complication to the design.
T
--
The early bird gets the worm. Moral: ewww...
Re: DIP 1028--Make @safe the Default--Formal Assessment
On Thursday, 21 May 2020 at 20:46:09 UTC, Walter Bright wrote: On 5/21/2020 9:14 AM, Seb wrote: Why we can't we have a technical board where the community can vote in experts and potentially companies could even buy a seat for $$$ which would mean a lot more for them than the current very vague sponsorship options. I'm aware that Walter doesn't like the idea of giving up ownership, but it makes all the other people question why they should still bother with this process and not simply fork and move to an open, transparent development... I expected flak from this decision. I'm prepared to take the flak because this is the right decision. I did not make it lightly. That's interesting that you are saying it is the "right" decision. Let's analyze that for a second: What this boils down to is Simplicity Vs. Memory Safety Is the **correct** code actually simpler? A beginner that doesn't have the knowledge of D's safety system will ultimately create C bindings that are implicitly @safe without realizing the consequences of their actions. This change introduces a risk to memory safety, extern(C) declarations that were @system will now be flipped to @safe. No, putting @system: at the top isn't a solution, extern(C) functions aren't all nicely put in their own modules. Druntime and Phobos both have extern(C) declarations throughout their source; I guarantee you missed them with your PR's trying to illustrate how simple it is. As others will most definitely miss them as well. Reasons for Memory Safety: - Less error prone and simpler for beginners, the default is what the *correct* behavior should be. They organically discover @safe writing C bindings. - Less error prone for advanced users, won't accidentally call a C function that isn't explicitly verified as being @trusted. - Switch to @safe by default won't introduce potential security bugs from extern(C) functions not being annotated @system in the switch. - Proven implementation by other safe languages (Rust). Reasons for Simplicity: - simpler logic for the compiler - simpler rules for the user that default to *incorrect* code - Fear of the unknown, unforeseen complexity - trust Walter This is where the divide is, from my perspective. There's this fear of the unknown, that making it slightly more complicated will introduce these unforeseen complications that will far outweigh any benefit that is added from it. I don't see what that can be. There are other languages that have safe by default, and then have C declarations be unsafe by default. They don't have any of these devastation complications you seem to think that there will be. This is what doesn't sit right with me. If you could give an example of a complication that could occur, then I think you could get more people onboard. But it would have to be justifiable against the increased security risk of having extern(C) declarations be @safe by default. For a DIP that is trying to increase safety, it is a bit ironic that it will also be reducing safety at the same time. Otherwise right now, as it stands, this basically boils down to Logic Vs. Fear. Please keep in mind that I've made other unpopular decisions that have proven their worth over time. I hope you'll reserve judgement until we all see how this change plays out. If it does turn out badly, it's on me and I'll take my lumps. You've also done the opposite, you can't justify it with such a statement unless you've never made a mistake. This whole process is suppose to avoid exactly this; a single person taking a gamble.
Re: DIP 1028--Make @safe the Default--Formal Assessment
On Thursday, 21 May 2020 at 21:41:53 UTC, Steven Schveighoffer wrote: The unfortunate end result of this change is that safety will be gutted with all C functions being trusted by default I'm really sorry, Walter, but I have to agree with Steve on this point. This was the one aspect of the DIP that I really wanted to get modified, I also proposed a number of options for how to do so, and I'm really worried about the consequences of this decision. I recognize and respect your right to make decisions as you see fit for the language, but I really wish I could persuade you to change your mind about this one :-)
Re: DIP 1028--Make @safe the Default--Formal Assessment
On Thursday, 21 May 2020 at 20:48:18 UTC, Walter Bright wrote: On 5/21/2020 10:03 AM, bachmeier wrote: Walter makes decisions based on his mood on a particular day That's uncalled for. Regional variation in English? Translation: You make your decisions based on how you feel about the situation at a point in time. "Mood" is used because there's some subjectivity and "gut feel" involved in the decision. It's not intended to be negative, it's simply a description of how any human makes any decision. That's why I said the same about how a committee would make decisions.
Re: DIP 1028--Make @safe the Default--Formal Assessment
On Thursday, 21 May 2020 at 20:59:08 UTC, Walter Bright wrote: Many replies to you, Steven: https://digitalmars.com/d/archives/digitalmars/D/Discussion_Thread_DIP_1028--Make_safe_the_Default--Final_Review_336354.html I did not ignore you. I just didn't agree. One concern here is that these responses are scattered across different parts of a long discussion thread. So it probably would be a good idea for the acceptance to be accompanied by an explanation of what the major objections were to the DIP, and why they were discounted. It's not so different from the way that, at the end of a talk or presentation, it's a good idea to recap the key points that have already been covered.
Re: DIP 1028--Make @safe the Default--Formal Assessment
On 5/21/20 4:59 PM, Walter Bright wrote: On 5/21/2020 10:26 AM, Steven Schveighoffer wrote: Agree. I will not be participating in the DIP process from now on. It is a complete waste of time. Walter should just make the changes he wants and not bother with the facade of discussion. Many replies to you, Steven: https://digitalmars.com/d/archives/digitalmars/D/Discussion_Thread_DIP_1028--Make_safe_the_Default--Final_Review_336354.html Many unsatisfactory replies. Eventually my attempts to explain my position were ignored. It's the equivalent of walking off stage because you lost the debate, only to claim you won because you stopped talking. My points were straightforward, easy to understand, vastly agreed upon (and echoed) by all of the experienced people here (except you), and your rebuttals were extremely dubious, depending on hypothetical non-sequiturs with an imagined developer who doesn't understand how prototypes might work. Short story is, you made poor arguments and considered the matter closed "without comment". This is extremely unsatisfactory. I did not ignore you. I just didn't agree. You didn't agree, and that is your choice. But you also didn't address any of the points I made, instead choosing to focus on confusion from an imaginary person who has no clue why his safe code cannot call unsafe functions even though the attributes are not explicit (which means he should probably spend the 10 seconds to learn and become a better programmer). The unfortunate end result of this change is that safety will be gutted with all C functions being trusted by default, ironically by the person who is claiming that memory safety is of utmost importance, and how C got it wrong. All without delivering a single convincing argument as to why he is right. I even put forth a completely ignored compromise solution that would have solved the problem and allowed extern(C) functions to be considered @safe by default: https://digitalmars.com/d/archives/digitalmars/D/Discussion_Thread_DIP_1028--Make_safe_the_Default--Final_Review_336354.html#N336968 This is why I consider the process a waste of time, and why I'm done participating. -Steve
Re: DIP 1028--Make @safe the Default--Formal Assessment
On 5/21/2020 10:26 AM, Steven Schveighoffer wrote: Agree. I will not be participating in the DIP process from now on. It is a complete waste of time. Walter should just make the changes he wants and not bother with the facade of discussion. Many replies to you, Steven: https://digitalmars.com/d/archives/digitalmars/D/Discussion_Thread_DIP_1028--Make_safe_the_Default--Final_Review_336354.html I did not ignore you. I just didn't agree.
Re: DIP 1028--Make @safe the Default--Formal Assessment
On 5/21/2020 10:03 AM, bachmeier wrote: Walter makes decisions based on his mood on a particular day That's uncalled for.
Re: DIP 1028--Make @safe the Default--Formal Assessment
On 5/21/2020 11:36 AM, H. S. Teoh wrote: I'd even grant that Walter, being BFDL, can make whatever arbitrary decisions he wants, but at the very least acknowledge the existence of the rest of us. "Accepted without comment" amounts to denial that we even exist, considering how much feedback was given on this DIP. Even a "accepted in spite of community feedback" is better than "without comment". I've discussed it at length in the n.g. with y'all.
Re: DIP 1028--Make @safe the Default--Formal Assessment
On 5/21/2020 9:14 AM, Seb wrote: On Thursday, 21 May 2020 at 13:51:34 UTC, Mike Parker wrote: DIP 1028, "Make @safe the Default", has been accepted without comment. https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1028.md "without comment" - even though there were a lot of unaddressed problems :/ I did address, several times over, the problems in the discussion thread. Great! So what's the entire point of this process? To give people the illusion of progress and participation? Consider that several of my own DIPs were rejected due to community response. Why we can't we have a technical board where the community can vote in experts and potentially companies could even buy a seat for $$$ which would mean a lot more for them than the current very vague sponsorship options. I'm aware that Walter doesn't like the idea of giving up ownership, but it makes all the other people question why they should still bother with this process and not simply fork and move to an open, transparent development... I expected flak from this decision. I'm prepared to take the flak because this is the right decision. I did not make it lightly. Please keep in mind that I've made other unpopular decisions that have proven their worth over time. I hope you'll reserve judgement until we all see how this change plays out. If it does turn out badly, it's on me and I'll take my lumps.
Re: DIP 1028--Make @safe the Default--Formal Assessment
On Thu, May 21, 2020 at 05:49:27PM +, Paul Backus via Digitalmars-d-announce wrote: [...] > I think the real problem here is the lack of communication. As it > stands, we have no way to tell whether feedback was considered or > ignored, or what the ultimate rationale behind this decision was--we > can only speculate. I've said pretty much the same thing before, but it seems to have fallen on deaf ears. :-/ What's frustrating to the community isn't primarily the technical aspects (though of course, that's also a factor), but the human aspect of communication. Or rather, the lack thereof. I'd even grant that Walter, being BFDL, can make whatever arbitrary decisions he wants, but at the very least acknowledge the existence of the rest of us. "Accepted without comment" amounts to denial that we even exist, considering how much feedback was given on this DIP. Even a "accepted in spite of community feedback" is better than "without comment". (Maybe our virtual non-existence might ultimately become actual non-existence as this community shrinks to zero. :-P) > Even if we suppose for the sake of argument that the decision is sound > on a technical level, this is poor leadership, and bodes ill for the > future of the D language and its community. D excels at the technical aspects, but time and time again has shown that it lacks proper management / leadership. Contrary to my own inclinations I'm compelled to suggest hiring a *non-technical* person to take up the management/leadership roles (emphatically non-technical, because let's face it, we techies just don't have the people skillz it takes to do this properly), because the current situation clearly isn't working, and is quite detrimental to D and its future. T -- Computers shouldn't beep through the keyhole.
Re: DIP 1028--Make @safe the Default--Formal Assessment
On Thursday, 21 May 2020 at 17:49:27 UTC, Paul Backus wrote: On Thursday, 21 May 2020 at 17:03:49 UTC, bachmeier wrote: The problem as I see it is someone making a decision on his own DIP. That just doesn't make any sense to me, and I've stated that numerous times. Walter has a tendency to throw gas on the fire by ignoring much of the feedback and not spending time to understand the points others are making when he does respond. I really think you should have to convince *someone else* that your proposal is reasonable. In principle, at least, this is why we have two "language maintainers," Walter and Atila (previously, Walter and Andrei). There's a big difference between being part of a three-person committee discussing a proposal by Walter and working together with Walter to make a decision on his own proposal. It's certainly doesn't pass the smell test.
Re: DIP 1028--Make @safe the Default--Formal Assessment
On Thursday, 21 May 2020 at 17:03:49 UTC, bachmeier wrote: The problem as I see it is someone making a decision on his own DIP. That just doesn't make any sense to me, and I've stated that numerous times. Walter has a tendency to throw gas on the fire by ignoring much of the feedback and not spending time to understand the points others are making when he does respond. I really think you should have to convince *someone else* that your proposal is reasonable. In principle, at least, this is why we have two "language maintainers," Walter and Atila (previously, Walter and Andrei). I think the real problem here is the lack of communication. As it stands, we have no way to tell whether feedback was considered or ignored, or what the ultimate rationale behind this decision was--we can only speculate. Even if we suppose for the sake of argument that the decision is sound on a technical level, this is poor leadership, and bodes ill for the future of the D language and its community.
Re: DIP 1028--Make @safe the Default--Formal Assessment
On Thursday, 21 May 2020 at 13:51:34 UTC, Mike Parker wrote: DIP 1028, "Make @safe the Default", has been accepted without comment. https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1028.md As others have mentioned, this really is a farce. I understand that not everybody will be happy with every decision but the fact that there is not even a comment is just disrespectful towards all the people that put in a lot of effort to review the DIP. How can you seriously expect them to continue to do that if you treat them like this? Don't you think their work is valuable? If not, why bother with the DIP process at all? It just seems like a total waste of everybody’s time. I am really disappointed about this...
Re: DIP 1028--Make @safe the Default--Formal Assessment
On 5/21/20 12:14 PM, Seb wrote: On Thursday, 21 May 2020 at 13:51:34 UTC, Mike Parker wrote: DIP 1028, "Make @safe the Default", has been accepted without comment. https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1028.md "without comment" - even though there were a lot of unaddressed problems :/ Great! So what's the entire point of this process? To give people the illusion of progress and participation? Agree. I will not be participating in the DIP process from now on. It is a complete waste of time. Walter should just make the changes he wants and not bother with the facade of discussion. -Steve
Re: DIP 1028--Make @safe the Default--Formal Assessment
On Thursday, 21 May 2020 at 16:48:22 UTC, SashaGreat wrote: On Thursday, 21 May 2020 at 16:32:32 UTC, Adam D. Ruppe wrote: On Thursday, 21 May 2020 at 16:14:02 UTC, Seb wrote: Why we can't we have a technical board where the community can vote in experts and potentially companies could even buy a seat for $$$ which would mean a lot more for them than the current very vague sponsorship options. ditto, I think we should have like a seven person elected DIP committee who pass/fail things by majority vote. It is obvious to me that the current process is totally useless. Exactly and I even remember there was even a discussion about this on reddit (/r/programming) sometime ago where someone was pointing the flaws on D, and someone said the DIP process was one of them, and there were some known people around here replying that comment saying it was not the case. The discussion topic about this DIP (https://forum.dlang.org/thread/wkdpnzarkbtqryigh...@forum.dlang.org) had 210 replies, some concerns and in the end was ACCEPT WITHOUT ANY COMMENT. This is what I call a waste of everybody's time. Completely agree. The way DIPs are being handled is quite disappointing and unproductive. If the authors aren't even intending to address (or even acknowledge) difficult comments, why even write a DIP and have the community spend time on it at all? It also is not very encouraging to potential DIP authors who aren't Walter (or Átila or Andrei).
Re: DIP 1028--Make @safe the Default--Formal Assessment
On Thursday, 21 May 2020 at 16:14:02 UTC, Seb wrote: On Thursday, 21 May 2020 at 13:51:34 UTC, Mike Parker wrote: DIP 1028, "Make @safe the Default", has been accepted without comment. https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1028.md "without comment" - even though there were a lot of unaddressed problems :/ Great! So what's the entire point of this process? To give people the illusion of progress and participation? Why we can't we have a technical board where the community can vote in experts and potentially companies could even buy a seat for $$$ which would mean a lot more for them than the current very vague sponsorship options. I'm aware that Walter doesn't like the idea of giving up ownership, but it makes all the other people question why they should still bother with this process and not simply fork and move to an open, transparent development... I honestly don't know if that would help. We'd be moving from a system where Walter makes decisions based on his mood on a particular day to one where others make decisions based on their moods on a particular day. The only thing worse than letting one person choose what to implement is having a group of people choose what to implement. Everyone has their own view of what is important. In my case, it's beginners and appealing to less technical users. Others view 20-year C++ programmers that specialize in performance optimizations as the only ones that matter. Needless to say, there's not a lot of overlap in the set of changes we think make sense. No matter who is making the decisions, the tradeoff between ease of use and technical awesomeness will continue to exist. The problem as I see it is someone making a decision on his own DIP. That just doesn't make any sense to me, and I've stated that numerous times. Walter has a tendency to throw gas on the fire by ignoring much of the feedback and not spending time to understand the points others are making when he does respond. I really think you should have to convince *someone else* that your proposal is reasonable.
Re: DIP 1028--Make @safe the Default--Formal Assessment
On Thursday, 21 May 2020 at 16:32:32 UTC, Adam D. Ruppe wrote: On Thursday, 21 May 2020 at 16:14:02 UTC, Seb wrote: Why we can't we have a technical board where the community can vote in experts and potentially companies could even buy a seat for $$$ which would mean a lot more for them than the current very vague sponsorship options. ditto, I think we should have like a seven person elected DIP committee who pass/fail things by majority vote. It is obvious to me that the current process is totally useless. Exactly and I even remember there was even a discussion about this on reddit (/r/programming) sometime ago where someone was pointing the flaws on D, and someone said the DIP process was one of them, and there were some known people around here replying that comment saying it was not the case. The discussion topic about this DIP (https://forum.dlang.org/thread/wkdpnzarkbtqryigh...@forum.dlang.org) had 210 replies, some concerns and in the end was ACCEPT WITHOUT ANY COMMENT. This is what I call a waste of everybody's time. SG.
Re: DIP 1028--Make @safe the Default--Formal Assessment
On Thursday, 21 May 2020 at 16:14:02 UTC, Seb wrote: Why we can't we have a technical board where the community can vote in experts and potentially companies could even buy a seat for $$$ which would mean a lot more for them than the current very vague sponsorship options. ditto, I think we should have like a seven person elected DIP committee who pass/fail things by majority vote. It is obvious to me that the current process is totally useless.
Re: DIP 1028--Make @safe the Default--Formal Assessment
On Thursday, 21 May 2020 at 13:51:34 UTC, Mike Parker wrote: DIP 1028, "Make @safe the Default", has been accepted without comment. https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1028.md "without comment" - even though there were a lot of unaddressed problems :/ Great! So what's the entire point of this process? To give people the illusion of progress and participation? Why we can't we have a technical board where the community can vote in experts and potentially companies could even buy a seat for $$$ which would mean a lot more for them than the current very vague sponsorship options. I'm aware that Walter doesn't like the idea of giving up ownership, but it makes all the other people question why they should still bother with this process and not simply fork and move to an open, transparent development...
Re: DIP 1028--Make @safe the Default--Formal Assessment
On Thursday, 21 May 2020 at 13:51:34 UTC, Mike Parker wrote: DIP 1028, "Make @safe the Default", has been accepted without comment. https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1028.md I guess they be more open to dips that fixes holes in the "safe by default" feature then.
Re: DIP 1028--Make @safe the Default--Formal Assessment
On 21.05.20 15:51, Mike Parker wrote: DIP 1028, "Make @safe the Default", has been accepted without comment. just another brick in the wall
DIP 1028--Make @safe the Default--Formal Assessment
DIP 1028, "Make @safe the Default", has been accepted without comment. https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1028.md
