May 27, 2020 Greenwashing | ||||
---|---|---|---|---|
| ||||
From https://www.investopedia.com/terms/g/greenwashing.asp, the top Google search result: Greenwashing is the process of conveying a false impression or providing misleading information about how a company's products are more environmentally sound. Greenwashing is considered an unsubstantiated claim to deceive consumers into believing that a company's products are environmentally friendly. Paraphrasing for our context: Greenwashing is the process of conveying a false impression or providing misleading information about how a codebase is more memory-safe. Greenwashing is considered an unsubstantiated claim to deceive readers into believing that a codebase is memory-safe. If this is greenwashing, then DIP 1028 is doing it. |
May 27, 2020 Re: Greenwashing | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On Wednesday, 27 May 2020 at 11:37:17 UTC, Andrei Alexandrescu wrote:
> From https://www.investopedia.com/terms/g/greenwashing.asp, the top Google search result:
>
> Greenwashing is the process of conveying a false impression or providing misleading information about how a company's products are more environmentally sound. Greenwashing is considered an unsubstantiated claim to deceive consumers into believing that a company's products are environmentally friendly.
>
> Paraphrasing for our context:
>
> Greenwashing is the process of conveying a false impression or providing misleading information about how a codebase is more memory-safe. Greenwashing is considered an unsubstantiated claim to deceive readers into believing that a codebase is memory-safe.
>
> If this is greenwashing, then DIP 1028 is doing it.
I think you're right - unless D has a thorough, rigorously specified static analysis this will be the case (At zero cost, at least).
The current efforts to add that seem like they go in the right direction, but I feel like they'll have to have a breaking semantic/syntax change at some point (e.g. the way rust handles references seems much more decidable).
FWIW: There's need to be a thorough design first, the current approach to safety seems to spread among dmd like an octopuses tentacles. However, talk is cheap so I'm not complaining about what we have so far.
|
May 27, 2020 Re: Greenwashing | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On Wednesday, 27 May 2020 at 11:37:17 UTC, Andrei Alexandrescu wrote:
> Paraphrasing for our context:
>
> Greenwashing <...>
I propose safewashing
|
May 27, 2020 Re: Greenwashing | ||||
---|---|---|---|---|
| ||||
Posted in reply to welkam | On 5/27/20 5:25 AM, welkam wrote:
> On Wednesday, 27 May 2020 at 11:37:17 UTC, Andrei Alexandrescu wrote:
>> Paraphrasing for our context:
>>
>> Greenwashing <...>
>
> I propose safewashing
The bikeshed should clearly be green! ;)
|
May 27, 2020 Re: Greenwashing | ||||
---|---|---|---|---|
| ||||
Posted in reply to welkam | On Wednesday, 27 May 2020 at 12:25:48 UTC, welkam wrote:
> On Wednesday, 27 May 2020 at 11:37:17 UTC, Andrei Alexandrescu wrote:
>> Paraphrasing for our context:
>>
>> Greenwashing <...>
>
> I propose safewashing
There's also what I call "digital washing". The process for a tech company to advertise how repespectful it is toward privacy and consumer data or how friendly it is toward open source software. Digital washing also includes Green washing when the company advertises that their datacenter use solar energy for example.
|
May 27, 2020 Re: Greenwashing | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On Wednesday, May 27, 2020 5:37:17 AM MDT Andrei Alexandrescu via Digitalmars- d wrote:
> From https://www.investopedia.com/terms/g/greenwashing.asp, the top
> Google search result:
>
> Greenwashing is the process of conveying a false impression or providing misleading information about how a company's products are more environmentally sound. Greenwashing is considered an unsubstantiated claim to deceive consumers into believing that a company's products are environmentally friendly.
>
> Paraphrasing for our context:
>
> Greenwashing is the process of conveying a false impression or providing misleading information about how a codebase is more memory-safe. Greenwashing is considered an unsubstantiated claim to deceive readers into believing that a codebase is memory-safe.
>
> If this is greenwashing, then DIP 1028 is doing it.
Indeed.
A number of us have argued with Walter that DIP 1028 turns @safe into a lie and that the compiler should _never_ treat anything as @safe unless it can mechanicaly verify it or the programmer has explicitly marked it with @trusted. But for some reason, he thinks that having a "special rule" that non-extern(D) function declarations aren't treated as @safe by default like all of the functions that the compiler can actually mechanically verify adds too much complexity to the language. @safe isn't necessarily a problem, but @safe shouldn't have a huge blown in it in the process.
Based on some of Walter's comments, it also sounds like he intends to make nothrow the default in another DIP, which is also a terrible idea. I'm increasingly worried about the future of D with some of where these DIPs are going.
- Jonathan M Davis
|
May 27, 2020 Re: Greenwashing | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | On Wednesday, 27 May 2020 at 18:50:50 UTC, Jonathan M Davis wrote:
>I'm increasingly worried about the future
> of D with some of where these DIPs are going.
>
> - Jonathan M Davis
I foresee three things that could happen :
1. People get annoyed and stop using D.
2. Tools and editor features(think like dfmt) are added that slap @system everywhere unless @safe or @trusted is specified.(the most probable in my opinion)
3. DMD gets forked and/or third party compilers keep @system as default
No matter what ends up happening i think there is reason to worry...
|
May 27, 2020 Re: Greenwashing | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | On 5/27/20 2:50 PM, Jonathan M Davis wrote:
> Based on some of Walter's comments, it also sounds like he intends to make
> nothrow the default in another DIP, which is also a terrible idea. I'm
> increasingly worried about the future of D with some of where these DIPs are
> going.
In general, I think @safe, nothrow, @nogc, and pure by default have some benefits on code that is actually compiled by a D compiler. Simply because most of the time, code you write is generally in these categories, but isn't marked as such.
Imagine instead of any of this, you simply wrote all functions that are not marked as no-arg templates. This would change nothing (only one symbol is generated anyway, Stefan), but provide a much better experience for users who care about certain attributes.
Perhaps instead of making these things the default, we instead made *inference* the default. Then we could have something like @noinfer (please, this is not a proposal, don't focus on the name) which would declare that you intend to make this something that the source code will not be available.
Perhaps the focus on "X by default" is just looking at the wrong aspect.
-Steve
|
May 27, 2020 Re: Greenwashing | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | On Wednesday, 27 May 2020 at 18:50:50 UTC, Jonathan M Davis wrote:
> Based on some of Walter's comments, it also sounds like he intends to make nothrow the default in another DIP, which is also a terrible idea. I'm increasingly worried about the future of D with some of where these DIPs are going.
>
> - Jonathan M Davis
What's wrong with nothrow by default? Probably 97% of code doesn't need to throw exceptions.
|
May 27, 2020 Re: Greenwashing | ||||
---|---|---|---|---|
| ||||
Posted in reply to Meta | On Wednesday, May 27, 2020 5:57:00 PM MDT Meta via Digitalmars-d wrote:
> On Wednesday, 27 May 2020 at 18:50:50 UTC, Jonathan M Davis wrote:
> > Based on some of Walter's comments, it also sounds like he intends to make nothrow the default in another DIP, which is also a terrible idea. I'm increasingly worried about the future of D with some of where these DIPs are going.
> >
> > - Jonathan M Davis
>
> What's wrong with nothrow by default? Probably 97% of code doesn't need to throw exceptions.
If anything, I would say the opposite.
In general, exceptions are by far the best way to deal with error conditions that we have. They clean up code considerably and make it much harder for error conditions to be ignored or eaten. Alternatives such as error code are terrible in comparison. We do end up with far less code being able to be nothrow in D than we should because of how autodecoding works, but it's still the case that _way_ more than 97% of the code out there is going to potentially throw exceptions - especially in applications that have to deal with users and/or the network. Propagating error conditions without exceptions gets disgusting fast.
There's no question that there is code that cannot afford the extra cost of exception handling and has to do something else, but it's much more error-prone and isn't the norm for programs in general. And of course, in some cases, exceptions just plain don't make sense (e.g. the fact that std.utf.validate throws instead of returning bool is terrible), so it's not like they're always the appropriate solution or used correctly. However, in general, they most definitely should be the default for how your typical application deals with error conditions. Anything else leads to far more bugs. I would have thought that the experience of the programming community at large at this point would make that pretty clear. Exceptions are by no means perfect, but for the general case, they're the best way that we have to cleanly propagate error conditions and avoid having error conditions be ignored or lost.
Having nothrow be the default would encourage people to not use exceptions (leading to worse code in general) and would result in a _lot_ more attributes being needed on the code that does use exceptions. Certainly, I know that for the libraries and applications that I've worked on for most of my career (be it in D or some other language), if nothrow were the default, those libraries and applications would have to be marking throw all over the place (which is in fact basically what happens in Java, though they have they extra annoyance of having to mark _which_ exception types can be thrown, which has proven to be a terrible idea and which we fortunately have avoided in D).
I think that it's great that we have nothrow for those cases where it's appropriate, but I don't think that it makes sense at all to assume that that's the _normal_ situation.
In any case, when the topic has come up before, plenty of people have raised similar complaints to mine, so if/when Walter puts forth a DIP proposing nothrow to be the default as I think that he's planning on doing, I expect that he'll get quite a few dissenting opinions on it - likely far more than for making @safe the default. Of course, since he won't listen when pretty much everyone else disagrees with him on what to do with extern(C) with @safe being the default, who knows how well _that_ will go...
- Jonathan M Davis
|
Copyright © 1999-2021 by the D Language Foundation