Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: Simula (Was: The wisdom of the object mentors)

Re: Simula (Was: The wisdom of the object mentors)

From: S Perryman <a_at_a.net>
Date: Wed, 21 Jun 2006 15:23:48 +0100
Message-ID: <e7bkpn$30r5$1@news.ndhu.edu.tw>


"Robert Martin" <unclebob_at_objectmentor.com> wrote in message news:2006062012555670933-unclebob_at_objectmentorcom...

> On 2006-06-13 06:24:00 -0400, "S Perryman" <a_at_a.net> said:

>>> EWD is indirectly one of the fathers of OO.  His name is on a book named 
>>> "Structured Programming".  In that book Dahl and Hoare describe Simula 
>>> 67, arguably the first OOPL.  They talked about how they stumbled upon 
>>> the notion of objects by moving the stack frame of block-structured 
>>> function from the stack to the heap.

>> This is just bollocks.
>> And not even corroborated by what Nygaard and Dahl have written
>> themselves about the origins of Simula, or people who have researched >> the history of Simula (Jan Holmevik etc) . ***

>> Simula had objects from day 1, long before the NCC ran into the >> trap that basing their language on Algol-60 sprung.

> I didn't say anything about WHEN Simula had objects. I was talking bout
> the the way the idea was formulated. Below is thier own description of
> that formulation.

So you are talking about *the way they formulated the idea of objects* ??

From Jan Holmevik, "Compiling Simula" :

"The status on the Simulation Language (Monte Carlo Compiler) is that I have rather clear ideas on how to describe queuing systems, and have developed concepts which I feel allow a reasonably easy description of large classes of
situations. I believe that these results have some interest even isolated from
the compiler, since the presently used ways of describing such systems are not
very satisfactory. [...] The work on the compiler could not start before the language was fairly well developed, but this stage seems now to have been reached. The expert programmer who is interested in this part of the job will
meet me tomorrow. He has been rather optimistic during our previous meetings.[5]
As is evidenced from this letter, SIMULA was intended from the very outset to be
simultaneously a systems description and a programming language, its construction would thus require both systems reasoning and programming skills.
Even though Nygaard had some experience with computer programming at NDRE before
he was assigned to operations research in 1952, he did not have sufficient experience or knowledge to undertake an extensive task like this on his own. He
was compelled to recruit programming expertise from outside and the best ally he
could find, besides Garwick, was his old acquaintance from NDRE, Ole-Johan Dahl.
During the spring of 1962 Nygaard and Dahl joined in a series of discussions which in May, 1962 resulted in the first formal language proposal.

SIMULA at IFIP 62

In order to better understand Nygaard's reasoning at this point, it is helpful
to anticipate the course of events a little by examining how the language appeared when it was first presented publicly in the fall of 1962. The occasion
was the second international conference on information processing held in Munich, Germany in late August that year. In the introduction to his paper entitled "SIMULA--An Extension of ALGOL to the Description of Discrete-Event Networks," Nygaard explained the rationale behind SIMULA as follows: For operational research workers and others studying network systems, there is a
definite need for a precise language which allows a description of a network in
terms of standardized and generally accepted concepts. Such a description should
force the research worker to consider all relevant aspects of the network. SIMULA--SIMUlation LAnguage-- represents an effort to meet this need with regard
to discrete-event networks, that is, where the flow may be thought of as being
composed of discrete units demanding service at discrete service elements, and
entering and leaving the elements at definite moments [sic] of time. Examples of
such systems are ticket counter systems, production lines, production in development programs, neuron systems, and concurrent processing of programs on
computers.[6]
The early approach to SIMULA was, as evidenced by the quotation above, based on
the notion of a mathematically formulated network concept consisting of active
stations serving a flow of passive customers. As illustrated in Figure 7, these
stations consisted of a queue part and a service part, and the actions associated with the service part were described by a sequence of formalized statements. The customers possessed no similar operating rules, but were instead
described through a sequence of variables called characteristics. A customer was
supposed to be generated by the service part of a given station, then transferred to the queue part of another station, and subsequently to the service part of that station. Here the customer was "served", and then passed on
to the next station in the network, and so on until it ultimately disappeared by
not being transferred any further. The actions taken by the stations were regarded as instantaneous, occurring at discrete points in time, and accordingly, this class of systems was called discrete event networks.[7]"

The above is corroborated by Nygaard and Dahl (The History of the Simula Languages - pages 246 and 247) .

