"not here" <not.here@this.address.com> wrote in message news:1104_1014393359@news.digitalmars.com...

> Should I infer then that the average D programmer is always going to be an
average C/C++/C#/Java programmer too? Is this a short-sighted attidude for the future of D?

Definitely not. However, the most popular language nowadays is C++, so
C-centric
model seems most appropriate to me here.

> .meaning that Basic and Pascal are NOT practical languages, and their
users are NOT practical? Ummm. Sounds a little xenophobic to me.

Not really. It's just that C/C++ proves to be better in such cases. So should D.

> Why is that we spend hours of coding time to optimise a few micro-seconds
into a program? We no longer live in the age when computer time is more expensive than people time. It seems you are willing to sacrifice
> coders time rather than computer time. I don't think it's the best idea to
sacrifice coding speed, IMO.

There is no "sacrifice" in coding speed with 0-based indexing. Nothing you can't get used to, and, in fact, many programmers over the world are already. On other hand, that microsecond can cost you 20fps drop when writing a game which iterates through 100000 objects in a loop...

> Every good C programmer knows how useful the macro preprocessor is (oops,
that's not in D is it?)

Preprocessor thing had been discussed many times and there are _very_
serious reasons to ban it. After all, if you really need one, you
can always use an external program. Otherwise, most uses of preprocessor
in C are covered by constants, inline functions, and version/debug
statements in D.

> Every good C++ programmer knows how useful multiple inheritance can be
(ooops, that not in D is it?)

The latest discussion on the topic in this group shows that, in fact, most
C++
programmers use MI rarely or don't use it at all.

> Every good C++/Java/C# programer knows how useful namespaces can be
(ooops, that's not in D is it?)

Namespaces ARE good. And they are present in D - implicitly, each module is a namespace. Don't forget about packages as well. And the fact that each enum has its own namespace speaks for itself.

> Every C programmer can type #include files in their sleep (ooops, that's
not in D is it?)

    import c.stdio;

> Yes I know these are a little unfair. But what I'm trying to get across is
that D will already force C coders to learn/unlearn things. So why not have 1-based indexes, just like we use in the real world.

Even in the real world, indices aren't always 1-based.
Then again, with 1-based arrays, you can only have 2^32-1 elements,
while with 0-based you get the whole 2^32! Just think of all the
benefits this gives! =)

> Hey we got tradition! You can't mess that baby. Sure it makes things a bit
harder but you'll soon get used to that.

"Tradition" isn't something you should get used to. It's something that _most_ people got used two.

> Is this the same as saying "We can't do that new thing because its not
what we currently do"?

Almost. Just because it seems impractical.

> I could just as equally say "1-based indexing is not hard to get used to,
seeing you already do it everywhere else except when you are thinking like a computer."

Well, mathematicians don't use it.
Also, I understand why a user shouldn't think like a computer. But
why not programmer? Memory is indexed from 0, nothing you can do
with it. So are all that assembler opcodes that your program ends
up being, anyhow. You write programs for computers, not for men,
after all...

"Roberto Mariottini" <rmariottini@lycosmail.com> wrote in message news:a55s13$1c8a$1@digitaldaemon.com...

> So I'm not an "average"  C/C++/Java programmer, therefore I use them only
> since 1991/93/96.
> I know how slicing currently works in D, but I had to double check to
> understand.

End-exclusive slicing _is_ an issue, definitely. But we were talking about 0-based indexing.

> I always wondered why C and derivatives don't have a way to define a start
> index like Pascal does. To me it seems better to leave to the compiler the
> task
> to subtract the start index from the actual index. In C you write:
>
> int occurrencies['Z'-'A'];
> for (i = 0; i < size; ++i)
> {
>     ++occurrencies[s[i]-'A'];
> }
>
> Here the task to subtract 'A' to every indexing is left to the programmer.
>
> Maybe the compiler could live with an optional initial index to subtract
> every time
> the array is accessed.

This is a far better idea. What I like in Pascal is the ability to
use 0-based, 1-based or whatever else based arrays depending on
your task and your personal taste. Those who care of speed (me) would
probably use 0-based (and I believe it should be the default, to
work the same way as in C/C++). Otherwise, you can specify it yourself:

    int[5]    foo;     // consists of foo[0] to foo[4]
    int[1..5] bar;     // consists of bar[1] to bar[5]

