Will you permit some questions and observations from a D newbie-to-be?  (Well, maybe it's a soapbox or a challenge, but you can decide.)  I'm thinking of using D, and I like what I see so far.  Still, I have some fundamental questions that I think are essential measures of the quality of a programming language.  I think most of the answers are "right", but I'd rather hear them from this community.

1. Is it safe?  By that I mean, is it completely type-safe, even across compiled modules?  Are memory violations possible?  Is pointer arithmetic allowed?  Is the compiler capable of ensuring that all the rules of the language are followed?  Are array subscript bounds always checked at run time?  (I will allow that maybe it is necessary to turn this off in rare instances for lengthy computations.  And yes, I know, probably nothing is completely safe.)

It seems to me that if memory and type violations are possible, they will occur. Your own programs will not be as reliable as they could be, and if you use a second- or third-party library, you can never be sure it won't crash and leave you with the wreckage.


2. Is it simple?  I really like the philosophy of simplicity espoused on the home page.  Maybe I'm mistaken, but I think I detect a certain pressure for creeping featuritis.  If I can violate the rule against programming religion, I would say, please, please keep the language simple.  All-powerful, but as simple as possible.  And resist dialects at all costs.  My support goes to those of you who have consistently advocated simplicity.

Please permit me some observations, if you will.  Programming is only part of my job.  Although I'm not a professional programmer, as such, my programs have to be right, and have to give the right answers, or I'm out of business.

My preferred language so far is Pascal -- you heard me right.  It's not without problems, but when I started writing in Pascal, Fortran could not do the job, and C++ was vaporware.  I also judged C and C++ to be dangerous, and apparently the creators of D agree.  The interesting thing is that my very first, crude Pascal program (about 1700 lines + communications libraries) has performed complicated instrument-control functions flawlessly, day and night, for 15+ years.  (Well, actually, two errors surfaced during that time, but only two.)  I can't remember ever writing a program with a memory violation (and yes, I use pointers and OOP), and my programs almost always work right with little debugging.  I attribute success not to programming prowess, but to the simplicity and clarity of the language.

I would like to pass on one other observation.  There is a programmer who has been using Component Pascal (an Oberon variant) extensively for a few years. (I'm not really advocating that, for irrelevant reasons.)  The compiler and environment are written in the same language.  The point is that he claims that he has made just about every kind of mistake possible, including dangling pointers, subtle type conversion errors -- you name it -- but he has not had a single crash.  Maybe some infinite loops or other errors, but no memory violations or type errors.

The $64 question:  can you match the simplicity and safety?  Please tell me you can!

"Rex Couture spamdump" <auser@levee.wustl.edu> wrote in message news:ahrvec$2tdm$1@digitaldaemon.com...
> Will you permit some questions and observations from a D newbie-to-be?

Sure! Fire away.

> 1. Is it safe?  By that I mean, is it completely type-safe, even across
compiled
> modules?

Yes.

>  Are memory violations possible?  Is pointer arithmetic allowed?

Yes, and yes.

>  Is
> the compiler capable of ensuring that all the rules of the language are
> followed?

No, although I try to note these areas in the spec.

>  Are array subscript bounds always checked at run time?

No, it is enabled/disabled with a compiler switch. D requires that programs not be coded in such a manner that they *depend* on array bounds checking (this is different from Java).

> It seems to me that if memory and type violations are possible, they will
occur.
> Your own programs will not be as reliable as they could be, and if you use
a
> second- or third-party library, you can never be sure it won't crash and
leave
> you with the wreckage.

That's correct. On the other hand, D makes it largely unnecessary to use practices that commonly lead in C to corrupted memory. An example is 'out' parameters for functions.

> 2. Is it simple?  I really like the philosophy of simplicity espoused on
the
> home page.  Maybe I'm mistaken, but I think I detect a certain pressure
for
> creeping featuritis.  If I can violate the rule against programming
religion, I
> would say, please, please keep the language simple.  All-powerful, but as
simple
> as possible.  And resist dialects at all costs.  My support goes to those
of you
> who have consistently advocated simplicity.

Where to draw that line between features and simplicity will make or break D.

> My preferred language so far is Pascal -- you heard me right.  It's not
without
> problems, but when I started writing in Pascal, Fortran could not do the
job,
> and C++ was vaporware.  I also judged C and C++ to be dangerous, and
apparently
> the creators of D agree.  The interesting thing is that my very first,
crude
> Pascal program (about 1700 lines + communications libraries) has performed complicated instrument-control functions flawlessly, day and night, for
15+
> years.  (Well, actually, two errors surfaced during that time, but only
two.)  I
> can't remember ever writing a program with a memory violation (and yes, I
use
> pointers and OOP), and my programs almost always work right with little debugging.  I attribute success not to programming prowess, but to the simplicity and clarity of the language.

Modula 3 is derived from Pascal. I'd be interested then in your take on a comparison between M3 and D.

> I would like to pass on one other observation.  There is a programmer who
has
> been using Component Pascal (an Oberon variant) extensively for a few
years.
> (I'm not really advocating that, for irrelevant reasons.)  The compiler
and
> environment are written in the same language.  The point is that he claims
that
> he has made just about every kind of mistake possible, including dangling pointers, subtle type conversion errors -- you name it -- but he has not
had a
> single crash.  Maybe some infinite loops or other errors, but no memory
> violations or type errors.
> The $64 question:  can you match the simplicity and safety?  Please tell
me you
> can!

I think that is possible, but only more experience doing large projects in D will tell for sure.

>"Rex Couture wrote
>>  Are memory violations possible?  Is pointer arithmetic allowed?

Walter's reply
>Yes, and yes.

I guess it's too late, but I sure like the Java idea of no pointer arithmetic. Of course, pointers are used, they just don't admit to it.


>>  Are array subscript bounds always checked at run time?
>No, it is enabled/disabled with a compiler switch. D requires that programs not be coded in such a manner that they *depend* on array bounds checking (this is different from Java).

Now this is interesting!  How is this possible?  I missed this somehow.



>> 2. Is it simple?  I really like the philosophy of simplicity espoused on
>the
>> home page....
>Where to draw that line between features and simplicity will make or break D.

That's hard to say, isn't it?  Good luck!  I don't have any great wisdom here.


>> My preferred language so far is Pascal -- you heard me right....  I attribute success not to programming prowess, but to the
>> simplicity and clarity of the language.

>Modula 3 is derived from Pascal. I'd be interested then in your take on a comparison between M3 and D.

I don't know.  Sorry, never tried M3.
It takes an enormous amount of effort to get into a language, with libraries and
all.  Unfortunately, Pascal and derivatives are plagued by dialects and division
of effort, as are all programming languages.


Thanks for your thoughtful reply.

On Fri, 26 Jul 2002 18:44:36 +0000 (UTC) Rex Couture <auser@levee.wustl.edu wrote:

> I guess it's too late, but I sure like the Java idea of no pointer arithmetic. Of course, pointers are used, they just don't admit to it.

Pointers (and arithmetic) are necessary for low-level system programming.

But well, if you want safety, do you really _need_ pointers? You've got references to objects - and these don't support arithmetic (although one could cast them to byte*, and then...), just like Java.

>>No, it is enabled/disabled with a compiler switch. D requires that programs not be coded in such a manner that they *depend* on array bounds checking (this is different from Java).
> 
> Now this is interesting!  How is this possible?  I missed this somehow.

This means that for debug builds, compiler inserts checks to throw
an exception whenever array index is out of bounds. However, this
is implementation detail, and you should NOT rely on it in your
programs - in other words, never ever do something like this:

	try
		array[i] = 666;
	catch (EOutOfBounds)
		return;

"Rex Couture" <auser@levee.wustl.edu> wrote in message news:ahs5ak$2ot$1@digitaldaemon.com...
> >"Rex Couture wrote
> >>  Are memory violations possible?  Is pointer arithmetic allowed?
>
> Walter's reply
> >Yes, and yes.
>
> I guess it's too late, but I sure like the Java idea of no pointer
arithmetic.
> Of course, pointers are used, they just don't admit to it.
>

For the most parts, you don't need pointers. You can use one-dimensional dynamic arrays and object references for most occasions were you might have used pointers in C/C++. Also, all member fields of objects and variables are initialized on instantiation, so there are much smaller risks of using uninitialized variables.

But when you need pointers, they are there. Also, because of D's garbage collection, there is no need to free memory, so much smaller risks of memory leakage. This even works for pointers you have malloc'ed yourself, so not only for object references.


>
> >>  Are array subscript bounds always checked at run time?
> >No, it is enabled/disabled with a compiler switch. D requires that
programs
> >not be coded in such a manner that they *depend* on array bounds checking (this is different from Java).
>
> Now this is interesting!  How is this possible?  I missed this somehow.
>

In debug mode arrays are bounds-checked, but this code is
removed in release builds. This ensures that your code will
run at full speed in release mode, while still giving you
an easy way to check your code in debug mode.
The same goes for contracts (Design By Contract), check it
out:  http://www.digitalmars.com/d/ section Contracts.

<SNIP>
>
> >> My preferred language so far is Pascal -- you heard me right....  I
attribute success not to programming prowess, but to the
> >> simplicity and clarity of the language.
>

I like Pascal too.

<SNIP>


Nice too see more and more people taking an interest in D!


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail

In article <CFN374639694477315@news.digitalmars.com>, Pavel Minayev says...

>Pointers and arithmetic are necessary for low-level system programming. But well if you want safety do you really need pointers?  You've got references to objects - and these don't support arithmetic...

Actually, I hope I'm not making enemies here, but all variants of the Oberon language completely prohibit pointer arithmetic.  Nevertheless, they have been used extensively for systems programming, and at least two or three operating systems have been written and ported to several platforms.  The compilers are also completely written in Oberon.  You can easily verify that pointer arithmetic is prohibited by searching Google for ' "pointer arithmetic" Oberon '.  I don't know anything about the convenience of their approach, and they may use a safe substitute of some sort, but I'm pretty sure that they don't give up any capability by prohibiting pointer arithmetic.

I don't want to get into an argument about which is better (I don't use Oberon, but I am considering D, after all), but 's very hard to convince me that pointer arithmetic is either necessary or safe.  Maybe it's worth considering alternatives.

I do like the idea of references to objects, which makes possible such structures as linked lists.  I agree, I would never use pointer arithmetic for my own software, but I would never be sure about compilers and libraries.

The majority of commercial programs that I own crash from time to time because of memory violations.  D seems to be a big step in the right direction, but could it be made even safer?

In article <ahsbn4$9ms$1@digitaldaemon.com>, OddesE says...
>For the most parts, you don't need pointers. You can use one-dimensional dynamic arrays and object references for most occasions were you might have used pointers in C/C++.

That's good news.  I think object references are really pointers by another name, but they do seem safe.

>Also, all member fields of objects and variables are initialized on instantiation, so there are much smaller risks of using uninitialized variables.

Oooh!


>But when you need pointers, they are there. Also, because of D's garbage collection, there is no need to free memory, so much smaller risks of memory leakage. This even works for pointers you have malloc'ed yourself, so not only for object references.

Aaah!  :-)


