Re: Cobol work?
- From: mwojcik@xxxxxxxxxxx (Michael Wojcik)
- Date: 20 Oct 2005 15:21:26 GMT
In article <4iz5f.37655$S4.20966@edtnps84>, "Oliver Wong" <owong@xxxxxxxxxxxxxx> writes:
> "John Culleton" <john@xxxxxxxxxxxxxxxx> wrote in message
> news:OZadnYRVUOPeKcveRVn-ig@xxxxxxxxxxxxxxx
> > COBOL encourages the use of meaningful names, and other languages, at
> > least the way they are usually taught, don't.
>
> I'm not sure what you mean by this; I've never heard a computer science
> teacher say "Don't use meaningful names", while I have heard several
> computer science teachers say "(Do) use meaningful names".
I think it's a highly suspect claim. It sounds like a generalization
from anecdote. I'd like to see some evidence for it.
> > COBOL also encourages meaningful internal documentation, starting with the
> > (original) IDENTIFICATION DIVISION. Other languages have commenting
> > mechanisms, but those languages are neutral on the subject. And internal
> > documentation is not part of the usual teaching method.
>
> This is true. For many languages I'm familiar with, a documentation
> system is usually processed by a third party application, and not the
> compiler (e.g. JavaDoc, Doxygen, C#'s XML documentation system, etc.)
Doxygen is "third party", but Javadoc and the C# documentation system
are part of the standard toolset from the primary vendor.
While C and C++, say, don't standardize an internal documentation
mechanism, Javadoc markup *is* a standard part of Java. Ditto for
the documentation systems of Perl and Python, for example. COBOL is
far from unique in this regard.
And using a separate tool for generating documentation is not a
compelling objection. My COBOL toolchain uses more than one step;
why should any other language be penalized for separating build steps
into separate processes? In fact, I consider that a distinct
advantage of a language implementation.
> However, it seems that the developper's toolset is moving more and more
> towards intelligent IDEs, where it starts to become difficult to know where
> one tool (e.g. the compiler) ends and another (e.g. the documentation
> processor) begins.
Which is precisely why I don't like IDEs - but I don't think they're
relevant to this matter anyway. Incorporating documentation into
source code doesn't depend on IDEs in any significant way. A
developer knows how to use the toolset or doesn't; whether it's
wrapped up in an IDE is inconsequential, at least for questions of
what tools are available.
> As an aside, I was surprised to discover that there actually did exist a
> language which seemed to DIScourage meaningful names: The GPSS language had
> "arbitrary" lengths for function names and variable (I forget the exact
> figures, but it was something like all names had to be between 4 and 8
> characters long), and restrictions such as variables whose type were integer
> had to start with either I, J or K, and variables whose type were real had
> to start with X, Y or Z (all other variables were assumed to be Strings).
Early BASICs had similar requirements.
Strictly-conforming C programs must not exceed the minimum limits
required of all implementations, which means that in the current
(1999) standard internal identifiers have only 63 significant (case-
sensitive) initial characters, and external identifiers have only 31
significant (case-insensitive) initial characters. That's usually
plenty, but prior to the 1999 standard the limits were 31 characters
for internal identifiers and only 6(!) significant initial case-
insensitive characters for external ones.
No one writes strictly-conforming C programs (there's a line of
argument that it's impossible to do so, because of the requirement
that a strictly-conforming program not depend on any implementation-
defined behavior), of course. And since nearly all C implementations
treated considerably more than six characters as significant for
external identifiers, that limit is almost universally ignored. But
you could have a conforming C implementation that treated all
external identifiers beginning with the same six characters as the
same identifier.
But that's not because C discourages meaningful names; it's because
it tries to support as many platforms as possible, including some
old, very limited ones.
--
Michael Wojcik michael.wojcik@xxxxxxxxxxxxxx
"Well, we're not getting a girl," said Marilla, as if poisoning wells were
a purely feminine accomplishment and not to be dreaded in the case of a boy.
-- L. M. Montgomery, _Anne of Green Gables_
.
- References:
- Cobol work?
- From: Martik
- Re: Cobol work?
- From: Judson McClendon
- Re: Cobol work?
- From: Christopher Pomasl
- Re: Cobol work?
- From: HeyBub
- Re: Cobol work?
- From: Michael Wojcik
- Re: Cobol work?
- From: Ian Dalziel
- Re: Cobol work?
- From: John Culleton
- Re: Cobol work?
- From: Oliver Wong
- Cobol work?
- Prev by Date: Re: [OT] Debugging, Ye Olde-Tyme Waye, Kind Of
- Next by Date: Re: [OT] Debugging, Ye Olde-Tyme Waye, Kind Of
- Previous by thread: Re: Cobol work?
- Next by thread: Re: Cobol work?
- Index(es):
Relevant Pages
|
