Re: Is it possible to use the value of the PROGRAM ID within the source code?

From: Richard (riplin_at_Azonic.co.nz)
Date: 06/22/04 

Date: 22 Jun 2004 13:57:32 -0700

robert.deletethis@wagner.net (Robert Wagner) wrote

> Wrong. I stopped using GO TO in the '60s.

Until the universal availability of scope terminators there were
several ways that flow could be controlled around the problem areas
where a single full stop would terminate all scopes. Some of these
led to complexity problems of having too many small paragraphs, others
led to repitition of condition tests.

It is a matter of balancing 'purity' against complexity and
reliability. You may well have a level of purity that approached
sainthood (in your own church at least), but for others a more
pragmatic resolution was required.

> True, but Cobol is plagued with large programs more than other languages. It
> seems a feature of 'Cobol culture' as practiced in big shops.

I suspect that you have a rather limited experience. Large Fortran
programs used also to be found. But this is a matter of 'selection of
the fittest'. If large programs were a 'plague' then this would have
been resolved by the programming shops themselves. If they didn't
work or were too expensive in some way, the business case would have
removed them.

Just because you don't like them doesn't mean that they are wrong.

> >What particular OO features do you think that batch programs need ?
>
> Reusability.

But 'reusability' is not a unique feature of OO design. That is, it
is not necessary to have object orientation to have code reusability.

> Packaging logic close to the data it operates on.

That is a convenience for the source editing, perhaps better editing
tools will help you there.
 
> Packaging ALL logic that operates on a particular datum in one place.

Why is that actually an advantage ?

You seem to want, for example, a simple print report program to carry
all the baggage of the logic that would be used to update the file.
Instead of the programmer being able to focus on the _procedure_ being
performed, you want them to deal with all the other complexities.

This _may_ be appropriate in types of programs that actually do deal
with all possible actions that apply to data items, such as would
occur in interactive programs or where programmers may have to use all
the logic, but it is not an advantage where there are 'classes' of
programmers.

You don't need 24 gear gearboxes on local delivery vans.

> Ability to define structures more complex than a record or array.

Really ? Do they _need_ this ? Why ?

> Ability to perform operations on those structures more complex than Copy,
> facilitating abstraction in design.

Really ? Do they _require_ this ? Why. Give examples.

> Ability to change logic by overriding rather than modifying existing logic,
> especially useful when you don't have access to existing third-party code.
>
> Separation between low-level mechanics (reading files) and application logic.

All that you have done is listed a few features from an OO primer and
stated these are _required_.

There is no argumentation, no justification, no rationale, just you
want it.

> Garbage gets paged out of real memory.

Garbage _may_ be paged out of real memory, except where it resides in
the same pages or segments that non-garbage resides in. These objects
are created on the heap and ddrop out of scope in random ways. Some
remain and some are now garbage. Because of the granuality of the
address space being larger than a typical object the garbage may
reside in real memory. Garbage collection will allow that space to be
reused.

A little better understanding will allow you to make fewer errors of
judgement.
 
> Even with "lots of memory", multi-dimensional arrays can grow to
> multi-gigabytes. For instance, I wrote a 'program' (a series of modular
> programs) that parses freeform text documents, a very common data warehousing
> problem. Suppose I had allocated 30 bytes per word (not enough, as Cobol has
> shown), 20 words per line, 10,000 lines per document and a maximum of 3,000
> documents (way too small). My array would have taken 18GB. If I'd carelessly
> used INITIALIZE, every one of those bytes would have been touched.
 
> Because I used lists, it ran in 500MB.

You are attempting to use one extreme example to justify a general
case. I very much doubt that '500Mbyte' is 'very common'.

> >The problem with pointers is that they are the 'GO TO' of data.
>
> Only if they are single-threaded. The simplest tree is as fast as a binary
> lookup on an array. A tree can be made faster by increasing its width; an array
> cannot be speeded up.

Yet you finally did agree that your lists were actually slower than
arrays when challenged to prove your argument about speed, yet you
continue to make claims about how fast they are.

Increasing the 'width' of a tree built with pointers makes them slower
to create. There is _no_ restriction on having navigation paths in a
array by including index references to traverse the array in any
required manner. Your assertions merely show a lack of imagination.

> If I hadn't used pointers, the aforementioned freeform text program would have
> been impractical. It would have taken all day to process 3,000 reports rather
> than 5 minutes.

Or it could have been done in a language with more appropriate
features.

Relevant Pages

  • Part 4 of Short Steps Toward Generic Programming: KIND Genericity
    ... In this part I will again be discussing a feature that has been ... KIND and select the appropriate instance at compile-time in the ... Assumed Rank Arrays ... argument that don't require knowledge of the rank of the array. ...
    (comp.lang.fortran)
  • Re: Packages and returning errors
    ... > array intact. ... sub is_a_instance_method { ... my $class = shift; ... You need to fix the scope of $error by moving its declaration outside ...
    (comp.lang.perl.misc)
  • Re: Relative merits of Lisp-1 vs. Lisp-2?
    ... Many constructs in Common Lisp provide a way to control the scope of definitions: lexical scope, dynamic scope, shadowing in packages are constrained to that package, metaclass definitions affect only classes that are instances of that metaclass, and so on. ... The situation is less ideal for changing the read table for some compilation unit. ... Since ANSI Common Lisp doesn't specify when macro expansion takes place for interpreted code, you cannot easily use rebinding for specific parts of your code and expect reliable semantics. ... The only reason I'm anchoring my argument in a specific use case is to forestall the objection that the feature I'm advocating has no practical use. ...
    (comp.lang.lisp)
  • Re: Is it possible to use the value of the PROGRAM ID within the source code?
    ... > led to complexity problems of having too many small paragraphs, ... >> Ability to define structures more complex than a record or array. ... >> Garbage gets paged out of real memory. ...
    (comp.lang.cobol)
  • Re: Properly using Rubys specialness
    ... Ruby, I used this feature to add in a method to the Array class ... of making a class that inherited from Array and added that method. ... Open classes are best used sparingly. ...
    (comp.lang.ruby)