Re: Help Constructing Fictional Cross-Religious Movement

whheydt@xxxxxxxxxxx (Wilson Heydt) wrote on 08.09.05 in <IMH29E.Jy5@xxxxxxxxxxx>:

> In article <9dEtetGXw-B@xxxxxxxxxxxxxxxxx>,
> Kai Henningsen <kaih=9dEtetGXw-B@xxxxxxxxxxxxxxxxx> wrote:
> >whheydt@xxxxxxxxxxx (Wilson Heydt) wrote on 28.08.05 in
> ><ILwo9G.n35@xxxxxxxxxxx>:
> >> In article <4310F7D0.9020204@xxxxxxxxxxxxxxxxxx>,
> >> Brooks Moses <bmoses-nospam@xxxxxxxxxxxxxxxxxx> wrote:
> >> >Wilson Heydt wrote:
> >> >I see three reasons: (a) You know how to do something in Fortran that I
> >> >don't know how to do despite being pretty familiar with it, (b) COBOL
> >> >can do this where Fortran 95 can't, or (c) one of us isn't understanding
> >> >the other about what the "exact same thing" is.
> >>
> >> (a) is unlikely. My FORTRAN stopped at IV and that was some years ago.
> >>
> >> (b) is possible.
> >>
> >> (c) We'd have to sit down a compare notes....a lot. (Probably by
> >> brining my FORTRAN up to date as being easier than teachin you
> >> COBOL from scratch.)
> >
> >...
> >
> >> The
> >> biggest problem I would see would be a compiler and OS dependency. That
> >> how multiple calls from different programs are treated. If the OS
> >> allocates local memory for each caller, then the subroutine can just use
> >> it's local storage to manage the data. If not, the subroutine will need
> >> an additional variable to tell it which point is being referenced.
> >
> >See, differing jargon territory already - at least that makes close to no
> >sense to me, and it's about stuff I thought I knew quite a lot about.
> >
> >First of all, how do different programs come into this? I suspect by
> >"program" you mean something entirely different from what I mean, but as
> >in context the obvious alternative would be "subroutine" and you already
> >use that, it's unclear to me *what* your "program" could map to.
>
> For "program", think "compilation unit".

Ah. Um. Those which are linked together into what *I* think of as a
program, the division ought to be meaningless in this discussion; others
ought not to belong into the discussion.

> >It's unclear to me how something like this could possibly be OS dependent.
>
> How many differnt OSes have you used?

Let's see ...

Apple DOS; ProDOS; UCSD Pascal; CP/M; MVS; CMS; Amdahl UTS; Interactive
UNIX; Xenix; Linux; Apple OS X/Darwin; MS-DOS; Windows 3.x; Windows 9x;
Windows NT; OS/400 ... I'm sure I forgot some there; not counting multiple
versions of the same thing.

> >If it's compiler dependent, then it would seem to be outside of what the
> >language actually defines ... which would mean it's something you actually
> >*can't* do in COBOL, only in COBOL-with-extension-X which some compilers
> >implement and others don't.
> >
> >Unfortunately I don't know enough about COBOL to tell.
>
> So far as i can tell *every* compiler has extensions to the language
> and most of them are incomatible with each other. The best practice
> is not to use any of the extensions unless you ahve to, since they
> make porting much more difficult.

Which is why I explicitely point out what is and is not covered by the
unextended language - what *is* covered is, by definition, independent of
who and where implements it ... so long as they do their job right, of
course.

> >2. COBOL originated the idea of records or structs, but as is often the
> >case with early languages, it did so in rather clumsy ways. PL/1 ("throw
> >FORTRAN and COBOL together and try to make a language from that which can
> >do what both of them could"), which I actually used, still is rather
> >clumsy in that area.
>
> COBOL was originally only intended to hand "flat files", and mostly
> unit record files, at that. Remember that the language was designed
> before disk drives came into widespread use even on large systems.

Sure. It's just that languages like Pascal or C feel much less clumsy
doing exactly that stuff. In fact, I did not even (much) think about files
there but about data structure handling.

Maybe it's actually a separate concept that is relevant here - explicit
user-defined data types. If memory serves, PL/1 doesn't really have them,
and therefore probably neither does COBOL. These things are so fundamental
to the way I think about computers that it's hard to remember they weren't
universal from day one.

> >4. COBOL is rather strange in various other ways, symptomatic of its early
> >design. At least originally no recursion, for example.
>
> I don't think much of anything else was doing recursion circa 1956,
> either.

I'd be astonished if FORTRAN didn't, and that was older. If you're coming
from math and engineering like FORTRAN did, recursion is pretty much
obvious. Data which isn't integers or floats, on the other hand, isn't -
early FORTRAN didn't have anything useful in the text handling department,
for example; by the time Lisp 1.5 was implemented in FORTRAN, we've left
the early days, I believe.

> >5. COBOL comes with some database access facilities - very much pre-SQL, I
> >believe.
>
> Depends on the compiler and preprocessors.

Again, I mean COBOL the language as defined.

Kai
--
http://www.westfalen.de/private/khms/
"... by God I *KNOW* what this network is for, and you can't have it."
- Russ Allbery (rra@xxxxxxxxxxxx)
.

Relevant Pages

  • Re: Choice of programming language
    ... Language choice is a deeply religious issue, ... I also don't know how well the Fortran compilers are ... Do you have a bunch of money to drop on a compiler, ... other data structures? ...
    (sci.math.num-analysis)
  • Re: Fortran 2003 and F
    ... >> As the Fortran language keeps getting bigger, ... Walt's F compiler doesn't have ... what part of object-oriented programming ...
    (comp.lang.fortran)
  • Re: Python is far from a top performer according to benchmark test...
    ... >> Okay seems that you don't know a lot about compiler writing. ... >> Fortran does not have this problem so a lot of optimizations can be ... GNU Fortran uses the same backend as ... > language on which optimizations are done. ...
    (comp.lang.python)
  • Re: National Labs, Fortran, and free compilers
    ... The Salford Fortran ... > dollars on a programming course in order to learn an obsolete language ... We actually have a site license for the Slaford compiler. ... > graduate student, the lack of a tool such as Fortran 95 compiler will ...
    (comp.lang.fortran)
  • Re: new programming language idea
    ... |> compiler for a language like that a few decades ago. ... inclusions with the output being in fortran. ...
    (sci.logic)