On Wed, 27 Dec 2017 08:36:13 +0000, codephantom wrote:

> btw. I'd like to see D 3.x introduce a breaking change and make @safe the default, instead of @system. I think that would be huge boost for D going forward.
> 
> How practical that is, I would have no idea.
> 
> But as an 'end user' of D, I would prefer to have to explicitely mark code as @system, rather than have to explicitely mark code as @safe, and therefore having to find tools that help me check whether I 'forgot' to do that.


I used to agree. For people that use @safe religiously, a tool could easily fix the breakage (it's just a toggle), and for most others the tool could still fix everything, though with a little more work. But it's so easy to do this now without breaking anything.

```
module mymodule; @safe:

@system
class ABC {
    int func(int* p, size_t len) {
        return p[0] + p[1];
    }
}

string thisIsSafe() { return "Yay!"; }
```

I actually like requiring the explicit @safe at the module declaration now; it tells other programmers "I intend this module to be memory-@safe"; you just need a quick grep for @system and @trusted to find exceptions.

Sure, that expression of intention wouldn't be necessary if it were default, but I don't really see the benefit in changing it now. People who care will add the attribute, people that don't care, won't; knowing the programmer's intention can be useful, too.

On Tue, 26 Dec 2017 14:54:14 -0800, Walter Bright wrote:

> On 12/26/2017 1:03 AM, Paolo Invernizzi wrote:
>> The point is that the presence of one @safe: line in the module can be mechanically checked, over one million devs working on a codebase.
>> 
>> The whole point of Walter argumentation is 'mechanically'.
> 
> That's right. C++ is based on faith in the programmer using best practices. D is not based on faith, it can be automatically checked.


If the programmer opts-in to those checks... it's a +1 for pragmatism but does make marketing the language a bit weird -- one-liners spawn objections to the integrity of the claim (such as a portion of this thread; if there are objections within the community, how much more will we find objections outside it!).

When I hear someone talk about a memory-safe language (especially as a major feature), I do think memory-safe by default. The thing is, D does have support for memory-safety by default (bound-checked arrays, etc.), and allows you to opt-in to greater safety guarantees; but that's not what many think of when they think memory-safe (it doesn't really help that every language provides their own, slightly different, definition).

And D has faith that programmers using @trusted know what they're doing (for both writing and calling the function). There is no avoiding trust in a useful language.

On Wednesday, 27 December 2017 at 15:37:22 UTC, rjframe wrote:
> On Tue, 26 Dec 2017 14:54:14 -0800, Walter Bright wrote:
>
>> On 12/26/2017 1:03 AM, Paolo Invernizzi wrote:
>>> The point is that the presence of one @safe: line in the module can be mechanically checked, over one million devs working on a codebase.
>>> 
>>> The whole point of Walter argumentation is 'mechanically'.
>> 
>> That's right. C++ is based on faith in the programmer using best practices. D is not based on faith, it can be automatically checked.
>
>
> If the programmer opts-in to those checks... it's a +1 for pragmatism but does make marketing the language a bit weird -- one-liners spawn objections to the integrity of the claim (such as a portion of this thread; if there are objections within the community, how much more will we find objections outside it!).
>
> When I hear someone talk about a memory-safe language (especially as a major feature), I do think memory-safe by default. The thing is, D does have support for memory-safety by default (bound-checked arrays, etc.), and allows you to opt-in to greater safety guarantees; but that's not what many think of when they think memory-safe (it doesn't really help that every language provides their own, slightly different, definition).
>
> And D has faith that programmers using @trusted know what they're doing (for both writing and calling the function). There is no avoiding trust in a useful language.

I prefer pragmatism over marketing all the times.

If I was a company evaluating a language, I would notice that my safety goal can be reached right today:

- the language guarantees that pieces of written code are memory safe.
- there are plenty of easy way to force that, during the development process.
- there's the possibility to escape this safety net to gain flexibility, and such part of the code can by easily searched and peer reviewed for memory corruption problems.

That's a big, big advancement compared to the status quo (C/C++).

It's difficult for me to comprehend why a company should not take advantage of it, if it cares about memory safety, only because @safe is not the default: that's a really _minor_ issue, compared to the gain of having the work done.

/Paolo

On Wed, 2017-12-27 at 02:13 -0800, Walter Bright via Digitalmars-d
wrote:
[…]
> 
> Builtin unittests and Ddoc, for example. There's a big psychological
> advantage
> to having them built in rather than requiring an external tool. The
> closeness to
> C syntax is no accident, for another.
> 
> I've been in the compiler biz since the early 80s, working with
> customers, doing
> tech support. That results in experience in what works for people and
> what
> doesn't, even if it is not scientific or better from a CS point of
> view.

This does not support the original claim that the design of D by you is based on psychology. It may be based on your perception of other programmers needs, which is fine per se, but that is not psychology- based design.

-- 
Russel.
==========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Wed, 2017-12-27 at 00:13 +0000, codephantom via Digitalmars-d wrote: […]
> As such, as better and more realistic marketing campaign would promote D as being primarily a flexible language, with 'safe' features you can make use of, if you need them, some of which are on by default, and some which are not.

