On 20.11.2024 16:56, fir wrote:

i coded soem roguelike game loop which gave me
a lot of logical trouble

imagine game has micro turns, thise micro turns are
noted by
int game_time = 0; //styart with microturn 0

if you press a key on keyboard you update variable
of chuman character: character[HUM}.action_end = game_time+300
then the not human bits should execute in thise microturns
until you reacg turn 300 then you need to read keyboard again

what work is terribly weird, maybe becouse i started
with while loop and while loops from my experience
im not sure but imo tent do be logically heavy problematic
form tiem to time..what work is

While loops are no more problematic than any other standard
control structure with as simple an operational semantics.

void ProcessMicroturnsUntilHuman()
{
if( game_time < character[HUM].action_end)
{
while(game_time < character[HUM].action_end)
{
DispatchActions();
game_time++;
}
if(game_time == character[HUM].action_end) //**
DispatchActions();
}

}

(I recall to have seem exactly such a code pattern (i.e. the
'if <', 'while <', 'if =') about 40 years ago in an university
exercise, so I suppose that structure is an effect of a valid
algorithm structure property. - But that just aside. It may
soothe you.)

What I really suggest - and sorry for not literally answering
your question - is to implement (for your roguelike) an event
queue where you schedule not only your human player's actions,
but also the monsters, and other timed events in the game. I'm
aware that this might mess up your plans but I think it will
pay to have a cleaner "simulation structure", also with better
decoupling properties.[*]

