
Programming with Abstract Data Types (1974) [pdf] - tjalfi
http://web.cs.iastate.edu/~hridesh/teaching/362/07/01/papers/p50-liskov.pdf
======
gwenzek
I just have the feeling that the author is trying to explain OOP with the
vocabulary of 1974.

What did you find interesting in this paper?

~~~
eru
Some of those ideas are also in OOP. But I think that might just be seeing
what you are used to. The paper's ideas fit eg OCaml's ideas of modules and
abstract types just as well.

~~~
kirillkh
A key difference from OCaml's modules (besides the lack of type
parameterization) is Liskov's data types have associated data. So it's more
like Rust's structs. Also, like in Rust, there is no support for multiple
implementations of a single signature.

~~~
eru
Thanks!

Though couldn't you associate data with your OCaml modules, too?

~~~
kirillkh
It's been a while since I played with OCaml, but I'm pretty sure that modules
are stateless. A quick googling shows that you can use global state, but it's
not the same as one instance of state per one instance of struct as in Rust.

~~~
eru
I should have been less tentative: you can add values to modules, and you can
add mutable values to modules. And that state is not global at all. (Though
you might be able to ask for global state.)

They are often used without mutable state, but the language doesn't make them
so.

See eg [https://realworldocaml.org/v1/en/html/first-class-
modules.ht...](https://realworldocaml.org/v1/en/html/first-class-modules.html)

~~~
kirillkh
Then you were right, I should've checked before answering.

~~~
eru
No worries. Thanks!

------
miceeatnicerice
Not entirely on topic, obviously, but whatever: there's a strange emphasis on
the male pronoun in the first paragraph of this, that at first seems like a
kind of horrible hiccup from the past, but then, through its repetition,
becomes more clearly a sardonic gendering of the programmer-user from above,
which is excellent (if true)

~~~
westoncb
Maybe you are referring to some material from the opening like:

> _The programmer is initially concerned with satisfying himself (or proving)
> that his program correctly solves the problem. In this analysis he is
> concerned with the way his program makes use of the abstractions, but not
> with any details of how those abstractions may be realized. When he is
> satisfied with the correctness of his program, he turns his attention to the
> abstractions it uses._

I can imagine how to a modern reader the usage of the male pronoun here might
sound excessive, but I think it's useful to note that this would be standard
academic writing for the time. If I'm not mistaken, the switchover—away from
using the male pronoun as a gender neutral pronoun—began (very slowly) in the
late '70s. I remember reading an article Douglas Hofstadter wrote about how it
bothered him once he became aware of the issue, but he'd mostly been oblivious
until it was brought to his attention. The article also discussed various
solutions to the problem, many of which are now common place (but if I'm not
mistaken were fairly novel at the time). I think that article was from '79.

Edit: I was looking for the actual date Hofstadter's article was published,
but I'm not sure since all the references I can find to it are from his '85
book _Metamagical Themas_ whose contents was mostly (but not all) re-printing
stuff he'd written starting in the late seventies. I noticed (just now) his
article was included in a bunch of academic histories of gender in language,
so it may be a decent reference point after all. So it looks like the idea to
not use the male pronoun this way was pretty novel even in '85, probably.

~~~
abecedarius
[https://www.cs.virginia.edu/~evans/cs655/readings/purity.htm...](https://www.cs.virginia.edu/~evans/cs655/readings/purity.html)

