Re: Simula (Was: The wisdom of the object mentors)
Date: Wed, 21 Jun 2006 15:23:48 +0100
Message-ID: <e7bkpn$30r5$1_at_news.ndhu.edu.tw>
> 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..."
"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.
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.
The game is over : cease and desist with the Simula mis-information.
Steven Perryman Received on Wed Jun 21 2006 - 16:23:48 CEST