is there some more proper form of this loop?
(the line nioted by ** i know is not needed but
overally this loop is weird imo

It looks not nice, indeed. But code structure follows demands.
And, at first glance, I see no better structural variant with
loops and conditionals.

Janis


[*] A friend of mine just recently implemented the code frame
for a roguelike and followed the suggestion of an event based
object-oriented implementation; it worked well, he told me.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 20 Nov 2024 17:34:34 +0100, Janis Papanagnou wrote:

[*] A friend of mine just recently implemented the code frame for a
roguelike and followed the suggestion of an event based object-oriented implementation; it worked well, he told me.

The next step would be to use coroutines so the logic of a longer-running
task, which has to wait for other events at multiple points, can be
written in a single linear stream without having to be fragmented into
multiple callbacks.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 21.11.2024 00:53, Lawrence D'Oliveiro wrote:

On Wed, 20 Nov 2024 17:34:34 +0100, Janis Papanagnou wrote:

[*] A friend of mine just recently implemented the code frame for a
roguelike and followed the suggestion of an event based object-oriented
implementation; it worked well, he told me.

The next step would be to use coroutines so the logic of a longer-running task, which has to wait for other events at multiple points, can be
written in a single linear stream without having to be fragmented into multiple callbacks.

Yes, indeed.

Actually, if you know Simula, coroutines are inherent part of that
language, and they based their yet more advanced process-oriented
model on these. I find it amazing what Simula provided (in 1967!)
to support such things. Object orientation[*], coroutines, etc.,
all fit together, powerful, and in a neat syntactical form. - But
"no one" is using Simula, and my friend was using C++; don't know
what C++ supports in that respect today. I know that he implemented
the "simulation" parts (queuing, time-model, etc.) in C++ himself.

Janis

[*] It was the language who invented Object Orientation - quite
naturally a concept from the simulation perspective -, but they
neither invented nor used the term "OO"; probably because it was
much more than that what they provided.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 21.11.2024 12:01, fir wrote:

there is a question qhat would be more logical (prone, suitable) here

for example it is a movement and say takes 200 mikroturns then logicall
would be to not do this as Setup() in turn 0 and finalize(0 in turn 200
but add 1/200 of distance in each turn.. but the rogualike is in
discrete space on tiles so i think setup() and finalize() is probably
better

more yet in things like fight ..say one character was Setuping() a hit
which takes like 90 microturns to finalize and the defender could be
able to setup() a shield blocking or something or decide to setup a
hit too

i dont tested it yet but my [previous approach without the actions that
spans in time was much simpler and you only eventually check what last
action of given bot waas bot not which next or current is

some would say tehe simpel would suffice but in fact if soeme want model
more nice system you need that spaning action time imo...sadly the
division of myriads of this actions on setup() and finalize() is worse
to code

My opinion on that...

For a roguelike, don't model it too detailed or too "realistic"; it
happens too often that you're getting lost in unnecessary complexity.

Keep it time-discrete (as you indicated above), define an integer of
sufficient length, don't use numeric types with fractions, define a
sensible base unit (that conforms probably to your 1/200 unit).

The start of action is the primary point in time. With "elementary"
actions (place a hit, quaff, read, loot, etc.) it's not worth to
complicate things; just consider the actual environmental situation
of the dungeon installations or individuals that affect your action
in any way.

It is an issue when _long lasting actions_ (like learning spells,
eating, etc.) will get "interrupted". Here I suggest to inspect the
Nethack code (obviously being still the "standard" roguelike), or
have a look into GnollHack (which IMO may have a more sophisticated
way to handle such interrupts). - I've not looked into the code so
I cannot give you concrete information; it's just from observation.

Practically I'd have, for example, an eating character put into a
queue at the time when its eating is supposed to get finished. In
case another actor or event pops in to affect the player (or the [user-perceivable] environment) the player object will be taken
from the queue, its status (e.g. unfinished food consumption)
updated, and rescheduled. The actual activation-time for that may
be immediately (after) the triggering event source, or delayed
(e.g. after gotten hit by sleep or paralysis) to the time it is
required for the effect to wear off.

I think such event-queues on a time-scale makes things more easier
and more consistent to implement.

(I also think that using C for such a task is not the best choice.
C++ at least provides classes to keep things together. - But that
just aside, to not angering the audience too much.)

Janis

REACTIVATE this.player DELAY meal_time (food_item.nutrition)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 21.11.2024 14:05, fir wrote:

well im somewhat experienced in writing roguelike (never make some
finished but i wrote them i dont know in sum maybe about 3-4 months day
bay dey

Yeah, I suspected so; that's why I initially wrote about my suggestion
that "this might mess up your plans".

previously i used thsi simpler approach and the conclusion from
experiecne was i need something that stores the action..

bothering bots i dont see as a problem but it is just needed to eb able
to bother them - not for being unable for bother them... i just need a
lot of cases when i could combine warious states for good efects

I was tempted to suggest, for the implementation details, to (also or
better) try a post in rec.games.roguelike.development but that group
appears to be dead.

spells in turn if casted just live on their own loop so they not block
a caster if are casted

I would have seen a spell-cast (as opposed to learning a spell) as a single-turn action, but that is of course a design decision.

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 21 Nov 2024 07:06:43 +0100, Janis Papanagnou wrote:

Actually, if you know Simula, coroutines are inherent part of that
language, and they based their yet more advanced process-oriented model
on these. I find it amazing what Simula provided (in 1967!) to support
such things. Object orientation[*], coroutines, etc., all fit together, powerful, and in a neat syntactical form.

Wirth did include coroutines in Modula-2. And a kind of object orientation
in Oberon, I think it was.

But these are (nowadays) called “stackful” coroutines -- because a control transfer to another coroutine can happen at any routine call, each
coroutine context needs a full-sized stack, just like a thread.

There is this newer concept of “stackless” coroutines -- not that they
have no stack, but they need less of it, since a control transfer to
another coroutine context can only happen at the point of an “await” construct, and these are only allowed in coroutine functions, which are declared “async”. I think Microsoft pioneered this in C♯, but it has since
been copied into JavaScript, Python and other languages.

Yes, Simula pioneered OO. But the concept has gone in different directions since then. For example, multiple inheritance, metaclasses and classes as objects -- all things that Python supports.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 22.11.2024 01:04, Lawrence D'Oliveiro wrote:

On Thu, 21 Nov 2024 07:06:43 +0100, Janis Papanagnou wrote:

Actually, if you know Simula, coroutines are inherent part of that
language, and they based their yet more advanced process-oriented model
on these. I find it amazing what Simula provided (in 1967!) to support
such things. Object orientation[*], coroutines, etc., all fit together,
powerful, and in a neat syntactical form.

Wirth did include coroutines in Modula-2. And a kind of object orientation
in Oberon, I think it was.

But these are (nowadays) called “stackful” coroutines -- because a control
transfer to another coroutine can happen at any routine call, each
coroutine context needs a full-sized stack, just like a thread.

Simula has also in objects own PCs (Program Counters) to enable each
object to be interrupted and resumed. Can't tell about Modula-2 and
Oberon, but I suppose they adopted quite some things from Simula, as
C++ and other languages adopted Simula concepts.

There is this newer concept of “stackless” coroutines -- not that they have no stack, but they need less of it, since a control transfer to
another coroutine context can only happen at the point of an “await” construct, and these are only allowed in coroutine functions, which are declared “async”. I think Microsoft pioneered this in C♯, but it has since
been copied into JavaScript, Python and other languages.

Not surprising that good concepts were adopted in other languages,
and expanded by own ideas. Rather it surprised me that some basic
IMO necessities were not; e.g. that C++ had no garbage collection
but Simula (and other languages) already had it long ago.

Yes, Simula pioneered OO. But the concept has gone in different directions since then. For example, multiple inheritance, metaclasses and classes as objects -- all things that Python supports.

Of course evolution will influence development of future languages,
and they may deviate or may also take new directions. Individual
language design decisions were arguable, though; I recall disputes
concerning, e.g., multiple inheritance (which is not necessary but significantly complicates an OO language) or that "everything must
be an object" to qualify as "real" OOL, and so on. I don't want to
start or continue these discussions here. Personally I found e.g.
C++'s multiple inheritance useful; that was a language I actually
used professionally. I also find it not very surprising if Python,
a quarter centenary after Simula, supports concepts (sensible or
not) that Simula didn't have. What I find impressive [in Simula]
is not only the new "OO" modeling concept but also how all their
software patterns fit together (the already mentioned coroutines,
or the prefix blocks; just for example to make clear what I mean).
As a pioneering language, as you rightly classify it, Simula had
no paragon for many things that it invented in an impressive way.

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 22 Nov 2024 00:04:32 -0000 (UTC)
Lawrence D'Oliveiro <[email protected]d> wrote:

On Thu, 21 Nov 2024 07:06:43 +0100, Janis Papanagnou wrote:

Actually, if you know Simula, coroutines are inherent part of that language, and they based their yet more advanced process-oriented
model on these. I find it amazing what Simula provided (in 1967!)
to support such things. Object orientation[*], coroutines, etc.,
all fit together, powerful, and in a neat syntactical form.

Wirth did include coroutines in Modula-2. And a kind of object
orientation in Oberon, I think it was.

But these are (nowadays) called “stackful” coroutines -- because a control transfer to another coroutine can happen at any routine call,
each coroutine context needs a full-sized stack, just like a thread.

There is this newer concept of “stackless” coroutines -- not that
they have no stack, but they need less of it, since a control
transfer to another coroutine context can only happen at the point of
an “await” construct, and these are only allowed in coroutine
functions, which are declared “async”. I think Microsoft pioneered
this in C♯, but it has since been copied into JavaScript, Python and
other languages.

By chance, few days ago I was writing a small GUI panel to present a
status from the hardware board we just finished building. In C#,
because despite me knowing C++ (at least "old" C++) 10 times better
than I know C#, building simple GUI in C# still takes me less time and
the result tends to look better. It was the first time I was doing UDP
in .Net and going through docs I encountered UdpClient.ReceiveAsync
method. Got excited thinking that's exactly what I need to wait for
response from my board while still keeping GUI responsive. But it was
not obvious what exactly this async/await business is about.
Read several articles, including one quite long. https://devblogs.microsoft.com/dotnet/how-async-await-really-works
More I read, less I understood how it helps me and what's the point.
In particular, handling timeout scenario looked especially ugly.
5-10 hours of reading were 5-12 hours wasted most unproductively.
At the end, just did it good old way by ThreadPool.QueueUserWorkItem()
with everything done synchronously by separate thread. Took me, may be,
two hours, including wrapping my head around Control.BeginInvoke and Control.Invoke.
So much for innovations.

Yes, Simula pioneered OO. But the concept has gone in different
directions since then. For example, multiple inheritance, metaclasses
and classes as objects -- all things that Python supports.

What I read seems to suggest that Smalltalk had bigger influence on
modern twists of OOP. But then, may be Simula influenced Smalltalk?
Anyway, I don't like OOP very much, esp. so the version of it that was
pushed down our throats in late 80s and early 90s.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Janis Papanagnou <[email protected]> writes:

On 21.11.2024 00:53, Lawrence D'Oliveiro wrote:

On Wed, 20 Nov 2024 17:34:34 +0100, Janis Papanagnou wrote:

[*] A friend of mine just recently implemented the code frame for a
roguelike and followed the suggestion of an event based object-oriented
implementation; it worked well, he told me.

The next step would be to use coroutines so the logic of a longer-running
task, which has to wait for other events at multiple points, can be
written in a single linear stream without having to be fragmented into
multiple callbacks.

Yes, indeed.

Actually, if you know Simula, coroutines are inherent part of that
language, and they based their yet more advanced process-oriented
model on these. I find it amazing what Simula provided (in 1967!)
to support such things. Object orientation[*], coroutines, etc.,
all fit together, powerful, and in a neat syntactical form. - But
"no one" is using Simula, and my friend was using C++; don't know
what C++ supports in that respect today. I know that he implemented
the "simulation" parts (queuing, time-model, etc.) in C++ himself.

[*] It was the language who invented Object Orientation [...]

No, it wasn't. First, programming in a language with classes and
objects does not imply object-oriented programming. Second, the
underlying ideas of object-oriented programming pre-date Simula 67
by five years or more. That history has been pointed out by
Alan Kay, who is the originator of the term and is responsible
for pioneering the concept.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Michael S <[email protected]> writes:

On Fri, 22 Nov 2024 00:04:32 -0000 (UTC)
Lawrence D'Oliveiro <[email protected]d> wrote:

Yes, Simula pioneered OO. But the concept has gone in different
directions since then. For example, multiple inheritance, metaclasses
and classes as objects -- all things that Python supports.

What I read seems to suggest that Smalltalk had bigger influence on
modern twists of OOP. But then, may be Simula influenced Smalltalk?

There is no question that Simula had an influence on the development
of Smalltalk; Alan Kay has said as much -

https://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en

But the ideas of object-oriented programming came before Smalltalk
(and also before Simula). It was the ideas underlying object-oriented programming that influenced the Smalltalk language, not the other way
around. (To be fair here I should add that other factors undoubtedly influenced Smalltalk as well.)

Anyway, I don't like OOP very much, esp. so the version of it that was
pushed down our throats in late 80s and early 90s.

Almost everyone who took Simula and C++ as the archetype for OOP
never understood it.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 05.12.2024 02:07, Tim Rentsch wrote:

Janis Papanagnou <[email protected]> writes:

Actually, if you know Simula, coroutines are inherent part of that
language, and they based their yet more advanced process-oriented
model on these. I find it amazing what Simula provided (in 1967!)
to support such things. Object orientation[*], coroutines, etc.,
all fit together, powerful, and in a neat syntactical form. - But
"no one" is using Simula, and my friend was using C++; don't know
what C++ supports in that respect today. I know that he implemented
the "simulation" parts (queuing, time-model, etc.) in C++ himself.

[*] It was the language who invented Object Orientation [...]

No, it wasn't. First, programming in a language with classes and
objects does not imply object-oriented programming.

It does not necessarily imply it. But if you'd know some more about
it you might understand that it's the natural way of thinking when
simulating systems' objects, and modeling object structures. Simula
in a natural way provided the platform to program object oriented.
(As said, without coining the term or speaking about "OO".)

Second, the
underlying ideas of object-oriented programming pre-date Simula 67
by five years or more.

Of course the ideas were there before Simula was released in 1967;
the inventors (also publicly) presented their ideas five years ago.

That history has been pointed out by
Alan Kay, who is the originator of the term and is responsible
for pioneering the concept.

Yes, the Simula "OO" pioneers didn't invent the *term* "OO", but they
were (amongst) the first who spread the ideas and the first inventing
a language to model OO and work with the OO concepts that are still
used and implemented in many other OO languages nowadays.

(All the rest is [IMO] no more than dogmatic or marketing.)

If you have some substance on the topic I'm always interested to hear.

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 05.12.2024 04:53, Tim Rentsch wrote:

Almost everyone who took Simula and C++ as the archetype for OOP
never understood it.

LOL.

(Funny [dogmatic] statement, without any substance again.)

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 05/12/2024 12:21, Janis Papanagnou wrote:

On 05.12.2024 04:53, Tim Rentsch wrote:

Almost everyone who took Simula and C++ as the archetype for OOP
never understood it.

LOL.

(Funny [dogmatic] statement, without any substance again.)

If you take the position that Alan Key, as the person who is credited
with inventing the term "object oriented programming", gets to make the definition of what OOP is, then Tim's statement is accurate. Originally
OOP meant something very different from how it is interpreted in C++.
(I don't know Simula except by reputation, so I can't comment on that.)

The original idea of OOP was to have self-contained "objects" that
communicated only by passing messages. If object A wanted object B to
do "foo", it would not call "B.foo()" in its own context, as is done in
C++. Instead, it would pass a message "foo" to B. What B does with it,
and when, is up to B. If a return value is expected, then B will send a message with the answer back to A.

This is, I think, akin to the modern "actor" programming paradigm, and
it has connections back to Hoare's CSP (which has inspired many systems
and languages, most recently Golang). It gives you a robust, modular
system with great scalability - objects can run on different cores or
threads, or different computers connected by a network. Data races and
other concurrency issues are pretty much impossible. Different parts of
the program could be changed at run-time.

Of course, all this has significant overheads - it is not suitable for a low-level high efficiency language. The rather different idea of OOP represented by languages like C++ can be very much more efficient, which
is why it caught on.

Perhaps the language that is most true to the original idea is Erlang,
with its "write once, run forever" motto.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 05.12.2024 16:06, David Brown wrote:

On 05.12.2024 04:53, Tim Rentsch wrote:

Almost everyone who took Simula and C++ as the archetype for OOP
never understood it.

If you take the position that Alan Key, as the person who is credited
with inventing the term "object oriented programming", gets to make the definition of what OOP is, then Tim's statement is accurate. Originally
OOP meant something very different from how it is interpreted in C++. (I don't know Simula except by reputation, so I can't comment on that.)

(For the topic discussed here I think it would be necessary, or at
least helpful, to know Simula, though.)

The original idea of OOP was to have self-contained "objects" that communicated only by passing messages. If object A wanted object B to
do "foo", it would not call "B.foo()" in its own context, as is done in
C++. Instead, it would pass a message "foo" to B. What B does with it,
and when, is up to B. If a return value is expected, then B will send a message with the answer back to A.

(see below)

This is, I think, akin to the modern "actor" programming paradigm, [...]

Of course, all this has significant overheads - it is not suitable for a low-level high efficiency language. The rather different idea of OOP represented by languages like C++ can be very much more efficient, which
is why it caught on.

Right.

Perhaps the language that is most true to the original idea is Erlang,
with its "write once, run forever" motto.

To open the knot, concerning this statement and the paragraph above
where you formulate "original idea of OOP", is to make clear what
each of us thinks would be crucial for "OOP".

If the "OO properties" are what at the time the term "OO" was coined
and associated with - which was rather late, as I think - is meant
then it would be a very limited view, focused by the inventor of the
*term* "OO". But the "OO" concepts - AFAICT - existed before the term.

If I look up various Wikipedia entries I find the properties
* Inheritance
* Polymorphism
* Encapsulation
* Abstraction
All of which have (for example) been implemented (besides some other
features that support Object Oriented Programming) already by Simula.

We find statements about separate, collaborating, communicating,
objects, about objects having attributes and "methods" (functions).

We also find statements like:
"Simula introduced important concepts that are today an essential
part of object-oriented programming, such as class and object,
inheritance, and dynamic binding."

Yet I haven't seen anyone who would dissent that Simula had been the
first implemented OO language (released 1967).

My (historic) experience with OO is that most people heard about OO
only in context of Smalltalk (1972) [Alan Kay]. Their specific (but
mostly unnecessarily introduced) terminology became common speech in
that context. And the long existing Simula wasn't even known widely.

As an anecdote: Decades ago there was an "OO expert" (B. Oestereich)
who gave (in the upcoming flourishing OO days of C++) speeches at IT
boards, he wrote books about the topic, gave interviews, and so on.
His first book started with on overview of the OO languages (with
Smalltalk as the root), and its descendants, and where it influenced
other languages. - I sent him a mail pointing to Simula (as being,
if not the root of all, at least the first OO language). Cautiously
he asked me about its features and conceded that his picture was
wrong. - The next edition of his book had that corrected.

And the whole discussion about OO had always mostly been done with
the worn blinkers. B. Stroustrup's mention of Simula in his books
somewhat contributed to get a more open minded view on OO, what it
is, and who has its most merits.

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Janis Papanagnou <[email protected]> writes:

On 05.12.2024 02:07, Tim Rentsch wrote:

Janis Papanagnou <[email protected]> writes:

Actually, if you know Simula, coroutines are inherent part of that
language, and they based their yet more advanced process-oriented
model on these. I find it amazing what Simula provided (in 1967!)
to support such things. Object orientation[*], coroutines, etc.,
all fit together, powerful, and in a neat syntactical form. - But
"no one" is using Simula, and my friend was using C++; don't know
what C++ supports in that respect today. I know that he implemented
the "simulation" parts (queuing, time-model, etc.) in C++ himself.

[*] It was the language who invented Object Orientation [...]

No, it wasn't. First, programming in a language with classes and
objects does not imply object-oriented programming.

It does not necessarily imply it. But if you'd know some more about
it you might understand that it's the natural way of thinking when
simulating systems' objects, and modeling object structures. Simula
in a natural way provided the platform to program object oriented.
(As said, without coining the term or speaking about "OO".)

I've been doing object-oriented programming, as explained by Alan
Kay, since the late 1970s. I've written code in Simula 67, three
different versions of Smalltalk, and C++. C++ is a pale shadow
of Simula, and Simula is a pale shadow of Alan Kay's vision of
object-oriented programming. People who think programming in C++
or Simula encourages object-oriented programming don't understand
the term.

Second, the
underlying ideas of object-oriented programming pre-date Simula 67
by five years or more.

Of course the ideas were there before Simula was released in 1967;
the inventors (also publicly) presented their ideas five years ago.

The key ideas underlying object-oriented programming were not done
by the people who developed Simula.

That history has been pointed out by
Alan Kay, who is the originator of the term and is responsible
for pioneering the concept.

Yes, the Simula "OO" pioneers didn't invent the *term* "OO", but they
were (amongst) the first who spread the ideas and the first inventing
a language to model OO and work with the OO concepts that are still
used and implemented in many other OO languages nowadays.

You are confusing programming with classes and objects as being
the same as object-oriented programming. It isn't.

(All the rest is [IMO] no more than dogmatic or marketing.)

If you have some substance on the topic I'm always interested to hear.

Let me offer some stories out of my own experiences.

In the mid 1970s, I listened to Alan Kay teach his class, over two
years, officially titled Philosophy of Computing but unofficially
titled The Alan Kay Mystery Hour. A lot of times I was baffled by
why he was talking about what he was saying, but I understood what
he was saying. At least that's what I thought at the time. I might
add that there was no direct explanation of either the Smalltalk
language or object-oriented programming -- both were mentioned but
pretty much only in passing. My reaction then was mostly that here
is another guy with a favorite language but programming languages
are all basically the same. (I had already been exposed to Simula
before taking Alan's class.)

A year or so after finishing Alan's class, I took a class titled
(IIRC) "Object Oriented Programming", taught by three graduate
students who had worked in Smalltalk (which at the time must have
been Smalltalk 76). The course was basically how to program in
Simula as though it were Smalltalk. I was already proficient in
Simula before starting the class, and had no trouble following
what they were saying, programming-wise. But in one class hour
something interesting happened. Someone asked a question, and
the answer blew my mind. It was an epiphany. Suddenly lots of
the things that Alan had said fell into place; my perspective
had changed. For two years Alan had been talking over my head,
and in fact so far over that I hadn't even realized it.

Later, in the early-to-mid 1980s, I went to graduate school at
the University of North Carolina. While there I had some
conversations with Fred Brooks about (among other things)
object-oriented programming. I tried to give an example that
would let him understand the idea I was trying to explain. I
could see by his reaction that it didn't help; the idea hadn't
gotten across. A year or two later one of the groups in Fred
Brooks's programming projects course (I don't remember the
official title) chose to do their project in Smalltalk. During
the end-of-course review/demonstration, a question about was
asked about changing the behavior of one part of the program
(which had a visual representation so it could be seen as soon as
the change was done). The person demonstrating said the change
could be made in two minutes. When Brooks prompted with "Let's
see", the demonstrator made the change on the spot. That made a
strong impression on Fred Brooks; he looked over at me with an
expression that said "there really is something to what you've
been saying".

That demonstration was possible not because of classes and
objects but because Smalltalk embodies the principles of
object-oriented programming.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-12-07, Keith Thompson <[email protected]> wrote:

Tim Rentsch <[email protected]> writes:
[...]

People who think programming in C++
or Simula encourages object-oriented programming don't understand
the term.

Or they use the term differently than you do. Language is not static.

Obviously, the term they don't understand is "encourages", not "object-oriented".

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @[email protected]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Keith Thompson <[email protected]> writes:

Tim Rentsch <[email protected]> writes:
[...]

People who think programming in C++
or Simula encourages object-oriented programming don't understand
the term.

Or they use the term differently than you do. Language is not static.

There's a confusion here. I didn't say they misunderstand the
term; what I said is they don't understand the term. That is
an essential difference.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)