>In debug mode arrays are bounds-checked, but this code is removed in release builds.

Ouch!  I still have legacy Fortran code (my own, unfortunately) that occasionally violates array bounds after "successful" debugging and years of use.  Personally, I've never needed to turn off bounds checking, but I acknowledge that it is necessary to do so for some applications.  One trick that often can be used, incidentally, is to hand-code bounds checking outside the loop, so it takes essentially no time.


>The same goes for contracts (Design By Contract), check it out:  http://www.digitalmars.com/d/ section Contracts.

I'll do it.  I'm getting an education here.


>> >> My preferred language so far is Pascal -- you heard me right....
>...Nice too see more and more people taking an interest in D!

Well, Pascal-derived languages all have some sort of limitation (like dialects or missing essentials), and I am definitely considering alternatives for future development.  There's a lot to like in D.  So far, all languages are a pain in some way, but I am still hoping for improvements.  By the way, I have given my share of grief to those Swiss guys too, trying to instigate some improvements. Occasionally they say I'm right, but it's always too late.

Thanks again to you and Walter and Pavel.

In article <ahsbn4$9ms$1@digitaldaemon.com>, OddesE says...
>The same goes for contracts (Design By Contract), check it out:  http://www.digitalmars.com/d/ section Contracts.

The contracts implementation is very nice.  There is one other very useful way of implementing this, which I can recommend if it fits your coding style.  It not only complements assert statements, but it can be used if assert statements are not available.

