Re: COBOL "non-myth" confirmed - Index and subscripts (MF on Windows)

On Sat, 22 Sep 2007 05:52:35 -0700, Alistair <alistair@xxxxxxxxxxxxxxxxxxxxx> wrote:

On 22 Sep, 06:22, Robert <n...@xxxxxx> wrote:
On Fri, 21 Sep 2007 09:52:17 -0700, Alistair <alist...@xxxxxxxxxxxxxxxxxxxxx> wrote:
I do wish you hadn't tugged my chain by bringing Evolution into the
argument. Especially as you don't appear to have much knowledge of how
Evolution works.

Comments below:

On 21 Sep, 01:16, Robert <n...@xxxxxx> wrote:
On Thu, 20 Sep 2007 08:07:13 -0600, Howard Brazee <how...@xxxxxxxxxx> wrote:
On Wed, 19 Sep 2007 21:51:48 -0500, Robert <n...@xxxxxx> wrote:

This is about evolution versus revolution. The evolutionary approach is to change one
thing, give it enough time to succeed or fail (testing) before moving on to the next
change.

Evolution is about incremental implementation of a multitude of
changes simultaneously (or even all at once).

Wrong, it's about one change at a time. Recommended reading: Notes on the Synthesis of
Form, by Alexander. It talks about how to design a teakettle, but is really about system
development in the abstract.


So, a bad analogy (Evolution) is being justified as applicable to
programming based upon a book telling me how to design a kettle? Again
you have failed. Evolution happens on many fronts simultaneously. A
successful evolution in one factor may result in the carriage of a
multitude of factors to the improved evolutionary form. Only some of
those improvements will be beneficial and many will be detrimental.
You can take the human as an example of the 'ultimate' evolved
organism on the planet. There is no form factor that the human has
that can be said to be the sole reason as to why we have become so
successful. However, other factors can be shown to be barely adequate
or even detrimental to human success: fallen arches; poor spinal
strucure; poor vision....

Evolution may appear to be one change at a time to a naive observer
but, in fact, there are many changes occuring all of the time.

Here's more about Alexander's ideas, from the blog of a Swedish programmer, Peter
Lindberg:

Christopher Alexander?s OOPSLA ?96 keynote is quite fascinating. Software patterns capture
proven ideas in a convenient format, and surely you hear the idea that if you?re savvy
about patterns and use them frequently, your software will be well-architected. (One of
the early papers on patterns, by Kent Beck and Ralph Johnson, was titled Patterns Generate
Architectures; I guess I should re-read that one.) In the keynote, Alexander says that his
idea of pattern languages goes well beyond that: it was intended to generate ?living
structure [and] coherent wholes?, even when applied by laymen.

Alexander mentions that he, after having worked for a while with pattern languages, found
out that they didn?t succeed:

[T]he buildings generated [by people using the patterns] were okay, but not profound.
[???] I [?] realized that whatever was going wrong wasn?t going to be corrected by writing
a few more patterns or making [them] a little bit better. There seemed to be something
more fundamental that was missing from the pattern language.

At about the same time I began to notice a deeper level of structure and a small
number (fifteen) of geometric properties that appeared to exist recursively in space
whenever buildings had life. These fifteen properties seemed to define a more fundamental
kind of stuff; similar to the patterns we had defined earlier, but more condensed, more
essential ? some kind of stuff that all good patterns were made of.

These were simple ideas. [P]roperties like ?boundaries? which will not only delineate
but connect the inside to the outside, or ?positive space,? as when you look at a Matisse
cutout and see that the space between the colored paper is not amorphous but also has
form.

These fifteen principles seem hard to swallow, but an immense amount of work has gone into
them. For instance, Alexander has conducted experiments to verify that the presence of the
fifteen principles in an object is empirically testable. People have been shown two
objects and asked which of them makes them feel ?more whole? or ?more alive?. He writes:
?it turns out that there is quite a striking statistical agreement, 80-90%, very strong,
as strong a level of agreement as one gets in any experiments in social science.? In
addition, he has written a series of four books about this, titled The Nature of Order: An
Essay on the Art of Building and The Nature of the Universe. (The books have a website.)

So, it doesn?t seem to be mere aesthetic principles. And the following claim (also from
the keynote) is stunning:

Compared to the pattern language that you?ve seen in A Pattern Language [Amazon.com]
these generative schemes are much more like what you call code. They are generative
processes which are defined by sets of instructions that produce or generate designs. They
are, in fact, systems of instructions which allow unfolding to occur in space in just the
way that I was talking about a minute ago [?], and are therefore more capable of producing
living structure. The published pattern language by comparison is static. The new
generative languages are dynamic and, like software, interact with context, to allow
people to generate an infinite variety of possible results ? but, in this case, with a
built-in guarantee of well-formed results. The design that is created is guaranteed, ahead
of time, to be coherent, useful, and to have living structure.

