Re: Ragged Array Proposal

[Robert Dewar <robert_dewar@my-deja.com>]

In article <t7zoy8vt8x.fsf@calumny.jyacc.com>,
  Hyman Rosen <hymie@prolifics.com> wrote:
> Robert Dewar <robert_dewar@my-deja.com> writes:
> > "more complicated" /= longer
> >
> > Actually the C version is quite a bit more complex, because
of
> > the rather peculiar rules about whether string pointers are
> > or are not constants, and about the issue of whether
> > "abc" == "abc" (in general of course the answer in C is no)
> >
> > It looks simpler, but that can hide a lot of sins :-)
>
> Like I said, I don't have proper Ada intuition. Frankly, for
all its
> supposed readability, looking at Ada code makes my eyes and my
brain
> swim. I think it's because Ada uses too many words and not
enough
> symbols. I've felt that way ever since I first saw Ada code lo
those
> many years ago, and I still feel so today.
>
> I would certainly say that C's type system is simpler than
Ada's.
> The C ragged array example is completely simple. Granted, you
have
> to know C, but that's true of any language.

No, I still disagree, the apparent simple syntax of C in this
case hides too many details. In particular, the fact that the
string literals are not what they appear, but instead are
implicit pointers is quite confusing.

In particular there are two confusing issues

1. Are the referenced strings constants or variables? As you
know the answer is not simple, and in some cases is even
implementation dependent in practice, or has compiler switches
to control the answer.

2. The equality check between two strings

   if (a == "the") { ...

   has difficult semantics. Generally it does not do at all
   what is expected, and in some cases again, the result can
   be implementation or compiler switch dependent.

Sure you can respond "well you have to know C", but, note that
a common type of publication in the C community are books that
go through pitfalls like this, and explain how to avoid falling
into them. Ada prefers an approach that avoids the pitfalls in
the first place.

There is even a C++ primer that has a section called "pitfalls"
in every chapter, outlining things that compile fine, but do not
do what you might expect at run time.

This kind of phenomenon is simply far less common in Ada, since
Ada was designed to avoid pitfalls of this kind, note that I
say far less common, not non-existant, but the difference is
striking.

Sure, if you know a language well enough, you can completly
insulate yourself from such problems. This is also true of
PDP-8 machine language, but this is NOT a legitimate argument
for writing in PDP-8 machine language!



>


Sent via Deja.com http://www.deja.com/
Before you buy.