I often place pre- and post-conditions in comments.  Like the enforced contracts, this encourages a formal way of looking at the contract, and it encourages you to identify and examine all possibilities when you are coding.

It seems to me that this can be used to complement assert statements, in two ways.  In particular, you can use it as a reminder to verify preconditions at the coding stage, when using previously debugged functions.  In addition, you may not be able to test all possibilities by example, during debugging, and it encourages one more analysis of the possibilities.  The only drawback is that you need to keep comments with the headers.

Pavel Minayev wrote:

> On Fri, 26 Jul 2002 18:44:36 +0000 (UTC) Rex Couture <auser@levee.wustl.edu wrote:
> 
> 
>>I guess it's too late, but I sure like the Java idea of no pointer arithmetic.
>>Of course, pointers are used, they just don't admit to it.
>>
> 
> Pointers (and arithmetic) are necessary for low-level system programming.


> But well, if you want safety, do you really _need_ pointers? You've got
> references to objects - and these don't support arithmetic (although
> one could cast them to byte*, and then...), just like Java.


If you don't need them, you're certainly already coding in a style that doesn't use them, so this issue is moot.  If you do need them, the language provides for it, so this issue is moot.

Cross-type casting is dangerous, and I don't mean just for portability reasons.  Consider the nonsense code:

    float g1, g2;

    float foo (int *p)
    {
        float res = g1 + g2;

        *p = 0;
        return res + g1 + g2;
    }

