Values and objects in programming languages (1982) [pdf]

Really interesting to compare such early thinking to where we are today.<p>&gt; <i>4. Values and objects in programming languages</i><p>&gt; <i>Most languages confuse them.</i><p>Indeed. All programmers have an intuition of (primitive, immutable) values and (mutable) objects, but e.g. Dan Abramov claims the intuition is often lacking w.r.t. how a specific language actually works in practice. His book Just JavaScript explicitly describes the full mental model for one language, and I found this approach valuable when I taught a JS bootcamp. <a href="https:&#x2F;&#x2F;justjavascript.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;justjavascript.com&#x2F;</a><p>For example, JS strings are superficially similar to an array of characters, but their semantics such as equality are completely different because strings happen to be primitives while arrays are not.<p>&gt; <i>Names should be fixed.</i><p>Here, they are advocating the use of const&#x2F;final (single-assignment) variables, which has become a best practice but wasn&#x27;t widely available back then. This is orthogonal to the value vs object distinction though (with const-immutable being what pure FP requires.)<p>However, further in conclusions:<p>&gt; <i>We have shown that objects correspond to real world entities, and hence exist in time, are changeable, have state, are instantiated, and can be created, destroyed, and shared.</i><p>I think this is the naive OO hype of the time (1982) talking: whether something should be modelled as a mutable object in a program is orthogonal to real world entities.

Here is a more nicely formatted version: <a href="https:&#x2F;&#x2F;www.researchgate.net&#x2F;publication&#x2F;220177801_Values_and_Objects_in_Programming_Languages" rel="nofollow">https:&#x2F;&#x2F;www.researchgate.net&#x2F;publication&#x2F;220177801_Values_an...</a>

Today we&#x27;d talk about value objects[1], small objects that represent simple entities whose equality is not based on identity. Some languages include types to represent things other than numbers. Things like Timestamp and Duration. Most modern languages allow defining new types, which can be made immutable (barring language features like reflection that &quot;go through the back door&quot;). For example a Point that has x and y values assigned at creation and unchangeable. Any Point{x,y} is equal to any other Point{x,y} if x and y are the same, so there is no need for identity. In practice, the runtime may keep different <i>instances</i> of points, just as there may be two int values, i, and n, which are equal but stored in different memory locations.<p>1 <a href="https:&#x2F;&#x2F;martinfowler.com&#x2F;bliki&#x2F;ValueObject.html" rel="nofollow">https:&#x2F;&#x2F;martinfowler.com&#x2F;bliki&#x2F;ValueObject.html</a>

This is a very nomenclature-focused essay. But the names are still relatively salient for modern use. Relatively.