November 19, 2021
On Thursday, 18 November 2021 at 23:51:09 UTC, SealabJaster wrote:
> "fuck it, let's just scrap it so everyone looses out instead"

Ding, ding, ding!  I think you just stumbled on D's new motto :)
November 19, 2021
On Thursday, 18 November 2021 at 17:52:44 UTC, H. S. Teoh wrote:
>
> Exactly what I said.  The day will come when the world realizes just how much of a liability an inherently-unsafe language is, and how much it's costing businesses, and the tables will turn.
>
>
> T

unsafe really is subjective (and we can learn this fact from observing how different countries, and different people dealt with the pandemic). There is a tolerance for risk, always, up to a point.

In anycase... C has, and will always have, value.

I like this statement below:

"..because we see everything with its real nature in C"
- quoted from: https://forum.dlang.org/post/vfsxzwrieivwqipicgka@forum.dlang.org

Any langauge that tries to improve on C, no matter how worthwhile the effort, is inherently deceptive.

November 18, 2021
On Thu, Nov 18, 2021 at 11:51:09PM +0000, SealabJaster via Digitalmars-d wrote:
> On Thursday, 18 November 2021 at 17:52:44 UTC, H. S. Teoh wrote:
> > Exactly what I said.  The day will come when the world realizes just how much of a liability an inherently-unsafe language is, and how much it's costing businesses, and the tables will turn.
[...]
> A shame we didn't get @safe by default pushed through, because (from
> what I recall) extern(C) functions were for some reason also
> considered @safe by default, which caused too much backlash.
[...]

Honestly, it was a big loss for D that @safe by default failed to get through simply due to such a small detail. IMO the benefits of @safe by default far exceed any squabble we may have over how extern(C) functions should behave.

Still, @safe itself leaves much to be desired:

	https://issues.dlang.org/buglist.cgi?keywords=safe&list_id=238237&resolution=---

It's not bad in its current state, but could be so much more had a more complete job been done.

The fact that it's implemented as a blacklist rather than a whitelist also means that there are likely many holes in it that we just haven't found yet.  What should've been done, is to implement it as a whitelist, and then each time somebody gets blocked by @safe for something that's actually safe, we can review it and conservatively expand the whitelist. With a blacklist implementation, it's anybody's guess where in the exponentially-many combinations of language features there might be loopholes in @safe, which is a far less tractible problem.

(Yes, a blacklist implementation and a whitelist implementation will eventually both converge to the same thing.  But a blacklist implementation will continue to have loopholes until it converges, whereas a whitelist implementation is guaranteed safe, with only the occasional inconvenience when a valid operation is wrongly blocked. When it comes to memory safety and potential security exploits, it's always better to err on the safe side.)


T

-- 
Don't throw out the baby with the bathwater. Use your hands...
November 19, 2021
On Friday, 19 November 2021 at 00:03:39 UTC, Greg Strong wrote:
> On Thursday, 18 November 2021 at 23:51:09 UTC, SealabJaster wrote:
>> "fuck it, let's just scrap it so everyone looses out instead"
>
> Ding, ding, ding!  I think you just stumbled on D's new motto :)

Depressingly true :D
November 19, 2021
On Friday, 19 November 2021 at 00:09:20 UTC, H. S. Teoh wrote:
> ...

I wonder if we should rename the language to "swiss cheese" considering the amount of holes we have.
November 19, 2021
On 19.11.21 01:08, forkit wrote:
> On Thursday, 18 November 2021 at 17:52:44 UTC, H. S. Teoh wrote:
>>
>> Exactly what I said.  The day will come when the world realizes just how much of a liability an inherently-unsafe language is, and how much it's costing businesses, and the tables will turn.
>>
>>
>> T
> 
> unsafe really is subjective (and we can learn this fact from observing how different countries, and different people dealt with the pandemic). There is a tolerance for risk, always, up to a point.
> 
> In anycase... C has, and will always have, value.
> 
> I like this statement below:
> 
> "..because we see everything with its real nature in C"
> - quoted from: https://forum.dlang.org/post/vfsxzwrieivwqipicgka@forum.dlang.org
> 
> Any langauge that tries to improve on C, no matter how worthwhile the effort, is inherently deceptive.
> 

I think that statement itself is deceptive. C is not all that close to how modern hardware actually operates.
November 18, 2021
On Fri, Nov 19, 2021 at 12:35:49AM +0000, SealabJaster via Digitalmars-d wrote:
> On Friday, 19 November 2021 at 00:09:20 UTC, H. S. Teoh wrote:
> > ...
> 
> I wonder if we should rename the language to "swiss cheese" considering the amount of holes we have.

No, cheese grater. :-P


T

-- 
Making non-nullable pointers is just plugging one hole in a cheese grater. -- Walter Bright
November 19, 2021
On Friday, 19 November 2021 at 00:38:15 UTC, Timon Gehr wrote:
>
> I think that statement itself is deceptive. C is not all that close to how modern hardware actually operates.

I mean the abstraction of the C memory model...

i.e. " ..one or more contiguous sequences of bytes. Each byte in memory has a unique address." This is still an appropriate abstraction, even in modern times.

When working at a low-level, this is still, even today, an appropriate and suitable abstraction, on which to build your ideas.

No language can model 'actual hardware', and even if it could, the human brain could never use such a language.


November 19, 2021
On 19.11.21 03:36, forkit wrote:
> On Friday, 19 November 2021 at 00:38:15 UTC, Timon Gehr wrote:
>>
>> I think that statement itself is deceptive. C is not all that close to how modern hardware actually operates.
> 
> I mean the abstraction of the C memory model...
> 
> i.e. " ..one or more contiguous sequences of bytes. Each byte in memory has a unique address." This is still an appropriate abstraction, even in modern times.
> ...

Depends on what you want to do.

> When working at a low-level, this is still, even today, an appropriate and suitable abstraction, on which to build your ideas.
> ...

Debatable, but this is not even what C gives you, so...

> No language can model 'actual hardware', and even if it could, the human brain could never use such a language.
> 
> 

You are moving the goalposts. There were two statements:

- "..because we see everything with its real nature in C"
- "Any langauge that tries to improve on C, no matter how worthwhile the effort, is inherently deceptive."

Those are not useful statements. They are not true.
November 19, 2021
On Friday, 19 November 2021 at 02:36:31 UTC, forkit wrote:
> Each byte in memory has a unique address.

This is not true and has never been true, at least in the x86 world.