> Note the terms in which they couch our now familiar concepts of objects
> and constructors.

>> If you wish to refute this claim, please quote the *exact text* from your >> sources that show how the NCC "stumbled upon" objects.

> Structured Programming, Academic Press, 1972, p178-9.
> Including the following:

> "In ALGOL 60, the rules of the language have been carefully designed to
> ensure that the lifetimes of block instances are nested, in the sense that
> those instances are the latest activated and are the first go go out of
> existence. It is this feature that permits an ALGOL 60 implementation to
> take advantage of a stack as the method of dynamic storage allocation and
> relinquishment. But it has the disadvantage that a program which creates
> a new block instance can never interact with it as an object which exists
> and has attributes, since it has disappeared by the time the calling
> program regains control. Thus the calling program can observe only the
> results of the actions of the procedures it calls. Consequently, the
> operational aspects of a block are overemphasised; and algorithms (for
> example, matrix multiplication) are the only concepts that can be
> modelled.

> "In SIMULA 67, a block instance is permitted to outlive it's calling
> statement, and to remain in existence for as long as the program needs to
> refer to it. it may even outlive the block instance that called it into
> existence. As a consequence, it is no longer possible to administer
> storage allocation as a simple stack; a general garbage collector,
> including a scan-mark operation, is required to detect and reclaim those
> areas of store (local workspace of block instances) which can no longer be
> referenced by the running program."

> Clearly these guys figured out that if you moved the block (e.g. the
> function stack frame) from the stack, to the heap, you get:

> "...a wider range of concepts to be conveniently expressed..."

  1. Here is your *own* text :

"They talked about how they

stumbled upon
^^^^^^^^ ^^^^

the notion of objects ..."

As the text you have quoted says nothing of the kind (marked ^^^ ) , retract the claim.

2. Here is what Nygaard and Dahl say about storage allocation. From the Development of the Simula Languages - 1978, page 250 :

"2.3.2 Storage Allocation.

The initial plan was that the simulation facility should be implemented as a procedure package and a simple preprocessor on top of ALGOL 60. One idea that looked promising at the time came from the observation that ALGOL, by its recursive block mechanism, did cater for multiple
occurrences of user defined data structures rather like the "customers" that would go from one "station ~' to the next in our simulation models.

Also the station descriptions had block format. It turned out, however, that the block
structure of ALGOL was not very helpful, in fact the preprocessor would have to fight against it by breaking up the blocks, making local variables non-local, etc. There was no hope of integrating special purpose operations like "hold (time interval)" completely into the language, since it implied a kind of "parallel" processing foreign to ALGOL and conflicting with ALGOL's strict dynamic stack regime of procedure calls and storage allocation.

During the spring of 1963 we became more a .~ more convinced that the project was on a wrong track, and started toying with the idea of making nontrivial changes to ALGOL by breaking with the stack regime. Since that would have grave consequences for the storage management ofthe ALGOL run time system, we had to dig from that end.

During the summer and autumn of 1963 a storage allocation package was designed, based on a two-dimensional free area list (Dahl 1963). The inner lists contained areas of the same size, which we felt would be numerous in typical steady state situations; the outer list contained the inner ones ordered according to area size. Each area had a "used" bit in its first and last words to facilitate the recombination of neighbouring free areas. Thus the system had stack allocation as a special case, and could at the same time utilize the entire non-contiguous store of our computer.

With this solution to the storage allocation problem the search space for useful dynamic structures was drastically increased, and in Febuary 1964 the SIMULA process concept was born, ranging from pure data structures to quasi-parallel ALGOL programs."

Hmm, don't see the words "stumbled upon" , "by accident" etc here either.

But I do see that a concept of objects was first published by the Simula creators at least one year before the earliest time that you can possibly claim (the time at which they changed their storage allocation scheme) .

And the reason for the heap storage structure for Simula was a carefully considered development, and not something discovered by accident.

For years you have tried to suggest that the NCC were just a bunch of programmers hacking around with Algol, and that Simula and what is now OOP came from stumbling by accident upon something akin to the 'pencillin dish' discovery.

The reality, as told by the creators themselves, people who were involved with Simula (Ron Kerr etc) , and those who diligently researched the Simula projects (Jan Holmevik etc) , tells a different story.

The game is over : cease and desist with the Simula mis-information.

Steven Perryman Received on Wed Jun 21 2006 - 09:23:48 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US