safety model in D

[Leandro Lucarella]

Andrei Alexandrescu, el  5 de noviembre a las 09:57 me escribiste:
> Leandro Lucarella wrote:
> >Andrei Alexandrescu, el  5 de noviembre a las 08:48 me escribiste:
> >>First off: _all_ languages except C, C++, and assembler are or at
> >>least claim to be safe. All. I mean ALL. Did I mention all? If that
> >>was some ideology that is not realistic, is extremely difficult to
> >>achieve, and ends up too painful to use, then such theories would be
> >>difficult to corroborate with "ALL". Walter and I are in agreement
> >>that safety is not difficult to achieve in D and that it would allow
> >>a great many good programs to be written.
> >
> >I think the problem is the cost. The cost for the programmer (the subset
> >of language features it can use is reduced) and the cost for the compiler
> >(to increase the subset of language features that can be used, the
> >compiler has to be much smarter).
> >
> >Most languages have a lot of developers, and can afford making the
> >compiler smarter to allow safety with a low cost for the programmer (at
> >least when writing code, that cost might be higher performance-wise).
> 
> D is already a rich superset of Java. So the cost of making the
> language safe and useful was already absorbed.

That's an unfair comparison. Java has a very efficient GC (partially
because of safety), so using D as it were Java yields very inefficient
programs (using classes and new all over the places). D can't be
completely safe and because of that, it's doomed to have a quite worse GC,
so writing code a la Java in D beats the purpose of using D in the first
place.

> >A clear example of this, is not being able to take the address of a local.
> >This is too restrictive to be useful, as you pointed in you post about
> >having to write static methods because of this. If you can't find
> >a workaround for this, I guess safety in D can look a little unrealistic.
> 
> Most other languages do not allow taking addresses of locals. Why
> are they realistic and SafeD wouldn't? Just because we know we could
> do it in unsafe D?

Because in other languages there are no locals! All objects are references
and allocated in the heap (except, maybe, some value types). Again, you
can do that in D too, but because D is a system language, you can't assume
a lot of things and it has a lot less optimization opportune ties,
yielding bad performance when not used wisely.

> >I like the idea of having a safe subset in D, but I think being
> >a programming language, *runtime* safety should be *always* a choice for
> >the user compiling the code.
> 
> Well in that case we need to think again about the command-line options.

Not necessarily, -release is already there =)

But then, I don't have any issues with the GCC-way of hundreds of compiler
flags to have fine grained control, so I'm all for adding new flags for
that.

> >As other said, you can never be 100% sure your program won't blow for
> >unknown reasons (it could do that because a bug in the
> >compiler/interpreter, or even because a hardware problem), you can just
> >try to make it as difficult as possible, but 100% safety doesn't exist.
> 
> I understand that stance, but I don't find it useful.

The usefulness is that D can't be 100% safe, so spending time in trying to
make it that way (specially at the expense of flexibility, i.e., don't
providing a way to disable bound-checking in safe modules) makes no sense.
You'll just end up with a less efficient Java.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
The average person laughs 13 times a day