Re: Confusing language, was Re: Help help.. please.i am totaly new in ada programing

[Robert A Duff <bobduff@world.std.com>]

Robert Dewar <robert_dewar@my-deja.com> writes:

> 
> In article <wcc90462gqw.fsf@world.std.com>,
>   Robert A Duff <bobduff@world.std.com> wrote:
> > Still, you (and Robert Dewar) now blame it on deficiencies of
> > COBOL, which is quite fair.
> 
> No, we did not say it was a deficiency, to make such a claim
> indicates a lack of knowledge of COBOL and how it is used.

OK, you didn't say it was a deficiency, but I still think it *is* a
deficiency.  It's not *always* true that people who disagree with you
lack your knowledge -- sometimes they disagree for other reasons.  ;-)

> A fundamental principle of COBOL, not present in other
> languages, is that data is represented the same externally
> and internally and is fully portable. This leads directly to
> the character model of data.

I disagree.  It is possible to define a binary representation that is
still standard and portable.  So the fact that COBOL forces an unwelcome
choice between portability and efficiency, seems like a flaw to me.
Especially when, as you say, memory was 100,000 times more expensive.

>... This is not a deficiency, just
> a design decision with advantages and disadvantages. But once
> you have data in this form, it definitely is the case that
> 4-digit years will take up more expensive core memory than
> 2-digit years.
> 
> Note as a contrast Ada's view of how to store dates, which is
> completely hidden from the programmer. If you instantiate
> sequential I/O for a type with Calendar.Time in it, you get
> a tape full of highly implementation dependent data, something
> that one avoids like the plague in the COBOL world.

Right, and that's a flaw in Ada.  Ever since Ada 95 was standardized,
I've been thinking we made a big mistake: we should have made the
streams stuff portable.  Data portability seems like it's even more
important in these network times, than it was when COBOL was designed.

> The importance of data representation consistency in the COBOL
> world is so high that no compiler is viable unless it is bit
> compatible in data representation with standard IBM compilers,
> including the ability to use EBCDIC to represent character data.
> COBOL goes much further than Ada in worrying about *data*
> compatibility. For example, the standard stream data in Ada is
> nowhere near being portable!

Right, and I think that's bad.

- Bob