A compiler of C doesn't have to consider that "p" may point to "g1" or "g2", so it can freely mix the operation in such a way that it comes out all wrong if it does.  Type-based alias optimisations are pretty advanced, but they're becoming a reality in some compilers and definitely will be important in the future.  The solution is (if p could be one of g1 or g2):

    union e
    {
        float f;
        int i;
    }

    float foo (e *p)
    {
        float res = g1 + g2;

        p1->i = 0;
        return res + g1 + g2;
    }

Thus the compiler has to assume that p->f could be g1 or g2.

One way the language can help to keep this from being a problem is to prevent casting a pointer to anything but (void *), but allow (void *) to be casted to anything you want.  But this kind of error should be carefully written to make sure the programmer doesn't think the compiler's being gratuitously malicious or that there's no solution (see GCC's horrible error messages for longjmp).

On Fri, 26 Jul 2002 21:25:50 +0000 (UTC) Rex Couture <Rex_member@pathlink.com> wrote:

> '.  I don't know anything about the convenience of their approach, and they
may
> use a safe substitute of some sort, but I'm pretty sure that they don't give
up
> any capability by prohibiting pointer arithmetic.

I guess they just cast pointers to integers, then do arithmetic, then cast back. At least I did so when writing programs in Borland Pascal, where pointer arithmetic was forbidden as well. =)

Still I prefer the C way.

> I don't want to get into an argument about which is better (I don't use
Oberon,
> but I am considering D, after all), but 's very hard to convince me that
pointer
> arithmetic is either necessary or safe.  Maybe it's worth considering alternatives.

It is definitely not safe. But as long as you stick with references and
dynamic arrays, you don't even have to remember about this problem.

> I do like the idea of references to objects, which makes possible such structures as linked lists.  I agree, I would never use pointer arithmetic for my own software, but I would never be sure about compilers and libraries.

This would also assume that any program which has parts written in assembler should not be trusted, nor can you trust OS API calls (because they could use pointer arithmetic), nor drivers etc etc.

As long as it works correctly, why should I care if it uses pointer arithmetic
or not? It is a dangerous feature, indeed, but it is quite possible - and
not very hard, in fact - to use it properly. At least easier than inline
assembler.

> The majority of commercial programs that I own crash from time to time because of memory violations.  D seems to be a big step in the right direction, but could it be made even safer?

At a cost of power. For an example of what it could then turn into, see Java.