not here wrote:
> Heaven forbid that we should try to retrain C coders! 
> Everyone knows that we are sacrosanct and must be protected.
> Every good C programmer knows how useful the macro 
> preprocessor is (oops, that's not in D is it?)
> Every good C++ programmer knows how useful multiple 
> inheritance can be (ooops, that not in D is it?)
> Every good C++/Java/C# programer knows how useful namespaces 
> can be (ooops, that's not in D is it?)
> Every C programmer can type #include files in their sleep 
> (ooops, that's not in D is it?)
> 
> Yes I know these are a little unfair. But what I'm trying to 
> get across is that D will already force C coders to learn/
> unlearn things. So why not have 1-based indexes, just like
> we use in the real world.

I don't see the problem as being one of tradition -- as you point
out, Walter has dispensed with a number of C/C++ traditions -- but
of practicality. The changes you describe above are wholesale
removals of features that the compiler can slap you for very
quickly if you forget about. Trying to use the preprocessor in
D clearly won't lead to subtle bugs; the compiler will scream and
the typical programmer will very quickly adapt.

Changing the index base will create subtle bugs, because code
that would compile in C or C++ will still frequently compile in
what I'll call D-1 (D with 1-based arrays), but change its meaning.
That scares me. The most common error, of course, will be accessing
the zeroeth element of a 1-based array, which should throw an
exception, but how about the following code:

  void parse_command_line_option( char[] option )
  {
     switch (option[1]) // switch on the chracter after the '-'
     {
        case 'x': do_option_x(); break;
        case 'y': do_option_y(); break;
        default: printf("undefined option\n"); break;
     }
  }

The comment is correct for C/C++, but in D-1 the comment is
misleading and both "-x" and "-y" yield an undefined option
message.

-RB

On Fri, 22 Feb 2002 21:27:16 +0300, "Pavel Minayev" <evilone@omen.ru> wrote:


> There is no "sacrifice" in coding speed with 0-based indexing.
>
Maybe not for you!

> ...
> Nothing
> you can't get used to, and, in fact, many programmers over the world
> are already. On other hand, that microsecond can cost you 20fps drop
> when writing a game which iterates through 100000 objects in a loop...

Actually the instruction time for an add is more like 1 ns. these days,
especially on computers where speed is a concern.
The cpu has multiple execution units, so the add would frequently be done
in parallel with other instructions, costing 0 time.
The +1 will often be combined with another  constant costing 0 time.
Many assembly instructions used for array access use an addressing mode
that adds a constant whether it is needed or not, again 0 time.

Finally there is the issue of how often the +1 comes up in the first place.
arr[2]   -- no +1
arr[x]   -- no +1 unless the programmer has stored the wrong thing in x
Of course you run into a problem if you pass a cardinal to something that
expects an ordinal!

An interesting point:
Addressing arrays with cardinals implies the existence of an element at [-1].
There are no negative ordinals!

> 
> Even in the real world, indices aren't always 1-based.
>
The obvious example is computer hardware, which uses cardinal indexes.

> Then again, with 1-based arrays, you can only have 2^32-1 elements, while with 0-based you get the whole 2^32! Just think of all the benefits this gives! =)
>
Actually, I think cardinal arrays have (theorectically) half as many
indexes. Unless you count (shudder) negative indexes.
I suppose implementation issues would limit ordinal arrays
though.

> > Is this the same as saying "We can't do that new thing because its not
> what we currently do"?
> 
> Almost. Just because it seems impractical.
>
The only thing about it that is even mildly difficult is that D is already written using cardinal arrays ( And that is a killer!)

> 
> Well, mathematicians don't use it.
> Also, I understand why a user shouldn't think like a computer. But
> why not programmer? Memory is indexed from 0, nothing you can do
> with it. So are all that assembler opcodes that your program ends
> up being, anyhow.

The program actually ends up being binary -- I would like to make as few concessions as possible to that unfortunate fact.

> You write programs for computers, not for men,  after all...

I write programs for 2 readers: compilers, and humans (If you can call
programmers that :-)
The great majority of my programming time is spent trying to satisfy the humans.

"Russell Borogove" <kaleja@estarcion.com> wrote in message news:3C76928A.8090508@estarcion.com...
> I don't see the problem as being one of tradition -- as you point
> out, Walter has dispensed with a number of C/C++ traditions -- but
> of practicality. The changes you describe above are wholesale
> removals of features that the compiler can slap you for very
> quickly if you forget about. Trying to use the preprocessor in
> D clearly won't lead to subtle bugs; the compiler will scream and
> the typical programmer will very quickly adapt.
>
> Changing the index base will create subtle bugs, because code
> that would compile in C or C++ will still frequently compile in
> what I'll call D-1 (D with 1-based arrays), but change its meaning.
> That scares me. The most common error, of course, will be accessing
> the zeroeth element of a 1-based array, which should throw an
> exception, but how about the following code:

And I want to emphasize this is an important point. D tries hard to avoid having incompatibilities with C that will subtly break things. 1 based arrays would do that. Another way to really mess people up would be to change the operator precedence. Since D is meant to appeal to C and C++ programmers, I feel it would be a mistake to change those things, regardless of how meritorious those changes are when viewed outside of the context of C familiarity.

I've done some conversions of a few thousand line programs from C++ to D, and it's bad enough finding and fixing all the dependencies on 0 terminated strings. That turns out to be more work than I'd anticipated.

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a562qa$5lv$1@digitaldaemon.com...
> This is a far better idea. What I like in Pascal is the ability to
> use 0-based, 1-based or whatever else based arrays depending on
> your task and your personal taste. Those who care of speed (me) would
> probably use 0-based (and I believe it should be the default, to
> work the same way as in C/C++). Otherwise, you can specify it yourself:
>
>     int[5]    foo;     // consists of foo[0] to foo[4]
>     int[1..5] bar;     // consists of bar[1] to bar[5]

Having lower bounds specifiable will work with D (and even with C), but in my decades (!) of programming I've never found a use for it. I came to C from Basic, FORTRAN, and Pascal. I had some initial trouble getting used to 0 based rather than 1 based, but never looked back. 0 based looked more 'right' to me.

"Walter" <walter@digitalmars.com> wrote in message news:a56tc2$1534$1@digitaldaemon.com...
>
> And I want to emphasize this is an important point. D tries hard to avoid having incompatibilities with C that will subtly break things. 1 based arrays would do that. Another way to really mess people up would be to change the operator precedence. Since D is meant to appeal to C and C++ programmers, I feel it would be a mistake to change those things,
regardless
> of how meritorious those changes are when viewed outside of the context of
C
> familiarity.
>
> I've done some conversions of a few thousand line programs from C++ to D, and it's bad enough finding and fixing all the dependencies on 0
terminated
> strings. That turns out to be more work than I'd anticipated.

Thanks for this explanation, Walter. I now have a better understanding of your goals for D. I wish you and your endevours well. I think you are off to a good start.

Goodbye.

> 
> And I want to emphasize this is an important point. D tries hard to avoid having incompatibilities with C that will subtly break things. 1 based arrays would do that. Another way to really mess people up would be to change the operator precedence. Since D is meant to appeal to C and C++ programmers, I feel it would be a mistake to change those things, regardless of how meritorious those changes are when viewed outside of the context of C familiarity.

So while ordinal arrays might be more technically correct, D would be less successful with them. However annoying that is, I'm sure you're right.


> 
> I've done some conversions of a few thousand line programs from C++ to D, and it's bad enough finding and fixing all the dependencies on 0 terminated strings. That turns out to be more work than I'd anticipated.
> 

0-terminated strings today; 0-terminated arrays tomorrow. (maybe in 'E').

 Karl

"Karl Bochert" <kbochert@ix.netcom.com> wrote in message news:1104_1014441056@bose...
> So while ordinal arrays might be more technically correct, D would be less successful with them. However annoying that is, I'm sure you're right.

Language design is inevitably going to be an uneasy alliance of contradictory goals <g>. It's like designing a house - to make a bigger closet, you have to shrink the bedroom.

I've been following this debate about slices and cases with some interest.  As a Python programmer, I'm rooting for end-exclusiveness in slices - it's the way Python handles slices, and seems to work very well in practice.  If D sticks with that, then I think there'll be a lot of Python programmers who will be able to make use of it very comfortably.

Another Python-ish thing that might be worth considering would be support for negative array indexes.  For example:

   foo[-1]  is the last element of array foo
   foo[-2]  is the second-to-last element of array foo

then with slices

   foo[-2..] would be the last two elements of foo
   foo[1..-1] would be a copy of foo, except for the first and last elements

implementation should be pretty simple, for any index < 0, such as: foo[-n], the compiler would just treat it like: foo[foo.length - n]

CASES
----------

When it comes to case-ranges though, I agree that end-exclusiveness would be a weird PITA.  Perhaps the thing to do is decide that case-ranges and array-slices will be different things, and go ahead and use different syntaxes.

To steal from Python again, perhaps use a colon for array slicing (foo[1:-1]) and keep '..' for case-ranges (which seems pretty natural).

This would also kind of make sense if you also supported Python-style negative array indexes, since negative numbers in case-ranges would presumably have a completely different meaning.

    Barry