So remove the @safe annotation because everything is safe by default
and introduce an @unsafe annotation to deal with the cases where lack
of safety is required. Hummm… isn't that exactly what Rust has done?

-- 
Russel.
==========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Tue, 2017-12-26 at 14:54 -0800, Walter Bright via Digitalmars-d
wrote:
[…]
> That's right. C++ is based on faith in the programmer using best
> practices. D is
> not based on faith, it can be automatically checked.

"Can be" is not the same as "is". Perhaps all D compilers should enforce the "can be" as "is", with options to switch it off if need be? This is the route Rust is going, and it has great benefits exactly because C and C++ do not do this.

-- 
Russel.
==========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Wednesday, 27 December 2017 at 07:44:30 UTC, Walter Bright wrote:
> On 12/26/2017 4:18 AM, Russel Winder wrote:
>> All of which brings us full circle: when it comes to programming
>> languages and software development, it is all about advocacy,
>> prejudice, and belief, there is very, very little science happening –
>> and most of the science that is happening is in the psychology of
>> programming, about which most developers of programming languages know
>> nothing.
>
> If you're hinting that I know nothing about the topic, you're mistaken :-)
>
> A fair amount of D's design is based on psychology.

I'd love to hear more about this sometime.  I think that's what people who assess languages based on checklists miss - it's the gestalt of the features and how they are organised and the consequence of this for the pattern of the code as it emerges, rather than particular tickbox features that's appealing.  (I agree with code phantom that an adaptation to how people chunk is one of those benefits).

On Wednesday, 27 December 2017 at 15:37:22 UTC, rjframe wrote:
>
>
> And D has faith that programmers using @trusted know what they're doing (for both writing and calling the function). There is no avoiding trust in a useful language.

I'm just playing devil's advocate.  Faith is something best left to priests not engineers. There is a lot of value in code for critical systems in having the compiler enforcing safe constructs by default. And still trust you enough to let it disable where it counts without writing a Tolstoi novel. It is the sane default.

But unfortunately socially people feel different. If safe would be the default, they would feel like the government robed them of their right to free speech or confiscated their property. The aversion to safety in a programming language is nothing but one of the countless way in which fear to be robbed of "free will" manifests. An unjustified fear after all, for so much of your free will is already so limited.

No hacker language == no success.

On Wednesday, 27 December 2017 at 16:29:02 UTC, Russel Winder wrote:
> On Wed, 2017-12-27 at 02:13 -0800, Walter Bright via Digitalmars-d
> wrote:
> […]
>> 
>> Builtin unittests and Ddoc, for example. There's a big psychological
>> advantage
>> to having them built in rather than requiring an external tool. The
>> closeness to
>> C syntax is no accident, for another.
>> 
>> I've been in the compiler biz since the early 80s, working with
>> customers, doing
>> tech support. That results in experience in what works for people and
>> what
>> doesn't, even if it is not scientific or better from a CS point of
>> view.
>
> This does not support the original claim that the design of D by you is based on psychology. It may be based on your perception of other programmers needs, which is fine per se, but that is not psychology- based design.

That's like saying the way George Soros trades is not based on psychology because he doesn't refer to the literature in making and articulating his decision-making process.  Instead people write papers about how he thinks, because it's not yet in the literature!

If published knowledge were what was most important or valuable then anyone intelligent with an interest in a subject would be part of a war of all against all, because how is it possible to have an edge?  But I don't think human expertise can be described in that manner.  Karl Polanyi's work is quite interesting:

https://en.wikipedia.org/wiki/Tacit_knowledge

On Wednesday, 27 December 2017 at 16:44:25 UTC, Laeeth Isharc wrote:
> On Wednesday, 27 December 2017 at 16:29:02 UTC, Russel Winder wrote:
>> On Wed, 2017-12-27 at 02:13 -0800, Walter Bright via Digitalmars-d
>> wrote:
>> […]
>>> 
>>> Builtin unittests and Ddoc, for example. There's a big psychological
>>> advantage
>>> to having them built in rather than requiring an external tool. The
>>> closeness to
>>> C syntax is no accident, for another.
>>> 
>>> I've been in the compiler biz since the early 80s, working with
>>> customers, doing
>>> tech support. That results in experience in what works for people and
>>> what
>>> doesn't, even if it is not scientific or better from a CS point of
>>> view.
>>
>> This does not support the original claim that the design of D by you is based on psychology. It may be based on your perception of other programmers needs, which is fine per se, but that is not psychology- based design.
>
> That's like saying the way George Soros trades is not based on psychology because he doesn't refer to the literature in making and articulating his decision-making process.  Instead people write papers about how he thinks, because it's not yet in the literature!
>
> If published knowledge were what was most important or valuable then anyone intelligent with an interest in a subject would be part of a war of all against all, because how is it possible to have an edge?  But I don't think human expertise can be described in that manner.  Karl Polanyi's work is quite interesting:
>
> https://en.wikipedia.org/wiki/Tacit_knowledge

On Soros:
http://marketfocusing.com/downloads/soros.pdf