He talks about paradigms and how the major players of the old paradigm aren?t the major
players of the new paradigm. He says that architects may never realize this and suggests
that programmers should become the new architects, by creating software that embodies
these patterns and generative languages to support builders:

What I am proposing here is [?] a view of programming as the natural genetic
infrastructure of a living world which you/we are capable of creating, managing, making
available, and which could then have the result that a living structure in our towns,
houses, work places, cities, becomes an attainable thing. That would be remarkable. It
would turn the world around, and make living structure the norm again [?]

http://tesugen.com/archives/03/06/patternkeynote2

As I understand it, Alexander is supporting Pete's idea that design should be self-aware,
recursive, what some call 'interactive'. The Pattern Languages he finds inferior are
analogous to waterfall Cobol, being 'static', pretending the designer is capable of
anticipating every turn of events that will occur during the creation of a system.


The resolutionary approach is to change everything at once, for example to a new
language.

Evolution is inherentely safe;

Except for those who get left behind or out-competed or even those
blind evolutionary off-shoots which end up in dead-ends.

Dead-end, left behind and out-competed depend on your definition of success, or which
third party measure you choose to believe. I know poor people who live happy, rewarding
lives.

I'm poor, unhappy and lead a life that is largely unfulfilling. A
generalised example does not prove your case. That is an argument that
has raged elsewhere in this newsgroup.


revolution is inherently prone to failure. Evolution is the
preferred approach. The problem is it may be too slow to keep up with environmental
changes, either because the environment is changing rapidly or because resistance to
change slows evolution to a crawl. With Cobol, the latter is the case. Institutionalized
foot dragging (standards) slowed Cobol's evolution so much that it was doomed to failure,
to fall behind even a moderate pace of environment change. The only alternative, albeit an
undesirable one, was a revolutionary change to another language: Java.

You clearly don't have any idea why Cobol became so yesteryear and
java became the new fashion accessory.

Conventional answer: Object Oriented. Wait a minute, Cobol has that.

QED.


This could have been prevented by allowing Cobol to change at a normal rate. True
conservatives would have seen that, and thereby conserved Cobol.

Then which version of the myriad Cobols would be the one true cobol?

There's only One True Cobol -- The ANS/ISO Standard.

And all the other evolutionary forms of cobol have satisfied your
requirements for change and yet you persist in denigrating cobol for
its' failure to adapt and change.

Practitioners rejected changes to the language spec. They prefer to write Cobol in a style
that hasn't changed in 20 years. Also, the changes were too little, too late. We didn't
see foot-dragging when C++ was created in 1979.

What about the ones who destroyed Cobol with excessive resistance to change?

Resistance to change was not what killed Cobol.

It's the easiest to talk about. Cobolers don't want to discuss the real reason -- lousy
code.

It has already been observed by others that it is easier to write
cruddy code in Java than in Cobol. I believe that, with the wrong
attitude and poor application, it is possible to write cruddy code in
any computing language (with the possible excepetion of Befunge where
it could be argued that any program which executes is a success).

Authors of cruddy Java KNOW they're writing crud; it takes a conscious effort. Authors of
cruddy Cobol THINK they're writing good code.

When I once wrote cruddy Cobol for a magazine article, the effort was more difficult than
I expected. Numbered paragraphs and perform thru were easy. The hard part was cruddy
structure and logic, for instance the bloat of redundant code.


.

Relevant Pages

  • Re: COBOL "non-myth" confirmed - Index and subscripts (MF on Windows)
    ... Evolution happens on many fronts simultaneously. ... about patterns and use them frequently, ... Compared to the pattern language that you've seen in A Pattern Language ... With Cobol, ...
    (comp.lang.cobol)
  • DECLARATION OF MEANING
    ... Patterns, such as: ... A fairly straight-forward example is that the theory or biological evolution ... intrinsic evolutionary pressures. ... philosophy have smarts 'senza' making sense of the lifetime challenges ...
    (sci.bio.evolution)
  • Re: religion
    ... Evolution does not predict that lifeless dirt, all on its own, will form ... God A is much more complex than all ... by evolution) which targets that species, then all members of the species ... that recognizes patterns. ...
    (comp.lang.cobol)
  • Re: About certain stubborn stiff-legged axiomatic assertions that sources of heritable variation
    ... merely reworked Freudian psychology bundled up with the nominal fallacy and ... doesn't this suggest that the concept of 'convergent evolution' ... or the patterns we recognize as we possibly can. ... and environmentally and developmentally realized "actention selection ...
    (sci.bio.evolution)
  • More about Patterns...
    ... Christopher Alexander’s ideas of patterns has as its ... found in other programming languages — for example, ... is no pattern language involved, and there is nothing about QWAN. ... A deeper role in human life. ...
    (comp.lang.lisp)