5 ms·

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

80 points by jgrodziski 4y ago

tuukkah 4y ago
Really interesting to compare such early thinking to where we are today. > 4. Values and objects in programming languages > Most languages confuse them. 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. https://justjavascript.com/ https://justjavascript.com/ 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. > Names should be fixed. Here, they are advocating the use of const/final (single-assignment) variables, which has become a best practice but wasn't widely available back then. This is orthogonal to the value vs object distinction though (with const-immutable being what pure FP requires.) However, further in conclusions: > 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 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.
- epolanski 4y ago
  > 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. How do the semantics change? They are arrays, they literally have pointers to their characters.
  - Jtsummers 4y ago
    > How do the semantics change? They are arrays, they literally have pointers to their characters. console.log("hello" == "hello") console.log([1,2,3] == [1,2,3]) These produce different results despite the surface similarity between the two expressions. If strings were just arrays, then both of these expressions should result in true or both in false, not different values.
    - epolanski 4y ago
      I don't think you've chosen a good example. A better one could've been that you can't reassign specific characters and the string is immutable, but its still a list of characters. Anyway, the author doesn't think about objects in the oop sense, kind the contrary he thinks any value representation in a computer (or even piece of paper) is an object.
      - Jtsummers 4y ago
        > I don't think you've chosen a good example. This comment makes zero sense. Here's the part that you quoted from the OP in this thread: >> 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. [emphasis added] Here's your response: > How do the semantics change? They are arrays, they literally have pointers to their characters. [emphasis added] My example provides an answer to your question, precisely as it relates to the statement you quoted. How is that possibly a bad example when it answers your exact question?
        epolanski 4y ago
        Because JS strings are obviously arrays (or if you prefer lists) of characters. > The String type is the set of all ordered sequences of zero or more 16-bit unsigned integer values (“elements”) up to a maximum length of 253 - 1 elements. Everytime the computer has to compare two strings it will have to compare the length and check whether each character is identical. The fact that a choice was made to make strings immutable or how to implement comparison for arrays doesn't take away from strings being arrays of 16bit chars.
        tuukkah 4y ago
        My bad, I shouldn't have said the semantics are completely different. I suppose I meant to say the semantics are defined separately. I also should have clarified that I talked of JS arrays and not the general concept of arrays or lists.
avgcorrection 4y ago
This is a very nomenclature-focused essay. But the names are still relatively salient for modern use. Relatively.
layer8 4y ago
Here is a more nicely formatted version: https://www.researchgate.net/publication/220177801_Values_and_Objects_in_Programming_Languages https://www.researchgate.net/publication/220177801_Values_an...
cratermoon 4y ago
Today we'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 "go through the back door"). 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 instances of points, just as there may be two int values, i, and n, which are equal but stored in different memory locations. 1 https://martinfowler.com/bliki/ValueObject.html https://martinfowler.com/bliki/ValueObject.html

80 points by jgrodziski 4y ago

Really interesting to compare such early thinking to where we are today. > 4. Values and objects in programming languages > Most languages confuse them. 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. https://justjavascript.com/ https://justjavascript.com/ 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. > Names should be fixed. Here, they are advocating the use of const/final (single-assignment) variables, which has become a best practice but wasn't widely available back then. This is orthogonal to the value vs object distinction though (with const-immutable being what pure FP requires.) However, further in conclusions: > 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 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.

epolanski 4y ago
> 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. How do the semantics change? They are arrays, they literally have pointers to their characters.
- Jtsummers 4y ago
  > How do the semantics change? They are arrays, they literally have pointers to their characters. console.log("hello" == "hello") console.log([1,2,3] == [1,2,3]) These produce different results despite the surface similarity between the two expressions. If strings were just arrays, then both of these expressions should result in true or both in false, not different values.
  - epolanski 4y ago
    I don't think you've chosen a good example. A better one could've been that you can't reassign specific characters and the string is immutable, but its still a list of characters. Anyway, the author doesn't think about objects in the oop sense, kind the contrary he thinks any value representation in a computer (or even piece of paper) is an object.
    - Jtsummers 4y ago
      > I don't think you've chosen a good example. This comment makes zero sense. Here's the part that you quoted from the OP in this thread: >> 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. [emphasis added] Here's your response: > How do the semantics change? They are arrays, they literally have pointers to their characters. [emphasis added] My example provides an answer to your question, precisely as it relates to the statement you quoted. How is that possibly a bad example when it answers your exact question?
      - epolanski 4y ago
        Because JS strings are obviously arrays (or if you prefer lists) of characters. > The String type is the set of all ordered sequences of zero or more 16-bit unsigned integer values (“elements”) up to a maximum length of 253 - 1 elements. Everytime the computer has to compare two strings it will have to compare the length and check whether each character is identical. The fact that a choice was made to make strings immutable or how to implement comparison for arrays doesn't take away from strings being arrays of 16bit chars.
        tuukkah 4y ago
        My bad, I shouldn't have said the semantics are completely different. I suppose I meant to say the semantics are defined separately. I also should have clarified that I talked of JS arrays and not the general concept of arrays or lists.

avgcorrection 4y ago

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

layer8 4y ago

Here is a more nicely formatted version: https://www.researchgate.net/publication/220177801_Values_and_Objects_in_Programming_Languages https://www.researchgate.net/publication/220177801_Values_an...

cratermoon 4y ago

Today we'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 "go through the back door"). 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 instances of points, just as there may be two int values, i, and n, which are equal but stored in different memory locations. 1 https://martinfowler.com/bliki/ValueObject.html https://martinfowler.com/bliki/ValueObject.html